resolving conflicts

2020-08-23 12:13:37 -04:00
parent 8d56047830 03e4a9edc5
commit 95c94c03d5
504 changed files with 16169 additions and 11399 deletions
@@ -0,0 +1,102 @@
+---
+title: Kubernetes 社区 - 2017 年开源排行榜榜首
+date: 2018-04-25
+slug: open-source-charts-2017
+---
+<!--
+---
+title: Kubernetes Community - Top of the Open Source Charts in 2017
+date: 2018-04-25
+slug: open-source-charts-2017
+---
+--->
+
+<!--
+2017 was a huge year for Kubernetes, and GitHub’s latest [Octoverse report](https://octoverse.github.com) illustrates just how much attention this project has been getting.
+
+Kubernetes, an [open source platform for running application containers](/docs/concepts/overview/what-is-kubernetes/), provides a consistent interface that enables developers and ops teams to automate the deployment, management, and scaling of a wide variety of applications on just about any infrastructure.
+--->
+对于 Kubernetes 来说，2017 年是丰收的一年，GitHub的最新 [Octoverse 报告](https://octoverse.github.com) 说明了该项目获得了多少关注。
+
+Kubernetes 是 [用于运行应用程序容器的开源平台](/docs/concepts/overview/what-is-kubernetes/)，它提供了一个统一的界面，使开发人员和操作团队能够自动执行部署、管理和扩展几乎任何基础架构上的各种应用程序。
+
+<!--
+Solving these shared challenges by leveraging a wide community of expertise and industrial experience, as Kubernetes does, helps engineers focus on building their own products at the top of the stack, rather than needlessly duplicating work that now exists as a standard part of the “cloud native” toolkit.
+
+However, achieving these gains via ad-hoc collective organizing is its own unique challenge, one which makes it increasingly difficult to support open source, community-driven efforts through periods of rapid growth.
+
+Read on to find out how the Kubernetes Community has addressed these scaling challenges to reach the top of the charts in GitHub’s 2017 Octoverse report.
+--->
+Kubernetes 所做的，是通过利用广泛的专业知识和行业经验来解决这些共同的挑战，可以帮助工程师专注于在堆栈的顶部构建自己的产品，而不是不必要地进行重复工作，比如现在已经存在的 “云原生” 工具包的标准部分。
+
+但是，通过临时的集体组织来实现这些收益是它独有的挑战，这使得支持开源，社区驱动的工作变得越来越困难。
+
+继续阅读以了解 Kubernetes 社区如何解决这些挑战，从而在 GitHub 的 2017 Octoverse 报告中位居榜首。
+
+<!--
+## Most-Discussed on GitHub
+
+The top two most-discussed repos of 2017 are both based on Kubernetes:
+
+![Most Discussed](/images/blog-logging/2018-04-24-open-source-charts-2017/most-discussed.png)
+
+Of all the open source repositories on GitHub, none received more issue comments than [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/). [OpenShift](http://openshift.com/), a [CNCF certified distribution of Kubernetes](https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/), took second place.  
+
+Open discussion with ample time for community feedback and review helps build shared infrastructure and establish new standards for cloud native computing.
+--->
+## GitHub 上讨论最多的
+
+2017 年讨论最多的两个仓库都是基于 Kubernetes 的：
+
+！[讨论最多](/images/blog-logging/2018-04-24-open-source-charts-2017/most-discussed.png)
+
+在 GitHub 的所有开源存储库中，没有比 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/) 收到更多的评论。 [OpenShift](http://openshift.com/)， [CNCF 认证的 Kubernetes 发行版](https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/) 排名第二。
+
+利用充足时间进行公开讨论来获取社区反馈和审查，有助于建立共享的基础架构并为云原生计算建立新标准。
+
+<!--
+## Most Reviewed on GitHub
+
+Successfully scaling an open source effort’s communications often leads to better coordination and higher-quality feature delivery. The Kubernetes project’s [Special Interest Group (SIG)](https://github.com/kubernetes/community/blob/master/sig-list.md) structure has helped it become GitHub’s second most reviewed project:
+
+![Most Reviewed](/images/blog-logging/2018-04-24-open-source-charts-2017/most-reviews.png)
+
+Using SIGs to segment and standardize mechanisms for community participation helps channel more frequent reviews from better-qualified community members.
+
+When managed effectively, active community discussions indicate more than just a highly contentious codebase, or a project with an extensive list of unmet needs.
+--->
+## GitHub 上审阅最多的
+
+成功扩展开放源代码工作的通信通常会带来更好的协调和更高质量的功能交付。Kubernetes 项目的 [Special Interest Group（SIG）](https://github.com/kubernetes/community/blob/master/sig-list.md) 结构已使其成为 GitHub 审阅第二多的项目：
+
+！[审阅最多](/images/blog-logging/2018-04-24-open-source-charts-2017/most-reviews.png)
+
+使用 SIG 对社区参与机制进行细分和标准化有助于从资格更高的社区成员中获得更频繁的审阅。
+
+如果得到有效管理，活跃的社区讨论不仅表明代码库存在很大的争议，也可能表明项目包含大量未满足的需求。
+
+<!--
+Scaling a project’s capacity to handle issues and community interactions helps to expand the conversation.  Meanwhile, large communities come with more diverse use cases and a larger array of support problems to manage. The Kubernetes [SIG organization structure](https://github.com/kubernetes/community#sigs) helps to address the challenges of complex communication at scale.
+
+SIG meetings provide focused opportunities for users, maintainers, and specialists from various disciplines to collaborate together in support of this community effort.  These investments in organizing help create an environment where it’s easier to prioritize architecture discussion and planning over commit velocity; enabling the project to sustain this kind of scale.
+--->
+扩展项目处理问题和社区互动的能力有助于扩大交流。同时，大型社区具有更多不同的用例和更多的支持问题需要管理。Kubernetes [SIG 组织结构](https://github.com/kubernetes/community#sigs) 帮助应对大规模复杂通信的挑战。
+
+SIG 会议为不同学科的用户、维护者和专家提供了重点合作的机会，以共同协作来支持社区的工作。这些在组织上的投资有助于创建一个环境，在这样的环境中，可以更轻松地将架构讨论和规划的优先级排到提交速度前面，并使项目能够维持这种规模。
+
+<!--
+## Join the party!
+
+You may already be using solutions that are successfully managed and scaled on Kubernetes. For example, GitHub.com, which hosts Kubernetes’ upstream source code, [now runs on Kubernetes](https://githubengineering.com/kubernetes-at-github/) as well!
+
+Check out the [Kubernetes Contributors’ guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) for more information on how to get started as a contributor.
+
+You can also join the [weekly Kubernetes Community meeting](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) and consider [joining a SIG or two](https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list).
+--->
+## 加入我们！
+
+您可能已经在 Kubernetes 上成功使用管理和扩展的解决方案。例如，托管 Kubernetes 上游源代码的 GitHub.com [现在也可以在 Kubernetes 上运行](https://githubengineering.com/kubernetes-at-github/) ！
+
+请查看 [Kubernetes 贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) ，以获取有关如何开始作为贡献者的更多信息。
+
+您也可以参加 [每周 Kubernetes 的社区会议](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) 并考虑 [加入一个或两个 SIG](https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list)。
@@ -0,0 +1,307 @@
+---
+layout: blog
+title: "用于 Kubernetes 集群 DNS 的 CoreDNS GA 正式发布"
+date: 2018-07-10
+---
+<!--
+---
+layout: blog
+title: "CoreDNS GA for Kubernetes Cluster DNS"
+date: 2018-07-10
+---
+--->
+
+<!--
+**Author**: John Belamaric (Infoblox)
+
+**Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) on what’s new in Kubernetes 1.11**
+--->
+**作者**：John Belamaric (Infoblox)
+
+**编者注：这篇文章是 [系列深度文章](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) 中的一篇，介绍了 Kubernetes 1.11 新增的功能
+
+<!--
+## Introduction
+
+In Kubernetes 1.11, [CoreDNS](https://coredns.io) has reached General Availability (GA) for DNS-based service discovery, as an alternative to the kube-dns addon. This means that CoreDNS will be offered as an option in upcoming versions of the various installation tools. In fact, the kubeadm team chose to make it the default option starting with Kubernetes 1.11.
+--->
+## 介绍
+
+在 Kubernetes 1.11 中，[CoreDNS](https://coredns.io) 已经达到基于 DNS 服务发现的 General Availability (GA)，可以替代 kube-dns 插件。这意味着 CoreDNS 会作为即将发布的安装工具的选项之一上线。实际上，从 Kubernetes 1.11 开始，kubeadm 团队选择将它设为默认选项。
+
+<!--
+DNS-based service discovery has been part of Kubernetes for a long time with the kube-dns cluster addon. This has generally worked pretty well, but there have been some concerns around the reliability, flexibility and security of the implementation.
+
+CoreDNS is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. It resolves the issues seen with kube-dns, and offers a number of unique features that solve a wider variety of use cases.
+
+In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.
+--->
+很久以来， kube-dns 集群插件一直是 Kubernetes 的一部分，用来实现基于 DNS 的服务发现。
+通常，此插件运行平稳，但对于实现的可靠性、灵活性和安全性仍存在一些疑虑。
+
+CoreDNS 是通用的、权威的 DNS 服务器，提供与 Kubernetes 向后兼容但可扩展的集成。它解决了 kube-dns 遇到的问题，并提供了许多独特的功能，可以解决各种用例。
+
+在本文中，您将了解 kube-dns 和 CoreDNS 的实现有何差异，以及 CoreDNS 提供的一些非常有用的扩展。
+
+<!--
+## Implementation differences
+
+In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
+container watches the Kubernetes API and serves DNS records based on the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), `dnsmasq` provides caching and stub domain support, and `sidecar` provides metrics and health checks.
+--->
+## 实现差异
+
+在 kube-dns 中，一个 Pod 中使用多个 容器：`kubedns`、`dnsmasq`、和 `sidecar`。`kubedns` 容器监视 Kubernetes API 并根据 [Kubernetes DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md) 提供 DNS 记录，`dnsmasq` 提供缓存和存根域支持，`sidecar` 提供指标和健康检查。
+
+<!--
+This setup leads to a few issues that have been seen over time. For one, security vulnerabilities in `dnsmasq` have led to the need
+for a security-patch release of Kubernetes in the past. Additionally, because `dnsmasq` handles the stub domains,
+but `kubedns` handles the External Services, you cannot use a stub domain in an external service, which is very
+limiting to that functionality (see [dns#131](https://github.com/kubernetes/dns/issues/131)).
+
+All of these functions are done in a single container in CoreDNS, which is running a process written in Go. The
+different plugins that are enabled replicate (and enhance) the functionality found in kube-dns.
+--->
+随着时间的推移，此设置会导致一些问题。一方面，以往 `dnsmasq` 中的安全漏洞需要通过发布 Kubernetes 的安全补丁来解决。但是，由于 `dnsmasq` 处理存根域，而 `kubedns` 处理外部服务，因此您不能在外部服务中使用存根域，导致这个功能具有局限性（请参阅 [dns#131](https://github.com/kubernetes/dns/issues/131)）。
+
+在 CoreDNS 中，所有这些功能都是在一个容器中完成的，该容器运行用 Go 编写的进程。所启用的不同插件可复制（并增强）在 kube-dns 中存在的功能。
+
+<!--
+## Configuring CoreDNS
+
+In kube-dns, you can [modify a ConfigMap](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/) to change the behavior of your service discovery. This allows the addition of
+features such as serving stub domains, modifying upstream nameservers, and enabling federation.
+--->
+## 配置 CoreDNS
+
+在 kube-dns 中，您可以 [修改 ConfigMap](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/) 来更改服务发现的行为。用户可以添加诸如为存根域提供服务、修改上游名称服务器以及启用联盟之类的功能。
+
+<!--
+In CoreDNS, you similarly can modify the ConfigMap for the CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) to change how service discovery
+works. This Corefile configuration offers many more options than you will find in kube-dns, since it is the
+primary configuration file that CoreDNS uses for configuration of all of its features, even those that are not
+Kubernetes related.
+
+When upgrading from kube-dns to CoreDNS using `kubeadm`, your existing ConfigMap will be used to generate the
+customized Corefile for you, including all of the configuration for stub domains, federation, and upstream nameservers. See [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/) for more details.
+--->
+在 CoreDNS 中，您可以类似地修改 CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) 的 ConfigMap，以更改服务发现的工作方式。这种 Corefile 配置提供了比 kube-dns 中更多的选项，因为它是 CoreDNS 用于配置所有功能的主要配置文件，即使与 Kubernetes 不相关的功能也可以操作。
+
+使用 `kubeadm` 将 kube-dns 升级到 CoreDNS 时，现有的 ConfigMap 将被用来为您生成自定义的 Corefile，包括存根域、联盟和上游名称服务器的所有配置。更多详细信息，请参见
+[使用 CoreDNS 进行服务发现](/zh/docs/tasks/administer-cluster/coredns/)。
+
+<!--
+## Bug fixes and enhancements
+
+There are several open issues with kube-dns that are resolved in CoreDNS, either in default configuration or with some customized configurations.
+--->
+## 错误修复和增强
+
+在 CoreDNS 中解决了 kube-dn 的多个未解决问题，无论是默认配置还是某些自定义配置。
+
+<!--
+  * [dns#55 - Custom DNS entries for kube-dns](https://github.com/kubernetes/dns/issues/55) may be handled using the "fallthrough" mechanism in the [kubernetes plugin](https://coredns.io/plugins/kubernetes), using the [rewrite plugin](https://coredns.io/plugins/rewrite), or simply serving a subzone with a different plugin such as the [file plugin](https://coredns.io/plugins/file).
+
+  * [dns#116 - Only one A record set for headless service with pods having single hostname](https://github.com/kubernetes/dns/issues/116). This issue is fixed without any additional configuration.
+  * [dns#131 - externalName not using stubDomains settings](https://github.com/kubernetes/dns/issues/131). This issue is fixed without any additional configuration.
+  * [dns#167 - enable skyDNS round robin A/AAAA records](https://github.com/kubernetes/dns/issues/167). The equivalent functionality can be configured using the [load balance plugin](https://coredns.io/plugins/loadbalance).
+  * [dns#190 - kube-dns cannot run as non-root user](https://github.com/kubernetes/dns/issues/190). This issue is solved today by using a non-default image, but it will be made the default CoreDNS behavior in a future release.
+  * [dns#232 - fix pod hostname to be podname for dns srv records](https://github.com/kubernetes/dns/issues/232) is an enhancement that is supported through the "endpoint_pod_names" feature described below.
+--->
+  * [dns#55 - kube-dns 的自定义 DNS 条目](https://github.com/kubernetes/dns/issues/55) 可以使用 [kubernetes 插件](https://coredns.io/plugins/kubernetes) 中的 "fallthrough" 机制，使用 [rewrite 插件](https://coredns.io/plugins/rewrite)，或者分区使用不同的插件，例如 [file 插件](https://coredns.io/plugins/file)。
+  
+  * [dns#116 - 对具有相同主机名的、提供无头服务服务的 Pod 仅设置了一个 A 记录](https://github.com/kubernetes/dns/issues/116)。无需任何其他配置即可解决此问题。
+  * [dns#131 - externalName 未使用 stubDomains 设置](https://github.com/kubernetes/dns/issues/131)。无需任何其他配置即可解决此问题。
+  * [dns#167 - 允许 skyDNS 为 A/AAAA 记录提供轮换](https://github.com/kubernetes/dns/issues/167)。可以使用 [负载均衡插件](https://coredns.io/plugins/loadbalance) 配置等效功能。
+  * [dns#190 - kube-dns 无法以非 root 用户身份运行](https://github.com/kubernetes/dns/issues/190)。今天，通过使用 non-default 镜像解决了此问题，但是在将来的版本中，它将成为默认的 CoreDNS 行为。
+  * [dns#232 - 在 dns srv 记录中修复 pod hostname 为 podname](https://github.com/kubernetes/dns/issues/232) 是通过下面提到的 "endpoint_pod_names" 功能进行支持的增强功能。
+
+
+<!--
+## Metrics
+
+The functional behavior of the default CoreDNS configuration is the same as kube-dns. However,
+one difference you need to be aware of is that the published metrics are not the same. In kube-dns,
+you get separate metrics for `dnsmasq` and `kubedns` (skydns). In CoreDNS there is a completely
+different set of metrics, since it is all a single process. You can find more details on these
+metrics on the CoreDNS [Prometheus plugin](https://coredns.io/plugins/metrics/) page.
+--->
+## 指标
+
+CoreDNS 默认配置的功能性行为与 kube-dns 相同。但是，你需要了解的差别之一是二者发布的指标是不同的。在 kube-dns 中，您将分别获得 `dnsmasq` 和 `kubedns`（skydns）的度量值。在 CoreDNS 中，存在一组完全不同的指标，因为它们在同一个进程中。您可以在 CoreDNS [Prometheus 插件](https://coredns.io/plugins/metrics/) 页面上找到有关这些指标的更多详细信息。
+
+<!--
+## Some special features
+
+The standard CoreDNS Kubernetes configuration is designed to be backwards compatible with the prior
+kube-dns behavior. But with some configuration changes, CoreDNS can allow you to modify how the
+DNS service discovery works in your cluster. A number of these features are intended to still be
+compliant with the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md);
+they enhance functionality but remain backward compatible. Since CoreDNS is not
+*only* made for Kubernetes, but is instead a general-purpose DNS server, there are many things you
+can do beyond that specification.
+--->
+## 一些特殊功能
+
+标准的 CoreDNS Kubernetes 配置旨在与以前的 kube-dns 在行为上向后兼容。但是，通过进行一些配置更改，CoreDNS 允许您修改 DNS 服务发现在群集中的工作方式。这些功能中的许多功能仍要符合 [Kubernetes DNS规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)；它们在增强了功能的同时保持向后兼容。由于 CoreDNS 并非 *仅* 用于 Kubernetes，而是通用的 DNS 服务器，因此您可以做很多超出该规范的事情。
+
+<!--
+### Pods verified mode
+
+In kube-dns, pod name records are "fake". That is, any "a-b-c-d.namespace.pod.cluster.local" query will
+return the IP address "a.b.c.d". In some cases, this can weaken the identity guarantees offered by TLS. So,
+CoreDNS offers a "pods verified" mode, which will only return the IP address if there is a pod in the
+specified namespace with that IP address.
+--->
+### Pod 验证模式
+
+在 kube-dns 中，Pod 名称记录是 "伪造的"。也就是说，任何 "a-b-c-d.namespace.pod.cluster.local" 查询都将返回 IP 地址 "a.b.c.d"。在某些情况下，这可能会削弱 TLS 提供的身份确认。因此，CoreDNS 提供了一种 "Pod 验证" 的模式，该模式仅在指定名称空间中存在具有该 IP 地址的 Pod 时才返回 IP 地址。
+
+<!--
+### Endpoint names based on pod names
+
+In kube-dns, when using a headless service, you can use an SRV request to get a list of
+all endpoints for the service:
+--->
+### 基于 Pod 名称的端点名称
+
+在 kube-dns 中，使用无头服务时，可以使用 SRV 请求获取该服务的所有端点的列表：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 10 33 0 6234396237313665.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6662363165353239.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6338633437303230.headless.default.svc.cluster.local.
+dnstools#
+```
+
+<!--
+However, the endpoint DNS names are (for practical purposes) random. In CoreDNS, by default, you get endpoint
+DNS names based upon the endpoint IP address:
+--->
+但是，端点 DNS 名称（出于实际目的）是随机的。在 CoreDNS 中，默认情况下，您所获得的端点 DNS 名称是基于端点 IP 地址生成的：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-14.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-18.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-4.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-9.headless.default.svc.cluster.local.
+```
+
+<!--
+For some applications, it is desirable to have the pod name for this, rather than the pod IP
+address (see for example [kubernetes#47992](https://github.com/kubernetes/kubernetes/issues/47992) and [coredns#1190](https://github.com/coredns/coredns/pull/1190)). To enable this in CoreDNS, you specify the "endpoint_pod_names" option in your Corefile, which results in this:
+--->
+对于某些应用程序，你会希望在这里使用 Pod 名称，而不是 Pod IP 地址（例如，参见 [kubernetes#47992](https://github.com/kubernetes/kubernetes/issues/47992) 和 [coredns#1190](https://github.com/coredns/coredns/pull/1190)）。要在 CoreDNS 中启用此功能，请在 Corefile 中指定 "endpoint_pod_names" 选项，结果如下：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-qv84p.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-zc8lx.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-q7lf2.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-566rt.headless.default.svc.cluster.local.
+```
+
+<!--
+### Autopath
+
+CoreDNS also has a special feature to improve latency in DNS requests for external names. In Kubernetes, the
+DNS search path for pods specifies a long list of suffixes. This enables the use of short names when requesting
+services in the cluster - for example, "headless" above, rather than "headless.default.svc.cluster.local". However,
+when requesting an external name  - "infoblox.com", for example - several invalid DNS queries are made by the client,
+requiring a roundtrip from the client to kube-dns each time (actually to `dnsmasq` and then to `kubedns`, since [negative caching is disabled](https://github.com/kubernetes/dns/issues/121)):
+--->
+### 自动路径
+
+CoreDNS 还具有一项特殊功能，可以改善 DNS 中外部名称请求的延迟。在 Kubernetes 中，Pod 的 DNS 搜索路径指定了一长串后缀。这一特点使得你可以针对集群中服务使用短名称 - 例如，上面的 "headless"，而不是 "headless.default.svc.cluster.local"。但是，当请求一个外部名称（例如 "infoblox.com"）时，客户端会进行几个无效的 DNS 查询，每次都需要从客户端到 kube-dns 往返（实际上是到 `dnsmasq`，然后到 `kubedns`），因为 [禁用了负缓存](https://github.com/kubernetes/dns/issues/121)）
+
+  * infoblox.com.default.svc.cluster.local -> NXDOMAIN
+  * infoblox.com.svc.cluster.local -> NXDOMAIN
+  * infoblox.com.cluster.local -> NXDOMAIN
+  * infoblox.com.your-internal-domain.com -> NXDOMAIN
+<!--
+  * infoblox.com -> returns a valid record
+--->
+  * infoblox.com -> 返回有效记录
+
+<!--
+In CoreDNS, an optional feature called [autopath](https://coredns.io/plugins/autopath) can be enabled that will cause this search path to be followed
+*in the server*. That is, CoreDNS will figure out from the source IP address which namespace the client pod is in,
+and it will walk this search list until it gets a valid answer. Since the first 3 of these are resolved internally
+within CoreDNS itself, it cuts out all of the back and forth between the client and server, reducing latency.
+--->
+在 CoreDNS 中，可以启用 [autopath](https://coredns.io/plugins/autopath) 的可选功能，该功能使搜索路径在 *服务器端* 遍历。也就是说，CoreDNS 将基于源 IP 地址判断客户端 Pod 所在的命名空间，并且遍历此搜索列表，直到获得有效答案为止。由于其中的前三个是在 CoreDNS 本身内部解决的，因此它消除了客户端和服务器之间所有的来回通信，从而减少了延迟。
+
+<!--
+### A few other Kubernetes specific features
+
+In CoreDNS, you can use standard DNS zone transfer to export the entire DNS record set. This is useful for
+debugging your services as well as importing the cluster zone into other DNS servers.
+
+You can also filter by namespaces or a label selector. This can allow you to run specific CoreDNS instances that will only server records that match the filters, exposing only a limited set of your services via DNS.
+--->
+### 其他一些特定于 Kubernetes 的功能
+
+在 CoreDNS 中，您可以使用标准 DNS 区域传输来导出整个 DNS 记录集。这对于调试服务以及将集群区导入其他 DNS 服务器很有用。
+
+您还可以按名称空间或标签选择器进行过滤。这样，您可以运行特定的 CoreDNS 实例，该实例仅服务与过滤器匹配的记录，从而通过 DNS 公开受限的服务集。
+
+<!--
+## Extensibility
+
+In addition to the features described above, CoreDNS is easily extended. It is possible to build custom versions
+of CoreDNS that include your own features. For example, this ability has been used to extend CoreDNS to do recursive resolution
+with the [unbound plugin](https://coredns.io/explugins/unbound), to server records directly from a database with the [pdsql plugin](https://coredns.io/explugins/pdsql), and to allow multiple CoreDNS instances to share a common level 2 cache with the [redisc plugin](https://coredns.io/explugins/redisc).
+
+Many other interesting extensions have been added, which you will find on the [External Plugins](https://coredns.io/explugins/) page of the CoreDNS site. One that is really interesting for Kubernetes and Istio users is the [kubernetai plugin](https://coredns.io/explugins/kubernetai), which allows a single CoreDNS instance to connect to multiple Kubernetes clusters and provide service discovery across all of them.
+--->
+## 可扩展性
+
+除了上述功能之外，CoreDNS 还可轻松扩展，构建包含您独有的功能的自定义版本的 CoreDNS。例如，这一能力已被用于扩展 CoreDNS 来使用 [unbound 插件](https://coredns.io/explugins/unbound) 进行递归解析、使用 [pdsql 插件](https://coredns.io/explugins/pdsql) 直接从数据库提供记录，以及使用 [redisc 插件](https://coredns.io/explugins/redisc) 与多个 CoreDNS 实例共享一个公共的 2 级缓存。
+
+已添加的还有许多其他有趣的扩展，您可以在 CoreDNS 站点的 [外部插件](https://coredns.io/explugins/) 页面上找到这些扩展。Kubernetes 和 Istio 用户真正感兴趣的是 [kubernetai 插件](https://coredns.io/explugins/kubernetai)，它允许单个 CoreDNS 实例连接到多个 Kubernetes 集群并在所有集群中提供服务发现 。
+
+<!--
+## What's Next?
+
+CoreDNS is an independent project, and as such is developing many features that are not directly
+related to Kubernetes. However, a number of these will have applications within Kubernetes. For example,
+the upcoming integration with policy engines will allow CoreDNS to make intelligent choices about which endpoint
+to return when a headless service is requested. This could be used to route traffic to a local pod, or
+to a more responsive pod. Many other features are in development, and of course as an open source project, we welcome you to suggest and contribute your own features!
+
+The features and differences described above are a few examples. There is much more you can do with CoreDNS.
+You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
+--->
+## 下一步工作
+
+CoreDNS 是一个独立的项目，许多与 Kubernetes 不直接相关的功能正在开发中。但是，其中许多功能将在 Kubernetes 中具有对应的应用。例如，与策略引擎完成集成后，当请求无头服务时，CoreDNS 能够智能地选择返回哪个端点。这可用于将流量分流到到本地 Pod 或响应更快的 Pod。更多的其他功能正在开发中，当然作为一个开源项目，我们欢迎您提出建议并贡献自己的功能特性！
+
+上述特征和差异是几个示例。CoreDNS 还可以做更多的事情。您可以在 [CoreDNS 博客](https://coredns.io/blog) 上找到更多信息。
+
+<!--
+### Get involved with CoreDNS
+
+CoreDNS is an incubated [CNCF](https:://cncf.io) project.
+
+We're most active on Slack (and GitHub):
+--->
+### 参与 CoreDNS
+
+CoreDNS 是一个 [CNCF](https:://cncf.io) 孵化项目。
+
+我们在 Slack（和 GitHub）上最活跃：
+
+- Slack: #coredns on <https://slack.cncf.io>
+- GitHub: <https://github.com/coredns/coredns>
+
+<!--
+More resources can be found:
+--->
+更多资源请浏览：
+
+- Website: <https://coredns.io>
+- Blog: <https://blog.coredns.io>
+- Twitter: [@corednsio](https://twitter.com/corednsio)
+- Mailing list/group: <coredns-discuss@googlegroups.com>
@@ -0,0 +1,219 @@
+---
+title: Raw Block Volume 支持进入 Beta
+date: 2019-03-07
+---
+<!--
+---
+title: Raw Block Volume support to Beta
+date: 2019-03-07
+---
+--->
+
+<!--
+**Authors:**
+Ben Swartzlander (NetApp), Saad Ali (Google)
+
+Kubernetes v1.13 moves raw block volume support to beta. This feature allows persistent volumes to be exposed inside containers as a block device instead of as a mounted file system.
+--->
+**作者：**
+Ben Swartzlander (NetApp), Saad Ali (Google)
+
+Kubernetes v1.13 中对原生数据块卷（Raw Block Volume）的支持进入 Beta 阶段。此功能允许将持久卷作为块设备而不是作为已挂载的文件系统暴露在容器内部。
+
+<!--
+## What are block devices?
+
+Block devices enable random access to data in fixed-size blocks. Hard drives, SSDs, and CD-ROMs drives are all examples of block devices.
+
+Typically persistent storage is implemented in a layered maner with a file system (like ext4) on top of a block device (like a spinning disk or SSD). Applications then read and write files instead of operating on blocks. The operating systems take care of reading and writing files, using the specified filesystem, to the underlying device as blocks.
+
+It's worth noting that while whole disks are block devices, so are disk partitions, and so are LUNs from a storage area network (SAN) device.
+--->
+## 什么是块设备？
+
+块设备允许对固定大小的块中的数据进行随机访问。硬盘驱动器、SSD 和 CD-ROM 驱动器都是块设备的例子。
+
+通常，持久性性存储是在通过在块设备（例如磁盘或 SSD）之上构造文件系统（例如 ext4）的分层方式实现的。这样应用程序就可以读写文件而不是操作数据块进。操作系统负责使用指定的文件系统将文件读写转换为对底层设备的数据块读写。
+
+值得注意的是，整个磁盘都是块设备，磁盘分区也是如此，存储区域网络（SAN）设备中的 LUN 也是一样的。
+
+<!--
+## Why add raw block volumes to kubernetes?
+
+There are some specialized applications that require direct access to a block device because, for example, the file system layer introduces unneeded overhead. The most common case is databases, which prefer to organize their data directly on the underlying storage. Raw block devices are also commonly used by any software which itself implements some kind of storage service (software defined storage systems).
+--->
+## 为什么要将 raw block volume 添加到 kubernetes？
+
+有些特殊的应用程序需要直接访问块设备，原因例如，文件系统层会引入不必要的开销。最常见的情况是数据库，通常会直接在底层存储上组织数据。原生的块设备（Raw Block Devices）还通常由能自己实现某种存储服务的软件（软件定义的存储系统）使用。
+
+<!--
+From a programmer's perspective, a block device is a very large array of bytes, usually with some minimum granularity for reads and writes, often 512 bytes, but frequently 4K or larger.
+
+As it becomes more common to run database software and storage infrastructure software inside of Kubernetes, the need for raw block device support in Kubernetes becomes more important.
+--->
+从程序员的角度来看，块设备是一个非常大的字节数组，具有某种最小读写粒度，通常为 512 个字节，大部分情况为 4K 或更大。
+
+随着在 Kubernetes 中运行数据库软件和存储基础架构软件变得越来越普遍，在 Kubernetes 中支持原生块设备的需求变得越来越重要。
+
+<!--
+## Which volume plugins support raw blocks?
+
+As of the publishing of this blog, the following in-tree volumes types support raw blocks:
+--->
+## 哪些卷插件支持 raw block？
+
+在发布此博客时，以下 in-tree 卷类型支持原生块设备：
+
+- AWS EBS
+- Azure Disk
+- Cinder
+- Fibre Channel
+- GCE PD
+- iSCSI
+- Local volumes
+- RBD (Ceph)
+- Vsphere
+
+<!--
+Out-of-tree [CSI volume drivers](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) may also support raw block volumes. Kubernetes CSI support for raw block volumes is currently alpha. See documentation [here](https://kubernetes-csi.github.io/docs/raw-block.html).
+--->
+Out-of-tree [CSI 卷驱动程序](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) 可能也支持原生数据块卷。Kubernetes CSI 对原生数据块卷的支持目前为 alpha 阶段。参考 [这篇](https://kubernetes-csi.github.io/docs/raw-block.html) 文档。
+
+<!--
+## Kubernetes raw block volume API
+
+Raw block volumes share a lot in common with ordinary volumes. Both are requested by creating `PersistentVolumeClaim` objects which bind to `PersistentVolume` objects, and are attached to Pods in Kubernetes by including them in the volumes array of the `PodSpec`.
+
+There are 2 important differences however. First, to request a raw block `PersistentVolumeClaim`, you must set `volumeMode = "Block"` in the `PersistentVolumeClaimSpec`. Leaving `volumeMode` blank is the same as specifying `volumeMode = "Filesystem"` which results in the traditional behavior. `PersistentVolumes` also have a `volumeMode` field in their `PersistentVolumeSpec`, and `"Block"` type PVCs can only bind to `"Block"` type PVs and `"Filesystem"` PVCs can only bind to `"Filesystem"` PVs.
+--->
+## Kubernetes raw block volume 的 API
+
+原生数据块卷与普通存储卷有很多共同点。两者都通过创建与 `PersistentVolume` 对象绑定的 `PersistentVolumeClaim` 对象发起请求，并通过将它们加入到 `PodSpec` 的 volumes 数组中来连接到 Kubernetes 中的 Pod。
+
+但是有两个重要的区别。首先，要请求原生数据块设备的 `PersistentVolumeClaim` 必须在 `PersistentVolumeClaimSpec` 中设置 `volumeMode = "Block"`。`volumeMode` 为空时与传统设置方式中的指定 `volumeMode = "Filesystem"` 是一样的。`PersistentVolumes` 在其 `PersistentVolumeSpec` 中也有一个 `volumeMode` 字段，`"Block"` 类型的 PVC 只能绑定到 `"Block"` 类型的 PV 上，而`"Filesystem"` 类型的 PVC 只能绑定到 `"Filesystem"` PV 上。
+
+<!--
+Secondly, when using a raw block volume in your Pods, you must specify a `VolumeDevice` in the Container portion of the `PodSpec` rather than a `VolumeMount`. `VolumeDevices` have `devicePaths` instead of `mountPaths`, and inside the container, applications will see a device at that path instead of a mounted file system.
+
+Applications open, read, and write to the device node inside the container just like they would interact with any block device on a system in a non-containerized or virtualized context.
+--->
+其次，在 Pod 中使用原生数据块卷时，必须在 `PodSpec` 的 Container 部分指定一个 `VolumeDevice`，而不是 `VolumeMount`。`VolumeDevices` 具备 `devicePaths` 而不是 `mountPaths`，在容器中，应用程序将看到位于该路径的设备，而不是挂载了的文件系统。
+
+应用程序打开、读取和写入容器内的设备节点，就像它们在非容器化或虚拟环境中与系统上的任何块设备交互一样。
+
+<!--
+## Creating a new raw block PVC
+
+First, ensure that the provisioner associated with the storage class you choose is one that support raw blocks. Then create the PVC.
+--->
+## 创建一个新的原生块设备 PVC
+
+首先，请确保与您选择的存储类关联的驱动支持原生块设备。然后创建 PVC。
+
+```
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: my-pvc
+spec:
+  accessModes:
+    - ReadWriteMany
+  volumeMode: Block
+  storageClassName: my-sc
+  resources:
+    requests:
+    storage: 1Gi
+```
+
+<!--
+## Using a raw block PVC
+
+When you use the PVC in a pod definition, you get to choose the device path for the block device rather than the mount path for the file system.
+--->
+## 使用原生块 PVC
+
+在 Pod 定义中使用 PVC 时，需要选择块设备的设备路径，而不是文件系统的安装路径。
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-pod
+spec:
+  containers:
+    - name: my-container
+      image: busybox
+      command:
+        - sleep
+        - “3600”
+      volumeDevices:
+        - devicePath: /dev/block
+          name: my-volume
+      imagePullPolicy: IfNotPresent
+  volumes:
+    - name: my-volume
+      persistentVolumeClaim:
+        claimName: my-pvc
+```
+
+<!--
+## As a storage vendor, how do I add support for raw block devices to my CSI plugin?
+
+Raw block support for CSI plugins is still alpha, but support can be added today. The [CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md) details how to handle requests for volume that have the `BlockVolume` capability instead of the `MountVolume` capability. CSI plugins can support both kinds of volumes, or one or the other. For more details see [documentation here](https://kubernetes-csi.github.io/docs/raw-block.html).
+--->
+## 作为存储供应商，我如何在 CSI 插件中添加对原生块设备的支持？
+
+CSI 插件的原生块支持仍然是 alpha 版本，但是现在可以改进了。[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md) 详细说明了如何处理具有 `BlockVolume` 能力而不是 `MountVolume` 能力的卷的请求。CSI 插件可以支持两种类型的卷，也可以支持其中一种或另一种。更多详细信息，请查看 [这个文档](https://kubernetes-csi.github.io/docs/raw-block.html)。
+
+
+<!--
+## Issues/gotchas
+
+Because block devices are actually devices, it’s possible to do low-level actions on them from inside containers that wouldn’t be possible with file system volumes. For example, block devices that are actually SCSI disks support sending SCSI commands to the device using Linux ioctls.
+--->
+## 问题/陷阱
+
+由于块设备实质上还是设备，因此可以从容器内部对其进行底层操作，而文件系统的卷则无法执行这些操作。例如，实际上是块设备的 SCSI 磁盘支持使用 Linux ioctl 向设备发送 SCSI 命令。
+
+<!--
+By default, Linux won’t allow containers to send SCSI commands to disks from inside containers though. In order to do so, you must grant the `SYS_RAWIO` capability to the container security context to allow this. See documentation [here](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container).
+
+Also, while Kubernetes is guaranteed to deliver a block device to the container, there’s no guarantee that it’s actually a SCSI disk or any other kind of disk for that matter. The user must either ensure that the desired disk type is used with his pods, or only deploy applications that can handle a variety of block device types.
+--->
+默认情况下，Linux 不允许容器将 SCSI 命令从容器内部发送到磁盘。为此，必须向容器安全层级认证 `SYS_RAWIO` 功能实现这种行为。请参阅 [这篇](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) 文档。
+
+另外，尽管 Kubernetes 保证可以将块设备交付到容器中，但不能保证它实际上是 SCSI 磁盘或任何其他类型的磁盘。用户必须确保所需的磁盘类型与 Pod 一起使用，或只部署可以处理各种块设备类型的应用程序。
+
+<!--
+## How can I learn more?
+
+Check out additional documentation on the snapshot feature here: [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+
+How do I get involved?
+
+Join the Kubernetes storage SIG and the CSI community and help us add more great features and improve existing ones like raw block storage!
+--->
+## 如何学习更多？
+
+在此处查看有关 snapshot 功能的其他文档：[Raw Block Volume 支持](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+
+如何参与进来？
+
+加入 Kubernetes 存储 SIG 和 CSI 社区，帮助我们添加更多出色的功能并改进现有功能，就像 raw block 存储一样！
+
+https://github.com/kubernetes/community/tree/master/sig-storage
+https://github.com/container-storage-interface/community/blob/master/README.md
+
+<!--
+Special thanks to all the contributors who helped add block volume support to Kubernetes including:
+--->
+特别感谢所有为 Kubernetes 增加 block volume 支持的贡献者，包括：
+
+- Ben Swartzlander (https://github.com/bswartz)
+- Brad Childs (https://github.com/childsb)
+- Erin Boyd (https://github.com/erinboyd)
+- Masaki Kimura (https://github.com/mkimuram)
+- Matthew Wong (https://github.com/wongma7)
+- Michelle Au (https://github.com/msau42)
+- Mitsuhiro Tanino (https://github.com/mtanino)
+- Saad Ali (https://github.com/saad-ali)
@@ -265,7 +265,7 @@ The implementation of the four shared controllers highlighted above, and some sc
 For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
 -->

-有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
+有关开发插件的更多信息，请参阅[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。

 <!--
 ## Authorization
@@ -494,7 +494,7 @@ Complete instructions for configuring and running the CCM are provided
 [here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
 -->

-[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
+[这里](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。



@@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
 Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。
 apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求，
-并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
+并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。
 一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
-特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/authentication/#anonymous-requests)
-或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
+特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。

 <!--
 Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
@@ -168,5 +168,5 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。

-请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
+请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
 在你的集群中配置 Konnectivity 服务。
@@ -252,7 +252,7 @@ kubectl describe node <节点名称>

 The usage of these fields varies depending on your cloud provider or bare metal configuration.
 -->
-### 地址  {#addresses}
+### 地址   {#addresses}

 这些字段的用法取决于你的云服务商或者物理机配置。

@@ -103,7 +103,7 @@ Before choosing a guide, here are some considerations:
 * [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
 * [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
 * [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
-* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
+* [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
 * [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
 * [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
 * [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
@@ -274,7 +274,7 @@ Using a node-level logging agent is the most common and encouraged approach for
 Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
 -->
 Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
-[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
+[Stackdriver 日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
 适用于 Google Cloud Platform，和
 [Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。
 你可以在专门的文档中找到更多的信息和说明。
@@ -447,7 +447,7 @@ which uses fluentd as a logging agent. Here are two configuration files that
 you can use to implement this approach. The first file contains
 a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
 -->
-例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)，
+例如，你可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，
 它使用 fluentd 作为日志记录代理。
 以下是两个可用于实现此方法的配置文件。
 第一个文件包含配置 fluentd 的
@@ -531,7 +531,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec

 Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
 -->
-## 就地更新资源
+## 就地更新资源  {#in-place-updates-of-resources}

 有时，有必要对你所创建的资源进行小范围、无干扰地更新。

@@ -219,6 +219,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

 * 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
 * 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
-* 了解有关 [Kubernetes 指标弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
+* 了解有关 [Kubernetes 指标弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )


@@ -473,7 +473,7 @@ you can create the Secret on the API server with `kubectl apply`.
 -->
 #### 从生成器创建 Secret

-Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)。
+Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)。
 Kustomize 提供资源生成器创建 Secret 和 ConfigMaps。
 Kustomize 生成器要在当前目录内的 `kustomization.yaml` 中指定。
 生成 Secret 之后，使用 `kubectl apply` 在 API 服务器上创建对象。
@@ -89,34 +89,34 @@ Instead, specify a meaningful tag such as `v1.42.0`.
 <!--
 ## Updating Images

-The default pull policy is `IfNotPresent` which causes the Kubelet to skip
+The default pull policy is `IfNotPresent` which causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
 pulling an image if it already exists. If you would like to always force a pull,
 you can do one of the following:
-->
-## 更新镜像  {#updating-images}

-默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，`kubelet` 将不再去拉取镜像。
-如果希望强制总是拉取镜像，你可以执行以下操作之一：
-
-<!--
 - set the `imagePullPolicy` of the container to `Always`.
 - omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
 - omit the `imagePullPolicy` and the tag for the image to use.
 - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
+
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
 -->
+## 更新镜像  {#updating-images}
+
+默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 将不再去拉取镜像。
+如果希望强制总是拉取镜像，你可以执行以下操作之一：
+
 - 设置容器的 `imagePullPolicy` 为 `Always`。
 - 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签。
 - 省略 `imagePullPolicy` 和要使用的镜像标签。
 - 启用 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
  准入控制器（Admission Controller）。

-<!--
-When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
-->
 如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。

 <!--
-## Building Multi-architecture Images with Manifests
+## Multi-architecture Images with Manifests

 As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.

@@ -139,27 +139,27 @@ YAML 文件也能兼容。
 <!--
 ## Using a Private Registry

-Private registries may require keys to read images from them.
+Private registries may require keys to read images from them.  
 Credentials can be provided in several ways:
 -->
-## 使用私有仓库  {#using-a-private-registry}
+## 使用私有仓库   {#using-a-private-registry}

 从私有仓库读取镜像时可能需要密钥。
-凭据信息可以用以下方式提供:
+凭证可以用以下方式提供:

 <!--
- Configuring Nodes to Authenticate to a Private Registry
-  - all pods can read any configured private registries
-  - requires node configuration by cluster administrator
- Pre-pulled Images
-  - all pods can use any images cached on a node
-  - requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
-  - only pods which provide own keys can access the private registry
- Vendor-specific or local extensions
-  - if you're using a custom node configuration, you (or your cloud
-    provider) can implement your mechanism for authenticating the node
-    to the container registry.
+  - Configuring Nodes to Authenticate to a Private Registry
+    - all pods can read any configured private registries
+    - requires node configuration by cluster administrator
+  - Pre-pulled Images
+    - all pods can use any images cached on a node
+    - requires root access to all nodes to setup
+  - Specifying ImagePullSecrets on a Pod
+    - only pods which provide own keys can access the private registry
+  - Vendor-specific or local extensions
+    - if you're using a custom node configuration, you (or your cloud
+      provider) can implement your mechanism for authenticating the node
+      to the container registry.
 -->
 - 配置节点向私有仓库进行身份验证
  - 所有 Pod 均可读取任何已配置的私有仓库
@@ -174,9 +174,9 @@ Credentials can be provided in several ways:
    向容器仓库认证的机制

 <!--
-These options are explained in more detail below.
+These options are explaind in more detail below.
 -->
-下面将详细描述每一种方案。
+下面将详细描述每一项。

 <!--
 ### Configuring Nodes to authenticate to a Private Registry
@@ -299,21 +299,6 @@ EOF
 pod/private-image-test-1 created
 ```

-<!--
-If everything is working, then, after a few moments, you can run:
-->
-如果一切正常，一段时间后，可以运行:
-
-```shell
-kubectl logs private-image-test-1
-```
-
-并看到命令输出为：
-
-```
-SUCCESS
-```
-
 <!--
 If you suspect that the command failed, you can run:
 -->
@@ -388,7 +373,7 @@ All pods will have read access to any pre-pulled images.
 <!--
 ### Specifying ImagePullSecrets on a Pod
 -->
-### 为 Pod 设置 ImagePullSecrets
+### 在 Pod 上指定 ImagePullSecrets   {#specifying-imagepullsecrets-on-a-pod}

 <!--
 This is the recommended approach to run containers based on images
@@ -408,9 +393,9 @@ Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。

 Run the following command, substituting the appropriate uppercase values:
 -->
-#### 创建包含 Docker 配置的Secret
+#### 使用 Docker Config 创建 Secret   {#creating-a-secret-with-docker-config}

-将大写字母代替为合适的值，运行以下命令：
+运行以下命令，将大写字母代替为合适的值：

 ```shell
 kubectl create secret docker-registry <名称> \
@@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
 新的集群配置是可复用的，并且可以当作应用程序来管理。
 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
-一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
+一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。

 <!--
@@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/

 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。

-关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。

 <!--
 ### Combining New APIs with Automation
@@ -307,7 +307,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
 Kubernetes 提供若干内置的身份认证方法。
 它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
 某个远程服务（Webhook）来执行验证操作。
-所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
+所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/)
 中详细论述。

 <!--
@@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证    {#authentication}

-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
+[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
 的头部或证书映射到发出该请求的客户端的用户名。

 Kubernetes 提供若干种内置的认证方法，以及
-[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
 方法以备内置方法无法满足你的要求。

 <!--
@@ -443,7 +443,7 @@ the nodes chosen for a pod.
 * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
 * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
 -->
-* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 进一步了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 进一步了解基础设施扩展
  * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@@ -91,6 +91,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
  了解如何在自己的环境中启用聚合器。
 * 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
  开始使用聚合层。
-* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
 * 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范

@@ -61,7 +61,7 @@ to advertise that the node has 2 “Foo” devices installed and available.
 * 设备插件的 Unix 套接字。
 * 设备插件的 API 版本。
 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循
-  [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)，
+  [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
  类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）

 成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
@@ -378,8 +378,8 @@ Here are some examples of device plugin implementations:
 * Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
 -->
 * 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
-* 查看在上如何[公布节点上的扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)
+* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
 * 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 
-* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/)
+* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)


@@ -89,7 +89,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
 它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
 并以与应用程序相同的方式进行管理。
 而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
-[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
+[支持政策](/docs/reference/using-api/deprecation-policy/)。
 出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。

 <!--
@@ -243,7 +243,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
 不要使用自定义资源作为应用、用户或者监控数据的数据存储。

 有关自定义资源的更多信息，请查看
-[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。

 <!--
 ### Combining New APIs with Automation
@@ -288,7 +288,7 @@ Kubernetes has several built-in authentication methods that it supports. It can

 Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
 中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
-[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
+[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。

 <!--
 ### Authentication
@@ -299,11 +299,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证  {#authentication}

-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
+[身份认证](/docs/reference/access-authn-authz/authentication/)
 将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。

 Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
-[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
+[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。

 <!--
 ### Authorization
@@ -420,7 +420,7 @@ the nodes chosen for a pod.
 * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
 * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
 -->
-* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 详细了解基础设施扩展
  * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@@ -20,7 +20,7 @@ Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-con
 -->

 Operator 是 Kubernetes 的扩展软件，它利用
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
 Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。


@@ -66,7 +66,7 @@ Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes

 Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
 Operator 是 Kubernetes API 的客户端，充当
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。

 <!--
 ## An example Operator {#example}
@@ -212,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
 -->

-* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
 * 借助已有的工具来编写您自己的 Operator，例如：
  * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
@@ -100,8 +100,6 @@ These controllers include:
 <!--
 ### cloud-controller-manager

-{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
-
 The cloud-controller-manager only runs controllers that are specific to your cloud provider.
 If you are running Kubernetes on your own premises, or in a learning environment inside your
 own PC, the cluster does not have a cloud controller manager.
@@ -118,6 +116,8 @@ The following controllers can have cloud provider dependencies:
 -->
 ### cloud-controller-manager

+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
 `cloud-controller-manager` 进运行特定于云平台的控制回路。
 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
 所部属的环境中不需要云控制器管理器。
@@ -57,7 +57,7 @@ Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题

 一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
 删除资源或者字段则要遵从
-[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
+[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。

 关于什么是兼容性的变更，如何变更 API 等详细信息，可参考
 [API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
@@ -281,9 +281,9 @@ There are two paths to extending the API with [custom resources](/docs/concepts/
   to make it seamless for clients.
 -->
 有两种途径来扩展 Kubernetes API 以支持
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：

-1. 使用 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
+1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
   你可以用声明式方式来定义 API 如何提供你所选择的资源 API。 

 1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
@@ -325,7 +325,7 @@ Disadvantages compared to imperative object configuration:
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 -->
 - [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [使用对象配置管理 Kubernetes 对象（命令式）](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [使用对象配置管理 Kubernetes 对象（命令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [使用对象配置管理 Kubernetes 对象（声明式）](/docs/tasks/manage-kubernetes-objects/declarative-config/)
 - [使用 Kustomize（声明式）管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
@@ -696,7 +696,7 @@ several security mechanisms.
 See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
 -->
 更多的示例可参考
-[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
+[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。

 <!--
 ## Policy Reference
@@ -1219,7 +1219,7 @@ By default, all safe sysctls are allowed.

 - Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
 -->
- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
+- 参阅[Pod 安全标准](/docs/concepts/security/pod-security-standards/)
  了解策略建议。
 - 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。

@@ -190,7 +190,7 @@ In addition, you can limit consumption of storage resources based on associated
 -->
 ## 存储资源配额

-用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)总量进行限制。
+用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。

 此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。

@@ -205,9 +205,9 @@ In addition, you can limit consumption of storage resources based on associated
 | 资源名称 | 描述 |
 | --------------------- | ----------------------------------------------------------- |
 | `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 |
-| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
+| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
 | `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |

 <!--
 For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
@@ -307,7 +307,7 @@ The following types are supported:
 | 资源名称 | 描述 |
 | ------------------------------- | ------------------------------------------------- |
 | `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 |
-| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
+| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
 | `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true |
 | `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 |
 | `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 |
@@ -387,7 +387,7 @@ Pods can be created at a specific [priority](/docs/concepts/configuration/pod-pr
 You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
 field in the quota spec.
 -->
-Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
+Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
 通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。

 <!--
@@ -520,6 +520,6 @@ arbitrary tolerations to DaemonSets.
 * Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
 -->
 * 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
-* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/)


@@ -22,7 +22,7 @@ automatically provisions storage when it is requested by users.
 -->
 动态卷供应允许按需创建存储卷。
 如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
-然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
+然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。

 <!-- body -->
@@ -199,7 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
 Pods are scheduled. This can be accomplished by setting the [Volume Binding
 Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
 -->
-在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
+在[多区域](/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
 单区域存储后端应该被供应到 Pod 被调度到的区域。
 这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。

@@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
 [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
 -->
 本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
-[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
+[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。

 <!-- body -->

@@ -67,7 +67,7 @@ for details.
 -->
 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
 更多详情请参阅
-[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
 The `volumeBindingMode` field controls when [volume binding and dynamic
 provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
 -->
-`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
+`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
 应该发生在什么时候。

 <!--
@@ -18,7 +18,7 @@ weight: 20
 In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
 -->
 在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
-的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
+的 [持久卷](/docs/concepts/storage/persistent-volumes/)。

 <!-- body -->

@@ -260,5 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
 For more details, see
 [Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
 -->
-更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
+更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。

@@ -916,7 +916,7 @@ Watch out when using this type of volume, because:
 * 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
 * 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。
 * 基础主机上创建的文件或目录只能由 root 用户写入。您需要在
-[特权容器](/zh/docs/tasks/configure-pod-container/security-context/)
+[特权容器](/docs/tasks/configure-pod-container/security-context/)
 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。

 <!--
@@ -1190,7 +1190,7 @@ A `persistentVolumeClaim` volume is used to mount a
 way for users to "claim" durable storage (such as a GCE PersistentDisk or an
 iSCSI volume) without knowing the details of the particular cloud environment.
 -->
-`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
+`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
 持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。

 <!--
@@ -1198,7 +1198,7 @@ See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/)
 details.
 -->

-更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)
+更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)

 ### projected {#projected}

@@ -1887,7 +1887,7 @@ specification, and to select the type of media to use, for clusters that have
 several media types.
 -->
 将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用
-[resource](/zh/docs/concepts/configuration/manage-compute-resources-containers/)
+[resource](/zh/docs/concepts/configuration/manage-resources-containers/)
 规约来请求一定量的空间，
 并且能够为具有多种介质类型的集群选择要使用的介质类型。

@@ -2115,7 +2115,7 @@ CSI块卷支持功能已启用，但默认情况下启用。必须为此功能
 Learn how to
 [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
 -->
-学习怎样[安装您的带有块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
+学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。

 <!--
 #### CSI ephemeral volumes
@@ -20,7 +20,7 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
 -->
-_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
+_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/job/)。

 一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。
 它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，
@@ -136,9 +136,8 @@ For example, suppose a CronJob is set to schedule a new Job every one minute beg
 `startingDeadlineSeconds` field is not set. If the CronJob controller happens to
 be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
 -->
-例如，假设一个 CronJob 被设置为 `08:30:00` 准时开始，它的 `startingDeadlineSeconds`
-字段被设置为 10，如果在 `08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。
-如果觉得晚些开始比没有启动好，那请设置一个较长的 `startingDeadlineSeconds`。
+例如，假设一个 CronJob 被设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job，并且它的 `startingDeadlineSeconds` 字段
+未被设置。如果 CronJob 控制器从 `08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动，因为其错过的调度次数超过了100。

 <!--
 To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
@@ -199,7 +199,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
 -->
 ### 仅在某些节点上运行 Pod

-如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
 如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。

 <!--
@@ -232,7 +232,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。

 * Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
  DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
-* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
  由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
  的情况下制定调度决策。

@@ -21,7 +21,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).

 -->
-一个 _Deployment_ 控制器为 [Pods](/docs/concepts/workloads/pods/pod/)和 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
+一个 _Deployment_ 控制器为 [Pods](/zh/docs/concepts/workloads/pods/)和 [ReplicaSets](/zh/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。

 <!--

@@ -1030,7 +1030,7 @@ deployment.apps/nginx-deployment scaled
 in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
 Pods you want to run based on the CPU utilization of your existing Pods.
 -->
-假设启用[水平自动缩放 Pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
+假设启用[水平自动缩放 Pod](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
 要基于现有 Pods 的 CPU 利用率运行的 Pods。

 ```shell
@@ -1726,7 +1726,7 @@ thus that Deployment will not be able to roll back.
 can create multiple Deployments, one for each release, following the canary pattern described in
 [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
 -->
-如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
+如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。

 <!--
 ## Writing a Deployment Spec
@@ -1738,7 +1738,7 @@ can create multiple Deployments, one for each release, following the canary patt
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
 configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
 -->
-同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
+同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。

 <!--
 A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -1759,7 +1759,7 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
 The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
 `apiVersion` or `kind`.
 -->
-`.spec.template` 是一个 [Pod 示例](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
+`.spec.template` 是一个 [Pod 示例](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。

 <!--
 In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
@@ -1768,10 +1768,10 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
 除了 Pod 的必填字段外， Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。对于标签，请确保不要与其他控制器重叠。请参考[选择器](#selector))。

 <!--
- Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
+ Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/#restart-policy) equal to `Always` is
 allowed, which is the default if not specified.
 -->
-只有 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
+只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。

 <!--
 ### Replicas
@@ -1792,7 +1792,7 @@ allowed, which is the default if not specified.
 `.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this Deployment.
 -->
-`.spec.selector` 是指定本次 Deployment  Pods [标签选择器](/docs/concepts/overview/working-with-objects/labels/)的必要字段。
+`.spec.selector` 是指定本次 Deployment  Pods [标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)的必要字段。

 <!--
 `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -1857,7 +1857,7 @@ the default value.
 fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
 the rolling update process.
 -->
- Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取 [滚动更新](/docs/tasks/run-application/rolling-update-replication-controller/)的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
+ Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取滚动更新的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。

 <!--
 ##### Max Unavailable
@@ -1932,7 +1932,7 @@ created Pod should be ready without any of its containers crashing, for it to be
 This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
 a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 -->
-`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。

 <!--
 ### Rollback To
@@ -812,7 +812,7 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
 -->
 ### 副本控制器    {#replication-controller}

-Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。
+Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
 副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
 Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。

@@ -81,9 +81,9 @@ their ReplicaSets.
 -->
 ## 怎样使用 ReplicaSet   {#how-to-use-a-replicaset}

-大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
+大多数支持 Replication Controllers 的[`kubectl`](/zh/docs/reference/kubectl/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。

-虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
+虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
 当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。

 <!--
@@ -171,7 +171,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib

 ## 编写 ReplicaSet Spec

-与所有其他 Kubernetes API 对象一样，ReplicaSet  也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。
+与所有其他 Kubernetes API 对象一样，ReplicaSet  也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/zh/docs/concepts/overview/working-with-objects/object-management/)。

 ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。

@@ -195,15 +195,15 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.

 ### Pod 模版

-`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
+`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。

 除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。

 对于标签，请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。

-对于 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
+对于 [重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.

-对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。
+对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker 去执行。

 <!--
 ### Pod Selector
@@ -221,7 +221,7 @@ In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the curren

 ### Pod 选择器

-`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
+`.spec.selector` 字段是[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。

 `.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。

@@ -279,7 +279,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
 ### 删除 ReplicaSet 和它的 Pod

 要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
-默认情况下，[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
+默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。

 当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：

@@ -405,9 +405,9 @@ application using a Deployment, please read [Run a Stateless Application Using a

 ### Deployment （推荐）

-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
+[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
 如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
-有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
+有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。

 <!--
 ### Bare Pods
@@ -431,7 +431,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o

 ### Job

-使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
+使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。

 <!--
 ### DaemonSet
@@ -444,7 +444,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.

 ### DaemonSet

-对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
+对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
 这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。


@@ -211,7 +211,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
 只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。

 对于本地容器重启，ReplicationController 委托给节点上的代理，
-例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。
+例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。

 <!--
 ### Labels on the ReplicationController
@@ -546,7 +546,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
 ### Job

 对于预期会自行终止的 Pod (即批处理任务)，使用
-[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
+[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。

 <!--
 ### DaemonSet
@@ -140,7 +140,7 @@ spec:
 * 名为 `nginx` 的 Headless Service 用来控制网络域名。
 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
 * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
-  [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+  [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。

 <!--
 ## Pod Selector
@@ -232,7 +232,7 @@ This must be done manually.
 -->
 ### 稳定的存储  {#stable-storage}

-Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
+Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
 在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 
@@ -254,6 +254,8 @@ the StatefulSet.

 <!--
 ## Deployment and Scaling Guarantees
+-->
+## 部署和扩缩保证  {#deployment-and-scaling-guarantees}

 * For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
 * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
@@ -48,7 +48,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the

 TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
-[示例](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 所示。

 <!--
@@ -286,7 +286,7 @@ PodTemplates are specifications for creating Pods, and are included in workload

 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
-[Job](/zh/docs/concepts/workloads/containers/job/) 和
+[Job](/zh/docs/concepts/workloads/controllers/job/) 和
 [DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。

 <!--
@@ -431,7 +431,7 @@ Processes within a privileged container get almost the same privileges that are
 ## 容器的特权模式     {#rivileged-mode-for-containers}

 Pod 中的任何容器都可以使用容器规约中的
-[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
+[安全性上下文](/docs/tasks/configure-pod-container/security-context/)中的
 `privileged` 参数启用特权模式。
 这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
 的容器很有用。
@@ -516,7 +516,7 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
 或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
 封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：

-  * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+  * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
  * [Borg](https://research.google.com/pubs/pub43438.html)
  * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
  * [Omega](https://research.google/pubs/pub41684/)
@@ -147,7 +147,7 @@ or across zones (if using a
  和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
 - 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
  [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
-  （如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
+  （如果使用[多区域集群](/docs/setup/best-practices/multiple-zones/)）扩展应用程序。

 <!--
 The frequency of voluntary disruptions varies.  On a basic Kubernetes cluster, there are
@@ -204,7 +204,7 @@ instead of directly deleting pods or deployments.  Examples are the `kubectl dra
 and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
 -->
 集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口
-（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
+（通过调用[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
 而不是直接删除 Pod 或 Deployment。

 <!--
@@ -267,7 +267,7 @@ hornoring the
 `terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
 -->
 当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
-[终止](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
+[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
 中的 `terminationGracePeriodSeconds` 配置值。

@@ -497,7 +497,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
  including steps to maintain its availability during the rollout.
 -->
 * 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
-* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。
+* 进一步了解[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。
 * 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
  的过程，包括如何在其进程中维持应用的可用性

@@ -34,7 +34,7 @@ feature could change significantly in the future or be removed entirely.
 {{< warning >}}
 临时容器处于早期的 alpha 阶段，不适用于生产环境集群。
 应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
-根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
+根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)，
 此 alpha 功能将来可能发生重大变化或被完全删除。
 {{< /warning >}}

@@ -1017,7 +1017,7 @@ for more information.
 -->

 该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 pod。
-另请参见 [PodPreset 概念](/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset) 获取详情。
+另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) 获取详情。

 ### PodSecurityPolicy {#podsecuritypolicy}

@@ -576,7 +576,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `EnableAggregatedDiscoveryTimeout` （ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。
 - `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
 - `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。
- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
 - `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅 [调整使用中的 PersistentVolumeClaim 的大小](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
 - `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
 - `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
@@ -650,7 +650,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。
 - `PodOverhead`：启用 [PodOverhead](/docs/concepts/configuration/pod-overhead/) 特性以解决 Pod 开销。
 - `PodPriority`：根据[优先级](/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
+- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。

 <!--
 - `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
@@ -710,7 +710,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。
 - `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。
 - `ServiceTopology`: 启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见[Service 拓扑](https://kubernetes.io/zh/docs/concepts/services-networking/service-topology/)
- `StartupProbe`：在 kubelet 中启用 [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
+- `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
 - `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。

 <!--
@@ -2,7 +2,7 @@
 title: 附加组件
 id: addons
 date: 2019-12-15
-full_link: /docs/concepts/cluster-administration/addons/
+full_link: /zh/docs/concepts/cluster-administration/addons/
 short_description: >
  扩展 Kubernetes 功能的资源。

@@ -17,7 +17,7 @@ tags:
 title: Add-ons
 id: addons
 date: 2019-12-15
-full_link: /docs/concepts/cluster-administration/addons/
+full_link: /zh/docs/concepts/cluster-administration/addons/
 short_description: >
  Resources that extend the functionality of Kubernetes.

@@ -2,7 +2,7 @@
 title: 准入控制器
 id: admission-controller
 date: 2019-06-28
-full_link: /docs/reference/access-authn-authz/admission-controllers/
+full_link: /zh/docs/reference/access-authn-authz/admission-controllers/
 short_description: >
 在对象持久化之前拦截 Kubernetes Api 服务器请求的一段代码
 aka:
@@ -16,7 +16,7 @@ tags:
 title: Admission Controller
 id: admission-controller
 date: 2019-06-28
-full_link: /docs/reference/access-authn-authz/admission-controllers/
+full_link: /zh/docs/reference/access-authn-authz/admission-controllers/
 short_description: >
  A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.

@@ -2,7 +2,7 @@
 title: 聚合层
 id: aggregation-layer
 date: 2018-10-08
-full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+full_link: /zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
 short_description: >
  聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。

@@ -18,7 +18,7 @@ tags:
 title: Aggregation Layer
 id: aggregation-layer
 date: 2018-10-08
-full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+full_link: /zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
 short_description: >
  The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.

@@ -2,7 +2,7 @@
 title: 注解
 id: annotation
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /zh/docs/concepts/overview/working-with-objects/annotations/
 short_description: >
  注解是以键值对的形式给资源对象附加随机的无法标识的元数据。

@@ -16,7 +16,7 @@ tags:
 title: Annotation
 id: annotation
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /zh/docs/concepts/overview/working-with-objects/annotations/
 short_description: >
  A key-value pair that is used to attach arbitrary non-identifying metadata to objects.

@@ -2,7 +2,7 @@
 title: API Group
 id: api-group
 date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups
 short_description: >
  Kubernetes API 中的一组相关路径

@@ -16,7 +16,7 @@ tags:
 title: API Group
 id: api-group
 date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups
 short_description: >
  A set of related paths in the Kubernetes API.

@@ -2,7 +2,7 @@
 title: 证书
 id: certificate
 date: 2018-04-12
-full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
+full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/
 short_description: >
  证书是个安全加密文件，用来确认对 Kubernetes 集群访问的合法性。

@@ -16,7 +16,7 @@ tags:
 title: Certificate
 id: certificate
 date: 2018-04-12
-full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
+full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/
 short_description: >
  A cryptographically secure file used to validate access to the Kubernetes cluster.

@@ -2,7 +2,7 @@
 title: 云控制器管理器
 id: cloud-controller-manager
 date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/running-cloud-controller/
+full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/
 short_description: >
  云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。

@@ -18,7 +18,7 @@ tags:
 title: Cloud Controller Manager
 id: cloud-controller-manager
 date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/running-cloud-controller/
+full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/
 short_description: >
  Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud.

@@ -2,7 +2,7 @@
 title: 云供应商
 id: cloud-provider
 date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
+full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
 short_description: >
  云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。

@@ -16,7 +16,7 @@ tags:
 title: Cloud Provider
 id: cloud-provider
 date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
+full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
 short_description: >
  Cloud provider is a company that offers cloud computing platform that can run Kubernetes clusters.

@@ -2,7 +2,7 @@
 title: CNI (容器网络接口)
 id: cni
 date: 2018-05-25
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
 short_description: >
    容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。

@@ -17,7 +17,7 @@ tags:
 title: CNI (Container network interface)
 id: cni
 date: 2018-05-25
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
 short_description: >
    Container network interface (CNI) plugins are a type of Network plugin that adheres to the appc/CNI specification.

@@ -2,7 +2,7 @@
 title: ConfigMap
 id: configmap
 date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/
+full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/
 short_description: >
  ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。
   
@@ -16,7 +16,7 @@ tags:
 title: ConfigMap
 id: configmap
 date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/
+full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/
 short_description: >
  An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or config files in a volume.

@@ -2,7 +2,7 @@
 title: 容器生命周期钩子
 id: container-lifecycle-hooks
 date: 2018-10-08
-full_link: /docs/concepts/containers/container-lifecycle-hooks/
+full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/
 short_description: >
  生命周期钩子暴露容器管理生命周期中的事件，允许用户在事件发生时运行代码。

@@ -15,7 +15,7 @@ tags:
 title: Container Lifecycle Hooks
 id: container-lifecycle-hooks
 date: 2018-10-08
-full_link: /docs/concepts/containers/container-lifecycle-hooks/
+full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/
 short_description: >
  The lifecycle hooks expose events in the container management lifecycle and let the user run code when the events occur.

@@ -2,7 +2,7 @@
 title: 容器
 id: container
 date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers
 short_description: >
  容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。

@@ -17,7 +17,7 @@ tags:
 title: Container
 id: container
 date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers
 short_description: >
  A lightweight and portable executable image that contains software and all of its dependencies.

@@ -2,7 +2,7 @@
 title: 容器运行时接口 (CRI)
 id: cri
 date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /zh/docs/concepts/overview/components/#container-runtime
 short_description: >
  一组与 kubelet 集成的容器运行时 API 

@@ -18,7 +18,7 @@ tags:
 title: Container runtime interface (CRI)
 id: cri
 date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /zh/docs/concepts/overview/components/#container-runtime
 short_description: >
    An API for container runtimes to integrate with kubelet

@@ -2,7 +2,7 @@
 title: CronJob
 id: cronjob
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/
 short_description: >
  管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。

@@ -17,7 +17,7 @@ tags:
 title: CronJob
 id: cronjob
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/
 short_description: >
  Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.

@@ -2,7 +2,7 @@
 title: 容器存储接口 (CSI)
 id: csi
 date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#csi
+full_link: /zh/docs/concepts/storage/volumes/#csi
 short_description: >
    容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。

@@ -17,7 +17,7 @@ tags:
 title: Container Storage Interface (CSI)
 id: csi
 date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#csi
+full_link: /zh/docs/concepts/storage/volumes/#csi
 short_description: >
    The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers.

@@ -2,7 +2,7 @@
 title: DaemonSet
 id: daemonset
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /zh/docs/concepts/workloads/controllers/daemonset/
 short_description: >
  确保 Pod 的副本在集群中的一组节点上运行。

@@ -18,7 +18,7 @@ tags:
 title: DaemonSet
 id: daemonset
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /zh/docs/concepts/workloads/controllers/daemonset/
 short_description: >
  Ensures a copy of a Pod is running across a set of nodes in a cluster.

@@ -2,7 +2,7 @@
 title: Deployment
 id: deployment
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /zh/docs/concepts/workloads/controllers/deployment/
 short_description: >
  Deployment 是管理应用副本的 API 对象。

@@ -18,7 +18,7 @@ tags:
 title: Deployment
 id: deployment
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /zh/docs/concepts/workloads/controllers/deployment/
 short_description: >
  An API object that manages a replicated application.

@@ -2,7 +2,7 @@
 title: 驱动插件
 id: device-plugin
 date: 2019-02-02
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
 short_description: >
  在 Kubernetes 中运行的容器提供对供应商特定资源的访问权限。
 aka:
@@ -15,7 +15,7 @@ tags:
 title: Device Plugin
 id: device-plugin
 date: 2019-02-02
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
 short_description: >
  Containers running in Kubernetes that provide access to a vendor specific resource.
 aka:
@@ -2,7 +2,7 @@
 title: 干扰
 id: disruption
 date: 2019-09-10
-full_link: /docs/concepts/workloads/pods/disruptions/
+full_link: /zh/docs/concepts/workloads/pods/disruptions/
 short_description: >
   导致 Pod 服务停止的事件。
 aka:
@@ -17,7 +17,7 @@ tags:
 title: Disruption
 id: disruption
 date: 2019-09-10
-full_link: /docs/concepts/workloads/pods/disruptions/
+full_link: /zh/docs/concepts/workloads/pods/disruptions/
 short_description: >
  An event that leads to Pod(s) going out of service
 aka:
@@ -2,7 +2,7 @@
 title: docker
 id: docker
 date: 2018-04-12
-full_link: /docs/reference/kubectl/docker-cli-to-kubectl/
+full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/
 short_description: >
  Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术。

@@ -16,7 +16,7 @@ tags:
 title: docker
 id: docker
 date: 2018-04-12
-full_link: /docs/reference/kubectl/docker-cli-to-kubectl/
+full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/
 short_description: >
  Docker is a software technology providing operating-system-level virtualization also known as containers.

@@ -2,7 +2,7 @@
 title: 动态卷供应
 id: dynamicvolumeprovisioning
 date: 2018-04-12
-full_link: /docs/concepts/storage/dynamic-provisioning
+full_link: /zh/docs/concepts/storage/dynamic-provisioning/
 short_description: >
  允许用户请求自动创建存储卷。

@@ -17,7 +17,7 @@ tags:
 title: Dynamic Volume Provisioning
 id: dynamicvolumeprovisioning
 date: 2018-04-12
-full_link: /docs/concepts/storage/dynamic-provisioning
+full_link: /zh/docs/concepts/storage/dynamic-provisioning/
 short_description: >
  Allows users to request automatic creation of storage  Volumes.

@@ -2,7 +2,7 @@
 title: 端点切片
 id: endpoint-slice
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/endpoint-slices/
+full_link: /zh/docs/concepts/services-networking/endpoint-slices/
 short_description: >
  一种将网络端点与 Kubernetes 资源组合在一起的方法。

@@ -17,7 +17,7 @@ tags:
 title: Endpoint Slice
 id: endpoint-slice
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/endpoint-slices/
+full_link: /zh/docs/concepts/services-networking/endpoint-slices/
 short_description: >
  A way to group network endpoints together with Kubernetes resources.

@@ -2,7 +2,7 @@
 title: 临时容器
 id: ephemeral-container
 date: 2019-08-26
-full_link: /docs/concepts/workloads/pods/ephemeral-containers/
+full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/
 short_description: >
  您可以在 Pod 中临时运行的一种容器类型
 aka:
@@ -16,7 +16,7 @@ tags:
 title: Ephemeral Container
 id: ephemeral-container
 date: 2019-08-26
-full_link: /docs/concepts/workloads/pods/ephemeral-containers/
+full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/
 short_description: >
  A type of container type that you can temporarily run inside a Pod

@@ -2,7 +2,7 @@
 title: etcd
 id: etcd
 date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/
 short_description: >
  etcd 是兼具一致性和高可用性的键值数据库，用作保存 Kubernetes 所有集群数据的后台数据库。

@@ -17,7 +17,7 @@ tags:
 title: etcd
 id: etcd
 date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/
 short_description: >
  Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.

@@ -2,7 +2,7 @@
 title: 扩展组件
 id: Extensions
 date: 2019-02-01
-full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
+full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions
 short_description: >
  扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。
 aka:
@@ -17,7 +17,7 @@ tags:
 title: Extensions
 id: Extensions
 date: 2019-02-01
-full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
+full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions
 short_description: >
  Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.

@@ -2,7 +2,7 @@
 title: FlexVolume
 id: flexvolume
 date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#flexvolume
+full_link: /zh/docs/concepts/storage/volumes/#flexvolume
 short_description: >
    Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。

@@ -16,7 +16,7 @@ tags:
 title: FlexVolume
 id: flexvolume
 date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#flexvolume
+full_link: /zh/docs/concepts/storage/volumes/#flexvolume
 short_description: >
    FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.

@@ -2,7 +2,7 @@
 title: Pod 水平自动扩缩器
 id: horizontal-pod-autoscaler
 date: 2018-04-12
-full_link: /docs/tasks/run-application/horizontal-pod-autoscale/
+full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/
 short_description: >
  Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。

@@ -16,7 +16,7 @@ tags:
 title: Horizontal Pod Autoscaler
 id: horizontal-pod-autoscaler
 date: 2018-04-12
-full_link: /docs/tasks/run-application/horizontal-pod-autoscale/
+full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/
 short_description: >
  An API resource that automatically scales the number of pod replicas based on targeted CPU utilization or custom metric targets.

@@ -2,7 +2,7 @@
 title: Ingress
 id: ingress
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /zh/docs/concepts/services-networking/ingress/
 short_description: >
  Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。

@@ -18,7 +18,7 @@ tags:
 title: Ingress
 id: ingress
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /zh/docs/concepts/services-networking/ingress/
 short_description: >
  An API object that manages external access to the services in a cluster, typically HTTP.

@@ -2,7 +2,7 @@
 title: kube-proxy
 id: kube-proxy
 date: 2018-04-12
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/
 short_description: >
  `kube-proxy` 是集群中每个节点上运行的网络代理。

@@ -15,7 +15,7 @@ tags:
 title: kube-proxy
 id: kube-proxy
 date: 2018-04-12
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/
 short_description: >
  `kube-proxy` is a network proxy that runs on each node in the cluster.

@@ -2,7 +2,7 @@
 title: Kubernetes API
 id: kubernetes-api
 date: 2018-04-12
-full_link: /docs/concepts/overview/kubernetes-api/
+full_link: /zh/docs/concepts/overview/kubernetes-api/
 short_description: >
  Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。

@@ -17,7 +17,7 @@ tags:
 title: Kubernetes API
 id: kubernetes-api
 date: 2018-04-12
-full_link: /docs/concepts/overview/kubernetes-api/
+full_link: /zh/docs/concepts/overview/kubernetes-api/
 short_description: >
  The application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.

@@ -2,7 +2,7 @@
 title: 标签
 id: label
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
 short_description: >
  用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。

@@ -15,7 +15,7 @@ tags:
 title: Label
 id: label
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
 short_description: >
  Tags objects with identifying attributes that are meaningful and relevant to users.

@@ -2,7 +2,7 @@
 title: 日志
 id: logging
 date: 2019-04-04
-full_link: /docs/concepts/cluster-administration/logging/
+full_link: /zh/docs/concepts/cluster-administration/logging/
 short_description: >
  日志是集群或应用程序记录的事件列表。

@@ -18,7 +18,7 @@ tags:
 title: Logging
 id: logging
 date: 2019-04-04
-full_link: /docs/concepts/cluster-administration/logging/
+full_link: /zh/docs/concepts/cluster-administration/logging/
 short_description: >
  Logs are the list of events that are logged by cluster or application.

@@ -2,7 +2,7 @@
 title: 名称
 id: name
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
 short_description: >
  客户端提供的字符串，用来指代资源 URL 中的对象，如 `/api/v1/pods/some-name`。

@@ -16,7 +16,7 @@ tags:
 title: Name
 id: name
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
 short_description: >
  A client-provided string that refers to an object in a resource URL, such as `/api/v1/pods/some-name`.

@@ -2,7 +2,7 @@
 title: 命名空间
 id: namespace
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/
 short_description: >
  命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。

@@ -16,7 +16,7 @@ tags:
 title: Namespace
 id: namespace
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/
 short_description: >
  An abstraction used by Kubernetes to support multiple virtual clusters on the same physical cluster.

@@ -2,7 +2,7 @@
 title: 网络策略
 id: network-policy
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/network-policies/
+full_link: /zh/docs/concepts/services-networking/network-policies/
 short_description: >
  网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。

@@ -18,7 +18,7 @@ tags:
 title: Network Policy
 id: network-policy
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/network-policies/
+full_link: /zh/docs/concepts/services-networking/network-policies/
 short_description: >
  A specification of how groups of Pods are allowed to communicate with each other and with other network endpoints.

@@ -2,7 +2,7 @@
 title: 节点
 id: node
 date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /zh/docs/concepts/architecture/nodes/
 short_description: >
  Kubernetes 中的工作机器称作节点。

@@ -15,7 +15,7 @@ tags:
 title: Node
 id: node
 date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /zh/docs/concepts/architecture/nodes/
 short_description: >
  A node is a worker machine in Kubernetes.

@@ -2,7 +2,7 @@
 title: Operator 模式
 id: operator-pattern
 date: 2019-05-21
-full_link: /docs/concepts/extend-kubernetes/operator/
+full_link: /zh/docs/concepts/extend-kubernetes/operator/
 short_description: >
  一种用于管理自定义资源的专用控制器

@@ -17,7 +17,7 @@ tags:
 title: Operator pattern
 id: operator-pattern
 date: 2019-05-21
-full_link: /docs/concepts/extend-kubernetes/operator/
+full_link: /zh/docs/concepts/extend-kubernetes/operator/
 short_description: >
  A specialized controller used to manage a custom resource

@@ -37,4 +37,4 @@ tags:
 <!--
 A [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget.
 -->
- [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
+ [Pod Disruption Budget](/zh/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
--- a/Show More
+++ b/Show More