Kubernetes——Pod對象的聲明周期（Pod的相位、創建過程、重要行為、探測、重啟策略、終止過程）

来源:https://www.cnblogs.com/zuoyang/archive/2022/06/14/16371313.html
-Advertisement-
Play Games

Pod對象的聲明周期（Pod的相位、創建過程、重要行為、探測、重啟策略、終止過程） Pod 對象自從其創建開始至其終止退出的時間範圍稱為其生命周期。在這段時間中，Pod 會處於多種不同的狀態，並執行一些操作；其中，創建主容器（main container）為必須的操作，其他科選的操作還包括進行初始化 ...


Pod對象的聲明周期（Pod的相位、創建過程、重要行為、探測、重啟策略、終止過程）

  Pod 對象自從其創建開始至其終止退出的時間範圍稱為其生命周期。在這段時間中，Pod 會處於多種不同的狀態，並執行一些操作；其中，創建主容器（main container）為必須的操作，其他科選的操作還包括進行初始化容器（init container）、容器啟動後鉤子（post start hook）、容器的存活性探測（liveness probe）、就緒型探測（readiness probe）以及容器終止前鉤子（pre stop hook）等，這些操作是否執行則取決於 Pod 的定義。

一、Pod 的相位

  無論是用戶手動創建，還是通過 Deployment 等控制器創建，Pod 對象總是應該處於其生命進程中以下幾個相位（phase）之一:

    • pending：API Server 創建了 Pod 資源對象並已存入 etcd 中，但是它尚未被調度完成，或者仍處於從倉庫下載鏡像的過程中。
    • Running：Pod 已經被調度至某節點，並且所有容器都已經被 kubelet 創建完成。
    • Succeeded：Pod 中的所有容器都已經成功終止並且不會被重啟。
    • Failed：所有容器都已經終止，但至少有一個容器終止失敗，即容器返回了非 0 值的退出狀態或已經被系統終止。
    • Unkown：API Server 無法正常獲取到 Pod 對象的狀態信息，通常是由於其無法與所在工作節點的 kubelet 通信所致。

  Pod 相位是在其聲明周期的巨集觀概述，而非對容器或 Pod 對象的綜合彙總，而且相位的數量和含義被嚴格界定，它僅包含上面列舉的相位值。

二、Pod 的創建過程

  Pod 是 Kubernetes 的基礎單元，理解它的創建過程對於瞭解系統運作有很大幫助。

1）用戶通過 kubectl 或其他 API 客戶端提交 Pod Spec 給 API Server。

2）API Server 嘗試著將 Pod 對象的相關信息存入 etcd 中，待寫入操作執行完成，API Server 即會返回確認信息至客戶端。

3）API Server 返回 etcd 中的狀態變化。

4）所有的 Kubernetes 組件均使用 "watch" 機制來跟蹤檢查 API Server 上的相關的變動。

5）kube-scheduler（調度器）通過其 "watch" 覺察到 API Server 創建了新的 Pod 對象但尚未綁定至任何工作節點。

6）kube-scheduler 為 Pod 對象挑選一個工作節點將結果更新至 API Server。

7）調度結果信息由 API Server 更新至 etcd 存儲系統，而且 API Server 也開始反映此 Pod 對象的調度結果。

8）Pod 被調度到的目標工作節點上的 kubelet 嘗試在當前節點上調用 Docker 啟動容器，並將容器的結果狀態送至 API Server。

9）API Server 將 Pod 狀態信息存入 etcd 系統中。

10）在 etcd 確認寫入操作成功完成後，API Server 將確認信息發送至相關的 kubelet，事件將通過它被接受。

 三、Pod 生命周期中的重要行為

  除了創建應用容器（主容器及其輔助容器）之外，用戶還可以為 Pod 對象定義其生命周期中的多種行為，如初始化容器、存活性探測及就緒性探測等。

1、初始化容器

  初始化容器（init container）即應用程式的主容器啟動之前要運行的容器，常用於為主容器執行一些預置操作，它們具有兩種典型特征：

1）初始化容器必須運行完成執直至結束，若某初始化容器運行失敗，那麼 Kubernetes 需要重啟它直至成功完成。

2）每個初始化容器都必須按定義的順序串列運行。

  有不少場景都需要在應用容器啟動之前進行部分初始化操作，例如，等待其他關聯組件服務可用、基於環境變數或配置模版為應用程式生成配置文件、從配置中心獲取配置等。初始化容器的典型應用需求具體包括如下幾種：

