K8S资源控制器
什么是控制器
kubernetes中建立了很多的controller（控制器），這相當于一個控制機，來管理pod的狀態和行為。
控制器的類型
- ReplicationController和ReplicaSet
- Deployment 無狀態負載
- DaemonSet 守護進程集
- StateFulSet 有狀態負載
- Job/cronJob 普通任務/計劃任務
- Horizontal Pod Autoscaling 自動擴展
ReplicationController和ReplicaSet
ReplicationController（RC）是用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會創建新的pod來代替，如果異常多出來的容器也會回收；
在新版本的kubernetes中建議使用ReplicaSet來代替ReplicationController，ReplicaSet 跟ReplicationController沒有本質的不同，只是ReplicaSet支持集合式的selector（通過標簽來選擇）；而ReplicationController不支持。
Deployment
Deployment為Pod和ReplicaSet提供了一個聲明式定義（declarative）方法，用來替代以前的ReplicationController來方便管理應用，典型的場景包括：
- 定義deployment來創建pod和replicaset
- 擴容和縮容
- 部署無狀態應用，只關心數量，不論角色等，稱無狀態
- 具有上線部署、副本設定、滾動升級、回滾等功能
- 提供聲明式更新，例如只更新一個新的image
例： 部署一個nginx應用
創建一個rs.ymal的文件，定義deployment來創建pod和replicaset
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
~
[root@master ~]# kubectl apply -f rs.yaml #創建一個pod
deployment.apps/nginx-deployment created
[root@master ~]# kubectl get pods # 查看pod信息
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-d9p6h 1/1 Running 0 27m
nginx-deployment-7848d4b86f-bnvdg 0/1 ContainerCreating 0 13s
nginx-deployment-7848d4b86f-xwn6c 0/1 ContainerCreating 0 13s
nginx-deployment-7848d4b86f-zf4bh 1/1 Running 0 13s
[root@master ~]# vim rs.yaml
[root@master ~]# kubectl get pods --show-labels #查看pod的標簽
NAME READY STATUS RESTARTS AGE LABELS
nginx-6799fc88d8-d9p6h 1/1 Running 0 30m app=nginx,pod-template-hash=6799fc88d8
nginx-deployment-7848d4b86f-bnvdg 1/1 Running 0 3m42s app=nginx,pod-template-hash=7848d4b86f
nginx-deployment-7848d4b86f-xwn6c 1/1 Running 0 3m42s app=nginx,pod-template-hash=7848d4b86f
nginx-deployment-7848d4b86f-zf4bh 1/1 Running 0 3m42s app=nginx,pod-template-hash=7848d4b86f
[root@master ~]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 56d
nginx-deployment 3/3 3 3 6m53s
[root@master ~]# kubectl get rs #查看pod的rs信息
NAME DESIRED CURRENT READY AGE
nginx-6799fc88d8 1 1 1 35m
nginx-deployment-7848d4b86f 3 3 3 8m40s
[root@master ~]# kubectl get pods -o wide #查看pod的詳細信息
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6799fc88d8-d9p6h 1/1 Running 0 39m 10.101.11.5 node2 <none> <none>
nginx-deployment-7848d4b86f-bnvdg 1/1 Running 0 11m 10.101.149.5 node1 <none> <none>
nginx-deployment-7848d4b86f-xwn6c 1/1 Running 0 11m 10.101.149.4 node1 <none> <none>
nginx-deployment-7848d4b86f-zf4bh 1/1 Running 0 11m 10.101.11.6 node2 <none> <none>
擴容或者縮容，比如我們把pod數目擴容到10個
[root@master ~]# kubectl scale deployment nginx-deployment --replicas 10
deployment.apps/nginx-deployment scaled
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-d9p6h 1/1 Running 0 50m
nginx-deployment-7848d4b86f-bnvdg 1/1 Running 0 22m
nginx-deployment-7848d4b86f-fjhld 1/1 Running 0 92s
nginx-deployment-7848d4b86f-nld5c 1/1 Running 0 92s
nginx-deployment-7848d4b86f-nmxlf 1/1 Running 0 92s
nginx-deployment-7848d4b86f-vmjgl 1/1 Running 0 92s
nginx-deployment-7848d4b86f-wbfbq 1/1 Running 0 92s
nginx-deployment-7848d4b86f-x86hq 1/1 Running 0 92s
nginx-deployment-7848d4b86f-xngl5 1/1 Running 0 92s
nginx-deployment-7848d4b86f-xwn6c 1/1 Running 0 22m
nginx-deployment-7848d4b86f-zf4bh 1/1 Running 0 22m
更新鏡像
查看當前pod中的鏡像（以nginx為例）
[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-9d68ffd75-bnvdg 1/1 Running 0 9h 10.101.11.7 node2 <none> <none>
web1-9d68ffd75-x86hq 1/1 Running 0 9h 10.101.149.4 node1 <none> <none>
web1-9d68ffd75-zf4bh 1/1 Running 0 9h 10.101.149.5 node1 <none> <none>
[root@master ~]# kubectl describe pod web1-9d68ffd75-bnvdg | grep image
Normal Pulled 9h kubelet Container image "nginx:1.21.4" already present on machine
[root@master ~]#
查看當前鏡像的nginx為1.21.4版本 升級1.21.5版本命令為
kubectl set image deployment web1（需要更新鏡像的deployment名稱） nginx=nginx：1.21.5 （新版本鏡像名稱） --rcode #可以記錄鏡像更新信息。
[root@master ~]# kubectl set image deployment web1 nginx=nginx:1.21.5
deployment.apps/web1 image updated
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
web1-594b7b7c6-xngl5 0/1 ImagePullBackOff 0 20s
web1-9d68ffd75-bnvdg 1/1 Running 0 9h
web1-9d68ffd75-x86hq 1/1 Running 0 9h
web1-9d68ffd75-zf4bh 1/1 Running 0 9h
[root@master ~]#
等待片刻再次檢查鏡像版本，發現鏡像已經變為1.21.5版本。
[root@master ~]# kubectl describe pod web1-594b7b7c6-fkqt9 | grep image
Normal Pulled 2m49s kubelet Container image "nginx:1.21.5" already present on machine
回滾
kubectl rollout undo deployment web1
[root@master ~]# kubectl rollout undo deployment web1
deployment.apps/web1 rolled back
[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-594b7b7c6-fkqt9 0/1 Terminating 0 4m58s 10.101.149.6 node1 <none> <none>
web1-594b7b7c6-nmxlf 0/1 Terminating 0 4m59s 10.101.11.10 node2 <none> <none>
web1-594b7b7c6-xngl5 0/1 Terminating 0 40m 10.101.11.9 node2 <none> <none>
web1-9d68ffd75-fjhld 1/1 Running 0 5s 10.101.11.11 node2 <none> <none>
web1-9d68ffd75-vmjgl 1/1 Running 0 6s 10.101.149.7 node1 <none> <none>
web1-9d68ffd75-wbfbq 1/1 Running 0 3s 10.101.149.8 node1 <none> <none>
[root@master ~]#
Deployment更新策略
滾動更新（rollingUpdate）和重建更新（Recreate）。這兩種更新策略差異如下：
重建更新（Recreate）
重建更新指的是先全部刪除已有的Pod對象，然后創建新版本的Pod對象。這種更新方式，最大的弊端是在更新過程中，運行的服務要有一定時間的中斷。但是有點在于這種方式的更新，沒有出現新、老版本的Pod共存，并且共同提供服務的階段。但是，相比于其有點，其缺點尤為明顯。
spec:
replicas: 1
strategy: #更新策略
type: Recreate #重建更新，默認是rollingUpdate
滾動更新（rollingUpdate）
在刪除一部分老舊版本的Pod的同時，創建新版本的Pod資源。這種更新方式的好處在于，可以維持服務的正常提供，服務運行不會中斷。但是這樣做的問題在于，會存在一段時間，新版本的Pod和舊版本的Pod同時提供服務，客戶端接收的服務可能來源于老版本的Pod，也可能來源于新版本的Pod，這將會導致服務上的差異性。事實上，相對比與其缺點，滾動更新策略的優點更加明顯，即業務連續不中斷，并且新老版本Pod并存可以使得提前檢驗新版本Pod的可用性，如果發現更新后服務出現問題，更是可以提前發現，提前處理。同時，滾動更新的缺點也可以通過分區域更新等方式來進行解決。因此，我們最常用的更新策略就是滾動更新，并且滾動更新也是Deployment控制器的默認更新策略。
Deployment可以保證在升級時只有一定數量的pod是down的，默認的，他會確保至少比期望的pod數量少一個是up狀態
DaemonSet
Daemonset確保全部（或者一些）Node上運行一個pod的副本。 當有Node加入集群時，也會為它新增一個pod。當有Node從集群中刪除時，這些pod也會被回收。刪除Daemonset時會刪除它創建的所有pod。
使用Daemonset的一些典型用法：
- 運行集群存儲daemon，例如在每個Node上運行ceph、glusterd
- 在每個Node上運行日志收集daemon，例如logstash、fluentd
- 在每個Node上運行監控daemon，例如Prometheus Node Exporter
文檔：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/
job
job負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或者多個pod成功結束
特殊說明:
- spec.template格式同pod一樣
- restartpolicy僅支持never或 onfailure
- 單個pod時，默認pod成功運行job即 結束
cronjob
cronjob管理基于時間的job，即：
在給定時間點運行一次
周期性的在給定時間點運行
典型用法是：
在給定的時間點運行job
創建周期性的運行job，比如發送郵件，數據庫備份等等。
StateFulSet
StateFulSet作為controller為pod提供唯一的標識，它可以保證部署和scale的順序。
StateFulSet是為了解決有狀態服務的問題（對應的deployment和Replicaset是為無狀態服務而設計），應用場景包括：
- 穩定的持久化存儲，即pod重新調度后還是能訪問到相同的持久化數據，基于PVC來實現
- 穩定的網絡標識，即pod重新調度后其PodName和HostName不變，基于headless service（即沒有cluster IP 的service）來實現
- 有序部署，有序擴展，即pod是有順序的，在部署或者擴展時要依據定義的順序依次進行（即從0到N-1，在下一個pod運行之前所有之前的pod都是running或者ready狀態），基于init container來實現。
- 有序收縮，有序刪除
例：
vim statefuset.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # 必須匹配 .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # 默認值是 1
template:
metadata:
labels:
app: nginx # 必須匹配 .spec.selector.matchLabels
spec:
containers:
- name: nginx
image: nginx:1.21.4
ports:
- containerPort: 80
name: web
[root@master ~]# kubectl create -f statefuset.yaml
service/nginx created
statefulset.apps/web created
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2m24s
web-1 1/1 Running 0 2m23s
web-2 1/1 Running 0 2m22s
[root@master ~]#
StatefulSet Pod 具有唯一的標識，該標識包括順序標識、穩定的網絡標識和穩定的存儲。 該標識和 Pod 是綁定的，與該 Pod 調度到哪個節點上無關。
對于具有 N 個副本的 StatefulSet，該 StatefulSet 中的每個 Pod 將被分配一個從 0 到 N-1 的整數序號，該序號在此 StatefulSet 上是唯一的。
創建一個busybox的pod來測試一下，可以直接訪問到statufulset集群內部
[root@master ~]# kubectl run busybox --image=busybox
pod/busybox created
[root@master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 0 4s 10.101.11.20 node2 <none> <none>
web-0 （唯一標識符） 1/1 Running 0 49m 10.101.11.14 node2 <none> <none>
web-1 1/1 Running 0 49m 10.101.11.15 node2 <none> <none>
web-2 1/1 Running 0 49m 10.101.149.10 node1 <none> <none>
[root@master ~]# kubectl exec -it busybox -- sh
/ # ping web-0.nginx #$(服務名稱).$(名字空間)
PING web-0.nginx (10.101.11.22): 56 data bytes
64 bytes from 10.101.11.22: seq=0 ttl=63 time=0.133 ms
64 bytes from 10.101.11.22: seq=1 ttl=63 time=0.108 ms
64 bytes from 10.101.11.22: seq=2 ttl=63 time=0.097 ms
64 bytes from 10.101.11.22: seq=3 ttl=63 time=0.097 ms
statefulset更新策略
StatefulSet 的 .spec.updateStrategy 字段讓 你可以配置和禁用掉自動滾動更新 Pod 的容器、標簽、資源請求或限制、以及注解。 有兩個允許的值：
OnDelet- 當 StatefulSet 的
.spec.updateStrategy.type設置為OnDelete時， 它的控制器將不會自動更新 StatefulSet 中的 Pod。 用戶必須手動刪除 Pod 以便讓控制器創建新的 Pod，以此來對 StatefulSet 的.spec.template的變動作出反應。 RollingUpdateRollingUpdate更新策略對 StatefulSet 中的 Pod 執行自動的滾動更新。這是默認的更新策略。
當 StatefulSet 的 .spec.updateStrategy.type 被設置為 RollingUpdate 時， StatefulSet 控制器會刪除和重建 StatefulSet 中的每個 Pod。 它將按照與 Pod 終止相同的順序（從最大序號到最小序號）進行，每次更新一個 Pod。
Kubernetes 控制平面會等到被更新的 Pod 進入 Running 和 Ready 狀態，然后再更新其前身。 如果你設置了 .spec.minReadySeconds（查看最短就緒秒數）， 控制平面在 Pod 就緒后會額外等待一定的時間再執行下一步。
分區滾動更新(灰度發布)
通過聲明 .spec.updateStrategy.rollingUpdate.partition 的方式，RollingUpdate 更新策略可以實現分區。 如果聲明了一個分區，當 StatefulSet 的 .spec.template 被更新時， 所有序號大于等于該分區序號的 Pod 都會被更新。 所有序號小于該分區序號的 Pod 都不會被更新，并且，即使它們被刪除也會依據之前的版本進行重建。
[root@master ~]# kubectl edit sts web
apiVersion: apps/v1
kind: StatefulSet
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"web","namespace":"default"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"nginx"}},"serviceName":"nginx","template":{"metadata":{"labels":{"app":"nginx"}},"spec":{"containers":[{"image":"nginx:1.21.4","name":"nginx","ports":[{"containerPort":80,"name":"web"}]}]}}}}
creationTimestamp: "2022-07-26T07:51:51Z"
generation: 1
name: web
namespace: default
resourceVersion: "57225"
uid: 4b527fd0-6b5d-4bae-8312-d0cabb523ae3
spec:
podManagementPolicy: OrderedReady
replicas: 3
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
serviceName: nginx
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx:1.21.4
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
name: web
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
updateStrategy:
rollingUpdate:
partition: 0 比如當replicas數目為3時，把這里的0改為3的話，當更新版本時，只有web-2才會更新。
type: RollingUpdate
status:
collisionCount: 0
currentReplicas: 3
currentRevision: web-6cf5dbfdf7
observedGeneration: 1
readyReplicas: 3
replicas: 3
updateRevision: web-6cf5dbfdf7
updatedReplicas: 3
Horizontal Pod Autoscaling
應用的資源使用率通常有高峰和低谷的時候，如何肖峰填谷，提高集群的整體資源使用率，讓service中的pod數量自動調整呢？ 這就需要Horizontal Pod Autoscaling ，顧名思義，使pod水平縮放。
總結
- 上一篇： 【开发笔记】- yml中出现特殊字符启动
- 下一篇： 基于GPS定位和人脸识别的作业识别管理系