k8s之Pod控制器

一、Pod控制器

• Pod控制器，又稱之為工作負(fù)載（workload），是用于實現(xiàn)管理pod的中間層，確保pod資源符合預(yù)期的狀態(tài)，pod的資源出現(xiàn)故障時，會嘗試進(jìn)行重啟，當(dāng)根據(jù)重啟策略無效，則會重新新建pod的資源。

1、pod控制器類型

1.1 ReplicaSet

• 代用戶創(chuàng)建指定數(shù)量的pod副本，確保pod副本數(shù)量符合預(yù)期狀態(tài)，并且支持滾動式自動擴(kuò)容和縮容功能。

ReplicaSet主要三個組件組成

• 用戶期望的pod副本數(shù)量
• 標(biāo)簽選擇器，判斷哪個pod歸自己管理
• 當(dāng)現(xiàn)存的pod數(shù)量不足，會根據(jù)pod資源模板進(jìn)行新建

幫助用戶管理無狀態(tài)的pod資源，精確反應(yīng)用戶定義的目標(biāo)數(shù)量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

1.2 Deployment

• Deployment是最常用的Pod控制器之一，建立在ReplicaSet之上，它用于部署無狀態(tài)應(yīng)用程序。Deployment定義了Pod的期望副本數(shù)，并通過滾動更新和回滾機(jī)制來管理Pod的升級和降級。
• 工作在ReplicaSet之上，用于管理無狀態(tài)應(yīng)用，目前來說最好的控制器。支持滾動更新和回滾功能，還提供聲明式配置。

1.3 DaemonSet

• 用于確保集群中的每一個節(jié)點運(yùn)行一個pod副本，通常用于實現(xiàn)系統(tǒng)級后臺任務(wù)。比如ELK服務(wù)。

1.4 StatefulSet

• 部署有狀態(tài)的應(yīng)用，每個pod的名稱是唯一不變的，每個pod擁有自己專屬的持久化的存儲（pv/pvc）。

1.5 Job

• Job用于運(yùn)行一次性任務(wù)，如批處理作業(yè)或短生命周期的應(yīng)用程序。Job會創(chuàng)建Pod來執(zhí)行任務(wù)，并在任務(wù)完成后刪除Pod。
• 只要完成就立即退出，不需要重啟或重建。

1.6 Cronjob

• 周期性任務(wù)控制，不需要持續(xù)后臺運(yùn)行

2、Pod與控制器之間的關(guān)系

• controllers：在集群上管理和運(yùn)行容器的 pod 對象， pod 通過 label-selector 相關(guān)聯(lián)。
• Pod 通過控制器實現(xiàn)應(yīng)用的運(yùn)維，如伸縮，升級等。

二、使用POD控制器

1、Deployment

• 部署無狀態(tài)應(yīng)用
• 管理Pod和ReplicaSet
• 具有上線部署、副本設(shè)定、滾動升級、回滾等
• 提供聲明式更新，例如只更新一個新的image
• 應(yīng)用場景：Web服務(wù)、微服務(wù)

1.1 創(chuàng)建控制器

kubectl create deployment deploy --image=nginx:1.18 --port=80 --replicas=1 --dry-run=client -oyaml > deploy.yaml
#生成yaml配置文件模板

#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
#指定API版本
kind: Deployment
#指定創(chuàng)建資源類型為Deployment
metadata:
#定義資源的元數(shù)據(jù)信息
  name: nginx-deploy
  #指定資源的名稱
  labels:
  #設(shè)置標(biāo)簽
    app: nginx
    #標(biāo)簽以鍵值表示，標(biāo)簽鍵為app,標(biāo)簽值為nginx
spec:
#定義資源的規(guī)格
  replicas: 1
  #指定創(chuàng)建pod數(shù)量為1個
  selector:
  #選擇由Deployment管理的Pod的標(biāo)簽選擇器
    matchLabels:
    #指定用于匹配的標(biāo)簽
      app: nginx
      #設(shè)置標(biāo)簽需要與模板標(biāo)簽一致
  template:
  #創(chuàng)建pod的模板，deployment管理的pod實例，都由此模板定義
    metadata:
    #模板的元數(shù)據(jù)信息
      labels:
      #定義pod的標(biāo)簽
        app: nginx
        #此處需要與deployment管理pod的標(biāo)簽選擇器一致
    spec:
    #pod的規(guī)格信息
      containers:
      #定義pod中運(yùn)行的容器列表
      - name: nginx
      #指定容器名稱
        image: nginx:1.18.0
        #指定鏡像版本
        ports:
        #定義端口
        - containerPort: 80
        #定義容器內(nèi)部的監(jiān)聽端口

