前言
kubelet所有知識點
- 查看kubelet當前運行
- 查看kubelet當前運行(啟動文件10-kubeadm.conf)
- kubelet使用的kubeconfig
- kubelet使用的配置文件
- kubelet使用的環(huán)境變量文件
- kubelet使用的額外參數(shù)
- kubelet啟動全過程 (自定義啟動參數(shù)文件)
- kubelet和pause鏡像的關系就是Pod內容器間通信
一、查看kubelet當前運行
1.1 查看kubelet當前運行(啟動文件10-kubeadm.conf)
# 查看kubelet啟動命令
systemctl status kubelet
# kubelet服務使用的cgroup信息
systemd-cgls --no-page | grep kubelet
# kubelet服務使用的cgroup占用的cpu和內存
systemd-cgtop | grep kubelet
systemctl status kubelet 可以查看到 kubelet 服務的啟動命令
systemctl status kubelet -l
CGroup: /system.slice/kubelet.service # 這個進程所屬的cgroup
└─922 /usr/bin/kubelet # 進程號和啟動shell腳本(可執(zhí)行文件)
--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制定的標志，各個廠商自己實現(xiàn) calico flannel
--pod-infra-container-image=k8s.gcr.io/pause:3.4.1 # 管理Pod網(wǎng)絡容器的鏡像，每個docker運行起來的pause和kubelet有關
systemctl status kubelet 可以查看到 kubelet 服務的啟動文件
systemctl status kubelet -l
Drop-In: /usr/lib/systemd/system/kubelet.service.d
└─10-kubeadm.conf
所有，kubelet 就是使用 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf 文件啟動的，這個文件是 kubelet 啟動的源頭，其他所有的都是在這個文件中引用的，這個 10-kubeadm.conf 文件包括五行：
(1) 第一行，當前 kubelet 使用的 kubeconfig /etc/kubernetes/kubelet.conf $KUBELET_KUBECONFIG_ARGS
(2) 第二行，當前 kubelet 使用的 配置文件 /var/lib/kubelet/config.yaml $KUBELET_CONFIG_ARGS
(3) 第三行，當前 kubelet 使用的 環(huán)境變量文件 /var/lib/kubelet/kubeadm-flags.env $KUBELET_KUBEADM_ARGS
(4) 第四行，當前 kubelet 使用的 額外參數(shù) $KUBELET_EXTRA_ARGS
(5) 第五行，啟動命令，后面前面四行的參數(shù)，也就是 systemctl status kubelet 看到的 /usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
[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+
【服務】
# (1) 第一個參數(shù) kubeconfig KUBELET_KUBECONFIG_ARGS
# (2) 第二個參數(shù) config KUBELET_CONFIG_ARGS
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”
# (3) 第三個參數(shù) 環(huán)境變量kubedm-flags.env KUBELET_KUBEADM_ARGS
#這是一個“kubeadminit”和“kubeadm join”在運行時生成的文件，會動態(tài)填充KUBELET_kubeadm_ARGS參數(shù)
環(huán)境文件=-/var/lib/kubelet/kubeadm-flags.env
# (4) 第四個參數(shù) 額外參數(shù)可以覆蓋之前的 KUBELET_EXTRA_ARGS
#這是一個文件，作為最后的手段，用戶可以使用它來覆蓋kubelet參數(shù)，用戶最好使用。
#而是配置文件中的.NodeRegistration.KubeltExtraArgs對象，KUBELET_EXTRA_ARGS參數(shù)應來源于該文件。
環(huán)境文件=-/etc/sysconfig/kubelet
# (5) 啟動命令，使用前面四個參數(shù)，就是systemct status kubelet看到的啟動命令
執(zhí)行啟動=
ExecStart=/usr/bin/kubelet $kubelet_KUBECONFIG_ARGS $KUBEET_CONFIG_ARGS $kubelet_KUBEADM_ARGS $CUBLET_EXTRA_ARG
1.2 kubelet使用的kubeconfig
# (1) kubelet啟動的時候，連接apiserver使用bootstrap-kubelet.conf，但是啟動完成后就被刪除了
--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
# (2) kubelet穩(wěn)定運行的時候，連接apiserver使用kubelet.conf，這個可以在宿主機中被查看到
--kubeconfig=/etc/kubernetes/kubelet.conf
kubelet.conf 文件是用于 kubelet 訪問 apsierver ，其實 apiserver 也需要訪問 kubelet ，兩者需要相互訪問。
apiserver 訪問 kubelet 需要雙向認證(客戶端認證服務端，服務端也認證客戶端)，其證書包括：
apiserver作為客戶端 /etc/kubernetes/pki 目錄下 apiserver-kubelet-client.key apiserver-kubelet-client.crt
kubelet作為服務端 /var/lib/kubelet/pki 目錄下的 kubelet.key 和 kubelet.crt
kubelet 訪問 apiserver 也需要雙向認證(客戶端認證服務端，服務端也認證客戶端)，其證書包括：
apiserver作為服務端 /etc/kubernetes/pki 目錄下 apsierver.key apiserver.crt
kubelet作為客戶端 /var/lib/kubelet/pki 目錄下的 kubelet-client-current.pem 和 /etc/kubernetes/kubelet.conf
那么, kubelet 訪問 apiserver 的時候 ，kubelet作為客戶端 /var/lib/kubelet/pki 目錄下的 kubelet-client-current.pem 和 /etc/kubernetes/kubelet.conf 兩個文件有什么關系？
回答：本質是一樣的。
cd /var/lib/kubelet/pki
openssl x509 -in kubelet-client-current.pem -out client.crt
openssl rsa -in kubelet-client-current.pem -out client.key
openssl x509 -in client.crt -noout -text
openssl rsa -in client.key -noout -text
cd /etc/kubernetes
cat kubelet.conf # 查看kubelet訪問apiserver的x509證書
echo "xxx" | base64 --decode > client.crt
echo "xxx" | base64 --decode > client.key
openssl x509 -in client.crt -noout -text
openssl rsa -in client.key -noout -text
cd /etc/kubernetes
cat kubelet.conf # 查看kubelet訪問apiserver的x509證書
x509證書本質就是集群cluster和用戶user的關聯(lián)關系，集群cluster的ca.crt 表示操作哪個機器，用戶user 通過 證書和密鑰 crt/key 完成認證集群，再通過 user/userGroup - rolebinding/clusterrolebinding - role/clusterrole 完成授權集群的資源操作
echo “xxx” | base64 --decode > client.crt
echo “xxx” | base64 --decode > client.key
openssl x509 -in client.crt -noout -text
1.3 kubelet使用的配置文件
在使用systemctl status kubelet 查看到的啟動命令中，指定了 kubelet 的配置文件，即 --config=/var/lib/kubelet/config.yaml ，看一下這個文件
cat var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1 # 包名:類似java中的package
authentication: # 認證
anonymous:
enabled: false
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization: # 授權
mode: Webhook
webhook:
cacheAuthorizedTTL: 0s
cacheUnauthorizedTTL: 0s
# controller group 驅動，包括cgroupf和systemd兩種，kubelet的cgroup驅動需要和docker的cgroup驅動保持一致
cgroupDriver: systemd
# 域名解析兩個字段
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
# 健康檢查地址和端口
healthzBindAddress: 127.0.0.1
healthzPort: 10248
kind: KubeletConfiguration # 資源類型 KubeletConfiguration
logging: {}
staticPodPath: /etc/kubernetes/manifests # 靜態(tài)Pod yaml所在路徑
# 各種超時時間(了解即可)
# 默認值：10s，設置 CPU 管理器的調和時間。例如：10s 或者 1m。 如果未設置，默認使用節(jié)點狀態(tài)更新頻率。
cpuManagerReconcilePeriod: 0s
# 默認值：5m0s, kubelet 在驅逐壓力狀況解除之前的最長等待時間。
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s # 默認值：20s，檢查配置文件中新數(shù)據(jù)的時間間隔。
httpCheckFrequency: 0s # 默認值：20s，HTTP 服務以獲取新數(shù)據(jù)的時間間隔。
imageMinimumGCAge: 0s
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s # 默認值：10s，指定 kubelet 向主控節(jié)點匯報節(jié)點狀態(tài)的時間間隔。
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s # 默認值：1m0s，指定 kubelet 計算和緩存所有 Pod 和卷的磁盤用量總值的時間間隔。要禁用磁盤用量計算， 可設置為 0。
域名解析兩個字段
–cluster-dns strings
DNS 服務器的 IP 地址，以逗號分隔。此標志值用于 Pod 中設置了 “dnsPolicy=ClusterFirst” 時為容器提供 DNS 服務。
注意:：列表中出現(xiàn)的所有 DNS 服務器必須包含相同的記錄組， 否則集群中的名稱解析可能無法正常工作。至于名稱解析過程中會牽涉到哪些 DNS 服務器， 這一點無法保證。 （已棄用：應在 --config 所給的配置文件中進行設置。 請參閱 kubelet-config-file 了解更多信息。）
–cluster-domain string
集群的域名。如果設置了此值，kubelet 除了將主機的搜索域配置到所有容器之外，還會為其 配置所搜這里指定的域名。 （已棄用：應在 --config 所給的配置文件中進行設置。 請參閱 kubelet-config-file 了解更多信息。）
參考文件：k8s官網(wǎng)中的配置文件
k8s官網(wǎng)中的kubelet參數(shù)列表
注意：配置文件必須是這個結構體中參數(shù)的 JSON 或 YAML 表現(xiàn)形式，才能確保 kubelet 可以讀取該文件。
1.4 kubelet使用的環(huán)境變量文件
環(huán)境變量文件的定義和使用
-network-plugin=cni表示使用CNI（Container Network Interface）網(wǎng)絡插件來為Kubernetes集群中的Pod分配IP地址，實現(xiàn)Pod之間和Pod與外部網(wǎng)絡的通信。
–pod-infra-container-image=k8s.gcr.io/pause:3.4.1表示指定Pod的基礎設施容器鏡像，這個容器鏡像通常是一個無狀態(tài)的容器，它負責在Pod的生命周期中一直運行，為Pod提供必要的基礎服務，比如網(wǎng)絡、存儲等。Pause鏡像（k8s.gcr.io/pause）是Kubernetes默認提供的Pod基礎設施容器，它只是簡單地暫停運行，在容器中不做任何操作，以達到占用資源最小的目的。在Kubernetes中，每個Pod都有一個Pause容器，它與其他容器共享網(wǎng)絡命名空間和存儲空間，從而實現(xiàn)通信和數(shù)據(jù)共享。這個鏡像的版本號（3.4.1）表示鏡像的版本，Kubernetes使用版本號來管理鏡像的更新和回滾。
kubelet 的 環(huán)境變量文件中指定網(wǎng)絡插件使用cni插件，基礎設施容器鏡像使用pause鏡像，那么kubelet服務、 cni插件、 pause容器 三者之間的關系是什么？
Kubelet是Kubernetes系統(tǒng)的一個核心組件，它運行在每個節(jié)點上，負責管理該節(jié)點上的Pod生命周期和容器運行狀態(tài)等，同時也是進行網(wǎng)絡插件和Pod基礎設施容器管理的組件之一。
CNI（Container Network Interface）則是一種網(wǎng)絡插件標準，它定義了一組API和插件規(guī)范，用于實現(xiàn)網(wǎng)絡插件和容器運行時的集成。Kubernetes中的CNI插件負責為Pod分配IP地址和引導網(wǎng)絡流設置等，在Kubernetes的網(wǎng)絡模型中起到了重要的作用。
而Pause容器是Kubenetes系統(tǒng)中的一個特殊的Pod基礎設施容器，它在每個Pod中都存在，主要負責暫停容器進程，從而實現(xiàn)對該Pod內的容器進行共享網(wǎng)絡和共享存儲空間。Pause容器的鏡像通常是一個輕量級的鏡像，比如官方提供的k8s.gcr.io/pause鏡像。
總的來說，kubelet、CNI和Pause容器是Kubernetes系統(tǒng)中協(xié)同工作的三個關鍵組件，Kubelet和CNI負責實現(xiàn)網(wǎng)絡插件和Pod基礎設施容器的管理，而Pause容器則為Pod內部運行的容器提供了必要的基礎設施支持。通過這三者的協(xié)同工作，Kubernetes系統(tǒng)可以實現(xiàn)靈活可靠的容器編排和運行。
三者的本質：
kubelet 本質是Linux上的一個服務，它作為一個服務是通過運行 /usr/bin/kubelet 二進制文件運行起來，它作為一個服務運行起來可以通過 systemctl status kubelet -l 查看；
cni 全名 container network interface 容器網(wǎng)絡接口，本質是 k8s 定義的一個標準(類似SPI,交給廠商實現(xiàn))，實現(xiàn)了這個 cni 標準的插件就是 cni 插件，使用完成k8s Pod之間網(wǎng)絡通信（包括同一個節(jié)點和不同節(jié)點），常見的如 calico flannel ；
pause 本質是一個docker容器，通過鏡像啟動起來的容器。
三者的作用(和聯(lián)系)：
kubelet 是一個k8s的服務，是k8s用來管理每個node的(當一個虛擬機被納管到k8s集群，就變成了一個node)，比如說，后面可以看到，kubelet 還可以定時清理磁盤上的鏡像，避免磁盤空間占滿，所以說，kubelet服務是k8s用來管理每個node的。既然 kubelet 服務用來管理 node，但是每個 pod 都是放在 node 上的，那么 pod 之間如何通信呢？在 kubelet 環(huán)境變量文件中有一個 -network-plugin=cni 參數(shù)，用來指定運行在 node 上的pod使用 cni 標準通信，但是 cni 插件需要 kubeadm 安裝好k8s集群之后，額外安裝，一般使用 calico，即安裝完 k8s 機器之后，額外安裝 calico 插件(Calico通常也使用Pod運行)。另外，對于每個 業(yè)務Pod 之間的Container，由于不同 container 使用不同 network namespace 網(wǎng)絡命名空間，所以網(wǎng)絡之間是隔離的，應該如何網(wǎng)絡通信呢？答案是只要這個業(yè)務Pod運行的Node上，kubelet會管理運行在Node上的每個Pod，給一個Pod中添加一個 pause 容器，這個pause用來完成Pod之間不同container之間的網(wǎng)絡通信。這個 pause 容器并不寫在業(yè)務Pod的yaml文件中，對于業(yè)務Pod編寫人員是不感知的，透明的。
總而言之，kubelet 管理每個Node，對于運行在Node上的Pod，kubelet 通過要求使用 cni 插件，實現(xiàn)不同Pod之間的網(wǎng)絡通信，再通過給每個Pod里面添加一個pause容器，實現(xiàn)同一個Pod內部不同Container之間的通信。實現(xiàn)打通整個內部網(wǎng)絡。
1.5 kubelet使用的額外參數(shù)
這里沒有被定義，也沒有參數(shù)被使用，通過 systemctl status kubelet -l 查看到，當前 kubelet 服務運行起來，僅使用到了前三個參數(shù)，沒有使用第四個額外參數(shù)。
二、kubelet啟動過程
了解了 kubelet 啟動四個參數(shù)之后，繼續(xù)來看看 kubelet 啟動過程。
2.1 kubelet啟動過程
對于 k8s 整個架構和所有證書，這個 kubelet 服務比較特殊，它在每個node上都有一個。
對于多個節(jié)點，為每個節(jié)點單獨簽署證書將是一件非常繁瑣的事情；TLS bootstrapping 功能就是讓 kubelet 先使用一個預定的低權限用戶連接到 apiserver，然后向 apiserver 申請證書，kubelet 的證書由 apiserver 動態(tài)簽署。所以，kubelet 啟動時使用 /etc/kubernetes/bootstrap-kubelet.conf 證書，kubelet 運行時使用 /etc/kubernetes/kubelet.conf 證書。
當前的kubelet就是這樣做的，我們自己手動，將整個過程做一次，就完全理解整個 kubelet 啟動過程了，理解 kubelet 訪問 apiserver 的 x509客戶端證書了
步驟：TLS Bootstrapping ，使用 Token 時整個啟動引導過程:
(1) 認證：在集群內創(chuàng)建特定的 Bootstrap Token Secret ，該 Secret 將替代以前的 token.csv 內置用戶聲明文件
(2) 授權：在集群內創(chuàng)建首次 TLS Bootstrap 申請證書的 ClusterRole、后續(xù) 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 簽署，成功下發(fā)，Kubelet 自動重載完成引導流程
(7) 證書：后續(xù) Kubelet 自動 renew(更新) 相關證書
kubeadm部署的如下所示：
-bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf
–config=/var/lib/kubelet/config.yaml --network-plugin=cni
–pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.2
啟用 TLS Bootstrapping 機制
TLS Bootstraping：Master apiserver啟用TLS認證后，Node節(jié)點kubelet和kube-proxy要與kube-apiserver進行通信，必須使用CA簽發(fā)的有效證書才可以，當Node節(jié)點很多時，這種客戶端證書頒發(fā)需要大量工作，同樣也會增加集群擴展復雜度。
為了簡化流程，Kubernetes引入了TLS bootstraping機制來自動頒發(fā)客戶端證書，kubelet會以一個低權限用戶自動向apiserver申請證書，kubelet的證書由apiserver動態(tài)簽署。
所以強烈建議在Node上使用這種方式，目前主要用于kubelet，kube-proxy還是由我們統(tǒng)一頒發(fā)一個證書。（當機器越來越多的時候，手動的為kubelet頒發(fā)證書，還是比較麻煩的，應用這個機制就是為自動的為kubelet頒發(fā)證書）
TLS bootstraping 工作流程：
2.2 自定義kubelet所有文件并運行
步驟1：新建kubelet需要的user，給user進行rbac授權
步驟2：創(chuàng)建啟動參數(shù)文件 kubelet.conf
步驟3：創(chuàng)建配置文件 kubelet-config.yaml
步驟4：創(chuàng)建啟動x509證書 bootstrap.kubeconfig
步驟5：使用systemd來管理kubelet
步驟6：運行完成之后，這里 kubelet.conf (kubeconfig發(fā)生了改變)
步驟1：新建kubelet需要的user，給user進行rbac授權
新建kubelet需要的user，給user進行rbac授權，等一下自定義的
# 認證
# (1) 新建靜態(tài)token文件
mkdir -p /etc/kubernetes/cfg
cat > /opt/kubernetes/cfg/token.csv << EOF
c47ffb939f5ca36231d9e3121a252940,kubelet-bootstrap,10001,"system:node-bootstrapper"
EOF
# (2) 查看剛剛新建好的靜態(tài)token文件 token.csv
cd /etc/kubernetes/cfg
ll # 看到剛剛新建好的token.csv
# 授權
# (1) 新建binding，給剛剛新建的用戶kubelet-bootstrap授權，綁定role
kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper \
--user=kubelet-bootstrap
# (2) 查看新建的binding
kubectl get clusterrolebinding -o wide -A | grep kubelet-bootstrap
步驟2：創(chuàng)建啟動參數(shù)文件 kubelet.conf
新建這個 /opt/kubernetes/cfg/kubelet.conf 文件，這個文件里面定義了一個 KUBELET_OPTS 參數(shù)
cat > /opt/kubernetes/cfg/kubelet.conf << EOF
KUBELET_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--hostname-override=k8s-master \\
--config=/opt/kubernetes/cfg/kubelet-config.yml \\ # 這個配置文件這里引用，下面會自己定義的
--kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \\ # 這個kubeconfig這里引用，啟動后會自己在該目錄下生成的
--bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \\ # 這個kubeconfig這里引用，下面會定義的
--cert-dir=/opt/kubernetes/ssl \\
--network-plugin=cni \\
--pod-infra-container-image=k8s.gcr.io/pause:3.4.1"
EOF
這個 KUBELET_OPTS 參數(shù)正好是在下面的 /usr/lib/systemd/system/kubelet.service 中用到，然后啟動之后 /opt/kubernetes/cfg/kubelet.conf 文件就變動了
原生的kubelet啟動需要一個啟動參數(shù)文件和三個文件：
啟動文件：10-kubeadm.conf
三個文件：kubeconfig config.yaml kubeadm-flags.env
這里寫的是自定義啟動文件，啟動文件中引用三個文件，實際上是兩個 kubeconfig 和一個config.yaml ,這里啟動參數(shù)文件中引用了，下面會定義的，否則自定義的kubelet無法正常啟動。
–bootstrap-kubeconfig：首次啟動向apiserver申請證書 【這里生成的 x509客戶端證書】 【kubeconfig】
–kubeconfig：空路徑，會自動生成，后面用于連接apiserver 【這個文件可以為空，暫時不存在】 【kubeconfig】
–config：配置參數(shù)文件 【這里指定從默認的復制過來的配置文件 config.yaml】 【此為config配置文件】
–hostname-override：顯示名稱，集群中唯一 【這里寫成 m】
–cert-dir：kubelet證書生成目錄為 /opt/kubernetes/ssl 【這個mkdir新建一個目錄，然后指定】
–network-plugin：啟用CNI 【這里寫死 cni】
–pod-infra-container-image：管理Pod網(wǎng)絡容器的鏡像 【這個寫死為 k8s.gcr.io/pause:3.4.1 沒關系】
步驟3：創(chuàng)建配置文件 kubelet-config.yaml
原生的kubelet啟動需要一個啟動參數(shù)文件和三個文件：
啟動參數(shù)文件：10-kubeadm.conf
三個文件：kubeconfig config.yaml kubeadm-flags.env
自定義的kubelet啟動使用了一個啟動參數(shù)文件，里面引用了兩個kubeconfig和一個config.yaml，這里新建定義配置文件 config.yaml (這個config.yaml是給啟動參數(shù)文件使用的)
cd /opt/kubernetes/cfg
cat > /opt/kubernetes/cfg/kubelet-config.yml << EOF
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
mode: Webhook
webhook:
cacheAuthorizedTTL: 0s
cacheUnauthorizedTTL: 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
現(xiàn)在 /opt/kubernetes/cfg 目錄下有三個文件了，如下：
步驟4：創(chuàng)建啟動x509證書 bootstrap.kubeconfig
原生的kubelet需要一個啟動參數(shù)文件和三個文件，分別是 config.yaml 配置文件、kubeconfig 用來連接apiserver、環(huán)境變量文件
自定義的kubelet使用了一個啟動參數(shù)文件，里面引用了兩個kubeconfig和一個config.yaml配置文件，這里介紹新建 bootstrap.kubeconfig 文件。
編寫一個start.sh腳本，用來生成自定義kubelet啟動，所需要的 bootstrap.kubeconfig 文件（為了解決，當kubelet很多的時候，為了避免手動頒發(fā)證書，引入tls機制，能夠自動的為將要加入集群的node頒發(fā)證書。所有kubelet要鏈接apiserver都需要證書，要不然使用手簽，要不然使用tls，這里使用tls，使用這個文件去連接apiserver，然后頒發(fā)證書，加入集群。）
cd /opt/kubernetes/cfg
vi start.sh
# 定義變量
KUBE_APISERVER="https://192.168.100.155:6443" # apiserver IP:PORT
TOKEN="14cca9b8783da4a04a90f08a9b0e98ba" # 與token.csv里保持一致
# 生成 kubelet bootstrap kubeconfig 中的 cluster 字段，名為 kubernetes
kubectl config set-cluster kubernetes \ # 輸出：設置生成的集群cluster名為 kubernetes
--certificate-authority=/etc/kubernetes/pki/ca.crt \ # 輸入：指定集群的ca證書
--embed-certs=true \ # 輸入：密鑰文件和證書文件中內嵌 TLS 證書, 而不是放到目錄里面
--server=${KUBE_APISERVER} \ # 輸入：指定集群IP
--kubeconfig=bootstrap.kubeconfig # 輸出結果到bootstrap.kubeconfig文件中
# 生成 kubelet bootstrap kubeconfig 中的 user 字段，名為 kubelet-bootstrap
kubectl config set-credentials "kubelet-bootstrap" \ # 輸出：設置生成的名為 default
--token=${TOKEN} \ # 輸入：設置token
--kubeconfig=bootstrap.kubeconfig # 輸出結果到bootstrap.kubeconfig文件中
# 生成 kubelet bootstrap kubeconfig 中的 context 上下文字段，名為 default
kubectl config set-context default \ # 輸出：設置生成的上下文context名為 default
--cluster=kubernetes \ # 輸入：使用名為 kubernetes 的集群cluster
--user="kubelet-bootstrap" \ # 輸入：使用名為 kubelet-bootstrap 的用戶user
--kubeconfig=bootstrap.kubeconfig # 輸出：輸出結果到bootstrap.kubeconfig文件中
# 設置使用 kubelet bootstrap kubeconfig 中的 context 上下文字段
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
當指定 embed-certs=true 時，Kubernetes 將會在密鑰文件和證書文件中內嵌 TLS 證書，而不是將它們存儲在 kube-apiserver 運行環(huán)境的相應目錄中。這意味著在 API Server API Server 啟動時，它將從內嵌證書文件中讀取和配置TLS證書與密鑰。使用 embed-certs 可以確保密鑰和證書不被意外的替換或刪除，提高 Kubernetes API Server 的安全性。
chmod 777 start.sh
./start.sh
ll # 多了一個bootstrap.kubeconfig
cat bootstrap.kubeconfig
它就會拿著bootstrap.kubeconfig向apiserver發(fā)起請求，apiserver會去驗證這個token是不是可信任的 (因為user使用 靜態(tài)token生成，所以是可信的)
步驟5：使用systemd來管理kubelet
好了，現(xiàn)在整個自定義kubelet都已經(jīng)準備好了，就等啟動運行了，這里將使用systemd來管理kubelet，然后使用 systemctl restatt kubelet 來啟動整個服務。
# (1) 使用systemd來管理kubelet
cd /usr/lib/systemd/system
cat kubelet.service
vi kubelet.service
增加一行 EnvironmentFile=/opt/kubernetes/cfg/kubelet.conf ,這個文件定義了 $KUBELET_OPT 變量
修改一行 ExecStart=/usr/bin/kubelet ,后面加上 $KUBELET_OPT, ,這個文件使用了 $KUBELET_OPT 變量
# (2) 使用systemctl restart kubelet 運行自定義的kubelet服務
systemctl restart kubelet
使用systemd來管理kubelet：進入/usr/lib/systemd/system目錄，這里有一個kubelet.service,使用 systemctl restart kubelet 就是操作這個目錄下的kubelet.service服務，而這個kubelet.service服務，又恰好是指向 /usr/bin/kubelet 二進制文件，所以就實現(xiàn)了使用systemd來管理kubelet。
步驟6：運行完成之后，這里 kubelet.conf (kubeconfig發(fā)生了改變)
使用 systemctl restart kubelet 啟動服務之后，發(fā)現(xiàn) /etc/kubernetes/cfg 目錄下多了一個 kubelet.conf 文件，這是因為自定義kubelet的啟動參數(shù)文件有一句 --kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig ，這個參數(shù)指定kubelet啟動后會自己在該目錄下生成kubeconfig，所以就有了這個
但是上圖這個文件中的紅框中的 /var/lib/kubelet/pki/ 是在哪里指定的，根據(jù)數(shù)據(jù)追本溯源法，一定有一個地方指定了這個默認目錄 /var/lib/kubelet/pki/ , 這個目錄沒有指定缺省就是這樣 /var/lib/kubelet/pki .
無論是默認的kubelet，還是自定義的kubelet，都是這樣 /var/lib/kubelet/pki .
三、kubelet定時清理磁盤鏡像
kubelet 是k8s的系統(tǒng)服務，是用來管理 k8s node 的(如果一個虛擬機被k8s納管，就變成了一個k8s node)，node上的 images 鏡像越來越多有占滿磁盤的風險怎么辦，kubelet 作為管理node上的服務，有自帶的回收機制。
3.1 理論
-
Kubernetes的垃圾回收由kubelet進行管理，每分鐘會查詢清理一次容器，每五分鐘查詢清理一次鏡像。在kubelet剛啟動時并不會立即進行GC，即第一次進行容器回收為kubelet啟動一分鐘后，第一次進行鏡像回收為kubelet啟動五分鐘后。
-
不推薦使用其它管理工具或手工進行容器和鏡像的清理，因為kubelet需要通過容器來判斷pod的運行狀態(tài)，如果使用其它方式清除容器有可能影響kubelet的正常工作。
-
鏡像的回收針對node結點上由docker管理的所有鏡像，無論該鏡像是否是在創(chuàng)建pod時pull的。而容器的回收策略只應用于通過kubelet管理的容器。
-
Kubernetes通過kubelet集成的cadvisor進行鏡像的回收，有兩個參數(shù)可以設置：–image-gc-high-threshold和–image-gc-low-threshold。當用于存儲鏡像的磁盤使用率達到百分之–image-gc-high-threshold時將觸發(fā)鏡像回收，刪除最近最久未使用（LRU，Least Recently Used）的鏡像直到磁盤使用率降為百分之–image-gc-low-threshold或無鏡像可刪為止。默認–image-gc-high-threshold為90，–image-gc-low-threshold為80。
-
容器的回收有三個參數(shù)可設置：–minimum-container-ttl-duration，–maximum-dead-containers-per-container和–maximum-dead-containers。從容器停止運行時起經(jīng)過–minimum-container-ttl-duration時間后，該容器標記為已過期將來可以被回收（只是標記，不是回收），默認值為1m0s。一般情況下每個pod最多可以保留–maximum-dead-containers-per-container個已停止運行的容器集，默認值為2。整個node節(jié)點可以保留–maximum-dead-containers個已停止運行的容器，默認值為100。
-
如果需要關閉容器的垃圾回收策略，可以將–minimum-container-ttl-duration設為0（表示無限制），–maximum-dead-containers-per-container和–maximum-dead-containers設為負數(shù)。
-
–minimum-container-ttl-duration的值可以使用單位后綴，如h表示小時，m表示分鐘，s表示秒。
-
當–maximum-dead-containers-per-container和–maximum-dead-containers沖突時，–maximum-dead-containers優(yōu)先考慮。
-
對于那些由kubelet創(chuàng)建的但由于某些原因導致無名字（）的容器，會在到達GC時間點時被刪除。
-
回收容器時，按創(chuàng)建時間排序，優(yōu)先刪除那些創(chuàng)建時間最早的容器。
-
到達GC時間點時，具體的GC過程如下：
- 1）遍歷所有pod，使其滿足–maximum-dead-containers-per-container；
- 2）經(jīng)過上一步后如果不滿足–maximum-dead-containers，計算值X=（–maximum-dead-containers）/（pod總數(shù)），再遍歷所有pod，使其滿足已停止運行的容器集個數(shù)不大于X且至少為1；
- 3）經(jīng)過以上兩步后如果還不滿足–maximum-dead-containers，則對所有已停止的容器排序，優(yōu)先刪除創(chuàng)建時間最早的容器直到滿足–maximum-dead-containers為止。
-
當某個鏡像重新pull或啟動某個pod用到該鏡像時，該鏡像的最近使用時間都會被更新。
-
Kubernetes的垃圾回收在1.1.4版本開始才漸漸完善，之前的版本存在比較多bug甚至不能發(fā)揮作用。
-
關于容器的回收需要特別注意pod的概念，比如，通過同一個yaml文件create一個pod，再delete這個pod，然后再create這個pod，此時之前的那個pod對應的容器并不會作為新創(chuàng)建pod的已停止容器集，因為這兩個pod雖然同名，但已經(jīng)不是同一個pod了。只有同一個pod中在運行過程中由于意外或其它情況停止的容器才算是這個pod的已停止容器集。
3.2 實踐
鏡像回收（使用docker默認 --graph 參數(shù)：/var/lib/docker）
結點上運行的docker設置的參數(shù) --graph 使用默認的/var/lib/docker，指向/var文件系統(tǒng)，通過df -lh查看目前 /var 磁盤使用率為30%，啟動kubelet設置鏡像回收相關參數(shù)如下：
--image-gc-high-threshold=40 --image-gc-low-threshold=35
此時任意創(chuàng)建兩個使用不同鏡像的pod，在node節(jié)點上可以看到新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的鏡像回收時間點。然而五分鐘過去了，什么事情也沒有發(fā)生=_=!!。還記得 docker rmi 鏡像時有個前提條件是什么嗎？沒錯，要求使用該鏡像的容器都已經(jīng)被刪除了才可以。前面刪除pod只是停止了容器，并沒有將容器刪除。因此手工將對應的容器docker rm掉，再等待五分鐘后，可以看到鏡像已經(jīng)被刪除回收了：
$ 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
結論：只有相關聯(lián)的容器都被停止并刪除回收后，才能將Kubernetes的鏡像垃圾回收策略應用到該鏡像上。
鏡像回收（使用自定義docker --graph 參數(shù)：/opt/docker）
結點上運行的docker設置的參數(shù)–graph指向 /opt 磁盤，通過 df -lh 查看目前 /opt 磁盤使用率為 48% ，啟動 kubelet 設置鏡像回收相關參數(shù)如下：
--image-gc-high-threshold=50 --image-gc-low-threshold=40
此時任意創(chuàng)建兩個使用不同鏡像的pod，在node節(jié)點上可以看到新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 參數(shù)默認為 /var/lib/docker 時正常工作，當 --graph 設置為其它磁盤路徑時還存在bug。
問題反饋在 Github 的相關 issue 里：https://github.com/kubernetes/kubernetes/issues/17994，可以繼續(xù)跟進。
Append: 根據(jù)Github上的反饋，這個bug將在后續(xù)版本中解決，目前版本需要讓設置了–graph的鏡像垃圾回收生效，在啟動kubelet時還需要加上參數(shù) --docker-root=<docker --graph參數(shù)值>。
容器回收之 --maximum-dead-containers-per-container 參數(shù)
啟動kubelet設置容器回收相關參數(shù)如下：
--maximum-dead-containers-per-container=1
--minimum-container-ttl-duration=30s
--maximum-dead-containers=100
創(chuàng)建一個只包含一個容器且該容器一運行就退出的pod，此時在node節(jié)點上可以看到該pod中的容器不斷的創(chuàng)建退出創(chuàng)建退出：
$ 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的容器回收時間點到達時，可以看到創(chuàng)建時間大于30秒的已退出容器只剩下一個（pause容器不計算），且先創(chuàng)建的容器被優(yōu)先刪除：
$ 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參數(shù)設置可正常工作。
–maximum-dead-containers-per-container 針對容器還是容器集
啟動kubelet設置容器回收相關參數(shù)如下：
--maximum-dead-containers-per-container=1
--minimum-container-ttl-duration=30s
--maximum-dead-containers=100
創(chuàng)建一個包含三個容器且這些容器一運行就退出的pod，此時在node節(jié)點上可以看到該pod中的容器不斷的創(chuàng)建退出創(chuàng)建退出：
$ 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的容器回收時間點到達時，可以看到創(chuàng)建時間大于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 的計數(shù)針對一個pod內的容器集而不是容器的個數(shù)。
容器回收之 --maximum-dead-containers 參數(shù)
啟動kubelet設置容器回收相關參數(shù)如下：
--maximum-dead-containers-per-container=2
--minimum-container-ttl-duration=30s
--maximum-dead-containers=3
創(chuàng)建一個包含三個容器的pod，再刪除該pod，再創(chuàng)建該pod，再刪除該pod，這樣就產(chǎn)生了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參數(shù)設置可正常工作；pause容器也作為可回收容器被管理著；Tips第11條第3）點。
–maximum-dead-containers 對于非kubelet管理的容器是否計數(shù)
在第5個實驗的基礎上，手工創(chuàng)建一個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服務全解析，完！文章來源：http://www.zghlxwxcb.cn/news/detail-758318.html
參考資料：Kubelet Bootstrap 機制 APIServer基于引導token認證
kubelet定時清除磁盤鏡像文章來源地址http://www.zghlxwxcb.cn/news/detail-758318.html
到了這里，關于Kubernetes_核心組件_kubelet_kubelet服務全解析的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
