临时容器
该功能目前处于 alpha 状态,意味着:
- 版本名称包含 alpha(例如 v1alpha1)。
- 可能存在问题,启用该功能可能会暴露 bug。默认情况下被禁用。
- 对该功能的支持可能在任何时候被取消,而不另行通知。
- API 可能会在以后的软件版本中以不兼容的方式被更改,而不另行通知。
- 建议仅在短期测试集群中使用该功能,这是因为使用该功能会增加出现 bug 的风险,而且缺乏长期支持。
此页面概述了临时容器:一种特殊的容器,该容器在现有 PodPod 是 Kubernetes 的原子对象。Pod 表示您的集群上一组正在运行的容器。 中临时运行,为了完成用户启动的操作,例如故障排查。使用临时容器来检查服务,而不是构建应用程序。
是 Kubernetes 应用程序的基本构建块。由于 pod 是一次性且可替换的,因此一旦 Pod 创建,就无法将容器加入到 Pod 中。取而代之的是,通常使用 deploymentsDeployment 是管理应用副本的 API 对象。 以受控的方式来删除并替换 Pod。
有时有必要检查现有 Pod 的状态,例如,对于难以复现的故障进行排查。在这些场景中,可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。
临时容器与其他容器的不同之处在于,它们缺少对资源或执行的保证,并且永远不会自动重启,因此不适用于构建应用程序。临时容器使用与常规容器相同的 ContainerSpec
段进行描述,但许多字段是不相容且不允许的。
- Pod 资源分配是不可变的,因此
resources
配置是不允许的。 - 有关允许字段的完整列表,请参见。
与常规容器一样,将临时容器添加到 Pod 后,将不能更改或删除临时容器。
临时容器的用途
当由于容器崩溃或容器镜像不包含调试实用程序而导致 kubectl exec
无用时,临时容器对于交互式故障排查很有用。
尤其是,能够使得部署最小的容器镜像,从而减少攻击面并减少故障和漏洞的暴露。由于 distroless 镜像不包含 shell 或任何的调试工具,因此很难单独使用 kubectl exec
命令进行故障排查。
使用临时容器时,启用进程命名空间共享很有帮助,可以查看其他容器中的进程。
示例
注意: 本节中的示例要求启用
EphemeralContainers
特性,并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。
本节中的示例演示了临时容器如何出现在 API 中。 通常,您可以使用 插件进行故障排查,从而自动化执行这些步骤。
使用如下命令更新已运行的临时容器 example-pod
:
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
这将返回临时容器的新列表:
可以使用以下命令查看新创建的临时容器的状态:
kubectl describe pod example-pod
可以使用以下命令连接到新的临时容器:
kubectl attach -it example-pod -c debugger
如果启用了进程命名空间共享,则可以查看该 Pod 所有容器中的进程。 例如,运行上述 attach
操作后,在调试器容器中运行 ps
操作:
运行命令后,输出类似于:
PID USER TIME COMMAND
1 root 0:00 /pause
11 101 0:00 nginx: worker process
13 101 0:00 nginx: worker process
14 101 0:00 nginx: worker process
15 101 0:00 nginx: worker process
16 101 0:00 nginx: worker process
17 101 0:00 nginx: worker process
18 101 0:00 nginx: worker process
19 root 0:00 /pause
24 root 0:00 sh
29 root 0:00 ps auxww