Kubernetes中使用临时容器进行故障排查的方法
目录
- 前言
- 什么是临时容器?
- 临时容器的配置
- 启动临时容器
- 使用临时容器
- 与临时容器共享进程命名空间
- 结论
前言 容器及其周围的生态系统改变了工程师部署、维护和排查工作负载故障的方式。但是,在 Kubernetes 集群上调试应用程序有时可能会很困难,因为你可能在容器中找不到所需的调试工具。许多工程师使用基于精简、发行版构建无发行版的基础镜像,其中甚至没有包管理器或shell。甚至一些团队使用 scratch 作为基础镜像,并且只添加应用程序运行所需的文件。这种常见做法的一些原因是:
- 具有较小的攻击区域。
- 为了获得更快的扫描性能。
- 减小了镜像大小。
- 为了有更快的构建和更短CD/CI周期。
- 减少依赖关系。
我们不能将容器添加到已部署的容器; 您需要更新spec,并重新创建资源。但是,可以将临时容器添加到现有 Pod 中,以便对线上问题进行故障排查。
本文介绍如何使用临时容器进行Kubernetes上工作负载的问题排查。
什么是临时容器? 临时容器与其他容器的不同之处在于,它们缺少对资源或执行的保证,并且永远不会自动重启, 因此不适用于构建应用程序。 临时容器使用与常规容器相同的 ContainerSpec 节来描述,但许多字段是不兼容和不允许的。
- 临时容器没有端口配置,因此像 ports,livenessProbe,readinessProbe 这样的字段是不允许的。
- Pod 资源分配是不可变的,因此 resources 配置是不允许的。
- 有关允许字段的完整列表,请参见 EphemeralContainer 参考文档。
与常规容器一样,将临时容器添加到 Pod 后,将不能更改或删除临时容器。
【Kubernetes中使用临时容器进行故障排查的方法】
临时容器的配置 临时容器与常规容器共享相同的spec。但是,某些字段被禁用,并且某些行为被更改。下面列出了一些重大变化; 检查临时容器规范以获取完整列表。
- 它们不会重新启动。
- 不允许定义资源。
- 不允许使用端口。
- 不允许使用启动、活动和就绪探测。
启动临时容器 首先,检查是否启用了临时容器功能。
kubectl debug -it --image=busybox
如果未启用该功能,您将看到类似下面的消息。
Defaulting debug container name to debugger-wg54p.将 EphemeralContainers=true 附加到 kubelet、kube-apiserver、kube-controller-manager、kube-proxy、kube-scheduler 参数中的--feature-gates=后, 例如:
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
...--feature-gates=RemoveSelfLink=false,EphemeralContainers=true...
使用临时容器 现在,集群支持临时容器功能,让我们来试试吧。要创建临时容器,使用 kubectl 命令行工具的 debug 子命令。首先,创建一个Deployment
kubectl create deployment nginx-deployment --image=nginx
获取需要debug的Pod的名称
$ kubectl get podsNAMEREADYSTATUSRESTARTSAGEnginx-deployment-66b6c48dd5-frsv91/1Running662d
以下命令将在 pod nginx-deployment-66b6c48dd5-frsv9 中创建一个新的临时容器。临时容器的镜像是busybox。-i 和 -t 参数允许我们附加到新创建的容器。
$ kubectl debug -it pods/nginx-deployment-66b6c48dd5-frsv9 --image=busybox
现在我们可以debug了
/ # ping 8.8.8.8PING 8.8.8.8 (8.8.8.8): 56 data bytes64 bytes from 8.8.8.8: seq=0 ttl=112 time=9.797 ms64 bytes from 8.8.8.8: seq=1 ttl=112 time=9.809 ms^C/ # nc --helpBusyBox v1.34.1 (2021-11-11 01:55:05 UTC) multi-call binary.Usage: nc [OPTIONS] HOST PORT- connectnc [OPTIONS] -l -p PORT [HOST] [PORT]- listen...
当使用 kubectl describe pod 命令时,可以看到一个新字段 "Ephemeral Containers",此部分包含临时容器及其属性。
$ kubectl describe pods ......Ephemeral Containers:debugger-thwrn:Container ID:containerd://eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0Image:busyboxImage ID:docker.io/library/busybox@sha256:e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353Port:Host Port:
与临时容器共享进程命名空间 进程命名空间共享一直是一个很好的故障排查选项,此功能可用于临时容器。进程命名空间共享不能应用于现有容器,因此必须创建目标容器的副本。--share-processesflag 在与 --copy-to 一起使用时,可实现进程命名空间共享。这些标志将现有的 Pod spec定义复制到新定义中,并在spec中启用了进程命名空间共享。
$ kubectl debug -it --image=busybox --share-processes --copy-to=debug-pod
运行 ps 命令以查看正在运行的进程。正如您所期望的那样,您可以从 busybox 容器中看到 /pause,从 nginx-deployment 容器中看到 nginx 进程。
# ps auxPIDUSERTIMECOMMAND1 root0:00 /pause6 root0:00 nginx: master process nginx -g daemon off; 11 1010:00 nginx: worker process12 root0:00 sh17 root0:00 ps aux
使用进程命名空间,共享容器文件系统也是可访问的,这对于调试非常有用。您可以使用 /proc//root 链接访问容器。从上面的输出中,我们知道nginx的PID为6。
# ls /proc/6/root/etc/nginxconf.d koi-utf mime.types nginx.conf uwsgi_params fastcgi_params koi-win modules scgi_params win-utf
在这里,我们可以看到目标容器上的Nginx目录结构和配置文件。
结论 临时容器功能无疑给调试排查问题带来了很大便利,而进程命名空间共享允许高级调试功能。如果你也使用在 Kubernetes 集群中运行的应用程序,那么值得花时间尝试这些功能。不难想象,一些团队甚至使用这些工具自动执行工作流,例如在readiness probes探针失败时自动修复其他容器。
到此这篇关于Kubernetes中使用临时容器进行故障排查的文章就介绍到这了,更多相关k8s故障排查内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
推荐阅读
- 云原生技术kubernetes之volumes容器的使用
- 谈谈|谈谈 Kubernetes Operator
- 中国移动发布首款 RISC-V 内核 MCU 芯片(最高工作主频 144MHz)
- C语言经典例题|【C语言典例】——day11(统计二进制中1的个数)
- java|程序员口中常说的API是什么意思(什么是API?)
- 深度学习|【深度学习1】Anaconda3的安装和Jupyter的使用
- 中文语音识别软件
- Mybatis-Plus如何使用分页实例详解
- Flutter滚动组件之SingleChildScrollView使用详解
- MyBatis中正则使用foreach拼接字符串