k8s學習 - 概念 - ReplicaSet
首先,ReplicaSet 和 ReplicationController 基本上一樣,除了上篇說到的selector有不同之外,沒有啥區別。(官網也是這么說的)。但是為什么官方建議的不是ReplicaController + Deployment的集合呢?咋們也不敢說,咋們也不敢問。反正我就知道,用 ReplicationController 的值得被鄙視,用ReplicationSet +deployment 的現在是正統。
ReplicaSet
它和ReplicationController一樣用來控制pod的。ReplicationSet + deployment中,ReplicationSet都是由deployment自動生成的,我們不需要再寫一個replicaset.yaml。因為我們看中的是deployment的回滾、版本記錄等功能,deployment依賴的ReplicationSet自動生成會好過我們手動生成ReplicationSet。否則我們手動配置的哪個地方和deployment要求的不一樣,就很難查了。
下面是我用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的配置,前面章節已經說過了。所以整個配置文件縮略下來就是下面這個樣子:
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
我們就一個個研究這些沒有見過的配置:
metadata.generation & status.observedGeneration
這兩個是對應的,metadata.generation 就是這個 ReplicationSet 的元配置數據被修改了多少次。這里就有個版本迭代的概念。每次我們使用 kuberctl edit 來修改 ReplicationSet 的配置文件,或者更新鏡像,這個generation都會增長1,表示增加了一個版本。
這個版本迭代是配置文件只要有改動就進行版本迭代。observedGeneration就是最近觀察到的可用的版本迭代。這兩個只有在鏡像升級的時候有可能不同,當我們使用 kubectl rollout status
來探測一個deployment的狀態的時候,就是檢查observedGeneration是否大於等於generation。
metadata.ownerReferences
這個字段就需要說到 owner 對象的概念了。文章中這個 ReplicaSet 是通過 Deployment 自動生成的,所以這個 ReplicaSet 是屬於某個 Deployment的,那么那個 Deployment 就叫做它的 Owner,當前這個 ReplicaSet 就叫做那個 Deployment 的 Dependent。這個字段就是標注這個 ReplicaSet 的 Owner 信息。
blockOwnerDeletion 這個字段表示在刪除 Owner 對象的時候,是否要先刪除當前這個 Dependent。刪除一個 Owner 對象有兩種模式,一種是后台模式,就是先把 Owner 對象刪除,再在后台刪除它的 Dependent。另外一種是前台模式,先把所有的 Dependent 刪除(標記刪除),然后再刪除 Owner 對象。這里的 blockOwnerDeletion 就是表示當它的 Owner 的刪除策略是前台刪除的時候,是否需要考慮先刪除它。
controller 表示這個對象是否有管理它的控制器。
name, uid, kind 都是指向 Owner 對象的唯一標識。
metadata.resourceVersion
每個資源在底層數據庫都有版本的概念,我們可以使用 watch 來看某個資源,某個版本之后的操作。這些操作是存儲在 etcd 中的。當讓,並不是所有的操作都會永久存儲,只會保留有限的時間的操作。這個 resourceVersion 就是這個資源對象當前的版本號。
status
replicas 實際的 pod 副本數
availableReplicas 現在可用的 Pod 的副本數量,有的副本可能還處在未准備好,或者初始化狀態
readyReplicas 是處於 ready 狀態的 Pod 的副本數量
fullyLabeledReplicas 意思是這個 ReplicaSet 的標簽 selector 對應的副本數量,不同緯度的一種統計