kubectl apply -f deploy.yaml
#創(chuàng)建資源

kubectl get pods,deploy,rs
#查看pod資源信息

1.2 更新版本

curl 10.244.2.116 -I
#查看版本信息（nginx版本信息是1.80版本）

#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.20
      #修改版本號
        name: nginx
        ports:
        - containerPort: 80

kubectl apply -f deploy.yaml
#重新創(chuàng)建資源

1.3 查看更新的版本號

kubectl get pod -w
#另開一個終端，追蹤查看pod更新過程

curl -I 10.244.1.104
#查看版本信息（nginx版本更新為1.20版本）

2、SatefulSet

StatefulSet 是 Kubernetes 中的一個資源控制器，它用于管理有狀態(tài)的應(yīng)用。與 Deployment 和 ReplicaSet 這樣的無狀態(tài)工作負(fù)載不同，StatefulSet 為每個 Pod 提供了一個穩(wěn)定的、唯一的標(biāo)識符，并且能夠保證 Pod 的部署順序和終止順序。

• 穩(wěn)定的標(biāo)識符：每個Pod都有一個唯一的、持久的標(biāo)識符，這個標(biāo)識符在 Pod 的整個生命周期中都是不變的。這使得即使 Pod 被重新調(diào)度，其標(biāo)識符也會保持不變。這一功能常?；贖eadless(無頭模式，即沒有Cluster IP的Service)實現(xiàn)
• 有序的部署和擴(kuò)展：Pod 是按照特定的順序進(jìn)行創(chuàng)建和擴(kuò)展（0到N-1）的。這允許應(yīng)用程序在部署時按照特定的順序進(jìn)行初始化。
• 有序的終止和縮容：當(dāng)縮容或刪除 StatefulSet 時，Pod 會按照相反的順序（N-1到0）進(jìn)行終止。這允許應(yīng)用程序在關(guān)閉時按照特定的順序進(jìn)行清理。
• 穩(wěn)定的持久化存儲：StatefulSet 常常與 PersistentVolumeClaims（PVCs）一起使用，以提供穩(wěn)定的存儲。即使 Pod 被重新調(diào)度，其存儲卷也會被保留并重新附加到新的 Pod 上。
• 常見的應(yīng)用場景：數(shù)據(jù)庫

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
#官方文檔

2.1 StatefulSet的三個關(guān)鍵組成部分以及其作用

StatefulSet 的設(shè)計是為了滿足有狀態(tài)應(yīng)用的需求，這些應(yīng)用通常需要持久化存儲和穩(wěn)定的網(wǎng)絡(luò)標(biāo)識。

2.1.1 Headless Service（無頭服務(wù)）

• 目的：Headless Service 用于為 StatefulSet 中的每個 Pod 提供一個穩(wěn)定的 DNS 名稱。這樣，即使 Pod 被重新調(diào)度到其他節(jié)點，它的 DNS 名稱也不會改變，從而保證了網(wǎng)絡(luò)標(biāo)識的穩(wěn)定性。
• 實現(xiàn)：Headless Service 不分配 Cluster IP，而是直接將 DNS 請求解析到對應(yīng)的 Pod IP。這樣，每個 Pod 都有一個基于 StatefulSet 名稱和 Pod 序號的 DNS 子域，例如 web-0.nginx.default.svc.cluster.local。

2.1.2 VolumeClaimTemplates

