Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
0268ed0c18
commit
b05129acc3
+1
-1
@@ -16,7 +16,7 @@ Modification not using HostAliases is not suggested because the file is managed
|
||||
|
||||
当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。
|
||||
|
||||
建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。
|
||||
建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -22,7 +22,7 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same
|
||||
## Kubernetes 连接容器模型
|
||||
|
||||
既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
|
||||
在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。
|
||||
在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。
|
||||
|
||||
|
||||
|
||||
@@ -225,9 +225,9 @@ Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者
|
||||
|
||||
<!--
|
||||
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).
|
||||
-->
|
||||
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).
|
||||
-->
|
||||
|
||||
如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在
|
||||
[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。
|
||||
|
||||
@@ -54,7 +54,7 @@ For more up-to-date specification, see
|
||||
运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。
|
||||
运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。
|
||||
|
||||
以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。
|
||||
以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。
|
||||
有关最新规范请查看
|
||||
[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
||||
|
||||
@@ -145,7 +145,7 @@ Example:
|
||||
在 v1.3 版本中，PodSpec 具有 `hostname` 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation `pod.beta.kubernetes.io/hostname`。
|
||||
在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 `pod.beta.kubernetes.io/subdomain` 指定了 Pod 的子域名。
|
||||
最终的域名将是 “<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>”。
|
||||
举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。
|
||||
举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。
|
||||
|
||||
在 v1.3 版本中，PodSpec 具有 `subdomain` 字段，可以用来指定 Pod 的子域名。
|
||||
这个字段的值优先于 annotation `pod.beta.kubernetes.io/subdomain` 的值。
|
||||
@@ -235,7 +235,7 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
|
||||
|
||||
因为没有为 Pod 名称创建A记录，所以要创建 Pod 的 A 记录需要 `hostname` 。
|
||||
|
||||
没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。
|
||||
没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。
|
||||
另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则 Pod 需要准备好 A 记录。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -348,10 +348,10 @@ Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
|
||||
-->
|
||||
|
||||
- `nameservers`: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
|
||||
- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
|
||||
- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
|
||||
重复的域名将被删除。
|
||||
Kubernetes最多允许6个搜索域。
|
||||
- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。
|
||||
- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。
|
||||
重复的条目将被删除。
|
||||
|
||||
<!--
|
||||
|
||||
@@ -7,15 +7,15 @@ weight: 40
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
In order for the Ingress resource to work, the cluster must have an ingress controller running.
|
||||
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
|
||||
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 控制器。
|
||||
@@ -33,16 +33,16 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
|
||||
<!--
|
||||
## Additional controllers
|
||||
|
||||
* [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
|
||||
* [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).
|
||||
* [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).
|
||||
* [Contour](https://github.com/heptio/contour) is an [Envoy](https://www.envoyproxy.io) based ingress controller
|
||||
provided and supported by Heptio.
|
||||
* 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).
|
||||
* [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 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/).
|
||||
@@ -58,13 +58,13 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
|
||||
-->
|
||||
## 其他控制器
|
||||
|
||||
* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress
|
||||
* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress
|
||||
控制器，有着来自 [Datawire](https://www.datawire.io/) [社区](https://www.getambassador.io/docs)或[商业](https://www.getambassador.io/pro/)的支持。
|
||||
* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护.
|
||||
* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护.
|
||||
* [Contour](https://github.com/heptio/contour) 是一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它由 Heptio 提供和支持。
|
||||
* 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) 的企业级支持。
|
||||
* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。
|
||||
* [HAProxy Technologies](https://www.haproxy.com/) 为 [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/) 的 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/)支持和维护。
|
||||
@@ -76,9 +76,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
|
||||
<!--
|
||||
## Using multiple Ingress controllers
|
||||
|
||||
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
|
||||
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)
|
||||
[`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.
|
||||
@@ -90,7 +90,7 @@ 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.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 控制器。
|
||||
|
||||
@@ -62,7 +62,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
|
||||
|
||||
## Ingress 是什么？
|
||||
|
||||
Ingress公开了从群集外部到群集内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。
|
||||
Ingress公开了从群集外部到群集内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。
|
||||
流量路由由Ingress资源上定义的规则控制。
|
||||
|
||||
```none
|
||||
@@ -208,7 +208,7 @@ routed to your default backend.
|
||||
|
||||
### 默认后端
|
||||
|
||||
没有设定规则的 Ingress 将所有流量发送到单个默认后端。
|
||||
没有设定规则的 Ingress 将所有流量发送到单个默认后端。
|
||||
默认后端通常是 [Ingress控制器](/docs/concepts/services-networking/ingress-controllers) 的配置选项，并且未在Ingress资源中指定。
|
||||
|
||||
如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
|
||||
@@ -276,7 +276,7 @@ down to a minimum. For example, a setup like:
|
||||
|
||||
### 简单分列
|
||||
|
||||
分列配置根据请求的 HTTP URI 将流量从单个IP地址路由到多个服务。
|
||||
分列配置根据请求的 HTTP URI 将流量从单个IP地址路由到多个服务。
|
||||
通过Ingress，您可以将负载均衡器的数量保持在最低水平。 例如，如下设置：
|
||||
|
||||
```none
|
||||
@@ -494,7 +494,7 @@ sure the TLS secret you created came from a certificate that contains a CN
|
||||
for `sslexample.foo.com`.
|
||||
-->
|
||||
|
||||
在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。
|
||||
在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。
|
||||
您需要确保创建包含 `sslexample.foo.com` 的 TLS 秘钥的 CN 的证书。
|
||||
|
||||
```yaml
|
||||
@@ -528,7 +528,7 @@ platform specific Ingress controller to understand how TLS works in your environ
|
||||
|
||||
各种 Ingress 控制器所支持的 TLS 功能之间存在间隙。请参阅有关文件
|
||||
[nginx](https://git.k8s.io/ingress-nginx/README.md#https)，
|
||||
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)，
|
||||
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)，
|
||||
或任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -681,7 +681,7 @@ for details on deploying Ingress in a federated cluster.
|
||||
## 跨可用区失败
|
||||
|
||||
用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。
|
||||
请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
|
||||
请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
|
||||
您还可以参考[联合文档](/docs/concepts/cluster-administration/federation/)，以获取有关在联合群集中部署Ingress的详细信息。
|
||||
|
||||
|
||||
@@ -696,7 +696,7 @@ evolution of various Ingress controllers.
|
||||
|
||||
## 未来的工作
|
||||
|
||||
跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。
|
||||
跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。
|
||||
您也可以跟踪 [Ingress信息库](https://github.com/kubernetes/ingress/tree/master) 了解 Ingress 控制器进化的更多信息。
|
||||
|
||||
<!--
|
||||
|
||||
@@ -56,7 +56,7 @@ An example `NetworkPolicy` might look like this:
|
||||
|
||||
## `NetworkPolicy` 资源
|
||||
|
||||
查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解资源定义。
|
||||
查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解资源定义。
|
||||
|
||||
下面是一个 `NetworkPolicy` 的示例:
|
||||
|
||||
@@ -152,7 +152,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-
|
||||
|
||||
* 标签为 "role=frontend" 的 "default" 名称空间中的任何Pod
|
||||
* 名称空间中带有标签 "project=myproject" 的任何pod
|
||||
* 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）
|
||||
* 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. 允许从带有 "project=myproject" 标签的命名空间下的任何 pod 到 "default" 命名空间下的 pod 的6379 TCP端口的连接。
|
||||
|
||||
查看 [网络策略入门指南](/docs/getting-started-guides/network-policy/walkthrough) 了解更多示例。
|
||||
@@ -177,7 +177,7 @@ __podSelector__: 这将在与 `NetworkPolicy` 相同的名称空间中选择特
|
||||
|
||||
__namespaceSelector__: 这将选择特定的名称空间，应将所有 Pod 用作其输入源或输出目的地。
|
||||
|
||||
__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的YAML语法；这项政策：
|
||||
__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的YAML语法；这项政策：
|
||||
|
||||
```yaml
|
||||
...
|
||||
|
||||
@@ -184,7 +184,7 @@ port definitions on a Service object.
|
||||
Each port definition can have the same `protocol`, or a different one.
|
||||
-->
|
||||
|
||||
Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。
|
||||
Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。
|
||||
即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。
|
||||
这为部署和发展服务提供了很大的灵活性。
|
||||
例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。
|
||||
@@ -306,7 +306,7 @@ endpoints.
|
||||
Endpoint Slices provide additional attributes and functionality which is
|
||||
described in detail in [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/).
|
||||
-->
|
||||
Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
|
||||
Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
|
||||
尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
|
||||
默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。
|
||||
|
||||
@@ -345,7 +345,7 @@ There are a few reasons for using proxying for Services:
|
||||
|
||||
### 为什么不使用 DNS 轮询？
|
||||
|
||||
时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？
|
||||
时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？
|
||||
例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？
|
||||
|
||||
使用服务代理有以下几个原因：
|
||||
@@ -504,7 +504,7 @@ falls back to running in iptables proxy mode.
|
||||
|
||||
要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS Linux 在节点上可用。
|
||||
|
||||
当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。
|
||||
当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。
|
||||
如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。
|
||||
|
||||
{{< /note >}}
|
||||
@@ -699,7 +699,7 @@ You can find more information about `ExternalName` resolution in
|
||||
|
||||
您可以（几乎总是应该）使用[附加组件](/docs/concepts/cluster-administration/addons/)为Kubernetes集群设置DNS服务。
|
||||
|
||||
支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
|
||||
支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
|
||||
如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。
|
||||
|
||||
例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
|
||||
@@ -708,7 +708,7 @@ You can find more information about `ExternalName` resolution in
|
||||
|
||||
其他命名空间中的Pod必须将名称限定为 `my-service.my-ns` 。 这些名称将解析为为服务分配的群集IP。
|
||||
|
||||
Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
|
||||
Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
|
||||
如果 `"my-service.my-ns"` 服务具有名为 `"http"` 的端口，且协议设置为`TCP`，
|
||||
则可以对 `_http._tcp.my-service.my-ns` 执行DNS SRV查询查询以发现该端口号, `"http"`以及IP地址。
|
||||
|
||||
@@ -888,7 +888,7 @@ For example:
|
||||
|
||||
使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。
|
||||
负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。
|
||||
实例:
|
||||
实例:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -945,10 +945,10 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`.
|
||||
|
||||
Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
|
||||
-->
|
||||
在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。
|
||||
在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。
|
||||
此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。
|
||||
|
||||
将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。
|
||||
将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。
|
||||
有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息，
|
||||
请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。
|
||||
{{< /note >}}
|
||||
@@ -1245,7 +1245,7 @@ also be used to set maximum time, in seconds, to keep the existing connections o
|
||||
|
||||
#### AWS上的连接排空
|
||||
|
||||
可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。
|
||||
可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。
|
||||
注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。
|
||||
|
||||
```yaml
|
||||
@@ -1388,7 +1388,7 @@ public IP addresses, be aware that non-NLB traffic can also reach all instances
|
||||
in those modified security groups.
|
||||
-->
|
||||
|
||||
如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。
|
||||
如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。
|
||||
如果节点具有公共 IP 地址，请注意，非 NLB 流量也可以到达那些修改后的安全组中的所有实例。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -1404,7 +1404,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`:
|
||||
|
||||
### 类型ExternalName {#externalname}
|
||||
|
||||
类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。
|
||||
类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。
|
||||
您可以使用 `spec.externalName` 参数指定这些服务。
|
||||
|
||||
例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`：
|
||||
@@ -1427,7 +1427,7 @@ is intended to specify a canonical DNS name. To hardcode an IP address, consider
|
||||
[headless Services](#headless-services).
|
||||
-->
|
||||
|
||||
ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。
|
||||
ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。
|
||||
要对 IP 地址进行硬编码，请考虑使用 [headless Services](#headless-services)。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -1442,7 +1442,7 @@ Service's `type`.
|
||||
-->
|
||||
|
||||
当查找主机 `my-service.prod.svc.cluster.local` 时，群集DNS服务返回 `CNAME` 记录，其值为 `my.database.example.com`。
|
||||
访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
|
||||
访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
|
||||
如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的`类型`。
|
||||
|
||||
{{< note >}}
|
||||
@@ -1772,10 +1772,10 @@ Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPoli
|
||||
When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
|
||||
-->
|
||||
|
||||
Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。
|
||||
Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。
|
||||
要启用此功能，集群管理员需要在apiserver上启用 `SCTPSupport` 功能门，例如 `--feature-gates = SCTPSupport = true，…`。
|
||||
|
||||
启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。
|
||||
启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。
|
||||
Kubernetes相应地为 SCTP 关联设置网络，就像为 TCP 连接一样。
|
||||
|
||||
<!--
|
||||
|
||||
Reference in New Issue
Block a user