From 9f7414e7334baaaadf1edc0ff3474b693a5017d4 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 31 Jul 2020 13:57:23 +0800 Subject: [PATCH] [zh] Fix links in concepts section --- .../zh/docs/concepts/configuration/secret.md | 13 +- .../scheduling-eviction/assign-pod-node.md | 20 +- .../connect-applications-service.md | 84 ++--- .../services-networking/dual-stack.md | 59 ++-- .../services-networking/endpoint-slices.md | 68 ++--- .../ingress-controllers.md | 287 ++++++++++-------- .../services-networking/network-policies.md | 46 ++- .../concepts/services-networking/service.md | 4 +- .../concepts/storage/dynamic-provisioning.md | 20 +- .../docs/concepts/storage/storage-classes.md | 146 +++++---- .../concepts/storage/volume-pvc-datasource.md | 59 ++-- .../docs/concepts/storage/volume-snapshots.md | 27 +- content/zh/docs/concepts/storage/volumes.md | 265 ++++++---------- 13 files changed, 536 insertions(+), 562 deletions(-) diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md index 7f9de99257..47b0e983ff 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh/docs/concepts/configuration/secret.md @@ -244,10 +244,9 @@ You can also create a Secret in a file first, in JSON or YAML format, and then create that object. The name of a Secret object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - -he -[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core) contains two maps: -data and stringData. The data field is used to store arbitrary data, encoded using +The [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +contains two maps: +`data` and `stringData`. The `data` field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience, and allows you to provide secret data as unencoded strings. --> @@ -255,7 +254,7 @@ secret data as unencoded strings. 您也可以先以 JSON 或 YAML 格式文件创建一个 Secret，然后创建该对象。 Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core) +[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) 包含两个映射：`data` 和 `stringData`。 `data` 字段用于存储使用 base64 编码的任意数据。 提供 `stringData` 字段是为了方便，允许您用未编码的字符串提供机密数据。 @@ -1237,7 +1236,7 @@ See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data- 手动创建的 Secret（例如包含用于访问 GitHub 帐户令牌的 Secret）可以 根据其服务帐户自动附加到 Pod。 -请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/run-application/podpreset/) +请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/inject-data-application/podpreset/) 以获取该过程的详细说明。 -你可以为 Secret 数据开启[静态加密](//zhdocs/tasks/administer-cluster/encrypt-data/)， +你可以为 Secret 数据开启[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)， 这样 Secret 数据就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}} 中。 -你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： `In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。 +你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： +`In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。 +你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用 +[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。 -上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` 来部署 redis 集群以便在同一主机上没有两个实例。参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。 +上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` +来部署 redis 集群以便在同一主机上没有两个实例。 +参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)， +以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。 ## nodeName @@ -660,7 +666,7 @@ The above pod will run on the node kube-01. [Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods. --> -[污点](/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。 +[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。 -[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 [pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。 +[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 +[pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。 -一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 -[拓扑管理](/zh/docs/tasks/administer-cluster/topology-manager/) +一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 +[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) 可以参与到节点级别的资源分配决定中。 - diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index a4985549c1..25bebe4d01 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -1,10 +1,9 @@ --- -title: 应用连接到 Service +title: 使用 Service 连接到应用 content_type: concept weight: 30 --- - @@ -48,7 +43,6 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上 We did this in a previous example, but let's do it once again and focus on the networking perspective. Create an nginx Pod, and note that it has a container port specification: --> - ## 在集群中暴露 Pod 我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。 @@ -75,7 +69,6 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 - 检查 Pod 的 IP 地址： ```shell @@ -89,14 +82,12 @@ You should be able to ssh into any node in your cluster and curl both IPs. Note You can read more about [how we achieve this](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) if you're curious. --> - 应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。 需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。 这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。 像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。 -如果对此好奇，可以获取更多关于 [如何实现网络模型](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。 - +如果对此好奇，可以获取更多关于 [如何实现网络模型](/zh/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。 - ## 创建 Service 我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？ @@ -145,9 +135,11 @@ View [Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/ API object to see the list of supported fields in service definition. Check your Service: --> - -上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。 -查看 [Service API 对象](/docs/api-reference/{{< param "version" >}}/#service-v1-core) 了解 Service 定义支持的字段列表。 +上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80， +并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service +端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。 +查看 [Service API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) +了解 Service 定义支持的字段列表。 查看你的 Service 资源: ```shell @@ -167,7 +159,6 @@ matching the Service's selector will automatically get added to the endpoints. Check the endpoints, and note that the IPs are the same as the Pods created in the first step: --> - 正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 `endpoints` 暴露出来。 Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。 当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。 @@ -206,7 +197,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip 现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service `:` 。 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇， -可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。 +可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +的内容。 - +{{< note >}} 如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在 -[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 - +[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 {{< /note >}} - - -如果没有在运行，可以 [启用它](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。 -本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。 +如果没有在运行，可以[启用它](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。 +本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx）， +一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法， +使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。 让我们运行另一个 curl 应用来进行测试： ```shell @@ -370,9 +360,10 @@ You can acquire all these from the [nginx https example](https://github.com/kube * https 自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx server -* 使证书可以访问 Pod 的[秘钥](/docs/user-guide/secrets) +* 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) -可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下： +可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) +获取所有上述内容，简明示例如下： ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt @@ -456,7 +447,8 @@ Noteworthy points about the nginx-secure-app manifest: 关于 nginx-secure-app manifest 值得注意的点如下： - 它在相同的文件中包含了 Deployment 和 Service 的规格 -- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。 +- [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) + 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。 ```shell @@ -483,7 +475,8 @@ so we have to tell curl to ignore the CName mismatch. By creating a Service we l Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): --> -注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 +注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时， +我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。 让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）： @@ -513,15 +506,18 @@ LoadBalancers. The Service created in the last section already used `NodePort`, so your nginx HTTPS replica is ready to serve traffic on the internet if your node has a public IP. --> - ## 暴露 Service 对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。 -在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，如果使用一个公网 IP，能够处理 Internet 上的流量。 +在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪， +如果使用一个公网 IP，能够处理 Internet 上的流量。 ```shell kubectl get svc my-nginx -o yaml | grep nodePort -C 5 +``` + +``` uid: 07191fb3-f61a-11e5-8ae5-42010af00002 spec: clusterIP: 10.0.162.149 @@ -539,8 +535,12 @@ spec: selector: run: my-nginx ``` + ```shell kubectl get nodes -o yaml | grep ExternalIP -C 1 +``` + +``` - address: 104.197.41.11 type: ExternalIP allocatable: @@ -549,8 +549,14 @@ kubectl get nodes -o yaml | grep ExternalIP -C 1 type: ExternalIP allocatable: ... +``` -$ curl https://: -k +```shell +curl https://: -k +``` + +输出类似于： +``` ...

Welcome to nginx!

``` @@ -593,13 +599,14 @@ see it. You'll see something like this: ```shell kubectl describe service my-nginx +``` + +``` ... LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com ... ``` - - ## {{% heading "whatsnext" %}} @@ -32,14 +25,15 @@ weight: 70 -IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 {{< glossary_tooltip text="Services" term_id="service" >}}。 +IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 和 +{{< glossary_tooltip text="Service" term_id="service" >}}。 -如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，则该集群将支持同时分配 IPv4 和 IPv6 地址。 - - +如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络， +则该集群将支持同时分配 IPv4 和 IPv6 地址。 @@ -89,7 +83,9 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack -要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)，并且设置双协议栈的集群网络分配： +要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +并且设置双协议栈的集群网络分配： * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` @@ -113,13 +109,20 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ If your cluster has IPv4/IPv6 dual-stack networking enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} with either an IPv4 or an IPv6 address. You can choose the address family for the Service's cluster IP by setting a field, `.spec.ipFamily`, on that Service. You can only set this field when creating a new Service. Setting the `.spec.ipFamily` field is optional and should only be used if you plan to enable IPv4 and IPv6 {{< glossary_tooltip text="Services" term_id="service" >}} and {{< glossary_tooltip text="Ingresses" term_id="ingress" >}} on your cluster. The configuration of this field not a requirement for [egress](#egress-traffic) traffic. --> -如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建 {{< glossary_tooltip text="Services" term_id="service" >}}。你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的，并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Services" term_id="service" >}} 和 {{< glossary_tooltip text="Ingresses" term_id="ingress" >}}。对于[出口](#出口流量)流量，该字段的配置不是必须的。 +如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建 +{{< glossary_tooltip text="Service" term_id="service" >}}。 +你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。 +你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的， +并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Service" term_id="service" >}} +和 {{< glossary_tooltip text="Ingress" term_id="ingress" >}}。 +对于[出口](#出口流量)流量，该字段的配置不是必须的。 {{< note >}} -集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置。 +集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 +`kube-controller-manager` 上的 `--service-cluster-ip-range` 标志设置。 {{< /note >}} -### 负载均衡器类型 +### LoadBalancer 类型 -在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。 +在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`， +将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。 -公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 {{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈，所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。 +公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 +{{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。 +如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的 +（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。 +[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈， +所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。 - * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (--cluster-cidr) - - + * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`) ## {{% heading "whatsnext" %}} - -* [验证 IPv4/IPv6 双协议栈](/docs/tasks/network/validate-dual-stack)网络 - +* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络 diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md index 8a71b19b3c..d788da3d7d 100644 --- a/content/zh/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md @@ -1,9 +1,7 @@ --- -reviewers: -- freehan -title: Endpoint Slices +title: 端点切片（Endpoint Slices） feature: - title: Endpoint Slices + title: 端点切片 description: > Kubernetes 集群中网络端点的可扩展跟踪。 @@ -12,9 +10,6 @@ weight: 10 --- @@ -35,9 +29,8 @@ _Endpoint Slices_ 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 集群中的网络端点（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。 - - +_端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点 +（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。 @@ -55,7 +48,9 @@ Kubernetes Service. --> ## Endpoint Slice 资源 {#endpointslice-resource} -在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。 +在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。 +指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。 +这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。 例如，这里是 Kubernetes服务 `example` 的示例 EndpointSlice 资源。 @@ -90,7 +85,14 @@ with Endpoints and Services and have similar performance. Endpoint Slices can act as the source of truth for kube-proxy when it comes to how to route internal traffic. When enabled, they should provide a performance improvement for services with large numbers of endpoints. +--> +默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个端点。 +低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1:1 映射，并具有相似的性能。 +当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。 +启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。 + + +## 地址类型 +EndpointSlice 支持三种地址类型： + +* IPv4 +* IPv6 +* FQDN (完全合格的域名) + + - -默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个 endpoints。低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1：1 映射，并具有相似的性能。 - -当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。 - - -## 地址类型 - -EndpointSlice 支持三种地址类型： - -* IPv4 -* IPv6 -* FQDN (完全合格的域名) - ## 动机 -Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。最值得注意的是，这包含了扩展到更多网络端点的挑战。 +Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。 +不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。 +最值得注意的是，这包含了扩展到更多网络端点的挑战。 -由于服务的所有网络端点都存储在单个 Endpoints 资源中，因此这些资源可能会变得很大。这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints 发生更改时导致大量网络流量和处理。Endpoint Slices 可帮助您缓解这些问题并提供可扩展的 +由于服务的所有网络端点都存储在单个 Endpoints 资源中， +因此这些资源可能会变得很大。 +这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints +发生更改时导致大量网络流量和处理。 +Endpoint Slices 可帮助您缓解这些问题并提供可扩展的 附加特性（例如拓扑路由）平台。 - - ## {{% heading "whatsnext" %}} - -* [启用 Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices) -* 阅读 [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) +* [启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices) +* 阅读[使用服务链接应用](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index 46d166d9d9..4071ea6189 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -1,134 +1,155 @@ ---- -title: Ingress 控制器 -content_type: concept -weight: 40 ---- - - - - - - - -为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 - -与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 -基于此页面，您可选择最适合您的集群的 ingress 控制器实现。 - -Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) -和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 - - - - - - -## 其他控制器 - - -* [AKS 应用程序网关 Ingress 控制器]使用 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用[AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。 -* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress - 控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。 -* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护。 -* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 ingress。 -* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。 -* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 -* F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。 -* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 -* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、由社区驱动的 Ingress 控制器。 -* [HAProxy Technologies](https://www.haproxy.com/) 为[用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。 -* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 -* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。 -* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。 -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 -* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 - （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 - - -## 使用多个 Ingress 控制器 - - - -你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 -创建 ingress 时，应该使用适当的 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress -以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 - -如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 - -理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 - - -{{< note >}} -确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 -{{< /note >}} - - - +--- +title: Ingress 控制器 +content_type: concept +weight: 40 +--- + + + + + + +为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 + +与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 +基于此页面，您可选择最适合您的集群的 ingress 控制器实现。 + +Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) +和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 + + + + +## 其他控制器 + + +* [AKS 应用程序网关 Ingress 控制器]使用 + [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用 + [AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。 +* [Ambassador](https://www.getambassador.io/) API 网关，一个基于 [Envoy](https://www.envoyproxy.io) 的 Ingress + 控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 + [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。 +* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 + [HAProxy](https://www.haproxy.org/) 的 Ingress 控制器 + [Voyager](https://appscode.com/products/voyager) 提供支持和维护。 +* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) + 通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 Ingress。 +* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) + 的 Ingress 控制器，它由 VMware 提供和支持。 + +* Citrix 为其硬件（MPX），虚拟化（VPX）和 + [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) + 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)， + 用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和 + [云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 +* F5 Networks 为 + [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供 + [支持和维护](https://support.f5.com/csp/article/K86859508)。 +* [Gloo](https://gloo.solo.io) 是一个开源的基于 + [Envoy](https://www.envoyproxy.io) 的 Ingress 控制器，它提供了 API 网关功能， + 有着来自 [solo.io](https://www.solo.io) 的企业级支持。 +* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、 + 由社区驱动的 Ingress 控制器。 +* [HAProxy Technologies](https://www.haproxy.com/) 为 + [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) + 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。 +* 基于 [Istio](https://istio.io/) 的 ingress 控制器 + [控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 + +* [Kong](https://konghq.com/) 为 + [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) + 提供[社区](https://discuss.konghq.com/c/kubernetes)或 + [商业](https://konghq.com/kong-enterprise/)支持和维护。 +* [NGINX, Inc.](https://www.nginx.com/) 为 + [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) + 提供支持和维护。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 +* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 + （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket）， + 并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 + + +## 使用多个 Ingress 控制器 + + + +你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 +创建 ingress 时，应该使用适当的 +[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +注解每个 Ingress 以表明在集群中如果有多个 Ingress 控制器时，应该使用哪个 Ingress 控制器。 + +如果不定义 `ingress.class`，云提供商可能使用默认的 Ingress 控制器。 + +理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 + + +{{< note >}} +确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 +{{< /note >}} + ## {{% heading "whatsnext" %}} - - -* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 - + + +* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。 + diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index 2ad44866c6..784455922a 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -5,16 +5,10 @@ weight: 50 --- +--> {{< toc >}} @@ -30,8 +24,6 @@ NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">} NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}} 选择 Pod，并定义选定 Pod 所允许的通信规则。 - - - ## 隔离和非隔离的 Pod 默认情况下，Pod 是非隔离的，它们接受任何来源的流量。 -Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，该 Pod 会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量) +Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod， +该 Pod 会拒绝网络策略所不允许的连接。 +（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量） -网络策略不会冲突，它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。 +网络策略不会冲突，它们是累积的。 +如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 +ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。 -__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/), -和 [对象管理](/docs/concepts/overview/working-with-objects/object-management)。 +__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、`kind` 和 `metadata` 字段。 + 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), + 和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 __spec__: NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息。 @@ -175,7 +173,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network- * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16） 3. （Egress 规则）允许从带有 "role=db" 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。 -查看 [声明网络策略](/docs/getting-started-guides/network-policy/walkthrough) 来进行更多的示例演练。 +查看[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练。 -要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` 来启用 `SCTPSupport` [特性开关](/docs/reference/command-line-tools-reference/feature-gates/)。启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 +要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` +来启用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 -- 查看 [声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/) +- 查看 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练 -- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 [指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 - +- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 + [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index a78628ed29..294738085d 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -1461,7 +1461,7 @@ the NLB Target Group's health check on the auto-assigned 为了获得均衡流量，请使用 DaemonSet 或指定 -[Pod 反亲和性](/zh/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 使其不在同一节点上。 你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer) diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md index 3388a7bd6b..d2e8cff8e5 100644 --- a/content/zh/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md @@ -4,16 +4,9 @@ content_type: concept weight: 40 --- @@ -29,11 +22,9 @@ automatically provisions storage when it is requested by users. --> 动态卷供应允许按需创建存储卷。 如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷， -然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。 +然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。 - - -点击[这里](/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 +点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 -## 启用动态卷供应 +## 启用动态卷供应 {#enabling-dynamic-provisioning} -在[多区域](/docs/setup/multiple-zones)集群中，Pod 可以被分散到多个区域。 +在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。 单区域存储后端应该被供应到 Pod 被调度到的区域。 -这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 +这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 + diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md index 8dbff4f851..b2d98c25aa 100644 --- a/content/zh/docs/concepts/storage/storage-classes.md +++ b/content/zh/docs/concepts/storage/storage-classes.md @@ -1,14 +1,15 @@ --- -reviewers: -- jsafrane -- saad-ali -- thockin -- msau42 -title: Storage Classes +title: 存储类 content_type: concept weight: 30 --- + + -本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/docs/concepts/storage/volumes/) 和 -[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。 - - +本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和 +[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。 @@ -67,7 +66,8 @@ request any particular class to bind to: see the for details. --> 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ： -更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +更多详情请参阅 +[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ```yaml apiVersion: storage.k8s.io/v1 @@ -134,7 +134,8 @@ the specification. Some external provisioners are listed under the repository [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage). --> 您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。 -您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 +您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 +[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。 @@ -182,7 +183,6 @@ allows the users to resize the volume by editing the corresponding PVC object. The following types of volumes support volume expansion, when the underlying Storage Class has the field `allowVolumeExpansion` set to true. --> - PersistentVolume 可以配置为可扩展。将此功能设置为 `true` 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。 当基础存储类的 `allowVolumeExpansion` 字段设置为 true 时，以下类型的卷支持卷扩展。 @@ -207,10 +207,10 @@ Volume type | Required Kubernetes version {{< /table >}} -{{< note >}} +{{< note >}} 此功能仅可用于扩容卷，不能用于缩小卷。 {{< /note >}} @@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid. The `volumeBindingMode` field controls when [volume binding and dynamic provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. --> -`volumeBindingMode` 字段控制了 [卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning) +`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning) 应该发生在什么时候。 集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。 该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。 -PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 [资源需求](/docs/concepts/configuration/manage-compute-resources-container)， -[节点筛选器](/docs/concepts/configuration/assign-pod-node/#nodeselector)， -[pod 亲和性和互斥性](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -以及 [污点和容忍度](/docs/concepts/configuration/taint-and-toleration). +PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 +[资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、 +[节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、 +[pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、 +以及[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - -动态配置和预先创建的 PV 也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)， +动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)， 但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。 -### 允许的拓扑结构 +### 允许的拓扑结构 {#allowed-topologies} {{< feature-state for_k8s_version="v1.12" state="beta" >}} -* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 -* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 -* `zones`(弃用)：以逗号分隔的 AWS 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。 -* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，并将其限制在 20 000 IOPS（AWS 支持的最高值，请参阅 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 +* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 + [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 +* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`， + 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用)：以逗号分隔的 AWS 区域列表。 + 如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。 +* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。 + AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量， + 并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅 + [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 这里需要输入一个字符串，即 `"10"`，而不是 `10`。 * `fsType`：受 Kubernetes 支持的文件类型。默认值：`"ext4"`。 -* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。这里需要输入字符串，即 `"true"`, 而非 `true`。 -* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。 +* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。 + 这里需要输入字符串，即 `"true"`, 而非 `true`。 +* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。 + 如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。 {{< note >}} * `type`：`pd-standard` 或者 `pd-ssd`。默认：`pd-standard` -* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 -* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。`zone` 和 `zones` 参数不能同时使用。 +* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常 + 卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 + `zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`， + 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。 + `zone` 和 `zones` 参数不能同时使用。 * `fstype`: `ext4` 或 `xfs`。 默认: `ext4`。宿主机操作系统必须支持所定义的文件系统类型。 * `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。 @@ -465,14 +477,18 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the `zones` parameter is omitted, Kubernetes will arbitrarily choose among zones managed by the cluster. --> -如果 `replication-type` 设置为 `regional-pd`，会分配一个 [区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。 - -{{< note >}} +如果 `replication-type` 设置为 `regional-pd`，会分配一个 +[区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。 +在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。 +如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。 +如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。 +如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。 +{{< note >}} `zone` 和 `zones` 已被弃用并被 [allowedTopologies](#allowed-topologies) 取代。 {{< /note >}} @@ -516,11 +532,14 @@ parameters: --> * `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。 通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。 - 如果 Heketi 服务在 openshift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于 + 如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于 `http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。 -* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用，当在指定 `restuser`，`restuserkey`，`secretName` 或 `secretNamespace` 时，身份验证被启用。 +* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。 + 如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。 + 此选项已弃用，当在指定 `restuser`、`restuserkey`、`secretName` 或 `secretNamespace` 时，身份验证被启用。 * `restuser`：在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。 -* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。 +* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。 + 此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。 * `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。 - 这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建： + 这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。 + 所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建： ``` kubectl create secret generic heketi-secret \ @@ -547,7 +567,7 @@ parameters: --namespace=default ``` - secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。 + Secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。 -* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如： +* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时， + Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如： `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。 -* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。 +* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。 + 在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。 + 如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。 * `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。 + 例如： - 例如： - 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量. - 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量. - 'Distribute volume': `volumetype: none` + * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量. + * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量. + * 'Distribute volume': `volumetype: none` - 有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。 + 有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。 - 更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。 + 更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。 - 当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。 + 当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。 ### OpenStack Cinder @@ -674,7 +697,11 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部 specified in the vSphere config file used to initialize the vSphere Cloud Provider. --> - `datastore`：用户也可以在 StorageClass 中指定数据存储。卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。该字段是可选的。如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 配置文件中指定的数据存储上创建该卷。 + `datastore`：用户也可以在 StorageClass 中指定数据存储。 + 卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。 + 该字段是可选的。 + 如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere + 配置文件中指定的数据存储上创建该卷。 * 使用现有的 vCenter SPBM 策略 - vSphere 用于存储管理的最重要特性之一是基于策略的管理。基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的跨越广泛的数据服务和存储解决方案。 SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。 + vSphere 用于存储管理的最重要特性之一是基于策略的管理。 + 基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的 + 跨越广泛的数据服务和存储解决方案。 + SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。 SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。 @@ -719,7 +749,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部 --> * Kubernetes 内的 Virtual SAN 策略支持 - Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN 存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。存储功能需求会转换为 Virtual SAN 策略，然后当 persistent volume（虚拟磁盘）在创建时，会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。 + Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN + 存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。 + 存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时， + 会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。 更多有关 persistent volume 管理的存储策略的详细信息， 您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。 @@ -955,7 +988,8 @@ parameters: * `kind`：可能的值是 `shared`（默认）、`dedicated` 和 `managed`。 当 `kind` 的值是 `shared` 时，所有非托管磁盘都在集群的同一个资源组中的几个共享存储帐户中创建。 当 `kind` 的值是 `dedicated` 时，将为在集群的同一个资源组中新的非托管磁盘创建新的专用存储帐户。 -* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。 +* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。 + 若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。 -在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 secret。如果集群同时启用了 [RBAC](/docs/admin/authorization/rbac/) 和 [Controller Roles](/docs/admin/authorization/rbac/#controller-roles)， +在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了 +[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)， 为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。 @@ -22,42 +15,40 @@ weight: 30 - -本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。 - - - +本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/zh/docs/concepts/storage/volumes)。 ## 介绍 - - -{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 +{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 +`dataSource` 字段中指定存在的 +{{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}， +来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 -克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 +克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。 +唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 -从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound 状态且可用的（不在使用中）。 - - +从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时， +增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound +状态且可用的（不在使用中）。 + 用户在使用该功能时，需要注意以下事项： -## 供应 - - +## 供应 克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。 @@ -112,7 +100,8 @@ spec: ``` {{< note >}} @@ -127,14 +116,14 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c ## 用法 - - -一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 - +一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。 +可以预期的是，新创建的 PVC 是一个独立的对象。 +可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。 +这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 diff --git a/content/zh/docs/concepts/storage/volume-snapshots.md b/content/zh/docs/concepts/storage/volume-snapshots.md index f729f4b923..aaa68a342d 100644 --- a/content/zh/docs/concepts/storage/volume-snapshots.md +++ b/content/zh/docs/concepts/storage/volume-snapshots.md @@ -5,18 +5,9 @@ weight: 20 --- @@ -26,9 +17,8 @@ weight: 20 -在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes 的 [持久卷](/docs/concepts/storage/persistent-volumes/)。 - - +在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes +的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。 @@ -108,7 +98,9 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be --> #### 动态的 {#dynamic} -可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。在获取快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定要用的特定于存储提供程序的参数。 +可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。 +在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/) +指定要用的特定于存储提供程序的参数。 `persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。 -卷快照可以通过指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。 +卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/) +使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。 -如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。 +如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。 +对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。 ``` apiVersion: snapshot.storage.k8s.io/v1beta1 @@ -266,6 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object. For more details, see [Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). --> -更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 - +更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index 731f73d53f..262798346f 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -1,14 +1,15 @@ --- -reviewers: -- jsafrane -- saad-ali -- thockin -- msau42 -title: Volumes +title: 卷 content_type: concept weight: 10 --- + + - -阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 - - - +阅读本文前建议您熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 @@ -54,7 +51,8 @@ parameters to volumes). Docker 也有 [Volume](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 在 Docker 中，Volume 是磁盘上或者另外一个容器内的一个目录。 直到最近，Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。 -虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 +虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限 +（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 - 另一方面，Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 -当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 +当然，当一个 Pod 不再存在时，卷也将不再存在。 +也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 - 卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。 @@ -87,7 +84,6 @@ field) and where to mount those into Containers (the `.spec.containers.volumeMounts` field). --> - 使用卷时, Pod 声明中需要提供卷的类型 (`.spec.volumes` 字段)和卷挂载的位置 (`.spec.containers.volumeMounts` 字段). - 容器中的进程能看到由它们的 Docker 镜像和卷组成的文件系统视图。 -[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) 位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 +[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) +位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。 @@ -110,7 +106,6 @@ Pod 中的每个容器必须独立地指定每个卷的挂载位置。 Kubernetes supports several types of Volumes: --> - ## Volume 的类型 Kubernetes 支持下列类型的卷： @@ -161,19 +156,15 @@ volume are preserved and the volume is merely unmounted. This means that an EBS volume can be pre-populated with data, and that data can be "handed off" between Pods. --> - -`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](http://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 +`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 与 `emptyDir` 在删除 Pod 时会被删除不同，EBS 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着 EBS 卷可以预先填充数据，并且可以在 Pod 之间传递数据。 -{{< caution >}} - - +{{< caution >}} 您在使用 EBS 卷之前必须先创建它，可以使用 `aws ec2 create-volume` 命令进行创建；也可以使用 AWS API 进行创建。 - {{< /caution >}} - 使用 `awsElasticBlockStore` 卷时有一些限制： * Pod 正在运行的节点必须是 AWS EC2 实例。 @@ -195,7 +185,6 @@ There are some restrictions when using an `awsElasticBlockStore` volume: Before you can use an EBS volume with a Pod, you need to create it. --> - #### 创建 EBS 卷 在将 EBS 卷用到 Pod 上之前，您首先要创建它。 @@ -208,13 +197,11 @@ aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 Make sure the zone matches the zone you brought up your cluster in. (And also check that the size and EBS volume type are suitable for your use!) --> - 确保该区域与您的群集所在的区域相匹配。（也要检查卷的大小和 EBS 卷类型都适合您的用途！） - #### AWS EBS 配置示例 ```yaml @@ -276,7 +263,6 @@ into a Pod. More details can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). --> - `azureFile` 用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume） (SMB 2.1 和 3.0)。 更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 @@ -295,7 +281,6 @@ Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` Alpha features must be enabled. --> - 启用azureFile的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加file.csi.azure.com容器存储接口（CSI）驱动程序中。 为了使用此功能，必须在群集上安装 [Azure文件CSI驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， 并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha功能 必须启用。 @@ -310,37 +295,32 @@ unmounted. This means that a CephFS volume can be pre-populated with data, and that data can be "handed off" between Pods. CephFS can be mounted by multiple writers simultaneously. --> - -`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 +`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着 CephFS 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。 - -{{< caution >}} - - +{{< caution >}} 在您使用 Ceph 卷之前，您的 Ceph 服务器必须正常运行并且要使用的 share 被导出（exported）。 {{< /caution >}} - 更多信息请参考 [CephFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)。 ### cinder {#cinder} -{{< note >}} - - -先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 有关 cloudprovider 配置，请参考 [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack)。 - +{{< note >}} +先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 +有关 cloudprovider 配置，请参考 +[cloud provider openstack](/zh/docs/concepts/cluster-administration/cloud-providers/#openstack)。 {{< /note >}} - `cinder` 用于将 OpenStack Cinder 卷安装到 Pod 中。 #### Cinder Volume示例配置 @@ -402,8 +381,7 @@ provides a way to inject configuration data into Pods. The data stored in a `ConfigMap` object can be referenced in a volume of type `configMap` and then consumed by containerized applications running in a Pod. --> - -[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 +[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 `ConfigMap` 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被应用到 Pod 中运行的容器化应用。 - `log-config` ConfigMap 是以卷的形式挂载的， 存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 "`/etc/config/log_level`" 路径下。 请注意，这个路径来源于 Volume 的 `mountPath` 和 `log_level` 键对应的 `path`。 -{{< caution >}} -在使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 +{{< caution >}} +在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 {{< /caution >}} -{{< note >}} +{{< note >}} 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 {{< /note >}} @@ -475,20 +452,18 @@ It mounts a directory and writes the requested data in plain text files. `downwardAPI` 卷用于使 downward API 数据对应用程序可用。 这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 -{{< note >}} - - +{{< note >}} 容器以挂载 [subPath](#using-subpath) 卷的方式使用 downwardAPI 时，将不能接收到它的更新。 {{< /note >}} -更多详细信息请参考 [`downwardAPI` 卷示例](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 +更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 ### emptyDir {#emptydir} @@ -506,11 +481,10 @@ any reason, the data in the `emptyDir` is deleted forever. 尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，但是这些容器都可以读写 `emptyDir` 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会永久删除。 -{{< note >}} - +{{< note >}} 容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃时 `emptyDir` 卷中的数据是安全的。 {{< /note >}} @@ -522,14 +496,12 @@ Some uses for an `emptyDir` are: * holding files that a content-manager Container fetches while a webserver Container serves the data --> - `emptyDir` 的一些用途： * 缓存空间，例如基于磁盘的归并排序。 * 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。 * 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。 - - 默认情况下， `emptyDir` 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 但是，您可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes 为您安装 tmpfs（基于 RAM 的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 @@ -548,7 +519,6 @@ tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会 - #### Pod 示例 ```yaml @@ -576,24 +546,22 @@ You can specify single or multiple target World Wide Names using the parameter `targetWWNs` in your volume configuration. If multiple WWNs are specified, targetWWNs expect that those WWNs are from multi-path connections. --> - ### fc (光纤通道) {#fc} `fc` 卷允许将现有的光纤通道卷挂载到 Pod 中。 可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN。 如果指定多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 -{{< caution >}} +{{< caution >}} 您必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样 Kubernetes 主机才可以访问它们。 {{< /caution >}} - 更多详情请参考 [FC 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)。 - `flocker` 卷允许将一个 Flocker 数据集挂载到 Pod 中。 如果数据集在 Flocker 中不存在，则需要首先使用 Flocker CLI 或 Flocker API 创建数据集。 如果数据集已经存在，那么 Flocker 将把它重新附加到 Pod 被调度的节点。 这意味着数据可以根据需要在 Pod 之间 "传递"。 - -{{< caution >}} +{{< caution >}} 您在使用 Flocker 之前必须先安装运行自己的 Flocker。 {{< /caution >}} @@ -651,10 +617,10 @@ pre-populated with data, and that data can be "handed off" between Pods. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} +{{< caution >}} 您在使用 PD 前，必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 {{< /caution >}} @@ -664,7 +630,6 @@ There are some restrictions when using a `gcePersistentDisk`: * the nodes on which Pods are running must be GCE VMs * those VMs need to be in the same GCE project and zone as the PD --> - 使用 `gcePersistentDisk` 时有一些限制： * 运行 Pod 的节点必须是 GCE VM @@ -677,7 +642,6 @@ and then serve it in parallel from as many Pods as you need. Unfortunately, PDs can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed. --> - PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 这意味着您可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 不幸的是，PD 只能由单个使用者以读写模式挂载——即不允许同时写入。 @@ -686,7 +650,6 @@ PD 的一个特点是它们可以同时被多个消费者以只读方式挂载 Using a PD on a Pod controlled by a ReplicationController will fail unless the PD is read-only or the replica count is 0 or 1. --> - 在由 ReplicationController 所管理的 Pod 上使用 PD 将会失败，除非 PD 是只读模式或者副本的数量是 0 或 1。 - #### 创建持久盘（PD） 在 Pod 中使用 GCE 持久盘之前，您首先要创建它。 @@ -706,7 +668,6 @@ gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk - #### Pod 示例 ```yaml @@ -731,7 +692,6 @@ spec: - #### 区域持久盘（Regional Persistent Disks） {{< feature-state for_k8s_version="v1.10" state="beta" >}} @@ -739,19 +699,18 @@ spec: - [区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许您创建能在同一区域的两个可用区中使用的持久盘。 要使用这个功能，必须以持久盘的方式提供卷；Pod 不支持直接引用这种卷。 - #### 手动供应基于区域 PD 的 PersistentVolume -使用 [为 GCE PD 定义的存储类](/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 +使用 [为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 在创建 PersistentVolume 之前，您首先要创建 PD。 ```shell @@ -798,7 +757,6 @@ Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-drive must be installed on the cluster and the `CSIMigration` and `CSIMigrationGCE` Alpha features must be enabled. --> - 启用 GCE PD 的 CSI 迁移功能后，它会将所有插件操作从现有的内建插件填添加 `pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序中。 为了使用此功能，必须在群集上安装 [GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， 并且 `CSIMigration` 和 `CSIMigrationGCE` Alpha功能 必须启用。 @@ -810,10 +768,10 @@ Alpha features must be enabled. ### gitRepo (已弃用) -{{< warning >}} +{{< warning >}} gitRepo 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 [EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 {{< /warning >}} @@ -862,22 +820,20 @@ means that a glusterfs volume can be pre-populated with data, and that data can be "handed off" between Pods. GlusterFS can be mounted by multiple writers simultaneously. --> - -`glusterfs` 卷能将 [Glusterfs](http://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 +`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。GlusterFS 可以被多个写者同时挂载。 -{{< caution >}} +{{< caution >}} 在使用前您必须先安装运行自己的 GlusterFS。 {{< /caution >}} - 更多详情请参考 [GlusterFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)。 ### hostPath {#hostpath} @@ -959,12 +915,13 @@ Watch out when using this type of volume, because: * 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 * 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。 -* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 [特权容器](/docs/user-guide/security-context) 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 +* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 +[特权容器](/zh/docs/tasks/configure-pod-container/security-context/) +中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 - #### Pod 示例 ```yaml @@ -988,9 +945,16 @@ spec: type: Directory ``` + {{< caution >}} - -应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。如果挂载挂载文件的父目录不存在，pod 启动会失败。为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： +应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。 +如果挂载挂载文件的父目录不存在，pod 启动会失败。 +为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： {{< /caution >}} #### FileOrCreate pod 示例 @@ -1035,10 +999,10 @@ that data can be "handed off" between Pods. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} +{{< caution >}} 在您使用 iSCSI 卷之前，您必须拥有自己的 iSCSI 服务器，并在上面创建卷。 {{< /caution >}} @@ -1049,14 +1013,12 @@ and then serve it in parallel from as many Pods as you need. Unfortunately, iSCSI volumes can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed. --> - iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 这意味着您可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上提供它。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。 - 更多详情请参考 [iSCSI 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)。 +`NodeAffinity` field. +--> +{{< note >}} alpha 版本的 PersistentVolume NodeAffinity 注释已被取消，将在将来的版本中废弃。 用户必须更新现有的使用该注解的 PersistentVolume，以使用新的 PersistentVolume `NodeAffinity` 字段。 {{< /note >}} @@ -1094,7 +1058,8 @@ portable manner without manually scheduling Pods to nodes, as the system is awar of the volume's node constraints by looking at the node affinity on the PersistentVolume. --> -相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod 调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 +相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod +调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 - 然而，`local` 卷仍然取决于底层节点的可用性，并不是适合所有应用程序。 如果节点变得不健康，那么`local` 卷也将变得不可访问，并且使用它的 Pod 将不能运行。 使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 @@ -1145,7 +1109,6 @@ PersistentVolume `nodeAffinity` is required when using local volumes. It enables the Kubernetes scheduler to correctly schedule Pods using local volumes to the correct node. --> - 使用 `local` 卷时，需要使用 PersistentVolume 对象的 `nodeAffinity` 字段。 它使 Kubernetes 调度器能够将使用 `local` 卷的 Pod 正确地调度到合适的节点。 @@ -1154,8 +1117,8 @@ PersistentVolume `volumeMode` can now be set to "Block" (instead of the default value "Filesystem") to expose the local volume as a raw block device. The `volumeMode` field requires `BlockVolume` Alpha feature gate to be enabled. --> - -现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block"（而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 +现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block" +（而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 `volumeMode` 字段需要启用 Alpha 功能 `BlockVolume`。 当使用 `local` 卷时，建议创建一个 StorageClass，将 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。 -请参考 [示例](/docs/concepts/storage/storage-classes/#local)。 -延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 +请参考[示例](/zh/docs/concepts/storage/storage-classes/#local)。 +延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， +会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 - 您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 请注意，此驱动不支持动态配置。 有关如何运行外部 `local` 卷驱动的示例，请参考 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。 -{{< note >}} +{{< note >}} 如果不使用外部静态驱动来管理卷的生命周期，则用户需要手动清理和删除 local 类型的持久卷。 {{< /note >}} @@ -1203,22 +1166,20 @@ unmounted. This means that an NFS volume can be pre-populated with data, and that data can be "handed off" between Pods. NFS can be mounted by multiple writers simultaneously. --> - `nfs` 卷能将 NFS (网络文件系统) 挂载到您的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 -{{< caution >}} +{{< caution >}} 在您使用 NFS 卷之前，必须运行自己的 NFS 服务器并将目标 share 导出备用。 {{< /caution >}} - 要了解更多详情请参考 [NFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)。 ### persistentVolumeClaim {#persistentvolumeclaim} @@ -1229,7 +1190,7 @@ A `persistentVolumeClaim` volume is used to mount a way for users to "claim" durable storage (such as a GCE PersistentDisk or an iSCSI volume) without knowing the details of the particular cloud environment. --> -`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 +`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/) +更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/) ### projected {#projected} @@ -1273,7 +1234,8 @@ True. --> 服务帐户令牌的映射是 Kubernetes 1.11 版本中引入的一个功能，并在 1.12 版本中被提升为 Beta 功能。 -若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 +若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` +[功能开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 +`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到您的 Pod 中。 -`quobyte` 卷允许将现有的 [Quobyte](http://www.quobyte.com) 卷挂载到您的 Pod 中。 - -{{< caution >}} +{{< caution >}} 在使用 Quobyte 卷之前，您首先要进行安装并创建好卷。 - {{< /caution >}} - Quobyte 支持{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 Quobyte 的 GitHub 项目具有[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。 @@ -1532,16 +1491,14 @@ a `rbd` volume are preserved and the volume is merely unmounted. This means that a RBD volume can be pre-populated with data, and that data can be "handed off" between Pods. --> - -`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. +`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 - -{{< caution >}} +{{< caution >}} 在使用 RBD 之前，您必须安装运行 Ceph。 {{< /caution >}} @@ -1574,18 +1531,17 @@ volumes (or it can dynamically provision new volumes for persistent volume claim ScaleIO 是基于软件的存储平台，可以使用现有硬件来创建可伸缩的、共享的而且是网络化的块存储集群。 `scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷，参见[ScaleIO 持久卷](/docs/concepts/storage/persistent-volumes/#scaleio))。 -{{< caution >}} +{{< caution >}} 在使用前，您必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 {{< /caution >}} - 下面是配置了 ScaleIO 的 Pod 示例： ```yaml @@ -1632,26 +1588,25 @@ non-volatile storage. `secret` 卷用来给 Pod 传递敏感信息，例如密码。您可以将 secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 `secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。 -{{< caution >}} +{{< caution >}} 使用前您必须在 Kubernetes API 中创建 secret。 {{< /caution >}} -{{< note >}} +{{< note >}} 容器以 [subPath](#using-subpath) 卷的方式挂载 Secret 时，它将感知不到 Secret 的更新。 {{< /note >}} - -Secret 的更多详情请参考[这里](/docs/user-guide/secrets)。 +Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/)。 ### storageOS {#storageos} @@ -1659,7 +1614,6 @@ Secret 的更多详情请参考[这里](/docs/user-guide/secrets)。 A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) volume to be mounted into your Pod. --> - `storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到您的 Pod 中。 - StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes 集群中的任何节点访问本地或关联的存储。 为应对节点失效状况，可以复制数据。 若需提高利用率和降低成本，可以考虑瘦配置（Thin Provisioning）和数据压缩。 @@ -1679,23 +1632,20 @@ At its core, StorageOS provides block storage to Containers, accessible via a fi The StorageOS Container requires 64-bit Linux and has no additional dependencies. A free developer license is available. --> - 作为其核心能力之一，StorageOS 为容器提供了可以通过文件系统访问的块存储。 StorageOS 容器需要 64 位的 Linux，并且没有其他的依赖关系。 StorageOS 提供免费的开发者授权许可。 -{{< caution >}} - +{{< caution >}} 您必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 StorageOS 容器。 有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 - {{< /caution >}} ```yaml @@ -1735,27 +1685,27 @@ For more information including Dynamic Provisioning and Persistent Volume Claims ### vsphereVolume {#vspherevolume} -{{< note >}} -前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 [vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 +{{< note >}} +前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 +[vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 {{< /note >}} - `vsphereVolume` 用来将 vSphere VMDK 卷挂载到您的 Pod 中。 在卸载卷时，卷的内容会被保留。 vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 -{{< caution >}} +{{< caution >}} 在挂载到 Pod 之前，您必须用下列方式之一创建 VMDK。 {{< /caution >}} @@ -1764,7 +1714,6 @@ You must create VMDK using one of the following methods before using with Pod. Choose one of the following methods to create a VMDK. --> - #### 创建 VMDK 卷 选择下列方式之一创建 VMDK。 @@ -1793,7 +1742,6 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk - #### vSphere VMDK 配置示例 ```yaml @@ -1819,7 +1767,6 @@ spec: - 更多示例可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)找到。 - -## 使用 subPath +## 使用 subPath {#using-path} 有时，在单个 Pod 中共享卷以供多方使用是很有用的。 `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。 @@ -1838,7 +1784,6 @@ property can be used to specify a sub-path inside the referenced volume instead Here is an example of a Pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume. The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder: --> - 下面是一个使用同一共享卷的、内含 LAMP 栈（Linux Apache Mysql PHP）的 Pod 的示例。 HTML 内容被映射到卷的 `html` 文件夹，数据库将被存储在卷的 `mysql` 文件夹中： @@ -1878,13 +1823,11 @@ spec: {{< feature-state for_k8s_version="v1.15" state="beta" >}} - - 使用 `subPathExpr` 字段从 Downward API 环境变量构造 `subPath` 目录名。 在使用此特性之前，必须启用 `VolumeSubpathEnvExpansion` 功能开关。 `subPath` 和 `subPathExpr` 属性是互斥的。 @@ -1892,8 +1835,8 @@ The `subPath` and `subPathExpr` properties are mutually exclusive. - -在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` 在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 +在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` +在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 中。 ```yaml @@ -1932,7 +1875,6 @@ medium of the filesystem holding the kubelet root dir (typically `hostPath` volume can consume, and no isolation between Containers or between Pods. --> - ## 资源 `emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 @@ -1944,8 +1886,10 @@ request a certain amount of space using a [resource](/docs/user-guide/compute-re specification, and to select the type of media to use, for clusters that have several media types. --> - -将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 [resource](/docs/user-guide/computeresources) 规范来请求一定量的空间，并且能够为具有多种介质类型的集群选择要使用的介质类型。 +将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 +[resource](/zh/docs/concepts/configuration/manage-compute-resources-containers/) +规约来请求一定量的空间， +并且能够为具有多种介质类型的集群选择要使用的介质类型。 -在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的，这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 +在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的， +这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码合并到 Kubernetes 核心代码库中。 +{{< note >}} +Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 {{< /note >}} -Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 - -{{< note >}} - +{{< note >}} CSI驱动程序可能并非在所有Kubernetes版本中都兼容。 请查看特定CSI驱动程序的文档，以获取每个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 - {{< /note >}} - - `volumeHandle`：唯一标识卷的字符串值。 该值必须与CSI 驱动程序在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 @@ -2076,7 +2017,6 @@ persistent volume: passed to the CSI driver via the `readonly` field in the `ControllerPublishVolumeRequest`. --> - - `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。 默认值是 false。 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动程序。 @@ -2090,7 +2030,6 @@ persistent volume: `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. --> - - `fsType`：如果 PV 的 `VolumeMode` 为 `Filesystem`，那么此字段指定挂载卷时应该使用的文件系统。 如果卷尚未格式化，并且支持格式化，此值将用于格式化卷。 此值可以通过 `ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和 @@ -2117,7 +2056,6 @@ persistent volume: optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. --> - - `controllerPublishSecretRef`：对包含敏感信息的 secret 对象的引用；该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 此字段是可选的；在不需要 secret 时可以是空的。 如果 secret 对象包含多个 secret，则所有的 secret 都会被传递。 @@ -2129,7 +2067,6 @@ persistent volume: is required. If the secret object contains more than one secret, all secrets are passed. --> - - `nodeStageSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 此字段是可选的，如果不需要 secret，则可能是空的。 如果 secret 对象包含多个 secret，则传递所有 secret。 @@ -2141,7 +2078,6 @@ persistent volume: secret is required. If the secret object contains more than one secret, all secrets are passed. --> - - `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 此字段是可选的，如果不需要 secret，则可能是空的。 如果 secret 对象包含多个 secret，则传递所有 secret。 @@ -2149,6 +2085,7 @@ persistent volume: + #### CSI 原始块卷支持 {{< feature-state for_k8s_version="v1.14" state="beta" >}} @@ -2178,8 +2115,7 @@ CSI块卷支持功能已启用，但默认情况下启用。必须为此功能 Learn how to [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). --> - -学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 +学习怎样[安装您的带有块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 -＃开发人员资源 +# 开发人员资源 有关如何开发 CSI 驱动程序的更多信息，请参考[kubernetes-csi文档](https://kubernetes-csi.github.io/docs/) #### 从 in-tree 插件迁移到 CSI 驱动程序 @@ -2277,7 +2213,6 @@ plugin path on each node (and in some cases master). Pods interact with FlexVolume drivers through the `flexvolume` in-tree plugin. More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md). --> - FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的 out-of-tree 插件接口。 它使用基于 exec 的模型来与驱动程序对接。 用户必须在每个节点（在某些情况下是主节点）上的预定义卷插件路径中安装 FlexVolume 驱动程序可执行文件。 @@ -2356,8 +2291,6 @@ Its values are: 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rshared` 挂载传播选项。 - -{{< caution >}} - +{{< caution >}} `Bidirectional` 形式的挂载传播可能比较危险。 它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 强烈建议您熟悉 Linux 内核行为。 此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 - {{< /caution >}}