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
鏈接:https://pan.baidu.com/s/11huLHJkCeIPZqSyLEoUEmQ 提取碼:sa88
k8s系列所有問題更新記錄：GitHub
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/455415.html
標籤：其他