3.6 控制器——Garbage Collection（垃圾回收）和 TTL Controller

3.6 控制器——Garbage Collection（垃圾回收）

 K8S中的垃圾回收器和JVM的垃圾回收器有點類似，它將刪除那些沒有owner的對象。K8S中的某些對象是其他對象的owner（我沒有想到一個合適詞來翻譯這個owner…），在owned的對象叫做owner的dependents（也沒想好要怎麼翻譯），總之dependents是附屬於owner存在的，每個dependent的對象都有一個metadata.ownerReferences字段，用於指向它的owner，可以手動指定從屬關係。有時，K8S自動設置ownerReference，比如創建副本集ReplicaSet時，K8S將會自動設置副本集ReplicaSet中每個Pod的ownerReference。下面是一個有3個Pod的副本集ReplicaSet：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-repset
spec:
  replicas: 3
  # 指定管理哪些Pod
  selector:
    matchLabels:
      pod-is-for: garbage-collection-example
  # 創建Pod的模板
  template:
    metadata:
      labels:
        pod-is-for: garbage-collection-example
    spec:
      containers:
      - name: nginx
        image: nginx

【控制garbage collector刪除dependents】

 在刪除對象時，可以指定是否也將該對象的dependents也自動刪除（如果不刪除那dependents就變成孤兒orphaned），這種刪除行爲和數據刪除行爲一致也叫級聯刪除cascading deletion，級聯刪除有2種模式：

• foreground cascading deletion（前臺級聯刪除）：先刪除所有的dependents（這裏面又是先刪除ownerReference.blockOwnerDeletion=true的dependents），最後刪除owner；
• background cascading deletion（後臺級聯刪除）：先刪除owner，再由garbage collector在後臺刪除dependents；

 可以通過deleteOptions參數中的propagationPolicy字段控制級聯刪除的策略，它的值只能是Orphan、Foreground和Background，前者是針對不刪除dependents的情況，後兩者是針對刪除dependents的情況，默認是刪除dependents的，下面是示例：

# background cascading deletion
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"

# foreground cascading deletion
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"

# orphans dependents
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"

當然kubectl也可以用來做級聯刪除，刪除時帶上--cascade=true就是自動刪除（這也是默認值），--cascade=false就是不自動刪除orphan，比如：kubectl delete replicaset my-repset --cascade=false。

3.7 控制器——TTL Controller

 TTL控制器提供了TTL機制去限制那些已經完成執行動作的資源對象的聲明週期，TTL控制器現在僅用來處理Job，將來可能會擴展到其他完成指定動作的資源，比如Pod。集羣中可以指定Job的.spec.ttlSecondsAfterFinished的字段（即在Job做完工作後多少秒）使用TTL控制器自動清理已經完成Job（這裏的清理是級聯刪除），比如：

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  # 在完成Job後，再過100秒清理該資源
  ttlSecondsAfterFinished: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

可能用到TTL Controller的場景有：

• 在資源清單中指定此字段，以便在Job完成後的一段時間內自動清除Job；
• 在現有已完成資源的中設置此字段，以執行清理的行爲；
• 使用可變的許可webhook在資源創建時動態設置此字段。羣集管理員可以使用它對完成的資源強制執行TTL策略；
• 使用可變的許可webhook在資源完成後動態設置此字段，並根據資源狀態、標籤等選擇不同的TTL值；

注：在資源創建或執行完成後可以修改.spec.ttlSecondsAfterFinished字段，但是，一旦Job有資格被刪除（當TTL過期時），系統將無法保證Job將被保留，即使修改增大TTL的時長的請求返回成功的API響應。另外，TTL的時長是根據集羣中的時間戳來計算的，對事件非常敏感，集羣時間可能導致TTL控制器在錯誤的時間清理資源，所以如果使用TTL Controller一定要在所有節點上使用NTP命令同步機器時間。