[zh] Fix links in concepts section
This commit is contained in:
Qiming Teng
@@ -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/)
|
||||
以获取该过程的详细说明。
|
||||
|
||||
<!--
|
||||
@@ -1872,7 +1871,7 @@ Secrets are protected when transmitted over these channels.
|
||||
You can enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
|
||||
for secret data, so that the secrets are not stored in the clear into {{< glossary_tooltip term_id="etcd" >}}.
|
||||
-->
|
||||
你可以为 Secret 数据开启[静态加密](//zhdocs/tasks/administer-cluster/encrypt-data/)，
|
||||
你可以为 Secret 数据开启[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)，
|
||||
这样 Secret 数据就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}} 中。
|
||||
|
||||
<!--
|
||||
|
||||
@@ -285,7 +285,10 @@ You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, o
|
||||
[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
|
||||
-->
|
||||
|
||||
你可以在上面的例子中看到 `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 从特定节点中驱逐。
|
||||
|
||||
<!--
|
||||
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
|
||||
@@ -599,7 +602,10 @@ no two instances are located on the same host.
|
||||
See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
|
||||
for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.
|
||||
-->
|
||||
上面的例子使用 `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。
|
||||
|
||||
<!--
|
||||
The design documents for
|
||||
@@ -668,7 +674,8 @@ The design documents for
|
||||
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features.
|
||||
-->
|
||||
|
||||
[节点亲和](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)的设计文档包含这些功能的其他背景信息。
|
||||
|
||||
<!--
|
||||
Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources.
|
||||
@@ -676,8 +683,7 @@ The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can tak
|
||||
resource allocation decisions.
|
||||
-->
|
||||
|
||||
一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
|
||||
[拓扑管理](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
|
||||
[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
可以参与到节点级别的资源分配决定中。
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
---
|
||||
title: 应用连接到 Service
|
||||
title: 使用 Service 连接到应用
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
@@ -24,8 +23,6 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same
|
||||
既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
|
||||
在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。
|
||||
|
||||
|
||||
|
||||
默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。
|
||||
为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。
|
||||
|
||||
@@ -35,10 +32,8 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
|
||||
这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。
|
||||
文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。
|
||||
|
||||
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
|
||||
|
||||
|
||||
|
||||
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的
|
||||
[Jenkins CI 应用](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -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
|
||||
<!--
|
||||
Check your pods' IPs:
|
||||
-->
|
||||
|
||||
检查 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) 的内容。
|
||||
|
||||
<!--
|
||||
## Creating a Service
|
||||
@@ -107,7 +98,6 @@ A Kubernetes Service is an abstraction which defines a logical set of Pods runni
|
||||
|
||||
You can create a Service for your 2 nginx replicas with `kubectl expose`:
|
||||
-->
|
||||
|
||||
## 创建 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 `<CLUSTER-IP>:<PORT>` 。
|
||||
注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
|
||||
可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。
|
||||
可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
|
||||
的内容。
|
||||
|
||||
<!--
|
||||
## Accessing the Service
|
||||
@@ -219,22 +211,19 @@ and DNS. The former works out of the box while the latter requires the
|
||||
## 访问 Service
|
||||
|
||||
Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件]
|
||||
[CoreDNS 集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
|
||||
{{< note >}}
|
||||
[CoreDNS 集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
|
||||
<!--
|
||||
If the service environment variables are not desired (because possible clashing with expected program ones,
|
||||
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
|
||||
flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
-->
|
||||
|
||||
{{< 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 >}}
|
||||
|
||||
|
||||
<!--
|
||||
### Environment Variables
|
||||
|
||||
@@ -324,9 +313,10 @@ The rest of this section will assume you have a Service with a long lived IP
|
||||
cluster addon), so you can talk to the Service from any pod in your cluster using
|
||||
standard methods (e.g. gethostbyname). Let's run another curl application to test this:
|
||||
-->
|
||||
|
||||
如果没有在运行，可以 [启用它](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://<EXTERNAL-IP>:<NODE-PORT> -k
|
||||
```shell
|
||||
curl https://<EXTERNAL-IP>:<NODE-PORT> -k
|
||||
```
|
||||
|
||||
输出类似于：
|
||||
```
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
```
|
||||
@@ -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" %}}
|
||||
|
||||
<!--
|
||||
@@ -610,3 +617,4 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
||||
* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/)
|
||||
* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
|
||||
|
||||
@@ -3,26 +3,19 @@ title: IPv4/IPv6 双协议栈
|
||||
feature:
|
||||
title: IPv4/IPv6 双协议栈
|
||||
description: >
|
||||
Allocation of IPv4 and IPv6 addresses to Pods and Services
|
||||
|
||||
为 Pod 和 Service 分配 IPv4 和 IPv6 地址
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- lachie83
|
||||
- khenidak
|
||||
- aramase
|
||||
title: IPv4/IPv6 dual-stack
|
||||
feature:
|
||||
title: IPv4/IPv6 dual-stack
|
||||
description: >
|
||||
Allocation of IPv4 and IPv6 addresses to Pods and Services
|
||||
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -32,14 +25,15 @@ weight: 70
|
||||
<!--
|
||||
IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
|
||||
-->
|
||||
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" >}}。
|
||||
|
||||
<!--
|
||||
If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.
|
||||
-->
|
||||
如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，则该集群将支持同时分配 IPv4 和 IPv6 地址。
|
||||
|
||||
|
||||
如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，
|
||||
则该集群将支持同时分配 IPv4 和 IPv6 地址。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -89,7 +83,9 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack
|
||||
<!--
|
||||
To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments:
|
||||
-->
|
||||
要启用 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" >}}。
|
||||
对于[出口](#出口流量)流量，该字段的配置不是必须的。
|
||||
|
||||
<!--
|
||||
The default address family for your cluster is the address family of the first service cluster IP range configured via the `--service-cluster-ip-range` flag to the kube-controller-manager.
|
||||
The default address family for your cluster is the address family of the first service cluster IP range configured via the `-service-cluster-ip-range` flag to the kube-controller-manager.
|
||||
-->
|
||||
{{< note >}}
|
||||
集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置。
|
||||
集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过
|
||||
`kube-controller-manager` 上的 `--service-cluster-ip-range` 标志设置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -158,12 +161,13 @@ For comparison, the following Service specification will be assigned an IPV4 add
|
||||
<!--
|
||||
### Type LoadBalancer
|
||||
-->
|
||||
### 负载均衡器类型
|
||||
### LoadBalancer 类型
|
||||
|
||||
<!--
|
||||
On cloud providers which support IPv6 enabled external load balancers, setting the `type` field to `LoadBalancer` in additional to setting `ipFamily` field to `IPv6` provisions a cloud load balancer for your Service.
|
||||
-->
|
||||
在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。
|
||||
在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，
|
||||
将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。
|
||||
|
||||
<!--
|
||||
## Egress Traffic
|
||||
@@ -173,7 +177,12 @@ On cloud providers which support IPv6 enabled external load balancers, setting t
|
||||
<!--
|
||||
The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
|
||||
-->
|
||||
公共路由和非公共路由的 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 伪装。
|
||||
|
||||
<!--
|
||||
## Known Issues
|
||||
@@ -181,19 +190,15 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac
|
||||
## 已知问题
|
||||
|
||||
<!--
|
||||
* Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
|
||||
* Kubenet forces IPv4,IPv6 positional reporting of IPs (-cluster-cidr)
|
||||
-->
|
||||
* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (--cluster-cidr)
|
||||
|
||||
|
||||
* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
|
||||
-->
|
||||
* [验证 IPv4/IPv6 双协议栈](/docs/tasks/network/validate-dual-stack)网络
|
||||
|
||||
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络
|
||||
|
||||
|
||||
|
||||
@@ -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
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- freehan
|
||||
title: Endpoint Slices
|
||||
feature:
|
||||
title: Endpoint Slices
|
||||
@@ -23,7 +18,6 @@ feature:
|
||||
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -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 提供了一种可伸缩和可拓展的替代方案。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -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 规模庞大时会有可观的性能提升。
|
||||
|
||||
<!--
|
||||
## Address Types
|
||||
|
||||
EndpointSlices support three address types:
|
||||
@@ -98,7 +100,16 @@ EndpointSlices support three address types:
|
||||
* IPv4
|
||||
* IPv6
|
||||
* FQDN (Fully Qualified Domain Name)
|
||||
-->
|
||||
## 地址类型
|
||||
|
||||
EndpointSlice 支持三种地址类型：
|
||||
|
||||
* IPv4
|
||||
* IPv6
|
||||
* FQDN (完全合格的域名)
|
||||
|
||||
<!--
|
||||
## Motivation
|
||||
|
||||
The Endpoints API has provided a simple and straightforward way of
|
||||
@@ -114,38 +125,25 @@ significant amounts of network traffic and processing when Endpoints changed.
|
||||
Endpoint Slices help you mitigate those issues as well as provide an extensible
|
||||
platform for additional features such as topological routing.
|
||||
-->
|
||||
|
||||
默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个 endpoints。低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1：1 映射，并具有相似的性能。
|
||||
|
||||
当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。
|
||||
|
||||
<!--
|
||||
## Address Types
|
||||
-->
|
||||
## 地址类型
|
||||
|
||||
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" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
-->
|
||||
* [启用 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/)
|
||||
|
||||
|
||||
@@ -1,134 +1,155 @@
|
||||
---
|
||||
title: Ingress 控制器
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Ingress Controllers
|
||||
reviewers:
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
In order for the Ingress resource to work, the cluster must have an ingress controller running.
|
||||
|
||||
Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers
|
||||
are not started automatically with a cluster. Use this page to choose the ingress controller implementation
|
||||
that best fits your cluster.
|
||||
|
||||
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
|
||||
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
|
||||
|
||||
-->
|
||||
|
||||
为了让 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) 控制器。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Additional controllers
|
||||
-->
|
||||
## 其他控制器
|
||||
|
||||
<!--
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
|
||||
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
|
||||
controller with [community](https://www.getambassador.io/docs) or
|
||||
[commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
|
||||
* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
|
||||
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
|
||||
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
|
||||
provided and supported by VMware.
|
||||
* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
|
||||
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
|
||||
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
|
||||
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
|
||||
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
|
||||
* [Istio](https://istio.io/) based ingress controller
|
||||
[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
|
||||
* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
|
||||
[commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
|
||||
[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
|
||||
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
|
||||
[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
|
||||
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
|
||||
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
|
||||
support by [Containous](https://containo.us/services).
|
||||
-->
|
||||
* [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) 的商业支持。
|
||||
|
||||
<!--
|
||||
## Using multiple Ingress controllers
|
||||
-->
|
||||
## 使用多个 Ingress 控制器
|
||||
|
||||
<!--
|
||||
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
|
||||
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
|
||||
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
|
||||
to indicate which ingress controller should be used if more than one exists within your cluster.
|
||||
|
||||
If you do not define a class, your cloud provider may use a default ingress controller.
|
||||
|
||||
Ideally, all ingress controllers should fulfill this specification, but the various ingress
|
||||
controllers operate slightly differently.
|
||||
-->
|
||||
|
||||
你可以在集群中部署[任意数量的 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 控制器的操作略有不同。
|
||||
|
||||
<!--
|
||||
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
|
||||
-->
|
||||
{{< note >}}
|
||||
确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
---
|
||||
title: Ingress 控制器
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Ingress Controllers
|
||||
content_type: concept
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
In order for the Ingress resource to work, the cluster must have an ingress controller running.
|
||||
|
||||
Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers
|
||||
are not started automatically with a cluster. Use this page to choose the ingress controller implementation
|
||||
that best fits your cluster.
|
||||
|
||||
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
|
||||
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
|
||||
-->
|
||||
为了让 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) 控制器。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Additional controllers
|
||||
-->
|
||||
## 其他控制器
|
||||
|
||||
<!--
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
|
||||
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
|
||||
controller with [community](https://www.getambassador.io/docs) or
|
||||
[commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
|
||||
* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
|
||||
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
|
||||
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
|
||||
provided and supported by VMware.
|
||||
-->
|
||||
* [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 provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
|
||||
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
|
||||
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
|
||||
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
|
||||
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
|
||||
* [Istio](https://istio.io/) based ingress controller
|
||||
[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
|
||||
-->
|
||||
* 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/) offers [community](https://discuss.konghq.com/c/kubernetes) or
|
||||
[commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
|
||||
[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
|
||||
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
|
||||
[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
|
||||
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
|
||||
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
|
||||
support by [Containous](https://containo.us/services).
|
||||
-->
|
||||
* [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) 的商业支持。
|
||||
|
||||
<!--
|
||||
## Using multiple Ingress controllers
|
||||
-->
|
||||
## 使用多个 Ingress 控制器
|
||||
|
||||
<!--
|
||||
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
|
||||
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
|
||||
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
|
||||
to indicate which ingress controller should be used if more than one exists within your cluster.
|
||||
|
||||
If you do not define a class, your cloud provider may use a default ingress controller.
|
||||
|
||||
Ideally, all ingress controllers should fulfill this specification, but the various ingress
|
||||
controllers operate slightly differently.
|
||||
-->
|
||||
|
||||
你可以在集群中部署[任意数量的 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 控制器的操作略有不同。
|
||||
|
||||
<!--
|
||||
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
|
||||
-->
|
||||
{{< note >}}
|
||||
确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
|
||||
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
|
||||
-->
|
||||
* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。
|
||||
* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。
|
||||
|
||||
|
||||
<!--
|
||||
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
|
||||
* [Set up Ingress on Minikube with the NGINX Controller](/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)。
|
||||
|
||||
|
||||
@@ -5,16 +5,10 @@ weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- thockin
|
||||
- caseydavenport
|
||||
- danwinship
|
||||
title: Network Policies
|
||||
content_type: concept
|
||||
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 所允许的通信规则。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
@@ -42,7 +34,9 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
|
||||
|
||||
## 前提
|
||||
|
||||
网络策略通过[网络插件](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。
|
||||
网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。
|
||||
创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。
|
||||
|
||||
<!--
|
||||
## Isolated and Non-isolated Pods
|
||||
@@ -53,14 +47,17 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
|
||||
|
||||
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.
|
||||
-->
|
||||
|
||||
## 隔离和非隔离的 Pod
|
||||
|
||||
默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
|
||||
|
||||
Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，该 Pod 会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量)
|
||||
Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，
|
||||
该 Pod 会拒绝网络策略所不允许的连接。
|
||||
（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量）
|
||||
|
||||
网络策略不会冲突，它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。
|
||||
网络策略不会冲突，它们是累积的。
|
||||
如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
|
||||
ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。
|
||||
|
||||
<!--
|
||||
## The NetworkPolicy resource {#networkpolicy-resource}
|
||||
@@ -72,7 +69,7 @@ An example NetworkPolicy might look like this:
|
||||
|
||||
## NetworkPolicy 资源 {#networkpolicy-resource}
|
||||
|
||||
查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。
|
||||
查看 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。
|
||||
|
||||
下面是一个 NetworkPolicy 的示例:
|
||||
|
||||
@@ -138,8 +135,9 @@ __ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules.
|
||||
__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
|
||||
-->
|
||||
|
||||
__必填字段__: 与所有其他的 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/) 来进行更多的示例演练。
|
||||
|
||||
<!--
|
||||
## Behavior of `to` and `from` selectors
|
||||
@@ -362,7 +360,9 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
|
||||
To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
|
||||
When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
|
||||
-->
|
||||
要启用此特性，你（或你的集群管理员）需要通过为 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`。
|
||||
|
||||
<!--
|
||||
You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
|
||||
@@ -371,20 +371,16 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
|
||||
必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
|
||||
walkthrough for further examples.
|
||||
- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
|
||||
-->
|
||||
|
||||
- 查看 [声明网络策略](/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)。
|
||||
|
||||
|
||||
@@ -1461,7 +1461,7 @@ the NLB Target Group's health check on the auto-assigned
|
||||
|
||||
<!--
|
||||
In order to achieve even traffic, either use a DaemonSet, or specify a
|
||||
[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
|
||||
[pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
|
||||
to not locate on the same node.
|
||||
|
||||
You can also use NLB Services with the [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer)
|
||||
@@ -1472,7 +1472,7 @@ groups are modified with the following IP rules:
|
||||
-->
|
||||
|
||||
为了获得均衡流量，请使用 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)
|
||||
|
||||
@@ -4,16 +4,9 @@ content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- saad-ali
|
||||
- jsafrane
|
||||
- thockin
|
||||
- msau42
|
||||
title: Dynamic Volume Provisioning
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -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/)来表示这些卷。
|
||||
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
@@ -66,12 +57,12 @@ have the ability to select from multiple storage options.
|
||||
More information on storage classes can be found
|
||||
[here](/docs/concepts/storage/storage-classes/).
|
||||
-->
|
||||
点击[这里](/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
|
||||
点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
|
||||
|
||||
<!--
|
||||
## Enabling Dynamic Provisioning
|
||||
-->
|
||||
## 启用动态卷供应
|
||||
## 启用动态卷供应 {#enabling-dynamic-provisioning}
|
||||
|
||||
<!--
|
||||
To enable dynamic provisioning, a cluster administrator needs to pre-create
|
||||
@@ -208,6 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
|
||||
Pods are scheduled. This can be accomplished by setting the [Volume Binding
|
||||
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
-->
|
||||
在[多区域](/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)来实现。
|
||||
|
||||
|
||||
@@ -1,14 +1,15 @@
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
title: Storage Classes
|
||||
title: 存储类
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Storage Classes
|
||||
content_type: concept
|
||||
weight: 30
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
@@ -16,10 +17,8 @@ This document describes the concept of a StorageClass in Kubernetes. Familiarity
|
||||
with [volumes](/docs/concepts/storage/volumes/) and
|
||||
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
|
||||
-->
|
||||
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/docs/concepts/storage/volumes/) 和
|
||||
[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
|
||||
|
||||
|
||||
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
|
||||
[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -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 >}}
|
||||
<!--
|
||||
You can only use the volume expansion feature to grow a Volume, not to shrink it.
|
||||
-->
|
||||
{{< 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)
|
||||
应该发生在什么时候。
|
||||
|
||||
<!--
|
||||
@@ -266,10 +266,11 @@ and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
|
||||
-->
|
||||
集群管理员可以通过指定 `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/)。
|
||||
|
||||
<!--
|
||||
The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
|
||||
@@ -302,14 +303,13 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
|
||||
and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
|
||||
to see its supported topology keys and examples.
|
||||
-->
|
||||
|
||||
动态配置和预先创建的 PV 也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)，
|
||||
动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
|
||||
但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
|
||||
|
||||
<!--
|
||||
### Allowed Topologies
|
||||
-->
|
||||
### 允许的拓扑结构
|
||||
### 允许的拓扑结构 {#allowed-topologies}
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
<!--
|
||||
@@ -402,14 +402,22 @@ parameters:
|
||||
encrypting the volume. If none is supplied but `encrypted` is true, a key is
|
||||
generated by AWS. See AWS docs for valid ARN value.
|
||||
-->
|
||||
* `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 >}}
|
||||
<!--
|
||||
@@ -445,8 +453,12 @@ parameters:
|
||||
* `replication-type`: `none` or `regional-pd`. Default: `none`.
|
||||
-->
|
||||
* `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 会在集群管理的区域中任意选择。
|
||||
|
||||
<!--
|
||||
`zone` and `zones` parameters are deprecated and replaced with
|
||||
[allowedTopologies](#allowed-topologies)
|
||||
-->
|
||||
{{< 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` : Identification of Secret instance that
|
||||
@@ -539,7 +558,8 @@ parameters:
|
||||
[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
|
||||
-->
|
||||
* `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` is the ID of the cluster
|
||||
@@ -561,9 +581,12 @@ parameters:
|
||||
specified, the volume will be provisioned with a value between 2000-2147483647
|
||||
which are defaults for gidMin and gidMax respectively.
|
||||
-->
|
||||
* `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` : The volume type and its parameters can be configured with this
|
||||
@@ -587,17 +610,17 @@ parameters:
|
||||
deleted when the persistent volume claim is deleted.
|
||||
-->
|
||||
* `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-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
|
||||
当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 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
|
||||
配置文件中指定的数据存储上创建该卷。
|
||||
|
||||
<!--
|
||||
3. Storage Policy Management inside kubernetes
|
||||
@@ -697,7 +724,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
|
||||
-->
|
||||
* 使用现有的 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 集群相同的资源组中。
|
||||
<!--
|
||||
- Premium VM can attach both Standard_LRS and Premium_LRS disks, while Standard
|
||||
VM can only attach Standard_LRS disks.
|
||||
@@ -1015,7 +1049,8 @@ mounting credentials. If the cluster has enabled both
|
||||
add the `create` permission of resource `secret` for clusterrole
|
||||
`system:controller:persistent-volume-binder`.
|
||||
-->
|
||||
在存储分配期间，为挂载凭证创建一个名为 `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` 权限。
|
||||
|
||||
<!--
|
||||
@@ -1075,7 +1110,8 @@ parameters:
|
||||
* `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。
|
||||
这里需要填写字符串，即，是 `"0"` 而不是 `0`。
|
||||
* `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ，
|
||||
`persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
|
||||
`persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）
|
||||
`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
|
||||
|
||||
### ScaleIO
|
||||
|
||||
@@ -1136,8 +1172,8 @@ secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC
|
||||
|
||||
```shell
|
||||
kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
|
||||
--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \
|
||||
--namespace=default
|
||||
--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \
|
||||
--namespace=default
|
||||
```
|
||||
|
||||
### StorageOS
|
||||
|
||||
@@ -5,16 +5,9 @@ weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
title: CSI Volume Cloning
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -22,42 +15,40 @@ weight: 30
|
||||
<!--
|
||||
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
|
||||
-->
|
||||
|
||||
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。
|
||||
|
||||
|
||||
|
||||
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/zh/docs/concepts/storage/volumes)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
|
||||
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
|
||||
-->
|
||||
|
||||
## 介绍
|
||||
|
||||
<!--
|
||||
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
|
||||
-->
|
||||
|
||||
{{< 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" >}}。
|
||||
|
||||
<!--
|
||||
A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume.
|
||||
-->
|
||||
|
||||
克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
|
||||
克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。
|
||||
唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
|
||||
|
||||
<!--
|
||||
The implementation of cloning, from the perspective of the Kubernetes API, simply adds the ability to specify an existing PVC as a dataSource during new PVC creation. The source PVC must be bound and available (not in use).
|
||||
-->
|
||||
|
||||
从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound 状态且可用的（不在使用中）。
|
||||
|
||||
<!--
|
||||
Users need to be aware of the following when using this feature:
|
||||
-->
|
||||
|
||||
从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，
|
||||
增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound
|
||||
状态且可用的（不在使用中）。
|
||||
|
||||
用户在使用该功能时，需要注意以下事项：
|
||||
|
||||
<!--
|
||||
@@ -78,18 +69,15 @@ Users need to be aware of the following when using this feature:
|
||||
* 仅在同一存储类中支持克隆。
|
||||
- 目标卷必须和源卷具有相同的存储类
|
||||
- 可以使用默认的存储类并且 storageClassName 字段在规格中忽略了
|
||||
* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。
|
||||
|
||||
* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行
|
||||
（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。
|
||||
|
||||
<!--
|
||||
## Provisioning
|
||||
-->
|
||||
|
||||
## 供应
|
||||
|
||||
<!--
|
||||
Clones are provisioned just like any other PVC with the exception of adding a dataSource that references an existing PVC in the same namespace.
|
||||
-->
|
||||
## 供应
|
||||
|
||||
克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。
|
||||
|
||||
@@ -112,7 +100,8 @@ spec:
|
||||
```
|
||||
|
||||
<!--
|
||||
You must specify a capacity value for `spec.resources.requests.storage`, and the value you specify must be the same or larger than the capacity of the source volume.
|
||||
You must specify a capacity value for `spec.resources.requests.storage`,
|
||||
and the value you specify must be the same or larger than the capacity of the source volume.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
@@ -127,14 +116,14 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
|
||||
|
||||
<!--
|
||||
## Usage
|
||||
|
||||
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
|
||||
-->
|
||||
|
||||
## 用法
|
||||
|
||||
<!--
|
||||
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
|
||||
-->
|
||||
|
||||
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
|
||||
|
||||
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。
|
||||
可以预期的是，新创建的 PVC 是一个独立的对象。
|
||||
可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。
|
||||
这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
|
||||
|
||||
|
||||
@@ -5,18 +5,9 @@ weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
- jingxu97
|
||||
- xing-yang
|
||||
- yuxiangqian
|
||||
title: Volume Snapshots
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -26,9 +17,8 @@ weight: 20
|
||||
<!--
|
||||
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
-->
|
||||
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes 的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
|
||||
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
|
||||
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -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/)
|
||||
指定要用的特定于存储提供程序的参数。
|
||||
|
||||
<!--
|
||||
### Binding
|
||||
@@ -181,12 +173,14 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
|
||||
-->
|
||||
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。
|
||||
|
||||
卷快照可以通过指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
|
||||
卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
|
||||
使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
|
||||
|
||||
<!--
|
||||
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
|
||||
-->
|
||||
如下面例子所示，对于预配置的快照，需要给快照指定 `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)。
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user