文章目录
- 前言
- 一、查看kubelet当前运行
- 1.1 查看kubelet当前运行
- 1.2 kubelet配置文件
- 1.3 kubelet启动参数文件
- 1.4 kubelet启动全过程 (自定义启动参数文件)
- 二、kubelet启动过程
- 2.1 kubelet启动过程
- 2.2 自定义kubelet所有文件并运行
- 步骤1：新建静态token文件和user，给user进行rbac授权
- 步骤2：创建配置文件 kubelet.conf
- 步骤3：创建参数文件 config.yaml
- 步骤4：创建启动x509证书 bootstrap.kubeconfig
- 步骤5：使用systemd来管理kubelet
- 步骤6：运行完成之后，这里 kubelet.conf (kubeconfig发生了改变)
- 三、kubelet定时清理磁盘镜像
- 3.1 理论
- 3.2 实践
- 镜像回收（使用docker默认 --graph 参数：/var/lib/docker）
- 镜像回收（使用自定义docker --graph 参数：/opt/docker）
- 容器回收之 --maximum-dead-containers-per-container 参数
- --maximum-dead-containers-per-container 针对容器还是容器集
- 容器回收之 --maximum-dead-containers 参数
- --maximum-dead-containers 对于非kubelet管理的容器是否计数
- 尾声
前言
kubelet所有知识点
- 查看kubelet当前运行
- systemctl status kubelet -l 搞懂所有属性 (journalctl -u kubelet.service)
- kubelet配置文件 cat /var/lib/kubelet/config.yaml
- kubelet启动参数文件 10-kubeadm.conf
- kubelet启动全过程 (自定义启动参数文件)
- kubelet和pause镜像的关系就是Pod内容器间通信
一、查看kubelet当前运行
1.1 查看kubelet当前运行
# 查看kubelet启动命令
systemctl status kubelet
# kubelet服务使用的cgroup信息
systemd-cgls --no-page | grep kubelet
# kubelet服务使用的cgroup占用的cpu和内存
systemd-cgtop | grep kubelet
systemctl status kubelet -l CGroup: /system.slice/kubelet.service # 这个进程所属的cgroup└─922 /usr/bin/kubelet # 进程号和启动shell脚本(可执行文件)--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf # kubelet启动时连接apiserver的x509客户端证书,启动后删除 --kubeconfig=/etc/kubernetes/kubelet.conf # kubelet运行时连接apiserver的 x509 客户端证书--config=/var/lib/kubelet/config.yaml # 配置文件--network-plugin=cni # cni是k8s制定的标志，各个厂商自己实现 calico flannel--pod-infra-container-image=k8s.gcr.io/pause:3.4.1 # 管理Pod网络容器的镜像，每个docker运行起来的pause和kubelet有关
1.2 kubelet配置文件
–config=/var/lib/kubelet/config.yaml
1.3 kubelet启动参数文件
kubelet 就是使用 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf 配置文件运行起来的，证据就是
systemctl status kubelet -l Drop-In: /usr/lib/systemd/system/kubelet.service.d└─10-kubeadm.conf
1.4 kubelet启动全过程 (自定义启动参数文件)
[root@m kubelet.service.d]# pwd
/usr/lib/systemd/system/kubelet.service.d[root@mkubelet.service.d]#cat 10-kubeadm.conf
#注意：此插件仅适用于kubeadm和kubelet v1.11+
【服务】
Environment=“KUBELET_KUBECONFIG_ARGS=--bootstrap KUBECONFIG=/opt/kubernetes/cfg/bootstrap.KUBECONFIG--KUBECONFIG=/opt/kubernetes/cfg/KUBELET.conf”
Environment=“KUBELET_CONFIG_ARGS=--CONFIG=/opt/kubernetes/cfg/KUBELET CONFIG.yml”#这是一个“kubeadminit”和“kubeadm join”在运行时生成的文件，动态填充KUBELET_kubeadm_ARGS变量
环境文件=-/var/lib/kubelet/kubedm-flags.env#这是一个文件，作为最后的手段，用户可以使用它来覆盖kubelet参数。用户最好使用
#而是配置文件中的.NodeRegistration.KubeltExtraArgs对象。KUBELET_EXTRA_ARGS应来源于该文件。
环境文件=-/etc/sysconfig/kubelet
执行启动=
ExecStart=/usr/bin/kubelet$kubelet_KUBECONFIG_ARGS$KUBEET_CONFIG_ARGS$kubelet_KUBEADM_ARGS$CUBLET_EXTRA_ARG
二、kubelet启动过程
2.1 kubelet启动过程
我们之前学习过 k8s 架构和证书，这个 kubelet 服务比较特殊，它在每个node上都有一个。
对于多个节点，为每个节点单独签署证书将是一件非常繁琐的事情；TLS bootstrapping 功能就是让 kubelet 先使用一个预定的低权限用户连接到 apiserver，然后向 apiserver 申请证书，kubelet 的证书由 apiserver 动态签署。所以，kubelet 启动时使用 /etc/kubernetes/bootstrap-kubelet.conf 证书，kubelet 运行时使用 /etc/kubernetes/kubelet.conf 证书。
当前的kubelet就是这样做的，我们自己手动，将整个过程做一次，就完全理解整个 kubelet 启动过程了，理解 kubelet 访问 apiserver 的 x509客户端证书了
步骤：TLS Bootstrapping ，使用 Token 时整个启动引导过程:
1、在集群内创建特定的 Bootstrap Token Secret ，该 Secret 将替代以前的 token.csv 内置用户声明文件
2、在集群内创建首次 TLS Bootstrap 申请证书的 ClusterRole、后续 renew Kubelet client/server 的 ClusterRole，以及其相关对应的 ClusterRoleBinding；并绑定到对应的组或用户
3、调整 Controller Manager 配置，以使其能自动签署相关证书和自动清理过期的 TLS Bootstrapping Token
4、生成特定的包含 TLS Bootstrapping Token 的 bootstrap.kubeconfig 以供 kubelet 启动时使用
5、调整 Kubelet 配置，使其首次启动加载 bootstrap.kubeconfig 并使用其中的 TLS Bootstrapping Token 完成首次证书申请
6、证书被 Controller Manager 签署，成功下发，Kubelet 自动重载完成引导流程
7、后续 Kubelet 自动 renew(更新) 相关证书
kubelet 涉及两个配置：kubelet配置文件 + kubelet启动参数文件
kubelet 配置文件 /var/lib/kubelet/config.yaml (地位等同于docker 的 /etc/docker/daemon.json)
kubelet 启动参数文件：systemctl status kubelet -l 可以查看kubelet启动命令
2.2 自定义kubelet所有文件并运行
步骤1：新建静态token文件和user，给user进行rbac授权
步骤2：创建配置文件 kubelet.conf
步骤3：创建参数文件 config.yaml
步骤4：创建启动x509证书
步骤5：使用systemd来管理kubelet
步骤6：运行完成之后，这里 kubelet.conf (kubeconfig发生了改变)
步骤1：新建静态token文件和user，给user进行rbac授权
步骤2：创建配置文件 kubelet.conf
新建这个 /opt/kubernetes/cfg/kubelet.conf 文件，指定 -cert-dir 为 /opt/kubernetes/ssl 目录
cat > /opt/kubernetes/cfg/kubelet.conf << EOF
KUBELET_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--hostname-override=k8s-master \\
--network-plugin=cni \\
--kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \\
--bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \\
--config=/opt/kubernetes/cfg/kubelet-config.yml \\
--cert-dir=/opt/kubernetes/ssl \\
--pod-infra-container-image=k8s.gcr.io/pause:3.4.1"
EOF
这个 KUBELET_OPTS 参数正好是在下面的 /usr/lib/systemd/system/kubelet.service 中用到，然后启动之后 /opt/kubernetes/cfg/kubelet.conf 文件就变动了
–hostname-override：显示名称，集群中唯一 【这里写成 m】
–network-plugin：启用CNI 【这里写死 cni】
–kubeconfig：空路径，会自动生成，后面用于连接apiserver 【这个文件可以为空，暂时不存在】
–bootstrap-kubeconfig：首次启动向apiserver申请证书 【这里生成的 x509客户端证书】
–config：配置参数文件 【这里指定从默认的复制过来的配置文件 config.yaml】
–cert-dir：kubelet证书生成目录 【这个mkdir新建一个目录，然后指定】
–pod-infra-container-image：管理Pod网络容器的镜像 【这个写死为 k8s.gcr.io/pause:3.4.1 没关系】
步骤3：创建参数文件 config.yaml
cat > /opt/kubernetes/cfg/kubelet-config.yml << EOF
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:anonymous:enabled: falsewebhook:cacheTTL: 0senabled: truex509:clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:mode: Webhookwebhook:cacheAuthorizedTTL: 0scacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
EOF
步骤4：创建启动x509证书 bootstrap.kubeconfig
KUBE_APISERVER="https://192.168.100.155:6443" # apiserver IP:PORT
TOKEN="14cca9b8783da4a04a90f08a9b0e98ba" # 与token.csv里保持一致# 生成 kubelet bootstrap kubeconfig 配置文件
kubectl config set-cluster kubernetes \--certificate-authority=/etc/kubernetes/pki/ca.crt \--embed-certs=true \--server=${KUBE_APISERVER} \--kubeconfig=bootstrap.kubeconfigkubectl config set-credentials "kubelet-bootstrap" \--token=${TOKEN} \--kubeconfig=bootstrap.kubeconfigkubectl config set-context default \--cluster=kubernetes \--user="kubelet-bootstrap" \--kubeconfig=bootstrap.kubeconfigkubectl config use-context default --kubeconfig=bootstrap.kubeconfig
它就会拿着bootstrap.kubeconfig向apiserver发起请求，apiserver会去验证这个token是不是可信任的 (因为user使用 静态token生成，所以是可信的)
步骤5：使用systemd来管理kubelet
/usr/lib/systemd/system
步骤6：运行完成之后，这里 kubelet.conf (kubeconfig发生了改变)
但是这个 /var/lib/kubelet/pki/ 是在哪里指定的，根据数据追本溯源法，一定有一个地方指定了这个默认目录 /var/lib/kubelet/pki/
我现在要将这个目录修改为 /opt/kubernetes/ssl 目录
这个启动 bootstrap.kubeconfg 文件没有发生改变
三、kubelet定时清理磁盘镜像
images 镜像越来越多，kubelet 自带回收机制
3.1 理论
-
Kubernetes的垃圾回收由kubelet进行管理，每分钟会查询清理一次容器，每五分钟查询清理一次镜像。在kubelet刚启动时并不会立即进行GC，即第一次进行容器回收为kubelet启动一分钟后，第一次进行镜像回收为kubelet启动五分钟后。
-
不推荐使用其它管理工具或手工进行容器和镜像的清理，因为kubelet需要通过容器来判断pod的运行状态，如果使用其它方式清除容器有可能影响kubelet的正常工作。
-
镜像的回收针对node结点上由docker管理的所有镜像，无论该镜像是否是在创建pod时pull的。而容器的回收策略只应用于通过kubelet管理的容器。
-
Kubernetes通过kubelet集成的cadvisor进行镜像的回收，有两个参数可以设置：–image-gc-high-threshold和–image-gc-low-threshold。当用于存储镜像的磁盘使用率达到百分之–image-gc-high-threshold时将触发镜像回收，删除最近最久未使用（LRU，Least Recently Used）的镜像直到磁盘使用率降为百分之–image-gc-low-threshold或无镜像可删为止。默认–image-gc-high-threshold为90，–image-gc-low-threshold为80。
-
容器的回收有三个参数可设置：–minimum-container-ttl-duration，–maximum-dead-containers-per-container和–maximum-dead-containers。从容器停止运行时起经过–minimum-container-ttl-duration时间后，该容器标记为已过期将来可以被回收（只是标记，不是回收），默认值为1m0s。一般情况下每个pod最多可以保留–maximum-dead-containers-per-container个已停止运行的容器集，默认值为2。整个node节点可以保留–maximum-dead-containers个已停止运行的容器，默认值为100。
-
如果需要关闭容器的垃圾回收策略，可以将–minimum-container-ttl-duration设为0（表示无限制），–maximum-dead-containers-per-container和–maximum-dead-containers设为负数。
-
–minimum-container-ttl-duration的值可以使用单位后缀，如h表示小时，m表示分钟，s表示秒。
-
当–maximum-dead-containers-per-container和–maximum-dead-containers冲突时，–maximum-dead-containers优先考虑。
-
对于那些由kubelet创建的但由于某些原因导致无名字（）的容器，会在到达GC时间点时被删除。
-
回收容器时，按创建时间排序，优先删除那些创建时间最早的容器。
-
到达GC时间点时，具体的GC过程如下：
- 1）遍历所有pod，使其满足–maximum-dead-containers-per-container；
- 2）经过上一步后如果不满足–maximum-dead-containers，计算值X=（–maximum-dead-containers）/（pod总数），再遍历所有pod，使其满足已停止运行的容器集个数不大于X且至少为1；
- 3）经过以上两步后如果还不满足–maximum-dead-containers，则对所有已停止的容器排序，优先删除创建时间最早的容器直到满足–maximum-dead-containers为止。
-
当某个镜像重新pull或启动某个pod用到该镜像时，该镜像的最近使用时间都会被更新。
-
Kubernetes的垃圾回收在1.1.4版本开始才渐渐完善，之前的版本存在比较多bug甚至不能发挥作用。
-
关于容器的回收需要特别注意pod的概念，比如，通过同一个yaml文件create一个pod，再delete这个pod，然后再create这个pod，此时之前的那个pod对应的容器并不会作为新创建pod的已停止容器集，因为这两个pod虽然同名，但已经不是同一个pod了。只有同一个pod中在运行过程中由于意外或其它情况停止的容器才算是这个pod的已停止容器集。
3.2 实践
镜像回收（使用docker默认 --graph 参数：/var/lib/docker）
结点上运行的docker设置的参数 --graph 使用默认的/var/lib/docker，指向/var文件系统，通过df -lh查看目前 /var 磁盘使用率为30%，启动kubelet设置镜像回收相关参数如下：
--image-gc-high-threshold=40 --image-gc-low-threshold=35
此时任意创建两个使用不同镜像的pod，在node节点上可以看到新pull了三个images（pause镜像是启动pod必需的）：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
10.11.150.76:5000/openxxs/iperf 1.2 1783511c56f8 3 months ago 279 MB
10.11.150.76:5000/centos 7 5ddf34d4d69b 8 months ago 172.2 MB
pub.domeos.org/kubernetes/pause latest f9d5de079539 20 months ago 239.8 kB
此时查看/var磁盘使用率达到了41%，然后将使用10.11.150.76:5000/centos:7镜像的pod删除，等待GC的镜像回收时间点。然而五分钟过去了，什么事情也没有发生=_=!!。还记得 docker rmi 镜像时有个前提条件是什么吗？没错，要求使用该镜像的容器都已经被删除了才可以。前面删除pod只是停止了容器，并没有将容器删除。因此手工将对应的容器docker rm掉，再等待五分钟后，可以看到镜像已经被删除回收了：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
10.11.150.76:5000/openxxs/iperf 1.2 1783511c56f8 3 months ago 279 MB
pub.domeos.org/kubernetes/pause latest f9d5de079539 20 months ago 239.8 kB
结论：只有相关联的容器都被停止并删除回收后，才能将Kubernetes的镜像垃圾回收策略应用到该镜像上。
镜像回收（使用自定义docker --graph 参数：/opt/docker）
结点上运行的docker设置的参数–graph指向 /opt 磁盘，通过 df -lh 查看目前 /opt 磁盘使用率为 48% ，启动 kubelet 设置镜像回收相关参数如下：
--image-gc-high-threshold=50 --image-gc-low-threshold=40
此时任意创建两个使用不同镜像的pod，在node节点上可以看到新pull了三个images：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
10.11.150.76:5000/openxxs/iperf 1.2 1783511c56f8 3 months ago 279 MB
10.11.150.76:5000/centos 7 5ddf34d4d69b 8 months ago 172.2 MB
pub.domeos.org/kubernetes/pause latest f9d5de079539 20 months ago 239.8 kB
此时查看/opt磁盘使用率达到了51%，然后将使用10.11.150.76:5000/centos:7镜像的pod删除，手工将对应的容器docker rm掉，等待GC的镜像回收时间点。然而五分钟过去了，十分钟过去了，docker images时centos镜像依旧顽固地坚守在阵地。
结论：目前Kubernetes的镜像垃圾回收策略可以在docker --graph 参数默认为 /var/lib/docker 时正常工作，当 --graph 设置为其它磁盘路径时还存在bug。
问题反馈在 Github 的相关 issue 里：https://github.com/kubernetes/kubernetes/issues/17994，可以继续跟进。
Append: 根据Github上的反馈，这个bug将在后续版本中解决，目前版本需要让设置了–graph的镜像垃圾回收生效，在启动kubelet时还需要加上参数 --docker-root=<docker --graph参数值>。
容器回收之 --maximum-dead-containers-per-container 参数
启动kubelet设置容器回收相关参数如下：
--maximum-dead-containers-per-container=1
--minimum-container-ttl-duration=30s
--maximum-dead-containers=100
创建一个只包含一个容器且该容器一运行就退出的pod，此时在node节点上可以看到该pod中的容器不断的创建退出创建退出：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2fe969499164 10.11.150.76:5000/centos:7 "/bin/bash" 4 seconds ago Exited (0) 2 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_68cc6f03
555b5e7a8550 10.11.150.76:5000/centos:7 "/bin/bash" 24 seconds ago Exited (0) 22 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_ad4a5e39
94b30a0b32c2 10.11.150.76:5000/centos:7 "/bin/bash" 34 seconds ago Exited (0) 32 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_4027e3e1
d458e6a7d396 pub.domeos.org/kubernetes/pause:latest "/pause" 34 seconds ago Up 33 seconds k8s_POD.bdb2e1f5_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_09798975
GC的容器回收时间点到达时，可以看到创建时间大于30秒的已退出容器只剩下一个（pause容器不计算），且先创建的容器被优先删除：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5aae6157aeff 10.11.150.76:5000/centos:7 "/bin/bash" 46 seconds ago Exited (0) 45 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_f126d2a8
d458e6a7d396 pub.domeos.org/kubernetes/pause:latest "/pause" 2 minutes ago Up 2 minutes k8s_POD.bdb2e1f5_test-gc-pod-exit_default_92e8bd05-e9e6-11e5-974c-782bcb2a316a_09798975
结论：Kubernetes容器垃圾回收的–maximum-dead-containers-per-container参数设置可正常工作。
–maximum-dead-containers-per-container 针对容器还是容器集
启动kubelet设置容器回收相关参数如下：
--maximum-dead-containers-per-container=1
--minimum-container-ttl-duration=30s
--maximum-dead-containers=100
创建一个包含三个容器且这些容器一运行就退出的pod，此时在node节点上可以看到该pod中的容器不断的创建退出创建退出：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
dec04bd28a03 10.11.150.76:5000/centos:7 "/bin/bash" 7 seconds ago Exited (0) 6 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_830a9375
7c94d4a963a7 10.11.150.76:5000/centos:7 "/bin/bash" 7 seconds ago Exited (0) 6 seconds ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_975d44d3
4f3e7e8ddfd5 10.11.150.76:5000/centos:7 "/bin/bash" 8 seconds ago Exited (0) 7 seconds ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_d024eb06
cb48cf2ba133 10.11.150.76:5000/centos:7 "/bin/bash" 12 seconds ago Exited (0) 11 seconds ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_b5ff7373
ec2941f046f0 10.11.150.76:5000/centos:7 "/bin/bash" 13 seconds ago Exited (0) 12 seconds ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_69b1a996
f831e8ed5687 10.11.150.76:5000/centos:7 "/bin/bash" 13 seconds ago Exited (0) 12 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_fbc02e2e
ee972a4537fc pub.domeos.org/kubernetes/pause:latest "/pause" 14 seconds ago Up 13 seconds k8s_POD.bdb2e1f5_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_85b3c032
GC的容器回收时间点到达时，可以看到创建时间大于30秒的已退出容器剩下三个（pause容器不计算），且这三个容器正好是一组：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e4351e6855ae 10.11.150.76:5000/centos:7 "/bin/bash" 51 seconds ago Exited (0) 50 seconds ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_263dd820
990baa6e6a7a 10.11.150.76:5000/centos:7 "/bin/bash" 52 seconds ago Exited (0) 51 seconds ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_b16b5eaa
c6916fb06d65 10.11.150.76:5000/centos:7 "/bin/bash" 53 seconds ago Exited (0) 51 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_1d8ea284
ee972a4537fc pub.domeos.org/kubernetes/pause:latest "/pause" About a minute ago Up About a minute k8s_POD.bdb2e1f5_test-gc-pod-exit_default_d1677c09-e9e7-11e5-974c-782bcb2a316a_85b3c032
结论：–maximum-dead-containers-per-container 的计数针对一个pod内的容器集而不是容器的个数。
容器回收之 --maximum-dead-containers 参数
启动kubelet设置容器回收相关参数如下：
--maximum-dead-containers-per-container=2
--minimum-container-ttl-duration=30s
--maximum-dead-containers=3
创建一个包含三个容器的pod，再删除该pod，再创建该pod，再删除该pod，这样就产生了8个已退出容器（包括两个pause容器）：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a28625d189df 10.11.150.76:5000/centos:7 "/bin/bash" 1 seconds ago Exited (0) Less than a second ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_48c11200
97aca44f0deb 10.11.150.76:5000/centos:7 "/bin/bash" 2 seconds ago Exited (0) 1 seconds ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_df34f48d
4e57b6c839ae 10.11.150.76:5000/centos:7 "/bin/bash" 3 seconds ago Exited (0) 2 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_afd622b2
12588fce1433 pub.domeos.org/kubernetes/pause:latest "/pause" 3 seconds ago Exited (2) Less than a second ago k8s_POD.bdb2e1f5_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_c9d4cbaa
621ed207d452 10.11.150.76:5000/centos:7 "/bin/bash" 4 seconds ago Exited (0) 3 seconds ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_c5cbddbb-e9ee-11e5-974c-782bcb2a316a_a91278cd
023c10fad4fd 10.11.150.76:5000/centos:7 "/bin/bash" 5 seconds ago Exited (0) 4 seconds ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_c5cbddbb-e9ee-11e5-974c-782bcb2a316a_6cc03f37
756eb7bb4b53 10.11.150.76:5000/centos:7 "/bin/bash" 5 seconds ago Exited (0) 4 seconds ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_c5cbddbb-e9ee-11e5-974c-782bcb2a316a_83312ec2
d54bdc22773e pub.domeos.org/kubernetes/pause:latest "/pause" 6 seconds ago Exited (2) 3 seconds ago k8s_POD.bdb2e1f5_test-gc-pod-exit_default_c5cbddbb-e9ee-11e5-974c-782bcb2a316a_ccb57220
GC的容器回收时间点到达时，可以看到已退出容器只剩下了三个，pause容器也被回收了：
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a28625d189df 10.11.150.76:5000/centos:7 "/bin/bash" 2 minutes ago Exited (0) 2 minutes ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_48c11200
97aca44f0deb 10.11.150.76:5000/centos:7 "/bin/bash" 2 minutes ago Exited (0) 2 minutes ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_df34f48d
4e57b6c839ae 10.11.150.76:5000/centos:7 "/bin/bash" 2 minutes ago Exited (0) 2 minutes ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_afd622b2
结论：Kubernetes容器垃圾回收的 --maximum-dead-containers参数设置可正常工作；pause容器也作为可回收容器被管理着；Tips第11条第3）点。
–maximum-dead-containers 对于非kubelet管理的容器是否计数
在第5个实验的基础上，手工创建一个container，等待GC的容器回收时间点到达，一分钟过去了，两分钟过去了，docker ps -a 显示的依然是4个容器：
$ docker run -it 10.11.150.76:5000/openxxs/iperf:1.2 /bin/sh
sh-4.2# exit
exit$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
939b932dc7db 10.11.150.76:5000/openxxs/iperf:1.2 "/bin/sh" 2 minutes ago Exited (0) 2 minutes ago backstabbing_aryabhata
a28625d189df 10.11.150.76:5000/centos:7 "/bin/bash" 12 minutes ago Exited (0) 12 minutes ago k8s_iperf3.5c8de29f_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_48c11200
97aca44f0deb 10.11.150.76:5000/centos:7 "/bin/bash" 12 minutes ago Exited (0) 12 minutes ago k8s_iperf2.5a36e29e_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_df34f48d
4e57b6c839ae 10.11.150.76:5000/centos:7 "/bin/bash" 12 minutes ago Exited (0) 12 minutes ago k8s_iperf1.57dfe29d_test-gc-pod-exit_default_c7612b59-e9ee-11e5-974c-782bcb2a316a_afd622b2
结论：Kubernetes容器垃圾回收的策略不适用于非kubelet管理的容器。
尾声
kubelet服务全解析，完！
参考资料：Kubelet Bootstrap 机制 APIServer基于引导token认证
kubelet定时清除磁盘镜像
