kubernates 1.3出了几个新的概念,其中包括deployments,Replica Sets,而且官网称之为是the next-generation Replication Controller。因为NCE项目立刻就要使用其中包括deployments以及RS这个方式来管理pod,所以有必要了解下它的优越性。nginx
说RC以前先要提一个container和pod,container就是docker中的容器,pod能够理解为一个或者一组container。pod中的container能够进行共享资源。 RC-Replication Controller是一种资源对象,它能够经过json模板来建立,经过模板中定义的pod模板(Templet)来建立相应的带Lable的pod。RC经过包含的标签选择器(Label selector)来管理全部带相应label的pod。 下面是一个RC的定义模板文件:docker
"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是属于哪一个rcjson
"labels": { "name": "haohua2aa22-13275-c059ac0f" },
RC内pod变动大概有几种场景:api
1.经过设置副本个数能够动态的调整pod资源,若是将replicas设置为2,则控制器会自动去建立一个pod而且标签也设置为haohua2aa22-13275-c059ac0f。app
2.若是想删除资源,则须要将replicas设置为0,这时候控制器就会自动删除pod副本资源。须要注意若是直接删除RC,pod资源是不会被清理的。frontend
3.若是想更新service内rc中的pod,则须要用rolling Updates滚动更新模式,即逐个替换pod的方式来支持service的滚动更新,新建一个只有1个pod的rc,若新的rc副本数量加1,则旧的rc副本数减1,直到旧的rc副本数量为0,则删除旧的rc。ide
deployments是用来为pods和Replica Sets提供更新用的。Replica Sets被官网称之为下一代的RC,可见取而代之的决心,Replica Set 和Replication Controller仅有的区别是slector的支持,RS支持新的基于集合( set-based)的选择器,而RC只支持基于相等( equality-based )的选择器。ui
这边的两个概念基于集合( set-based);基于相等( equality-based ) 怎么来理解呢。spa
基于相等的就是说只能经过两种操做来设置:code
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
更多网易研发、产品、运营经验分享请访问网易云社区。