Merge branch 'main' into zh-secure-cluster

content/zh/docs/tasks/administer-cluster/access-cluster-services.md

@@ -151,7 +151,17 @@ See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/ac
 As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
 
-If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
+If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
+
+By default, the API server proxies to your service using HTTP. To use HTTPS, prefix the service name with `https:`:
+`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
+
+The supported formats for the `<service_name>` segment of the URL are:
+
+* `<service_name>` - proxies to the default or unnamed port using http
+* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
+* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
+* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
 -->
 #### 手动构建 API 服务器代理 URLs   {#manually-constructing-apiserver-proxy-urls}
 
@@ -160,6 +170,15 @@ If you haven't specified a name for your port, you don't have to specify *port_n
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
 
 如果还没有为你的端口指定名称，你可以不用在 URL 中指定 *port_name*。
+对于命名和未命名端口，你还可以使用端口号代替 *port_name*。
+
+默认情况下，API 服务器使用 HTTP 为你的服务提供代理。 要使用 HTTPS，请在服务名称前加上 `https:`：
+`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
+URL 的 `<service_name>` 段支持的格式为：
+* `<service_name>` - 使用 http 代理到默认或未命名端口
+* `<service_name>:<port_name>` - 使用 http 代理到指定的端口名称或端口号
+* `https:<service_name>:` -  使用 https 代理到默认或未命名端口（注意尾随冒号）
+* `https:<service_name>:<port_name>` - 使用 https 代理到指定的端口名称或端口号
 
 <!--
 ##### Examples

content/zh/docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -672,3 +672,20 @@ ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshotdb
 依赖一些过时的数据。请注意，实际中还原会花费一些时间。
 在还原过程中，关键组件将丢失领导锁并自行重启。
 {{< /note >}}
+
+<!--
+
+## Upgrading etcd clusters
+
+For more details on etcd upgrade, please refer to the [etcd upgrades](https://etcd.io/docs/latest/upgrades/) documentation.
+
+{{< note >}}
+Before you start an upgrade, please back up your etcd cluster first.
+{{< /note >}}
+-->
+## 升级 etcd 集群
+有关 etcd 升级的更多详细信息，请参阅 [etcd 升级](https://etcd.io/docs/latest/upgrades/)文档。
+{{< note >}}
+在开始升级之前，请先备份你的 etcd 集群。
+{{< /note >}}
+

content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md

@@ -16,7 +16,7 @@ content_type: concept
 
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}
 
-{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}}
+{{< glossary_definition term_id="cloud-controller-manager" length="all">}}
 
 <!-- body -->
 
@@ -27,44 +27,43 @@ Since cloud providers develop and release at a different pace compared to the Ku
 -->
 ## 背景
 
-由于云驱动的开发和发布与 Kubernetes 项目本身步调不同，将特定于云环境
-的代码抽象到 `cloud-controller-manager` 二进制组件有助于云厂商独立于
-Kubernetes 核心代码推进其驱动开发。
+由于云驱动的开发和发布与 Kubernetes 项目本身步调不同，将特定于云环境的代码抽象到
+`cloud-controller-manager` 二进制组件有助于云厂商独立于 Kubernetes
+核心代码推进其驱动开发。
 
 <!--
 The Kubernetes project provides skeleton cloud-controller-manager code with Go interfaces to allow you (or your cloud provider) to plug in your own implementations. This means that a cloud provider can implement a cloud-controller-manager by importing packages from Kubernetes core; each cloudprovider will register their own code by calling `cloudprovider.RegisterCloudProvider` to update a global variable of available cloud providers.
 -->
-Kubernetes 项目提供 cloud-controller-manager 的框架代码，其中包含 Go
-语言的接口，便于你（或者你的云驱动提供者）接驳你自己的实现。
-这意味着每个云驱动可以通过从 Kubernetes 核心代码导入软件包来实现一个
-cloud-controller-manager；每个云驱动会通过调用
-`cloudprovider.RegisterCloudProvider` 接口来注册其自身实现代码，从而更新
-记录可用云驱动的全局变量。
+Kubernetes 项目提供 cloud-controller-manager 的框架代码，其中包含 Go 语言的接口，
+便于你（或者你的云驱动提供者）接驳你自己的实现。这意味着每个云驱动可以通过从
+Kubernetes 核心代码导入软件包来实现一个 cloud-controller-manager；
+每个云驱动会通过调用 `cloudprovider.RegisterCloudProvider` 接口来注册其自身实现代码，
+从而更新一个用来记录可用云驱动的全局变量。
 
 <!--
 ## Developing
 -->
 ## 开发
 
-### Out of Tree
+### 树外（Out of Tree）
 
 <!--
 To build an out-of-tree cloud-controller-manager for your cloud, follow these steps:
 -->
-要为你的云环境构建一个 out-of-tree 云控制器管理器：
+要为你的云环境构建一个树外（Out-of-Tree）云控制器管理器：
 
 <!--
 1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go).
 2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/main.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
 3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go).
 -->
-1. 使用满足 [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)
-   的实现创建一个 Go 语言包。
+1. 使用满足 [`cloudprovider.Interface`](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)
+   接口的实现来创建一个 Go 语言包。
 2. 使用来自 Kubernetes 核心代码库的
    [cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/main.go)