• 目的：VolumeClaimTemplates 用于為每個 Pod 提供獨立的持久化存儲。這樣，每個 Pod 都有自己的存儲空間，即使在 Pod 重新調(diào)度后，也能保持?jǐn)?shù)據(jù)的連續(xù)性和一致性。
• 實現(xiàn)：在 StatefulSet 的定義中，可以包含一個或多個 VolumeClaimTemplates。當(dāng) StatefulSet 創(chuàng)建 Pod 時，會為每個 Pod 創(chuàng)建相應(yīng)的 PersistentVolumeClaim (PVC)。這些 PVC 會請求與 StatefulSet 關(guān)聯(lián)的 PersistentVolume (PV)，從而為每個 Pod 提供專用的存儲卷。

2.1.3 StatefulSet 控制器

• 目的：StatefulSet 控制器負(fù)責(zé)管理 Pod 的生命周期，確保 Pod 的數(shù)量符合用戶的期望，并且按照順序進(jìn)行部署、擴(kuò)展和收縮。
• 實現(xiàn)：StatefulSet 控制器會監(jiān)控 Pod 的狀態(tài)，確保每個 Pod 都按照定義的順序運(yùn)行。在進(jìn)行滾動更新時，它會按照順序逐個更新 Pod，確保在更新下一個 Pod 之前，所有先前的 Pod 都已經(jīng)就緒。同樣，在刪除 Pod 時，也會按照相反的順序進(jìn)行，以確保服務(wù)的平滑過渡。

總結(jié)

• Headless Service（無頭服務(wù)）：用于為Pod資源標(biāo)識符生成可解析的DNS記錄
• VolumeClaimTemplates（存儲卷申請模板）：基于靜態(tài)或動態(tài)PV供給方式為Pod資源提供專有的固定存儲
• StatefulSet：用于管控Pod資源

這三個組件共同工作，使得 StatefulSet 能夠為有狀態(tài)應(yīng)用提供所需的穩(wěn)定性和可靠性。Headless Service 解決了網(wǎng)絡(luò)標(biāo)識的穩(wěn)定性問題，VolumeClaimTemplates 解決了持久化存儲的需求，而 StatefulSet 控制器則確保了 Pod 的有序管理和更新。這種設(shè)計使得 StatefulSet 成為部署和管理有狀態(tài)應(yīng)用的理想選擇，如數(shù)據(jù)庫、消息隊列等。

為什么要有headless？

• 在deployment中，每一個pod是沒有名稱，是隨機(jī)字符串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當(dāng)節(jié)點掛了，重建之后的標(biāo)識符是不變的，每一個節(jié)點的節(jié)點名稱是不能改變的。pod名稱是作為pod識別的唯一標(biāo)識符，必須保證其標(biāo)識符的穩(wěn)定并且唯一。
• 為了實現(xiàn)標(biāo)識符的穩(wěn)定，這時候就需要一個headless service 解析直達(dá)到pod，還需要給pod配置一個唯一的名稱。

為什么要有volumeClainTemplate？

• 大部分有狀態(tài)副本集都會用到持久存儲，比如分布式系統(tǒng)來說，由于數(shù)據(jù)是不一樣的，每個節(jié)點都需要自己專用的存儲節(jié)點。而在 deployment中pod模板中創(chuàng)建的存儲卷是一個共享的存儲卷，多個pod使用同一個存儲卷，而statefulset定義中的每一個pod都不能使用同一個存儲卷，由此基于pod模板創(chuàng)建pod是不適應(yīng)的，這就需要引入volumeClainTemplate，當(dāng)在使用statefulset創(chuàng)建pod時，會自動生成一個PVC，從而請求綁定一個PV，從而有自己專用的存儲卷。

服務(wù)發(fā)現(xiàn)：就是應(yīng)用服務(wù)之間相互定位的過程。

應(yīng)用場景：

• 動態(tài)性強(qiáng)：Pod會飄到別的node節(jié)點
• 更新發(fā)布頻繁：互聯(lián)網(wǎng)思維小步快跑，先實現(xiàn)再優(yōu)化，老板永遠(yuǎn)是先上線再慢慢優(yōu)化，先把idea變成產(chǎn)品掙到錢然后再慢慢一點一點優(yōu)化
• 支持自動伸縮：一來大促，肯定是要擴(kuò)容多個副本

K8S里服務(wù)發(fā)現(xiàn)的方式—DNS，使K8S集群能夠自動關(guān)聯(lián)Service資源的“名稱”和“CLUSTER-IP”，從而達(dá)到服務(wù)被集群自動發(fā)現(xiàn)的目的。

