5.k8s資源控制器

阿新 • • 發佈：2021-07-25

一、控制器說明

Pod 的分類

自主式Pod： Pod退出了，就退出了，此型別的Pod 不會被建立

控制器管理的Pod：在控制器的生命週期裡，始終要維持Pod 的副本數目

什麼是控制器

kubernetes中內建了很多controller（控制器），這些相當於一個狀態機，用來控制Pod的具體狀態和行為

控制器的型別
- ReplicationController和ReplicaSet
- Deployment : 有狀態服務
- DaemonSet：指定執行在那個node上
- StateFulSet ：有狀態服務
- Job/CronJob：定製指令碼
- Horizontal Pod Autoscaling ：類似阿里雲的AS彈性伸縮
ReplicationController和ReplicaSet

ReplicationController(RC)用來確保容器應用的副本數始終保持在使用者定義的副本數，即如果有容器異常退出，會自動建立新的Pod來替代；而如果異常多出來的容器也會自動回收；

在新版的Kubernetes中建議使用ReplicaSet來取代RelicationController， ReplicaSet跟ReplicationConller沒有本質的不同，只是名字不一樣，並且ReplicaSet支援集合式的selector；

Deployment

Deployment為Pod和ReplicaSet提供了一個宣告式定義（declarative）方法，用來替代以前的ReplicationController來方便的管理應用，典型的應用場景包括；
- 定義Deployment來建立Pod和ReplicaSet
- 滾動升級和回滾應用
- 擴容和縮容
- 暫停和繼續Deployment
指令式程式設計：它側重於如何實現程式，就像我們剛接觸程式設計的時候那樣，我們需要把程式的實現過程按照邏輯結果一步步寫下來

宣告式程式設計：它側重於定義想要什麼，然後告訴計算機/引擎，讓他們幫你去實現

宣告式程式設計（Deployment）： apply（優） create

命令式（rs） create （優） apply

DaemonSet

DaemonSet確保全部（或者一些）Node上執行一個Pod的副本，當有Node加入叢集時，也會為他們新增一個Pod ，當有Node從叢集移除時，這些Pod也會被回收。刪除DaemonSet將會刪除它建立的所有Pod

使用DaemonSet的一些典型用法
- 執行叢集儲存daemon ，例如在每個Node上執行glusterd，ceph
- 在每個Node上執行日誌收集daemon，例如fluentd， logstash
- 在每個Node上執行監控daemon，例如Prometheus Node Exporter，collectd，Datadog代理，New Relic 代理，或Ganglia gmond
Job

job負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束

CronJob 在特定時間迴圈建立Job

Cron Job管理基於時間的Job ，即：
- 在給定時間點執行一次
- 週期性地在給定時間點執行
使用前提條件：當前使用的Kubernetes叢集，版本>=1.8（對CronJob），對於先前版本的叢集，版本<1.8 ，啟動API Server時，通過傳遞選項--runtime-config=batch/v2alpha1=true可以開啟batch/v2alpha1

典型的用法如下所示：
- 在給定的時間點排程Job執行
- 建立週期性執行的Job，例如：資料備份，傳送郵件
StatefulSet

StatefulSet作為Controller為Pod提供唯一的標識，它可以保證部署和scale的順序

StatefulSet是為了解決有狀態服務的問題（對應Deployments和ReplicaSets是為無狀態服務而設計），其應用場景包括：
- 穩定的持久化儲存，即Pod重新排程後還是能訪問到相同的持久化資料，基於PVC
- 穩定的網路標識，即Pod重新排程後其PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現
- 有序部署，有序擴充套件，即Pod是有順序的，在部署或擴充套件的時候要依據定義的順序依次進行（即從0到N-1，在下一個Pod執行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現
- 有序收縮，有序刪除（即從N-1到0）
Horizontal Pod Autoscaling

應用的資源使用率通常都有高峰和低谷的時候，如果削峰填谷，提高叢集的整體資源利用率，讓service中的Pod個數自動調整呢？這就有賴於Horizontal Pod Autoscaling了，顧名思議，使Pod水平自動縮放。

二、RS、Deployment

2.1 RS與RC與Deployment關聯

RC(ReplicationController)主要的作用就是用來確保容器應用的副本數始終保持在使用者定義的副本數。即如果有容器異常退出，會自動建立新的Pod來替代；而如果異常多出來的容器也會自動回收。

Kubernetes官方建議使用RS（ReplicaSet）替代RC（ReplicationController）進行部署， RS跟RC沒有本質的不同，只是名字不一樣，並且RS支援集合式的selector

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginxv1
        image: hub.syuee.com/library/nginx:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

檢視標籤kubectl label pod --show-labels

RS與Deployment的關聯

Deployment

Deployment為Pod和ReplicaSet提供了一個宣告式定義（declarative）方法，用來替代以前的ReplicationController來方便的管理應用。典型的應用場景包括：

定義Deployment來建立Pod和ReplicaSet
滾動升級和回滾應用
擴容和縮容
暫停和繼續Deployment

