From e97677e6de428560f32f8dd073338978861f1201 Mon Sep 17 00:00:00 2001
From: Qiming Teng <tengqim@cn.ibm.com>
Date: Fri, 13 Nov 2020 13:46:57 +0800
Subject: [PATCH] [zh] Sync changes from English site (5)

---
 ...ries-to-pod-etc-hosts-with-host-aliases.md |  98 ++--
 .../connect-applications-service.md           |   3 +-
 .../services-networking/dns-pod-service.md    |  95 +++-
 .../services-networking/dual-stack.md         |  12 +-
 .../ingress-controllers.md                    |  13 +-
 .../concepts/services-networking/ingress.md   |  17 +-
 .../concepts/services-networking/service.md   | 510 +++++++++---------
 7 files changed, 423 insertions(+), 325 deletions(-)

diff --git a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
index 6db722eed5..4229689422 100644
--- a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+++ b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
@@ -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 >}}
 
diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md
index 25bebe4d01..06d1744eb2 100644
--- a/content/zh/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md
@@ -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集群插件]
diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md
index 48453424da..fc23f799ae 100644
--- a/content/zh/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md
@@ -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 >}}
 
 <!--
diff --git a/content/zh/docs/concepts/services-networking/dual-stack.md b/content/zh/docs/concepts/services-networking/dual-stack.md
index 9d490cb9cf..c0c4402813 100644
--- a/content/zh/docs/concepts/services-networking/dual-stack.md
+++ b/content/zh/docs/concepts/services-networking/dual-stack.md
@@ -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" %}}
 
diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md
index 4071ea6189..6b31e610d6 100644
--- a/content/zh/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md
@@ -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" %}}
diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md
index 6a5cb35739..e3dd00dede 100644
--- a/content/zh/docs/concepts/services-networking/ingress.md
+++ b/content/zh/docs/concepts/services-networking/ingress.md
@@ -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
diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md
index af746c8b98..3155ca8751 100644
--- a/content/zh/docs/concepts/services-networking/service.md
+++ b/content/zh/docs/concepts/services-networking/service.md
@@ -3,7 +3,7 @@ title: 服务
 feature:
   title: 服务发现与负载均衡
   description: >
-    无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。
+    无需修改你的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。
 
 content_type: concept
 weight: 10
@@ -30,7 +30,7 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s
 Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods,
 and can load-balance across them.
 -->
-使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。
+使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。
 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，
 并且可以在它们之间进行负载均衡。
 
@@ -60,12 +60,12 @@ Enter _Services_.
 
 Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期的。
 它们可以被创建，而且销毁之后不会再启动。
-如果您使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}}
-来运行您的应用程序，则它可以动态创建和销毁 Pod。
+如果你使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}}
+来运行你的应用程序，则它可以动态创建和销毁 Pod。
 
 每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。
 
-这导致了一个问题： 如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能，
+这导致了一个问题： 如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能，
 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？
 
 进入 _Services_。
@@ -79,13 +79,13 @@ Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期
 In Kubernetes, a Service is an abstraction which defines a logical set of Pods
 and a policy by which to access them (sometimes this pattern is called
 a micro-service). The set of Pods targeted by a Service is usually determined
