Skip to content

[zh-cn]sync services-networking/_index network-policies pod-qos intro #55272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
my-git9 wants to merge 1 commit into
base: main
Choose a base branch
from
+65 −36
Open

[zh-cn]sync services-networking/_index network-policies pod-qos intro #55272

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 21 additions & 2 deletions content/zh-cn/docs/concepts/services-networking/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,7 +99,7 @@ Kubernetes 网络模型由几个部分构成：
the outside world.
-->
* [Gateway](/zh-cn/docs/concepts/services-networking/gateway/) API
（或其前身 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
（或其前身 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)）
使得集群外部的客户端能够访问 Service。

* 当使用受支持的 {{< glossary_tooltip term_id="cloud-provider">}} 时，通过 Service API 的
Expand Down Expand Up @@ -153,7 +153,7 @@ of which are optional:
-->
* Pod 网络本身由
[Pod 网络实现](/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy)管理。
在 Linux 上，大多数容器运行时使用{{< glossary_tooltip text="容器网络接口 (CNI)" term_id="cni" >}}
在 Linux 上，大多数容器运行时使用{{< glossary_tooltip text="容器网络接口（CNI）" term_id="cni" >}}
与 Pod 网络实现进行交互，因此这些实现通常被称为 **CNI 插件**。

* Kubernetes 提供了一个默认的服务代理实现，称为 {{< glossary_tooltip term_id="kube-proxy">}}，
Expand Down Expand Up @@ -191,3 +191,22 @@ Service 和 Kubernetes 如何联网。

[集群网络](/zh-cn/docs/concepts/cluster-administration/networking/)解释了如何为集群设置网络，
还概述了所涉及的技术。

<!--
To learn about specific networking concepts, see:

* [Service](/docs/concepts/services-networking/service/) - expose an application behind a single outward-facing endpoint
* [Ingress](/docs/concepts/services-networking/ingress/) - protocol-aware HTTP/HTTPS routing using URIs, hostnames, and paths
* [Gateway API](/docs/concepts/services-networking/gateway/) - dynamic infrastructure provisioning and advanced traffic routing
* [Network Policies](/docs/concepts/services-networking/network-policies/) - control traffic flow at the IP address or port level (OSI layer 3 or 4)
* [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) - discover services within your cluster using DNS
-->
要了解具体的网络概念，请参阅：

* [Service](/zh-cn/docs/concepts/services-networking/service/) - 将应用程序暴露在单个面向外部的端点之后
* [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) - 使用
URI、主机名和路径实现协议感知的 HTTP/HTTPS 路由
* [Gateway API](/zh-cn/docs/concepts/services-networking/gateway/) - 动态基础设施配置和高级流量路由
Copy link
Copy Markdown
Member

@windsonsea windsonsea Apr 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* [Gateway API](/zh-cn/docs/concepts/services-networking/gateway/) - 动态基础设施配置和高级流量路由
* [Gateway API](/zh-cn/docs/concepts/services-networking/gateway/) - 动态基础设施制备和高级流量路由

* [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) - 在
IP 地址或端口级别（OSI 第 3 层或第 4 层）控制流量
* [Service 和 Pod 的 DNS](/zh-cn/docs/concepts/services-networking/dns-pod-service/) - 使用 DNS 发现集群中的服务
30 changes: 21 additions & 9 deletions content/zh-cn/docs/concepts/services-networking/network-policies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -177,7 +177,7 @@ An example NetworkPolicy might look like this:
POSTing this to the API server for your cluster will have no effect unless your chosen networking
solution supports network policy.
-->
除非选择支持网络策略的网络解决方案，否则将上述示例发送到 API 服务器没有任何效果。
除非选择支持 NetworkPolicy 的网络解决方案，否则将上述示例发送到 API 服务器没有任何效果。
{{< /note >}}

<!--
Expand Down Expand Up @@ -256,7 +256,7 @@ So, the example NetworkPolicy:
See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
walkthrough for further examples.
-->
所以，该网络策略示例：
所以，该 NetworkPolicy 示例：

1. 隔离 `default` 名字空间下 `role=db` 的 Pod （如果它们不是已经被隔离的话）。
2. （Ingress 规则）允许以下 Pod 连接到 `default` 名字空间下的带有 `role=db`
Expand Down Expand Up @@ -354,13 +354,6 @@ Cluster ingress and egress mechanisms often require rewriting the source or dest
of packets. In cases where this happens, it is not defined whether this happens before or
after NetworkPolicy processing, and the behavior may be different for different
combinations of network plugin, cloud provider, `Service` implementation, etc.