-   作为 main.go 的模板。如上所述，唯一的区别应该是将导入的云包。
+   作为 `main.go` 的模板。如上所述，唯一的区别应该是将导入的云包不同。
 3. 在 `main.go` 中导入你的云包，确保你的包有一个 `init` 块来运行
-   [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go)。
+   [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go)。
 
 <!--
 Many cloud providers publish their controller manager code as open source. If you are creating
@@ -72,15 +71,15 @@ a new cloud-controller-manager from scratch, you could take an existing out-of-t
 controller manager as your starting point.
 -->
 很多云驱动都将其控制器管理器代码以开源代码的形式公开。
-如果你在开发一个新的 cloud-controller-manager，你可以选择某个 out-of-tree
+如果你在开发一个新的 cloud-controller-manager，你可以选择某个树外（Out-of-Tree）
 云控制器管理器作为出发点。
 
-### In Tree
+### 树内（In Tree）
 
 <!--
 For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details.
 -->
-对于 in-tree 驱动，你可以将 in-tree 云控制器管理器作为群集中的
-{{< glossary_tooltip term_id="daemonset" text="Daemonset" >}} 来运行。
+对于树内（In-Tree）驱动，你可以将树内云控制器管理器作为集群中的
+{{< glossary_tooltip term_id="daemonset" text="DaemonSet" >}} 来运行。
 有关详细信息，请参阅[云控制器管理器管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/)。
 

content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md

@@ -289,10 +289,10 @@ Install-WindowsFeature -Name containers
 ```
 <!--
 Install Docker
-Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows).
+Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker).
 -->
 安装 Docker
-操作指南在 [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)。
+操作指南在 [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)。
 
 <!--
 #### Install wins, kubelet, and kubeadm.

content/zh/docs/tasks/administer-cluster/memory-manager.md

@@ -287,7 +287,8 @@ Kubernetes 调度器在优化 Pod 调度过程时，会考虑“可分配的”
 并完成跨 NUMA 节点的预留操作。
 
 <!--
-The flag specifies a comma-separated list of memory reservations per NUMA node.
+The flag specifies a comma-separated list of memory reservations of different memory types per NUMA node.
+Memory reservations across multiple NUMA nodes can be specified using semicolon as separator.
 This parameter is only useful in the context of the Memory Manager feature. 
 The Memory Manager will not use this reserved memory for the allocation of container workloads.
 
@@ -295,7 +296,8 @@ For example, if you have a NUMA node "NUMA0" with `10Gi` of memory available, an
 the `--reserved-memory` was specified to reserve `1Gi` of memory at "NUMA0",
 the Memory Manager assumes that only `9Gi` is available for containers.
 -->
-标志设置的值是一个按 NUMA 节点所给的内存预留的值的列表，用逗号分开。
+标志设置的值是一个按 NUMA 节点的不同内存类型所给的内存预留的值的列表，用逗号分开。
+可以使用分号作为分隔符来指定跨多个 NUMA 节点的内存预留。
 只有在内存管理器特性被启用的语境下，这个参数才有意义。
 内存管理器不会使用这些预留的内存来为容器负载分配内存。
 
@@ -426,7 +428,7 @@ Here is an example of a correct configuration:
 --kube-reserved=cpu=4,memory=4Gi 
 --system-reserved=cpu=1,memory=1Gi 
 --memory-manager-policy=Static 
---reserved-memory 0:memory=3Gi --reserved-memory 1:memory=2148Mi
+--reserved-memory '0:memory=3Gi;1:memory=2148Mi'
 ```
 
 <!--

content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md

@@ -20,13 +20,13 @@ dockershim to other container runtimes.
 <!-- 
 Since the announcement of [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
 in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes
-installations. You can find this blog post useful to understand the problem better: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)
+installations. Our [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) is there to help you
+to understand the problem better.
 -->
 自从 Kubernetes 1.20 宣布
 [弃用 dockershim](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)，
 各类疑问随之而来：这对各类工作负载和 Kubernetes 部署会产生什么影响。
-你会发现这篇博文对于更好地理解此问题非常有用：
-[弃用 Dockershim 常见问题](/zh/blog/2020/12/02/dockershim-faq/)
+我们的[弃用  Dockershim 常见问题](/blog/2022/02/17/dockershim-faq/)可以帮助你更好地理解这个问题。
 
 <!-- It is recommended to migrate from dockershim to alternative container runtimes.
 Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)

content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md

@@ -29,7 +29,7 @@ you can take to check whether any workloads could be affected by `dockershim` de
 -->
 本页讲解你的集群把 Docker 用作容器运行时的运作机制，
 并提供使用 `dockershim` 时，它所扮演角色的详细信息，
-继而展示了一组验证步骤，可用来检查弃用 `dockershim` 对你的工作负载的影响。
+继而展示了一组操作，可用来检查弃用 `dockershim` 对你的工作负载是否有影响。
 
 <!-- 
 ## Finding if your app has a dependencies on Docker {#find-docker-dependencies} 
@@ -41,16 +41,16 @@ If you are using Docker for building your application containers, you can still
 run these containers on any container runtime. This use of Docker does not count
 as a dependency on Docker as a container runtime.
 -->
