容器

容器：容器是容器鏡像的運行態，通過基于標準的容器運行時運行，將應用程序從底層的主機設施中解耦。

容器鏡像：容器鏡像是一個隨時可以運行的軟件包，包含運行應用程序所需的一切：代碼和它需要的所有運行時、應用程序和系統庫，以及一些基本設置的默認值。

容器環境：在容器鏡像的基礎上，包括文件系統以及各種env變量、hostname、掛載的各種volume，共同組成了容器真正的運行環境。

容器運行時：負責管理 Kubernetes 環境中容器的執行和生命周期，通過容器運行時接口（CRI）與Kubernetes交互。

容器生命周期中的回調：特定運行時支持PostStart（異步）和PreStop（同步）回調。

容器更新和拉取：建議使用容器標簽或者摘要指定要更新的鏡像名，并配合明確的拉取策略（IfNotPresent/Always），為了加速鏡像拉取可以選擇啟用并行拉取以及預先拉取，同時需要通過憑據保護私有倉庫的訪問。

Pod

Pod 是可以在 Kubernetes 中創建和管理的、最小的可部署的計算單元。

Pod 內的容器共享namespace（共享進程、網絡、IPC和主機名）和文件系統卷。

Pod 中的容器可以在特權模式下運行，以使用原本無法訪問的操作系統管理權能。

通常不需要直接創建 Pod，應該使用諸如 Deployment 這類工作負載資源來創建 Pod。

Pod的更新遵循“刪除-重建”模式，能更新的只有[*].image、activeDeadlineSeconds 和tolerations。

Pod生命周期

Pod是一次性調度單元，重新調度、重啟等都是基于刪除舊的、新建新的策略；

Pod有Pending、Running、Successded、Failed、Unknows五個狀態，容器有Waiting、Running、Terminated狀態；

1.29版本加入Pod 就緒態的狀態用于更細力度區分contaienrs ready和Pod ready；

Pod探測：StartupProbe（是否啟動）、livenessProbe（是否存活）、ReadlinessProbe（是否Ready）;

Pod支持優雅停止，刪除一個Pod時會先發Term信號，提示Pod內的服務開始排空請求，默認30s后，如果Pod還沒終止，就發送KILL信號強制殺死Pod。

kubectl delete --force會觸發強制刪除。

PodGC控制器會自動回收非預期的Pod。

init容器是一種在 Pod 內的應用容器啟動之前運行的特殊容器，如果為一個 Pod 指定了多個 Init 容器，會在網絡和數據卷初始化后按順序逐個運行。

每個 Init 容器必須運行成功，下一個才能夠運行，當所有的 Init 容器運行完成時， Kubernetes 才會為 Pod 初始化應用容器并像平常一樣運行。

如果 Pod 重啟，所有 Init 容器必須重新執行。因為 Init 容器可能會被重啟、重試或者重新執行，所以 Init 容器的代碼應該是冪等的。

Pod中某個資源request/limit的有效值=max(init容器某資源request/limit的最大值，應用容器某資源request/limit之和)，調度和管理基于Pod有效資源值進行。

邊車容器是一種特殊的常駐init容器，遵循init容器啟動順序，在創建Init 容器時將 restartPolicy 設置為 Always將變為邊車容器，在整個 Pod 的生命周期中都處于活動狀態，并且可以獨立于主容器啟動和停止，具有獨立生命周期并支持探針來控制其生命周期。

臨時容器可以在現有 Pod 中臨時運行，以便完成用戶發起的操作，例如故障排查。當由于容器崩潰或容器鏡像不包含調試工具而導致 kubectl exec 無用時，臨時容器對于交互式故障排查很有用。kubectl debug就是使用臨時容器實現的，用于distroless鏡像排查問題很有用，需要注意的是使用時需要共享進程命名空間。

當一個 Node 耗盡資源時，Kubernetes 將首先驅逐該 Node 上運行的 BestEffort Pod，然后是 Burstable Pod，最后是 Guaranteed Pod。