In the case of ingress, this means that in some cases you may be able to filter incoming
packets based on the actual original source IP, while in other cases, the "source IP" that
the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc.

For egress, this means that connections from pods to `Service` IPs that get rewritten to
cluster-external IPs may or may not be subject to `ipBlock`-based policies.
-->
如有疑问，请使用 `kubectl describe` 查看 Kubernetes 如何解释该策略。

Expand All @@ -371,6 +364,14 @@ cluster-external IPs may or may not be subject to `ipBlock`-based policies.
在发生这种情况时，不确定在 NetworkPolicy 处理之前还是之后发生，
并且对于网络插件、云提供商、`Service` 实现等的不同组合，其行为可能会有所不同。

<!--
In the case of ingress, this means that in some cases you may be able to filter incoming
packets based on the actual original source IP, while in other cases, the "source IP" that
the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc.

For egress, this means that connections from pods to `Service` IPs that get rewritten to
cluster-external IPs may or may not be subject to `ipBlock`-based policies.
-->
对入站流量而言，这意味着在某些情况下，你可以根据实际的原始源 IP 过滤传入的数据包，
而在其他情况下，NetworkPolicy 所作用的 `源IP` 则可能是 `LoadBalancer` 或
Pod 的节点等。
Expand Down Expand Up @@ -451,6 +452,17 @@ egress traffic. This policy does not change the ingress isolation behavior of an
此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。
此策略不会更改任何 Pod 的入站流量隔离行为。

{{< caution >}}
<!--
A default deny-all egress policy also blocks DNS traffic. If your workloads need DNS
resolution, you must add a separate NetworkPolicy that allows egress to your
cluster's DNS service.
-->
默认的拒绝所有出站流量策略也会阻止 DNS 流量。
如果你的工作负载需要 DNS 解析，则必须添加一个单独的 NetworkPolicy，
允许出站流量访问集群的 DNS 服务。
{{< /caution >}}

<!--
### Allow all egress traffic
-->
Expand Down
34 changes: 15 additions & 19 deletions content/zh-cn/docs/concepts/windows/intro.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ weight: 65
-->

<!-- overview -->

