From cb2d70f064147ff02368f57f460d125cdd2560fb Mon Sep 17 00:00:00 2001
From: "xin.li" <xin.li@daocloud.io>
Date: Thu, 15 Aug 2024 19:24:51 +0800
Subject: [PATCH] [zh-cn] Add blog:
 2024-06-21-custom-profiling-kubectl-debug.md

Signed-off-by: xin.li <xin.li@daocloud.io>
---
 ...24-06-21-custom-profiling-kubectl-debug.md | 160 ++++++++++++++++++
 1 file changed, 160 insertions(+)
 create mode 100644 content/zh-cn/blog/_posts/2024-06-21-custom-profiling-kubectl-debug.md

diff --git a/content/zh-cn/blog/_posts/2024-06-21-custom-profiling-kubectl-debug.md b/content/zh-cn/blog/_posts/2024-06-21-custom-profiling-kubectl-debug.md
new file mode 100644
index 0000000000..ca14407b36
--- /dev/null
+++ b/content/zh-cn/blog/_posts/2024-06-21-custom-profiling-kubectl-debug.md
@@ -0,0 +1,160 @@
+---
+layout: blog
+title: "Kubernetes 1.31：kubectl debug 中的自定义模板化配置特性已进入 Beta 阶段"
+date: 2024-08-22
+slug: kubernetes-1-31-custom-profiling-kubectl-debug
+author: >
+  Arda Güçlü (Red Hat)
+translator: >
+  Xin Li (DaoCloud)
+---
+<!--
+layout: blog
+title: "Kubernetes 1.31: Custom Profiling in Kubectl Debug Graduates to Beta"
+date: 2024-08-22
+slug: kubernetes-1-31-custom-profiling-kubectl-debug
+author: >
+  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. It
+provides 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:
+-->
+有很多方法可以对集群中的 Pod 和节点进行故障排查，而 `kubectl debug` 是最简单、使用最广泛、最突出的方法之一。
+它提供了一组静态配置，每个配置适用于不同类型的角色。
+例如，从网络管理员的视角来看，调试节点应该像这样简单：
+
+```shell
+$ 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 specific
+necessities, 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:
+-->
+另一方面，静态配置也存在固有的刚性，对某些 Pod 所产生的影响与其易用性是相悖的。
+因为各种类型的 Pod（或节点）都有其特定的需求，不幸的是，有些问题仅通过静态配置是无法调试的。
+
+以一个简单的 Pod 为例，此 Pod 由一个容器组成，其健康状况依赖于环境变量：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: example-pod
+spec:
+  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 different
+for advanced troubleshooting?. There is no mechanism to achieve this.
+-->
+目前，复制 Pod 是使用 `kubectl debug` 命令调试此 Pod 的唯一机制。
+此外，如果用户需要将 `REQUIRED_ENV_VAR` 环境变量修改为其他不同值来进行高级故障排查，
+当前并没有机制能够实现这一需求。
+
+<!--
+## 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:
+-->
+## 自定义模板化配置
+
+自定义模板化配置使用 `--custom` 标志提供的一项新特性，在 `kubectl debug` 中引入以提供可扩展性。
+它需要以 YAML 或 JSON 格式的内容填充 `container` 规约，
+为了通过创建临时容器来调试上面的示例容器，我们只需定义此 YAML：
+
+```yaml
+# partial_container.yaml
+env:
+  - name: REQUIRED_ENV_VAR
+    value: value2
+```
+
+<!--
+and execute:
+-->
+并且执行：
+
+```shell
+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:
+-->
+下面是另一个在 JSON 中一次修改多个字段（更改端口号、添加资源限制、修改环境变量）的示例：
+
+```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 Pod
+That'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.
+-->
+## 限制
+
+`kubectl debug` 命令有 3 个方面：使用临时容器进行调试、Pod 复制和节点调试。
+这些方面最大的交集是 Pod 内的容器规约，因此自定义模版化配置仅支持修改使用 `containers` 下定义的字段。
+这导致了一个限制，如果用户需要修改 Pod 规约中的其他字段，则不受支持。
+
+<!--
+## Acknowledgments
+
+Special thanks to all the contributors who reviewed and commented on this feature, from the initial conception to its actual implementation (alphabetical order):
+-->
+## 致谢
+
+特别感谢所有审查和评论此特性（从最初的概念到实际实施）的贡献者（按字母顺序排列）：
+
+- [Eddie Zaneski](https://github.com/eddiezane)
+- [Maciej Szulik](https://github.com/soltysh)
+- [Lee Verberne](https://github.com/verb)