-虽然你通过 Docker 创建了应用容器，但这些容器却可以运行于所有容器运行时。
-所以这种使用 Docker 容器运行时的方式并不构成对 Docker 的依赖。
+即使你是通过 Docker 创建的应用容器，也不妨碍你在其他任何容器运行时上运行这些容器。
+这种使用 Docker 的方式并不构成对 Docker 作为一个容器运行时的依赖。
 
 <!-- 
 When alternative container runtime is used, executing Docker commands may either
 not work or yield unexpected output. This is how you can find whether you have a
 dependency on Docker:
 -->
-当用了替代的容器运行时之后，Docker 命令可能不工作，甚至产生意外的输出。
-这才是判定你是否依赖于 Docker 的方法。
+当用了别的容器运行时之后，Docker 命令可能不工作，或者产生意外的输出。
+下面是判定你是否依赖于 Docker 的方法。
 
 <!--
 1. Make sure no privileged Pods execute Docker commands (like `docker ps`),
@@ -75,20 +75,21 @@ dependency on Docker:
    cluster before migration.
 -->
 1. 确认没有特权 Pod 执行 Docker 命令（如 `docker ps`）、重新启动 Docker
-   服务（如 `systemctl restart docker.service`）或修改
-   Docker 配置文件 `/etc/docker/daemon.json`。
+   服务（如 `systemctl restart docker.service`）或修改 Docker 配置文件
+   `/etc/docker/daemon.json`。
 2. 检查 Docker 配置文件（如 `/etc/docker/daemon.json`）中容器镜像仓库的镜像（mirror）站点设置。
    这些配置通常需要针对不同容器运行时来重新设置。
-3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行Docker命令。
+3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行 Docker 命令。
    可能的情况如：
    - SSH 到节点排查故障；
    - 节点启动脚本；
    - 直接安装在节点上的监控和安全代理。
