首先,ReplicaSet 和 ReplicationController 基本上同樣,除了上篇說到的selector有不一樣以外,沒有啥區別。(官網也是這麼說的)。可是爲何官方建議的不是ReplicaController + Deployment的集合呢?咋們也不敢說,咋們也不敢問。反正我就知道,用 ReplicationController 的值得被鄙視,用ReplicationSet +deployment 的如今是正統。php
它和ReplicationController同樣用來控制pod的。ReplicationSet + deployment中,ReplicationSet都是由deployment自動生成的,咱們不須要再寫一個replicaset.yaml。由於咱們看中的是deployment的回滾、版本記錄等功能,deployment依賴的ReplicationSet自動生成會好過咱們手動生成ReplicationSet。不然咱們手動配置的哪一個地方和deployment要求的不同,就很難查了。redis
下面是我用deployment自動生成的一個ReplicationSet的yaml配置文件:數據庫
kubectl get rs frontend-5c548f4769 -o=yaml apiVersion: extensions/v1beta1 kind: ReplicaSet metadata: annotations: deployment.kubernetes.io/desired-replicas: "3" deployment.kubernetes.io/max-replicas: "4" deployment.kubernetes.io/revision: "1" creationTimestamp: 2019-07-09T06:28:38Z generation: 1 labels: app: guestbook pod-template-hash: "1710490325" tier: frontend name: frontend-5c548f4769 namespace: default ownerReferences: - apiVersion: extensions/v1beta1 blockOwnerDeletion: true controller: true kind: Deployment name: frontend uid: c970981e-a212-11e9-89ff-025000000001 resourceVersion: "1471299" selfLink: /apis/extensions/v1beta1/namespaces/default/replicasets/frontend-5c548f4769 uid: c972e269-a212-11e9-89ff-025000000001 spec: replicas: 3 selector: matchLabels: app: guestbook pod-template-hash: "1710490325" tier: frontend template: metadata: creationTimestamp: null labels: app: guestbook pod-template-hash: "1710490325" tier: frontend spec: containers: - env: - name: GET_HOSTS_FROM value: dns image: gcr.io/google-samples/gb-frontend:v4 imagePullPolicy: IfNotPresent name: php-redis ports: - containerPort: 80 protocol: TCP resources: requests: cpu: 100m memory: 100Mi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 status: availableReplicas: 3 fullyLabeledReplicas: 3 observedGeneration: 1 readyReplicas: 3 replicas: 3
spec.template就徹底是一個pod的配置,前面章節已經說過了。因此整個配置文件縮略下來就是下面這個樣子:api
kubectl get rs frontend-5c548f4769 -o=yaml apiVersion: extensions/v1beta1 kind: ReplicaSet metadata: ... generation: 1 ... ownerReferences: - apiVersion: extensions/v1beta1 blockOwnerDeletion: true controller: true kind: Deployment name: frontend uid: c970981e-a212-11e9-89ff-025000000001 resourceVersion: "1471299" selfLink: /apis/extensions/v1beta1/namespaces/default/replicasets/frontend-5c548f4769 uid: c972e269-a212-11e9-89ff-025000000001 spec: replicas: 3 selector: matchLabels: app: guestbook pod-template-hash: "1710490325" tier: frontend template: ... status: availableReplicas: 3 fullyLabeledReplicas: 3 observedGeneration: 1 readyReplicas: 3 replicas: 3
咱們就一個個研究這些沒有見過的配置:app
這兩個是對應的,metadata.generation 就是這個 ReplicationSet 的元配置數據被修改了多少次。這裏就有個版本迭代的概念。每次咱們使用 kuberctl edit 來修改 ReplicationSet 的配置文件,或者更新鏡像,這個generation都會增加1,表示增長了一個版本。frontend
這個版本迭代是配置文件只要有改動就進行版本迭代。observedGeneration就是最近觀察到的可用的版本迭代。這兩個只有在鏡像升級的時候有可能不一樣,當咱們使用 kubectl rollout status
來探測一個deployment的狀態的時候,就是檢查observedGeneration是否大於等於generation。學習
這個字段就須要說到 owner 對象的概念了。文章中這個 ReplicaSet 是經過 Deployment 自動生成的,因此這個 ReplicaSet 是屬於某個 Deployment的,那麼那個 Deployment 就叫作它的 Owner,當前這個 ReplicaSet 就叫作那個 Deployment 的 Dependent。這個字段就是標註這個 ReplicaSet 的 Owner 信息。ui
blockOwnerDeletion 這個字段表示在刪除 Owner 對象的時候,是否要先刪除當前這個 Dependent。刪除一個 Owner 對象有兩種模式,一種是後臺模式,就是先把 Owner 對象刪除,再在後臺刪除它的 Dependent。另一種是前臺模式,先把全部的 Dependent 刪除(標記刪除),而後再刪除 Owner 對象。這裏的 blockOwnerDeletion 就是表示當它的 Owner 的刪除策略是前臺刪除的時候,是否須要考慮先刪除它。google
controller 表示這個對象是否有管理它的控制器。spa
name, uid, kind 都是指向 Owner 對象的惟一標識。
每一個資源在底層數據庫都有版本的概念,咱們可使用 watch 來看某個資源,某個版本以後的操做。這些操做是存儲在 etcd 中的。當讓,並非全部的操做都會永久存儲,只會保留有限的時間的操做。這個 resourceVersion 就是這個資源對象當前的版本號。
replicas 實際的 pod 副本數 availableReplicas 如今可用的 Pod 的副本數量,有的副本可能還處在未準備好,或者初始化狀態 readyReplicas 是處於 ready 狀態的 Pod 的副本數量 fullyLabeledReplicas 意思是這個 ReplicaSet 的標籤 selector 對應的副本數量,不一樣緯度的一種統計