Merge pull request #32719 from zaunist/docs/concepts/services-networking

[zh]: Resync network-policies.md
pull/32717/merge
Kubernetes Prow Robot 2022-04-08 20:52:04 -07:00 committed by GitHub
commit f7ca4fd0a9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 54 additions and 38 deletions

View File

@ -4,7 +4,7 @@ content_type: concept
weight: 50
---
<!--
<!--
title: Network Policies
content_type: concept
weight: 50
@ -41,7 +41,7 @@ When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_t
Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges).
-->
在定义基于 Pod 或名字空间的 NetworkPolicy 时,你会使用
在定义基于 Pod 或名字空间的 NetworkPolicy 时,你会使用
{{< glossary_tooltip text="选择算符" term_id="selector">}} 来设定哪些流量
可以进入或离开与该算符匹配的 Pod。
@ -62,33 +62,50 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话,是没有任何作用的。
<!--
## Isolated and Non-isolated Pods
## The Two Sorts of Pod Isolation
By default, pods are non-isolated; they accept traffic from any source.
Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)
Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
For a network flow between two pods to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the traffic. If either the egress policy on the source, or the ingress policy on the destination denies the traffic, the traffic will be denied.
There are two sorts of isolation for a pod: isolation for egress, and isolation for ingress. They concern what connections may be established. "Isolation" here is not absolute, rather it means "some restrictions apply". The alternative, "non-isolated for $direction", means that no restrictions apply in the stated direction. The two sorts of isolation (or not) are declared independently, and are both relevant for a connection from one pod to another.
-->
## 隔离和非隔离的 Pod {#isolated-and-non-isolated-pods}
默认情况下Pod 是非隔离的,它们接受任何来源的流量。
## Pod 隔离的两种类型
Pod 在被某 NetworkPolicy 选中时进入被隔离状态
一旦名字空间中有 NetworkPolicy 选择了特定的 Pod该 Pod 会拒绝该 NetworkPolicy
所不允许的连接。
(名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量)
Pod 有两种隔离: 出口的隔离和入口的隔离。它们涉及到可以建立哪些连接。
这里的“隔离”不是绝对的,而是意味着“有一些限制”。
另外的,“非隔离方向”意味着在所述方向上没有限制。这两种隔离(或不隔离)是独立声明的,
并且都与从一个 Pod 到另一个 Pod 的连接有关。
网络策略不会冲突,它们是累积的。
如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
入站Ingress/出站Egress规则的并集。因此评估的顺序并不会影响策略的结果。
<!--
By default, a pod is non-isolated for egress; all outbound connections are allowed. A pod is isolated for egress if there is any NetworkPolicy that both selects the pod and has "Egress" in its `policyTypes`; we say that such a policy applies to the pod for egress. When a pod is isolated for egress, the only allowed connections from the pod are those allowed by the `egress` list of some NetworkPolicy that applies to the pod for egress. The effects of those `egress` lists combine additively.
-->
为了允许两个 Pods 之间的网络数据流,源端 Pod 上的出站Egress规则和
目标端 Pod 上的入站Ingress规则都需要允许该流量。
如果源端的出站Egress规则或目标端的入站Ingress规则拒绝该流量
则流量将被拒绝。
默认情况下,一个 Pod 的出口是非隔离的,即所有外向连接都是被允许的。如果有任何的 NetworkPolicy
选择该 Pod 并在其 `policyTypes` 中包含 “Egress”则该 Pod 是出口隔离的,
我们称这样的策略适用于该 Pod 的出口。当一个 Pod 的出口被隔离时,
唯一允许的来自 Pod 的连接是适用于出口的 Pod 的某个 NetworkPolicy 的 `egress` 列表所允许的连接。
这些 `egress` 列表的效果是相加的。
<!--
By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its `policyTypes`; we say that such a policy applies to the pod for ingress. When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the `ingress` list of some NetworkPolicy that applies to the pod for ingress. The effects of those `ingress` lists combine additively.
-->
默认情况下,一个 Pod 对入口是非隔离的,即所有入站连接都是被允许的。如果有任何的 NetworkPolicy
选择该 Pod 并在其 `policyTypes` 中包含 “Ingress”则该 Pod 被隔离入口,
我们称这种策略适用于该 Pod 的入口。 当一个 Pod 的入口被隔离时,唯一允许进入该 Pod
的连接是来自该 Pod 节点的连接和适用于入口的 Pod 的某个 NetworkPolicy 的 `ingress`
列表所允许的连接。这些 `ingress` 列表的效果是相加的。
<!--
Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow. Thus, order of evaluation does not affect the policy result.
For a connection from a source pod to a destination pod to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the connection. If either side does not allow the connection, it will not happen.
-->
网络策略是相加的,所以不会产生冲突。如果策略适用于 Pod 某一特定方向的流量,
Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。
因此,评估的顺序不影响策略的结果。
要允许从源 Pod 到目的 Pod 的连接,源 Pod 的出口策略和目的 Pod 的入口策略都需要允许连接。
如果任何一方不允许连接,建立连接将会失败。
<!--
## The NetworkPolicy resource {#networkpolicy-resource}
@ -141,7 +158,7 @@ spec:
port: 5978
```
<!--
<!--
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
-->
{{< note >}}
@ -262,7 +279,7 @@ __namespaceSelector__ *和* __podSelector__ 一个指定 `namespaceSelector`
...
```
<!--
<!--
contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy:
-->
`from` 数组中仅包含一个元素,只允许来自标有 `role=client` 的 Pod 且
@ -339,8 +356,8 @@ You can create a "default" isolation policy for a namespace by creating a Networ
-->
### 默认拒绝所有入站流量
你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy
来为名字空间创建 "default" 隔离策略。
你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy
来为名字空间创建 “default” 隔离策略。
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
@ -369,8 +386,8 @@ You can create a "default" egress isolation policy for a namespace by creating a
-->
### 默认拒绝所有出站流量
你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy
来为名字空间创建 "default" egress 隔离策略。
你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy
来为名字空间创建 “default” 隔离策略。
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
@ -429,7 +446,7 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
启用该特性门控后,用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`
{{< note >}}
<!--
<!--
You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
-->
你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
@ -474,17 +491,17 @@ spec:
```
<!--
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
The above rule allows any Pod with label `role=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 协议
上面的规则允许名字空间 `default` 中所有带有标签 `role=db` 的 Pod 使用 TCP 协议
`10.0.0.0/24` 范围内的 IP 通信,只要目标端口介于 32000 和 32768 之间就可以。
<!--
The following restrictions apply when using this field:
* As a beta feature, this is enabled by default. To disable the `endPort` field at a cluster level, you (or your cluster administrator) need to disable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=NetworkPolicyEndPort=false,…`.
* The `endPort` field must be equal than or greater to the `port` field.
* The `endPort` field must be equal to or greater than the `port` field.
* `endPort` can only be defined if `port` is also defined.
* Both ports must be numeric.
-->
@ -493,7 +510,7 @@ The following restrictions apply when using this field:
* 作为一种 Beta 阶段的特性,端口范围设定默认是被启用的。要在整个集群
范围内禁止使用 `endPort` 字段,你(或者你的集群管理员)需要为 API
服务器设置 `-feature-gates=NetworkPolicyEndPort=false,...` 以禁用
`NetworkPolicyEndPort`
`NetworkPolicyEndPort`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
* `endPort` 字段必须等于或者大于 `port` 字段的值。
* 两个字段的设置值都只能是数字。
@ -502,7 +519,7 @@ The following restrictions apply when using this field:
<!--
Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that
supports the `endPort` field in NetworkPolicy specifications.
If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
does not support the `endPort` field and you specify a NetworkPolicy with that,
the policy will be applied only for the single `port` field.
-->
@ -518,7 +535,7 @@ the policy will be applied only for the single `port` field.
-->
## 基于名字指向某名字空间 {#targeting-a-namespace-by-its-name}
{{< feature-state state="beta" for_k8s_version="1.21" >}}
{{< feature-state for_k8s_version="1.22" state="stable" >}}
<!--
The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all
@ -592,4 +609,3 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no
演练了解更多示例;
- 有关 NetworkPolicy 资源所支持的常见场景的更多信息,请参见
[此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。