用於運行特定的工具程式，處於安全的個方面的原因，這些程式不適於包含在主容器鏡像中。

2）提供主容器鏡像中不具備的工具程式或自定義代碼。

3）為容器鏡像的構建和部署人員提供了分離、獨立工作的途徑，使得他們不必協同起來製作單個鏡像文件。

4）初始化容器和主容器處於不同的文件系統視圖中，因此可以分別安全地使用敏感數據，例如 Secrets 資源。

5）初始化容器要先於應用容器串列啟動並運行完成，因此可用於延後應用容器的啟動直至其依賴的條件得到滿足。

  Pod 資源的 "spec.initContainers" 欄位以列表的形式定義可用的初始化容器，其嵌套可用欄位類型於 "spec.containers"。下麵的資源清單僅是一個初始化容器的使用示例參考：

kind: Pod
apiVersion: v1
metadata:
  name: redis-ha-haproxy-64444759d4-wf45w
  generateName: redis-ha-haproxy-64444759d4-
  namespace: kubesphere-system
  labels:
    app: redis-ha-haproxy
    pod-template-hash: 64444759d4
    release: ks-redis
  annotations:
    checksum/config: 46138f8b2005948188bc12c93b08a9c6460354af2db98eaa2158bcf1717e82de
    cni.projectcalico.org/podIP: 10.233.105.1/32
    cni.projectcalico.org/podIPs: 10.233.105.1/32
    prometheus.io/path: /metrics
    prometheus.io/port: '9101'
    prometheus.io/scrape: 'true'
spec:
  volumes:
    - name: config-volume
      configMap:
        name: redis-ha-configmap
        defaultMode: 420
    - name: shared-socket
      emptyDir: {}
    - name: data
      emptyDir: {}
    - name: redis-ha-haproxy-token-5lqwd
      secret:
        secretName: redis-ha-haproxy-token-5lqwd
        defaultMode: 420
  initContainers:
    - name: config-init
      image: 'registry.cn-beijing.aliyuncs.com/kubesphereio/haproxy:2.0.4'
      command:
        - sh
      args:
        - /readonly/haproxy_init.sh
      resources: {}
      volumeMounts:
        - name: config-volume
          readOnly: true
          mountPath: /readonly
        - name: data
          mountPath: /data
        - name: redis-ha-haproxy-token-5lqwd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
  containers:
    - name: haproxy
      image: 'registry.cn-beijing.aliyuncs.com/kubesphereio/haproxy:2.0.4'
      ports:
        - name: redis
          containerPort: 6379
          protocol: TCP
      resources: {}
      volumeMounts:
        - name: data
          mountPath: /usr/local/etc/haproxy
        - name: shared-socket
          mountPath: /run/haproxy
        - name: redis-ha-haproxy-token-5lqwd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8888
          scheme: HTTP
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 3
        successThreshold: 1
        failureThreshold: 3
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
  restartPolicy: Always
  terminationGracePeriodSeconds: 30
  dnsPolicy: ClusterFirst
  serviceAccountName: redis-ha-haproxy
  serviceAccount: redis-ha-haproxy
  nodeName: mh-k8s-master-prd-243.24
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
    fsGroup: 1000
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: node-role.kubernetes.io/master
                operator: In
                values:
                  - ''
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: redis-ha-haproxy
              release: ks-redis
          topologyKey: kubernetes.io/hostname
  schedulerName: default-scheduler
  tolerations:
    - key: node-role.kubernetes.io/master
      effect: NoSchedule
    - key: CriticalAddonsOnly
      operator: Exists
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 60
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 60
  priority: 0
  enableServiceLinks: true

2、聲明周期鉤子函數

  生命周期鉤子函數（lifcycle hook）是編程語言（如 Angular）中常用的生命周期管理的組件，它實現了程式運行周期中的關鍵時刻的可見性，並賦予用戶為此採取某種行動的能力。類似地，容器聲明周期鉤子使它能夠感知其自身生命周期管理中的事件，併在相應的時刻到來時運行由用戶指定的處理程式代碼。Kubernetes 為容器提供了兩種生命周期的鉤子。

1）postStart：於容器創建完成之後立即運行的鉤子處理器（handler），不過 Kubernetes 無法確保它一定會於容器中的 ENTRYPOINT 之前運行。

