whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Resync concepts section (4)

Browse Source
This commit is contained in:
Qiming Teng
2021-04-27 19:35:21 +08:00
parent a22aa8fd4f
commit 7499d8de03
3 changed files with 249 additions and 144 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/services-networking/dual-stack.md
+105 -83
View File
@@ -26,46 +26,46 @@ weight: 70
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
<!--
IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
-->
IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给
IPv4/IPv6 双协议栈网络能够将 IPv4 和 IPv6 地址分配给
{{< glossary_tooltip text="Pod" term_id="pod" >}} 和
{{< glossary_tooltip text="Service" term_id="service" >}}。
<!--
If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.
IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses.
-->
如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，
则该集群将支持同时分配 IPv4 和 IPv6 地址。
从 1.21 版本开始，Kubernetes 集群默认启用 IPv4/IPv6 双协议栈网络，
以支持同时分配 IPv4 和 IPv6 地址。
<!-- body -->
<!--
## Supported Features
-->
## 支持的功能
## 支持的功能 {#supported-features}
<!--
Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features:
IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features:
-->
在 Kubernetes 集群上启用 IPv4/IPv6 双协议栈可提供下面的功能：
Kubernetes 集群的 IPv4/IPv6 双协议栈可提供下面的功能：
<!--
* Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod)
* IPv4 and IPv6 enabled Services
* Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces
-->
* 双协议栈 pod 网络 (每个 pod 分配一个 IPv4 和 IPv6 地址)
* IPv4 和 IPv6 启用的服务
* Pod 的集群外出口通过 IPv4 和 IPv6 路由
* 双协议栈 pod 网络 (每个 pod 分配一个 IPv4 和 IPv6 地址)
* IPv4 和 IPv6 启用的服务
* Pod 的集群外出口通过 IPv4 和 IPv6 路由
<!--
## Prerequisites
-->
## 先决条件
## 先决条件 {#prerequisites}
<!--
The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters:
@@ -80,61 +80,62 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
* A network plugin that supports dual-stack (such as Kubenet or Calico)
-->
* Kubernetes 1.20 版本及更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息，请参考那个版本的 Kubernetes 文档。
* 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口）
* 支持双协议栈的网络插件（如 Kubenet 或 Calico）
* Kubernetes 1.20 版本或更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息，
请参考对应版本的 Kubernetes 文档。
* 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes
节点提供可路由的 IPv4/IPv6 网络接口）
* 支持双协议栈的网络插件（如 Kubenet 或 Calico）
<!--
## Enable IPv4/IPv6 dual-stack
## Configure IPv4/IPv6 dual-stack
-->
## 启用 IPv4/IPv6 双协议栈
## 配置 IPv4/IPv6 双协议栈
<!--
To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments:
To use IPv4/IPv6 dual-stack, ensure the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled for the relevant components of your cluster. (Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.)
-->
要使用 IPv4/IPv6 双协议栈，确保为集群的相关组件启用 `IPv6DualStack`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
（从 1.21 版本开始，IPv4/IPv6 双协议栈默认是被启用的）。
<!--
* kube-apiserver:
* `--feature-gates="IPv6DualStack=true"`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager:
* `--feature-gates="IPv6DualStack=true"`
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6
* kubelet:
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
-->
要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
并且设置双协议栈的集群网络分配：
* kube-apiserver:
* `--feature-gates="IPv6DualStack=true"`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager:
* `--feature-gates="IPv6DualStack=true"`
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24，对于 IPv6 默认为 /64
* kubelet:
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
* kube-apiserver:
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24，对于 IPv6 默认为 /64
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
{{< note >}}
<!--
An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range)
An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193))
-->
{{< note >}}
IPv4 CIDR 的一个例子：`10.244.0.0/16`（尽管你会提供你自己的地址范围）
IPv6 CIDR 的一个例子：`fdXY:IJKL:MNOP:15::/64`（这里演示的是格式而非有效地址 - 请看 [RFC 4193](https://tools.ietf.org/html/rfc4193)）
IPv4 CIDR 的一个例子：`10.244.0.0/16`（尽管你会提供你自己的地址范围）。
IPv6 CIDR 的一个例子：`fdXY:IJKL:MNOP:15::/64`
（这里演示的是格式而非有效地址 - 请看 [RFC 4193](https://tools.ietf.org/html/rfc4193)）。
<!--
Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.
You can disable it when necessary by specifying `--feature-gates="IPv6DualStack=false"`
on the kube-apiserver, kube-controller-manager, kubelet, and kube-proxy command line.
-->
从 1.21 开始 IPv4/IPv6 双协议栈默认为启用状态。
你可以在必要的时候通过为 kube-apiserver、kube-controller-manager、kubelet
和 kube-proxy 命令行设置 `--feature-gates="IPv6DualStack=false"` 来禁用
此特性。
{{< /note >}}
<!--
@@ -143,47 +144,49 @@ IPv6 CIDR 的一个例子：`fdXY:IJKL:MNOP:15::/64`（这里演示的是格式
## 服务
<!--
If your cluster has dual-stack enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both.
You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both.
The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver).
When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you
set the `.spec.ipFamilyPolicy` field to one of the following values:
-->
如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建
你可以使用 IPv4 或 IPv6 地址来创建
{{< glossary_tooltip text="Service" term_id="service" >}}。
服务的地址族默认为第一个服务集群 IP 范围的地址族（通过 kube-apiserver 的 `--service-cluster-ip-range` 参数配置）。
当你定义服务时，可以选择将其配置为双栈。若要指定所需的行为，你可以设置 `.spec.ipFamilyPolicy` 字段为以下值之一：
服务的地址族默认为第一个服务集群 IP 范围的地址族（通过 kube-apiserver 的
`--service-cluster-ip-range` 参数配置）。
当你定义服务时，可以选择将其配置为双栈。若要指定所需的行为，你可以设置
`.spec.ipFamilyPolicy` 字段为以下值之一：
<!--
* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range.
* `PreferDualStack`:
* Only used if the cluster has dual-stack enabled. Allocates IPv4 and IPv6 cluster IPs for the Service
* If the cluster does not have dual-stack enabled, this setting follows the same behavior as `SingleStack`.
* Allocates IPv4 and IPv6 cluster IPs for the Service. (If the cluster has `--feature-gates="IPv6DualStack=false"`, this setting follows the same behavior as `SingleStack`.)
* `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges.
* Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array.
* The cluster must have dual-stack networking configured.
-->
* `SingleStack`：单栈服务。控制面使用第一个配置的服务集群 IP 范围为服务分配集群 IP。
* `PreferDualStack`：
* 仅当集群启用了双栈时使用。为服务分配 IPv4 和 IPv6 集群 IP。
* 如果集群没有启用双堆栈，则此设置与 `SingleStack` 行为相同。
* 为服务分配 IPv4 和 IPv6 集群 IP 地址。
（如果集群设置了 `--feature-gates="IPv6DualStack=false"`，则此设置的行为与
`SingleStack` 设置相同。）
* `RequireDualStack`：从 IPv4 和 IPv6 的地址范围分配服务的 `.spec.ClusterIPs`
* 从基于在 `.spec.ipFamilies` 数组中第一个元素的地址族的 `.spec.ClusterIPs` 列表中选择 `.spec.ClusterIP`
* 集群必须配置双栈网络
* 从基于在 `.spec.ipFamilies` 数组中第一个元素的地址族的 `.spec.ClusterIPs`
列表中选择 `.spec.ClusterIP`
<!--
If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service.
-->
如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置服务上的可选字段 `.spec.ipFamilies` 来选择地址族。
如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置
服务上的可选字段 `.spec.ipFamilies` 来选择地址族。
{{< note >}}
<!--
The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service.
-->
{{< note >}}
`.spec.ipFamilies` 字段是不可变的，因为系统无法为已经存在的服务重新分配 `.spec.ClusterIP`。
如果你想改变 `.spec.ipFamilies`，则需要删除并重新创建服务。
`.spec.ipFamilies` 字段是不可变的，因为系统无法为已经存在的服务重新分配
`.spec.ClusterIP`。如果你想改变 `.spec.ipFamilies`，则需要删除并重新创建服务。
{{< /note >}}
<!--
@@ -206,7 +209,6 @@ You can set `.spec.ipFamilies` to any of the following array values:
<!--
The first family you list is used for the legacy `.spec.ClusterIP` field.
-->
你所列出的第一个地址族用于原来的 `.spec.ClusterIP` 字段。
<!--
@@ -214,7 +216,6 @@ The first family you list is used for the legacy `.spec.ClusterIP` field.
These examples demonstrate the behavior of various dual-stack Service configuration scenarios.
-->
### 双栈服务配置场景
以下示例演示多种双栈服务配置场景下的行为。
@@ -231,8 +232,8 @@ These examples demonstrate the behavior of various dual-stack Service configurat
1. 此服务规约中没有显式设定 `.spec.ipFamilyPolicy`。当你创建此服务时，Kubernetes
从所配置的第一个 `service-cluster-ip-range` 种为服务分配一个集群IP，并设置
`.spec.ipFamilyPolicy` 为 `SingleStack`。
（[无选择算符的服务](/zh/docs/concepts/services-networking/service/#services-without-selectors)和
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的行为方式
（[无选择算符的服务](/zh/docs/concepts/services-networking/service/#services-without-selectors)
和[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的行为方式
与此相同。）
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
@@ -251,6 +252,13 @@ These examples demonstrate the behavior of various dual-stack Service configurat
字段 `.spec.ClusterIPs` 是主要字段，包含两个分配的 IP 地址；`.spec.ClusterIP` 是次要字段，
其取值从 `.spec.ClusterIPs` 计算而来。
* 对于 `.spec.ClusterIP` 字段，控制面记录来自第一个服务集群 IP 范围
对应的地址族的 IP 地址。
* 对于单协议栈的集群，`.spec.ClusterIPs` 和 `.spec.ClusterIP` 字段都
仅仅列出一个地址。
* 对于启用了双协议栈的集群，将 `.spec.ipFamilyPolicy` 设置为
`RequireDualStack` 时，其行为与 `PreferDualStack` 相同。
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
<!--
@@ -270,15 +278,18 @@ These examples demonstrate the behavior of various dual-stack Service configurat
#### 现有服务的双栈默认值
<!--
These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist.
These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 will enable dual-stack unless `--feature-gates="IPv6DualStack=false"` is set.)
-->
下面示例演示了在服务已经存在的集群上新启用双栈时的默认行为。
（将现有集群升级到 1.21 会启用双协议栈支持，除非设置了
`--feature-gates="IPv6DualStack=false"`）
<!--
1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`.
-->
1. 在集群上启用双栈时，控制面会将现有服务（无论是 `IPv4` 还是 `IPv6`）配置 `.spec.ipFamilyPolicy`
设置为 `SingleStack` 并设置 `.spec.ipFamilies` 为服务的当前地址族。
1. 在集群上启用双栈时，控制面会将现有服务（无论是 `IPv4` 还是 `IPv6`）配置
`.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies`
为服务的当前地址族。
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
@@ -322,7 +333,7 @@ These examples demonstrate the default behavior when dual-stack is newly enabled
2. 在集群上启用双栈时，带有选择算符的现有
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
由控制面设置 `.spec.ipFamilyPolicy` 为 `SingleStack`
并设置 `.spec.ipFamilies` 为第一个服务群集 IP 范围的地址族（通过配置 kube-apiserver 的
并设置 `.spec.ipFamilies` 为第一个服务集群 IP 范围的地址族（通过配置 kube-apiserver 的
`--service-cluster-ip-range` 参数），即使 `.spec.ClusterIP` 的设置值为 `None` 也如此。
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
@@ -375,21 +386,25 @@ Services can be changed from single-stack to dual-stack and from dual-stack to s
-->
1. 要将服务从单栈更改为双栈，根据需要将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为
`PreferDualStack` 或 `RequireDualStack`。
当你将此服务从单栈更改为双栈时，Kubernetes 将分配缺失的地址族，以便现在该服务具有 IPv4 和 IPv6 地址。
当你将此服务从单栈更改为双栈时，Kubernetes 将分配缺失的地址族，以便现在
该服务具有 IPv4 和 IPv6 地址。
编辑服务规约将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为 `PreferDualStack`。
<!--
Before:
-->
之前：
```yaml
spec:
ipFamilyPolicy: SingleStack
```
<!--
After:
-->
之后：
```yaml
spec:
ipFamilyPolicy: PreferDualStack
@@ -399,9 +414,10 @@ Services can be changed from single-stack to dual-stack and from dual-stack to s
1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address family of `.spec.ClusterIPs`.
-->
2. 要将服务从双栈更改为单栈，请将 `.spec.ipFamilyPolicy` 从 `PreferDualStack` 或 `RequireDualStack`
改为 `SingleStack`。
当你将此服务从双栈更改为单栈时，Kubernetes 只保留 `.spec.ClusterIPs` 数组中的第一个元素，并设置 `.spec.ClusterIP` 为那个 IP 地址，
2. 要将服务从双栈更改为单栈，请将 `.spec.ipFamilyPolicy` 从 `PreferDualStack` 或
`RequireDualStack` 改为 `SingleStack`。
当你将此服务从双栈更改为单栈时，Kubernetes 只保留 `.spec.ClusterIPs`
数组中的第一个元素，并设置 `.spec.ClusterIP` 为那个 IP 地址，
并设置 `.spec.ipFamilies` 为 `.spec.ClusterIPs` 地址族。
<!--
@@ -413,7 +429,8 @@ Services can be changed from single-stack to dual-stack and from dual-stack to s
For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to `RequireDualStack`.
-->
对于[不带选择算符的无头服务](/zh/docs/concepts/services-networking/service/#without-selectors)，
若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` 字段默认设置为 `RequireDualStack`。
若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy`
字段默认设置为 `RequireDualStack`。
<!--
### Service type LoadBalancer
@@ -425,15 +442,15 @@ To provision a dual-stack load balancer for your Service:
* Set the `.spec.type` field to `LoadBalancer`
* Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack`
-->
要为你的服务提供双栈负载均衡器：
* 将 `.spec.type` 字段设置为 `LoadBalancer`
* 将 `.spec.ipFamilyPolicy` 字段设置为 `PreferDualStack` 或者 `RequireDualStack`
* 将 `.spec.type` 字段设置为 `LoadBalancer`
* 将 `.spec.ipFamilyPolicy` 字段设置为 `PreferDualStack` 或者 `RequireDualStack`
{{< note >}}
<!--
To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 load balancers.
-->
{{< note >}}
为了使用双栈的负载均衡器类型服务，你的云驱动必须支持 IPv4 和 IPv6 的负载均衡器。
{{< /note >}}
@@ -445,13 +462,16 @@ To use a dual-stack `LoadBalancer` type Service, your cloud provider must suppor
<!--
If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project supports IP masquerading on dual-stack clusters.
-->
如果你要启用出口流量，以便使用非公开路由 IPv6 地址的 Pod 到达集群外地址（例如公网），则需要通过透明代理或 IP 伪装等机制使 Pod 使用公共路由的 IPv6 地址。
[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)项目支持在双栈集群上进行 IP 伪装。
如果你要启用出站流量，以便使用非公开路由 IPv6 地址的 Pod 到达集群外地址
（例如公网），则需要通过透明代理或 IP 伪装等机制使 Pod 使用公共路由的
IPv6 地址。
[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)项目
支持在双栈集群上进行 IP 伪装。
{{< note >}}
<!--
Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6.
-->
{{< note >}}
确认你的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 驱动支持 IPv6。
{{< /note >}}
@@ -459,5 +479,7 @@ Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports
<!--
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
* [Enable dual-stack networking using kubeadm ](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
-->
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络
* [使用 kubeadm 启用双协议栈网络](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
content/zh/docs/concepts/services-networking/endpoint-slices.md
+44 -51
View File
@@ -1,25 +1,27 @@
---
title: 端点切片（Endpoint Slices）
content_type: concept
weight: 35
weight: 45
---
<!--
reviewers:
- freehan
title: Endpoint Slices
content_type: concept
weight: 35
weight: 45
-->
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
<!--
_Endpoint Slices_ provide a simple way to track network endpoints within a
_EndpointSlices_ provide a simple way to track network endpoints within a
Kubernetes cluster. They offer a more scalable and extensible alternative to
Endpoints.
-->
_端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点
_端点切片（EndpointSlices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点
（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。
<!-- body -->
@@ -85,7 +87,7 @@ EndpointSlice 的名称必须是合法的
例如，下面是 Kubernetes 服务 `example` 的 EndpointSlice 资源示例。
```yaml
apiVersion: discovery.k8s.io/v1beta1
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: example-abc
@@ -102,9 +104,8 @@ endpoints:
conditions:
ready: true
hostname: pod-1
topology:
kubernetes.io/hostname: node-1
topology.kubernetes.io/zone: us-west2-a
nodeName: node-1
zone: us-west2-a
```
<!--
@@ -228,55 +229,47 @@ For pods, this is any pod that has a deletion timestamp set.
<!--
### Topology information {#topology}
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
{{< note >}}
The topology field in EndpointSlices has been deprecated and will be removed in
a future release. A new `nodeName` field will be used instead of setting
`kubernetes.io/hostname` in topology. It was determined that other topology
fields covering zone and region would be better represented as EndpointSlice
labels that would apply to all endpoints within the EndpointSlice.
{{< /note >}}
Each endpoint within an EndpointSlice can contain relevant topology information.
This is used to indicate where an endpoint is, containing information about the
corresponding Node, zone, and region. When the values are available, the
control plane sets the following Topology labels for EndpointSlices:
The topology information includes the location of the endpoint and information
about the corresponding Node and zone. These are available in the following
per endpoint fields on EndpointSlices:
-->
### 拓扑信息 {#topology}
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
EndpointSlice 中的每个端点都可以包含一定的拓扑信息。
拓扑信息包括端点的位置，对应节点、可用区的信息。
这些信息体现为 EndpointSlices 的如下端点字段：
<!--
* `nodeName` - The name of the Node this endpoint is on.
* `zone` - The zone this endpoint is in.
-->
* `nodeName` - 端点所在的 Node 名称；
* `zone` - 端点所处的可用区。
{{< note >}}
EndpointSlices 中的 topology 字段已被弃用，并将在以后的版本中删除。
将使用新的 `nodeName` 字段代替在 topology 中设置 `kubernetes.io/hostname`。
可以确定的是，其他覆盖区和域的拓扑字段用 EndpointSlice 标签来表达更合适，
该标签将应用于 EndpointSlice 内的所有端点。
<!--
In the v1 API, the per endpoint `topology` was effectively removed in favor of
the dedicated fields `nodeName` and `zone`.
-->
在 v1 API 中，逐个端点设置的 `topology` 实际上被去除，以鼓励使用专用
的字段 `nodeName` 和 `zone`。
<!--
Setting arbitrary topology fields on the `endpoint` field of an `EndpointSlice`
resource has been deprecated and is not be supported in the v1 API. Instead,
the v1 API supports setting individual `nodeName` and `zone` fields. These
fields are automatically translated between API versions. For example, the
value of the `"topology.kubernetes.io/zone"` key in the `topology` field in
the v1beta1 API is accessible as the `zone` field in the v1 API.
-->
对 `EndpointSlice` 对象的 `endpoint` 字段设置任意的拓扑结构信息这一操作已被
废弃，不再被 v1 API 所支持。取而代之的是 v1 API 所支持的 `nodeName` 和 `zone`
这些独立的字段。这些字段可以在不同的 API 版本之间自动完成转译。
例如，v1beta1 API 中 `topology` 字段的 `topology.kubernetes.io/zone` 取值可以
在 v1 API 中通过 `zone` 字段访问。
{{< /note >}}
EndpointSlice 中的每个端点都可以包含一定的拓扑信息。
这一信息用来标明端点的位置，包含对应节点、可用区、区域的信息。
当这些值可用时，控制面会为 EndpointSlice 设置如下拓扑标签：
<!--
* `kubernetes.io/hostname` - The name of the Node this endpoint is on.
* `topology.kubernetes.io/zone` - The zone this endpoint is in.
* `topology.kubernetes.io/region` - The region this endpoint is in.
-->
* `kubernetes.io/hostname` - 端点所在的节点名称
* `topology.kubernetes.io/zone` - 端点所处的可用区
* `topology.kubernetes.io/region` - 端点所处的区域
<!--
The values of these labels are derived from resources associated with each
endpoint in a slice. The hostname label represents the value of the NodeName
field on the corresponding Pod. The zone and region labels represent the value
of the labels with the same names on the corresponding Node.
-->
这些标签的值时根据与切片中各个端点相关联的资源来生成的。
标签 `hostname` 代表的是对应的 Pod 的 NodeName 字段的取值。
`zone` 和 `region` 标签则代表的是对应的节点所拥有的同名标签的值。
<!--
### Management
@@ -288,7 +281,7 @@ entities or controllers managing additional sets of EndpointSlices.
-->
### 管理 {#management}
通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="controller" term_id="controller" >}}）
通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="控制器" term_id="controller" >}}）
会创建和管理 EndpointSlice 对象。EndpointSlice 对象还有一些其他使用场景，
例如作为服务网格（Service Mesh）的实现。这些场景都会导致有其他实体
或者控制器负责管理额外的 EndpointSlice 集合。
content/zh/docs/concepts/services-networking/network-policies.md
+100 -10
View File
@@ -427,47 +427,138 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
{{< note >}}
<!--
You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
-->
{{< note >}}
你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
{{< /note >}}
<!--
## Targeting a range of Ports
-->
## 针对某个端口范围 {#targeting-a-range-of-ports}
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
<!--
When writing a NetworkPolicy, you can target a range of ports instead of a single port.
This is achievable with the usage of the `endPort` field, as the following example:
-->
在编写 NetworkPolicy 时，你可以针对一个端口范围而不是某个固定端口。
这一目的可以通过使用 `endPort` 字段来实现，如下例所示：
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: multi-port-egress
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 32000
endPort: 32768
```
<!--
The above rule allows any Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` over TCP, provided that the target port is between the range 32000 and 32768.
-->
上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议
与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。
<!--
The following restrictions apply when using this field:
* As an alpha feature, this is disabled by default. To enable the `endPort` field at a cluster level, you (or your cluster administrator) need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=NetworkPolicyEndPort=true,…`.
* The `endPort` field must be equal than or greater to the `port` field.
* `endPort` can only be defined if `port` is also defined.
* Both ports must be numeric.
-->
使用此字段时存在以下限制：
* 作为一种 Alpha 阶段的特性，端口范围设定默认是被禁用的。要在整个集群
范围内允许使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
服务器设置 `-feature-gates=NetworkPolicyEndPort=true,...` 以启用
`NetworkPolicyEndPort`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
* `endPort` 字段必须等于或者大于 `port` 字段的值。
* 两个字段的设置值都只能是数字。
{{< note >}}
<!--
Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that
supports the `endPort` field in NetworkPolicy specifications.
-->
你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件
必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。
{{< /note >}}
<!--
## Targeting a Namespace by its name
-->
## 基于名字指向某名字空间 {#targeting-a-namespace-by-its-name}
{{< feature-state state="beta" for_k8s_version="1.21" >}}
<!--
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.
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/docs/reference/command-line-tools-reference/feature-gates/)
被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签
`kubernetes.io/metadata.name`。该标签的值是名字空间的名称。
如果 NetworkPolicy 无法在某些对象字段中指向某名字空间，你可以使用标准的
标签方式来指向特定名字空间。
<!--
## What you can't do with network policies (at least, not yet)
As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API.
As of Kubernetes {{< skew latestVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.
-->
## 你通过网络策略（至少目前还）无法完成的工作
## 通过网络策略（至少目前还）无法完成的工作
到 Kubernetes v1.20 为止，NetworkPolicy API 还不支持以下功能，不过
到 Kubernetes {{< skew latestVersion >}} 为止，NetworkPolicy API 还不支持以下功能，不过
你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等）
或者第七层技术（Ingress 控制器、服务网格实现）或准入控制器来实现一些
替代方案。
如果你对 Kubernetes 中的网络安全性还不太了解，了解使用 NetworkPolicy API
还无法实现下面的用户场景是很值得的。
对这些用户场景中的一部分（而非全部）的讨论扔在进行，或许在将来 NetworkPolicy
API 中会给出一定支持。
<!--
- Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
- Anything TLS related (use a service mesh or ingress controller for this).
- Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically).
- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
- Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
- Creation or management of "Policy requests" that are fulfilled by a third party.
-->
- 强制集群内部流量经过某公用网关（这种场景最好通过服务网格或其他代理来实现）；
- 与 TLS 相关的场景（考虑使用服务网格或者 Ingress 控制器）；
- 特定于节点的策略（你可以使用 CIDR 来表达这一需求不过你无法使用节点在
Kubernetes 中的其他标识信息来辩识目标节点）；
- 基于名字来选择名字空间或者服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}}
- 基于名字来选择服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}}
来选择目标 Pod 或名字空间，这也通常是一种可靠的替代方案）；
- 创建或管理由第三方来实际完成的“策略请求”；
<!--
- Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this).
- Advanced policy querying and reachability tooling.
- The ability to target ranges of Ports in a single policy declaration.
- The ability to log network security events (for example connections that are blocked or accepted).
- The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules).
- The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node).
@@ -475,7 +566,6 @@ API 中会给出一定支持。
- 实现适用于所有名字空间或 Pods 的默认策略（某些第三方 Kubernetes 发行版本
或项目可以做到这点）；
- 高级的策略查询或者可达性相关工具；
- 在同一策略声明中选择目标端口范围的能力；
- 生成网络安全事件日志的能力（例如，被阻塞或接收的连接请求）；
- 显式地拒绝策略的能力（目前，NetworkPolicy 的模型默认采用拒绝操作，
其唯一的能力是添加允许策略）；