From 7499d8de034bf4068fc1f04e91fd7562a854dcc0 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 27 Apr 2021 19:35:21 +0800 Subject: [PATCH] [zh] Resync concepts section (4) --- .../services-networking/dual-stack.md | 188 ++++++++++-------- .../services-networking/endpoint-slices.md | 95 ++++----- .../services-networking/network-policies.md | 110 +++++++++- 3 files changed, 249 insertions(+), 144 deletions(-) diff --git a/content/zh/docs/concepts/services-networking/dual-stack.md b/content/zh/docs/concepts/services-networking/dual-stack.md index f01bd78038..e1d5516bec 100644 --- a/content/zh/docs/concepts/services-networking/dual-stack.md +++ b/content/zh/docs/concepts/services-networking/dual-stack.md @@ -26,46 +26,46 @@ weight: 70 -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 +IPv4/IPv6 双协议栈网络能够将 IPv4 和 IPv6 地址分配给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 和 {{< glossary_tooltip text="Service" term_id="service" >}}。 -如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络， -则该集群将支持同时分配 IPv4 和 IPv6 地址。 +从 1.21 版本开始，Kubernetes 集群默认启用 IPv4/IPv6 双协议栈网络， +以支持同时分配 IPv4 和 IPv6 地址。 -## 支持的功能 +## 支持的功能 {#supported-features} -在 Kubernetes 集群上启用 IPv4/IPv6 双协议栈可提供下面的功能： +Kubernetes 集群的 IPv4/IPv6 双协议栈可提供下面的功能： - * 双协议栈 pod 网络 (每个 pod 分配一个 IPv4 和 IPv6 地址) - * IPv4 和 IPv6 启用的服务 - * Pod 的集群外出口通过 IPv4 和 IPv6 路由 +* 双协议栈 pod 网络 (每个 pod 分配一个 IPv4 和 IPv6 地址) +* IPv4 和 IPv6 启用的服务 +* Pod 的集群外出口通过 IPv4 和 IPv6 路由 -## 先决条件 +## 先决条件 {#prerequisites} - * Kubernetes 1.20 版本及更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息，请参考那个版本的 Kubernetes 文档。 - * 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口） - * 支持双协议栈的网络插件（如 Kubenet 或 Calico） +* Kubernetes 1.20 版本或更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息， + 请参考对应版本的 Kubernetes 文档。 +* 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes + 节点提供可路由的 IPv4/IPv6 网络接口） +* 支持双协议栈的网络插件（如 Kubenet 或 Calico） -## 启用 IPv4/IPv6 双协议栈 +## 配置 IPv4/IPv6 双协议栈 +要使用 IPv4/IPv6 双协议栈，确保为集群的相关组件启用 `IPv6DualStack` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +（从 1.21 版本开始，IPv4/IPv6 双协议栈默认是被启用的）。 + -要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， -并且设置双协议栈的集群网络分配： - - * kube-apiserver: - * `--feature-gates="IPv6DualStack=true"` - * `--service-cluster-ip-range=,` - * kube-controller-manager: - * `--feature-gates="IPv6DualStack=true"` - * `--cluster-cidr=,` - * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24，对于 IPv6 默认为 /64 - * kubelet: - * `--feature-gates="IPv6DualStack=true"` - * kube-proxy: - * `--cluster-cidr=,` - * `--feature-gates="IPv6DualStack=true"` +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--cluster-cidr=,` + * `--service-cluster-ip-range=,` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24，对于 IPv6 默认为 /64 +* kube-proxy: + * `--cluster-cidr=,` +{{< note >}} -{{< 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)）。 + +从 1.21 开始 IPv4/IPv6 双协议栈默认为启用状态。 +你可以在必要的时候通过为 kube-apiserver、kube-controller-manager、kubelet +和 kube-proxy 命令行设置 `--feature-gates="IPv6DualStack=false"` 来禁用 +此特性。 {{< /note >}} -如果你的集群启用了 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`：单栈服务。控制面使用第一个配置的服务集群 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` + -如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置服务上的可选字段 `.spec.ipFamilies` 来选择地址族。 +如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置 +服务上的可选字段 `.spec.ipFamilies` 来选择地址族。 +{{< note >}} -{{< note >}} -`.spec.ipFamilies` 字段是不可变的，因为系统无法为已经存在的服务重新分配 `.spec.ClusterIP`。 -如果你想改变 `.spec.ipFamilies`，则需要删除并重新创建服务。 +`.spec.ipFamilies` 字段是不可变的，因为系统无法为已经存在的服务重新分配 +`.spec.ClusterIP`。如果你想改变 `.spec.ipFamilies`，则需要删除并重新创建服务。 {{< /note >}} - 你所列出的第一个地址族用于原来的 `.spec.ClusterIP` 字段。 - ### 双栈服务配置场景 以下示例演示多种双栈服务配置场景下的行为。 @@ -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" >}} 下面示例演示了在服务已经存在的集群上新启用双栈时的默认行为。 +（将现有集群升级到 1.21 会启用双协议栈支持，除非设置了 +`--feature-gates="IPv6DualStack=false"`） -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`。 之前： + ```yaml spec: ipFamilyPolicy: SingleStack ``` + 之后： + ```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` 地址族。 对于[不带选择算符的无头服务](/zh/docs/concepts/services-networking/service/#without-selectors)， -若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` 字段默认设置为 `RequireDualStack`。 +若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` +字段默认设置为 `RequireDualStack`。 - 要为你的服务提供双栈负载均衡器： - * 将 `.spec.type` 字段设置为 `LoadBalancer` - * 将 `.spec.ipFamilyPolicy` 字段设置为 `PreferDualStack` 或者 `RequireDualStack` +* 将 `.spec.type` 字段设置为 `LoadBalancer` +* 将 `.spec.ipFamilyPolicy` 字段设置为 `PreferDualStack` 或者 `RequireDualStack` + +{{< note >}} -{{< note >}} 为了使用双栈的负载均衡器类型服务，你的云驱动必须支持 IPv4 和 IPv6 的负载均衡器。 {{< /note >}} @@ -445,13 +462,16 @@ To use a dual-stack `LoadBalancer` type Service, your cloud provider must suppor -如果你要启用出口流量，以便使用非公开路由 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 >}} -{{< 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 -* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络 \ No newline at end of file +* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络 +* [使用 kubeadm 启用双协议栈网络](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md index bfd8019d3c..54d086ddb5 100644 --- a/content/zh/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md @@ -1,25 +1,27 @@ --- title: 端点切片（Endpoint Slices） content_type: concept -weight: 35 +weight: 45 --- -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -_端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点 +_端点切片（EndpointSlices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点 （network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。 @@ -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 ``` ### 拓扑信息 {#topology} -{{< feature-state for_k8s_version="v1.20" state="deprecated" >}} +EndpointSlice 中的每个端点都可以包含一定的拓扑信息。 +拓扑信息包括端点的位置，对应节点、可用区的信息。 +这些信息体现为 EndpointSlices 的如下端点字段： + + +* `nodeName` - 端点所在的 Node 名称； +* `zone` - 端点所处的可用区。 {{< note >}} -EndpointSlices 中的 topology 字段已被弃用，并将在以后的版本中删除。 -将使用新的 `nodeName` 字段代替在 topology 中设置 `kubernetes.io/hostname`。 -可以确定的是，其他覆盖区和域的拓扑字段用 EndpointSlice 标签来表达更合适， -该标签将应用于 EndpointSlice 内的所有端点。 + +在 v1 API 中，逐个端点设置的 `topology` 实际上被去除，以鼓励使用专用 +的字段 `nodeName` 和 `zone`。 + + +对 `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` - 端点所在的节点名称 -* `topology.kubernetes.io/zone` - 端点所处的可用区 -* `topology.kubernetes.io/region` - 端点所处的区域 - - -这些标签的值时根据与切片中各个端点相关联的资源来生成的。 -标签 `hostname` 代表的是对应的 Pod 的 NodeName 字段的取值。 -`zone` 和 `region` 标签则代表的是对应的节点所拥有的同名标签的值。 - ### 管理 {#management} -通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="controller" term_id="controller" >}}） +通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="控制器" term_id="controller" >}}） 会创建和管理 EndpointSlice 对象。EndpointSlice 对象还有一些其他使用场景， 例如作为服务网格（Service Mesh）的实现。这些场景都会导致有其他实体 或者控制器负责管理额外的 EndpointSlice 集合。 diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index 8b38fa25d4..75631fb241 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -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 >}} -{{< note >}} 你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。 {{< /note >}} + +## 针对某个端口范围 {#targeting-a-range-of-ports} + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + +在编写 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 +``` + + +上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议 +与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。 + + +使用此字段时存在以下限制： + +* 作为一种 Alpha 阶段的特性，端口范围设定默认是被禁用的。要在整个集群 + 范围内允许使用 `endPort` 字段，你（或者你的集群管理员）需要为 API + 服务器设置 `-feature-gates=NetworkPolicyEndPort=true,...` 以启用 + `NetworkPolicyEndPort` + [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +* `endPort` 字段必须等于或者大于 `port` 字段的值。 +* 两个字段的设置值都只能是数字。 + +{{< note >}} + +你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件 +必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。 +{{< /note >}} + + +## 基于名字指向某名字空间 {#targeting-a-namespace-by-its-name} + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + + +只要 `NamespaceDefaultLabelName` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签 +`kubernetes.io/metadata.name`。该标签的值是名字空间的名称。 + +如果 NetworkPolicy 无法在某些对象字段中指向某名字空间，你可以使用标准的 +标签方式来指向特定名字空间。 + -## 你通过网络策略（至少目前还）无法完成的工作 +## 通过网络策略（至少目前还）无法完成的工作 -到 Kubernetes v1.20 为止，NetworkPolicy API 还不支持以下功能，不过 +到 Kubernetes {{< skew latestVersion >}} 为止，NetworkPolicy API 还不支持以下功能，不过 你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等） 或者第七层技术（Ingress 控制器、服务网格实现）或准入控制器来实现一些 替代方案。 如果你对 Kubernetes 中的网络安全性还不太了解，了解使用 NetworkPolicy API 还无法实现下面的用户场景是很值得的。 -对这些用户场景中的一部分（而非全部）的讨论扔在进行，或许在将来 NetworkPolicy -API 中会给出一定支持。 - 强制集群内部流量经过某公用网关（这种场景最好通过服务网格或其他代理来实现）； - 与 TLS 相关的场景（考虑使用服务网格或者 Ingress 控制器）； - 特定于节点的策略（你可以使用 CIDR 来表达这一需求不过你无法使用节点在 Kubernetes 中的其他标识信息来辩识目标节点）； -- 基于名字来选择名字空间或者服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}} +- 基于名字来选择服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}} 来选择目标 Pod 或名字空间，这也通常是一种可靠的替代方案）； - 创建或管理由第三方来实际完成的“策略请求”；