2）preStop：於容器終止操作之前立即運行的鉤子處理器，它以同步的方式調用，因此在其完成之前會阻塞刪除容器的操作的調用。

  鉤子處理器的實現方式有 "Exec" 和 "HTTP" 兩種，前一種在鉤子事件觸發時直接在當前容器中運行由用戶定義的命令，後一種則是在當前容器中向某 URL 發起 HTTP請求。

3、容器探測

 容器探測（container probe）是 Pod 對象生命周期中的一項重要的日常任務，它是 kubelet 對容器周期性執行的健康狀態診斷，診斷操作由容器的處理器（handler）進行定義。

  Kubernetes 支持三種處理器用於 Pod 探測。

    • ExecAction：在容器中執行一個命令，並根據其返回的狀態碼進行診斷的操作稱為 Exec 探測，狀態碼為 0 表示成功，否則即為不健康狀態。
    • TCPSocketAction：通過與容器的某 TCP 埠嘗試建立連接進行診斷，埠能夠成功打開即為正常，否則為不健康狀態。
    • HTTPGetAction：通過向容器 IP 地址的某指定埠的指定 path 發起 HTTP GET 請求進行診斷，響應碼為 2xx 或 3xx 時即為成功，否則為失敗。

  任何一種探測方式都可能存在三種結果："Success"（成功）、"Failure"（失敗）或 "Unknown"（未知），只有第一種結果表示成功通過檢測。

存活性檢測：

  用於判定容器是否處於 "運行"（Running）狀態；一旦此類檢測未通過，kubelet 將殺死容器並根據其 restartPolicy 決定是否將其重啟；未定義存活性檢測的容器的預設狀態為 "Success"。

就緒性檢測：

  用於判斷容器是否準備就緒並可對外提供服務；未通過檢測的容器意味著其尚未準備就緒，端點控制器（如 Service 對象）會將其 IP 從所有匹配到此 Pod 對象的 Service 對象的端點列表中移除；檢測通過之後，會再次將其 IP 添加至端點列表中。

四、容器調度重啟策略

  容器程式發生崩潰或容器申請超過限制的資源等原因都可能會導致 Pod 對象的終止，此時是否應該重建該 Pod 對象則取決於其重啟策略（restartPolicy）屬性的定義。

1）Always：但凡 Pod 對象終止就將其重啟，此為預設設定。

2）OnFailure：僅在 Pod 對象出現錯誤時方纔能將其重啟。

3）Nerver：從不重啟

提示：

  restartPolicy 適用於 Pod 對象中的所有容器，而且它僅用於控制在同一節點上重新啟動 Pod 對象的相關容器。
  首次需要重啟的容器，將在其需要時立即進行重啟，隨後再次需要重啟的操作由 kubelet 延遲一段時間後進行，且反覆的重啟操作的延遲時長依次為 10秒、20秒、40秒、80秒、160秒 和 300秒，300秒是最大延遲時長。
  Pod 一旦綁定到一個節點，Pod對象將永遠不會被重新綁定到另一個點，它要麼被重啟，要麼終止，直到節點發生故障或被刪除。

五、Pod 的終止過程

  Pod 對象代表了在 Kubernetes 集群節點上運行的進程，它可能曾用於處理生產數據或向用戶提供服務等，但是，當 Pod 本身不再具有存在的價值時，如何將其優雅地終止就顯得尤為重要了，而用戶也需要能夠在正常提交刪除操作後可以獲知其如何開始終止並最終完成。

  操作中，當用戶提交刪除請求後，系統就會進行強制刪除操作的寬限期倒計時，並將 TERM 信息發送給 Pod 對象的每個容器中的主進程。寬限期倒計時結束後，這些進程將啊收到強制終止的 KILL 信號，Pod 對象隨即也將由 API Server 刪除。如果在等待進程終止的過程中，kubelet 或容器管理器發生了重啟，那麼終止操作會重新獲得一個滿額的刪除寬限期並重新進行刪除操作。·

  一個典型的 Pod 對象終止流程具體如下：

1）用戶發送刪除 Pod 對象的命令。

2）API 伺服器中的 Pod 對象會隨著時間的推移而更新，在寬限期內（預設 30秒），Pod 視為 "dead"。

3）將 Pod 標記為 "Terminating" 狀態。

4）（與第 3 步同時運行）kubelet 在監控到 Pod 對象轉為 "Terminating" 狀態的同時啟動 Pod 關閉過程。

5）（與第 3 步同時運行）端點控制器監控到 Pod 對象的關閉行為時將其從所有匹配到此端點的 Service 資源的端點列表中移除。