<!--
Windows applications constitute a large portion of the services and applications that
run in many organizations. [Windows containers](https://aka.ms/windowscontainers)
Expand Down Expand Up @@ -51,7 +52,8 @@ you can deploy worker nodes running either Windows or Linux.
## Kubernetes 中的 Windows 节点 {#windows-nodes-in-k8s}

若要在 Kubernetes 中启用对 Windows 容器的编排，可以在现有的 Linux 集群中包含 Windows 节点。
在 Kubernetes 上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中的 Windows 容器与调度基于 Linux 的容器类似。
在 Kubernetes 上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中的 Windows
容器与调度基于 Linux 的容器类似。

为了运行 Windows 容器，你的 Kubernetes 集群必须包含多个操作系统。
尽管你只能在 Linux 上运行{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}，
Expand Down Expand Up @@ -210,18 +212,9 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。

<!--
* [Workload resources](/docs/concepts/workloads/controllers/) including:
* ReplicaSet
* Deployment
* StatefulSet
* DaemonSet
* Job
* CronJob
* ReplicationController
* {{< glossary_tooltip text="Services" term_id="service" >}}
See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details.
-->
* [工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)包括：

* ReplicaSet
* Deployment
* StatefulSet
Expand All @@ -230,6 +223,10 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
* CronJob
* ReplicationController

<!--
* {{< glossary_tooltip text="Services" term_id="service" >}}
See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details.
-->
* {{< glossary_tooltip text="Services" term_id="service" >}}

有关更多详细信息，请参考[负载均衡和 Service](/zh-cn/docs/concepts/services-networking/windows-networking/#load-balancing-and-services)。
Expand Down Expand Up @@ -357,7 +354,12 @@ passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.

The following list documents differences between how Pod container specifications
work between Windows and Linux:
-->
#### 容器规约的字段兼容性 {#compatibility-v1-pod-spec-containers}

以下列表记录了 Pod 容器规约在 Windows 和 Linux 之间的工作方式差异：

<!--
* Huge pages are not implemented in the Windows container
runtime, and are not available. They require [asserting a user
privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
Expand All @@ -368,10 +370,6 @@ work between Windows and Linux:
node. They should be applied to all containers as a best practice if the operator
wants to avoid overprovisioning entirely.
-->
#### 容器规约的字段兼容性 {#compatibility-v1-pod-spec-containers}

以下列表记录了 Pod 容器规约在 Windows 和 Linux 之间的工作方式差异：

* 巨页（Huge page）在 Windows 容器运行时中未实现，且不可用。
巨页需要不可为容器配置的[用户特权生效](https://docs.microsoft.com/zh-cn/windows/win32/memory/large-page-support)。
* `requests.cpu` 和 `requests.memory` -
Expand Down Expand Up @@ -467,7 +465,7 @@ The following list documents differences between how Pod specifications work bet
supported on Windows.
-->
* `terminationGracePeriodSeconds` - 这在 Windows 上的 Docker 中没有完全实现，
请参考 [GitHub issue](https://github.com/moby/moby/issues/25982)。
请参考 [GitHub Issue](https://github.com/moby/moby/issues/25982)。
目前的行为是通过 CTRL_SHUTDOWN_EVENT 发送 ENTRYPOINT 进程，然后 Windows 默认等待 5 秒，
最后使用正常的 Windows 关机行为终止所有进程。
5 秒默认值实际上位于[容器内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)的
Expand Down Expand Up @@ -626,8 +624,7 @@ See [Install MCR on Windows Servers](https://docs.mirantis.com/mcr/25.0/install/
## Windows OS version compatibility {#windows-os-version-support}

On Windows nodes, strict compatibility rules apply where the host OS version must
match the container base image OS version. Only Windows containers with a container
operating system of Windows Server 2019 are fully supported.
match the container base image OS version.

For Kubernetes v{{< skew currentVersion >}}, operating system compatibility for Windows nodes (and Pods)
is as follows:
Expand All @@ -636,7 +633,6 @@ is as follows:

在 Windows 节点上，如果主机操作系统版本必须与容器基础镜像操作系统版本匹配，
则会应用严格的兼容性规则。
仅 Windows Server 2019 作为容器操作系统时，才能完全支持 Windows 容器。

对于 Kubernetes v{{< skew currentVersion >}}，Windows 节点（和 Pod）的操作系统兼容性如下：

Expand Down
14 changes: 8 additions & 6 deletions content/zh-cn/docs/concepts/workloads/pods/pod-qos.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,14 +84,14 @@ For a Pod to be given a QoS class of `Guaranteed`:
Pod 被赋予 `Guaranteed` QoS 类的几个判据：

<!--
* Every Container in the Pod must have a memory limit and a memory request.
* Every Container in the Pod must have a memory limit and a memory request, both greater than zero.
* For every Container in the Pod, the memory limit must equal the memory request.
* Every Container in the Pod must have a CPU limit and a CPU request.
* Every Container in the Pod must have a CPU limit and a CPU request, both greater than zero.
* For every Container in the Pod, the CPU limit must equal the CPU request.
-->
* Pod 中的每个容器必须有内存 limit 和内存 request。
* Pod 中的每个容器必须有内存 limit 和内存 request，两者都必须大于零。
* 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。
* Pod 中的每个容器必须有 CPU limit 和 CPU request。
* Pod 中的每个容器必须有 CPU limit 和 CPU request，两者都必须大于零。
* 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。

<!--
Expand All @@ -102,7 +102,8 @@ If instead the Pod uses [Pod-level resources](/docs/concepts/configuration/manag
* The Pod must have a Pod-level memory limit and memory request, and their values must be equal.
* The Pod must have a Pod-level CPU limit and CPU request, and their values must be equal.
-->
如果 Pod 使用的是 [Pod 级别资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#pod-level-resource-specification)：
如果 Pod 使用的是
[Pod 级别资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#pod-level-resource-specification)：

{{< feature-state feature_gate_name="PodLevelResources" >}}

Expand Down Expand Up @@ -140,7 +141,8 @@ A Pod is given a QoS class of `Burstable` if:
Pod 被赋予 `Burstable` QoS 类的几个判据：

* Pod 不满足针对 QoS 类 `Guaranteed` 的判据。
* Pod 中至少一个容器有内存或 CPU 的 request 或 limit，或者 Pod 本身设置了 Pod 级别的内存或 CPU 的 request 或 limit。
* Pod 中至少一个容器有内存或 CPU 的 request 或 limit，或者 Pod 本身设置了 Pod 级别的内存或
CPU 的 request 或 limit。

### BestEffort

Expand Down