-4. 检查执行上述特权操作的第三方工具。详细操作请参考：
-   [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
+4. 检查执行上述特权操作的第三方工具。详细操作请参考
+   [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)。
 5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。
-   一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，或者在故障排查指令的一个环节中搜索特定的日志信息。
-   如果你有此类配置的工具，需要在迁移之前，在测试集群上完成功能验证。
+   一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，
+   或者在故障排查指令的一个环节中搜索特定的日志信息。
+   如果你有此类配置的工具，需要在迁移之前，在测试集群上测试这类行为。
 
 <!-- 
 ## Dependency on Docker explained {#role-of-dockershim}  
@@ -103,8 +104,7 @@ uses the container runtime interface as an abstraction so that you can use any c
 container runtime.
  -->
 [容器运行时](/zh/docs/concepts/containers/#container-runtimes)是一个软件，用来运行组成 Kubernetes Pod 的容器。
-Kubernetes 负责编排和调度 Pod；在每一个节点上，
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
+Kubernetes 负责编排和调度 Pod；在每一个节点上，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
 使用抽象的容器运行时接口，所以你可以任意选用兼容的容器运行时。
 
 <!-- 
@@ -118,14 +118,14 @@ if Docker were a CRI compatible runtime.
 在早期版本中，Kubernetes 提供的兼容性支持一个容器运行时：Docker。
 在 Kubernetes 发展历史中，集群运营人员希望采用更多的容器运行时。
 于是 CRI 被设计出来满足这类灵活性需要 - 而 kubelet 亦开始支持 CRI。
-然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件：`dockershim`。
-dockershim 适配器允许 kubelet 与 Docker交互，就好像 Docker 是一个 CRI 兼容的运行时一样。
+然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件 `dockershim`。
+dockershim 适配器允许 kubelet 与 Docker 交互，就好像 Docker 是一个 CRI 兼容的运行时一样。
 
 <!-- 
 You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post.
  -->
 你可以阅读博文
-[Kubernetes 容器集成功能的正式发布](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)
+[Kubernetes 正式支持集成 Containerd](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)。
 
 <!-- Dockershim vs. CRI with Containerd -->
 ![Dockershim 和 Containerd CRI 的实现对比图](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png)
@@ -138,8 +138,8 @@ So any Docker tooling or fancy UI you might have used
 before to check on these containers is no longer available.
  -->
 切换到容器运行时 Containerd 可以消除掉中间环节。
-所有以前遗留的容器可由 Containerd 这类容器运行时来运行和管理，操作体验也和以前一样。
-但是现在，由于直接用容器运行时调度容器，所以它们对 Docker 来说是不可见的。
+所有相同的容器都可由 Containerd 这类容器运行时来运行。
+但是现在，由于直接用容器运行时调度容器，它们对 Docker 是不可见的。
 因此，你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。
 
 <!-- 
@@ -156,10 +156,9 @@ the Kubernetes API rather than directly through the container runtime (this advi
 for all container runtimes, not only Docker).
  -->
 {{< note >}}
-
-如果你用 Kubernetes 运行工作负载，最好通过 Kubernetes API停止容器，而不是通过容器运行时
+如果你在用 Kubernetes 运行工作负载，最好通过 Kubernetes API 停止容器，
+而不是通过容器运行时来停止它们
 （此建议适用于所有容器运行时，不仅仅是针对 Docker）。
-
 {{< /note >}}
 
 <!-- 
@@ -170,4 +169,5 @@ by Kubernetes.
  -->
 你仍然可以下载镜像，或者用 `docker build` 命令创建它们。
 但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。
-为了在 Kubernetes 中使用，需要把镜像推送（push）到某注册中心。
+为了在 Kubernetes 中使用，需要把镜像推送（push）到某镜像仓库。
+

content/zh/docs/tasks/administer-cluster/nodelocaldns.md

@@ -1,18 +1,13 @@
 ---
-reviewers:
-- bowei
-- zihongz
 title: 在 Kubernetes 集群中使用 NodeLocal DNSCache
 content_type: task
 ---
 <!--
----
 reviewers:
 - bowei
 - zihongz
 title: Using NodeLocal DNSCache in Kubernetes clusters
 content_type: task
----
 -->
 
 <!-- overview -->
@@ -22,14 +17,10 @@ This page provides an overview of NodeLocal DNSCache feature in Kubernetes.
 -->
 本页概述了 Kubernetes 中的 NodeLocal DNSCache 功能。
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
  {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
  <!-- steps -->
 
 <!--
@@ -40,11 +31,11 @@ This page provides an overview of NodeLocal DNSCache feature in Kubernetes.
 <!--
 NodeLocal DNSCache improves Cluster DNS performance by running a dns caching agent on cluster nodes as a DaemonSet. In today's architecture, Pods in ClusterFirst DNS mode reach out to a kube-dns serviceIP for DNS queries. This is translated to a kube-dns/CoreDNS endpoint via iptables rules added by kube-proxy. With this new architecture, Pods will reach out to the dns caching agent running on the same node, thereby avoiding iptables DNAT rules and connection tracking. The local caching agent will query kube-dns service for cache misses of cluster hostnames(cluster.local suffix by default).
 -->
-NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 dns 缓存代理来提高集群 DNS 性能。
-在当今的体系结构中，处于 ClusterFirst DNS 模式的 Pod 可以连接到 kube-dns serviceIP 进行 DNS 查询。
+NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代理来提高集群 DNS 性能。
+在当今的体系结构中，运行在 ClusterFirst DNS 模式下的 Pod 可以连接到 kube-dns `serviceIP` 进行 DNS 查询。
 通过 kube-proxy 添加的 iptables 规则将其转换为 kube-dns/CoreDNS 端点。
-借助这种新架构，Pods 将可以访问在同一节点上运行的 dns 缓存代理，从而避免了 iptables DNAT 规则和连接跟踪。
-本地缓存代理将查询 kube-dns 服务以获取集群主机名的缓存缺失（默认为 cluster.local 后缀）。
+借助这种新架构，Pods 将可以访问在同一节点上运行的 DNS 缓存代理，从而避免 iptables DNAT 规则和连接跟踪。
+本地缓存代理将查询 kube-dns 服务以获取集群主机名的缓存缺失（默认为 "`cluster.local`" 后缀）。
 
 <!--
 ## Motivation
@@ -55,29 +46,36 @@ NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 dns 缓存代
 * With the current DNS architecture, it is possible that Pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns/CoreDNS instance.
 Having a local cache will help improve the latency in such scenarios.
 -->
-* 使用当前的 DNS 体系结构，如果没有本地 kube-dns/CoreDNS 实例，则具有最高 DNS QPS 的 Pod 可能必须延伸到另一个节点。
-在这种脚本下，拥有本地缓存将有助于改善延迟。
+* 使用当前的 DNS 体系结构，如果没有本地 kube-dns/CoreDNS 实例，则具有最高 DNS QPS
+  的 Pod 可能必须延伸到另一个节点。
+  在这种场景下，拥有本地缓存将有助于改善延迟。
 
 <!--
 * Skipping iptables DNAT and connection tracking will help reduce [conntrack races](https://github.com/kubernetes/kubernetes/issues/56903) and avoid UDP DNS entries filling up conntrack table.
 -->
-* 跳过 iptables DNAT 和连接跟踪将有助于减少 [conntrack 竞争](https://github.com/kubernetes/kubernetes/issues/56903)并避免 UDP DNS 条目填满 conntrack 表。
+* 跳过 iptables DNAT 和连接跟踪将有助于减少
+  [conntrack 竞争](https://github.com/kubernetes/kubernetes/issues/56903)
+  并避免 UDP DNS 条目填满 conntrack 表。
 
 <!--
 * Connections from local caching agent to kube-dns servie can be upgraded to TCP. TCP conntrack entries will be removed on connection close in contrast with UDP entries that have to timeout ([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` is 30 seconds)
 -->
-* 从本地缓存代理到 kube-dns 服务的连接可以升级到 TCP 。
-TCP conntrack 条目将在连接关闭时被删除，相反 UDP 条目必须超时([默认](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` 是 30 秒)
+* 从本地缓存代理到 kube-dns 服务的连接可以升级为 TCP 。
+  TCP conntrack 条目将在连接关闭时被删除，相反 UDP 条目必须超时
+  （[默认](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt)
+  `nf_conntrack_udp_timeout` 是 30 秒）。
 
 <!--
 * Upgrading DNS queries from UDP to TCP would reduce tail latency attributed to dropped UDP packets and DNS timeouts usually up to 30s (3 retries + 10s timeout). Since the nodelocal cache listens for UDP DNS queries, applications don't need to be changed.
 -->
-* 将 DNS 查询从 UDP 升级到 TCP 将减少归因于丢弃的 UDP 数据包和 DNS 超时的尾部等待时间，通常长达 30 秒（3 次重试+ 10 秒超时）。
+* 将 DNS 查询从 UDP 升级到 TCP 将减少由于被丢弃的 UDP 包和 DNS 超时而带来的尾部等待时间；
+  这类延时通常长达 30 秒（3 次重试 + 10 秒超时）。
+  由于 nodelocal 缓存监听 UDP DNS 查询，应用不需要变更。
 
 <!--
 * Metrics & visibility into dns requests at a node level.
 -->
-* 在节点级别对 dns 请求的度量和可见性。
+* 在节点级别对 DNS 请求的度量和可见性。
 
 <!--
 * Negative caching can be re-enabled, thereby reducing number of queries to kube-dns service.
@@ -92,13 +90,12 @@ TCP conntrack 条目将在连接关闭时被删除，相反 UDP 条目必须超
 <!--
 This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
 -->
-启用 NodeLocal DNSCache 之后，这是 DNS 查询所遵循的路径：
-
+启用 NodeLocal DNSCache 之后，DNS 查询所遵循的路径如下：
 
 <!--
-{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
+{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." class="diagram-medium" >}}
 -->
-{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache 流" title="Nodelocal DNSCache 流" caption="此图显示了 NodeLocal DNSCache 如何处理 DNS 查询。" >}}
+{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache 流" title="Nodelocal DNSCache 流" caption="此图显示了 NodeLocal DNSCache 如何处理 DNS 查询。" class="diagram-medium" >}}
 
 <!--
 ## Configuration
@@ -110,8 +107,8 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
 -->
 {{< note >}} 
 NodeLocal DNSCache 的本地侦听 IP 地址可以是任何地址，只要该地址不和你的集群里现有的 IP 地址发生冲突。
-推荐使用本地范围内的地址，例如，IPv4 链路本地区段 169.254.0.0/16 内的地址，
-或者 IPv6 唯一本地地址区段 fd00::/8 内的地址。
+推荐使用本地范围内的地址，例如，IPv4 链路本地区段 '169.254.0.0/16' 内的地址，
+或者 IPv6 唯一本地地址区段 'fd00::/8' 内的地址。
 {{< /note >}}
 
 <!--
@@ -129,7 +126,8 @@ This feature can be enabled using the following steps:
 If you are using the sample manifest from the previous point, this will require to modify [the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70) like this `health [__PILLAR__LOCAL__DNS__]:8080`
 -->
 * 如果使用 IPv6，在使用 IP:Port 格式的时候需要把 CoreDNS 配置文件里的所有 IPv6 地址用方括号包起来。
-  如果你使用上述的示例清单，需要把 [配置行 L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70) 
+  如果你使用上述的示例清单，需要把
+  [配置行 L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70) 
   修改为 `health [__PILLAR__LOCAL__DNS__]:8080`。
 <!--
 * Substitute the variables in the manifest with the right values:
@@ -143,13 +141,15 @@ If you are using the sample manifest from the previous point, this will require
      `<cluster-domain>` is "cluster.local" by default. `<node-local-address>` is the local listen IP address chosen for NodeLocal DNSCache.
 -->
 * 把清单里的变量更改为正确的值：
-     * kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
 
-     * domain=`<cluster-domain>`
+  ```
+  kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
+  domain=<cluster-domain>
+  localdns=<node-local-address>
+  ```
 
-     * localdns=`<node-local-address>`
-
-     `<cluster-domain>` 的默认值是 "cluster.local"。 `<node-local-address>` 是 NodeLocal DNSCache 选择的本地侦听 IP 地址。
+  `<cluster-domain>` 的默认值是 "`cluster.local`"。`<node-local-address>` 是
+  NodeLocal DNSCache 选择的本地侦听 IP 地址。
 
 <!--
    * If kube-proxy is running in IPTABLES mode:
@@ -161,16 +161,16 @@ If you are using the sample manifest from the previous point, this will require
      `__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
      In this mode, node-local-dns pods listen on both the kube-dns service IP as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
 -->   
-   * 如果 kube-proxy 运行在 IPTABLES 模式：
+  * 如果 kube-proxy 运行在 IPTABLES 模式：
 
-     ``` bash
-     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
-     ```
+    ``` bash
+    sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
+    ```
 
-     node-local-dns Pods 会设置 `__PILLAR__CLUSTER__DNS__` 和 `__PILLAR__UPSTREAM__SERVERS__`。
-     在此模式下, node-local-dns Pods 会同时侦听 kube-dns 服务的 IP 地址和 `<node-local-address>` 的地址，
-     以便 Pods 可以使用其中任何一个 IP 地址来查询 DNS 记录。
-<!--
+    node-local-dns Pods 会设置 `__PILLAR__CLUSTER__DNS__` 和 `__PILLAR__UPSTREAM__SERVERS__`。
+    在此模式下, node-local-dns Pods 会同时侦听 kube-dns 服务的 IP 地址和
+    `<node-local-address>` 的地址，以便 Pods 可以使用其中任何一个 IP 地址来查询 DNS 记录。
+  <!--
   * If kube-proxy is running in IPVS mode:
 
     ``` bash
@@ -179,16 +179,16 @@ If you are using the sample manifest from the previous point, this will require
      In this mode, node-local-dns pods listen only on `<node-local-address>`. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
      `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
 -->
-   * 如果 kube-proxy 运行在 IPVS 模式：
+  * 如果 kube-proxy 运行在 IPVS 模式：
 
-     ``` bash
-     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
-     ```
+    ``` bash
+    sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
+    ```
 
-     在此模式下，node-local-dns Pods 只会侦听 `<node-local-address>` 的地址。
-     node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址，因为 IPVS 负载均衡
-     使用的接口已经占用了该地址。
-     node-local-dns Pods 会设置 `__PILLAR__UPSTREAM__SERVERS__`。
+    在此模式下，node-local-dns Pods 只会侦听 `<node-local-address>` 的地址。
+    node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址，因为 IPVS 负载均衡
+    使用的接口已经占用了该地址。
+    node-local-dns Pods 会设置 `__PILLAR__UPSTREAM__SERVERS__`。
      
 <!--
 * Run `kubectl create -f nodelocaldns.yaml`
@@ -196,8 +196,10 @@ If you are using the sample manifest from the previous point, this will require
   Otherwise, there is no need to modify the value of the `--cluster-dns` flag, since NodeLocal DNSCache listens on both the kube-dns service IP as well as `<node-local-address>`.
 -->
 * 运行 `kubectl create -f nodelocaldns.yaml`
-* 如果 kube-proxy 运行在 IPVS 模式，需要修改 kubelet 的 `--cluster-dns` 参数为 NodeLocal DNSCache 正在侦听的 `<node-local-address>` 地址。
-  否则，不需要修改 `--cluster-dns` 参数，因为 NodeLocal DNSCache 会同时侦听 kube-dns 服务的 IP 地址和 `<node-local-address>` 的地址。
+* 如果 kube-proxy 运行在 IPVS 模式，需要修改 kubelet 的 `--cluster-dns` 参数
+  NodeLocal DNSCache 正在侦听的 `<node-local-address>` 地址。
+  否则，不需要修改 `--cluster-dns` 参数，因为 NodeLocal DNSCache 会同时侦听
+  kube-dns 服务的 IP 地址和 `<node-local-address>` 的地址。
 
 <!--
 Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
@@ -205,6 +207,93 @@ Once enabled, node-local-dns Pods will run in the kube-system namespace on each
 You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
 -->
 启用后，node-local-dns Pods 将在每个集群节点上的 kube-system 名字空间中运行。
-此 Pod 在缓存模式下运行 [CoreDNS](https://github.com/coredns/coredns) ，因此每个节点都可以使用不同插件公开的所有 CoreDNS 指标。
+此 Pod 在缓存模式下运行 [CoreDNS](https://github.com/coredns/coredns) ，
+因此每个节点都可以使用不同插件公开的所有 CoreDNS 指标。
+
+如果要禁用该功能，你可以使用 `kubectl delete -f <manifest>` 来删除 DaemonSet。
+你还应该回滚你对 kubelet 配置所做的所有改动。
+
+<!--
+## StubDomains and Upstream server Configuration
+-->
+## StubDomains 和上游服务器配置
+
+<!--
+StubDomains and upstream servers specified in the `kube-dns` ConfigMap in the `kube-system` namespace
+are automatically picked up by `node-local-dns` pods. The ConfigMap contents need to follow the format
+shown in [the example](/docs/tasks/administer-cluster/dns-custom-nameservers/#example-1).
+The `node-local-dns` ConfigMap can also be modified directly with the stubDomain configuration
+in the Corefile format. Some cloud providers might not allow modifying `node-local-dns` ConfigMap directly.
+In those cases, the `kube-dns` ConfigMap can be updated.
+-->
+`node-local-dns` Pod 能够自动读取 `kube-system` 名字空间中 `kube-dns` ConfigMap
+中保存的 StubDomains 和上游服务器信息。ConfigMap 中的内容需要遵从
+[此示例](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#example-1)
+中所给的格式。
+`node-local-dns` ConfigMap 也可被直接修改，使用 Corefile 格式设置 stubDomain 配置。
+某些云厂商可能不允许直接修改 `node-local-dns` ConfigMap 的内容。
+在这种情况下，可以更新 `kube-dns` ConfigMap。
+
+<!--
+## Setting memory limits
+-->
+## 设置内存限制
+
+<!--
+node-local-dns pods use memory for storing cache entries and processing queries. Since they do not watch Kubernetes objects, the cluster size or the number of Services/Endpoints do not directly affect memory usage. Memory usage is influenced by the DNS query pattern.
+From [CoreDNS docs](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md),
+> The default cache size is 10000 entries, which uses about 30 MB when completely filled.
+-->
+`node-local-dns` Pod 使用内存来保存缓存项并处理查询。
+由于它们并不监视 Kubernetes 对象变化，集群规模或者 Service/Endpoints
+的数量都不会直接影响内存用量。内存用量会受到 DNS 查询模式的影响。
+根据 [CoreDNS 文档](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md),
+
+> The default cache size is 10000 entries, which uses about 30 MB when completely filled.
+> （默认的缓存大小是 10000 个表项，当完全填充时会使用约 30 MB 内存）
+
+<!--
+This would be the memory usage for each server block (if the cache gets completely filled).
+Memory usage can be reduced by specifying smaller cache sizes.
+
+The number of concurrent queries is linked to the memory demand, because each extra
+goroutine used for handling a query requires an amount of memory. You can set an upper limit
+using the `max_concurrent` option in the forward plugin.
+-->
+这一数值是（缓存完全被填充时）每个服务器块的内存用量。
+通过设置小一点的缓存大小可以降低内存用量。
+
+并发查询的数量会影响内存需求，因为用来处理查询请求而创建的 Go 协程都需要一定量的内存。
+你可以在 forward 插件中使用 `max_concurrent` 选项设置并发查询数量上限。
+
+<!--
+If a node-local-dns pod attempts to use more memory than is available (because of total system
+resources, or because of a configured
+[resource limit](/docs/concepts/configuration/manage-resources-containers/)), the operating system
+may shut down that pod's container.
+If this happens, the container that is terminated (“OOMKilled”) does not clean up the custom
+packet filtering rules that it previously added during startup.
+The node-local-dns container should get restarted (since managed as part of a DaemonSet), but this
+will lead to a brief DNS downtime each time that the container fails: the packet filtering rules direct
+DNS queries to a local Pod that is unhealthy.
+-->
+如果一个 `node-local-dns` Pod 尝试使用的内存超出可提供的内存量
+（因为系统资源总量的，或者所配置的[资源约束](/zh/docs/concepts/configuration/manage-resources-containers/)）的原因，
+操作系统可能会关闭这一 Pod 的容器。
+发生这种情况时，被终止的（"OOMKilled"）容器不会清理其启动期间所添加的定制包过滤规则。
+该 `node-local-dns` 容器应该会被重启（因其作为 DaemonSet 的一部分被管理），
+但因上述原因可能每次容器失败时都会导致 DNS 有一小段时间不可用：
+the packet filtering rules direct DNS queries to a local Pod that is unhealthy
+（包过滤器规则将 DNS 查询转发到本地某个不健康的 Pod）。
+
+<!--
+You can determine a suitable memory limit by running node-local-dns pods without a limit and
+measuring the peak usage. You can also set up and use a
+[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)
+in _recommender mode_, and then check its recommendations.
+-->
+通过不带限制地运行 `node-local-dns` Pod 并度量其内存用量峰值，你可以为其确定一个合适的内存限制值。
+你也可以安装并使用一个运行在 “Recommender Mode（建议者模式）” 的
+[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)，
+并查看该组件输出的建议信息。
 
-如果要禁用该功能，你可以使用 `kubectl delete -f <manifest>` 来删除 DaemonSet。你还应该恢复你对 kubelet 配置所做的所有改动。

content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md

@@ -166,7 +166,7 @@ flag.
 It is recommended that the kubernetes system daemons are placed under a top
 level control group (`runtime.slice` on systemd machines for example). Each
 system daemon should ideally run within its own child control group. Refer to
-[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
+[the design proposal](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup)
 for more details on recommended control group hierarchy.
 
 Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
@@ -179,7 +179,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 `runtime.slice`）。
 理想情况下每个系统守护进程都应该在其自己的子控制组中运行。
 请参考
-[这个设计方案](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，
+[这个设计方案](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup)，
 进一步了解关于推荐控制组层次结构的细节。
 
 请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将 **不会** 创建它。

content/zh/docs/tasks/administer-cluster/safely-drain-node.md

@@ -174,154 +174,16 @@ replicas to fall below the specified budget are blocked.
 
 If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as
 to avoid calling to an external command, or to get finer control over the pod
-eviction process), you can also programmatically cause evictions using the eviction API.
+eviction process), you can also programmatically cause evictions using the
+eviction API.
+For more information, see [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/).
 -->
 ## 驱逐 API {#the-eviction-api}
 如果你不喜欢使用
 [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程），
 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。
-
-<!-- 
-You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api).
-
-The eviction subresource of a
-pod can be thought of as a kind of policy-controlled DELETE operation on the pod
-itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
-*create* an eviction), you POST an attempted operation. Here's an example:
--->
-首先应该熟悉使用 
-[Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。
-
-Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。
-要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子：
-
-{{< tabs name="Eviction_example" >}}
-{{% tab name="policy/v1" %}}
-<!--
-{{< note >}}
-`policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases.
-{{< /note >}}
--->
-{{< note >}}
-`policy/v1` 驱逐在 v1.22+ 中可用。在之前版本中请使用 `policy/v1beta1` 。
-{{< /note >}}
-
-
-```json
-{
-  "apiVersion": "policy/v1",
-  "kind": "Eviction",
-  "metadata": {
-    "name": "quux",
-    "namespace": "default"
-  }
-}
-```
-{{% /tab %}}
-{{% tab name="policy/v1beta1" %}}
-<!--
-{{< note >}}
-Deprecated in v1.22 in favor of `policy/v1`
-{{< /note >}}
--->
-{{< note >}}
-在 v1.22 中已弃用，以 `policy/v1` 取代
-{{< /note >}}
-
-```json
-{
-  "apiVersion": "policy/v1beta1",
-  "kind": "Eviction",
-  "metadata": {
-    "name": "quux",
-    "namespace": "default"
-  }
-}
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-<!-- 
-You can attempt an eviction using `curl`:
--->
-你可以使用 `curl` 尝试驱逐：
-
-```bash
-curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
-```
-
-<!-- 
-The API can respond in one of three ways:
-
-- If the eviction is granted, then the Pod is deleted as if you sent
-  a `DELETE` request to the Pod's URL and received back `200 OK`.
-- If the current state of affairs wouldn't allow an eviction by the rules set
-  forth in the budget, you get back `429 Too Many Requests`. This is
-  typically used for generic rate limiting of *any* requests, but here we mean
-  that this request isn't allowed *right now* but it may be allowed later.
-  Currently, callers do not get any `Retry-After` advice, but they may in
-  future versions.
-- If there is some kind of misconfiguration, like multiple budgets pointing at
-  the same pod, you will get `500 Internal Server Error`.
--->
-API 可以通过以下三种方式之一进行响应：
-
-- 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`，
-  就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。
-- 如果按照预算中规定，目前的情况不允许的驱逐，你会收到 `429 Too Many Requests`。
-  这通常用于对 *一些* 请求进行通用速率限制，
-  但这里我们的意思是：此请求 *现在* 不允许，但以后可能会允许。
-  目前，调用者不会得到任何 `Retry-After` 的提示，但在将来的版本中可能会得到。
-- 如果有一些错误的配置，比如多个预算指向同一个 Pod，你将得到 `500 Internal Server Error`。
-
-<!-- 
-For a given eviction request, there are two cases:
-
-- There is no budget that matches this pod. In this case, the server always
-  returns `200 OK`.
-- There is at least one budget. In this case, any of the three above responses may
-   apply.
--->
-对于一个给定的驱逐请求，有两种情况：
-
-- 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。
-- 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。
-
-<!-- 
-## Stuck evictions
-
-In some cases, an application may reach a broken state, one where unless you intervene the
-eviction API will never return anything other than 429 or 500.
-
-For example: this can happen if ReplicaSet is creating Pods for your application but
-the replacement Pods do not become `Ready`. You can also see similar symptoms if the
-last Pod evicted has a very long termination grace period.
--->
-## 驱逐阻塞
-
-在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。
-例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个
-Pod 有很长的终止宽限期，就会发生这种情况。
-
-<!--
-In this case, there are two potential solutions:
-
-- Abort or pause the automated operation. Investigate the reason for the stuck application,
-  and restart the automation.
-- After a suitably long wait, `DELETE` the Pod from your cluster's control plane, instead
-  of using the eviction API.
-
-Kubernetes does not specify what the behavior should be in this case; it is up to the
-application owners and cluster owners to establish an agreement on behavior in these cases.
--->
-在这种情况下，有两种可能的解决方案：
-
-- 中止或暂停自动操作。调查应用程序卡住的原因，并重新启动自动化。
-- 经过适当的长时间等待后，从集群中删除 Pod 而不是使用驱逐 API。
-
-Kubernetes 并没有具体说明在这种情况下应该采取什么行为，
-这应该由应用程序所有者和集群所有者紧密沟通，并达成对行动一致意见。
+更多信息，请参阅 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
 
 ## {{% heading "whatsnext" %}}
 

content/zh/docs/tasks/administer-cluster/securing-a-cluster.md

@@ -257,10 +257,10 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
 -->
 ### 限制云元数据 API 访问
 
-云平台（AWS、Azure、GCE 等）经常将元数据服务暴露给本地实例。
-默认情况下，这些 API 可由运行在实例上的 Pod 访问，且其中可能包含该云节点的凭据或配置数据
-（如 kubelet 凭据）。
-这些凭据可以用于在集群内提升权限或获得权限访问同一账户的其他云服务。
+云平台（AWS,  Azure, GCE 等）经常将 metadata 本地服务暴露给实例。
+默认情况下，这些 API 可由运行在实例上的 Pod 访问，并且可以包含
+该云节点的凭据或配置数据（如 kubelet 凭据）。
+这些凭据可以用于在集群内升级或在同一账户下升级到其他云服务。
 
 在云平台上运行 Kubernetes 时，需要限制对实例凭据的权限，使用
 [网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)

content/zh/docs/tasks/administer-cluster/sysctl-cluster.md

@@ -122,7 +122,7 @@ The following sysctls are supported in the _safe_ set:
 - `net.ipv4.ip_local_port_range`
 - `net.ipv4.tcp_syncookies`
 - `net.ipv4.ping_group_range` （从 Kubernetes 1.18 开始）
-- `net.ipv4.ip_unprivileged_port_start` (从 Kubernetes 1.22 开始).
+- `net.ipv4.ip_unprivileged_port_start` （从 Kubernetes 1.22 开始）。
 
 <!--
 The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.