部署一個簡單的nginx應用

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: hub.syuee.com/library/syuee-nginx:v2
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
## --record引數可以記錄命令， 我們可以很方便的檢視每次revision的變化

擴容

kubectl scale deployment nginx-deployment --replicas 10

如果叢集支援horizontal pod autoscaling的話

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

更新映象也比較簡單

kubectl set image deployment/nginx-deployment nginx=nginx:latest

回滾

kubectl rollout undo deployment/nginx-deployment

2.2 Deployment更新策略

Deployment可以保證在升級時只有一定數量的Pod是down的。預設的。它會確保至少有比期望的Pod數量少一個是up狀態（最多一個不可用）

Deployment同時也可以確保只創建出超過期望數量的一定數量的Pod。預設的，它會確保最多比期望的Pod數量多一個的Pod是UP的（最多1個surge）

未來的kubernetes版本中，將從1-1變成25%-25%

kubectl describe deployment

Rollover(多個rollout並行

假如您建立了一個有5個nginx:1.7.9 relica的Deployment，但是當還只有3個nginx:1.7.9的replica創建出來的時候您就開始更新含有5個nginx:1.9.1 replica的Deployment。在這種情況下： Deployment會立即殺掉已建立的3個nginx：1.7.9的Pod，並開始建立nginx:1.9.1的Pod。它不會等到所有的5個nginx:1.7.9的Pod都建立完成後才開始改變航道

2.3 回退Deployment

<!--只有Deployment的rollout被處罰就會建立revision。也就是說當且僅當Deployment的Pod template（如.spec.template>
被更改， 例如更新template中的label和容器映象時 ， 就會建立一個新的revision。 其他的更新， 比如擴容Deployment不會建立
revision-因此我們可以很方便的手動或者自動擴容。 這意味著當您回退到歷史revision時 ， 只有Ddeploument中的Pod template 
部分才會回退-->

kubectl set image deployment/nginx-deployment nginx-nginx:1.9.1
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用--revision引數指定某個歷史版本
kubectl rollout pause deployment/nginx-deployment #暫停deployment的更新

您可以用kubectl rollout status 命令檢視Deployment是否完成，如果rollout完成，kubectl rollout status將返回一個0值的Exit Code

kubectl rollout status deploument/nginx
waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
echo $?

清理Policy

您可以通設定.spec.revisonHistoryLimit項來指定deployment最多保留多少revision歷史記錄。預設的會保留所有的revision；如果將改項設定為0， Deployment就不允許回退了。

三、Daemonset

什麼是daemonset

DaemonSet確保全部（或者一些）Node上執行一個Pod的副本，當有Node加入叢集時，也會為他們新增一個Pod，當有Node從叢集移除時，這些Pod也會被回收，刪除DaemonSet將會刪除它建立的所有Pod

使用DaemonSet的一些典型用法：

執行在叢集儲存daemon，例如在每個Node上執行glusterd， ceph
在每個Node上執行日誌收集daemon，例如fluentd，logstash

在每個Node上執行監控daemon，例如Prometheus Node Exporter，collectd ，Datadog代理，New Relic代理，或Ganglia gmond

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: hub.syuee.com/library/syuee-nginx:v2

四、Job

Job負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束

特殊說明

spec.template格式同Pod
RestartPolicy僅支援Never或OnFailure
單個Pod時，預設Pod成功執行後Job即結束
.spec.completions標誌Job結束需要成功執行的Pod個數，預設為1
.spec.parallelism標誌並行執行的Pod的個數，預設為1
.spec.activeDeadlineSeconds標誌失敗Pod的重試最大時間，超過這個時間不會繼續重試

Example

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbigunm-bpi","-wle","print bpi(1000)"]
      restartPolicy: Never

5.k8s資源控制器

一、控制器說明

二、RS、Deployment

2.1 RS與RC與Deployment關聯

2.2 Deployment更新策略

2.3 回退Deployment

三、Daemonset

四、Job

5.k8s資源控制器

K8S--資源控制器&Pod詳解

Kubernetes K8S之資源控制器Job和CronJob詳解

3 k8s資源物件，控制器，儲存介紹

Kubernetes的資源控制器和Service(四)

5-kunernetes資源排程

k8s資源型別

04-K8S資源編排

《戴森球計劃》0.5倍資源電力裝置規劃

譯《遊戲分析導論攻略》| 2.5 潛在資源概覽（下）

k8s資源需求和限制, 以及pod驅逐策略

k8s資源deployment

K8S ingress控制器

4.k8s資源清單

k8s Pod控制器型別與部署例項

Longhorn，企業級雲原生容器分散式儲存 - K8S 資源配置示例

實驗5：開源控制器實踐——POX

5.K8s名稱空間

2021 SDN實驗5：開源控制器實踐——POX

#實驗5：開源控制器實踐——POX

5.k8s資源控制器

一、控制器說明

二、RS、Deployment

2.1 RS與RC與Deployment關聯

2.2 Deployment更新策略

2.3 回退Deployment

三、Daemonset

四、Job

相關推薦