6）如果當前 Pod 對象定義了 preStop 鉤子處理器，則在其標記為 "terminating" 後即會以同步的方式啟動執行；如若寬限期結束後，preStop 仍未執行結束，則第 2 步會被重新執行並額外獲取一個時長為 2 秒 的小寬限期。

7）Pod 對象中的容器進程收到 TERM 信號。

8）寬限期結束後，若存在任何一個仍在運行的進程，那麼 Pod 對象即會收到 SIGKILL 信號。

9）Kubelet 請求 API Server 將此 Pod 資源的寬限期設置為 0 從而完成刪除操作，它變得對用戶不再可見。

預設情況下，所有刪除操作的寬限期都是 30秒，不過， kubectl delete 命令可以使用 "--grace-period=<seconds>"選項自定義其時長，若使用 0 值則表示直接強制刪除指定的資源，不過，此時需要同時為命令使用 "--force" 選項。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Java學習-第一部分-第一階段-第二節：變數
    變數 變數介紹 為什麼需要變數 變數是程式的基本組成單位 不論是使用哪種高級程式語言編寫程式,變數都是其程式的基本組成單位，比如: //變數有三個基本要素(類型+名稱+值) class Test{ public static void main(String []args){ int a=1;//定 ...
  • 操作系統 進程式控制制 實驗（C語言）
    進程式控制制 基本要求 模擬操作系統內核對進程的控制和管理：包括進程的創建和撤銷、進程狀態的切換和簡單的記憶體空間管理。 實驗提示 1、 定義管理每個進程的數據結構PCB：包含進程名稱、隊列指針、分配的物理記憶體區域（基址和長度）。每創建一個進程時，需要為其創建PCB並分配空閑記憶體空間，對PCB進行初始化， ...
  • token和jwt
    首先明確：JWT = JSON WEB TOKEN 那麼就很簡單了，Token=令牌，JWT=含有json信息的令牌 用一個形象一點的例子解釋一下Token和JWT的區別與聯繫： 以前醫生開藥單，都是用的龍飛鳳舞的特殊簡寫，你只有把這個藥方拿到指定的取藥處，取藥人根據藥方結合腦中的對照表，就知道這個 ...
  • 【2022-06-16】Python解釋器的下載安裝與使用
    一、Python解釋器介紹 什麼是Python解釋器？ Python是一門解釋型語言，解釋器是Python運行必不可少的一種工具。所以，我們搭建Python環境，本質上就是對Python進行配置和定製。而解釋器就是能夠執行用其他電腦語言編寫的程式的系統軟體，它是一種翻譯程式。 它的執行方式是一邊翻 ...
  • matplotlib可視化系列之【顏色】
    顏色和排版一樣，看似簡單，其實非常複雜，往大了說，涉及到藝術和品味，不像數學公式，物理定理那樣，是非分明。 但是，對 matplotlib 中的顏色有些基本的瞭解，可以讓繪出的圖形顏色不至於太突兀。 雖不能說選出完美的顏色搭配，至少是看著舒服，醒目的顏色搭配。 顏色的種類 顏色一般用 RGB 來表示 ...
  • list,set ,map底層分析
    一、亮出效果 最近一些軟體的搜題、智能批改類的功能要下線。 退1024步講，要不要自己做一個自動批改的功能啊？萬一哪天孩子要用呢！ 昨晚我做了一個夢，夢見我實現了這個功能，如下圖所示： 功能簡介：作對了，能打對號；做錯了，能打叉號；沒做的，能補上答案。 醒來後，我環顧四周，趕緊再躺下，希望夢還能接上 ...
  • 【親測】IDEA激活教程2021.3.3版本
    一、需求分析 我們知道，網上有很多的翻譯平臺，比如：Google翻譯、百度翻譯、有道翻譯、微軟翻譯等等。本次我們來使用selenium模塊實現對Google翻譯的爬取的實現。 我們需要上傳一個文件給Google翻譯，然後再將Google翻譯的結果保存在一個文件之中。 當然了，我們是全自動化的處理了啦 ...
  • WPF開發隨筆收錄-獲取軟體當前目錄的坑
    一、嘮嘮叨叨 軟體開發過程中，經常需要使用到獲取exe當前目錄這個功能，前同事在實現這個需求時使用的是Directory.GetCurrentDirectory()這個方法，但再最近的測試中，突然發現文件沒有正常生成在exe所在的目錄，找了很久突然發現生成在了自啟動exe程式的bat文件所在的目錄， ...
