TTL 機制排毒，線上k8s的Job已經通過API 增加了Job的TTL 時長，且成功響應，為什麼系統還是清理了Job？
TTL 機制排毒，線上k8s的Job已經通過API 增加了Job的TTL 時長，且成功響應，為什麼系統還是清理了Job？
面試官："已完成 Job 的 TTL 機制了解嘛？簡單說說TTL存在的時間偏差問題？"
面試官："能簡單描述一下什麼是TTL-after-finished 控制器嘛？"
面試官："我明明已經通過API 增加了Job的TTL 時長，且得到了成功的響應，為什麼系統還是清理了Job？"
面試官："如何更加準確的跟蹤 Job 完成情況？了解 Finalizer 追蹤 Job嘛？"
面試官："說說什麼場景下CronJob 無法被調度？"
囧么肥事-胡說八道
已完成 Job 的 TTL 機制了解嘛？簡單說說TTL存在的時間偏差問題？
完成的 Job 通常不需要繼續留存在系統中。在系統中一直保留它們會給 API 服務器帶來額外的壓力。
實際上自動清理完成的 Job有兩種常規方式：
1、更高級別的控制器管理
2、已完成 Job 的 TTL 機制
更高級別的控制器管理
如果 Job 由某種更高級別的控制器來管理，例如CronJobs， 則 Job 可以被 CronJob 基於特定的根據容量裁定的清理策略清理掉。
已完成 Job 的 TTL 機制
自動清理已完成 Job （狀態為 Complete 或 Failed）的另一種方式是使用由TTL-after-finished控制器所提供 的 TTL 機制。 通過設置 Job 的 .spec.ttlSecondsAfterFinished 字段，可以讓該控制器清理掉 已結束的資源。
注意點一：TTL 控制器清理 Job 時，會級聯式地刪除 Job 對象。 換言之，它會刪除所有依賴的對象，包括 Pod 及 Job 本身。
注意點二：當 Job 被刪除時，系統會考慮其生命周期保障，其生命周期函數也將被觸發，例如 Finalizers。
面試官：「能簡單描述一下什麼是TTL-after-finished 控制器嘛？」
TTL-after-finished 控制器只支持 Job。集群操作員可以通過指定 Job 的 .spec.ttlSecondsAfterFinished 字段來自動清理已結束的作業（Job狀態為Complete或Failed）。
TTL-after-finished 控制器假設作業能在執行完成後的 TTL 秒內被清理，也就是當 TTL 過期後，當 TTL 控制器清理作業時，它將做級聯刪除操作，即刪除資源對象的同時也刪除其依賴對象。 注意，當資源被刪除時，由該資源的生命周期保證其終結器（Finalizers）等被執行。
Job可以隨時設置 TTL 秒，可以植入多種不同的需求場景，以下是設置 Job 的 .spec.ttlSecondsAfterFinished 字段的一些示例：
- 在作業清單（
manifest）中指定此字段，以便 Job 在完成後的某個時間被自動清除。 - 將此字段設置為現有的、已完成的作業，以採用此新功能。
- 創建作業時使用
mutating admission webhook動態設置該字段。集群管理員可以使用它對完成的作業強制執行 TTL 策略。 - 作業完成後使用
mutating admission webhook動態設置該字段，並根據作業狀態、標籤等選擇不同的 TTL 值。
字段解釋 ttlSecondsAfterFinished：
- Job
pi-with-ttl的ttlSecondsAfterFinished值為 100，則在其結束100秒之後，Job將可以被自動刪除 - 如果
ttlSecondsAfterFinished被設置為0，則 TTL 控制器在 Job 執行結束後，立刻就可以清理該 Job 及其 Pod - 如果
ttlSecondsAfterFinished值未設置，則 TTL 控制器不會清理該 Job
面試官：「我明明已經通過API 增加了Job的TTL 時長，且得到了成功的響應，為什麼系統還是清理了Job？」
這裡涉及到兩個TTL的概念：時間偏差和更新TTL秒數周期
時間偏差問題
由於 TTL-after-finished 控制器使用存儲在 Kubernetes 資源中的時間戳來確定 TTL 是否已過期， 該功能對集群中的時間偏差很敏感，所以，設置非零 TTL 時，可能導致 TTL-after-finished 控制器在錯誤的時間清理資源對象。
更新 TTL 秒數問題
在創建 Job 或已經執行結束後，仍可以修改其 TTL 周期，例如 Job 的 .spec.ttlSecondsAfterFinished 字段。
但是一旦 Job 變為可被刪除狀態（當其 TTL 已過期時），即使通過 API 增加其 TTL 時長得到了成功的響應，系統也不保證 Job 將被保留。
如何更加準確的跟蹤 Job 完成情況？了解 Finalizer 追蹤 Job嘛？
想要更加準確的跟蹤 Job 完成情況，需要為API 服務器和控制器管理器啟用 JobTrackingWithFinalizers特性，該特性默認是禁用的。
啟用後，控制面會追蹤新的 Job，對現有 Job 不受影響
未啟用JobTrackingWithFinalizers特性前是如何跟蹤Job完成情況的？
該功能未啟用時，Job控制器依靠計算k8s集群中存在的 Pod 來跟蹤作業狀態。
也就是說，Job控制器需要去維護一個統計 succeeded 和 failed 的 Pod 的計數器。
然而，Pod 可能會因為一些原因被移除，導致統計不準確：
- 當一個節點宕機時，垃圾收集器會刪除孤立（Orphan）Pod。
- 垃圾收集器在某個閾值後刪除已完成的 Pod（處於
Succeeded或Failed階段）。 - 人工干預刪除 Job 的 Pod。
- 一個外部控制器（不包含於
Kubernetes）來刪除或取代 Pod。
啟用JobTrackingWithFinalizers特性後是如何跟蹤Job完成情況的？
如果集群啟用了 JobTrackingWithFinalizers 特性，控制面會跟蹤屬於任何 Job 的 Pod。 並注意是否有任何這樣的 Pod 被從 API 服務器上刪除。 為了實現這一點，Job 控制器創建的 Pod 帶有 Finalizer batch.kubernetes.io/job-tracking。 控制器只有在 Pod 被記入 Job 狀態後才會移除 Finalizer，允許 Pod 可以被其他控制器或用戶刪除。
注意：Job 控制器只對新的 Job 使用新的算法。在啟用該特性之前創建的 Job 不受影響。 你可以根據檢查 Job 是否含有 batch.kubernetes.io/job-tracking 註解，來確定 Job 控制器是否正在使用 Pod Finalizer 追蹤 Job。 注意不應該給 Job 手動添加或刪除該註解。
前面你提到了CronJobs負載，它編排的Job為什麼需要是冪等的？
CronJob 創建基於時隔重複調度的 Jobs。CronJob 用於執行周期性的動作，例如備份、報告生成等。 你可以定義任務開始執行的時間間隔，這些每一個任務都應該配置為周期性重複的（例如：每天/每周/每月一次）；
CronJob 根據計劃編排，在每次該執行任務的時候大約會創建一個 Job。 之所以說 “大約”，是因為在某些情況下，可能會創建兩個 Job，或者不會創建任何 Job。 k8s 試圖使這些情況盡量少發生，但暫時還不能完全杜絕。因此，Job 應該是 冪等的。
注意：如果
startingDeadlineSeconds設置為很大的數值或未設置（默認），並且concurrencyPolicy設置為Allow，則作業將始終至少運行一次。
思考什麼場景下CronJob 無法被調度？
無法調度，第一種，startingDeadlineSeconds值低於CronJob 周期檢查時間，第二種，多次錯過調度。
如果 startingDeadlineSeconds 的設置值低於 10 秒鐘，CronJob 可能無法被調度。 因為 CronJob 控制器每 10 秒鐘執行一次檢查。
對於每個 CronJob負載來說，CronJob 檢查從上一次調度的時間點到現在所錯過了調度次數。如果錯過的調度次數超過 100 次， 那麼它就不會啟動這個任務，並記錄這個錯誤:
Cannot determine if job needs to be started.
Too many missed start time (> 100).
Set or decrease .spec.startingDeadlineSeconds or check clock skew.
需要注意的是，如果 startingDeadlineSeconds 字段非空，則控制器會統計從 startingDeadlineSeconds 設置的值到現在而不是從上一個計劃時間到現在錯過了多少次 Job。
例如，如果
startingDeadlineSeconds是200，則控制器會統計在過去 200 秒中錯過了多少次 Job。
如果未能在調度時間內創建 CronJob，則計為錯過。 例如，如果 concurrencyPolicy 被設置為 Forbid，並且當前有一個調度仍在運行的情況下， 試圖調度的 CronJob 將被計算為錯過。
例如，假設一個 CronJob 被設置為從
08:30:00開始每隔一分鐘創建一個新的 Job，並且它的startingDeadlineSeconds字段未被設置。如果 CronJob 控制器從
08:29:00到10:21:00終止運行，則該 Job 將不會啟動，因為其錯過的調度 次數超過了 100。
進一步分析
假設將 CronJob 設置為從
08:30:00開始每隔一分鐘創建一個新的 Job，並將其startingDeadlineSeconds字段設置為 200 秒。如果 CronJob 控制器恰好在與上一個示例相同的時間段（
08:29:00到10:21:00）終止運行， 則 Job 仍將從10:22:00開始。
造成這種情況的原因是控制器現在檢查在最近 200 秒（即 3 個錯過的調度）中發生了多少次錯過的 Job 調度，而不是從現在為止的最後一個調度時間開始。
這裡理解一個概念
CronJob 僅負責創建與其調度時間相匹配的 Job，而 Job 又負責管理其代表的 Pod。
Kubernetes 推薦學習書
Kubernetes權威指南PDF
鏈接://pan.baidu.com/s/11huLHJkCeIPZqSyLEoUEmQ 提取碼:sa88
k8s系列所有問題更新記錄：GitHub
