[zh-cn]sync system-metrics logging device-plugins ingress network-policies

Signed-off-by: xin.li <xin.li@daocloud.io>
2023-09-10 12:32:07 +08:00 · 2023-09-10 12:32:07 +08:00 · dffde5d994
parent 18568296df
commit dffde5d994
5 changed files with 31 additions and 76 deletions
--- a/content/zh-cn/docs/concepts/cluster-administration/logging.md
+++ b/content/zh-cn/docs/concepts/cluster-administration/logging.md
@ -69,7 +69,7 @@ Kubernetes 从正在运行的 Pod 中捕捉每个容器的日志。

 此示例使用带有一个容器的 `Pod` 的清单，该容器每秒将文本写入标准输出一次。

-{{% code file="debug/counter-pod.yaml" %}}
+{{% code_sample file="debug/counter-pod.yaml" %}}

 <!--
 To run this pod, use the following command:
@ -463,7 +463,7 @@ manifest for the Pod:
 例如，某 Pod 中运行一个容器，且该容器使用两个不同的格式写入到两个不同的日志文件。
 下面是这个 Pod 的清单：

-{{% code file="admin/logging/two-files-counter-pod.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod.yaml" %}}

 <!--
 It is not recommended to write log entries with different formats to the same log
@ -481,7 +481,7 @@ Here's a manifest for a pod that has two sidecar containers:
 -->
 下面是运行两个边车容器的 Pod 的清单：

