diff --git a/content/zh/_redirects b/content/zh/_redirects
new file mode 100644
index 0000000000..a38fbcc91b
--- /dev/null
+++ b/content/zh/_redirects
@@ -0,0 +1 @@
+/zh/docs/ /zh/docs/home/ 301
diff --git a/content/zh/docs/_index.md b/content/zh/docs/_index.md
index b274dc98cd..0b9545eaa6 100644
--- a/content/zh/docs/_index.md
+++ b/content/zh/docs/_index.md
@@ -1,5 +1,5 @@
---
-title: 主页
+title: 文档
weight: 5
---
diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md
index 7468ae1b57..5ee255fb75 100644
--- a/content/zh/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md
@@ -1,163 +1,416 @@
---
-approvers:
+reviewers:
+- enisoc
- erictune
+- foxish
+- janetkuo
+- kow3ns
title: DaemonSet
-redirect_from:
-- "/docs/admin/daemons/"
-- "/docs/admin/daemons.html"
+content_template: templates/concept
+weight: 50
---
-{{< toc >}}
+
+{{% capture overview %}}
+
+ _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，
+也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
-## 什么是 DaemonSet？
-
- _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。
- 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
-
-
+
使用 DaemonSet 的一些典型用法：
- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
-- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理, Ganglia `gmond`, 或 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。
+- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics 代理](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog 代理](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic 代理](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 或 Instana agent。
-一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
-一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
+
+一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使
+用。
+一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，
+和/或对不同硬件类型具有不同的内存、CPU要求。
+
+{{% /capture %}}
+{{% capture body %}}
-## 编写 DaemonSet 规约
+
+## 编写 DaemonSet 规约
+
+### 创建 DaemonSet
+
+
+您可以在 YAML 文件中描述 DaemonSet。例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet：
+
+{{< codenew file="controllers/daemonset.yaml" >}}
+
+* 基于 YAML 文件创建 DaemonSet:
+```
+kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
+```
+
+
### 必需字段
-
-
-
-和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。
-有关配置文件的基本信息，详见文档 [deploying applications](/docs/user-guide/deploying-applications/)、[配置容器](/docs/user-guide/configuring-containers/) 和 [资源管理](/docs/concepts/tools/kubectl/object-management-overview/) 。
+和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。有关配置文件的基本信息，详见文档 [部署应用](/docs/user-guide/deploying-applications/)、[配置容器](/docs/tasks/) 和 [使用kubectl进行对象管理](/docs/concepts/overview/object-management-kubectl/overview/) 。
DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
+
### Pod 模板
`.spec` 唯一必需的字段是 `.spec.template`。
-
-
-`.spec.template` 是一个 [Pod 模板](/docs/user-guide/replication-controller/#pod-template)。
-它与 [Pod](/docs/user-guide/pods) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
+`.spec.template` 是一个 [Pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它与 [Pod](/docs/concepts/workloads/pods/pod/) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。
在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 [`RestartPolicy`](/docs/user-guide/pod-states)，或者未指定它的值，默认是 `Always`。
-
-
+
+### Pod Selector
+
+`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 的 `.spec.selector` 的作用是相同的。
+
+从 Kubernetes 1.8开始，您必须指定与 `.spec.template` 的标签匹配的 pod selector。当不配置时，pod selector 将不再有默认值。selector 默认与 `kubectl apply` 不兼容。 此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。修改 pod selector 可能导致成为 孤儿Pod，并且这对用户来说是困惑的。
+
+
`spec.selector` 表示一个对象，它由如下两个字段组成：
* `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。
-* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表，以及与 key 和 value 列表相关的操作符。
-
-
+* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表
+，以及与 key 和 value 列表相关的操作符。
当上述两个字段都指定时，结果表示的是 AND 关系。
-如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果没有指定，它们默认是等价的。如果与它们配置的不匹配，则会被 API 拒绝。
-
-如果 Pod 的 label 与 selector 匹配，或者直接基于其它的 DaemonSet、或者 Controller（例如 ReplicationController），也不可以创建任何 Pod。
-否则 DaemonSet Controller 将认为那些 Pod 是它创建的。Kubernetes 不会阻止这样做。一个场景是，可能希望在一个具有不同值的、用来测试用的节点上手动创建 Pod。
+如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果与它们配置的不匹配，则会被 API 拒绝。
+此外，您通常不应该创建任何 pods，它们的 label 与 selector 匹配，或者直接创建，或者通过另一个 DaemonSet、或者其他控制器，比如 ReplicaSet。否则，DaemonSet 控制器会认为这些 Pod 是由它创建的。Kubernetes 不会阻止你这样做。 您可能希望这样做的一种情况是在节点上手动创建具有不同值的 Pod 以进行测试。
+
### 仅在某些节点上运行 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](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配>的节点上创建 Pod。
如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
+
+## 如何调度 Daemon Pods
+
+### 由 DaemonSet 控制器调度（从v1.12 开始默认禁用）
+
+正常情况下，Pod 运行在哪个机器上是由 Kubernetes 调度器来选择的。然而，由 DaemonSet Controller 创建的 Pod 已经确定了在哪个机器上（Pod 创建时指定了 `.spec.nodeName`，调度器会忽略它），因此：
- DaemonSet Controller 并不关心一个节点的 [`unschedulable`](/docs/admin/node/#manual-node-administration) 字段。
- DaemonSet Controller 可以创建 Pod，即使调度器还没有启动，这对集群启动是非常有帮助的。
+
+### 由默认 scheduler 调度（从v1.12开始默认开启）
+
+{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
+
+DaemonSet 确保所有符合条件的节点都运行一个 Pod 的副本。通常，运行 Pod 的节点由 Kubernetes scheduler 选择。然而，DaemonSet pods 由 DaemonSet controller 创建和调度。这将引入以下问题：
+
+ * Pod 行为的不一致性：等待调度的正常 Pod 已被创建并处于 `Pending` 状态，但 DaemonSet pods 未在 `Pending` 状态下创建。 这使用户感到困惑。
+ * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)由默认 scheduler 处理。 启用抢占后，DaemonSet 控制器将在不考虑 pod 优先级和抢占的情况下制定调度决策。
+
+
+`ScheduleDaemonSetPods` 允许您使用默认 scheduler 而不是 DaemonSet 控制器来调度 DaemonSets，方法是将 `NodeAffinity` 添加到 DaemonSet pods，而不是 `.spec.nodeName`。 然后使用默认 scheduler 将 pod 绑定到目标主机。 如果 DaemonSet pod的亲和节点已存在，则替换它。 DaemonSet 控制器仅在创建或修改 DaemonSet pods 时执行这些操作，并且不对 DaemonSet的 `spec.template` 进行任何更改。
+
+```yaml
+nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchFields:
+ - key: metadata.name
+ operator: In
+ values:
+ - target-host-name
+```
+
+
+此外，`node.kubernetes.io/unschedulable：NoSchedule` toleration 会自动添加到 DaemonSet Pods。 在调度DaemonSet Pod 时，默认调度器会忽略 `unschedulable`节点。
+
+
+### Taints and Tolerations
+
+尽管 Daemon Pods 尊重[taints and tolerations](/docs/concepts/configuration/taint-and-toleration)，根据相关特性，会自动将以下 tolerations 添加到 DaemonSet Pods 中。
+
+| Toleration Key | Effect | Version | Description |
+| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
+| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
+| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
+| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
+| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
-## 与 Daemon Pod 通信
+
+## 与 Daemon Pods 通信
与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：
- **Push**：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
-- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口。
-- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/user-guide/services/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
+- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口
+。
+- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/concepts/services-networking/service/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
- **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。
+
## 更新 DaemonSet
-如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除新近不能够匹配的节点上的 Pod。
+如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能够匹配的节点上的 Pod。
-我们可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
+您可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次
+节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
+您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
-
-可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
-
+
在 Kubernetes 1.6 或以后版本，可以在 DaemonSet 上 [执行滚动升级](/docs/tasks/manage-daemon/update-daemon-set/)。
-未来的 Kubernetes 版本将支持节点的可控更新。
+
## DaemonSet 的可替代选择
### init 脚本
我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处：
-
-
- 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
- 为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、`kubectl`）。
-- Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与节点升级工作流进行集成。
- 在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。
+
### 裸 Pod
-可能要直接创建 Pod，同时指定其运行在特定的节点上。
-然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
-
+可能要直接创建 Pod，同时指定其运行在特定的节点上。然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
+
### 静态 Pod
可能需要通过在一个指定目录下编写文件来创建 Pod，该目录受 Kubelet 所监视。这些 Pod 被称为 [静态 Pod](/docs/concepts/cluster-administration/static-pod/)。
-不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。
-而且，未来静态 Pod 可能会被废弃掉。
+不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。而且，未来静态 Pod 可能会被废弃掉。
+
+### Deployments
-DaemonSet 与 [Replication Controller](/docs/user-guide/replication-controller) 非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
-为无状态的 Service 使用 Replication Controller，比如前端（Frontend）服务，实现对副本的数量进行扩缩容、平滑升级，比之于精确控制 Pod 运行在某个主机上要重要得多。
+DaemonSet 与 [Deployments](/docs/concepts/workloads/controllers/deployment/)非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
+为无状态的 Service 使用 Deployments，比如前端 Frontend 服务，实现对副本的数量进行扩缩容、平滑升级，比基于精确控制 Pod 运行在某个主机上要重要得多。
需要 Pod 副本总是运行在全部或特定主机上，并需要先于其他 Pod 启动，当这被认为非常重要时，应该使用 Daemon Controller。
+{{% /capture %}}
diff --git a/content/zh/docs/home/_index.md b/content/zh/docs/home/_index.md
index 9a9d8b1e3f..76df61cbf8 100644
--- a/content/zh/docs/home/_index.md
+++ b/content/zh/docs/home/_index.md
@@ -2,19 +2,98 @@
title: Kubernetes 文档
layout: docsportal_home
noedit: true
-cid: userJourneys
-css: /css/style_user_journeys.css
-js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
+class: gridPage
display_browse_numbers: true
linkTitle: "主页"
main_menu: true
weight: 10
+hide_feedback: true
menu:
main:
title: "文档"
weight: 20
post: >
通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以帮助贡献文档！
+
+overview: >
+
+ Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 CNCF。
+
+
+
+cards:
+- name: concepts
+ title: "了解基本知识"
+ description: "了解 Kubernetes 和其基础概念。"
+ button: "了解概念"
+ button_path: "/zh/docs/concepts"
+- name: tutorials
+ title: "尝试 Kubernetes"
+ description: "按照教程学习如何在 Kubernetes 上部署应用。"
+ button: "查看教程"
+ button_path: "/zh/docs/tutorials"
+- name: setup
+ title: "设置集群"
+ description: "按照你的资源情况和需求运行 Kubernetes。"
+ button: "设置 Kubernetes"
+ button_path: "/zh/docs/setup"
+- name: tasks
+ title: "了解如何使用 Kubernetes"
+ description: "查看常见任务以及如何使用简单步骤执行它们。"
+ button: "查看任务"
+ button_path: "/zh/docs/tasks"
+- name: reference
+ title: 参考
+ description: 术语、命令行语法、API 资源类型和设置工具文档
+ button: 查看参考
+ button_path: /zh/docs/reference
+- name: contribute
+ title: 为该文档作出贡献
+ description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。
+ button: 参与贡献
+ button_path: /zh/docs/contribute
+- name: download
+ title: 下载 Kubernetes
+ description: 如果你正在安装或升级 Kubernetes 的话，最好参考最新的发行版说明。
+- name: about
+ title: 关于文档
+ description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。
---
+title: 动态准入控制
+content_template: templates/concept
+weight: 40
+---
+
+{{% capture overview %}}
+
+[admission 控制器文档](/docs/reference/access-authn-authz/admission-controllers/)
+介绍如何使用标准的插件式 admission 控制器。然而，
+由于以下原因插件 admission 控制器对于所有用例来说都不够灵活：
+
+* 他们需要编译到 kube-apiserver 里面。
+* 它们仅在 apiserver 启动时可配置。
+
+*Admission Webhooks*（1.9 版中的 beta）解决了这些限制。
+它允许 admission 控制器能被独立开发以及在运行时配置。
+
+本页介绍如何使用 Admission Webhooks。
+{{% /capture %}}
+
+{{% capture body %}}
+
+### 什么是 admission webhook？
+
+
+Admission webhooks 是 HTTP 回调，它接收 admission 请求并对它们做一些事情。
+您可以定义两种类型的 admission webhook，
+[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
+和
+[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
+通过 validating admission Webhook，您可以拒绝请求以执行自定义的 admission 策略。
+通过 mutating admission webhook，您可以更改请求以执行自定义的默认值。
+
+
+### 尝试 admission webhook
+
+admission webhook 本质上是集群控制平面的一部分。 您应该非常谨慎地编写和部署它们。
+如果您打算编写/部署生产级 admission webhook，请阅读[用户指南](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
+在下文中，我们将介绍如何快速试验 admission webhook。
+
+
+### 先决条件
+
+* 确保 Kubernetes 集群版本至少为 v1.9。
+
+* 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
+ [这里](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
+ 是一组推荐的 admission 控制器，通常可以启用。
+
+* 确保启用了`admissionregistration.k8s.io/v1beta1` API。
+
+
+### 编写一个admission webhook 服务器
+
+请参阅 Kubernetes e2e 测试中的
+[admission webhook 服务器](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go)实现。
+ webhook 处理由 apiservers 发送的 `admissionReview` 请求，并将其决定包含在 `admissionResponse` 中发回。
+
+`admissionReview` 请求可以有不同的版本（例如，`v1beta1` 或未来版本中的 `v1`）。
+webhook 可以使用 `admissionReviewVersions` 字段定义它们接受的版本。
+API 服务器将尝试在其支持的列表中使用第一个版本。
+如果 API 服务器不支持此列表中指定的任何版本，则此对象的验证将失败。
+如果 webhook 配置依然如此，则对 webhook 的调用将失败并受到失败策略的控制。
+
+示例 admission webhook 服务器置 `ClientAuth` 字段为
+[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，
+默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。
+如果您需要双向 TLS 或其他方式来验证客户端，请参阅如何[验证 apiservers](#验证 apiservers)。
+
+
+### 部署 admission webhook 服务
+
+e2e 测试中的 webhook 服务器部署在 Kubernetes 集群中，通过 [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1beta1-apps)。
+该测试还创建了 [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) 作为 webhook 服务器的前端。
+参见[代码](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/apimachinery/webhook.go#L227)。
+
+您还可以在集群外部署 Webhook，
+这需要相应地更新 [webhook 客户端配置](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L247)。
+
+
+### 动态配置 admission webhook
+
+您可以通过
+[ValidatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L84)
+或
+[MutatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L114)
+动态配置哪些资源通过哪些 admission webhook
+
+以下是 `validatingWebhookConfiguration` 的示例，Mutating Webhook Configuration 类似。
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1beta1
+kind: ValidatingWebhookConfiguration
+metadata:
+ name:
+webhooks:
+- name:
+ rules:
+ - apiGroups:
+ - ""
+ apiVersions:
+ - v1
+ operations:
+ - CREATE
+ resources:
+ - pods
+ scope: "Namespaced"
+ clientConfig:
+ service:
+ namespace:
+ name:
+ caBundle:
+ admissionReviewVersions:
+ - v1beta1
+ timeoutSeconds: 1
+```
+
+
+scope 字段指定是否只有集群范围的资源（“Cluster”）或命名空间范围的资源（“Namespaced”）才匹配此规则。 “*” 表示没有范围限制。
+
+{{< note >}}
+使用`clientConfig.service`时，服务器证书必须对`..svc`有效。
+{{< /note >}}
+
+{{< note >}}
+webhook 调用的默认超时为 30 秒，但从 kubernetes 1.14 开始，您可以设置超时，并鼓励对 webhook 使用非常小的超时时间。
+如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。
+{{< /note >}}
+
+当一个 apiserver 收到一个与 `rules` 之一匹配的请求时，apiserver 会向 `clientConfig` 中指定的 webhook 发送一个 `admissionReview` 请求。
+
+创建 webhook 配置后，系统将花费几秒钟来完成新配置的生效。
+
+
+### 验证 apiservers
+
+如果您的 webhooks 需要身份验证，您可以将 apiservers 配置为使用基本身份验证，不记名令牌或证书来对 webhook 进行身份验证。
+完成配置有三个步骤。
+
+* 启动apiserver时，通过 `--admission-control-config-file` 参数指定许可控制配置文件的位置。
+
+* 在准入控制配置文件中，指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。
+凭证存储在 kubeConfig 文件中（是的，与 kubectl 使用的模式相同），因此字段名称为`kubeConfigFile`。
+以下是一个示例准入控制配置文件：
+
+```yaml
+apiVersion: apiserver.k8s.io/v1alpha1
+kind: AdmissionConfiguration
+plugins:
+- name: ValidatingAdmissionWebhook
+ configuration:
+ apiVersion: apiserver.config.k8s.io/v1alpha1
+ kind: WebhookAdmission
+ kubeConfigFile:
+- name: MutatingAdmissionWebhook
+ configuration:
+ apiVersion: apiserver.config.k8s.io/v1alpha1
+ kind: WebhookAdmission
+ kubeConfigFile:
+```
+
+
+`admissionConfiguration` 的 shcema 在
+[这里](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1alpha1/types.go#L27).
+
+* 在 kubeConfig 文件中，提供凭据：
+
+```yaml
+apiVersion: v1
+kind: Config
+users:
+# DNS name of webhook service, i.e., ..svc, or the URL
+# of the webhook server.
+- name: 'webhook1.ns1.svc'
+ user:
+ client-certificate-data:
+ client-key-data:
+# The `name` supports using * to wildmatch prefixing segments.
+- name: '*.webhook-company.org'
+ user:
+ password:
+ username:
+# '*' is the default match.
+- name: '*'
+ user:
+ token:
+```
+
+
+当然，您需要设置 webhook 服务器来处理这些身份验证。
+{{% /capture %}}
diff --git a/content/zh/docs/reference/glossary/sysctl.md b/content/zh/docs/reference/glossary/sysctl.md
new file mode 100644
index 0000000000..46a6dd98f3
--- /dev/null
+++ b/content/zh/docs/reference/glossary/sysctl.md
@@ -0,0 +1,51 @@
+---
+title: sysctl
+id: sysctl
+date: 2019-02-12
+full_link: /docs/tasks/administer-cluster/sysctl-cluster/
+short_description: >
+ 用于获取和设置 Unix 内核参数的接口
+
+aka:
+tags:
+- 工具
+---
+
+
+
+
+
+ `sysctl` 是一个半标准化的接口，用于读取或更改正在运行的 Unix 内核的属性。
+
+
+
+
+
+在类 Unix 系统上， `sysctl` 既是管理员用于查看和修改这些设置的工具的名称，也是该工具所调用的系统调用的名称。
+
+
+
+{{< glossary_tooltip text="容器" term_id="container" >}} 运行时和网络插件可能对 `sysctl` 的取值有一定的要求。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md
new file mode 100644
index 0000000000..06392159d5
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md
@@ -0,0 +1,139 @@
+
+
+为控制器管理器生成要使用的 kubeconfig 文件
+
+
+### 概要
+
+
+
+生成控制器管理器要使用的 kubeconfig ，并保存到 controller-manager.conf 文件中
+
+```
+kubeadm init phase kubeconfig controller-manager [flags]
+```
+
+
+### 选项
+
+
+
+
+
+
+
+
+
+
+ | --apiserver-advertise-address 字符串 |
+
+
+ | API Server 对外发布的当前监听地址。设置此值为 “0.0.0.0” 以使用默认网络接口的 IP 地址。 |
+
+
+
+
+ | --apiserver-bind-port int32
+ 默认值: 6443 |
+
+
+ | 要绑定到 API Server 的端口。 |
+
+
+
+
+
+ | --cert-dir string 默认值: "/etc/kubernetes/pki" |
+
+
+ | 保存和存储证书的路径。 |
+
+
+
+
+ | --config string |
+
+
+ | kubeadm 配置文件的路径。警告：配置文件的使用是实验性的。 |
+
+
+
+
+ | -h, --help |
+
+
+ | controller-manager 命令的帮助 |
+
+
+
+
+ | --kubeconfig-dir string
+ 默认值: "/etc/kubernetes" |
+
+
+ | 保存 kubeconfig 的路径。 |
+
+
+
+
+
+
+
+
+### 从父命令继承的选项
+
+
+
+
+
+
+
+
+
+
+ | --rootfs 字符串 |
+
+
+ | [实验] 主机根文件系统的“真实”路径。 |
+
+
+
+
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md
new file mode 100644
index 0000000000..7da8cbebb6
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md
@@ -0,0 +1,111 @@
+
+
+将节点标记为控制平面
+
+
+### 概要
+
+
+
+将节点标记为控制平面
+
+```
+kubeadm init phase mark-control-plane [flags]
+```
+
+
+### 例子
+
+```
+ # 将控制平面的标签和污点应用于当前节点，功能上等同于 kubeadm init 执行的操作。
+ kubeadm init phase mark-control-plane --config config.yml
+
+ # 将控制平面的标签和污点应用于特定节点
+ kubeadm init phase mark-control-plane --node-name myNode
+```
+
+
+### 选项
+
+
+
+
+
+
+
+
+
+
+ | --config string |
+
+
+ | kubeadm 配置文件的路径。 警告：配置文件的使用是实验性的。 |
+
+
+
+
+
+ | -h, --help |
+
+
+ | mark-control-plane 命令的帮助 |
+
+
+
+
+
+ | --node-name string |
+
+
+ | 指定节点名称。 |
+
+
+
+
+
+
+
+
+
+### 从父命令继承的选项
+
+
+
+
+
+
+
+
+
+
+ | --rootfs 字符串 |
+
+
+ | 主机根文件系统的“真实”路径。 |
+
+
+
+
+
+
+
diff --git a/content/zh/docs/setup/independent/create-cluster-kubeadm.md b/content/zh/docs/setup/independent/create-cluster-kubeadm.md
index d1bc217ea2..b33d016833 100644
--- a/content/zh/docs/setup/independent/create-cluster-kubeadm.md
+++ b/content/zh/docs/setup/independent/create-cluster-kubeadm.md
@@ -458,35 +458,61 @@ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/
```
{{% /tab %}}
-
-
-
{{% tab name="Cilium" %}}
-有关将 Cilium 与 Kubernetes 一起使用的更多信息，请参阅[关于 Kubernetes 的 Cilium 快速入门](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) 和 [适用于 Ciliu m的 kubernetes 安装指南](http://docs.cilium.io/en/v1.2/kubernetes/install/)。
+
+有关将 Cilium 与 Kubernetes 一起使用的更多信息，请参阅[适用于 Cilium 的 Kubernetes 安装指南](https://docs.cilium.io/en/stable/kubernetes/)。
+
+为了使 Cilium 正确工作，您必须向 `kubeadm init` 传递 `--pod-network-cidr=10.217.0.0/16` 参数。
+
+以下命令将部署 Cilium，包括其运行需要的 etcd（被 etcd operator 管理）。
+
+_注意_: 如果您在单节点运行 kubeadm，您需要解除该节点的污点（untaint），以便 etcd-operator pod 能被调度到该控制节点。
+
+```shell
+kubectl taint nodes node-role.kubernetes.io/master:NoSchedule-
+```
+
+部署 Cilium，您只需执行：
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
+```
+
+一旦所有的 Cilium pod 的状态变成 `READY`，您就可以开始使用集群了。
+
+```shell
+$ kubectl get pods -n kube-system --selector=k8s-app=cilium
+NAME READY STATUS RESTARTS AGE
+cilium-drxkl 1/1 Running 0 18m
+```
{{% /tab %}}
diff --git a/content/zh/docs/tasks/federation/cluster.md b/content/zh/docs/tasks/federation/cluster.md
new file mode 100644
index 0000000000..b63438d9d2
--- /dev/null
+++ b/content/zh/docs/tasks/federation/cluster.md
@@ -0,0 +1,218 @@
+---
+title: 联邦集群
+content_template: templates/task
+---
+
+
+
+{{% capture overview %}}
+
+{{< deprecationfilewarning >}}
+{{< include "federation-deprecation-warning-note.md" >}}
+{{< /deprecationfilewarning >}}
+
+
+本指南介绍了如何在联邦控制平面中使用集群 API 资源。
+
+与其他 Kubernetes 资源（例如 Deployment，Service 和 ConfigMap）不同， 集群资源仅存在于联邦上下文中，即这些请求必须提交给联邦 api-server。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* {{< include "federated-task-tutorial-prereqs.md" >}}
+
+* 你还应该对 [Kubernetes 的工作方式](/docs/setup/pick-right-solution/)有基本的认识。
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+
+## 列出集群
+
+要列出联邦中可用的集群，可以使用 [kubectl](/docs/user-guide/kubectl/) 运行：
+
+``` shell
+kubectl --context=federation get clusters
+```
+
+`--context=federation` 参数告诉 kubectl 将请求提交到联邦 apiserver 而不是发送给 Kubernetes 集群。如果您将其提交给 k8s 集群，您将会收到如下的错误信息：
+
+```the server doesn't have a resource type "clusters"```
+
+如果您传递了正确的联邦上下文，但却收到错误消息：
+
+```No resources found.```
+
+这表示您尚未将任何集群添加到联邦。
+
+
+## 创建联邦集群
+
+在联邦中创建 `cluster` 资源意味着将其加入联邦。您也可以使用 `kubefed join` 命令实现该操作。大体上，您需要给新的集群一个名字，并指出联邦主集群对应的上下文名称。以下示例命令将集群 `gondor` 加入运行于主集群 `rivendell` 上的联邦中：
+
+``` shell
+kubefed join gondor --host-cluster-context=rivendell
+```
+
+您可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation)的相应部分找到更多关于如何做到这一点的详细介绍。
+
+
+
+## 删除联邦集群
+
+与创建集群相反，删除集群表示将集群从联邦中退出。这可以通过 `kubefed unjoin` 完成。要删除 `gondor` 集群，只需要执行：
+
+``` shell
+kubefed unjoin gondor --host-cluster-context=rivendell
+```
+
+您可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation)中找到更多关于 unjoin 的详细介绍。
+
+
+## 标记集群
+
+您可以使用与其它 Kubernetes 对象相同的方式标记集群，这有助于集群分组，也可以被 ClusterSelector 利用。
+
+``` shell
+kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
+```
+
+
+## ClusterSelector 注解
+
+从 Kubernetes 1.7 版本开始，alpha 支持通过注解 `federation.alpha.kubernetes.io/cluster-selector` 来指示跨联邦集群的对象。*ClusterSelector* 在概念上与 `nodeSelector` 类似，但不是针对节点上的标签进行选择，而是针对联邦集群上的标签进行选择。
+
+注解值必须为 JSON 格式，并且必须可以解析为 [ClusterSelector API 类型](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector)。例如：`[{"key": "load", "operator": "Lt", "values": ["10"]}]`。无法正确解析的内容将引发错误并阻止将对象分发到任何联邦集群。Alpha 实现中包含 ConfigMap、Secret、Daemonset、Service 和 Ingress 类型的对象。
+
+下面是一个 ClusterSelector 注解的示例，它只会选择带有 `pci=true` 且没有 `environment=test` 的集群：
+
+``` yaml
+ metadata:
+ annotations:
+ federation.alpha.kubernetes.io/cluster-selector: '[{"key": "pci", "operator":
+ "In", "values": ["true"]}, {"key": "environment", "operator": "NotIn", "values":
+ ["test"]}]'
+```
+
+*key* 用于匹配联邦集群上的标签名。
+
+*values* 用于匹配联邦集群上的标签值。
+
+可能的 *operator* 有：`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`。
+
+当指定 `Exists` 或 `DoesNotExist` 时，*values* 字段应为空。使用 `In` 或 `NotIn` 时，可能包含多个字符串。
+
+目前，`Gt` 或 `Lt` 仅支持整数。
+
+
+
+## 集群 API 参考
+
+完整的集群 API 参考在 `federation/v1beta1` 中，更多细节可以在 [联邦 API 参考页面](/docs/reference/federation/)找到。
+
+{{% /capture %}}
+
+
diff --git a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
index eb1666d873..7e6171358b 100644
--- a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -1,22 +1,41 @@
---
-approvers:
+reviewers:
- derekwaynecarr
title: 管理巨页（HugePages）
content_template: templates/task
---
+
{{% capture overview %}}
-{{< feature-state state="alpha" >}}
+{{< feature-state state="stable" >}}
-作为 **alpha** 特性，Kubernetes 支持在 Pod 应用中使用预先分配的巨页（或称“大页面”，下文统称为“巨页”）。 本文描述了用户如何使用巨页，以及当前的限制。
+
+作为 **GA** 特性，Kubernetes 支持在 Pod 应用中使用预先分配的巨页。本文描述了用户如何使用巨页，以及当前的限制。
{{% /capture %}}
{{% capture prerequisites %}}
-1. 为了使节点能够上报巨页容量，Kubernetes 节点必须预先分配巨页。
- 每个节点只能预先分配一种特定规格的巨页。
-1. 用户必须在整个系统中将专用的 **alpha** 特性开关 `HugePages` 设置为 true： `--feature-gates=HugePages=true`。
+
+1. 为了使节点能够上报巨页容量，Kubernetes 节点必须预先分配巨页。每个节点只能预先分配一种特定规格的巨页。
节点会自动发现全部巨页资源，并作为可供调度的资源进行上报。
@@ -26,7 +45,18 @@ content_template: templates/task
## API
+
+
用户可以通过在容器级别的资源需求中使用资源名称 `hugepages-` 来使用巨页，其中的 size 是特定节点上支持的以整数值表示的最小二进制单位。 例如，如果节点支持 2048KiB 的页面规格， 它将暴露可供调度的资源 `hugepages-2Mi`。 与 CPU 或内存不同，巨页不支持过量使用（overcommit）。
+注意，在请求巨页资源时，还必须请求内存或 CPU 资源。
```yaml
apiVersion: v1
@@ -46,23 +76,49 @@ spec:
resources:
limits:
hugepages-2Mi: 100Mi
+ memory: 100Mi
+ requests:
+ memory: 100Mi
volumes:
- name: hugepage
emptyDir:
medium: HugePages
```
-- 巨页的资源需求和限制必须相等。 该条件在指定了资源限制，而没有指定需求的情况下默认成立。
+
+
+- 巨页的资源请求值必须等于其限制值。该条件在指定了资源限制，而没有指定请求的情况下默认成立。
- 巨页是被隔离在 pod 作用域的，计划在将来的迭代中实现容器级别的隔离。
-- 巨页对 EmptyDir 卷提供支持，EmptyDir 卷所使用的巨页，不能够超出 pod 请求的内存容量。
+- 巨页可用于 EmptyDir 卷，不过 EmptyDir 卷所使用的巨页数量不能够超出 Pod 请求的巨页数量。
- 通过带有 `SHM_HUGETLB` 的 `shmget()` 使用巨页的应用，必须运行在一个与
`proc/sys/vm/hugetlb_shm_group` 匹配的补充组下。
+- 通过 ResourceQuota 资源，可以使用 `hugepages-` 标记控制每个命名空间下的巨页使用量，
+ 类似于使用 `cpu` 或 `memory` 来控制其他计算资源。
-## （待实现的）特性
+
+
+## 待实现的特性
- 在 pod 级别隔离的基础上，支持巨页在容器级别的隔离。
- 作为服务质量特性，保证巨页的 NUMA 局部性。
-- 支持 ResourceQuota 。
- 支持 LimitRange 。
{{% /capture %}}
diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md
index 1928131edc..0c99aa6d98 100644
--- a/content/zh/docs/tutorials/_index.md
+++ b/content/zh/docs/tutorials/_index.md
@@ -17,7 +17,7 @@ content_template: templates/concept
{{% capture overview %}}
Kubernetes 文档的这一部分包含教程。一个教程展示了如何完成一个比单个[任务](/docs/tasks/)更大的目标。
-通常，通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
+通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
您可能希望将[标准化术语表](/docs/reference/glossary/)页面添加到书签，供以后参考。
+强烈建议不要使用`联邦 v1 版本`，`联邦 v1 版本`从未达到 GA 状态，且不再处于积极开发阶段。文档仅作为历史参考。
+
+有关更多信息，请参阅预期的替代品 [Kubernetes 联邦 v2 版本](https://github.com/kubernetes-sigs/federation-v2)。
\ No newline at end of file