-by a {{< glossary_tooltip text="selector" term_id="selector" >}}
-(see [below](#services-without-selectors) for why you might want a Service
-_without_ a selector).
+by a {{< glossary_tooltip text="selector" term_id="selector" >}}.
+To learn about other ways to define Service endpoints,
+see [Services _without_ selectors](#services-without-selectors).
 -->
 Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。
 这一组 Pod 能够被 Service 访问到，通常是通过 {{< glossary_tooltip text="选择算符" term_id="selector" >}}
-（查看[下面](#services-without-selectors)了解，为什么你可能需要没有 selector 的 Service）实现的。
+要了解如何定义服务端点，请参阅[不带选择算符的服务](#services-without-selectors)。
 
 <!--
 For example, consider a stateless image-processing backend which is running with
@@ -114,7 +114,7 @@ balancer in between your application and the backend Pods.
 -->
 ### 云原生服务发现
 
-如果您想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询
+如果你想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询
 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
 的 Endpoints 资源，只要服务中的 Pod 集合发生更改，Endpoints 就会被更新。
 
@@ -126,6 +126,8 @@ balancer in between your application and the backend Pods.
 A Service in Kubernetes is a REST object, similar to a Pod.  Like all of the
 REST objects, you can `POST` a Service definition to the API server to create
 a new instance.
+The name of a Service object must be a valid
+[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
 
 For example, suppose you have a set of Pods that each listen on TCP port 9376
 and carry a label `app=MyApp`:
@@ -135,6 +137,8 @@ and carry a label `app=MyApp`:
 
 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。
 像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。
+Service 对象的名称必须是合法的
+[DNS 标签名称](/zh/docs/concepts/overview/working-with-objects/names#dns-label-names)。
 
 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签。
 
@@ -200,9 +204,9 @@ Each port definition can have the same `protocol`, or a different one.
 Pod 中的端口定义是有名字的，你可以在服务的 `targetPort` 属性中引用这些名称。
 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。
 这为部署和发展服务提供了很大的灵活性。
-例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。
+例如，你可以更改 Pods 在新版本的后端软件中公开的端口号，而不会破坏客户端。
 
-服务的默认协议是TCP。 您还可以使用任何其他[受支持的协议](#protocol-support)。
+服务的默认协议是TCP。 你还可以使用任何其他[受支持的协议](#protocol-support)。
 
 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
 每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。
@@ -231,7 +235,7 @@ For example:
 
   * 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
   * 希望服务指向另一个 {{< glossary_tooltip term_id="namespace" >}} 中或其它集群中的服务。
-  * 您正在将工作负载迁移到 Kubernetes。 在评估该方法时，您仅在 Kubernetes 中运行一部分后端。
+  * 你正在将工作负载迁移到 Kubernetes。 在评估该方法时，你仅在 Kubernetes 中运行一部分后端。
 
 在任何这些场景中，都能够定义没有选择算符的 Service。
 实例:
@@ -254,7 +258,7 @@ created automatically. You can manually map the Service to the network address a
 where it's running, by adding an Endpoint object manually:
 -->
 由于此服务没有选择算符，因此 *不会* 自动创建相应的 Endpoint 对象。
-您可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口：
+你可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口：
 
 ```yaml
 apiVersion: v1
@@ -267,6 +271,12 @@ subsets:
     ports:
       - port: 9376
 ```
+<!--
+The name of the Endpoints object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+Endpoints 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
 <!--
 The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or
@@ -300,11 +310,11 @@ ExternalName Service 是 Service 的特例，它没有选择算符，但是使
 有关更多信息，请参阅本文档后面的[`ExternalName`](#externalname)。
 
 <!--
-### Endpoint Slices
+### EndpointSlices
 -->
-### Endpoint 切片
+### EndpointSlice
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 <!--
 Endpoint Slices are an API resource that can provide a more scalable alternative
@@ -315,7 +325,7 @@ point additional Endpoint Slices will be created to store any additional
 endpoints.
 
 Endpoint Slices provide additional attributes and functionality which is
-described in detail in [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/).
+described in detail in [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/).
 -->
 Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
@@ -323,26 +333,21 @@ Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的
 届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。
 
 Endpoint 切片提供了附加的属性和功能，这些属性和功能在
-[Endpoint 切片](/zh/docs/concepts/services-networking/endpoint-slices/)中有详细描述。
+[EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
+中有详细描述。
 
 <!-- 
 ### Application protocol
 
-The AppProtocol field provides a way to specify an application protocol to be
-used for each Service port.
-
-As an alpha feature, this field is not enabled by default. To use this field,
-enable the `ServiceAppProtocol` [feature
-gate](/docs/reference/command-line-tools-reference/feature-gates/).
+The `AppProtocol` field provides a way to specify an application protocol for each Service port.
+The value of this field is mirrored by corresponding Endpoints and EndpointSlice resources.
 -->
-### 应用程序协议
+### 应用程序协议   {#application-protocol}
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-`appProtocol` 字段提供了一种为每个 Service 端口指定应用程序协议的方式。
-
-作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+`appProtocol` 字段提供了一种为每个 Service 端口指定应用协议的方式。
+此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 资源。
 
 <!--
 ## Virtual IPs and service proxies
@@ -351,8 +356,7 @@ Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
 responsible for implementing a form of virtual IP for `Services` of type other
 than [`ExternalName`](#externalname).
 -->
-
-## VIP 和 Service 代理 {#virtual-ips-and-service-proxies}
+## 虚拟 IP 和 Service 代理 {#virtual-ips-and-service-proxies}
 
 在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。
 `kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是
@@ -376,33 +380,17 @@ There are a few reasons for using proxying for Services:
    on the DNS records could impose a high load on DNS that then becomes
    difficult to manage.
 -->
-
 ### 为什么不使用 DNS 轮询？
 
-时不时会有人问到，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？
-例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？
+时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？
+例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？
 
 使用服务代理有以下几个原因：
 
-  * DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
-  * 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
-  * 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 DNS 带来高负载，从而使管理变得困难。
-
-<!--
-### Version compatibility
-
-Since Kubernetes v1.0 you have been able to use the
-[userspace proxy mode](#proxy-mode-userspace).
-Kubernetes v1.1 added iptables mode proxying, and in Kubernetes v1.2 the
-iptables mode for kube-proxy became the default.
-Kubernetes v1.8 added ipvs proxy mode.
--->
-
-### 版本兼容性
-
-从 Kubernetes v1.0 开始，您已经可以使用 [用户空间代理模式](#proxy-mode-userspace)。
-Kubernetes v1.1 添加了 iptables 模式代理，在 Kubernetes v1.2 中，kube-proxy 的 iptables 模式成为默认设置。
-Kubernetes v1.8 添加了 ipvs 代理模式。
+* DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
+* 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
+* 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给
+  DNS 带来高负载，从而使管理变得困难。
 
 <!--
 ### User space proxy mode {#proxy-mode-userspace}
@@ -434,7 +422,7 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg
 
 默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。
 
-![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg)
+![userspace 代理模式下 Service 概览图](/images/docs/services-userspace-overview.svg)
 
 <!--
 ### `iptables` proxy mode {#proxy-mode-iptables}
@@ -481,9 +469,9 @@ having traffic sent via kube-proxy to a Pod that's known to have failed.
 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，
 并会自动使用其他后端 Pod 重试。
 
-您可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
+你可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。
-这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。
+这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
 
 ![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg)
 
@@ -513,7 +501,6 @@ higher throughput of network traffic.
 IPVS provides more options for balancing traffic to backend Pods;
 these are:
 -->
-
 在 `ipvs` 模式下，kube-proxy监视Kubernetes服务和端点，调用 `netlink` 接口相应地创建 IPVS 规则，
 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保IPVS 
 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。
@@ -572,7 +559,7 @@ You can also set the maximum session sticky time by setting
 则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP" 
 （默认值是 "None"），来基于客户端的 IP 地址选择会话关联。
 
-您还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 
+你还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 
 来设置最大会话停留时间。
 （默认值为 10800 秒，即 3 小时）。
 
@@ -585,10 +572,10 @@ When using multiple ports for a Service, you must give all of your ports names
 so that these are unambiguous.
 For example:
 -->
-## 多端口 Service
+## 多端口 Service   {#multi-port-services}
 
-对于某些服务，您需要公开多个端口。
-Kubernetes 允许您在 Service 对象上配置多个端口定义。
+对于某些服务，你需要公开多个端口。
+Kubernetes 允许你在 Service 对象上配置多个端口定义。
 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义。
 
 例如：
@@ -639,7 +626,6 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within
 If you try to create a Service with an invalid clusterIP address value, the API
 server will return a 422 HTTP status code to indicate that there's a problem.
 -->
-
 ## 选择自己的 IP 地址
 
 在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。
@@ -673,7 +659,7 @@ For example, the Service `"redis-master"` which exposes TCP port 6379 and has be
 allocated cluster IP address 10.0.0.11, produces the following environment
 variables:
 -->
-### 环境变量
+### 环境变量   {#environment-variables}
 
 当 Pod 运行在 `Node` 上，kubelet 会为每个活跃的 Service 添加一组环境变量。
 它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量
@@ -704,11 +690,11 @@ If you only use DNS to discover the cluster IP for a Service, you don't need to
 worry about this ordering issue.
 -->
 {{< note >}}
-当您具有需要访问服务的Pod时，并且您正在使用环境变量方法将端口和群集 IP 发布到客户端
+当你具有需要访问服务的 Pod 时，并且你正在使用环境变量方法将端口和集群 IP 发布到客户端
 Pod 时，必须在客户端 Pod 出现 *之前* 创建服务。
 否则，这些客户端 Pod 将不会设定其环境变量。
 
-如果仅使用 DNS 查找服务的群集 IP，则无需担心此设定问题。
+如果仅使用 DNS 查找服务的集群 IP，则无需担心此设定问题。
 {{< /note >}}
 
 ### DNS
@@ -721,7 +707,14 @@ A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new
 Services and creates a set of DNS records for each one.  If DNS has been enabled
 throughout your cluster then all Pods should automatically be able to resolve
 Services by their DNS name.
+-->
+你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
+为 Kubernetes 集群设置 DNS 服务。
 
+支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
+如果在整个集群中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。
+
+<!--
 For example, if you have a Service called `"my-service"` in a Kubernetes
 Namespace `"my-ns"`, the control plane and the DNS Service acting together
 create a DNS record for `"my-service.my-ns"`. Pods in the `"my-ns"` Namespace
@@ -730,7 +723,16 @@ should be able to find it by simply doing a name lookup for `my-service`
 
 Pods in other Namespaces must qualify the name as `my-service.my-ns`. These names
 will resolve to the cluster IP assigned for the Service.
+-->
+例如，如果你在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
+则控制平面和 DNS 服务共同为 `"my-service.my-ns"` 创建 DNS 记录。
+`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它
+（`"my-service.my-ns"` 也可以工作）。
 
+其他命名空间中的 Pod 必须将名称限定为 `my-service.my-ns`。
+这些名称将解析为为服务分配的集群 IP。
+
+<!--
 Kubernetes also supports DNS SRV (Service) records for named ports.  If the
 `"my-service.my-ns"` Service has a port named `"http"` with protocol set to
 `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover
@@ -740,19 +742,6 @@ The Kubernetes DNS server is the only way to access `ExternalName` Services.
 You can find more information about `ExternalName` resolution in
 [DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/).
 -->
-您可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
-为 Kubernetes 集群设置 DNS 服务。
-
-支持群集的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
-如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。
-
-例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
-则控制平面和DNS服务共同为 `"my-service.my-ns"` 创建 DNS 记录。
-`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它
-（`"my-service.my-ns"` 也可以工作）。
-
-其他命名空间中的Pod必须将名称限定为 `my-service.my-ns`。这些名称将解析为为服务分配的群集 IP。
-
 Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
 如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为 TCP，
 则可以对 `_http._tcp.my-service.my-ns` 执行 DNS SRV 查询查询以发现该端口号, 
@@ -762,9 +751,9 @@ Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的
 更多关于 `ExternalName` 信息可以查看
 [DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。
 
+<!--
 ## Headless Services  {#headless-services}
 
-<!--
 Sometimes you don't need load-balancing and a single Service IP.  In
 this case, you can create what are termed “headless” Services, by explicitly
 specifying `"None"` for the cluster IP (`.spec.clusterIP`).
@@ -777,11 +766,14 @@ these Services, and there is no load balancing or proxying done by the platform
 for them. How DNS is automatically configured depends on whether the Service has
 selectors defined:
 -->
+## 无头服务（Headless Services）  {#headless-services}
+
 有时不需要或不想要负载均衡，以及单独的 Service IP。
 遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"`
 来创建 `Headless` Service。
 
-您可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。
+你可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes
+的实现捆绑在一起。
 
 对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，
 而且平台也不会为它们进行负载均衡和路由。
@@ -794,8 +786,7 @@ For headless Services that define selectors, the endpoints controller creates
 `Endpoints` records in the API, and modifies the DNS configuration to return
 records (addresses) that point directly to the `Pods` backing the Service.
 -->
-
-### 带选择算符的服务
+### 带选择算符的服务   {#with-selectors}
 
 对定义了选择算符的无头服务，Endpoint 控制器在 API 中创建了 Endpoints 记录，
 并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 Service 的后端 Pod 上。
@@ -807,18 +798,17 @@ For headless Services that do not define selectors, the endpoints controller doe
 not create `Endpoints` records. However, the DNS system looks for and configures
 either:
 
-  * CNAME records for [`ExternalName`](#externalname)-type Services.
-  * A records for any `Endpoints` that share a name with the Service, for all
-    other types.
+* CNAME records for [`ExternalName`](#externalname)-type Services.
+* A records for any `Endpoints` that share a name with the Service, for all
+  other types.
 -->
-
-### 无选择算符的服务
+### 无选择算符的服务  {#without-selectors}
 
 对没有定义选择算符的无头服务，Endpoint 控制器不会创建 `Endpoints` 记录。
 然而 DNS 系统会查找和配置，无论是：
 
-  * `ExternalName` 类型 Service 的 CNAME 记录
-  * 记录：与 Service 共享一个名称的任何 `Endpoints`，以及所有其它类型
+* 对于 [`ExternalName`](#external-name) 类型的服务，查找其 CNAME 记录
+* 对所有其他类型的服务，查找与 Service 名称相同的任何 `Endpoints` 的记录
 
 <!--
 ## Publishing Services (ServiceTypes) {#publishing-services-service-types}
@@ -830,52 +820,55 @@ Kubernetes `ServiceTypes` allow you to specify what kind of Service you want.
 The default is `ClusterIP`.
 
 `Type` values and their behaviors are:
-
-   * `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
-     makes the Service only reachable from within the cluster. This is the
-     default `ServiceType`.
-   * [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
-     (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
-     routes, is automatically created.  You'll be able to contact the `NodePort` Service,
-     from outside the cluster,
-     by requesting `<NodeIP>:<NodePort>`.
-   * [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
-     provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
-     load balancer routes, are automatically created.
-   * [`ExternalName`](#externalname): Maps the Service to the contents of the
-     `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
-
-     with its value. No proxying of any kind is set up.
-     {{< note >}}
-     You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
-     {{< /note >}}
-
-You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
 -->
-## 发布服务 —— 服务类型 {#publishing-services-service-types}
+## 发布服务（服务类型)      {#publishing-services-service-types}
 
-对一些应用（如前端）的某些部分，可能希望通过外部 Kubernetes 集群外部 IP 地址暴露 Service。
+对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部
+的 IP 地址。
 
-Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。
+Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是 `ClusterIP`。
 
 `Type` 的取值以及行为如下：
 
-  * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。
-  * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。
-    `NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。
-    通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。
-  * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器，可以向外部暴露服务。
-    外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。
-  * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName`
-    字段的内容（例如， `foo.bar.example.com`）。
-    没有任何类型代理被创建。
+<!--
+* `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
+  makes the Service only reachable from within the cluster. This is the
+  default `ServiceType`.
+* [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
+  (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
+  routes, is automatically created.  You'll be able to contact the `NodePort` Service,
+  from outside the cluster,
+  by requesting `<NodeIP>:<NodePort>`.
+* [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
+  provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
+  load balancer routes, are automatically created.
+* [`ExternalName`](#externalname): Maps the Service to the contents of the
+  `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
+  with its value. No proxying of any kind is set up.
+  {{< note >}}
+  You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
+  {{< /note >}}
+-->
+* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。
+  这也是默认的 `ServiceType`。
+* [`NodePort`](#nodeport)：通过每个节点上的 IP 和静态端口（`NodePort`）暴露服务。
+  `NodePort` 服务会路由到自动创建的 `ClusterIP` 服务。
+  通过请求 `<节点 IP>:<节点端口>`，你可以从集群的外部访问一个 `NodePort` 服务。
+* [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器向外部暴露服务。
+  外部负载均衡器可以将流量路由到自动创建的 `NodePort` 服务和 `ClusterIP` 服务上。
+* [`ExternalName`](#externalname)：通过返回 `CNAME` 和对应值，可以将服务映射到
+  `externalName` 字段的内容（例如，`foo.bar.example.com`）。
+  无需创建任何类型代理。
 
-    {{< note >}}
-    您需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。
-    {{< /note >}}
+  {{< note >}}
+  你需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。
+  {{< /note >}}
 
-您也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
-Ingress 不是服务类型，但它充当集群的入口点。
+<!--
+You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
+-->
+你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
+Ingress 不是一种服务类型，但它充当集群的入口点。
 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。
 
 <!--
@@ -888,15 +881,15 @@ Your Service reports the allocated port in its `.spec.ports[*].nodePort` field.
 
 If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s); this is supported since Kubernetes v1.10.
 This flag takes a comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 192.0.2.0/25) to specify IP address ranges that kube-proxy should consider as local to this node.
-
 -->
 ### NodePort 类型  {#nodeport}
 
-如果将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。
-每个节点将那个端口（每个节点上的相同端口号）代理到您的服务中。
-您的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。
+如果你将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在
+`--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。
+每个节点将那个端口（每个节点上的相同端口号）代理到你的服务中。
+你的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。
 
-如果您想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 
+如果你想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 
 标志设置为特定的 IP 块。从 Kubernetes v1.10 开始支持此功能。
 
 该标志采用逗号分隔的 IP 块列表（例如，`10.0.0.0/8`、`192.0.2.0/25`）来指定
@@ -912,13 +905,16 @@ This means that you need to take care about possible port collisions yourself.
 You also have to use a valid port number, one that's inside the range configured
 for NodePort use.
 -->
-例如，如果您使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，则 kube-proxy 仅选择 NodePort Services 的环回接口。
+例如，如果你使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，
+则 kube-proxy 仅选择 NodePort Services 的本地回路接口。
 `--nodeport-addresses` 的默认值是一个空列表。
 这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。
 （这也与早期的 Kubernetes 版本兼容）。
 
-如果需要特定的端口号，则可以在 `nodePort` 字段中指定一个值。控制平面将为您分配该端口或向API报告事务失败。
-这意味着您需要自己注意可能发生的端口冲突。您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。
+如果需要特定的端口号，你可以在 `nodePort` 字段中指定一个值。
+控制平面将为你分配该端口或报告 API 事务失败。
+这意味着你需要自己注意可能发生的端口冲突。
+你还必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。
 
 <!--
 Using a NodePort gives you the freedom to set up your own load balancing solution,
@@ -930,10 +926,11 @@ and `.spec.clusterIP:spec.ports[*].port`. (If the `-nodeport-addresses` flag in
 
 For example:
 -->
-使用 NodePort 可以让您自由设置自己的负载平衡解决方案，配置 Kubernetes 不完全支持的环境，
+使用 NodePort 可以让你自由设置自己的负载均衡解决方案，配置 Kubernetes 不完全支持的环境，
 甚至直接暴露一个或多个节点的 IP。
 
-需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。
+需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和
+`spec.clusterIp:spec.ports[*].port` 而对外可见。
 
 例如：
 
@@ -998,24 +995,34 @@ status:
 <!--
 Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.
 
+For LoadBalancer type of Services, when there is more than one port defined, all
+ports must have the same protocol and the protocol must be one of `TCP`, `UDP`,
+and `SCTP`.
+-->
+来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。
+
+对于 LoadBalancer 类型的服务，当所定义的端口不止一个时，所有端口都必须
+使用相同的协议，并且其协议必须是 `TCP`、`UDP` 和 `SCTP` 之一。
+
+<!--
 Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
 with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
 the loadBalancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP`
 but your cloud provider does not support the feature, the `loadbalancerIP` field that you
 set is ignored.
 -->
-来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。
-
+某些云提供商允许设置 `loadBalancerIP`。
 在这些情况下，将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。
-某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。
-如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。
+如果没有设置 `loadBalancerIP` 字段，将会给负载均衡器指派一个临时 IP。
+如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的
+`loadBalancerIP` 值将会被忽略掉。
 
 <!--
 If you're using SCTP, see the [caveat](#caveat-sctp-loadbalancer-service-type) below about the
 `LoadBalancer` Service type.
 -->
 {{< note >}}
-如果您使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的
+如果你使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的
 [注意事项](#caveat-sctp-loadbalancer-service-type)。
 {{< /note >}}
 
@@ -1028,13 +1035,16 @@ 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).
 -->
 {{< note >}}
-在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。
-此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。
+在 **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)。
+请参阅 [与 Azure Kubernetes服务（AKS）负载平衡器一起使用静态 IP 地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)
+或[在 AKS 集群上使用高级联网时出现 CreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。
 {{< /note >}}
 
 <!--
@@ -1048,13 +1058,13 @@ In a split-horizon DNS environment you would need two Services to be able to rou
 You can achieve this by adding one the following annotations to a Service.
 The annotation to add depends on the cloud Service provider you're using.
 -->
-#### 内部负载均衡器
+#### 内部负载均衡器   {#internal-load-balancer}
 
 在混合环境中，有时有必要在同一(虚拟)网络地址块内路由来自服务的流量。
 
-在水平分割 DNS 环境中，您需要两个服务才能将内部和外部流量都路由到您的端点（Endpoints）。
-您可以通过向服务添加以下注释之一来实现此目的。
-要添加的注释取决于您使用的云服务提供商。
+在水平分割 DNS 环境中，你需要两个服务才能将内部和外部流量都路由到你的端点（Endpoints）。
+你可以通过向服务添加以下注解之一来实现此目的。
+要添加的注解取决于你使用的云服务提供商。
 
 {{< tabs name="service_tabs" >}}
 {{% tab name="Default" %}}
@@ -1072,14 +1082,10 @@ metadata:
         cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
-<!--
-Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
-For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing).
--->
-将 `cloud.google.com/load-balancer-type: "internal"` 节点用于版本1.7.0至1.7.3的主服务器。
-有关更多信息，请参见[文档](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)。
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1088,8 +1094,10 @@ metadata:
         service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1098,8 +1106,10 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1108,8 +1118,10 @@ metadata:
         service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1118,8 +1130,10 @@ metadata:
         service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1128,8 +1142,10 @@ metadata:
         service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1137,8 +1153,10 @@ metadata:
     service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Alibaba Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1146,6 +1164,7 @@ metadata:
     service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -1157,7 +1176,8 @@ annotations to a `LoadBalancer` service:
 -->
 ### AWS TLS 支持 {#ssl-support-on-aws}
 
-为了对在AWS上运行的集群提供部分TLS / SSL支持，您可以向 `LoadBalancer` 服务添加三个注释：
+为了对在 AWS 上运行的集群提供 TLS/SSL 部分支持，你可以向 `LoadBalancer`
+服务添加三个注解：
 
 ```yaml
 metadata:
@@ -1171,8 +1191,8 @@ The first specifies the ARN of the certificate to use. It can be either a
 certificate from a third party issuer that was uploaded to IAM or one created
 within AWS Certificate Manager.
 -->
-
-第一个指定要使用的证书的ARN。 它可以是已上载到 IAM 的第三方颁发者的证书，也可以是在 AWS Certificate Manager 中创建的证书。
+第一个指定要使用的证书的 ARN。 它可以是已上载到 IAM 的第三方颁发者的证书，
+也可以是在 AWS Certificate Manager 中创建的证书。
 
 ```yaml
 metadata:
@@ -1197,14 +1217,15 @@ modifying the headers.
 In a mixed-use environment where some ports are secured and others are left unencrypted,
 you can use the following annotations:
 -->
-第二个注释指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书通过加密连接对自己进行身份验证。
+第二个注解指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书
+通过加密连接对自己进行身份验证。
 
 HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向
 `X-Forwarded-For` 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。
 
 TCP 和 SSL 选择第4层代理：ELB 转发流量而不修改报头。
 
-在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注释：
+在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注解：
 
 ```yaml
     metadata:
@@ -1222,10 +1243,9 @@ be proxied HTTP.
 From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
 To see which policies are available for use, you can use the `aws` command line tool:
 -->
-
 从 Kubernetes v1.9 起可以使用
 [预定义的 AWS SSL 策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)
-为您的服务使用 HTTPS 或 SSL 侦听器。
+为你的服务使用 HTTPS 或 SSL 侦听器。
 要查看可以使用哪些策略，可以使用 `aws` 命令行工具：
 
 ```bash
@@ -1237,8 +1257,8 @@ You can then specify any one of those policies using the
 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
 annotation; for example:
 -->
-然后，您可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" 注解; 
-例如：
+然后，你可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
+注解; 例如：
 
 ```yaml
     metadata:
@@ -1256,8 +1276,9 @@ annotation:
 -->
 #### AWS 上的 PROXY 协议支持
 
-为了支持在 AWS 上运行的集群，启用 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。
-您可以使用以下服务注释：
+为了支持在 AWS 上运行的集群，启用
+[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。
+你可以使用以下服务注解：
 
 ```yaml
     metadata:
@@ -1270,7 +1291,7 @@ annotation:
 Since version 1.3.0, the use of this annotation applies to all ports proxied by the ELB
 and cannot be configured otherwise.
 -->
-从 1.3.0 版开始，此注释的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。
+从 1.3.0 版开始，此注解的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。
 
 <!--
 ### External IPs
@@ -1330,17 +1351,17 @@ specifies the logical hierarchy you created for your Amazon S3 bucket.
 -->
 #### AWS 上的 ELB 访问日志
 
-有几个注释可用于管理 AWS 上 ELB 服务的访问日志。
+有几个注解可用于管理 AWS 上 ELB 服务的访问日志。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。
 
 注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` 
-控制发布访问日志的时间间隔（以分钟为单位）。您可以指定 5 分钟或 60 分钟的间隔。
+控制发布访问日志的时间间隔（以分钟为单位）。你可以指定 5 分钟或 60 分钟的间隔。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 
 控制存储负载均衡器访问日志的 Amazon S3 存储桶的名称。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`
 指定为 Amazon S3 存储桶创建的逻辑层次结构。
 
 ```yaml
@@ -1348,13 +1369,13 @@ specifies the logical hierarchy you created for your Amazon S3 bucket.
       name: my-service
       annotations:
         service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
-        # Specifies whether access logs are enabled for the load balancer
+        # 指定是否为负载均衡器启用访问日志
         service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
-        # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes).
+        # 发布访问日志的时间间隔。你可以将其设置为 5 分钟或 60 分钟。
         service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
-        # The name of the Amazon S3 bucket where the access logs are stored
+        # 用来存放访问日志的 Amazon S3 Bucket 名称
         service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
-        # The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod`
+        # 你为 Amazon S3 Bucket 所创建的逻辑层次结构，例如 `my-bucket-prefix/prod`
 ```
 
 <!--
@@ -1370,7 +1391,7 @@ also be used to set maximum time, in seconds, to keep the existing connections o
 
 可以将注解 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`
 设置为 `"true"` 来管理 ELB 的连接排空。
-注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`
+注解 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`
 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。
 
 ```yaml
@@ -1388,7 +1409,7 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
 -->
 #### 其他 ELB 注解
 
-还有其他一些注释，用于管理经典弹性负载均衡器，如下所述。
+还有其他一些注解，用于管理经典弹性负载均衡器，如下所述。
 
 ```yaml
     metadata:
@@ -1421,8 +1442,16 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
         # 此值必须小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
         # 默认值为 5，必须介于 2 和 60 之间
 
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # 要添加到所创建的 ELB 之上的已有安全组列表。与注解
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 不同，此
+        # 注解会替换掉之前指派给 ELB 的所有其他安全组
+
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
         # 要添加到 ELB 上的额外安全组列表
+
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
+        # 用逗号分隔的一个键-值偶对列表，用来为负载均衡器选择目标节点
 ```
 
 <!--
@@ -1449,7 +1478,6 @@ To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernet
 NLB only works with certain instance classes; see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
 on Elastic Load Balancing for a list of supported instance types.
 -->
-
 {{< note >}}
 NLB 仅适用于某些实例类。有关受支持的实例类型的列表，
 请参见
@@ -1540,7 +1568,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`:
 ### ExternalName 类型         {#externalname}
 
 类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。
-您可以使用 `spec.externalName` 参数指定这些服务。
+你可以使用 `spec.externalName` 参数指定这些服务。
 
 例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`：
 
@@ -1578,7 +1606,7 @@ Service's `type`.
 当查找主机 `my-service.prod.svc.cluster.local` 时，集群 DNS 服务返回 `CNAME` 记录，
 其值为 `my.database.example.com`。
 访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
-如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。
+如果以后你决定将数据库移到集群中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。
 
 <!--
 This section is indebted to the [Kubernetes Tips - Part
@@ -1603,7 +1631,8 @@ In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10
 ### 外部 IP  {#external-ips}
 
 如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes Service 会被暴露给这些 externalIPs。
-通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，将会被路由到 Service 的 Endpoint 上。
+通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，
+将会被路由到 Service 的 Endpoint 上。
 `externalIPs` 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。
 
 根据 Service 的规定，`externalIPs` 可以同任意的 `ServiceType` 来一起指定。
@@ -1653,7 +1682,8 @@ but the current API requires it.
 
 使用用户空间代理，隐藏了访问 Service 的数据包的源 IP 地址。
 这使得一些类型的防火墙无法起作用。
-iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
+iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求
+必须通过一个负载均衡器或 Node 端口。
 
 `Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
 不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer`
@@ -1732,8 +1762,10 @@ each operate slightly differently.
 -->
 ### Service IP 地址 {#ips-and-vips}
 
-不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。
-相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。
+不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上
+不能通过单个主机来进行应答。
+相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个
+虚拟 IP 地址（VIP），它可以根据需要透明地进行重定向。
 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。
 环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。
 
@@ -1762,9 +1794,11 @@ of which Pods they are actually accessing.
 作为一个例子，考虑前面提到的图片处理应用程序。
 当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
 假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。
-当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。
+当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到
+新端口的 iptables，并开始接收请求连接。
 
-当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 "服务代理" 的端口。
+当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到
+"服务代理" 的端口。
 "服务代理" 选择一个后端，并将客户端的流量代理到后端上。
 
 这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。
@@ -1811,9 +1845,11 @@ through a load-balancer, though in those cases the client IP does get altered.
 iptables operations slow down dramatically in large scale cluster e.g 10,000 Services.
 IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
 -->
-在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。
-因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。
-同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。
+在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS
+专为负载平衡而设计，并基于内核内哈希表。
+因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。
+同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、
+加权、持久性）。
 
 ## API 对象
 
@@ -1821,57 +1857,48 @@ IPVS is designed for load balancing and based on in-kernel hash tables. So you c
 Service is a top-level resource in the Kubernetes REST API. You can find more details
 about the API object at: [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
 -->
-Service 是 Kubernetes REST API 中的顶级资源。您可以在以下位置找到有关A PI 对象的更多详细信息：
+Service 是 Kubernetes REST API 中的顶级资源。你可以在以下位置找到有关 API 对象的更多详细信息：
 [Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
 
 ## 受支持的协议 {#protocol-support}
 
 ### TCP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 You can use TCP for any kind of Service, and it's the default network protocol.
 -->
-您可以将 TCP 用于任何类型的服务，这是默认的网络协议。
+你可以将 TCP 用于任何类型的服务，这是默认的网络协议。
 
 ### UDP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 You can use UDP for most Services. For type=LoadBalancer Services, UDP support
 depends on the cloud provider offering this facility.
 -->
-您可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。
+你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。
 
 ### HTTP
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
 <!--
 If your cloud provider supports it, you can use a Service in LoadBalancer mode
 to set up external HTTP / HTTPS reverse proxying, forwarded to the Endpoints
 of the Service.
 -->
-如果您的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。
+如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部
+HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。
 
 <!--
 You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service
 to expose HTTP / HTTPS Services.
 -->
 {{< note >}}
-您还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替 Service 来公开 HTTP/HTTPS 服务。
+你还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替
+Service 来公开 HTTP/HTTPS 服务。
 {{< /note >}}
 
 <!--
 ### PROXY protocol
--->
-### PROXY 协议
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
-<!--
 If your cloud provider supports it,
 you can use a Service in LoadBalancer mode to configure a load balancer outside
 of Kubernetes itself, that will forward connections prefixed with
@@ -1880,10 +1907,12 @@ of Kubernetes itself, that will forward connections prefixed with
 The load balancer will send an initial series of octets describing the
 incoming connection, similar to this example
 -->
+### PROXY 协议
 
-如果您的云提供商支持它，
+如果你的云提供商支持它，
 则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器，
-该负载均衡器将转发前缀为 [PROXY协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
+该负载均衡器将转发前缀为
+[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
 的连接。
 
 负载平衡器将发送一系列初始字节，描述传入的连接，类似于此示例
@@ -1899,19 +1928,22 @@ followed by the data from the client.
 
 ### SCTP
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 <!--
-Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPolicy and Pod definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `-feature-gates=SCTPSupport=true,…`.
+Kubernetes supports SCTP as a `protocol` value in Service, Endpoints, EndpointSlice, NetworkPolicy and Pod definitions. As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
 
-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.
+When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoints, EndpointSlice, 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、EndpointSlice, NetworkPolicy
+和 Pod 定义中的 `protocol` 值。
+作为一种 Beta 特性，此功能默认是启用的。集群管理员需要在 API 服务器上使用
+`--feature-gates=SCTPSupport=false,...` 来关闭
+`SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+来在集群级别禁用 SCTP。
 
-作为一种 alpha 功能，Kubernetes 支持 SCTP 作为 Service、Endpoint、NetworkPolicy 和 Pod 定义中的 `protocol` 值。
-要启用此功能，集群管理员需要在 API 服务器上启用 `SCTPSupport` 特性门控，
-例如 `--feature-gates=SCTPSupport=true,...`。
-
-启用特性门控后，你可以将 Service、Endpoints、NetworkPolicy 或 Pod 的 `protocol` 字段设置为 `SCTP`。
+启用特性门控后，你可以将 Service、Endpoints、EndpointSlice、NetworkPolicy 或
+Pod 的 `protocol` 字段设置为 `SCTP`。
 Kubernetes 相应地为 SCTP 关联设置网络，就像为 TCP 连接所做的一样。
 
 <!--
@@ -1936,13 +1968,10 @@ NAT for multihomed SCTP associations requires special logic in the corresponding
 
 <!--
 ##### Service with type=LoadBalancer {#caveat-sctp-loadbalancer-service-type}
--->
 
-##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type}
-
-<!--
 You can only create a Service with `type` LoadBalancer plus `protocol` SCTP if the cloud provider's load balancer implementation supports SCTP as a protocol. Otherwise, the Service creation request is rejected. The current set of cloud load balancer providers (Azure, AWS, CloudStack, GCE, OpenStack) all lack support for SCTP.
 -->
+##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type}
 
 {{< warning >}}
 如果云提供商的负载平衡器实现支持将 SCTP 作为协议，则只能使用 `type` LoadBalancer 加上
@@ -1959,38 +1988,20 @@ SCTP is not supported on Windows based nodes.
 基于 Windows 的节点不支持 SCTP。
 {{< /warning >}}
 
+<!--
+##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
+
+The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
+-->
 ##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace}
 
+{{< warning >}}
 <!--
 The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
 -->
-{{< warning >}}
 当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。
 {{< /warning >}}
 
-<!--
-## Future work
-
-In the future, the proxy policy for Services can become more nuanced than
-simple round-robin balancing, for example master-elected or sharded.  We also
-envision that some Services will have "real" load balancers, in which case the
-virtual IP address will simply transport the packets there.
-
-The Kubernetes project intends to improve support for L7 (HTTP) Services.
-
-The Kubernetes project intends to have more flexible ingress modes for Services
-which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more.
--->
-## 未来工作
-
-未来我们能预见到，代理策略可能会变得比简单的轮转均衡策略有更多细微的差别，比如主控节点选举或分片。
-我们也能想到，某些 Service 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。
-
-Kubernetes 项目打算为 L7（HTTP）服务改进支持。
-
-Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式，
-这些模式包含当前的 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。
-
 ## {{% heading "whatsnext" %}}
 
 <!--
@@ -1998,8 +2009,7 @@ Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式，
 * Read about [Ingress](/docs/concepts/services-networking/ingress/)
 * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
 -->
-
 * 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/)
 * 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)
-* 阅读了解 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)
+* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/)