實現(xiàn)K8S里DNS功能的插件

• skyDNS：Kubernetes 1.3之前的版本
• kubeDNS：Kubernetes 1.3至Kubernetes 1.11
• CoreDNS：Kubernetes 1.11開始至今

2.2 創(chuàng)建控制器

• 先清空之前創(chuàng)建的pod資源

• 驗證dns是否可以使用

kubectl run busybox --image=busybox:1.28 -- sleep 36000
#創(chuàng)建一個busybox的pod，該容器提供一些基本的命令，主要用于測試環(huán)境

kubectl get pod busybox
#查看pod資源

kubectl exec -it busybox sh
#進(jìn)入容器

/ # nslookup kubernetes
#測試svc能否正常解析，可以使用kubectl get svc查看有哪些svc（解析正常，解析kubernetes的地址為10.96.0.1）

kubectl get svc
#查看svc資源信息

2.2.1 創(chuàng)建svc資源

#編輯yaml配置文件
vim service.yaml
apiVersion: v1
#指定API版本
kind: Service
#創(chuàng)建資源類型為Service
metadata:
  name: headless-svc
  #指定service名稱
  labels:
    app: headless-svc
    #設(shè)置service標(biāo)簽
spec:
  ports:
  - port: 80
  #service端口
    name: web
    #端口名稱
    targetPort: 80
    #指定流量轉(zhuǎn)發(fā)的目標(biāo)端口，與pod暴露的端口一致
  clusterIP: None
  #將clusterIP地址的值設(shè)置為None，表示無IP地址，即無頭模式
  selector:
  #選擇管理的標(biāo)簽
    app: state
    #此標(biāo)簽需要與StatefulSet控制器管理的pod模板中定義的標(biāo)簽一致
  type: ClusterIP
  #設(shè)置類型為ClusterIP，此為默認(rèn)設(shè)置，可以省略

kubectl apply -f service.yaml
#創(chuàng)建資源

kubectl get svc headless-svc
#查看資源信息

2.2.2 創(chuàng)建StatefulSet

#編輯yaml配置文件
vim statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
#創(chuàng)建資源類型為StatefulSet
metadata:
  name: state
  #指定資源名稱
spec:
  serviceName: headless-svc
  #指定需要綁定的service名稱
  replicas: 3
  #創(chuàng)建pod數(shù)量為三個
  selector:
  #標(biāo)簽選擇器，指定StatefulSet要管理哪些pod
    matchLabels:
    #指定標(biāo)簽名稱
      app: state
      #必須與service中selector定義的標(biāo)簽一致。pod含有此標(biāo)簽的，都會去管理
  template:
  #指定pod創(chuàng)建模板
    metadata:
      labels:
        app: state
        #設(shè)置pod標(biāo)簽，與上面標(biāo)簽選擇器相同，StatefulSet才會管理
    spec:
      containers:
      #定義pod中運(yùn)行的容器
      - name: nginx-pod
      #應(yīng)當(dāng)設(shè)置有狀態(tài)的服務(wù)，在此以nginx為例，官方文檔有MySQL示例
        image: nginx:1.18.0
        #定義鏡像
        ports:
        - containerPort: 80
        #定義容器監(jiān)聽端口
          name: web
          #端口名稱
        volumeMounts:
        #定義將存儲卷卷掛載到指定目錄
        - name: html
        #指定存儲卷名稱
          mountPath: /usr/share/nginx/html
          #掛載到此目錄，此目錄為nginx服務(wù)的站點目錄
  volumeClaimTemplates:
  #PVC的請求模板
  - metadata:
      name: html
      #定義PVC的名稱
      annotations:
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
        #用于指定存儲類的注解。該存儲類定義了用于動態(tài)卷供應(yīng)的后端存儲類型
    spec:
      accessModes: ["ReadWriteOnce"]
      #指定訪問模式為RWO
      resources:
        requests:
          storage: 2Gi
          #指定存儲卷的使用大小

kubectl apply -f statefulset.yaml 
#創(chuàng)建資源
長度、
kubectl get statefulsets.apps state
#查看資源信息