Guaranteed Pod：Pod內部所有容器都有設置request和limit，且值一樣；Burstable Pod：Pod內部至少有一個容器設置了資源request/limit；BestEffort Pod：Pod內部容器都沒有設置資源request/limit。

故障預算（PDB）指定應用可以容忍的副本數量（相當于應該有多少副本），可以防止非預期的Pod終止情況。

在進行滾動升級時不受 PDB 的限制，更新期間的處理方式是在對應的工作負載資源的 spec 中配置的。

Pod終止狀況（PodDisruptionConditions）指示Pod終止原因。

在 Kubernetes 中，有兩種方法可以將 Pod 和容器字段暴露給運行中的容器：

• 作為環境變量，這個是最常用的
• 作為 downwardAPI 卷中的文件

 這兩種暴露 Pod 和容器字段的方式統稱為 Downward API。通常使用現代的開發框架，如springboot，都可以自動識別很多Pod和容器信息，具體需要參考各個框架。應用最常用的是環境變量方案獲取Podname或者IP，用于設置日志文件名稱或者注冊中心注冊，這兩個信息通常默認都有（HOSTNAME和XXX_SERVICE_HOST），不需要額外注入，其他信息需要根據需要選擇注入。

工作負載

Deployment

Deployment 為 Pod 和 ReplicaSet 提供聲明式的更新能力。

Deployment 為 Pod 和 ReplicaSet提供聲明式的更新能力，幫助用戶自動化的管理Pod和服務，包括Pod更新、回滾、縮放等運維操作。

Deployment每次更新會發起一個新的ReplicaSet，ReplicaSet部署對應Pod。

命名規則：Deployment的name由.metadata.name指定，ReplicaSet的name由.metadata.name-Pod-template-hash組成，Pod name查了代碼發現是在ReplicaSet名稱后面附加5個隨機字符。

僅當 Deployment Pod 模板（即 .spec.template）發生改變時，例如模板的標簽或容器鏡像被更新，才會觸發Deployment 更新。

在 API 版本 apps/v1 中，Deployment 標簽選擇算符在創建后是不可變的，且.spec.selector 必須匹配 .spec.template.metadata.labels，否則請求會被 API 拒絕。

當 Deployment 正在更新時又被更新，Deployment 會針對更新創建一個新的 ReplicaSet 并開始對其擴容，之前正在被擴容的 ReplicaSet 會被縮容，添加到舊 ReplicaSet 列表 并開始縮容。

如果 .spec.strategy.type==Recreate，在創建新 Pod 之前，所有現有的 Pod 會被殺死。若 .spec.strategy.type==RollingUpdate時，采取滾動更新的方式更新 Pod。可以指定 maxUnavailable 和 maxSurge 來控制滾動更新過程，默認值都是25%。

Deployment支持比例縮放，如果一個Deployment存在多個ReplicaSet在執行更新過程，那么縮放時按當前rs中的Pod數量等比例縮放，而不是一股腦都給最新的rs。

Deployment更新前或者更新過程中，可以設置暫停更新，然后修改各種信息后，重新恢復執行，此時會自動應用最新修改后的更新。

Deployment默認保持最新10次的ReplicaSet記錄，這樣可以支持回滾到最近10次修改，建議還是用git記錄所有歷史YAML的修改。

Deployment狀態有三種：Progressing、Complete、Failed。

Deployment其實不支持金絲雀發布，需要額外或者更高級的控制Deployment實現金絲雀發布的能力。

StatefulSet

StatefulSet 是用來管理有狀態應用的工作負載 API 對象，可以管理某 Pod 集合的部署和擴縮，并為這些 Pod 提供持久存儲和持久標識符，包括：

• 穩定的、唯一的網絡標識符
• 穩定的、持久的存儲
• 有序的、優雅的部署和擴縮
• 有序的、自動的滾動更新

重點能力如下：