一周排行
    -Advertisement-
    Play Games
  • GoF之工廠模式
    GoF之工廠模式 @目錄GoF之工廠模式每博一文案1. 簡單說明“23種設計模式”1.2 介紹工廠模式的三種形態1.3 簡單工廠模式（靜態工廠模式）1.3.1 簡單工廠模式的優缺點:1.4 工廠方法模式1.4.1 工廠方法模式的優缺點:1.5 抽象工廠模式1.6 抽象工廠模式的優缺點：2. 總結:3 ...
  • dotnet C# 簡單的追加文件夾到 ZipArchive 壓縮文件的方法
    新改進提供的Taurus Rpc 功能，可以簡化微服務間的調用，同時可以不用再手動輸出模塊名稱，或調用路徑，包括負載均衡，這一切，由框架實現並提供了。新的Taurus Rpc 功能，將使得服務間的調用，更加輕鬆、簡約、高效。 ...
  • Elasticsearch 系列（六）- ES數據同步和ES集群
    本章將和大家分享ES的數據同步方案和ES集群相關知識。廢話不多說，下麵我們直接進入主題。 一、ES數據同步 1、數據同步問題 Elasticsearch中的酒店數據來自於mysql資料庫，因此mysql數據發生改變時，Elasticsearch也必須跟著改變，這個就是Elasticsearch與my ...
  • 自動化測試數據生成：Asp.Net Core單元測試利器AutoFixture詳解
    引言 在我們之前的文章中介紹過使用Bogus生成模擬測試數據，今天來講解一下功能更加強大自動生成測試數據的工具的庫"AutoFixture"。 什麼是AutoFixture? AutoFixture 是一個針對 .NET 的開源庫，旨在最大程度地減少單元測試中的“安排（Arrange）”階段，以提高 ...
  • .NET Emit 入門教程：第七部分：實戰項目1：將 DbDataReader 轉實體
    經過前面幾個部分學習，相信學過的同學已經能夠掌握 .NET Emit 這種中間語言，並能使得它來編寫一些應用，以提高程式的性能。隨著 IL 指令篇的結束，本系列也已經接近尾聲，在這接近結束的最後，會提供幾個可供直接使用的示例，以供大伙分析或使用在項目中。 ...
  • Windows下綁定線程到指定的CPU核心
    當從不同來源導入Excel數據時，可能存在重覆的記錄。為了確保數據的準確性，通常需要刪除這些重覆的行。手動查找並刪除可能會非常耗費時間，而通過編程腳本則可以實現在短時間內處理大量數據。本文將提供一個使用C# 快速查找並刪除Excel重覆項的免費解決方案。 以下是實現步驟： 1. 首先安裝免費.NET ...
  • mORMot 1.18 第07章 簡單的讀寫操作
    C++ 異常處理 C++ 異常處理機制允許程式在運行時處理錯誤或意外情況。它提供了捕獲和處理錯誤的一種結構化方式，使程式更加健壯和可靠。 異常處理的基本概念： 異常: 程式在運行時發生的錯誤或意外情況。 拋出異常: 使用 throw 關鍵字將異常傳遞給調用堆棧。 捕獲異常: 使用 try-catch ...
  • mORMot 1.18 第06章 概念
    優秀且經驗豐富的Java開發人員的特征之一是對API的廣泛瞭解，包括JDK和第三方庫。 我花了很多時間來學習API，尤其是在閱讀了Effective Java 3rd Edition之後 ，Joshua Bloch建議在Java 3rd Edition中使用現有的API進行開發，而不是為常見的東西編 ...
  • php 開發規範
    框架 · 使用laravel框架，原因：tp的框架路由和orm沒有laravel好用 · 使用強制路由，方便介面多時，分多版本，分文件夾等操作 介面 · 介面開發註意欄位類型，欄位是int，查詢成功失敗都要返回int（對接java等強類型語言方便） · 查詢介面用GET、其他用POST 代碼 · 所 ...
  • 2024 年 4 月 28 日 周日 晴 熱（1253 字）
    正文 下午找企業的人去鎮上做貸後。 車上聽同事跟那個司機對罵，火星子都快出來了。司機跟那同事更熟一些，連我在內一共就三個人，同事那一手指桑罵槐給我都聽愣了。司機也是老社會人了，馬上聽出來了，為那個無辜的企業經辦人辯護，實際上是為自己辯護。 “這個事情你不能怪企業。”“但他們總不能讓銀行的人全權負責， ...
所有分類