whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Sync changes from English site (5)

Browse Source
This commit is contained in:
Qiming Teng
2020-11-13 13:46:57 +08:00
parent fd65678baa
commit e97677e6de
7 changed files with 423 additions and 325 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+54 -44
View File
@@ -2,52 +2,62 @@
title: 使用 HostAliases 向 Pod /etc/hosts 文件添加条目
content_type: concept
weight: 60
min-kubernetes-server-version: 1.7
---
{{< toc >}}
<!--
reviewers:
- rickypai
- thockin
title: Adding entries to Pod /etc/hosts with HostAliases
content_type: concept
weight: 60
min-kubernetes-server-version: 1.7
-->
<!-- overview -->
<!--
Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec.
Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart.
-->
当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，
可以在 Pod 级别覆盖对主机名的解析。你可以通过 PodSpec 的 HostAliases
字段来添加这些自定义条目。
当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。
建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。
建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且
可以在 Pod 创建/重启过程中被重写。
<!-- body -->
<!--
## Default Hosts File Content
Let's start an Nginx Pod which is assigned a Pod IP:
Start an Nginx Pod which is assigned a Pod IP:
-->
## 默认 hosts 文件内容
让我们从一个 Nginx Pod 开始，给该 Pod 分配一个 IP：
让我们从一个 Nginx Pod 开始，该 Pod 被分配一个 IP：
```shell
kubectl run nginx --image nginx --generator=run-pod/v1
```
```shell
```
pod/nginx created
```
<!--
Examine a Pod IP:
-->
检查Pod IP：
检查 Pod IP：
```shell
kubectl get pods --output=wide
```
```shell
```
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
@@ -55,14 +65,13 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0
<!--
The hosts file content would look like this:
-->
主机文件的内容如下所示：
```shell
kubectl exec nginx -- cat /etc/hosts
```
```none
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -77,63 +86,63 @@ fe00::2 ip6-allrouters
By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
`localhost` and its own hostname.
-->
默认，hosts 文件只包含 ipv4 和 ipv6 的样板内容，像 `localhost` 和主机名称。
默认情况下，hosts 文件只包含 IPv4 和 IPv6 的样板内容，像 `localhost` 和主机名称。
<!--
## Adding Additional Entries with HostAliases
In addition to the default boilerplate, we can add additional entries to the
`hosts` file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
`bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under
`hosts` file.
For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
`bar.remote` to `10.1.2.3`, we can configure HostAliases for a Pod under
`.spec.hostAliases`:
-->
## 通过 HostAliases 增加额外条目
## 通过 HostAliases 增加额外的条目
除了默认的样板内容，我们可以向 hosts 文件添加额外的条目，将 `foo.local`、 `bar.local` 解析为`127.0.0.1`，
将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在 `.spec.hostAliases` 下为 Pod 添加 HostAliases。
除了默认的样板内容，我们可以向 hosts 文件添加额外的条目。
例如，要将 `foo.local`、`bar.local` 解析为 `127.0.0.1`，
将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在
`.spec.hostAliases` 下为 Pod 配置 HostAliases。
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
<!--
This Pod can be started with the following commands:
You can start a Pod with that configuration by running:
-->
可以使用以下命令启动此Pod：
你可以使用以下命令用此配置启动 Pod：
```shell
kubectl apply -f hostaliases-pod.yaml
```
```shell
```
pod/hostaliases-pod created
```
<!--
Examine a Pod IP and status:
Examine a Pod's details to see its IPv4 address and its status:
-->
检查Pod IP 和状态：
检查 Pod 详情，查看其 IPv4 地址和状态：
```shell
kubectl get pod --output=wide
```
```shell
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
```
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
```
<!--
The `hosts` file content would look like this:
The `hosts` file content looks like this:
-->
hosts 文件的内容看起来类似如下这样：
```shell
kubectl logs hostaliases-pod
```
```none
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -151,30 +160,31 @@ fe00::2 ip6-allrouters
<!--
With the additional entries specified at the bottom.
-->
在最下面额外添加了一些条目。
<!--
With the additional entries specified at the bottom.
## Why Does Kubelet Manage the Hosts File?
Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
`hosts` file for each container of the Pod to prevent Docker from
[modifying](https://github.com/moby/moby/issues/17190) the file after the
containers have already been started.
Because of the managed-nature of the file, any user-written content will be
overwritten whenever the `hosts` file is remounted by Kubelet in the event of
a container restart or a Pod reschedule. Thus, it is not suggested to modify
the contents of the file.
-->
## 为什么 kubelet 管理 hosts 文件？
## 为什么 Kubelet 管理 hosts文件？
kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod
中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去
[修改](https://github.com/moby/moby/issues/17190) 该文件。
kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod 中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去 [修改](https://github.com/moby/moby/issues/17190) 该文件。
因为该文件是托管性质的文件，无论容器重启或 Pod 重新调度，用户修改该 hosts 文件的任何内容，都会在 Kubelet 重新安装后被覆盖。因此，不建议修改该文件的内容。
{{< caution >}}
<!--
Avoid making manual changes to the hosts file inside a container.
If you make manual changes to the hosts file,
those changes are lost when the container exits.
-->
请避免手工更改容器内的 hosts 文件内容。
如果你对 hosts 文件做了手工修改，这些修改都会在容器退出时丢失。
{{< /caution >}}
content/zh/docs/concepts/services-networking/connect-applications-service.md
+1 -2
View File
@@ -205,9 +205,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
Kubernetes supports 2 primary modes of finding a Service - environment variables
and DNS. The former works out of the box while the latter requires the
[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
-->
## 访问 Service
Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件]
content/zh/docs/concepts/services-networking/dns-pod-service.md
+80 -15
View File
@@ -42,8 +42,7 @@ considered implementation details and are subject to change without warning.
For more up-to-date specification, see
[Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
-->
## 怎样获取 DNS 名字?
## 哪些对象会有 DNS 名字? {#what-things-get-dns-names}
在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。
默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。
@@ -74,7 +73,6 @@ Services, this resolves to the set of IPs of the pods selected by the Service.
Clients are expected to consume the set or else use standard round-robin
selection from the set.
-->
### 服务 {#services}
#### A/AAAA 记录
@@ -117,17 +115,35 @@ Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或
<!--
### A/AAAA records
Any pods created by a Deployment or DaemonSet have the following
DNS resolution available:
In general a pod has the following DNS resolution:
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
`pod-ip-address.my-namespace.pod.cluster-domain.example`.
For example, if a pod in the `default` namespace has the IP address 172.17.0.3,
and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
`172-17-0-3.default.pod.cluster.local`.
Any pods created by a Deployment or DaemonSet exposed by a Service have the
following DNS resolution available:
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
-->
### A/AAAA 记录
经由 Deployment 或者 DaemonSet 所创建的所有 Pods 都会有如下 DNS
解析项与之对应：
一般而言，Pod 会对应如下 DNS 名字解析：
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
`pod-ip-address.my-namespace.pod.cluster-domain.example`
例如，对于一个位于 `default` 名字空间，IP 地址为 172.17.0.3 的 Pod，
如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称：
`172-17-0-3.default.pod.cluster.local`.
Deployment 或通过 Service 暴露出来的 DaemonSet 所创建的 Pod 会有如下 DNS
解析名称可用：
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
<!--
### Pod's hostname and subdomain fields
@@ -146,7 +162,6 @@ domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`".
Example:
-->
### Pod 的 hostname 和 subdomain 字段
当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。
@@ -254,6 +269,51 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
才会有与之对应的记录。
{{< /note >}}
<!--
### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
-->
### Pod 的 setHostnameAsFQDN 字段 {#pod-sethostnameasfqdn-field}
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
<!--
**Prerequisites**: The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
must be enabled for the
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and the `hostname -fqdn` command returns the FQDN.
-->
**前置条件**：`SetHostnameAsFQDN`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
上启用。
当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod
的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在名字空间。
在这种情况下，`hostname` 和 `hostname --fqdn` 都会返回 Pod 的全限定域名。
{{< note >}}
<!--
In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
-->
在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定
最多 64 个字符。
如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。
Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`），
并产生错误事件，例如
"Failed to construct FQDN from pod hostname and cluster domain, FQDN
`long-FQDN` is too long (64 characters is the max, 70 characters requested)."
（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64
字符，请求字符数为 70）。
对于这种场景而言，改善用户体验的一种方式是创建一个
[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。
{{< /note >}}
<!--
### Pod's DNS Policy
@@ -278,10 +338,15 @@ following pod-specific DNS policies. These policies are specified in the
`dnsConfig` field in the Pod Spec.
See [Pod's DNS config](#pod-s-dns-config) subsection below.
-->
### Pod 的 DNS 策略 {#pod-s-dns-policy}
- "`Default`": Pod 从运行所在的节点继承名称解析配置。
参考[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。
- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io”）
DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。
这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置：
- "`Default`": Pod 从运行所在的节点继承名称解析配置。参考
[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
获取更多信息。
- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"）
都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
了解在这些场景中如何处理 DNS 查询的信息。
@@ -293,10 +358,10 @@ following pod-specific DNS policies. These policies are specified in the
<!--
"Default" is not the default DNS policy. If `dnsPolicy` is not
explicitly specified, then “ClusterFirst” is used.
explicitly specified, then "ClusterFirst" is used.
-->
{{< note >}}
"`Default`" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "`ClusterFirst`"。
"Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "ClusterFirst"。
{{< /note >}}
<!--
content/zh/docs/concepts/services-networking/dual-stack.md
+6 -6
View File
@@ -176,13 +176,13 @@ 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.
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-sigsr/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 地址块，前提是下层的
{{< 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](https://github.com/kubernetes-sigs/ip-masq-agent) 可以感知双栈，
所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。
<!--
@@ -191,9 +191,9 @@ 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" %}}
content/zh/docs/concepts/services-networking/ingress-controllers.md
+7 -6
View File
@@ -25,7 +25,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。
基于此页面，您可选择最适合您的集群的 ingress 控制器实现。
基于此页面，你可选择最适合你的集群的 ingress 控制器实现。
Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md)
和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
@@ -42,7 +42,7 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
* [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](https://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.
@@ -95,7 +95,8 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
* [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
* [Traefik](https://github.com/traefik/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).
-->
@@ -107,9 +108,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
[用于 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 控制器
* [Traefik](https://github.com/traefik/traefik) 是一个全功能的 Ingress 控制器。
（[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），
并且它也有来自 [Containous](https://containo.us/services) 的商业支持。
并且它也有来自 [Traefik Labs](https://traefik.io) 的商业支持。
<!--
## Using multiple Ingress controllers
@@ -141,7 +142,7 @@ controllers operate slightly differently.
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
-->
{{< note >}}
确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
确保你查看了 ingress 控制器的文档，以了解选择它的注意事项。
{{< /note >}}
## {{% heading "whatsnext" %}}
content/zh/docs/concepts/services-networking/ingress.md
+15 -2
View File
@@ -708,6 +708,18 @@ Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `https-example
你需要确保创建的 TLS Secret 创建自包含 `sslexample.foo.com` 的公用名称（CN）的证书。
这里的公共名称也被称为全限定域名（FQDN）。
{{< note >}}
<!--
Keep in mind that TLS will not work on the default rule because the
certificates would have to be issued for all the possible sub-domains. Therefore,
`hosts` in the `tls` section need to explicitly match the `host` in the `rules`
section.
-->
注意，默认规则上无法使用 TLS，因为需要为所有可能的子域名发放证书。
因此，`tls` 节区的 `hosts` 的取值需要域 `rules` 节区的 `host`
完全匹配。
{{< /note >}}
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
<!--
@@ -754,9 +766,10 @@ specific documentation to see how they handle health checks (
中存在并行的概念，比如
[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
允许你实现相同的目的。
请检查特定控制器的说明文档，以了解它们是怎样处理健康检查的 (
请检查特定控制器的说明文档（
[nginx](https://git.k8s.io/ingress-nginx/README.md)，
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）
以了解它们是怎样处理健康检查的。
<!--
## Updating an Ingress
content/zh/docs/concepts/services-networking/service.md
+260 -250
View File
File diff suppressed because it is too large Load Diff