diff --git a/content/zh-cn/docs/concepts/services-networking/network-policies.md b/content/zh-cn/docs/concepts/services-networking/network-policies.md index d6d9c6be3c..54b3284487 100644 --- a/content/zh-cn/docs/concepts/services-networking/network-policies.md +++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md @@ -309,7 +309,7 @@ This policy contains a single `from` element allowing connections from Pods with `role=client` in namespaces with the label `user=alice`. But the following policy is different: --> 此策略在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod -且该 Pod 所在的名字空间中标有 `user=alice` 的连接。但是 **这项** 策略： +且该 Pod 所在的名字空间中标有 `user=alice` 的连接。但是**这项**策略： ```yaml ... @@ -330,7 +330,7 @@ Namespace with the label `role=client`, *or* from any Pod in any namespace with `user=alice`. --> 它在 `from` 数组中包含两个元素，允许来自本地名字空间中标有 `role=client` 的 -Pod 的连接，**或** 来自任何名字空间中标有 `user=alice` 的任何 Pod 的连接。 +Pod 的连接，**或**来自任何名字空间中标有 `user=alice` 的任何 Pod 的连接。 -你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy +你可以通过创建选择所有 Pod 但不允许任何进入这些 Pod 的入站流量的 NetworkPolicy 来为名字空间创建 “default” 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} @@ -562,6 +562,58 @@ NetworkPolicy 规约中使用 `endPort` 字段。 策略只对单个 `port` 字段生效。 {{< /note >}} + +## 按标签选择多个命名空间 {#targeting-multiple-namespaces-by-label} + +在这种情况下，你的 `Egress` NetworkPolicy 使用名字空间的标签名称来将多个名字空间作为其目标。 +为此，你需要为目标名字空间设置标签。例如： + +```shell + kubectl label namespace frontend namespace=frontend + kubectl label namespace backend namespace=backend +``` + + +在 NetworkPolicy 文档中的 namespaceSelector 下添加标签。例如： + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: egress-namespaces +spec: + podSelector: + matchLabels: + app: myapp + policyTypes: + - Egress + egress: + - to: + - namespaceSelector: + matchExpressions: + - key: namespace + operator: In + values: ["frontend", "backend"] +``` + +{{< note >}} + +你不可以在 NetworkPolicy 中直接指定命名空间的名称。 +你必须使用带有 `matchLabels` 或 `matchExpressions` 的 `namespaceSelector` +来根据标签选择命名空间。 +{{< /note >}} + diff --git a/content/zh-cn/docs/concepts/storage/volumes.md b/content/zh-cn/docs/concepts/storage/volumes.md index cc93f8ae66..bdfced31a7 100644 --- a/content/zh-cn/docs/concepts/storage/volumes.md +++ b/content/zh-cn/docs/concepts/storage/volumes.md @@ -19,18 +19,24 @@ weight: 10 -Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用程序带来一些问题。 -问题之一是当容器崩溃时文件丢失。 -kubelet 会重新启动容器，但容器会以干净的状态重启。 -第二个问题会在同一 `Pod` 中运行多个容器并共享文件时出现。 +容器中的文件在磁盘上是临时存放的，这给在容器中运行较重要的应用带来一些问题。 +当容器崩溃或停止时会出现一个问题。此时容器状态未保存， +因此在容器生命周期内创建或修改的所有文件都将丢失。 +在崩溃期间，kubelet 会以干净的状态重新启动容器。 +当多个容器在一个 Pod 中运行并且需要共享文件时，会出现另一个问题。 +跨所有容器设置和访问共享文件系统具有一定的挑战性。 + Kubernetes {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}} 这一抽象概念能够解决这两个问题。 @@ -56,14 +62,16 @@ Docker 提供卷驱动程序，但是其功能非常有限。 Kubernetes 支持很多类型的卷。 {{< glossary_tooltip term_id="pod" text="Pod" >}} 可以同时使用任意数目的卷类型。 -临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。 +[临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/)类型的生命周期与 Pod 相同， +但[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)可以比 Pod 的存活期长。 当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁持久卷。 对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。 @@ -1943,20 +1951,26 @@ persistent volume: secrets are passed. When you have configured secret data for node-initiated volume expansion, the kubelet passes that data via the `NodeExpandVolume()` call to the CSI driver. In order to use the `nodeExpandSecretRef` field, your - cluster should be running Kubernetes version 1.25 or later and you must enable + cluster should be running Kubernetes version 1.25 or later. + If you are running Kubernetes Version 1.25 or 1.26, you must enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `CSINodeExpandSecret` for each kube-apiserver and for the kubelet on every - node. You must also be using a CSI driver that supports or requires secret data during + node. In Kubernetes version 1.27 this feature has been enabled by default + and no explicit enablement of the feature gate is required. + You must also be using a CSI driver that supports or requires secret data during node-initiated storage resize operations. --> * `nodeExpandSecretRef`：对包含敏感信息的 Secret 对象的引用， 该信息会传递给 CSI 驱动以完成 CSI `NodeExpandVolume` 调用。 此字段是可选的，如果不需要 Secret，则可能是空的。 如果 Secret 包含多个 Secret 条目，则传递所有 Secret 条目。 - 当你为节点初始化的卷扩展配置 Secret 数据时，kubelet 会通过 `NodeExpandVolume()` 调用将该数据传递给 CSI 驱动。 - 为了使用 `nodeExpandSecretRef` 字段，你的集群应运行 Kubernetes 1.25 或更高版本， - 并且你必须为每个 kube-apiserver 和每个节点上的 kubelet 启用名为 `CSINodeExpandSecret` + 当你为节点初始化的卷扩展配置 Secret 数据时，kubelet 会通过 `NodeExpandVolume()` + 调用将该数据传递给 CSI 驱动。为了使用 `nodeExpandSecretRef` 字段， + 你的集群应运行 Kubernetes 1.25 或更高版本， + 如果你所运行的 Kubernetes 是 1.25 或 1.26，你必须为每个 kube-apiserver + 和每个节点上的 kubelet 启用名为 `CSINodeExpandSecret` 的[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 + 在 Kubernetes 1.27 版本中，此特性已默认启用，无需显式启用特性门控。 在节点初始化的存储大小调整操作期间，你还必须使用支持或需要 Secret 数据的 CSI 驱动。 参考[使用持久卷部署 WordPress 和 MySQL](/zh-cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 -