kubectl get pod -owide -w
#查看pod資源信息
#它會按照0到N-1的順序去指定pod名稱，一定建立，指定pod生命周期結(jié)束，否則IP地址改變，它的名稱也不會改變

kubectl get pv,pvc
#查看pv/pvc資源信息

• 在nfs服務(wù)器上自定義web頁面
• nfs服務(wù)器

cd /nfs/k8s
#切換目錄

echo "this is state-0" > default-html-state-0-pvc-5d4f3a8c-f5da-4aae-a244-1cfef9f328ec/index.html
#編輯state-0訪問頁面

echo "this is state-1" > default-html-state-1-pvc-23363402-a920-471e-9a1b-da43af18620d/index.html
#編輯state-1訪問頁面

echo "this is state-2" > default-html-state-2-pvc-754e992e-4573-408d-b78d-687f5dfd285f/index.html
#編輯state-2訪問頁面

• 訪問驗證

由于沒有ClusterIP地址，想要通過IP地址訪問，只能在k8s集群中直接訪問podIP

curl 10.244.2.120
curl 10.244.2.121
curl 10.244.1.109
#訪問驗證

2.2.3 使用service訪問

• 創(chuàng)建的svc是可以進(jìn)行解析的

kubectl exec -it busybox sh
#進(jìn)入容器

/ # nslookup headless-svc
#查看dns解析
#service會通過endpoint關(guān)聯(lián)到后端的pod

• 訪問驗證

由于pod的IP地址是k8s集群內(nèi)部的IP地址，且并沒有clusterIP去綁定podIP，只有域名管理，宿主機(jī)的DNS解析，無法解析k8s集群內(nèi)部的域名與地址，所以使用宿主機(jī)無法訪問pod。只能通過創(chuàng)建pod，在pod中進(jìn)行訪問

kubectl run centos --image=centos:7 -- sleep 36000
#創(chuàng)建一個centos容器，訪問service

kubectl exec -it centos sh
#進(jìn)入容器

curl headless-svc
#訪問驗證

2.3 刪除與創(chuàng)建

• 當(dāng)pod刪除時，會按照N-1到0的順序，倒序刪除

kubectl delete -f statefulset.yaml
#刪除pod資源

kubectl get pod -w
#另開一個終端，跟蹤查看pod資源信息

• 重新創(chuàng)建的時候，數(shù)據(jù)會持久化 ，而且創(chuàng)建的順序還是按照0到N-1的順序創(chuàng)建

kubectl apply -f statefulset.yaml 
#重新創(chuàng)建資源

kubectl exec -it centos sh
#進(jìn)入容器

curl headless-svc
#訪問驗證（重新創(chuàng)建之后再次訪問，數(shù)據(jù)不會丟失）

• 重新創(chuàng)建之后再次訪問，數(shù)據(jù)不會丟失

kubectl exec -it busybox sh
#進(jìn)入測試容器

/ # nslookup headless-svc
#測試svc解析，后端ip地址發(fā)生變化
#不論后端的IP地址如何變化，只通過DNS來解析service，從而綁定后端的IP地址，得到數(shù)據(jù)

2.4 deployment與statefulset的區(qū)別

2.4.1 應(yīng)用場景

• Deployment：主要用于部署無狀態(tài)服務(wù)，即服務(wù)實例之間可以相互替換且不需要保留特定的網(wǎng)絡(luò)標(biāo)識或存儲數(shù)據(jù)。它適用于那些不需要關(guān)心Pod具體身份且可任意替換的彈性 服務(wù)。

• StatefulSet：適用于部署有狀態(tài)的服務(wù)，比如數(shù)據(jù)庫集群、消息隊列等。這些服務(wù)需要穩(wěn)定的持久化存儲和唯一、有序的網(wǎng)絡(luò)標(biāo)識。StatefulSet為Pod分配的網(wǎng)絡(luò)標(biāo)識符和存儲都是穩(wěn)定的，使得應(yīng)用能夠維持跨重啟或再調(diào)度的持久狀態(tài)。

2.4.2 Pod管理

