當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

K8S资源控制器

發布時間：2023/10/18 编程问答 53 如意码农

生活随笔收集整理的這篇文章主要介紹了 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 的變動作出反應。
RollingUpdate
RollingUpdate 更新策略對 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水平縮放。

總結

以上是生活随笔為你收集整理的K8S资源控制器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：【开发笔记】- yml中出现特殊字符启动
下一篇：基于GPS定位和人脸识别的作业识别管理系

编程问答

K8S资源控制器

什么是控制器

控制器的類型

ReplicationController和ReplicaSet

Deployment

例： 部署一個nginx應用

更新鏡像

回滾

Deployment更新策略

DaemonSet

job

cronjob

StateFulSet

statefulset更新策略

分區滾動更新(灰度發布)

Horizontal Pod Autoscaling

總結

例：部署一個nginx應用

Deployment更新策略　