序號：對于具有 N 個副本的 StatefulSet，該 StatefulSet 中的每個 Pod 將被分配一個整數序號，該序號在此 StatefulSet 中是唯一的。默認情況下，這些 Pod 將被賦予從 0 到 N-1 的序號。

主機標識：StatefulSet 中的每個 Pod 根據 StatefulSet 的名稱和 Pod 的序號派生出它的主機名，格式為$(StatefulSet 名稱)-$(序號)。

網絡標識：需要創建Headless服務以便為 Pod 提供網絡標識，格式為$(podname).$(servicename).$(namespace).svc.cluster.local。

持久存儲：對于 StatefulSet 中定義的 VolumeClaimTemplate，每個 Pod 接收到一個 PersistentVolumeClaim。 當 Pod 或者 StatefulSet 被刪除時，與 PersistentVolumeClaims 相關聯的 PersistentVolume 并不會被刪除，要刪除它必須通過手動方式來完成。

部署的順序性：對于包含 N 個副本的StatefulSet，當部署 Pod 時，它們是依次創建的，順序為 0..N-1。當刪除 Pod 時，它們是逆序終止的，順序為 N-1..0。在將擴縮操作應用到 Pod 之前，它前面的所有 Pod 必須是 Running 和 Ready 狀態。在一個 Pod 終止之前，所有的繼任者必須完全關閉。

滾動更新：StatefulSet 控制器會刪除和重建 StatefulSet 中的每個 Pod，按照與 Pod 終止相同的順序（從最大序號到最小序號）進行，每次更新一個 Pod。

滾動更新的異常處置：如果更新后 Pod 模板配置進入無法運行或就緒的狀態StatefulSet 將停止回滾并等待。恢復模板后，StatefulSet 繼續等待損壞狀態的 Pod 準備就緒（永遠不會發生），此時必須刪除 StatefulSet 嘗試使用錯誤的配置來運行的 Pod， StatefulSet 才會開始使用被還原的模板來重新創建 Pod（已知問題kubernetes/issues/67250）。

來自 volumeClaimTemplate 的 PVC 默認策略是在 Pod 被刪除時不受影響，依然保留。

DaemonSet

DaemonSet 與 Deployment 非常類似，但DaemonSet 確保全部（或者某些）節點上運行一個 Pod 的副本。當有節點加入集群時，也會為他們新增一個 Pod，當有節點從集群移除時，這些 Pod 也會被回收，刪除 DaemonSet 將會刪除它創建的所有 Pod。

• DaemonSet 比較適合運維工具的部署，例如監控、日志采集等組件。
• DaemonSet 遵循 .spec.template.spec.nodeSelector 和 .spec.template.spec.affinity 限制，只在滿足節點親和性的節點上部署 Pod。 如果沒有指定，則 DaemonSet Controller 將在所有節點上創建 Pod。
• 調度起評估符合條件的節點時，原本在 .spec.template.spec.affinity.nodeAffinity 字段上指定的節點親和性將由 DaemonSet 控制器進行考慮，但在創建的 Pod 上會被替換為與符合條件的節點名稱匹配的節點親和性。
• DaemonSet 控制器會自動將一組容忍度添加到 DaemonSet Pod，以實現可以被調度到不健康或還不準備接受 Pod 的節點上，包括不健康、沒Ready、不可達、不可調度以及資源使用原理的節點。
• DaemonSet 默認更新策略是滾動更新。

Job

Job 會創建一個或者多個 Pod，并將繼續重試 Pod 的執行，直到指定數量的 Pod 成功終止。 隨著 Pod 成功結束，Job 跟蹤記錄成功完成的 Pod 個數。 當數量達到指定的成功個數閾值時，任務（即 Job）結束。

