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命令同步机器时间。