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
更多網易研發、產品、運營經驗分享請訪問網易雲社區。