Kubernetes 1.31：Kubectl Debug 中的自定义性能分析功能升级为 Beta 版

作者：Arda Güçlü (Red Hat) |

有很多方法可以对集群中的 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 以进行高级故障排除，该怎么办？ 没有机制来实现这一点。

自定义配置文件

自定义配置文件是 kubectl debug 中引入的 --custom 标志下提供的新功能，旨在提供可扩展性。 它期望以 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"
    }
  ]
}

约束

不受控制的可扩展性会损害可用性。 因此，自定义配置文件不允许用于某些字段，例如 command、image、lifecycle、volume devices 和 container name。 未来，如果需要，可以将更多字段添加到不允许的列表中。

限制

kubectl debug 命令有 3 个方面：使用临时容器调试、Pod 复制和节点调试。 这些方面的最大交集是 Pod 中的容器规范。 这就是为什么自定义配置文件仅支持修改使用 containers 定义的字段的原因。 这导致一个限制，如果用户需要修改 Pod 规范中的其他字段，则不支持。

致谢

特别感谢所有从最初构思到实际实现（按字母顺序排列）对该功能进行审查和评论的贡献者