Merge pull request #41154 from my-git9/path-17075
[zh-cn] sync network-policies.md and volumes.mdpull/41194/head
commit
fdeb85f75f
|
@ -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 的连接。
|
||||
|
||||
<!--
|
||||
When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.
|
||||
|
@ -388,7 +388,7 @@ in that namespace.
|
|||
You can create a "default" ingress isolation policy for a namespace by creating a NetworkPolicy
|
||||
that selects all pods but does not allow any ingress traffic to those pods.
|
||||
-->
|
||||
你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 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
|
||||
|
||||
In this scenario, your `Egress` NetworkPolicy targets more than one namespace using their
|
||||
label names. For this to work, you need to label the target namespaces. For example:
|
||||
-->
|
||||
## 按标签选择多个命名空间 {#targeting-multiple-namespaces-by-label}
|
||||
|
||||
在这种情况下,你的 `Egress` NetworkPolicy 使用名字空间的标签名称来将多个名字空间作为其目标。
|
||||
为此,你需要为目标名字空间设置标签。例如:
|
||||
|
||||
```shell
|
||||
kubectl label namespace frontend namespace=frontend
|
||||
kubectl label namespace backend namespace=backend
|
||||
```
|
||||
|
||||
<!--
|
||||
Add the labels under `namespaceSelector` in your NetworkPolicy document. For example:
|
||||
-->
|
||||
在 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 >}}
|
||||
<!--
|
||||
It is not possible to directly specify the name of the namespaces in a NetworkPolicy.
|
||||
You must use a `namespaceSelector` with `matchLabels` or `matchExpressions` to select the
|
||||
namespaces based on their labels.
|
||||
-->
|
||||
你不可以在 NetworkPolicy 中直接指定命名空间的名称。
|
||||
你必须使用带有 `matchLabels` 或 `matchExpressions` 的 `namespaceSelector`
|
||||
来根据标签选择命名空间。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Targeting a Namespace by its name
|
||||
-->
|
||||
|
|
|
@ -19,18 +19,24 @@ weight: 10
|
|||
|
||||
<!--
|
||||
On-disk files in a container are ephemeral, which presents some problems for
|
||||
non-trivial applications when running in containers. One problem
|
||||
is the loss of files when a container crashes. The kubelet restarts the container
|
||||
but with a clean state. A second problem occurs when sharing files
|
||||
between containers running together in a `Pod`.
|
||||
non-trivial applications when running in containers. One problem occurs when
|
||||
a container crashes or is stopped. Container state is not saved so all of the
|
||||
files that were created or modified during the lifetime of the container are lost.
|
||||
During a crash, kubelet restarts the container with a clean state.
|
||||
Another problem occurs when multiple containers are running in a `Pod` and
|
||||
need to share files. It can be challenging to setup
|
||||
and access a shared filesystem across all of the containers.
|
||||
The Kubernetes {{< glossary_tooltip text="volume" term_id="volume" >}} abstraction
|
||||
solves both of these problems.
|
||||
Familiarity with [Pods](/docs/concepts/workloads/pods/) is suggested.
|
||||
-->
|
||||
Container 中的文件在磁盘上是临时存放的,这给 Container 中运行的较重要的应用程序带来一些问题。
|
||||
问题之一是当容器崩溃时文件丢失。
|
||||
kubelet 会重新启动容器,但容器会以干净的状态重启。
|
||||
第二个问题会在同一 `Pod` 中运行多个容器并共享文件时出现。
|
||||
容器中的文件在磁盘上是临时存放的,这给在容器中运行较重要的应用带来一些问题。
|
||||
当容器崩溃或停止时会出现一个问题。此时容器状态未保存,
|
||||
因此在容器生命周期内创建或修改的所有文件都将丢失。
|
||||
在崩溃期间,kubelet 会以干净的状态重新启动容器。
|
||||
当多个容器在一个 Pod 中运行并且需要共享文件时,会出现另一个问题。
|
||||
跨所有容器设置和访问共享文件系统具有一定的挑战性。
|
||||
|
||||
Kubernetes {{< glossary_tooltip text="卷(Volume)" term_id="volume" >}}
|
||||
这一抽象概念能够解决这两个问题。
|
||||
|
||||
|
@ -56,14 +62,16 @@ Docker 提供卷驱动程序,但是其功能非常有限。
|
|||
<!--
|
||||
Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}}
|
||||
can use any number of volume types simultaneously.
|
||||
Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
|
||||
[Ephemeral volume](/docs/concepts/storage/ephemeral-volumes/) types have a lifetime of a pod,
|
||||
but [persistent volumes](/docs/concepts/storage/persistent-volumes/) exist beyond
|
||||
the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes;
|
||||
however, Kubernetes does not destroy persistent volumes.
|
||||
For any kind of volume in a given pod, data is preserved across container restarts.
|
||||
-->
|
||||
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 驱动。
|
||||
|
||||
<!--
|
||||
|
@ -2115,7 +2129,8 @@ FlexVolume 是一个使用基于 exec 的模型来与驱动程序对接的树外
|
|||
驱动程序可执行文件,在某些情况下,控制平面节点中也要安装。
|
||||
|
||||
Pod 通过 `flexvolume` 树内插件与 FlexVolume 驱动程序交互。
|
||||
更多详情请参考 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 文档。
|
||||
更多详情请参考 FlexVolume
|
||||
[README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 文档。
|
||||
|
||||
<!--
|
||||
The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows),
|
||||
|
@ -2273,4 +2288,3 @@ sudo systemctl restart docker
|
|||
Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
|
||||
-->
|
||||
参考[使用持久卷部署 WordPress 和 MySQL](/zh-cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。
|
||||
|
||||
|
|
Loading…
Reference in New Issue