Kubernetes的Controller進階(十二)

童話述說我的結局發表於2022-01-28
Controller

一、Controller

既然學習了Pod進階，對於管理Pod的Controller肯定也要進階一下，之前我們已經學習過的Controller有RC、RS和Deployment，除此之外還有嗎，如果感興趣的可以自己根據官網網址瞭解下

官網：https://kubernetes.io/docs/concepts/architecture/controller/

1.1、Job & CronJob

1.1.1 、Job

官網：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

 

 

 為啥要說這玩意呢，舉個例子來說吧，如果我有一個需求，用pod跑一個累加計算，當達到一定條件時我希望這個pod能結束；用之前Deployment的方式進行管理是做不到的，他只能做到無狀態的管理，對這種有狀態的管理就要通過我們接下來聊的jobs來處理;下面就實戰下說明；

（1）建立job.yaml檔案

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    metadata:
      name: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

（2）啟動指令碼命令

kubectl apply -f job.yaml

（3）用下面命令檢視會發現任務完成了

kubectl get pods | grep job

（4）jobs的狀態檢視 

kubectl describe jobs/pi

(5) 檢視日誌

kubectl logs pod-name

總結：

  • 非並行Job：
    • 通常只執行一個Pod，Pod成功結束Job就退出。
  • 固定完成次數的並行Job:
    • 併發執行指定數量的Pod，直到指定數量的Pod成功，Job結束。
  • 帶有工作佇列的並行Job:
    • 使用者可以指定並行的Pod數量，當任何Pod成功結束後，不會再建立新的Pod
    • 一旦有一個Pod成功結束，並且所有的Pods都結束了，該Job就成功結束。
    • 一旦有一個Pod成功結束，其他Pods都會準備退出。

1.1.2 、CronJob

官網：https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

 

 

 jobs是任務執行一次就結束了，而cronJob是基於時間進行任務的定時管理。在特定的時間點執行任務，反覆在指定的時間點執行任務：比如定時進行資料庫備份，定時傳送電子郵件等等。

1.2、StatefulSet

官網：https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

 

 

 之前接觸的Pod的管理物件比如RC、Deployment、DaemonSet和Job都是面向無狀態的服務，但是現實中有很多服務是有狀態的，比如MySQL叢集、MongoDB叢集、ZK叢集等，它們都有以下共同的特點：

  • 每個節點都有固定的ID，通過該ID，叢集中的成員可以互相發現並且通訊
  • 叢集的規模是比較固定的，叢集規模不能隨意變動
  • 叢集裡的每個節點都是有狀態的，通常會持久化資料到永久儲存中
  • 如果磁碟損壞，則叢集裡的某個節點無法正常執行，叢集功能受損

而之前的RC/Deployment沒辦法滿足要求，所以從Kubernetes v1.4版本就引入了PetSet資源物件，在v1.5版本時更名為StatefulSet。從本質上說，StatefulSet可以看作是Deployment/RC物件的特殊變種

  • StatefulSet裡的每個Pod都有穩定、唯一的網路標識，可以用來發現叢集內其他的成員
  • Pod的啟動順序是受控的，操作第n個Pod時，前n-1個Pod已經是執行且準備好的狀態
  • StatefulSet裡的Pod採用穩定的持久化儲存卷，通過PV/PVC來實現，刪除Pod時預設不會刪除與StatefulSet相關的儲存卷
  • StatefulSet需要與Headless Service配合使用

實戰案例

（1）建立nginx-st.yaml檔案

# 定義Service
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
# 定義StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx 
  serviceName: "nginx"  
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web

（2）執行指令碼檔案

kubectl apply nginx-st.yaml

（3）檢視資源

kubectl get statefulset

1.3、DaemonSet

官網：https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

 

 根據官網可以知道這玩意也是用來管理pod的，DaemonSet應用場景：

  • 執行叢集儲存 daemon，例如在每個節點上執行 `glusterd`、`ceph`。
  • 在每個節點上執行日誌收集 daemon，例如`fluentd`、`logstash`。
  • 在每個節點上執行監控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理，或 Ganglia `gmond`。

1.4、Horizontal Pod Autoscaler

pod如果能根據併發量和cpu效能進行動態的擴縮容，那麼對宿主機的效能是一個大的提升。下面這玩意就是實現這種思想的

官網：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

（1）配置nginx-deployment.yaml

 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: nginx-deployment
 labels:
  app: nginx
 spec:
 replicas: 3
 selector:
  matchLabels:
    app: nginx
 template:
  metadata:
    labels:
      app: nginx
  spec:
    containers:
       - name: nginx
      image: nginx
      ports:
         - containerPort: 80

（2）執行指令碼建立

kubectl apply -f nginx-deployment.yaml

（3）建立hpa，使nginx pod的數量介於2和10之間，CPU使用率維持在50％

kubectl autoscale deployment nginx-deployment --min=2 --max=10 --cpu-percent=50

（4）檢視所有建立的資源

kubectl get pods
kubectl get deploy
kubectl get hpa

（5）修改replicas值為1或者11 

kubectl edit deployment nginx-deployment.yaml

可以發現最終最小還是2，最大還是10

kubectl edit deployment nginx-deployment

(6)再次理解什麼是hpa

Horizontal Pod Autoscaling可以根據CPU使用率或應用自定義metrics自動擴充套件Pod數量（支援replication controller、deployment和replica set）

  • 控制管理器每隔30s查詢metrics的資源使用情況
  • 通過kubectl建立一個horizontalPodAutoscaler物件，並儲存到etcd中
  • APIServer:負責接受建立hpa物件，然後存入etcd

相關文章