kubectl exec 是什么
kubectl exec 在正在运行的容器里新起一个进程，或者打开一个交互式命令行。请求由 API Server 转发到目标节点的 kubelet，再由容器运行时在该容器内创建进程，因此不需要开放节点端口，也不要求 Pod 有外部网络入口。它不改镜像、不重启容器，是排查运行时问题最直接的手段。
它能验证什么
容器内看到的世界才是应用真实看到的世界：DNS 能不能解析服务名、依赖的端口通不通、挂载进去的配置文件是不是新版本、环境变量有没有生效、证书文件在不在。这些用集群侧的查询命令都看不出来，必须进去看。反过来说，它验证不了镜像构建是否可复现，也不能替代日志排查。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，需要 pods 与 pods/exec 权限 |
|---|---|
| 语法 | kubectl exec [-it] <pod> [-c 容器] -- <命令> |
| 前提条件 | 目标容器处于运行中状态，且镜像内有对应可执行文件 |
| 交互要求 | 开交互式 shell 需要 -it 组合；纯执行命令可省略 |
| 进程来源 | 在容器命名空间内新起进程，不经过镜像入口脚本 |
| 典型限制 | 精简镜像无 shell；容器重启后会话中断 |
典型使用场景
- 网络排查：在容器里测目标服务的端口连通性，判断是网络策略还是应用问题
- DNS 验证：解析服务名与外部域名，确认解析结果与预期一致
- 配置核对：查看挂载进容器的配置文件内容，确认是否为最新版本
- 环境变量确认：检查注入的变量是否生效，排查配置缺失导致的启动失败
- 证书检查：查看证书文件是否存在、有效期是否正确
- 进程观察：查看容器内的进程列表与监听端口，确认应用真的起来了
- 临时取证：在没有终端权限的环境里执行一次性的诊断命令并把结果打印出来
常用示例
常用示例
kubectl exec -it web-7d9c8b6f5c-abcde -- sh # 精简镜像优先用 sh
kubectl exec -it web-x -c app -- bash # 多容器时指定容器
kubectl exec web-x -- env | grep -i proxy # 只看环境变量，无需交互
kubectl exec -it web-x -- nslookup kubernetes.default # 验证集群 DNS
kubectl exec web-x -- cat /etc/app/app.properties # 核对挂载进去的配置
kubectl exec web-x -- ls -l /var/run/secrets/tls # 检查证书挂载
kubectl exec web-x -- printenv | sort | head -30 # 排查变量缺失常用参数
| 参数 | 作用 | 注意事项 |
|---|---|---|
| -i | 把标准输入接到容器进程 | 需要从管道喂数据时必加 |
| -t | 分配伪终端 | 仅在交互场景需要 |
| -it | 组合使用，得到可交互会话 | 缺 -t 会出现无法输入的现象 |
| -c | 指定容器名 | 多容器 Pod 必须明确指定 |
| -- | 分隔 kubectl 参数与容器内命令 | 命令带选项时务必加上 |
| -n | 指定命名空间 | 脚本里建议每条都显式带 |
排查动作组合
- 先确认容器在运行，已崩溃的容器要改用 debug 注入临时容器或在重建前抓紧取证
- 网络类问题优先在容器内测端口与解析，而不是在节点上测
- 配置类问题对比容器内文件与集群中的对象内容，确认是否受挂载方式影响
-- 之后的第一项是容器内命令；带选项的命令要放在 -- 之后，否则选项会被 kubectl 解析掉。
镜像里没有 shell 时会报找不到可执行文件，此时应改用 kubectl debug 注入临时容器，而不是反复重试。
exec 起的进程与主进程共享资源限制，做压测或大文件操作会影响业务容器的内存与 CPU 配额，排查动作要轻量。