Posted in

Kubernetes 1.31: kubectl debug 中的自定义调试升级至 Beta_AI阅读总结 — 包阅AI

包阅导读总结

1. `Kubernetes 1.31`、`kubectl debug`、`Custom Profiling`、`静态配置文件`、`扩展功能`

2. Kubernetes 1.31 中,kubectl debug 的自定义分析功能已升级到测试版。静态配置文件有局限性,自定义分析可扩展,但有字段限制,仅支持修改容器相关字段。

3.

– Kubernetes 1.31 中 kubectl debug 的相关内容

– 介绍:是排查集群中 pods 和 nodes 问题的常用工具,提供静态配置文件,但有固有局限性。

– 自定义分析功能

– 简介:通过 `–custom` 标志引入,提供扩展性,以 YAML 或 JSON 格式接受部分容器规范。

– 示例:包括修改环境变量等。

– 约束:某些字段不允许自定义,未来可能有更多限制。

– 局限:仅支持修改容器相关字段。

– 致谢:感谢相关贡献者。

思维导图:

文章地址:https://kubernetes.io/blog/2024/08/22/kubernetes-1-31-custom-profiling-kubectl-debug/

文章来源:kubernetes.io

作者:Kubernetes Blog

发布时间:2024/8/22 0:00

语言:英文

总字数:464字

预计阅读时间:2分钟

评分:89分

标签:Kubernetes,kubectl debug,自定义调试,容器规范,调试


以下为原文内容

本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com

Kubernetes 1.31: Custom Profiling in Kubectl Debug Graduates to Beta

By Arda Güçlü (Red Hat) |

There are many ways of troubleshooting the pods and nodes in the cluster. However, kubectl debug is one of the easiest, highly used and most prominent ones. Itprovides a set of static profiles and each profile serves for a different kind of role. For instance, from the network administrator’s point of view,debugging the node should be as easy as this:

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

On the other hand, static profiles also bring about inherent rigidity, which has some implications for some pods contrary to their ease of use.Because there are various kinds of pods (or nodes) that all have their specificnecessities, and unfortunately, some can’t be debugged by only using the static profiles.

Take an instance of a simple pod consisting of a container whose healthiness relies on an environment variable:

apiVersion: v1kind: Podmetadata:  name: example-podspec:  containers:  - name: example-container    image: customapp:latest    env:    - name: REQUIRED_ENV_VAR      value: "value1"

Currently, copying the pod is the sole mechanism that supports debugging this pod in kubectl debug. Furthermore, what if user needs to modify the REQUIRED_ENV_VAR to something differentfor advanced troubleshooting?. There is no mechanism to achieve this.

Custom Profiling

Custom profiling is a new functionality available under --custom flag, introduced in kubectl debug to provide extensibility. It expects partial Container spec in either YAML or JSON format.In order to debug the example-container above by creating an ephemeral container, we simply have to define this YAML:

# partial_container.yamlenv:  - name: REQUIRED_ENV_VAR    value: value2

and execute:

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

Here is another example that modifies multiple fields at once (change port number, add resource limits, modify environment variable) in JSON:

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

Constraints

Uncontrolled extensibility hurts the usability. So that, custom profiling is not allowed for certain fields such as command, image, lifecycle, volume devices and container name.In the future, more fields can be added to the disallowed list if required.

Limitations

The kubectl debug command has 3 aspects: Debugging with ephemeral containers, pod copying, and node debugging. The largest intersection set of these aspects is the container spec within a PodThat’s why, custom profiling only supports the modification of the fields that are defined with containers. This leads to a limitation that if user needs to modify the other fields in the Pod spec, it is not supported.

Acknowledgments

Special thanks to all the contributors who reviewed and commented on this feature, from the initial conception to its actual implementation (alphabetical order):