-{{% code file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}

 <!--
 Now when you run this pod, you can access each log stream separately by
@ -619,7 +619,7 @@ to configure fluentd.
 第一个文件包含用来配置 fluentd 的
 [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。

-{{% code file="admin/logging/fluentd-sidecar-config.yaml" %}}
+{{% code_sample file="admin/logging/fluentd-sidecar-config.yaml" %}}

 {{< note >}}
 <!--
@ -636,7 +636,7 @@ The pod mounts a volume where fluentd can pick up its configuration data.
 第二个清单描述了一个运行 fluentd 边车容器的 Pod。
 该 Pod 挂载一个卷，flutend 可以从这个卷上拣选其配置数据。

-{{% code file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}

 <!--
 ### Exposing logs directly from the application
--- a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md
+++ b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md
@ -204,35 +204,6 @@ to remove this metric dependency before upgrading to `1.14`
 如果你要从版本 `1.12` 升级到 `1.13`，但仍依赖于 `1.12` 中弃用的指标 `A`，则应通过命令行设置隐藏指标：
 `--show-hidden-metrics=1.12`，并记住在升级到 `1.14` 版本之前删除此指标依赖项。

-<!--
-## Disable accelerator metrics
-
-The kubelet collects accelerator metrics through cAdvisor. To collect these metrics, for
-accelerators like NVIDIA GPUs, kubelet held an open handle on the driver. This meant that in order
-to perform infrastructure changes (for example, updating the driver), a cluster administrator
-needed to stop the kubelet agent.
-
-The responsibility for collecting accelerator metrics now belongs to the vendor rather than the
-kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics
-service (for example, Prometheus).
-
-The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-disables metrics collected by the kubelet, with a
-[timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
-->
-## 禁用加速器指标  {#disable-accelerator-metrics}
-
-kubelet 通过 cAdvisor 收集加速器指标。为了收集这些指标，对于 NVIDIA GPU 之类的加速器，
-kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结构更改（例如更新驱动程序），
-集群管理员需要停止 kubelet 代理。
-
-现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器，
-并将其公开给指标服务（例如 Prometheus）。
-
-[`DisableAcceleratorUsageMetrics` 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
-禁止由 kubelet 收集的指标。
-关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
-
 <!--
 ## Component metrics

--- a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@ -18,9 +18,8 @@ weight: 20
 {{< feature-state for_k8s_version="v1.26" state="stable" >}}

 <!--
-Kubernetes provides a [device plugin framework](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)
-that you can use to advertise system hardware resources to the
-{{< glossary_tooltip term_id="kubelet" >}}.
+Kubernetes provides a device plugin framework that you can use to advertise system hardware
+resources to the {{< glossary_tooltip term_id="kubelet" >}}.

 Instead of customizing the code for Kubernetes itself, vendors can implement a
 device plugin that you deploy either manually or as a {{< glossary_tooltip term_id="daemonset" >}}.
@ -28,9 +27,8 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
 and other similar computing resources that may require vendor specific initialization
 and setup.
 -->
-Kubernetes 提供了一个
-[设备插件框架](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)，
-你可以用它来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。
+Kubernetes 提供了一个设备插件框架，你可以用它来将系统硬件资源发布到
+{{< glossary_tooltip term_id="kubelet" >}}。

 供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}}
 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、
@ -454,7 +452,7 @@ this feature `kubelet` must be started with the following flags:
 要启用此特性，必须使用以下标志启动 `kubelet`：

 ```
--feature-gates=DynamicResourceAllocation=true,KubeletPodResourcesDynamiceResources=true
+--feature-gates=DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true
 ```

 <!--
@ -715,15 +713,6 @@ will continue working.

 {{< /note >}}

-<!--
-Support for the `PodResourcesLister service` requires `KubeletPodResources`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
-It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
-->
-对 “PodResourcesLister 服务”的支持要求启用 `KubeletPodResources`
-[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
-从 Kubernetes 1.15 开始默认启用，自从 Kubernetes 1.20 开始为 v1。
-
 <!--
 ### `Get` gRPC endpoint {#grpc-endpoint-get}
 -->
@ -774,7 +763,7 @@ ensure your kubelet services are started with the following flags:
 要启用此特性，你必须确保使用以下标志启动 kubelet 服务：

 ```
--feature-gates=KubeletPodResourcesGet=true,DynamicResourceAllocation=true,KubeletPodResourcesDynamiceResources=true
+--feature-gates=KubeletPodResourcesGet=true,DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true
 ```

 <!--
@ -842,6 +831,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 Here are some examples of device plugin implementations:

 * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
+* The [generic device plugin](https://github.com/squat/generic-device-plugin) for generic Linux devices and USB devices
 * The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for
  Intel GPU, FPGA, QAT, VPU, SGX, DSA, DLB and IAA devices
 * The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for
@ -856,6 +846,7 @@ Here are some examples of device plugin implementations:
 下面是一些设备插件实现的示例：

 * [AMD GPU 设备插件](https://github.com/RadeonOpenCompute/k8s-device-plugin)
+* 适用于通用 Linux 设备和 USB 设备的[通用设备插件](https://github.com/squat/generic-device-plugin)
 * [Intel 设备插件](https://github.com/intel/intel-device-plugins-for-kubernetes)支持
  Intel GPU、FPGA、QAT、VPU、SGX、DSA、DLB 和 IAA 设备
 * [KubeVirt 设备插件](https://github.com/kubevirt/kubernetes-device-plugins) 用于硬件辅助的虚拟化
--- a/content/zh-cn/docs/concepts/services-networking/ingress.md
+++ b/content/zh-cn/docs/concepts/services-networking/ingress.md
@ -148,7 +148,7 @@ A minimal Ingress resource example:

 一个最小的 Ingress 资源示例：

-{{% code file="service/networking/minimal-ingress.yaml" %}}
+{{% code_sample file="service/networking/minimal-ingress.yaml" %}}

 <!-- 
 An Ingress needs `apiVersion`, `kind`, `metadata` and `spec` fields.
@ -284,7 +284,7 @@ with static assets.
 `Resource` 后端与 Service 后端是互斥的，在二者均被设置时会无法通过合法性检查。
 `Resource` 后端的一种常见用法是将所有入站数据导向保存静态资产的对象存储后端。

-{{% code file="service/networking/ingress-resource-backend.yaml" %}}
+{{% code_sample file="service/networking/ingress-resource-backend.yaml" %}}

 <!--
 After creating the Ingress above, you can view it with the following command:
@ -442,7 +442,7 @@ equal to the suffix of the wildcard rule.
 | `*.foo.com`  | `baz.bar.foo.com`  | 不匹配，通配符仅覆盖了一个 DNS 标签 |
 | `*.foo.com`  | `foo.com`          | 不匹配，通配符仅覆盖了一个 DNS 标签 |

-{{% code file="service/networking/ingress-wildcard-host.yaml" %}}
+{{% code_sample file="service/networking/ingress-wildcard-host.yaml" %}}

 <!-- 
 ## Ingress class
@ -458,7 +458,7 @@ Ingress 可以由不同的控制器实现，通常使用不同的配置。
 每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。
 IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。

-{{% code file="service/networking/external-lb.yaml" %}}
+{{% code_sample file="service/networking/external-lb.yaml" %}}

 <!-- 
 The `.spec.parameters` field of an IngressClass lets you reference another
@ -667,7 +667,7 @@ default `IngressClass`:
 不过仍然[推荐](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)
 设置默认的 `IngressClass`。

-{{% code file="service/networking/default-ingressclass.yaml" %}}
+{{% code_sample file="service/networking/default-ingressclass.yaml" %}}

 <!--
 ## Types of Ingress
@ -685,7 +685,7 @@ There are existing Kubernetes concepts that allow you to expose a single Service
 现有的 Kubernetes 概念允许你暴露单个 Service（参见[替代方案](#alternatives)）。
 你也可以使用 Ingress 并设置无规则的**默认后端**来完成这类操作。

-{{% code file="service/networking/test-ingress.yaml" %}}
+{{% code_sample file="service/networking/test-ingress.yaml" %}}

 <!-- 
 If you create it using `kubectl apply -f` you should be able to view the state
@ -736,7 +736,7 @@ It would require an Ingress such as:
 -->
 这将需要一个如下所示的 Ingress：

-{{% code file="service/networking/simple-fanout-example.yaml" %}}
+{{% code_sample file="service/networking/simple-fanout-example.yaml" %}}

 <!--
 When you create the Ingress with `kubectl apply -f`:
@ -804,7 +804,7 @@ the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
 以下 Ingress 让后台负载均衡器基于
 [host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4)来路由请求。

-{{% code file="service/networking/name-virtual-host-ingress.yaml" %}}
+{{% code_sample file="service/networking/name-virtual-host-ingress.yaml" %}}

 <!-- 
 If you create an Ingress resource without any hosts defined in the rules, then any
@ -823,7 +823,7 @@ and `second.bar.com` to `service3`.
 例如，下面的 Ingress 对象会将请求 `first.bar.com` 的流量路由到 `service1`，将请求
 `second.bar.com` 的流量路由到 `service2`，而将所有其他流量路由到 `service3`。

-{{% code file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}}
+{{% code_sample file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}}

 <!--
 ### TLS
@ -882,7 +882,7 @@ section.
 因此，`tls` 字段中的 `hosts` 的取值需要与 `rules` 字段中的 `host` 完全匹配。
 {{< /note >}}

-{{% code file="service/networking/tls-example-ingress.yaml" %}}
+{{% code_sample file="service/networking/tls-example-ingress.yaml" %}}

 {{< note >}}
 <!-- 
@ -1077,4 +1077,3 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 * 进一步了解 [Ingress](/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
 * 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/)
 * [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/)
-
--- a/content/zh-cn/docs/concepts/services-networking/network-policies.md
+++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md
@ -160,7 +160,7 @@ An example NetworkPolicy might look like this:

 下面是一个 NetworkPolicy 的示例:

-{{< codenew file="service/networking/networkpolicy.yaml" >}}
+{{< code_sample file="service/networking/networkpolicy.yaml" >}}

 {{< note >}}
 <!--
@ -391,7 +391,7 @@ that selects all pods but does not allow any ingress traffic to those pods.
 你可以通过创建选择所有 Pod 但不允许任何进入这些 Pod 的入站流量的 NetworkPolicy
 来为名字空间创建 “default” 隔离策略。

-{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+{{< code_sample file="service/networking/network-policy-default-deny-ingress.yaml" >}}

 <!--
 This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated
@ -411,7 +411,7 @@ that explicitly allows that.
 -->
 如果你想允许一个名字空间中所有 Pod 的所有入站连接，你可以创建一个明确允许的策略。

-{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+{{< code_sample file="service/networking/network-policy-allow-all-ingress.yaml" >}}

 <!--
 With this policy in place, no additional policy or policies can cause any incoming connection to
@ -431,7 +431,7 @@ that selects all pods but does not allow any egress traffic from those pods.
 你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy
 来为名字空间创建 “default” 隔离策略。

-{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+{{< code_sample file="service/networking/network-policy-default-deny-egress.yaml" >}}

 <!--
 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed
@ -452,7 +452,7 @@ explicitly allows all outgoing connections from pods in that namespace.
 如果要允许来自名字空间中所有 Pod 的所有连接，
 则可以创建一个明确允许来自该名字空间中 Pod 的所有出站连接的策略。

-{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+{{< code_sample file="service/networking/network-policy-allow-all-egress.yaml" >}}

 <!--
 With this policy in place, no additional policy or policies can cause any outgoing connection from
@ -472,7 +472,7 @@ creating the following NetworkPolicy in that namespace.
 你可以为名字空间创建“默认”策略，以通过在该名字空间中创建以下 NetworkPolicy
 来阻止所有入站和出站流量。

-{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+{{< code_sample file="service/networking/network-policy-default-deny-all.yaml" >}}

 <!--
 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed
@ -524,7 +524,7 @@ This is achievable with the usage of the `endPort` field, as the following examp

 这一目的可以通过使用 `endPort` 字段来实现，如下例所示：

-{{< codenew file="service/networking/networkpolicy-multiport-egress.yaml" >}}
+{{< code_sample file="service/networking/networkpolicy-multiport-egress.yaml" >}}

 <!--
 The above rule allows any Pod with label `role=db` on the namespace `default` to communicate 
@ -619,19 +619,13 @@ namespaces based on their labels.
 -->
 ## 基于名字指向某名字空间   {#targeting-a-namespace-by-its-name}

-{{< feature-state for_k8s_version="1.22" state="stable" >}}
-
 <!--
 The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all
-namespaces, provided that the `NamespaceDefaultLabelName`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled.
-The value of the label is the namespace name.
+namespaces, the value of the label is the namespace name.

 While NetworkPolicy cannot target a namespace by its name with some object field, you can use the
 standardized label to target a specific namespace.
 -->
-只要 `NamespaceDefaultLabelName`
-[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)被启用，
 Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签
 `kubernetes.io/metadata.name`。该标签的值是名字空间的名称。