• Deployment：通過ReplicaSet確保指定數(shù)量的Pod副本始終運(yùn)行，提供水平擴(kuò)展和滾動更新能力。Pod由Deployment創(chuàng)建時，雖然可以自定義名稱，但通常由系統(tǒng)生成，并在重建或擴(kuò)展時可能會發(fā)生變化。

• StatefulSet：Pods在創(chuàng)建、更新和刪除時按照順序進(jìn)行，以滿足那些依賴于嚴(yán)格順序啟動或停止的應(yīng)用場景需求。每個Pod都有一個固定的、唯一的網(wǎng)絡(luò)標(biāo)識符，并且其持久卷聲明(PVC)會綁定到持久化的存儲，即使Pod被刪除后重新創(chuàng)建，存儲的數(shù)據(jù)也會保留。

2.4.3 存儲與網(wǎng)絡(luò)

• Deployment：通常不直接管理Pod的存儲和網(wǎng)絡(luò)，而是依賴于其他Kubernetes資源（如PersistentVolume和Service）來實現(xiàn)這些功能。

• StatefulSet：為Pod提供穩(wěn)定的存儲和網(wǎng)絡(luò)標(biāo)識，確保有狀態(tài)應(yīng)用能夠正常運(yùn)行。StatefulSet通常與Headless Service和volumeClaimTemplate一起使用，以提供可解析的DNS資源記錄和專有且固定的存儲。

2.4.4 升級與回滾

• Deployment：支持多種升級策略，如滾動更新和回滾，確保服務(wù)在整個升級過程中具有高可用性。通過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態(tài)，并逐步替換舊的Pod。

• StatefulSet：也支持有序而自動的滾動更新，但由于涉及到有狀態(tài)應(yīng)用，更新過程可能更加復(fù)雜和嚴(yán)格。同時，StatefulSet也支持回滾到之前的版本。

2.4.5 擴(kuò)展性

• Deployment：可以根據(jù)系統(tǒng)負(fù)載進(jìn)行水平擴(kuò)展和縮容，通過調(diào)整ReplicaSet的副本數(shù)來實現(xiàn)。

• StatefulSet：雖然也支持?jǐn)U展和縮容操作，但由于涉及到有狀態(tài)應(yīng)用和數(shù)據(jù)一致性等問題，擴(kuò)展性可能相對較弱。

3、DaemonSet

• DaemonSet 是 Kubernetes 中的一種工作負(fù)載控制器，它確保在集群中的所有（或指定的）節(jié)點上運(yùn)行一個 Pod 的副本。這使得 DaemonSet 成為運(yùn)行集群級服務(wù)的理想選擇，如日志收集、監(jiān)控代理、存儲守護(hù)進(jìn)程等。

3.1 關(guān)鍵特性

• 節(jié)點覆蓋：DaemonSet 確保在集群中的每個節(jié)點上都有一個 Pod 副本運(yùn)行，或者根據(jù)需要在特定節(jié)點上運(yùn)行。
• 自動管理：當(dāng)新節(jié)點加入集群時，DaemonSet 會自動在這些節(jié)點上創(chuàng)建 Pod。當(dāng)節(jié)點被移除時，相應(yīng)的 Pod 也會被清理。
• 刪除行為：刪除 DaemonSet 會刪除它創(chuàng)建的所有 Pod，這有助于維護(hù)集群的整潔。

3.2 應(yīng)用場景

• 集群存儲守護(hù)進(jìn)程：在每個節(jié)點上運(yùn)行如 GlusterFS 的 glusterd 或 Ceph 的守護(hù)進(jìn)程，以提供分布式存儲服務(wù)。
• 日志收集：部署如 Fluentd、Logstash 等日志收集代理，以便在每個節(jié)點上收集日志并將其發(fā)送到中央日志存儲。
• 監(jiān)控代理：在每個節(jié)點上運(yùn)行監(jiān)控代理，如 Prometheus 的 Node Exporter、Collectd、Datadog 代理、New Relic 代理或 Ganglia 的 gmond，以收集節(jié)點的監(jiān)控數(shù)據(jù)。
• 網(wǎng)絡(luò)插件：在每個節(jié)點上運(yùn)行如Calico、Cilium或Flannel等

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
#官方案例（監(jiān)控）

3.3 創(chuàng)建控制器

