From 51cb915202ec753cc0fc06001ed9480d657d9fc0 Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Fri, 6 May 2022 19:20:55 +0800 Subject: [PATCH] [zh]Sync pod-overhead.md --- .../scheduling-eviction/pod-overhead.md | 102 +++++++++--------- 1 file changed, 52 insertions(+), 50 deletions(-) diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md index 6c9f119d4d..df4967664d 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md @@ -18,17 +18,17 @@ weight: 30 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些是运行 Pod 内容器所需资源之外的资源。 -_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。 +在 Kubernetes 中，_POD 开销_ 是一种方法，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。 @@ -53,17 +53,14 @@ the Pod cgroup, and when carrying out Pod eviction ranking. 类似地，kubelet 将在确定 Pod cgroups 的大小和执行 Pod 驱逐排序时也会考虑 Pod 开销。 -## 启用 Pod 开销 {#set-up} +## 配置 Pod 开销 {#set-up} -你需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -（在 1.18 默认是开启的），以及一个定义了 `overhead` 字段的 `RuntimeClass`。 +你需要确保使用一个定义了 `overhead` 字段的 `RuntimeClass`。 -要使用 PodOverhead 特性，需要一个定义了 `overhead` 字段的 RuntimeClass。 +要使用 Pod 开销，你需要一个定义了 `overhead` 字段的 RuntimeClass。 作为例子，下面的 RuntimeClass 定义中包含一个虚拟化所用的容器运行时， RuntimeClass 如下，其中每个 Pod 大约使用 120MiB 用来运行虚拟机和寄宿操作系统： ```yaml ---- -kind: RuntimeClass apiVersion: node.k8s.io/v1 +kind: RuntimeClass metadata: - name: kata-fc + name: kata-fc handler: kata-fc overhead: - podFixed: - memory: "120Mi" - cpu: "250m" + podFixed: + memory: "120Mi" + cpu: "250m" ``` -在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec: - +在 RuntimeClass 准入控制器进行修改后，你可以查看更新后的 PodSpec： ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` @@ -171,8 +166,10 @@ requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB o 然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 +Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip +text="cgroup" term_id="cgroup" >}} for the Pod. It is within this pod that the underlying +container runtime will create containers. +--> 一旦 Pod 被调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}。 底层容器运行时将在这个 Pod 中创建容器。 @@ -189,8 +186,8 @@ Burstable QoS），kubelet 会为与该资源（CPU 的 `cpu.cfs_quota_us` 以 相关的 Pod cgroup 设定一个上限。该上限基于 PodSpec 中定义的容器限制总量与 `overhead` 之和。 对于 CPU，如果 Pod 的 QoS 是 Guaranteed 或者 Burstable，kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`。 @@ -199,6 +196,7 @@ PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`。 Looking at our example, verify the container requests for the workload: --> 请看这个例子，验证工作负载的容器请求： + ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` @@ -207,6 +205,7 @@ kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' The total container requests are 2000m CPU and 200MiB of memory: --> 容器请求总计 2000m CPU 和 200MiB 内存： + ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` @@ -215,18 +214,19 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] Check this against what is observed by the node: --> 对照从节点观察到的情况来检查一下： + ```bash kubectl describe node | grep test-pod -B2 ``` -该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内： +The output shows requests for 2250m CPU, and for 320MiB of memory. The requests include Pod overhead: +--> +该输出显示请求了 2250m CPU 以及 320MiB 内存。请求包含了 Pod 开销在内： ``` - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE - --------- ---- ------------ ---------- --------------- ------------- --- - default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m ``` 执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 在即上一层目录。 + ``` - "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` +In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. +Verify the Pod level cgroup setting for memory: +--> 在这个例子中，该 Pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。 验证内存的 Pod 级别 cgroup 设置： @@ -300,6 +303,7 @@ In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-94 This is 320 MiB, as expected: --> 和预期的一样，这一数值为 320 MiB。 + ``` 335544320 ``` @@ -310,14 +314,12 @@ This is 320 MiB, as expected: ### 可观察性 在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 -`kube_pod_overhead` 指标来协助确定何时使用 PodOverhead +`kube_pod_overhead_*` 指标来协助确定何时使用 Pod 开销， 以及协助观察以一个既定开销运行的工作负载的稳定性。 该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。 在此之前，用户需要从源代码构建 kube-state-metrics。 @@ -325,9 +327,9 @@ from source in the meantime. ## {{% heading "whatsnext" %}} - -* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) -* [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) +* 学习更多关于 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 的信息 +* 阅读 [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)增强建议以获取更多上下文