Kubernetes 1.31：kubectl debug 中的自定义模板化配置特性已进入 Beta 阶段

By Arda Güçlü (Red Hat) | 译者 Xin Li (DaoCloud) |

有很多方法可以对集群中的 Pod 和节点进行故障排查，而 kubectl debug 是最简单、使用最广泛、最突出的方法之一。 它提供了一组静态配置，每个配置适用于不同类型的角色。 例如，从网络管理员的视角来看，调试节点应该像这样简单：

$ kubectl debug node/mynode -it --image=busybox --profile=netadmin

另一方面，静态配置也存在固有的刚性，对某些 Pod 所产生的影响与其易用性是相悖的。 因为各种类型的 Pod（或节点）都有其特定的需求，不幸的是，有些问题仅通过静态配置是无法调试的。

以一个简单的 Pod 为例，此 Pod 由一个容器组成，其健康状况依赖于环境变量：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: customapp:latest
    env:
    - name: REQUIRED_ENV_VAR
      value: "value1"

目前，复制 Pod 是使用 kubectl debug 命令调试此 Pod 的唯一机制。 此外，如果用户需要将 REQUIRED_ENV_VAR 环境变量修改为其他不同值来进行高级故障排查， 当前并没有机制能够实现这一需求。

自定义模板化配置

自定义模板化配置使用 --custom 标志提供的一项新特性，在 kubectl debug 中引入以提供可扩展性。 它需要以 YAML 或 JSON 格式的内容填充 container 规约， 为了通过创建临时容器来调试上面的示例容器，我们只需定义此 YAML：

# partial_container.yaml
env:
  - name: REQUIRED_ENV_VAR
    value: value2

并且执行：

kubectl debug example-pod -it --image=customapp --custom=partial_container.yaml

下面是另一个在 JSON 中一次修改多个字段（更改端口号、添加资源限制、修改环境变量）的示例：

{
  "ports": [
    {
      "containerPort": 80
    }
  ],
  "resources": {
    "limits": {
      "cpu": "0.5",
      "memory": "512Mi"
    },
    "requests": {
      "cpu": "0.2",
      "memory": "256Mi"
    }
  },
  "env": [
    {
      "name": "REQUIRED_ENV_VAR",
      "value": "value2"
    }
  ]
}

约束

不受控制的扩展性会损害可用性。因此，某些字段（例如命令、镜像、生命周期、卷设备和容器名称）不允许进行自定义模版化配置。 将来如果需要，可以将更多字段添加到禁止列表中。

限制

kubectl debug 命令有 3 个方面：使用临时容器进行调试、Pod 复制和节点调试。 这些方面最大的交集是 Pod 内的容器规约，因此自定义模版化配置仅支持修改使用 containers 下定义的字段。 这导致了一个限制，如果用户需要修改 Pod 规约中的其他字段，则不受支持。

致谢

特别感谢所有审查和评论此特性（从最初的概念到实际实施）的贡献者（按字母顺序排列）：