#編輯yaml配置文件
vim daemonset.yaml  
apiVersion: apps/v1
kind: DaemonSet
#創(chuàng)建資源類型為DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18.0
        ports:
        - containerPort: 80

kubectl apply -f daemonset.yaml
#創(chuàng)建資源

kubectl get pod -owide
#查看詳細(xì)信息（DaemonSet會在每個node節(jié)點都創(chuàng)建一個Pod）

4、Job

• Job控制器是Kubernetes中的一個核心組件，主要用于在集群中運(yùn)行一次性或批處理任務(wù)。Job確保在集群中運(yùn)行獨立的任務(wù)，并在任務(wù)成功完成后自動終止，不會重啟。

4.1 主要特點

• 任務(wù)執(zhí)行：Job控制器主要負(fù)責(zé)批量處理短暫的一次性任務(wù)。當(dāng)任務(wù)執(zhí)行完畢后，Job會自動將Pod的可用數(shù)設(shè)置為0，并將Pod的狀態(tài)置為Complete。
• 任務(wù)記錄：當(dāng)Job創(chuàng)建的Pod成功執(zhí)行完任務(wù)后，Job會記錄成功結(jié)束的Pod數(shù)量。當(dāng)成功結(jié)束的Pod數(shù)量達(dá)到指定的數(shù)量時，Job完成執(zhí)行。
• 任務(wù)重試：Job支持定義任務(wù)的重試策略，通過backoffLimit字段指定Job失敗后進(jìn)行重試的次數(shù)。
• 并行任務(wù)：Job允許定義多個并行執(zhí)行的任務(wù)，通過parallelism字段指定在任一時刻應(yīng)該并發(fā)運(yùn)行的Pod數(shù)量

4.2 應(yīng)用場景

• Job常用于運(yùn)行那些僅需要執(zhí)行一次的任務(wù)

批處理作業(yè)

• Kubernetes Job主要被用于執(zhí)行一次性批處理作業(yè)，如每日數(shù)據(jù)分析、事務(wù)處理等。

數(shù)據(jù)遷移和清理

• Job可以用來定時遷移大量數(shù)據(jù)，以及維護(hù)數(shù)據(jù)庫

后臺任務(wù)

• Job可以用來執(zhí)行后臺任務(wù)，如計算任務(wù)、日志采集等

日志打包和壓縮

• 例如按時間段打包日志文件、將多個日志文件壓縮成一個文件等。

備份和恢復(fù)操作

• 例如備份數(shù)據(jù)庫、配置文件等，并將其存儲到云存儲服務(wù)中以便后續(xù)恢復(fù)

其它應(yīng)用場景

• kube-bench掃描、離線數(shù)據(jù)處理，視頻解碼等業(yè)務(wù)

4.3 創(chuàng)建控制器

#編輯yaml配置文件
vim job.yaml
apiVersion: batch/v1
#Batch API的第一個穩(wěn)定版
kind: Job
#指定創(chuàng)建的資源類型是Job
metadata:
  name: job
  #資源名稱
spec:
  template:
    spec:
    #spec.template.spec 定義了 Pod 的規(guī)格，包括容器的名稱、鏡像和執(zhí)行的命令
      containers:
      - name: busybox
      #容器名稱
        image: busybox:1.28
        #鏡像名稱
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
        #perl解釋器，-Mbignum=bpi模塊中的子進(jìn)程，使用計算功能，計算結(jié)果輸出圓周率2000位的結(jié)果
      restartPolicy: Never
      #表示 Pod 失敗后不會重啟。
  backoffLimit: 4
  #表示 Job 在失敗后最多重試 4 次

kubectl apply -f job.yaml 
#創(chuàng)建資源

kubectl get job
#查看job資源信息

kubectl get pod -w
#追蹤查看pod資源信息

4.4 清除job資源

kubectl get job
#查看job資源信息

kubectl delete -f job.yaml 
#刪除job資源

kubectl get job
#查看job資源信息

#編輯yaml配置文件
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2
  
kubectl apply -f job-limit.yaml
#創(chuàng)建資源
 
kubectl get job,pods
#查看資源信息
 
kubectl get pod -w
#追蹤查看資源信息

5、CronJob