• Job 會創建一個或者多個 Pod，并將繼續重試 Pod 的執行，直到指定數量的 Pod 成功終止。 隨著 Pod 成功結束，Job 跟蹤記錄成功完成的 Pod 個數。 當數量達到指定的成功個數閾值時，任務（即 Job）結束。
• 掛起 Job 的操作會刪除 Job 的所有活躍 Pod（可能執行了部分），直到 Job 被再次恢復執行（重新調度新的Pod再次執行）。
• 刪除 Job 的操作會清除所創建的全部 Pod。
• Job Spec中通常不設置Labels和Selctor，RestartPolicy 只能設置為 Never 或 OnFailure 之一。spec.completions 和 spec.parallelism代表完成數和并行數，默認都是1，可以根據任務需要的完成數和并行度分別設置。
• 容器失敗：當Pod中的容器運行失敗時，當RestartPolicy=OnFailure會重啟容器，當RestartPolicy=Never不會重啟容器，會直接將Pod狀態修改為Failed。
• Pod失敗：Job會重新調度一個新的Pod運行，所以程序需要處理冪等問題。
• Pod失敗回退策略：.spec.backoffLimit 設置 Job 失敗之前Pod的重試次數，默認6，回退重試時間將會按指數增長 （從 10 秒、20 秒到 40 秒）最多至 6 分鐘。
• Pod失敗次數統計方法：第一種是Pod狀態為Failed，但對于RestartPolicy=OnFailure會重啟容器的Pod，容器失敗次數也會當做Pod失敗次數。當失敗次數超過.spec.backoffLimit 時會將Job狀態設置為Failed。
• .spec.podFailurePolicy 字段支持配置 Pod 失效策略，該策略可以根據容器退出碼和 Pod 狀況來處理 Pod 失效。
• Job 完成時（不論成功或失敗）不會再創建新的 Pod，不過已有的 Pod 通常也不會被刪除。 保留這些 Pod 使得你可以查看已完成的 Pod 的日志輸出，以便檢查錯誤、警告或者其它診斷性輸出。 Job 完成時 Job 對象也一樣被保留下來，這樣你就可以查看它的狀態。 在查看了 Job 狀態之后刪除老的 Job 的操作留給了用戶自己。
• 自動清理已完成 Job （狀態為 Complete 或 Failed）的一種方式是使用由 TTL 控制器所提供的 TTL 機制。 通過設置 Job 的 .spec.ttlSecondsAfterFinished 字段，可以讓該控制器清理掉已結束的資源。
• 可以為 Job 的 .spec.activeDeadlineSeconds 設置一個秒數值，該值適用于 Job 的整個生命期，無論 Job 創建了多少個 Pod，一旦 Job 運行時間達到 activeDeadlineSeconds 秒，其所有運行中的 Pod 都會被終止，并且 Job 的狀態更新為 type: Failed 及 reason: DeadlineExceeded。

CronJob

CronJob 創建基于時隔重復調度的 Job。CronJob 用于執行排期操作，例如備份、生成報告等。 一個 CronJob 對象就像 Unix 系統上的 crontab（cron table）文件中的一行。 它用 Cron 格式進行編寫，并周期性地在給定的調度時間執行 Job。

# ┌───────────── 分鐘 (0 - 59)
# │ ┌───────────── 小時 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周六）
# │ │ │ │ │                          或者是 sun，mon，tue，web，thu，fri，sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

CronJob 創建基于時隔重復調度的 Job，Job負責Pod生成和調度執行。

CronJob 用于執行排期操作，例如備份、生成報告等。一個 CronJob 對象就像 Unix 系統上的 crontab（cron table）文件中的一行。 它用 Cron 格式進行編寫[分 時 日 月 周]，并周期性地在給定的調度時間執行 Job。

CronJob支持時區設置，默認為本地時區。

修改CronJob只對后續創建的Job有效。

并發調度策略支持三種：{"Allow":"允許并發","Forbid":"不允許","Replace":"調度覆蓋"}，默認Allow。

建議設置spec.startingDeadlineSeconds，表示統計錯過調度次數的開始時間，默認從最后一次調度時間開始統計錯過調度次數(超過100不再調度)。

CronJob Spec中是jobTemplate，其他控制器都是template，且Job和CronJob控制器都無需定義Labels和Selector，控制器自動添加并確保匹配。