从K8s的“临时容器”看K8s设计的厉害之处
本文分享自华为云社区《从K8s的“临时容器”看K8s设计的厉害之处》,作者: tsjsdbd。
从一个容器的不足说起
容器概念出现时,有个非常重要的理念:容器中极简。
即容器里面只保留需要运行的进程就可以,其他一律不要安装。这也是为什么Docker出现的那时,有一篇文章《为什么不需要在Docker容器中运行sshd》经常被提及的原因。
但有时候Docker容器中缺少需要的软件。比如 curl,wget,ifconfig,ip,tcpdump 等基础软件包,遇到问题时,什么命令都敲不了,很是让人抓狂。平时定位问题的技术(各种Linux命令行工具),一点都用不上了。自己打的镜像倒还好,大不了重新打镜像把需要的工具也安装后,重新打镜像。但是如果是开源镜像就比较棘手。
如何在没有安装软件包的容器里面,执行需要的命令行(二进制工具)进行调试,一直是K8s平台的一个小遗憾。
我以前想K8s可以补充的功能
之前唐老师写过《跟唐老师学习云网络 - nsenter魔法棒》,我还想着:可以利用Host上面的命令行呀,通过nsenter跳到容器里面,不就可以执行了么。
当年还幻想可以给K8s提点proposal:让exec命令增加 --from-host 参数,当带上这个参数的时候,让kubelet直接从Host执行nsenter运行主机上面的二进制,这样就绕过了容器里面没有命令行的约束。方便管理员调试容器中相关问题。
想法似乎挺好,后面转战上层AI平台,并没有继续关注这么底层的了。直到最近看到K8s的新功能:“临时容器” (ephemeral containers)。发现K8s对某个特性的设计还是非常值得点赞的。
结果K8s实现的功能
K8s为了能在容器里面,执行不存在的命令行,增加了一个 kubectl debug命令
大致流程如下图:
其中红色容器,就是一个“临时容器”,它与目标容器共享各种namespace,所以与直接在目标容器中执行命令的效果是一样的。通过指定镜像地址,来控制这个新启动的“临时容器”里面包含自己所需要的各类命令行。
这样就可以在任意K8s的容器里面,执行不存在的命令行工具了。比如,对某Pod里面的名为app的容器执行调试:
kubectl debug -it -c debugger --target=app --image=busybox {POD_NAME}
--target参数,是指定Pod中需要调试的目标Container(有时Pod有多个Container)。
果然还是人家的更厉害
看完K8s的实现,明显比我早期想的 “借用Host” 方法更好:其仍然保持Host节点的“极简”,而是将需要的工具仍然保持由容器来承载。这样可以借用任意的容器镜像,而不必在Host节点上面安装各种工具包。非常优雅。
更“过分”的是,在节点上没有的命令行工具,也不需要给节点安装软件包,也可以通过临时容器来执行。
kubectl debug node/mynode -it --image=ubuntu
扩展性也很赞,确实考虑的挺周全。
So,启动“临时容器”来在目标容器中“整活”走起~
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)
2023-07-26 5分钟迁移关系型数据库到图数据库
2023-07-26 GaussDB(for Redis)多租户:读写权限控制和数据库隔离的完美融合
2023-07-26 实践分析丨AscendCL应用编译&运行案例
2022-07-26 6种方法帮你搞定SimpleDateFormat类不是线程安全的问题
2022-07-26 实践GoF的23种设计模式:观察者模式
2022-07-26 带你熟悉云网络的“电话簿”:DNS
2022-07-26 Python图像处理丨两种实现图像形态学转化运算