• 在Kubernetes中，CronJob控制器用于運(yùn)行定時任務(wù)，例如備份、生成報告等。這些任務(wù)在指定的時間周期上自動執(zhí)行。一個 CronJob 對象就像 linux 系統(tǒng)上的 crontab（cron table）文件中的一行，使用Cron格式進(jìn)行編寫， 并周期性地在給定的調(diào)度時間執(zhí)行Job。它在Kubernetes集群上運(yùn)行的，可以管理多個Pod。

5.1 創(chuàng)建控制器

• 創(chuàng)建 CronJob 配置文件 (cronjob.yaml) 每分鐘打印hello

#編輯yaml配置文件
vim cronjob.yaml
apiVersion: batch/v1beta1
#指定 Kubernetes API 的版本
kind: CronJob
#指定資源類型為 CronJob
metadata:
#包含 CronJob 的名稱
  name: hello
spec:
#包含 CronJob 的規(guī)格
  schedule: "*/1 * * * *"
  #使用 Cron 表達(dá)式定義任務(wù)的執(zhí)行時間表。在這個例子中，"*/1 * * * *" 表示每分鐘執(zhí)行一次。
  jobTemplate:
  #定義了 Job 模板，它包含了執(zhí)行任務(wù)的 Pod 規(guī)格
    spec:
      template:
        spec:
          containers:
          #定義了容器的名稱、鏡像和其他參數(shù)
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            #執(zhí)行的命令，這里使用 /bin/sh 打印當(dāng)前日期和 "Hello" 消息
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
          #設(shè)置為 OnFailure，表示只在容器失敗時重啟
 
 
kubectl apply -f cronjob.yaml 
#創(chuàng)建資源
 
kubectl get cronjob
#查看cronjob資源
 
kubectl get pods
#查看pod資源
 
kubectl logs hello-1717340820-s8n4j
#我們查看了 hello-1717225740-8nlx7 Pod 的日志，可以看到打印的日期和 "Hello" 消息。

--------------------------------------------------------------------------------------------
#解決日志查看權(quán)限問題
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

#如果在查看日志時遇到權(quán)限問題，可以通過創(chuàng)建一個 clusterrolebinding 來授予 system:anonymous 用戶 cluster-admin 權(quán)限。這通常不推薦，因為它會降低集群的安全性。在生產(chǎn)環(huán)境中，應(yīng)該使用更細(xì)粒度的權(quán)限控制。
-------------------------------------------------------------------------------------------

Pod控制器

• Deployment：部署無狀態(tài)應(yīng)用的管理RS和Pod，創(chuàng)建Pod，主要是維護(hù)Pod副本數(shù)量與期望狀態(tài)相同，創(chuàng)建和刪除Pod時并行執(zhí)行，升級時想創(chuàng)建一部分，再刪除一部分
• StatefulSet：部署有狀態(tài)的應(yīng)用，每個Pod的唯一（名稱）且不變的，每個Pod擁有自己專屬的持久化的存儲（PVC和PV）在K8S集群內(nèi)部可以通過（Pod_name）.（Service_name）.{namespace}.svc.cluster.local 解析出Pod的IP（基于headless service 和CoreDNS）
• ? 創(chuàng)建和刪除Pod時有順序的（串行執(zhí)行的），升級時串行執(zhí)行的，會刪除舊的Pod，再創(chuàng)建和新Pod刪除和升級時逆序執(zhí)行的（先從標(biāo)識符最大的n-1開始，一直到最小的0）
• Daemonset：理論上在K8S集群的所有Node節(jié)點上創(chuàng)建相同的Pod（無論Node節(jié)點什么時候加入到K8S集群），但是會受到Node節(jié)點上污點影響
• Job：部署一次性任務(wù)，正常完成后容器立即退出并且不重啟容器（RestartPolicy不設(shè)置Always），也不會重建異常完成后重試任務(wù)，重建次數(shù)根據(jù)backofflimit 配置指定（默認(rèn)為6次）
  用戶 cluster-admin 權(quán)限。這通常不推薦，因為它會降低集群的安全性。在生產(chǎn)環(huán)境中，應(yīng)該使用更細(xì)粒度的權(quán)限控制。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論