前言
kubernates 1.3出了几个新的概念，其中包括deployments，Replica Sets，并且官网称之为是the next-generation Replication Controller。由于NCE项目马上就要使用其中包括deployments以及RS这个方式来管理pod，因此有必要了解下它的优越性。
回顾老版RC概念
说RC之前先要提一个container和pod，container就是docker中的容器，pod可以理解为一个或者一组container。pod中的container可以进行共享资源。 RC-Replication Controller是一种资源对象，它可以通过json模板来创建，通过模板中定义的pod模板（Templet）来创建相应的带Lable的pod。RC通过包含的标签选择器（Label selector）来管理所有带相应label的pod。 下面是一个RC的定义模板文件：
"kind": "ReplicationController",
"apiVersion": "v1",
"metadata": {
"name": "haohua2aa22-13275-c059ac0f",
"namespace": "90ab293349704831aa3977c450235fe1",
"selfLink": "/api/v1/namespaces/90ab293349704831aa3977c450235fe1/replicationcontrollers/haohua2aa22-13275-c059ac0f",
"uid": "87ee2f1e-4f16-11e6-96bb-fa163e70fcd5",
"resourceVersion": "9565340",
"generation": 1,
"creationTimestamp": "2016-07-21T07:41:26Z",
"labels": {
"name": "haohua2aa22-13275-c059ac0f"
}
},
"spec": {
"replicas": 1,
"selector": {
"name": "haohua2aa22-13275-c059ac0f"
},
"podCreatePolicy": "New",
"template": {
"metadata": {
"name": "haohua2aa22-13275-c059ac0f",
"namespace": "90ab293349704831aa3977c450235fe1",
"creationTimestamp": null,
"labels": {
"name": "haohua2aa22-13275-c059ac0f"
}
},
"spec": {
"containers": [
{
...(此处省略)
],
}
],
}
}
可以看到这个RC里面包含了一个容器的pod：haohua2aa22-13275-c059ac0f，该pod有1个副本（ "replicas": 1,）。 pod的模板文件中有一个labels标识pod是属于哪个rc
"labels": {
"name": "haohua2aa22-13275-c059ac0f"
},
RC内pod变更大概有几种场景：
1.通过设置副本个数可以动态的调整pod资源，如果将replicas设置为2，则控制器会自动去创建一个pod并且标签也设置为haohua2aa22-13275-c059ac0f。
2.如果想删除资源，则需要将replicas设置为0，这时候控制器就会自动删除pod副本资源。需要注意如果直接删除RC，pod资源是不会被清理的。
3.如果想更新service内rc中的pod，则需要用rolling Updates滚动更新模式，即逐个替换pod的方式来支持service的滚动更新，新建一个只有1个pod的rc，若新的rc副本数量加1，则旧的rc副本数减1，直到旧的rc副本数量为0，则删除旧的rc。
deployments&RS概念
deployments是用来为pods和Replica Sets提供更新用的。Replica Sets被官网称之为下一代的RC，可见取而代之的决心，Replica Set 和Replication Controller仅有的区别是slector的支持，RS支持新的基于集合（ set-based）的选择器，而RC只支持基于相等（ equality-based ）的选择器。
这边的两个概念基于集合（ set-based）；基于相等（ equality-based ） 怎么来理解呢。
基于相等的就是说只能通过两种操作来设置：
environment = production
tier != frontend
基于集合的不只是包含等于和不等于两种规则，还可以包含 in 和notin的方式来筛选。
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
下面来看看kubernetes 1.3的deployments是如何用模板文件定义的 这是一个官网的3的deployments是如何用模板文件定义的例子，我在1.3的环境下试着用命令创建了1个deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
kubectl create -f /root/cxq/jsonxml/nginx-deployment.yaml
deployment "nginx-deployment" created
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 0 12s
这个时候查询当前的rs，发现多了一个名字跟deployment有点关联性的rs
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get rs
NAME DESIRED CURRENT AGE
nginx-deployment-1159050644 3 3 8m
在后面随机加了一串数字。 检查rs的json说明文件，看下跟之前的rc有什么区别【重点在此，请注意】：
kubectl get rs -o json
{
"kind": "List",
"apiVersion": "v1",
"metadata": {},
"items": [
{
"kind": "ReplicaSet",
"apiVersion": "extensions/v1beta1",
"metadata": {
"name": "nginx-deployment-1159050644",
"namespace": "default",
"selfLink": "/apis/extensions/v1beta1/namespaces/default/replicasets/nginx-deployment-1159050644",
"uid": "57fd01cc-4f29-11e6-9cce-fa163ee959c4",
"resourceVersion": "179452",
"generation": 1,
"creationTimestamp": "2016-07-21T09:56:06Z",
"labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
},
"annotations": {
"deployment.kubernetes.io/revision": "1"
}
},
"spec": {
"replicas": 3,
"selector": {
"matchLabels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}
},
"spec": {
"containers": [
{
...(此处省略)
}
}
},
}
]
}
可以看到labels的值不是只有一条name：value的格式，而是有两条。
"labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}
说明app=nginx或者包含nginx的都可以被筛选出来作为rs的pod 查看pod，并且模拟selector的筛选方式实验一下
当前系统有4个pod，其中前3个属于新建的rs
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 4m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 4m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225
test-5-5tcql 1/1 Running 0 1d 192.168.5.2 10.180.217.225
使用过滤器equality-based方法筛选，可以准确的筛选出来3条app=nginx的pod
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get pod -o wide -l app=nginx
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 5m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 5m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225
使用过滤器set-based方式筛选，看下能否筛选出来
使用in的规则筛选，则筛选出app中包含nginx的pod
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get pod -o wide -l 'app in (nginx)'
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 6m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 6m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225
使用notin规则，筛选出来app不包含nginx的pod（剩余的1条）
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get pod -o wide -l 'app notin (nginx)'
NAME READY STATUS RESTARTS AGE IP NODE
test-5-5tcql 1/1 Running 0 1d 192.168.5.2 10.180.217.225
总结
简单来说 rs的selector选择器多了两种除了相等和非相等之外的筛选模式，使得筛选和管理pod更为灵活。
本文来自网易云社区，经作者崔晓晴授权发布。
原文地址：kubernetes 1.3管中窥豹- RS（Replica Sets）：the next-generation Replication Controller
更多网易研发、产品、运营经验分享请访问网易云社区。