Kubernetes中使用臨時(shí)容器進(jìn)行故障排查的方法
前言
容器及其周圍的生態(tài)系統(tǒng)改變了工程師部署、維護(hù)和排查工作負(fù)載故障的方式。但是,在 Kubernetes 集群上調(diào)試應(yīng)用程序有時(shí)可能會(huì)很困難,因?yàn)槟憧赡茉谌萜髦姓也坏剿璧恼{(diào)試工具。許多工程師使用基于精簡、發(fā)行版構(gòu)建無發(fā)行版的基礎(chǔ)鏡像,其中甚至沒有包管理器或shell。甚至一些團(tuán)隊(duì)使用 scratch 作為基礎(chǔ)鏡像,并且只添加應(yīng)用程序運(yùn)行所需的文件。這種常見做法的一些原因是:
- 具有較小的攻擊區(qū)域。
- 為了獲得更快的掃描性能。
- 減小了鏡像大小。
- 為了有更快的構(gòu)建和更短CD/CI周期。
- 減少依賴關(guān)系。
這些精簡的基礎(chǔ)鏡像不包括用于對應(yīng)用程序或其依賴項(xiàng)進(jìn)行故障排查的工具。這是 Kubernetes 臨時(shí)容器功能最大用途。臨時(shí)容器允許創(chuàng)建包含可能需要的所有調(diào)試工具的容器鏡像。一旦需要調(diào)試,就可以將臨時(shí)容器部署到所選的正在運(yùn)行的 Pod 中。
我們不能將容器添加到已部署的容器;您需要更新spec,并重新創(chuàng)建資源。但是,可以將臨時(shí)容器添加到現(xiàn)有 Pod 中,以便對線上問題進(jìn)行故障排查。
本文介紹如何使用臨時(shí)容器進(jìn)行Kubernetes上工作負(fù)載的問題排查。
什么是臨時(shí)容器?
臨時(shí)容器與其他容器的不同之處在于,它們?nèi)鄙賹Y源或執(zhí)行的保證,并且永遠(yuǎn)不會(huì)自動(dòng)重啟, 因此不適用于構(gòu)建應(yīng)用程序。 臨時(shí)容器使用與常規(guī)容器相同的 ContainerSpec 節(jié)來描述,但許多字段是不兼容和不允許的。
- 臨時(shí)容器沒有端口配置,因此像 ports,livenessProbe,readinessProbe 這樣的字段是不允許的。
- Pod 資源分配是不可變的,因此 resources 配置是不允許的。
- 有關(guān)允許字段的完整列表,請參見 EphemeralContainer 參考文檔。
臨時(shí)容器是使用 API 中的一種特殊的 ephemeralcontainers 處理器進(jìn)行創(chuàng)建的, 而不是直接添加到 pod.spec 段,因此無法使用 kubectl edit 來添加一個(gè)臨時(shí)容器。
與常規(guī)容器一樣,將臨時(shí)容器添加到 Pod 后,將不能更改或刪除臨時(shí)容器。
臨時(shí)容器的配置
臨時(shí)容器與常規(guī)容器共享相同的spec。但是,某些字段被禁用,并且某些行為被更改。下面列出了一些重大變化;檢查臨時(shí)容器規(guī)范以獲取完整列表。
- 它們不會(huì)重新啟動(dòng)。
- 不允許定義資源。
- 不允許使用端口。
- 不允許使用啟動(dòng)、活動(dòng)和就緒探測。
啟動(dòng)臨時(shí)容器
首先,檢查是否啟用了臨時(shí)容器功能。
kubectl debug -it <POD_NAME> --image=busybox
如果未啟用該功能,您將看到類似下面的消息。
Defaulting debug container name to debugger-wg54p.
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
將 EphemeralContainers=true 附加到 kubelet、kube-apiserver、kube-controller-manager、kube-proxy、kube-scheduler 參數(shù)中的--feature-gates=后, 例如:
... --feature-gates=RemoveSelfLink=false,EphemeralContainers=true ...
使用臨時(shí)容器
現(xiàn)在,集群支持臨時(shí)容器功能,讓我們來試試吧。要?jiǎng)?chuàng)建臨時(shí)容器,使用 kubectl 命令行工具的 debug 子命令。首先,創(chuàng)建一個(gè)Deployment
kubectl create deployment nginx-deployment --image=nginx
獲取需要debug的Pod的名稱
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-66b6c48dd5-frsv9 1/1 Running 6 62d
以下命令將在 pod nginx-deployment-66b6c48dd5-frsv9 中創(chuàng)建一個(gè)新的臨時(shí)容器。臨時(shí)容器的鏡像是busybox。-i 和 -t 參數(shù)允許我們附加到新創(chuàng)建的容器。
$ kubectl debug -it pods/nginx-deployment-66b6c48dd5-frsv9 --image=busybox
現(xiàn)在我們可以debug了
/ # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=112 time=9.797 ms 64 bytes from 8.8.8.8: seq=1 ttl=112 time=9.809 ms ^C / # nc --help BusyBox v1.34.1 (2021-11-11 01:55:05 UTC) multi-call binary. Usage: nc [OPTIONS] HOST PORT - connect nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen ...
當(dāng)使用 kubectl describe pod <POD_NAME> 命令時(shí),可以看到一個(gè)新字段 "Ephemeral Containers",此部分包含臨時(shí)容器及其屬性。
$ kubectl describe pods <POD_NAME> ... ... Ephemeral Containers: debugger-thwrn: Container ID: containerd://eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0 Image: busybox Image ID: docker.io/library/busybox@sha256:e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353 Port: <none> Host Port: <none>
與臨時(shí)容器共享進(jìn)程命名空間
進(jìn)程命名空間共享一直是一個(gè)很好的故障排查選項(xiàng),此功能可用于臨時(shí)容器。進(jìn)程命名空間共享不能應(yīng)用于現(xiàn)有容器,因此必須創(chuàng)建目標(biāo)容器的副本。--share-processesflag 在與 --copy-to 一起使用時(shí),可實(shí)現(xiàn)進(jìn)程命名空間共享。這些標(biāo)志將現(xiàn)有的 Pod spec定義復(fù)制到新定義中,并在spec中啟用了進(jìn)程命名空間共享。
$ kubectl debug -it <POD_NAME> --image=busybox --share-processes --copy-to=debug-pod
運(yùn)行 ps 命令以查看正在運(yùn)行的進(jìn)程。正如您所期望的那樣,您可以從 busybox 容器中看到 /pause,從 nginx-deployment 容器中看到 nginx 進(jìn)程。
# ps aux PID USER TIME COMMAND 1 root 0:00 /pause 6 root 0:00 nginx: master process nginx -g daemon off; 11 101 0:00 nginx: worker process 12 root 0:00 sh 17 root 0:00 ps aux
使用進(jìn)程命名空間,共享容器文件系統(tǒng)也是可訪問的,這對于調(diào)試非常有用。您可以使用 /proc//root 鏈接訪問容器。從上面的輸出中,我們知道nginx的PID為6。
# ls /proc/6/root/etc/nginx conf.d koi-utf mime.types nginx.conf uwsgi_params fastcgi_params koi-win modules scgi_params win-utf
在這里,我們可以看到目標(biāo)容器上的Nginx目錄結(jié)構(gòu)和配置文件。
結(jié)論
臨時(shí)容器功能無疑給調(diào)試排查問題帶來了很大便利,而進(jìn)程命名空間共享允許高級(jí)調(diào)試功能。如果你也使用在 Kubernetes 集群中運(yùn)行的應(yīng)用程序,那么值得花時(shí)間嘗試這些功能。不難想象,一些團(tuán)隊(duì)甚至使用這些工具自動(dòng)執(zhí)行工作流,例如在readiness probes探針失敗時(shí)自動(dòng)修復(fù)其他容器。
到此這篇關(guān)于Kubernetes中使用臨時(shí)容器進(jìn)行故障排查的文章就介紹到這了,更多相關(guān)k8s故障排查內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
在AWS-EC2中安裝Minikube集群的詳細(xì)過程
這篇文章主要介紹了在AWS-EC2中安裝Minikube集群,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-06-06理解k8s控制器DaemonSet創(chuàng)建及使用場景
這篇文章主要為大家介紹了k8s控制器DaemonSet創(chuàng)建及使用場景詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-09-09在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格的過程詳解
這篇文章主要介紹了在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格,我們采用default配置檔部署istio網(wǎng)格,istioctl?install命令不指定任何配置檔默認(rèn)就是呀default配置檔,需要的朋友可以參考下2022-05-05CentOS 7.9 升級(jí)內(nèi)核 kernel-ml-5.6.14版本的方法
這篇文章主要介紹了CentOS 7.9 升級(jí)內(nèi)核 kernel-ml-5.6.14版本,默認(rèn)內(nèi)核版本為3.10.0,現(xiàn)升級(jí)到 5.6.14 版本,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-10-10Kubernetes k8s configmap 容器技術(shù)解析
這篇文章主要為大家介紹了k8s configmap 容器技術(shù)解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-08-08青龍面板拉庫解決沒有或丟失依賴can‘t?find?module的保姆級(jí)教程(附青龍面板腳本倉庫)
這篇文章主要介紹了青龍面板拉庫解決沒有或丟失依賴can‘t?find?module的保姆級(jí)教程(附青龍面板腳本倉庫),需要的朋友可以參考下2022-05-05