From abcee2dccd17c94376595b34cc05e56345a7f06c Mon Sep 17 00:00:00 2001
From: Zach Corleissen <zacharysarah@users.noreply.github.com>
Date: Fri, 12 Oct 2018 14:25:01 -0700
Subject: [PATCH] Update localization guidelines (#10485)

* Update localization guidelines for language labels

Continuing work

Continuing work

Continuing work

More work in progress

Add local OWNERS folders

Add an OWNERS file to Chinese

Remove shortcode for repos

Add Japanese

Alphabetize languages, change weights accordingly

More updates

Add Korean in Korean

Add English to languageName

Feedback from gochist

Move Chinese content from cn/ to zh/

Move OWNERS from cn/ to zh/

Resolve merge conflicts by updating from master

Add files back in to prep for resolution

After rebase on upstream/master, remove files

Review and update localization guidelines

Feedback from gochist, tnir, cstoku

Add a trailing newline to content/ja/OWNERS

Add a trailing newline to content/zh/OWNERS

Drop requirement for GH repo project

Clarify language about forks/branches

Edits and typos

Remove a shortcode specific to a multi-repo language setup

Update aliases and owners

Add explicit OWNERS for content/en

Migrate content from Chinese repo, update regex in config.toml

Remove untranslated strings

Add trailing newline to content/en/OWNERS

Add trailing newlines to OWNERS files

add Jaguar project description (#10433)

* add Jaguar project description

[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.

* Minor newline tweak

blog post for azure vmss (#10538)

Add microk8s to pick-right-solution.md (#10542)

* Add microk8s to pick-right-solution.md

Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.

* capitalized Istio

Add microk8s to foundational.md (#10543)

* Add microk8s to foundational.md

Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.

* Update foundational.md

Thank you for your suggestions! LMK if this works now?

* Rewrote first paragraph

And included a bullet list of features of microk8s

* Copyedit

fix typo (#10545)

Fix the kubectl subcommands links. (#10550)

Signed-off-by: William Zhang <warmchang@outlook.com>

Fix command issue (#10515)

Signed-off-by: mooncake <xcoder@tenxcloud.com>

remove imported community files per issue 10184 (#10501)

networking.md: Markdown fix (#10498)

Fix front matter, federation command-line tools (#10500)

Clean up glossary entry (#10399)

update slack link (#10536)

typo in StatefulSet docs (#10558)

fix discription about horizontal pod autoscale (#10557)

Remove redundant symbols (#10556)

Fix issue #10520 (#10554)

Signed-off-by: William Zhang <warmchang@outlook.com>

Update api-concepts.md (#10534)

Revert "Fix command issue (#10515)"

This reverts commit c02a7fb9f9d19872d9227814b3e9ffaaa28d85f0.

Update memory-constraint-namespace.md (#10530)

update memory request to 100MiB corresponding the yaml content

Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)

* blog post for azure vmss

* snapshot blog post

Resolve merge conflicts in OWNERS*

Minor typo fix (#10567)

Not sure what's supposed to be here, proposing removing it.

* Feedback from gochist

Tweaks to feedback

* Feedback from ClaudiaJKang
---
 OWNERS_ALIASES                                |  30 +
 config.toml                                   |  26 +-
 .../includes/default-storage-class-prereqs.md |   6 -
 .../federated-task-tutorial-prereqs.md        |   8 -
 .../cn/includes/federation-content-moved.md   |   2 -
 .../cn/includes/federation-current-state.md   |   7 -
 content/cn/includes/index.md                  |   3 -
 content/cn/includes/task-tutorial-prereqs.md  |   8 -
 .../cn/includes/user-guide-content-moved.md   |   3 -
 .../includes/user-guide-migration-notice.md   |  12 -
 content/en/OWNERS                             |  11 +
 content/en/docs/contribute/localization.md    | 173 +++--
 content/ja/OWNERS                             |  11 +
 content/ko/OWNERS                             |  11 +
 content/zh/OWNERS                             |  11 +
 content/{cn => zh}/_index.html                |   0
 ...16-04-00-Kubernetes-Network-Policy-APIs.md | 182 +++++
 .../_posts/2016-04-00-Kubernetes-On-Aws_15.md | 129 ++++
 ...3-00-Principles-Of-Container-App-Design.md |  81 +++
 .../2018-06-28-Airflow-Kubernetes-Operator.md | 676 ++++++++++++++++++
 ...18-07-09-IPVS-In-Cluster-Load-Balancing.md | 401 +++++++++++
 content/{cn => zh}/docs/.gitkeep              |   0
 content/{cn => zh}/docs/_index.md             |   0
 .../docs/admin/accessing-the-api.md           |   0
 .../docs/admin/authorization/_index.md        |   0
 .../docs/admin/authorization/abac.md          |   0
 .../docs/admin/authorization/webhook.md       |   0
 .../{cn => zh}/docs/admin/bootstrap-tokens.md |   0
 .../{cn => zh}/docs/admin/cluster-large.md    |   0
 content/{cn => zh}/docs/admin/daemon.yaml     |   0
 .../docs/admin/high-availability/_index.md    |   0
 .../{cn => zh}/docs/admin/kube-apiserver.md   |   0
 .../kubelet-authentication-authorization.md   |   0
 .../docs/admin/kubelet-tls-bootstrapping.md   |   0
 .../{cn => zh}/docs/admin/multiple-zones.md   |   0
 .../{cn => zh}/docs/admin/node-conformance.md |   0
 .../{cn => zh}/docs/admin/ovs-networking.md   |   0
 .../docs/admin/service-accounts-admin.md      |   0
 .../concepts/architecture/cloud-controller.md |   0
 .../architecture/master-node-communication.md |   0
 .../docs/concepts/architecture/nodes.md       |   0
 .../concepts/cluster-administration/addons.md |   0
 .../cluster-administration/certificates.md    |   0
 .../cluster-administration/cloud-providers.md |   0
 .../cluster-administration-overview.md        |   0
 .../cluster-administration/device-plugins.md  |   0
 .../cluster-administration/federation.md      |   0
 .../cluster-administration/proxies.md         |   0
 .../cluster-administration/sysctl-cluster.md  |   0
 .../docs/concepts/configuration/commands.yaml |   0
 .../manage-compute-resources-container.md     |   0
 .../configuration/pod-with-node-affinity.yaml |   0
 .../configuration/pod-with-pod-affinity.yaml  |   0
 .../docs/concepts/configuration/pod.yaml      |   0
 .../docs/concepts/configuration/secret.md     |   2 +-
 .../configuration/taint-and-toleration.md     | 464 ++++++++++++
 .../container-environment-variables.md        |   0
 .../docs/concepts/containers/images.md        |   2 +-
 .../docs/concepts/example-concept-template.md |   0
 .../docs/concepts/overview/components.md      |   0
 .../docs/concepts/overview/kubernetes-api.md  |   0
 .../concepts/overview/what-is-kubernetes.md   |   0
 .../kubernetes-objects.md                     |   0
 .../nginx-deployment.yaml                     |   0
 .../concepts/policy/pod-security-policy.md    |   0
 .../{cn => zh}/docs/concepts/policy/psp.yaml  |   0
 .../docs/concepts/policy/resource-quotas.md   |   0
 ...ries-to-pod-etc-hosts-with-host-aliases.md |   0
 .../connect-applications-service.md           |   0
 .../concepts/services-networking/curlpod.yaml |   0
 .../services-networking/dns-pod-service.md    |   0
 .../services-networking/hostaliases-pod.yaml  |   0
 .../concepts/services-networking/ingress.yaml |   0
 .../services-networking/network-policies.md   |   0
 .../services-networking/nginx-secure-app.yaml |   0
 .../services-networking/nginx-svc.yaml        |   0
 .../services-networking/run-my-nginx.yaml     |   0
 .../concepts/services-networking/service.md   |   0
 .../workloads/controllers/cron-jobs.md        |   0
 .../workloads/controllers/daemonset.md        |   0
 .../workloads/controllers/daemonset.yaml      |   0
 .../workloads/controllers/deployment.md       |   0
 .../workloads/controllers/frontend.yaml       |   0
 .../controllers/garbage-collection.md         |   0
 .../workloads/controllers/hpa-rs.yaml         |   0
 .../concepts/workloads/controllers/job.yaml   |   0
 .../workloads/controllers/my-repset.yaml      |   0
 .../controllers/nginx-deployment.yaml         |   0
 .../workloads/controllers/replication.yaml    |   0
 .../workloads/pods/init-containers.md         |   0
 .../concepts/workloads/pods/pod-lifecycle.md  |   0
 .../docs/concepts/workloads/pods/podpreset.md |   0
 .../getting-started-guides/ubuntu/security.md |  68 ++
 .../admission-controllers.md                  | 563 +++++++++++++++
 .../access-authn-authz/authorization.md       | 304 ++++++++
 .../kube-proxy.md                             | 491 +++++++++++++
 .../kube-scheduler.md                         | 380 ++++++++++
 .../command-line-tools-reference/kubelet.md   | 112 +++
 content/zh/docs/reference/kubectl/kubectl.md  | 178 +++++
 .../reference/labels-annotations-taints.md    |   0
 content/zh/docs/reference/tools.md            | 112 +++
 content/zh/docs/setup/salt.md                 | 244 +++++++
 .../access-cluster.md                         | 573 +++++++++++++++
 ...icate-containers-same-pod-shared-volume.md |   0
 .../configure-access-multiple-clusters.md     |   0
 .../configure-cloud-provider-firewall.md      |   0
 .../configure-dns-cluster.md                  |  26 +
 .../connecting-frontend-backend.md            |   2 +-
 .../create-external-load-balancer.md          | 322 +++++++++
 .../access-application-cluster/frontend.yaml  |   0
 .../frontend/frontend.conf                    |   0
 .../hello-service.yaml                        |   0
 .../access-application-cluster/hello.yaml     |   0
 .../list-all-running-container-images.md      | 193 +++++
 ...load-balance-access-application-cluster.md | 190 +++++
 ...port-forward-access-application-cluster.md | 222 ++++++
 .../redis-master.yaml                         |   0
 .../service-access-application-cluster.md     | 225 ++++++
 .../two-container-pod.yaml                    |   0
 .../setup-extension-api-server.md             | 112 +++
 .../access-cluster-services.md                |   0
 .../apply-resource-quota-limit.md             |   0
 .../calico-network-policy.md                  |   0
 .../change-default-storage-class.md           |   0
 .../change-pv-reclaim-policy.md               |   0
 .../administer-cluster/cluster-management.md  |   0
 .../cpu-constraints-pod-2.yaml                |   0
 .../cpu-constraints-pod-3.yaml                |   0
 .../cpu-constraints-pod-4.yaml                |   0
 .../cpu-constraints-pod.yaml                  |   0
 .../administer-cluster/cpu-constraints.yaml   |   0
 .../cpu-defaults-pod-2.yaml                   |   0
 .../cpu-defaults-pod-3.yaml                   |   0
 .../administer-cluster/cpu-defaults-pod.yaml  |   0
 .../administer-cluster/cpu-defaults.yaml      |   0
 .../cpu-management-policies.md                |   0
 .../administer-cluster/cpu-memory-limit.md    |   2 +-
 .../declare-network-policy.md                 |   0
 .../dns-custom-nameservers.md                 |   0
 .../dns-horizontal-autoscaler.yaml            |   0
 .../tasks/administer-cluster/encrypt-data.md  | 323 +++++++++
 ...aranteed-scheduling-critical-addon-pods.md |   0
 .../kubeadm/kubeadm-upgrade-1-9.md            | 453 ++++++++++++
 .../administer-cluster/kubelet-config-file.md |   0
 .../memory-constraints-pod-2.yaml             |   0
 .../memory-constraints-pod-3.yaml             |   0
 .../memory-constraints-pod-4.yaml             |   0
 .../memory-constraints-pod.yaml               |   0
 .../memory-constraints.yaml                   |   0
 .../memory-defaults-pod-2.yaml                |   2 +-
 .../memory-defaults-pod-3.yaml                |   0
 .../memory-defaults-pod.yaml                  |   0
 .../administer-cluster/memory-defaults.yaml   |   0
 .../administer-cluster/my-scheduler.yaml      |   0
 .../calico-network-policy.md                  |  86 +++
 .../cilium-network-policy.md                  | 133 ++++
 .../kube-router-network-policy.md             |  31 +
 .../romana-network-policy.md                  |  57 ++
 .../weave-network-policy.md                   |  78 ++
 .../docs/tasks/administer-cluster/pod1.yaml   |   0
 .../docs/tasks/administer-cluster/pod2.yaml   |   0
 .../docs/tasks/administer-cluster/pod3.yaml   |   0
 .../quota-mem-cpu-pod-2.yaml                  |   0
 .../administer-cluster/quota-mem-cpu-pod.yaml |   0
 .../administer-cluster/quota-mem-cpu.yaml     |   0
 .../quota-objects-pvc-2.yaml                  |   0
 .../administer-cluster/quota-objects-pvc.yaml |   0
 .../administer-cluster/quota-objects.yaml     |   0
 .../quota-pod-deployment.yaml                 |   0
 .../administer-cluster/quota-pod-namespace.md |   0
 .../tasks/administer-cluster/quota-pod.yaml   |   0
 .../tasks/administer-cluster/quota-pvc-2.yaml |   0
 .../romana-network-policy.md                  |   0
 .../tasks/administer-cluster/static-pod.md    |   0
 .../administer-cluster/sysctl-cluster.md      | 329 +++++++++
 .../weave-network-policy.md                   |   0
 .../assign-pods-nodes.md                      | 135 ++++
 .../cpu-request-limit-2.yaml                  |   0
 .../cpu-request-limit.yaml                    |   0
 .../exec-liveness.yaml                        |   0
 .../http-liveness.yaml                        |   0
 .../init-containers.yaml                      |   0
 .../lifecycle-events.yaml                     |   0
 .../mem-limit-range.yaml                      |   0
 .../memory-request-limit-2.yaml               |   0
 .../memory-request-limit-3.yaml               |   0
 .../memory-request-limit.yaml                 |   0
 .../configure-pod-container/oir-pod-2.yaml    |   0
 .../configure-pod-container/oir-pod.yaml      |   0
 .../opaque-integer-resource.md                |   0
 .../configure-pod-container/pod-redis.yaml    |   0
 .../tasks/configure-pod-container/pod.yaml    |   0
 .../private-reg-pod.yaml                      |   0
 .../projected-volume.yaml                     |   0
 .../configure-pod-container/qos-pod-2.yaml    |   0
 .../configure-pod-container/qos-pod-3.yaml    |   0
 .../configure-pod-container/qos-pod-4.yaml    |   0
 .../configure-pod-container/qos-pod.yaml      |   0
 .../rq-compute-resources.yaml                 |   0
 .../security-context-2.yaml                   |   0
 .../security-context-3.yaml                   |   0
 .../security-context-4.yaml                   |   0
 .../security-context.yaml                     |   0
 .../task-pv-claim.yaml                        |   0
 .../configure-pod-container/task-pv-pod.yaml  |   0
 .../task-pv-volume.yaml                       |   0
 .../tcp-liveness-readiness.yaml               |   0
 .../tasks/debug-application-cluster/audit.md  | 612 ++++++++++++++++
 .../debug-application.md                      |   0
 .../debug-cluster.md                          |   0
 .../debug-pod-replication-controller.md       |   0
 .../debug-stateful-set.md                     |   0
 .../inject-data-application/commands.yaml     |   0
 .../dapi-envars-container.yaml                |   0
 .../dapi-envars-pod.yaml                      |   0
 .../dapi-volume-resources.yaml                |   0
 .../inject-data-application/dapi-volume.yaml  |   0
 .../define-command-argument-container.md      |   0
 .../define-environment-variable-container.md  |   2 +-
 .../distribute-credentials-secure.md          |   0
 ...nward-api-volume-expose-pod-information.md |   2 +-
 .../tasks/inject-data-application/envars.yaml |   0
 ...ronment-variable-expose-pod-information.md |   0
 .../podpreset-allow-db-merged.yaml            |   0
 .../podpreset-allow-db.yaml                   |   0
 .../podpreset-configmap.yaml                  |   0
 .../podpreset-conflict-pod.yaml               |   0
 .../podpreset-conflict-preset.yaml            |   0
 .../podpreset-merged.yaml                     |   0
 .../podpreset-multi-merged.yaml               |   0
 .../podpreset-pod.yaml                        |   0
 .../podpreset-preset.yaml                     |   0
 .../podpreset-proxy.yaml                      |   0
 .../podpreset-replicaset-merged.yaml          |   0
 .../podpreset-replicaset.yaml                 |   0
 .../inject-data-application/podpreset.md      |   0
 .../secret-envars-pod.yaml                    |   0
 .../inject-data-application/secret-pod.yaml   |   0
 .../tasks/inject-data-application/secret.yaml |   0
 .../fine-parallel-processing-work-queue.md    | 380 ++++++++++
 .../manage-daemon/rollback-daemon-set.md      |   0
 .../docs/tasks/manage-gpus/scheduling-gpus.md |   0
 .../manage-hugepages/scheduling-hugepages.md  |   0
 .../deployment-patch-demo.yaml                |   0
 .../run-application/deployment-scale.yaml     |   0
 .../run-application/deployment-update.yaml    |   0
 .../tasks/run-application/deployment.yaml     |   0
 .../tasks/run-application/gce-volume.yaml     |   0
 .../run-application/mysql-configmap.yaml      |   0
 .../run-application/mysql-deployment.yaml     |   0
 .../tasks/run-application/mysql-services.yaml |   0
 .../run-application/mysql-statefulset.yaml    |   0
 .../rolling-update-replication-controller.md  |   0
 ...un-single-instance-stateful-application.md |   0
 .../run-stateless-application-deployment.md   |   0
 .../run-application/scale-stateful-set.md     |   0
 .../docs/tasks/tls/certificate-rotation.md    |   0
 content/{cn => zh}/docs/templates/index.md    |   0
 .../configure-redis-using-configmap.md        |   0
 .../tutorials/kubernetes-basics/_index.html   |   0
 .../cluster-interactive.html                  |   0
 .../kubernetes-basics/cluster-intro.html      |   0
 .../kubernetes-basics/deploy-interactive.html |   0
 .../kubernetes-basics/deploy-intro.html       |   0
 .../explore-interactive.html                  |   0
 .../kubernetes-basics/explore-intro.html      |   0
 .../kubernetes-basics/expose-interactive.html |   0
 .../kubernetes-basics/expose-intro.html       |   0
 .../kubernetes-basics/scale-interactive.html  |   0
 .../kubernetes-basics/scale-intro.html        |   0
 .../kubernetes-basics/scale/scale-intro.html  | 136 ++++
 .../kubernetes-basics/update-interactive.html |   0
 .../kubernetes-basics/update-intro.html       |   0
 .../imperative-object-management-command.md   |   0
 .../object-management.md                      |   0
 .../docs/tutorials/services/source-ip.md      |   4 +-
 .../tutorials/stateful-application/Dockerfile |   0
 .../tutorials/stateful-application/FETCH_HEAD |   0
 .../basic-stateful-set.md                     |   3 +-
 .../cassandra-service.yaml                    |   0
 .../cassandra-statefulset.yaml                |   0
 .../stateful-application/cassandra.md         |   0
 .../docs/tutorials/stateful-application/dev   |   0
 .../mysql-wordpress-persistent-volume.md      |   4 +-
 .../local-volumes.yaml                        |   0
 .../mysql-deployment.yaml                     |   0
 .../wordpress-deployment.yaml                 |   0
 .../tutorials/stateful-application/web.yaml   |   0
 .../tutorials/stateful-application/webp.yaml  |   0
 .../stateful-application/zookeeper.md         |   0
 .../stateful-application/zookeeper.yaml       |   0
 .../docs/user-guide/bad-nginx-deployment.yaml |   0
 .../{cn => zh}/docs/user-guide/curlpod.yaml   |   0
 .../docs/user-guide/deployment.yaml           |   0
 .../docs/user-guide/docker-cli-to-kubectl.md  |   0
 .../{cn => zh}/docs/user-guide/ingress.yaml   |   0
 content/{cn => zh}/docs/user-guide/job.yaml   |   0
 .../{cn => zh}/docs/user-guide/jsonpath.md    |   0
 .../docs/user-guide/kubectl-overview.md       |   0
 .../{cn => zh}/docs/user-guide/multi-pod.yaml |   0
 .../docs/user-guide/new-nginx-deployment.yaml |   0
 .../{cn => zh}/docs/user-guide/nginx-app.yaml |   0
 .../docs/user-guide/nginx-deployment.yaml     |   0
 .../user-guide/nginx-init-containers.yaml     |   0
 .../nginx-lifecycle-deployment.yaml           |   0
 .../user-guide/nginx-probe-deployment.yaml    |   0
 .../docs/user-guide/nginx-secure-app.yaml     |   0
 .../{cn => zh}/docs/user-guide/nginx-svc.yaml |   0
 .../docs/user-guide/pod-w-message.yaml        |   0
 content/{cn => zh}/docs/user-guide/pod.yaml   |   0
 .../docs/user-guide/redis-deployment.yaml     |   0
 .../user-guide/redis-resource-deployment.yaml |   0
 .../user-guide/redis-secret-deployment.yaml   |   0
 .../docs/user-guide/run-my-nginx.yaml         |   0
 content/{cn => zh}/docs/whatisk8s.md          |   0
 layouts/shortcodes/language-repos-list.html   |  38 -
 316 files changed, 9222 insertions(+), 164 deletions(-)
 delete mode 100644 content/cn/includes/default-storage-class-prereqs.md
 delete mode 100644 content/cn/includes/federated-task-tutorial-prereqs.md
 delete mode 100644 content/cn/includes/federation-content-moved.md
 delete mode 100644 content/cn/includes/federation-current-state.md
 delete mode 100644 content/cn/includes/index.md
 delete mode 100644 content/cn/includes/task-tutorial-prereqs.md
 delete mode 100644 content/cn/includes/user-guide-content-moved.md
 delete mode 100644 content/cn/includes/user-guide-migration-notice.md
 create mode 100644 content/en/OWNERS
 create mode 100644 content/ja/OWNERS
 create mode 100644 content/ko/OWNERS
 create mode 100644 content/zh/OWNERS
 rename content/{cn => zh}/_index.html (100%)
 create mode 100644 content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md
 create mode 100644 content/zh/blog/_posts/2016-04-00-Kubernetes-On-Aws_15.md
 create mode 100644 content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md
 create mode 100644 content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
 create mode 100644 content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md
 rename content/{cn => zh}/docs/.gitkeep (100%)
 rename content/{cn => zh}/docs/_index.md (100%)
 rename content/{cn => zh}/docs/admin/accessing-the-api.md (100%)
 rename content/{cn => zh}/docs/admin/authorization/_index.md (100%)
 rename content/{cn => zh}/docs/admin/authorization/abac.md (100%)
 rename content/{cn => zh}/docs/admin/authorization/webhook.md (100%)
 rename content/{cn => zh}/docs/admin/bootstrap-tokens.md (100%)
 rename content/{cn => zh}/docs/admin/cluster-large.md (100%)
 rename content/{cn => zh}/docs/admin/daemon.yaml (100%)
 rename content/{cn => zh}/docs/admin/high-availability/_index.md (100%)
 rename content/{cn => zh}/docs/admin/kube-apiserver.md (100%)
 rename content/{cn => zh}/docs/admin/kubelet-authentication-authorization.md (100%)
 rename content/{cn => zh}/docs/admin/kubelet-tls-bootstrapping.md (100%)
 rename content/{cn => zh}/docs/admin/multiple-zones.md (100%)
 rename content/{cn => zh}/docs/admin/node-conformance.md (100%)
 rename content/{cn => zh}/docs/admin/ovs-networking.md (100%)
 rename content/{cn => zh}/docs/admin/service-accounts-admin.md (100%)
 rename content/{cn => zh}/docs/concepts/architecture/cloud-controller.md (100%)
 rename content/{cn => zh}/docs/concepts/architecture/master-node-communication.md (100%)
 rename content/{cn => zh}/docs/concepts/architecture/nodes.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/addons.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/certificates.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/cloud-providers.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/cluster-administration-overview.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/device-plugins.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/federation.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/proxies.md (100%)
 rename content/{cn => zh}/docs/concepts/cluster-administration/sysctl-cluster.md (100%)
 rename content/{cn => zh}/docs/concepts/configuration/commands.yaml (100%)
 rename content/{cn => zh}/docs/concepts/configuration/manage-compute-resources-container.md (100%)
 rename content/{cn => zh}/docs/concepts/configuration/pod-with-node-affinity.yaml (100%)
 rename content/{cn => zh}/docs/concepts/configuration/pod-with-pod-affinity.yaml (100%)
 rename content/{cn => zh}/docs/concepts/configuration/pod.yaml (100%)
 rename content/{cn => zh}/docs/concepts/configuration/secret.md (98%)
 create mode 100755 content/zh/docs/concepts/configuration/taint-and-toleration.md
 rename content/{cn => zh}/docs/concepts/containers/container-environment-variables.md (100%)
 rename content/{cn => zh}/docs/concepts/containers/images.md (99%)
 rename content/{cn => zh}/docs/concepts/example-concept-template.md (100%)
 rename content/{cn => zh}/docs/concepts/overview/components.md (100%)
 rename content/{cn => zh}/docs/concepts/overview/kubernetes-api.md (100%)
 rename content/{cn => zh}/docs/concepts/overview/what-is-kubernetes.md (100%)
 rename content/{cn => zh}/docs/concepts/overview/working-with-objects/kubernetes-objects.md (100%)
 rename content/{cn => zh}/docs/concepts/overview/working-with-objects/nginx-deployment.yaml (100%)
 rename content/{cn => zh}/docs/concepts/policy/pod-security-policy.md (100%)
 rename content/{cn => zh}/docs/concepts/policy/psp.yaml (100%)
 rename content/{cn => zh}/docs/concepts/policy/resource-quotas.md (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/connect-applications-service.md (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/curlpod.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/dns-pod-service.md (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/hostaliases-pod.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/ingress.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/network-policies.md (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/nginx-secure-app.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/nginx-svc.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/run-my-nginx.yaml (100%)
 rename content/{cn => zh}/docs/concepts/services-networking/service.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/cron-jobs.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/daemonset.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/daemonset.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/deployment.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/frontend.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/garbage-collection.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/hpa-rs.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/job.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/my-repset.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/nginx-deployment.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/controllers/replication.yaml (100%)
 rename content/{cn => zh}/docs/concepts/workloads/pods/init-containers.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/pods/pod-lifecycle.md (100%)
 rename content/{cn => zh}/docs/concepts/workloads/pods/podpreset.md (100%)
 create mode 100644 content/zh/docs/getting-started-guides/ubuntu/security.md
 create mode 100755 content/zh/docs/reference/access-authn-authz/admission-controllers.md
 create mode 100644 content/zh/docs/reference/access-authn-authz/authorization.md
 create mode 100644 content/zh/docs/reference/command-line-tools-reference/kube-proxy.md
 create mode 100644 content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md
 create mode 100644 content/zh/docs/reference/command-line-tools-reference/kubelet.md
 create mode 100644 content/zh/docs/reference/kubectl/kubectl.md
 rename content/{cn => zh}/docs/reference/labels-annotations-taints.md (100%)
 create mode 100644 content/zh/docs/reference/tools.md
 create mode 100755 content/zh/docs/setup/salt.md
 create mode 100644 content/zh/docs/tasks/access-application-cluster/access-cluster.md
 rename content/{cn => zh}/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md (100%)
 rename content/{cn => zh}/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md (100%)
 rename content/{cn => zh}/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md (100%)
 create mode 100644 content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md
 rename content/{cn => zh}/docs/tasks/access-application-cluster/connecting-frontend-backend.md (98%)
 create mode 100644 content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
 rename content/{cn => zh}/docs/tasks/access-application-cluster/frontend.yaml (100%)
 rename content/{cn => zh}/docs/tasks/access-application-cluster/frontend/frontend.conf (100%)
 rename content/{cn => zh}/docs/tasks/access-application-cluster/hello-service.yaml (100%)
 rename content/{cn => zh}/docs/tasks/access-application-cluster/hello.yaml (100%)
 create mode 100644 content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
 create mode 100644 content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
 create mode 100644 content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
 rename content/{cn => zh}/docs/tasks/access-application-cluster/redis-master.yaml (100%)
 create mode 100644 content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
 rename content/{cn => zh}/docs/tasks/access-application-cluster/two-container-pod.yaml (100%)
 create mode 100644 content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
 rename content/{cn => zh}/docs/tasks/administer-cluster/access-cluster-services.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/apply-resource-quota-limit.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/calico-network-policy.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/change-default-storage-class.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/change-pv-reclaim-policy.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cluster-management.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-constraints-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-constraints-pod-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-constraints-pod-4.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-constraints-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-constraints.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-defaults-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-defaults-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-defaults.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-management-policies.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/cpu-memory-limit.md (99%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/declare-network-policy.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/dns-custom-nameservers.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml (100%)
 create mode 100644 content/zh/docs/tasks/administer-cluster/encrypt-data.md
 rename content/{cn => zh}/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md (100%)
 create mode 100644 content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md
 rename content/{cn => zh}/docs/tasks/administer-cluster/kubelet-config-file.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-constraints-pod-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-constraints-pod-4.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-constraints-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-constraints.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml (81%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-defaults-pod-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-defaults-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/memory-defaults.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/my-scheduler.yaml (100%)
 create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
 create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
 create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
 create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
 create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
 rename content/{cn => zh}/docs/tasks/administer-cluster/pod1.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/pod2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/pod3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-mem-cpu.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-objects-pvc-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-objects-pvc.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-objects.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-pod-deployment.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-pod-namespace.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/quota-pvc-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/romana-network-policy.md (100%)
 rename content/{cn => zh}/docs/tasks/administer-cluster/static-pod.md (100%)
 create mode 100644 content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
 rename content/{cn => zh}/docs/tasks/administer-cluster/weave-network-policy.md (100%)
 create mode 100644 content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
 rename content/{cn => zh}/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/cpu-request-limit.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/exec-liveness.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/http-liveness.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/init-containers.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/lifecycle-events.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/mem-limit-range.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/memory-request-limit-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/memory-request-limit-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/memory-request-limit.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/oir-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/oir-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/opaque-integer-resource.md (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/pod-redis.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/private-reg-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/projected-volume.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/qos-pod-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/qos-pod-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/qos-pod-4.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/qos-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/rq-compute-resources.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/security-context-2.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/security-context-3.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/security-context-4.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/security-context.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/task-pv-claim.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/task-pv-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/task-pv-volume.yaml (100%)
 rename content/{cn => zh}/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml (100%)
 create mode 100644 content/zh/docs/tasks/debug-application-cluster/audit.md
 rename content/{cn => zh}/docs/tasks/debug-application-cluster/debug-application.md (100%)
 rename content/{cn => zh}/docs/tasks/debug-application-cluster/debug-cluster.md (100%)
 rename content/{cn => zh}/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md (100%)
 rename content/{cn => zh}/docs/tasks/debug-application-cluster/debug-stateful-set.md (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/commands.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/dapi-envars-container.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/dapi-envars-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/dapi-volume-resources.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/dapi-volume.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/define-command-argument-container.md (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/define-environment-variable-container.md (96%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/distribute-credentials-secure.md (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md (98%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/envars.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-allow-db.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-configmap.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-merged.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-multi-merged.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-preset.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-proxy.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset-replicaset.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/podpreset.md (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/secret-envars-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/secret-pod.yaml (100%)
 rename content/{cn => zh}/docs/tasks/inject-data-application/secret.yaml (100%)
 create mode 100755 content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
 rename content/{cn => zh}/docs/tasks/manage-daemon/rollback-daemon-set.md (100%)
 rename content/{cn => zh}/docs/tasks/manage-gpus/scheduling-gpus.md (100%)
 rename content/{cn => zh}/docs/tasks/manage-hugepages/scheduling-hugepages.md (100%)
 rename content/{cn => zh}/docs/tasks/run-application/deployment-patch-demo.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/deployment-scale.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/deployment-update.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/deployment.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/gce-volume.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/mysql-configmap.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/mysql-deployment.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/mysql-services.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/mysql-statefulset.yaml (100%)
 rename content/{cn => zh}/docs/tasks/run-application/rolling-update-replication-controller.md (100%)
 rename content/{cn => zh}/docs/tasks/run-application/run-single-instance-stateful-application.md (100%)
 rename content/{cn => zh}/docs/tasks/run-application/run-stateless-application-deployment.md (100%)
 rename content/{cn => zh}/docs/tasks/run-application/scale-stateful-set.md (100%)
 rename content/{cn => zh}/docs/tasks/tls/certificate-rotation.md (100%)
 rename content/{cn => zh}/docs/templates/index.md (100%)
 rename content/{cn => zh}/docs/tutorials/configuration/configure-redis-using-configmap.md (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/_index.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/cluster-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/cluster-intro.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/deploy-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/deploy-intro.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/explore-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/explore-intro.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/expose-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/expose-intro.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/scale-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/scale-intro.html (100%)
 create mode 100644 content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/update-interactive.html (100%)
 rename content/{cn => zh}/docs/tutorials/kubernetes-basics/update-intro.html (100%)
 rename content/{cn => zh}/docs/tutorials/object-management-kubectl/imperative-object-management-command.md (100%)
 rename content/{cn => zh}/docs/tutorials/object-management-kubectl/object-management.md (100%)
 rename content/{cn => zh}/docs/tutorials/services/source-ip.md (95%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/Dockerfile (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/FETCH_HEAD (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/basic-stateful-set.md (99%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/cassandra-service.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/cassandra-statefulset.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/cassandra.md (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/dev (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md (98%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/web.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/webp.yaml (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/zookeeper.md (100%)
 rename content/{cn => zh}/docs/tutorials/stateful-application/zookeeper.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/bad-nginx-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/curlpod.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/docker-cli-to-kubectl.md (100%)
 rename content/{cn => zh}/docs/user-guide/ingress.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/job.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/jsonpath.md (100%)
 rename content/{cn => zh}/docs/user-guide/kubectl-overview.md (100%)
 rename content/{cn => zh}/docs/user-guide/multi-pod.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/new-nginx-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-app.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-init-containers.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-lifecycle-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-probe-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-secure-app.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/nginx-svc.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/pod-w-message.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/pod.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/redis-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/redis-resource-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/redis-secret-deployment.yaml (100%)
 rename content/{cn => zh}/docs/user-guide/run-my-nginx.yaml (100%)
 rename content/{cn => zh}/docs/whatisk8s.md (100%)
 delete mode 100644 layouts/shortcodes/language-repos-list.html

diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index d2968dbe7c866..22150b331bf5e 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -130,6 +130,36 @@ aliases:
     - rajakavitha1
     - stewart-yu
     - xiangpengzhao
+    - zhangxiaoyu
+  sig-docs-ja-owners: #Team: Japanese docs localization; GH: sig-docs-ja-owners
+    - cstoku
+    - nasa9084
+    - tnir
+  sig-docs-ja-reviews: #Team: Japanese docs PR reviews; GH:sig-docs-ja-reviews 
+    - cstoku
+    - makocchi-git
+    - MasayaAoyama
+    - nasa9084
+    - tnir
+  sig-docs-ko-owners: #Team Korean docs localization; GH: sig-docs-ko-owners
+    - ClaudiaJKang
+    - gochist
+  sig-docs-ko-reviews: #Team Korean docs reviews; GH: sig-docs-ko-reviews
+    - ClaudiaJKang
+    - gochist
+    - ianychoi
+  sig-docs-zh-owners: #Team Chinese docs localization; GH: sig-docs-zh-owners
+    - dchen1107
+    - haibinxie
+    - hanjiayao
+    - lichuqiang
+    - tengqm
+    - xiangpengzhao
+    - zhangxiaoyu-zidif
+  sig-docs-zh-reviews: #Team Chinese docs reviews; GH: sig-docs-zh-reviews
+    - tengqm
+    - xiangpengzhao
+
     - zhangxiaoyu-zidif
   sig-federation: #Team: Federation; e.g. Federated Clusters
     - csbell
diff --git a/config.toml b/config.toml
index 00a08449102a6..6d780612c1f0e 100644
--- a/config.toml
+++ b/config.toml
@@ -7,7 +7,7 @@ enableRobotsTXT = true
 
 disableKinds = ["taxonomy", "taxonomyTerm"]
 
-ignoreFiles = [ "^OWNERS$", "README.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
+ignoreFiles = [ "^OWNERS$", "README[-]+[a-z]*\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
 
 contentDir = "content/en"
 
@@ -131,25 +131,29 @@ description = "Production-Grade Container Orchestration"
 languageName ="English"
 # Weight used for sorting.
 weight = 1
-[languages.cn]
+
+[languages.zh]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName = "Chinese"
+languageName = "中文 Chinese"
 weight = 2
-contentDir = "content/cn"
+contentDir = "content/zh"
+
+[languages.ko]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "한국어 Korean"
+weight = 3
+contentDir = "content/ko"
+
 [languages.no]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
 languageName ="Norsk"
-weight = 3
+weight = 4
 contentDir = "content/no"
+
 [languages.no.params]
 time_format_blog = "02.01.2006"
 # A list of language codes to look for untranslated content, ordered from left to right.
 language_alternatives = ["en"]
-[languages.ko]
-title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
-languageName = "Korean"
-weight = 4
-contentDir = "content/ko"
diff --git a/content/cn/includes/default-storage-class-prereqs.md b/content/cn/includes/default-storage-class-prereqs.md
deleted file mode 100644
index ef4823318dcab..0000000000000
--- a/content/cn/includes/default-storage-class-prereqs.md
+++ /dev/null
@@ -1,6 +0,0 @@
-You need to either have a dynamic PersistentVolume provisioner with a default
-[StorageClass](/docs/concepts/storage/storage-classes/),
-or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning)
-yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)
-used here.
-
diff --git a/content/cn/includes/federated-task-tutorial-prereqs.md b/content/cn/includes/federated-task-tutorial-prereqs.md
deleted file mode 100644
index c5ec939c07894..0000000000000
--- a/content/cn/includes/federated-task-tutorial-prereqs.md
+++ /dev/null
@@ -1,8 +0,0 @@
-This guide assumes that you have a running Kubernetes Cluster
-Federation installation. If not, then head over to the
-[federation admin guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) to learn how to
-bring up a cluster federation (or have your cluster administrator do
-this for you).
-Other tutorials, such as Kelsey Hightower's 
-[Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
-might also help you create a Federated Kubernetes cluster.
\ No newline at end of file
diff --git a/content/cn/includes/federation-content-moved.md b/content/cn/includes/federation-content-moved.md
deleted file mode 100644
index 87a10e7199193..0000000000000
--- a/content/cn/includes/federation-content-moved.md
+++ /dev/null
@@ -1,2 +0,0 @@
-The topics in the [Federation API](/docs/federation/api-reference/) section of the Kubernetes docs
-are being moved to the [Reference](/docs/reference/) section. The content in this topic has moved to:
diff --git a/content/cn/includes/federation-current-state.md b/content/cn/includes/federation-current-state.md
deleted file mode 100644
index 56e4decdf3c2e..0000000000000
--- a/content/cn/includes/federation-current-state.md
+++ /dev/null
@@ -1,7 +0,0 @@
-**Note:** `Federation V1`, the current Kubernetes federation API which reuses the Kubernetes API 
-resources 'as is', is currently considered alpha for many of its features, and there is no clear
-path to evolve the API to GA. However, there is a `Federation V2` effort in progress to implement
-a dedicated federation API apart from the Kubernetes API. The details can be found at
-[sig-multicluster community page](https://github.com/kubernetes/community/tree/master/sig-multicluster).
-{: .note}
-
diff --git a/content/cn/includes/index.md b/content/cn/includes/index.md
deleted file mode 100644
index ca03031f1ee91..0000000000000
--- a/content/cn/includes/index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-headless: true
----
diff --git a/content/cn/includes/task-tutorial-prereqs.md b/content/cn/includes/task-tutorial-prereqs.md
deleted file mode 100644
index 6f1407fe45913..0000000000000
--- a/content/cn/includes/task-tutorial-prereqs.md
+++ /dev/null
@@ -1,8 +0,0 @@
-You need to have a Kubernetes cluster, and the kubectl command-line tool must
-be configured to communicate with your cluster. If you do not already have a
-cluster, you can create one by using
-[Minikube](/docs/getting-started-guides/minikube),
-or you can use one of these Kubernetes playgrounds:
-
-* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
-* [Play with Kubernetes](http://labs.play-with-k8s.com/)
diff --git a/content/cn/includes/user-guide-content-moved.md b/content/cn/includes/user-guide-content-moved.md
deleted file mode 100644
index 8b93e29f125f7..0000000000000
--- a/content/cn/includes/user-guide-content-moved.md
+++ /dev/null
@@ -1,3 +0,0 @@
-The topics in the [User Guide](/docs/user-guide/) section of the Kubernetes docs
-are being moved to the [Tasks](/docs/tasks/), [Tutorials](/docs/tutorials/), and
-[Concepts](/docs/concepts) sections. The content in this topic has moved to:
diff --git a/content/cn/includes/user-guide-migration-notice.md b/content/cn/includes/user-guide-migration-notice.md
deleted file mode 100644
index 366a05907cda5..0000000000000
--- a/content/cn/includes/user-guide-migration-notice.md
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
-<table style="background-color:#eeeeee">
-<tr>
-  <td>
-  <p><b>NOTICE</b></p>
-  <p>As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> through the <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> group and <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> channel.</p>
-  <p>The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.</p>
-  <p>For any questions, please contact: <a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
-  </td>
-</tr>
-</table>
diff --git a/content/en/OWNERS b/content/en/OWNERS
new file mode 100644
index 0000000000000..52f02277d4437
--- /dev/null
+++ b/content/en/OWNERS
@@ -0,0 +1,11 @@
+# This is the directory for English source content.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+- sig-docs-en-reviews
+
+approvers:
+- sig-docs-en-owners
+
+labels:
+- language/en
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 2f8c870d0d7a5..90d3c51ccfe71 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -4,17 +4,19 @@ content_template: templates/concept
 approvers:
 - chenopis
 - zacharysarah
+- zparnold
 ---
 
 {{% capture overview %}}
 
-The Kubernetes documentation is currently available in [multiple languages](#supported-languages) and we encourage you to add new localizations ([l10n](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/))!
+Documentation for Kubernetes is available in multiple languages:
 
-Currently available languages:
+- English
+- Chinese
+- Japanese
+- Korean
 
-{{< language-repos-list >}}
-
-In order for localizations to be accepted, however, they must fulfill some requirements related to workflow (*how* to localize) and output (*what* to localize).
+We encourage you to add new  [localizations](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)!
 
 {{% /capture %}}
 
@@ -22,42 +24,51 @@ In order for localizations to be accepted, however, they must fulfill some requi
 
 {{% capture body %}}
 
-## Workflow
+## Getting started
 
-The Kubernetes documentation for all languages is built from the [kubernetes/website](https://github.com/kubernetes/website) repository on GitHub. Most day-to-work work on translations, however, happens in separate translation repositories. Changes to those repositories are then [periodically](#upstream-contributions) synced to the main kubernetes/website repository via [pull request](../create-pull-request).
+Localizations must meet some requirements for workflow (*how* to localize) and output (*what* to localize).
 
-Work on the Chinese translation, for example, happens in the [kubernetes/kubernetes-docs-zh](https://github.com/kubernetes/kubernetes-docs-zh) repository.
+To add a new localization of the Kubernetes documentation, you'll need to update the website by modifying the  [site configuration](#modify-the-site-configuration) and [directory structure](#add-a-new-localization-directory). Then you can start [translating documents](#translating-documents)!
 
-{{< note >}}
-**Note**: For an example localization-related [pull request](../create-pull-request), see [this pull request](https://github.com/kubernetes/website/pull/8636) to the [Kubernetes website repo](https://github.com/kubernetes/website) adding Korean localization to the Kubernetes docs.
-{{< /note >}}
+Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). We're happy to help you get started and answer any questions you have.
 
-## Source Files
-
-Localizations must use English files from the most recent major release as sources. To find the most recent release's documentation source files:
-
-1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website.
-2. Select the `release-1.X` branch for the most recent version, which is currently **{{< latest-version >}}**, making the most recent release branch [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}).
+All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you.
 
-## Getting started
+### Fork and clone the repo
 
-In order to add a new localization of the Kubernetes documentation, you'll need to make a few modifications to the site's [configuration](#configuration) and [directory structure](#new-directory), and then you can get to work [translating documents](#translating-documents)!
+First, [create your own fork](https://help.github.com/articles/fork-a-repo/) of the [kubernetes/website](https://github.com/kubernetes/website).
 
-To get started, clone the website repo and `cd` into it:
+Then, clone the website repo and `cd` into it:
 
 ```shell
 git clone https://github.com/kubernetes/website
 cd website
-git checkout {{< release-branch >}}
 ```
 
-## Configuration
+{{< note >}}
+Contributors to `k/website` must [create a fork](https://kubernetes.io/docs/contribute/start/#improve-existing-content) from which to open pull requests. For localizations, we ask additionally that:
+
+1. Team approvers open development branches directly from https://github.com/kubernetes/website.
+2. Localization contributors work from forks, with branches based on the current development branch.
 
-We'll walk you through the configuration process using the German language (language code `de`) as an example.
+This is because localization projects are collaborative efforts on long-running branches, similar to the development branches for the Kubernetes release cycle. For information about localization pull requests, see ["branching strategy"](#branching-strategy).
+{{< /note >}}
 
-There's currently no translation for German, but you're welcome to create one using the instructions here.
+### Find your two-letter language code
 
-The Kubernetes website's configuration is in the [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml) file. You need to add a configuration block for the new language to that file, under the existing `[languages]` block. The German block, for example, looks like this:
+Consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) for your localization's two-letter country code. For example, the two-letter code for German is `de`.
+
+{{< note >}}
+These instructions use the [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) language code for German (`de`) as an example.
+
+There's currently no Kubernetes localization for German, but you're welcome to create one!
+{{< /note >}}
+
+### Modify the site configuration
+
+The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the  [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml) file. To support a new localization, you'll need to modify `config.toml`.
+
+Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. The German block, for example, looks like:
 
 ```toml
 [languages.de]
@@ -68,74 +79,128 @@ contentDir = "content/de"
 weight = 3
 ```
 
-When assigning a `weight` parameter, see which of the current languages has the highest weight and add 1 to that value.
+When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value.
 
-Now add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/master/content) folder. The two-letter code for German is `de`, so add a `content/de` directory:
+For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".
+
+### Add a new localization directory
+
+Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/master/content) folder in the repository. For example, the two-letter code for German is `de`:
 
 ```shell
 mkdir content/de
 ```
 
+### Add a localized README
+
+To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`.
+
+Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as:
+
+- A point of contact for the localization project
+- Any information specific to the localization
+
+After you create the localized README, add a link to the file from the main English file, [`README.md`] and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact.
+
 ## Translating documents
 
-We understand that localizing *all* of the Kubernetes documentation would be an enormous task. We're okay with localizations smarting small and expanding over time.
+Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and expand over time.
 
-As an initial requirement, all localizations must include the following documentation at a minimum:
+At a minimum, all localizations must include:
 
 Description | URLs
 -----|-----
 Home | [All heading and subheading URLs](https://kubernetes.io/docs/home/)
 Setup | [All heading and subheading URLs](https://kubernetes.io/docs/setup/)
 Tutorials | [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/), [Hello Minikube](https://kubernetes.io/docs/tutorials/stateless-application/hello-minikube/)
+Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
 
-Translated documents should have the same URL endpoint as the English docs (substituting the subdirectory of the `content` folder). To translate the [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) doc into German, for example, create the proper subfolder under the `content/de` folder and copy the English doc:
+Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
 
 ```shell
 mkdir -p content/de/docs/tutorials
 cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
 ```
 
-## Project logistics
+For an example of a localization-related [pull request](../create-pull-request), [this pull request](https://github.com/kubernetes/website/pull/10471) to the [Kubernetes website repo](https://github.com/kubernetes/website) added Korean localization to the Kubernetes docs.
 
-### Contact with project chairs
+### Source Files
 
-When starting a new localization effort, you should get in touch with one of the chairs of the Kubernetes [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) organization. The current chairs are listed [here](https://github.com/kubernetes/community/tree/master/sig-docs#chairs).
+Localizations must use English files from the most recent release as their source. The most recent version is **{{< latest-version >}}**.
 
-### Project information
+To find source files for the most recent release:
 
-Teams working on localization efforts must provide a single point of contact, including the name and contact information of a person who can respond to or redirect questions or concerns, listed in the translation repository's main [`README`](https://help.github.com/articles/about-readmes/). You can provide an email address, email list, [Slack channel](https://slack.com/), or some other method of contact.
+1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website.
+2. Select the `release-1.X` branch for the most recent version.
+
+The latest version is **{{< latest-version >}}**, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}).
+
+### Site strings in i18n/
+
+Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`.
+
+Add a new localization file to `i18n/`. For example, with German (`de`):
+
+```shell
+cp i18n/en.toml i18n/de.toml
+```
+
+Then translate the value of each string:
+
+```TOML
+[docs_label_i_am]
+other = "ICH BIN..."
+```
+
+Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page.
+
+## Project logistics
+
+### Contact the SIG Docs chairs
+
+Contact one of the chairs of the Kubernetes [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs#chairs) chairs when you start a new localization.
 
 ### Maintainers
 
-Each localization repository must select its own maintainers. Maintainers can be from a single organization or multiple organizations.
+Each localization repository must provide its own maintainers. Maintainers can be from a single organization or multiple organizations. Whenever possible, localization pull requests should be approved by a reviewer from a different organization than the translator.
 
-In addition, all l10n work must be self-sustaining with the team's own resources.
+A localization must provide a minimum of two maintainers. (It's not possible to review and approve one's own work.)
 
-Wherever possible, every localized page must be approved by a reviewer from a different company than the translator.
+### Branching strategy
 
-### GitHub project
+Because localization projects are highly collaborative efforts, we encourage teams to work from a shared development branch.
 
-Each Kubernetes localization repository must track its overall progress with a [GitHub project](https://help.github.com/articles/creating-a-project-board/).
+To collaborate on a development branch:
 
-Projects must include at least these columns:
+1. A team member opens a development branch, usually by opening a new pull request against a source branch on https://github.com/kubernetes/website.
 
-- To Do
-- In Progress
-- Done
+    We recommend the following branch naming scheme:
 
-{{< note >}}
-**Note**: For an example GitHub project, see the [Chinese localization project](https://github.com/kubernetes/kubernetes-docs-zh/projects/1).
-{{< /note >}}
+    `dev-<source version>-<language code>.<team milestone>`
 
-### Repository structure
+    For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12.
 
-Each l10n repository must have branches for the different Kubernetes documentation release versions, matching the branches in the main [kubernetes/website](https://github.com/kubernetes/website) documentation repository. For example, the kubernetes/website `release-1.10` branch (https://github.com/kubernetes/website/tree/release-1.10) has a corresponding branch in the kubernetes/kubernetes-docs-zh repository (https://github.com/kubernetes/kubernetes-docs-zh/tree/release-1.10). These version branches keep track of the differences in the documentation between Kubernetes versions.
+2. Individual contributors open feature branches based on the development branch.
 
-### Upstream contributions
+    For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`.
+
+3. Approvers review and merge feature branches into the development branch.
+
+4. Periodically, an approver merges the development branch to its source branch.
 
-Upstream contributions are welcome and encouraged!
+Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc.
+
+Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}.
+
+An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
+
+While only approvers can merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
+
+For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo).
+
+### Upstream contributions
 
-For the sake of efficiency, limit upstream contributions to a single pull request per week, containing a single [squashed commit](https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit).
+SIG Docs welcomes upstream contributions and corrections to the English source! Open a [pull request](https://kubernetes.io/docs/contribute/start/#improve-existing-content) (from a fork) with any updates.
 
 {{% /capture %}}
 
@@ -143,7 +208,7 @@ For the sake of efficiency, limit upstream contributions to a single pull reques
 
 Once a l10n meets requirements for workflow and minimum output, SIG docs will:
 
-- Work with the localization team to implement language selection on the website.
-- Publicize availability through [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) channels.
+- Enable language selection on the website
+- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
 
 {{% /capture %}}
diff --git a/content/ja/OWNERS b/content/ja/OWNERS
new file mode 100644
index 0000000000000..91ea772f74b86
--- /dev/null
+++ b/content/ja/OWNERS
@@ -0,0 +1,11 @@
+# This is the localization project for Japanese.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+- sig-docs-ja-reviews
+
+approvers:
+- sig-docs-ja-owners
+
+labels:
+- language/ja
diff --git a/content/ko/OWNERS b/content/ko/OWNERS
new file mode 100644
index 0000000000000..45a4bc5870300
--- /dev/null
+++ b/content/ko/OWNERS
@@ -0,0 +1,11 @@
+# This is the localization project for Korean.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+- sig-docs-ko-reviews
+
+approvers:
+- sig-docs-ko-owners
+
+labels:
+- language/ko
diff --git a/content/zh/OWNERS b/content/zh/OWNERS
new file mode 100644
index 0000000000000..7eec09c28cf47
--- /dev/null
+++ b/content/zh/OWNERS
@@ -0,0 +1,11 @@
+# This is the localization project for Chinese.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams. 
+
+reviewers:
+- sig-docs-zh-reviews
+
+approvers:
+- sig-docs-zh-owners
+
+labels:
+- language/zh
diff --git a/content/cn/_index.html b/content/zh/_index.html
similarity index 100%
rename from content/cn/_index.html
rename to content/zh/_index.html
diff --git a/content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md b/content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md
new file mode 100644
index 0000000000000..072ec679f3b41
--- /dev/null
+++ b/content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md
@@ -0,0 +1,182 @@
+<!-- ---
+title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
+date: 2016-04-18
+slug: kubernetes-network-policy-apis
+url: /blog/2016/04/Kubernetes-Network-Policy-APIs
+--- -->
+
+---
+title: "SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
+date: 2016-04-18
+slug: kubernetes-network-policy-apis
+url: /blog/2016/04/Kubernetes-Network-Policy-APIs
+---
+
+<!-- _Editor’s note: This week we’re featuring [Kubernetes Special Interest Groups](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)); Today’s post is by the Network-SIG team describing network policy APIs coming in 1.3 - policies for security, isolation and multi-tenancy._ -->
+
+编者按：这一周，我们的封面主题是 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs))；今天的文章由网络兴趣小组撰写，来谈谈 1.3 版本中即将出现的网络策略 API - 针对安全，隔离和多租户的策略。
+
+<!-- The [Kubernetes network SIG](https://kubernetes.slack.com/messages/sig-network/) has been meeting regularly since late last year to work on bringing network policy to Kubernetes and we’re starting to see the results of this effort. -->
+
+自去年下半年起，[Kubernetes 网络特别兴趣小组](https://kubernetes.slack.com/messages/sig-network/)经常定期开会，讨论如何将网络策略带入到 Kubernetes 之中，现在，我们也将慢慢看到这些工作的成果。
+
+<!-- One problem many users have is that the open access network policy of Kubernetes is not suitable for applications that need more precise control over the traffic that accesses a pod or service. Today, this could be a multi-tier application where traffic is only allowed from a tier’s neighbor. But as new Cloud Native applications are built by composing microservices, the ability to control traffic as it flows among these services becomes even more critical. -->
+
+很多用户经常会碰到的一个问题是， Kubernetes 的开放访问网络策略并不能很好地满足那些需要对 pod 或服务( service )访问进行更为精确控制的场景。今天，这个场景可以是在多层应用中，只允许临近层的访问。然而，随着组合微服务构建原生应用程序潮流的发展，如何控制流量在不同服务之间的流动会别的越发的重要。
+
+<!-- In most IaaS environments (both public and private) this kind of control is provided by allowing VMs to join a ‘security group’ where traffic to members of the group is defined by a network policy or Access Control List (ACL) and enforced by a network packet filter. -->
+
+在大多数的（公共的或私有的） IaaS 环境中，这种网络控制通常是将 VM 和“安全组”结合，其中安全组中成员的通信都是通过一个网络策略或者访问控制表（ Access Control List, ACL ）来定义，以及借助于网络包过滤器来实现。
+
+<!-- The Network SIG started the effort by identifying [specific use case scenarios](https://docs.google.com/document/d/1blfqiH4L_fpn33ZrnQ11v7LcYP0lmpiJ_RaapAPBbNU/edit?pref=2&pli=1#) that require basic network isolation for enhanced security. Getting the API right for these simple and common use cases is important because they are also the basis for the more sophisticated network policies necessary for multi-tenancy within Kubernetes. -->
+
+“网络特别兴趣小组”刚开始的工作是确定 [特定的使用场景](https://docs.google.com/document/d/1blfqiH4L_fpn33ZrnQ11v7LcYP0lmpiJ_RaapAPBbNU/edit?pref=2&pli=1#) ，这些用例需要基本的网络隔离来提升安全性。
+让这些API恰如其分地满足简单、共通的用例尤其重要，因为它们将为那些服务于 Kubernetes 内多租户，更为复杂的网络策略奠定基础。
+
+<!-- From these scenarios several possible approaches were considered and a minimal [policy specification](https://docs.google.com/document/d/1qAm-_oSap-f1d6a-xRTj6xaH1sYQBfK36VyjB5XOZug/edit) was defined. The basic idea is that if isolation were enabled on a per namespace basis, then specific pods would be selected where specific traffic types would be allowed. -->
+
+根据这些应用场景，我们考虑了集中不同的方法，然后定义了一个最简[策略规范](https://docs.google.com/document/d/1qAm-_oSap-f1d6a-xRTj6xaH1sYQBfK36VyjB5XOZug/edit)。
+基本的想法是，如果是根据命名空间的不同来进行隔离，那么就会根据所被允许的流量类型的不同，来选择特定的 pods 。
+
+<!-- The simplest way to quickly support this experimental API is in the form of a ThirdPartyResource extension to the API Server, which is possible today in Kubernetes 1.2. -->
+
+快速支持这个实验性 API 的办法是往 API 服务器上加入一个 `ThirdPartyResource` 扩展，这在 Kubernetes 1.2 就能办到。
+
+<!-- If you’re not familiar with how this works, the Kubernetes API can be extended by defining ThirdPartyResources that create a new API endpoint at a specified URL. -->
+
+如果你还不是很熟悉这其中的细节， Kubernetes API 是可以通过定义 `ThirdPartyResources` 扩展在特定的 URL 上创建一个新的 API 端点。
+
+#### third-party-res-def.yaml
+
+```
+kind: ThirdPartyResource
+apiVersion: extensions/v1beta1
+metadata:
+	- name: network-policy.net.alpha.kubernetes.io
+description: "Network policy specification"
+versions:
+	- name: v1alpha1
+```
+
+```
+$kubectl create -f third-party-res-def.yaml
+```
+
+<!-- This will create an API endpoint (one for each namespace): -->
+这条命令会创建一个 API 端点（每个命名空间各一个）:
+
+```
+/net.alpha.kubernetes.io/v1alpha1/namespace/default/networkpolicys/
+```
+
+<!-- Third party network controllers can now listen on these endpoints and react as necessary when resources are created, modified or deleted. _Note: With the upcoming release of Kubernetes 1.3 - when the Network Policy API is released in beta form - there will be no need to create a ThirdPartyResource API endpoint as shown above._ -->
+
+
+第三方网络控制器可以监听这些端点，根据资源的创建，修改或者删除作出必要的响应。
+_注意：在接下来的 Kubernetes 1.3 发布中， Network Policy API 会以 beta API 的形式出现，这也就不需要像上面那样，创建一个 `ThirdPartyResource` API 端点了。_
+
+<!-- Network isolation is off by default so that all pods can communicate as they normally do. However, it’s important to know that once network isolation is enabled, all traffic to all pods, in all namespaces is blocked, which means that enabling isolation is going to change the behavior of your pods -->
+
+网络隔离默认是关闭的，因而，所有的 pods 之间可以自由地通信。
+然而，很重要的一点是，一旦开通了网络隔离，所有命名空间下的所有 pods 之间的通信都会被阻断，换句话说，开通隔离会改变 pods 的行为。
+
+<!-- Network isolation is enabled by defining the _network-isolation_ annotation on namespaces as shown below: -->
+
+网络隔离可以通过定义命名空间， `net.alpha.kubernetes.io` 里的 `network-isolation` 注释来开通关闭:
+
+```
+net.alpha.kubernetes.io/network-isolation: [on | off]
+```
+
+<!-- Once network isolation is enabled, explicit network policies **must be applied** to enable pod communication. -->
+
+一旦开通了网络隔离，**一定需要使用** 显示的网络策略来允许 pod 间的通信。
+
+<!-- A policy specification can be applied to a namespace to define the details of the policy as shown below: -->
+
+一个策略规范可以被用到一个命名空间中，来定义策略的细节（如下所示）：
+
+```
+POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/
+{
+  "kind": "NetworkPolicy",
+  "metadata": {
+    "name": "pol1"
+  },
+  "spec": {
+    "allowIncoming": {
+      "from": [
+        {
+          "pods": {
+            "segment": "frontend"
+          }
+        }
+      ],
+      "toPorts": [
+        {
+          "port": 80,
+          "protocol": "TCP"
+        }
+      ]
+    },
+    "podSelector": {
+      "segment": "backend"
+    }
+  }
+}
+```
+
+<!-- In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1** ’ applied as indicated. Specifically, pods with the **segment** label ‘ **backend** ’ would allow TCP traffic on port 80 from pods with the **segment** label ‘ **frontend** ’ to be received. -->
+
+在这个例子中，**tenant-a** 空间将会使用 **pol1** 策略。
+具体而言，带有 **segment** 标签为 **backend** 的 pods 会允许 **segment** 标签为 **frontend** 的 pods 访问其端口 80 。
+
+
+<!-- Today, [Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).&nbsp; -->
+
+
+今天，[Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) 以及 [Calico](http://projectcalico.org/) 都已经支持在命名空间和pods中使用网络策略。
+而 Cisco 和 VMware 也在努力实现支持之中。
+Romana 和 Calico 已经在最近的 KubeCon 中展示了如何在 Kubernetes 1.2 下使用这些功能。
+你可以在这里看到他们的演讲：
+[Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([幻灯片](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)),
+[Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([幻灯片](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).
+
+<!-- **How does it work?** -->
+
+**这是如何工作的**
+
+<!-- Each solution has their their own specific implementation details. Today, they rely on some kind of on-host enforcement mechanism, but future implementations could also be built that apply policy on a hypervisor, or even directly by the network itself.&nbsp; -->
+
+每套解决方案都有自己不同的具体实现。尽管今天，他们都借助于每种主机上（ on-host ）的实现机制，但未来的实现可以通过将策略使用在 hypervisor 上，亦或是直接使用到网络本身上来达到同样的目的。
+
+<!-- External policy control software (specifics vary across implementations) will watch the new API endpoint for pods being created and/or new policies being applied. When an event occurs that requires policy configuration, the listener will recognize the change and a controller will respond by configuring the interface and applying the policy. &nbsp;The diagram below shows an API listener and policy controller responding to updates by applying a network policy locally via a host agent. The network interface on the pods is configured by a CNI plugin on the host (not shown). -->
+
+外部策略控制软件（不同实现各有不同）可以监听 pods 创建以及新加载策略的 API 端点。
+当产生一个需要策略配置的事件之后，监听器会确认这个请求，相应的，控制器会配置接口，使用该策略。
+下面的图例展示了 API 监视器和策略控制器是如何通过主机代理在本地应用网络策略的。
+这些 pods 的网络接口是使用过主机上的 CNI 插件来进行配置的（并未在图中注明）。
+
+ ![controller.jpg](https://lh5.googleusercontent.com/zMEpLMYmask-B-rYWnbMyGb0M7YusPQFPS6EfpNOSLbkf-cM49V7rTDBpA6k9-Zdh2soMul39rz9rHFJfL-jnEn_mHbpg0E1WlM-wjU-qvQu9KDTQqQ9uBmdaeWynDDNhcT3UjX5)
+
+
+<!-- If you’ve been holding back on developing applications with Kubernetes because of network isolation and/or security concerns, these new network policies go a long way to providing the control you need. No need to wait until Kubernetes 1.3 since network policy is available now as an experimental API enabled as a ThirdPartyResource. -->
+
+如果你一直受网络隔离或安全考虑的困扰，而犹豫要不要使用 Kubernetes 来开发应用程序，这些新的网络策略将会极大地解决你这方面的需求。并不需要等到 Kubernetes 1.3 ，现在就可以通过 `ThirdPartyResource` 的方式来使用这个实现性 API 。
+
+
+<!-- If you’re interested in Kubernetes and networking, there are several ways to participate - join us at:
+
+- Our [Networking slack channel](https://kubernetes.slack.com/messages/sig-network/)
+- Our [Kubernetes Networking Special Interest Group](https://groups.google.com/forum/#!forum/kubernetes-sig-network) email list -->
+
+如果你对 Kubernetes 和网络感兴趣，可以通过下面的方式参与、加入其中：
+
+- 我们的[网络 slack channel](https://kubernetes.slack.com/messages/sig-network/)
+- 我们的[Kubernetes 特别网络兴趣小组](https://groups.google.com/forum/#!forum/kubernetes-sig-network) 邮件列表
+
+<!-- The Networking “Special Interest Group,” which meets bi-weekly at 3pm (15h00) Pacific Time at [SIG-Networking hangout](https://zoom.us/j/5806599998). -->
+
+网络“特别兴趣小组”每两周下午三点（太平洋时间）开会，地址是[SIG-Networking hangout](https://zoom.us/j/5806599998).
+
+_--Chris Marino, Co-Founder, Pani Networks_
diff --git a/content/zh/blog/_posts/2016-04-00-Kubernetes-On-Aws_15.md b/content/zh/blog/_posts/2016-04-00-Kubernetes-On-Aws_15.md
new file mode 100644
index 0000000000000..c5de9e6a1285e
--- /dev/null
+++ b/content/zh/blog/_posts/2016-04-00-Kubernetes-On-Aws_15.md
@@ -0,0 +1,129 @@
+<!-- ---
+title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
+date: 2016-04-15
+slug: kubernetes-on-aws_15
+url: /blog/2016/04/Kubernetes-On-Aws_15
+--- -->
+
+---
+title: " 如何在AWS上部署安全，可审计，可复现的k8s集群 "
+date: 2016-04-15
+slug: kubernetes-on-aws_15
+url: /blog/2016/04/Kubernetes-On-Aws_15
+---
+
+<!-- _Today’s guest post is written by Colin Hom, infrastructure engineer at [CoreOS](https://coreos.com/), the company delivering Google’s Infrastructure for Everyone Else (#GIFEE) and running the world's containers securely on CoreOS Linux, Tectonic and Quay._
+
+_Join us at [CoreOS Fest Berlin](https://coreos.com/fest/), the Open Source Distributed Systems Conference, and learn more about CoreOS and Kubernetes._ -->
+
+_今天的客座文章是由Colin Hom撰写，[CoreOS](https://coreos.com/)的基础架构工程师。CoreOS致力于推广谷歌的基础架构模式（Google’s Infrastructure for Everyone Else， #GIFEE），让全世界的容器都能在CoreOS Linux, Tectonic 和 Quay上安全运行。_
+
+_加入到我们的[柏林CoreOS盛宴](https://coreos.com/fest/)，这是一个开源分布式系统主题的会议，在这里可以了解到更多关于CoreOS和Kubernetes的信息。_
+
+<!-- At CoreOS, we're all about deploying Kubernetes in production at scale. Today we are excited to share a tool that makes deploying Kubernetes on Amazon Web Services (AWS) a breeze. Kube-aws is a tool for deploying auditable and reproducible Kubernetes clusters to AWS, currently used by CoreOS to spin up production clusters. -->
+
+在CoreOS, 我们一直都是在生产环境中大规模部署Kubernetes。今天我们非常兴奋地想分享一款工具，它能让你的Kubernetes生产环境大规模部署更加的轻松。Kube-aws这个工具可以用来在AWS上部署可审计，可复现的k8s集群，而CoreOS本身就在生产环境中使用它。
+
+<!-- Today you might be putting the Kubernetes components together in a more manual way. With this helpful tool, Kubernetes is delivered in a streamlined package to save time, minimize interdependencies and quickly create production-ready deployments. -->
+
+也许今天，你更多的可能是用手工的方式来拼接Kubernetes组件。但有了这个工具之后，Kubernetes可以流水化地打包、交付，节省时间，减少了相互间的依赖，更加快捷地实现生产环境的部署。
+
+<!-- A simple templating system is leveraged to generate cluster configuration as a set of declarative configuration templates that can be version controlled, audited and re-deployed. Since the entirety of the provisioning is by [AWS CloudFormation](https://aws.amazon.com/cloudformation/) and cloud-init, there’s no need for external configuration management tools on your end. Batteries included! -->
+
+借助于一个简单的模板系统，来生成集群配置，这么做是因为一套声明式的配置模板可以版本控制，审计以及重复部署。而且，由于整个创建过程只用到了[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 和 cloud-init，你也就不需要额外用到其它的配置管理工具。开箱即用！
+
+<!-- To skip the talk and go straight to the project, check out [the latest release of kube-aws](https://github.com/coreos/coreos-kubernetes/releases), which supports Kubernetes 1.2.x. To get your cluster running, [check out the documentation](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html). -->
+
+如果要跳过演讲，直接了解这个项目，可以看看[kube-aws的最新发布](https://github.com/coreos/coreos-kubernetes/releases)，支持Kubernetes 1.2.x。如果要部署集群，可以参考[文档]](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html).
+
+<!-- **Why kube-aws? Security, auditability and reproducibility** -->
+**为什么是kube-aws？安全，可审计，可复现**
+
+<!-- Kube-aws is designed with three central goals in mind. -->
+Kube-aws设计初衷有三个目标。
+
+<!-- **Secure** : TLS assets are encrypted via the [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) before being embedded in the CloudFormation JSON. By managing [IAM policy](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) for the KMS key independently, an operator can decouple operational access to the CloudFormation stack from access to the TLS secrets. -->
+
+**安全** : TLS 资源在嵌入到CloudFormation JSON之前，通过[AWS 秘钥管理服务](https://aws.amazon.com/kms/)加密。通过单独管理KMS密钥的[IAM 策略](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)，可以将CloudFormation栈的访问与TLS秘钥的访问分离开。
+
+<!-- **Auditable** : kube-aws is built around the concept of cluster assets. These configuration and credential assets represent the complete description of the cluster. Since KMS is used to encrypt TLS assets, you can feel free to check your unencrypted stack JSON into version control as well! -->
+
+**可审计** : kube-aws是围绕集群资产的概念来创建。这些配置和账户资产是对集群的完全描述。由于KMS被用来加密TLS资产，因而可以无所顾忌地将未加密的CloudFormation栈 JSON签入到版本控制服务中。
+
+<!-- **Reproducible** : The _--export_ option packs your parameterized cluster definition into a single JSON file which defines a CloudFormation stack. This file can be version controlled and submitted directly to the CloudFormation API via existing deployment tooling, if desired. -->
+
+**可重复** : _--export_ 选项将参数化的集群定义打包成一整个JSON文件，对应一个CloudFormation栈。这个文件可以版本控制，然后，如果需要的话，通过现有的部署工具直接提交给CloudFormation API。
+
+<!-- **How to get started with kube-aws** -->
+**如何开始用kube-aws**
+
+<!-- On top of this foundation, kube-aws implements features that make Kubernetes deployments on AWS easier to manage and more flexible. Here are some examples. -->
+在此基础之上，kube-aws也实现了一些功能，使得在AWS上部署Kubernetes集群更加容易，灵活。下面是一些例子。
+
+<!-- **Route53 Integration** : Kube-aws can manage your cluster DNS records as part of the provisioning process. -->
+**Route53集成** : Kube-aws 可以管理你的集群DNS记录，作为配置过程的一部分。
+
+cluster.yaml
+```
+externalDNSName: my-cluster.kubernetes.coreos.com
+
+createRecordSet: true
+
+hostedZone: kubernetes.coreos.com
+
+recordSetTTL: 300
+```
+
+<!-- **Existing VPC Support** : Deploy your cluster to an existing VPC. -->
+**现有VPC支持** : 将集群部署到现有的VPC上。
+
+cluster.yaml
+```
+vpcId: vpc-xxxxx
+
+routeTableId: rtb-xxxxx
+```
+
+<!-- **Validation** : Kube-aws supports validation of cloud-init and CloudFormation definitions, along with any external resources that the cluster stack will integrate with. For example, here’s a cloud-config with a misspelled parameter: -->
+**验证** : kube-aws 支持验证 cloud-init 和 CloudFormation定义，以及集群栈会集成用到的外部资源。例如，下面就是一个cloud-config，外带一个拼写错误的参数：
+
+userdata/cloud-config-worker
+```
+#cloud-config
+
+coreos:
+
+  flannel:
+    interrface: $private\_ipv4
+    etcd\_endpoints: {{ .ETCDEndpoints }}
+```
+
+$ kube-aws validate
+
+ \> Validating UserData...
+     Error: cloud-config validation errors:
+     UserDataWorker: line 4: warning: unrecognized key "interrface"
+
+<!-- To get started, check out the [kube-aws documentation](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html). -->
+考虑如何起步？看看[kube-aws 文档](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html)！
+
+<!-- **Future Work** -->
+**未来的工作**
+
+<!-- As always, the goal with kube-aws is to make deployments that are production ready. While we use kube-aws in production on AWS today, this project is pre-1.0 and there are a number of areas in which kube-aws needs to evolve. -->
+一如既往，kube-aws的目标是让生产环境部署更加的简单。尽管我们现在在AWS下使用kube-aws进行生产环境部署，但是这个项目还是pre-1.0，所以还有很多的地方，kube-aws需要考虑、扩展。
+
+<!-- **Fault tolerance** : At CoreOS we believe Kubernetes on AWS is a potent platform for fault-tolerant and self-healing deployments. In the upcoming weeks, kube-aws will be rising to a new challenge: surviving the [Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey) – control plane and all! -->
+**容错** : CoreOS坚信 Kubernetes on AWS是强健的平台，适于容错、自恢复部署。在接下来的几个星期，kube-aws将会迎接新的考验：混世猴子（[Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey)）测试 - 控制平面以及全部！
+
+<!-- **Zero-downtime updates** : Updating CoreOS nodes and Kubernetes components can be done without downtime and without interdependency with the correct instance replacement strategy. -->
+**零停机更新** : 更新CoreOS节点和Kubernetes组件不需要停机，也不需要考虑实例更新策略（instance replacement strategy）的影响。
+
+<!-- A [github issue](https://github.com/coreos/coreos-kubernetes/issues/340) tracks the work towards this goal. We look forward to seeing you get involved with the project by filing issues or contributing directly. -->
+有一个[github issue](https://github.com/coreos/coreos-kubernetes/issues/340)来追踪这些工作进展。我们期待你的参与，提交issue，或是直接贡献。
+
+<!-- _Learn more about Kubernetes and meet the community at [CoreOS Fest Berlin](https://coreos.com/fest/) - May 9-10, 2016_ -->
+_想要更多地了解Kubernetes，来[柏林CoreOS盛宴](https://coreos.com/fest/)看看，- 五月 9-10, 2016_
+
+<!-- _– Colin Hom, infrastructure engineer, CoreOS_ -->
+_– Colin Hom, 基础架构工程师, CoreOS_
diff --git a/content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md b/content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md
new file mode 100644
index 0000000000000..4797bb7986ea4
--- /dev/null
+++ b/content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md
@@ -0,0 +1,81 @@
+---
+title: "Principles of Container-based Application Design"
+date: 2018-03-15
+slug: principles-of-container-app-design
+url: /blog/2018/03/Principles-Of-Container-App-Design
+---
+
+<!-- It's possible nowadays to put almost any application in a container and run it. Creating cloud-native applications, however—containerized applications that are automated and orchestrated effectively by a cloud-native platform such as Kubernetes—requires additional effort. Cloud-native applications anticipate failure; they run and scale reliably even when their infrastructure experiences outages. To offer such capabilities, cloud-native platforms like Kubernetes impose a set of contracts and constraints on applications. These contracts ensure that applications they run conform to certain constraints and allow the platform to automate application management. -->
+
+现如今，几乎所有的的应用程序都可以在容器中运行。但创建云原生应用，通过诸如 Kubernetes 的云原生平台更有效地自动化运行、管理容器化的应用却需要额外的工作。
+云原生应用需要考虑故障；即使是在底层架构发生故障时也需要可靠地运行。
+为了提供这样的功能，像 Kubernetes 这样的云原生平台需要向运行的应用程序强加一些契约和约束。
+这些契约确保应用可以在符合某些约束的条件下运行，从而使得平台可以自动化应用管理。
+
+<!-- I've outlined [seven principles][1]for containerized applications to follow in order to be fully cloud-native. -->
+
+我已经为容器化应用如何之为云原生应用概括出了[七项原则][1]。
+
+| ----- |
+| ![][2]  |
+| Container Design Principles |
+
+
+<!-- These seven principles cover both build time and runtime concerns. -->
+
+这里所述的七项原则涉及到构建时和运行时，两类关注点。
+
+<!-- ####  Build time -->
+#### 构建时
+
+<!-- * **Single Concern:** Each container addresses a single concern and does it well.
+* **Self-Containment:** A container relies only on the presence of the Linux kernel. Additional libraries are added when the container is built.
+* **Image Immutability:** Containerized applications are meant to be immutable, and once built are not expected to change between different environments. -->
+
+* **单一关注点：** 每个容器只解决一个关注点，并且完成的很好。
+* **自包含：** 一个容器只依赖Linux内核。额外的库要求可以在构建容器时加入。
+* **镜像不变性：** 容器化的应用意味着不变性，一旦构建完成，不需要根据环境的不同而重新构建。
+
+<!-- ####  Runtime -->
+#### 运行时
+
+<!-- * **High Observability:** Every container must implement all necessary APIs to help the platform observe and manage the application in the best way possible.
+* **Lifecycle Conformance:** A container must have a way to read events coming from the platform and conform by reacting to those events.
+* **Process Disposability:** Containerized applications must be as ephemeral as possible and ready to be replaced by another container instance at any point in time.
+* **Runtime Confinement:** Every container must declare its resource requirements and restrict resource use to the requirements indicated. -->
+
+* **高可观测性：** 每个容器必须实现所有必要的 API 来帮助平台以最好的方式来观测、管理应用。
+* **生命周期一致性：** 一个容器必须要能从平台中获取事件信息，并作出相应的反应。
+* **进程易处理性：** 容器化应用的寿命一定要尽可能的短暂，这样，可以随时被另一个容器所替换。
+* **运行时限制：** 每个容器都必须要声明自己的资源需求，并将资源使用限制在所需要的范围之内。
+
+<!-- The build time principles ensure that containers have the right granularity, consistency, and structure in place. The runtime principles dictate what functionalities must be implemented in order for containerized applications to possess cloud-native function. Adhering to these principles helps ensure that your applications are suitable for automation in Kubernetes. -->
+
+编译时原则保证了容器拥有合适的粒度，一致性以及结构。运行时原则明确了容器化必须要实现那些功能才能成为云原生函数。遵循这些原则可以帮助你的应用适应 Kubernetes 上的自动化。
+
+<!-- The white paper is freely available for download: -->
+
+白皮书可以免费下载：
+
+<!-- To read more about designing cloud-native applications for Kubernetes, check out my [Kubernetes Patterns][3] book. -->
+
+想要了解更多关于如何面向 Kubernetes 设计云原生应用，可以看看我的 [Kubernetes 模式][3] 一书。
+
+<!-- — [Bilgin Ibryam][4], Principal Architect, Red Hat -->
+
+— [Bilgin Ibryam][4], 首席架构师, Red Hat
+
+Twitter: 

+Blog: [http://www.ofbizian.com][5]
+Linkedin:
+
+<!-- Bilgin Ibryam (@bibryam) is a principal architect at Red Hat, open source committer at ASF, blogger, author, and speaker. He is the author of Camel Design Patterns and Kubernetes Patterns books. In his day-to-day job, Bilgin enjoys mentoring, training and leading teams to be successful with distributed systems, microservices, containers, and cloud-native applications in general. -->
+
+Bilgin Ibryam (@bibryam) 是 Red Hat 的一名首席架构师， ASF 的开源贡献者，博主，作者以及演讲者。
+他是 Camel 设计模式、 Kubernetes 模式的作者。在他的日常生活中，他非常享受指导、培训以及帮助各个团队更加成功地使用分布式系统、微服务、容器，以及云原生应用。
+
+[1]: https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
+[2]: https://lh5.googleusercontent.com/1XqojkVC0CET1yKCJqZ3-0VWxJ3W8Q74zPLlqnn6eHSJsjHOiBTB7EGUX5o_BOKumgfkxVdgBeLyoyMfMIXwVm9p2QXkq_RRy2mDJG1qEExJDculYL5PciYcWfPAKxF2-DGIdiLw
+[3]: http://leanpub.com/k8spatterns/
+[4]: http://twitter.com/bibryam
+[5]: http://www.ofbizian.com/
diff --git a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
new file mode 100644
index 0000000000000..6ff8dc79c83bb
--- /dev/null
+++ b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
@@ -0,0 +1,676 @@
+---
+
+layout: blog
+
+title:  'Airflow on Kubernetes (Part 1): A Different Kind of Operator'
+
+date:   2018-06-28
+
+title: 'Airflow在Kubernetes中的使用（第一部分）：一种不同的操作器'
+
+cn-approvers:
+
+- congfairy
+
+---
+
+
+<!--
+
+Author: Daniel Imberman (Bloomberg LP)
+
+-->
+
+ 
+
+作者: Daniel Imberman (Bloomberg LP)
+
+ 
+
+<!--
+
+## Introduction
+
+ 
+
+As part of Bloomberg's continued commitment to developing the Kubernetes ecosystem, we are excited to announce the Kubernetes Airflow Operator; a mechanism for Apache Airflow, a popular workflow orchestration framework to natively launch arbitrary Kubernetes Pods using the Kubernetes API.
+
+-->
+
+ 
+
+## 介绍
+
+ 
+
+作为Bloomberg [继续致力于开发Kubernetes生态系统]的一部分（https://www.techatbloomberg.com/blog/bloomberg-awarded-first-cncf-end-user-award-contributions-kubernetes/），我们很高兴能够宣布Kubernetes Airflow Operator的发布; [Apache Airflow]（https://airflow.apache.org/）的机制，一种流行的工作流程编排框架，使用Kubernetes API可以在本机启动任意的Kubernetes Pod。
+
+ 
+
+<!--
+
+## What Is Airflow?
+
+ 
+
+Apache Airflow is one realization of the DevOps philosophy of "Configuration As Code." Airflow allows users to launch multi-step pipelines using a simple Python object DAG (Directed Acyclic Graph). You can define dependencies, programmatically construct complex workflows, and monitor scheduled jobs in an easy to read UI.
+
+ 
+
+
+
+
+
+-->
+
+ 
+
+## 什么是Airflow?
+
+ 
+
+Apache Airflow是DevOps“Configuration As Code”理念的一种实现。 Airflow允许用户使用简单的Python对象DAG（有向无环图）启动多步骤流水线。 您可以在易于阅读的UI中定义依赖关系，以编程方式构建复杂的工作流，并监视调度的作业。
+
+ 
+
+<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow_dags.png”width =“85％”alt =“Airflow DAGs”/>
+
+<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow.png”width =“85％”alt =“Airflow UI”/>
+
+ 
+
+<!--
+
+## Why Airflow on Kubernetes?
+
+ 
+
+Since its inception, Airflow's greatest strength has been its flexibility. Airflow offers a wide range of integrations for services ranging from Spark and HBase, to services on various cloud providers. Airflow also offers easy extensibility through its plug-in framework. However, one limitation of the project is that Airflow users are confined to the frameworks and clients that exist on the Airflow worker at the moment of execution. A single organization can have varied Airflow workflows ranging from data science pipelines to application deployments. This difference in use-case creates issues in dependency management as both teams might use vastly different libraries for their workflows.
+
+ 
+
+To address this issue, we've utilized Kubernetes to allow users to launch arbitrary Kubernetes pods and configurations. Airflow users can now have full power over their run-time environments, resources, and secrets, basically turning Airflow into an "any job you want" workflow orchestrator.
+
+-->
+
+ 
+
+## 为什么在Kubernetes上使用Airflow?
+
+ 
+
+自成立以来，Airflow的最大优势在于其灵活性。 Airflow提供广泛的服务集成，包括Spark和HBase，以及各种云提供商的服务。 Airflow还通过其插件框架提供轻松的可扩展性。但是，该项目的一个限制是Airflow用户仅限于执行时Airflow站点上存在的框架和客户端。单个组织可以拥有各种Airflow工作流程，范围从数据科学流到应用程序部署。用例中的这种差异会在依赖关系管理中产生问题，因为两个团队可能会在其工作流程使用截然不同的库。
+
+ 
+
+为了解决这个问题，我们使Kubernetes允许用户启动任意Kubernetes pod和配置。 Airflow用户现在可以在其运行时环境，资源和机密上拥有全部权限，基本上将Airflow转变为“您想要的任何工作”工作流程协调器。
+
+ 
+
+<!--
+
+## The Kubernetes Operator
+
+ 
+
+Before we move any further, we should clarify that an Operator in Airflow is a task definition. When a user creates a DAG, they would use an operator like the "SparkSubmitOperator" or the "PythonOperator" to submit/monitor a Spark job or a Python function respectively. Airflow comes with built-in operators for frameworks like Apache Spark, BigQuery, Hive, and EMR. It also offers a Plugins entrypoint that allows DevOps engineers to develop their own connectors.
+
+ 
+
+Airflow users are always looking for ways to make deployments and ETL pipelines simpler to manage. Any opportunity to decouple pipeline steps, while increasing monitoring, can reduce future outages and fire-fights. The following is a list of benefits provided by the Airflow Kubernetes Operator:
+
+-->
+
+ 
+
+## Kubernetes运营商
+
+ 
+
+在进一步讨论之前，我们应该澄清Airflow中的[Operator]（https://airflow.apache.org/concepts.html#operators）是一个任务定义。 当用户创建DAG时，他们将使用像“SparkSubmitOperator”或“PythonOperator”这样的operator分别提交/监视Spark作业或Python函数。 Airflow附带了Apache Spark，BigQuery，Hive和EMR等框架的内置运算符。 它还提供了一个插件入口点，允许DevOps工程师开发自己的连接器。
+
+ 
+
+Airflow用户一直在寻找更易于管理部署和ETL流的方法。 在增加监控的同时，任何解耦流程的机会都可以减少未来的停机等问题。 以下是Airflow Kubernetes Operator提供的好处：
+
+ 
+
+<!--
+
+ * Increased flexibility for deployments:  
+
+Airflow's plugin API has always offered a significant boon to engineers wishing to test new functionalities within their DAGs. On the downside, whenever a developer wanted to create a new operator, they had to develop an entirely new plugin. Now, any task that can be run within a Docker container is accessible through the exact same operator, with no extra Airflow code to maintain.
+
+-->
+
+ 
+
+* 提高部署灵活性：
+
+Airflow的插件API一直为希望在其DAG中测试新功能的工程师提供了重要的福利。 不利的一面是，每当开发人员想要创建一个新的operator时，他们就必须开发一个全新的插件。 现在，任何可以在Docker容器中运行的任务都可以通过完全相同的运算符访问，而无需维护额外的Airflow代码。
+
+ 
+
+<!--
+
+ * Flexibility of configurations and dependencies:
+
+For operators that are run within static Airflow workers, dependency management can become quite difficult. If a developer wants to run one task that requires SciPy and another that requires NumPy, the developer would have to either maintain both dependencies within all Airflow workers or offload the task to an external machine (which can cause bugs if that external machine changes in an untracked manner). Custom Docker images allow users to ensure that the tasks environment, configuration, and dependencies are completely idempotent.  
+
+-->
+
+ 
+
+* 配置和依赖的灵活性：
+
+对于在静态Airflow工作程序中运行的operator，依赖关系管理可能变得非常困难。 如果开发人员想要运行一个需要[SciPy]（https://www.scipy.org） 的任务和另一个需要[NumPy]（http://www.numpy.org） 的任务，开发人员必须维护所有Airflow节点中的依赖关系或将任务卸载到其他计算机（如果外部计算机以未跟踪的方式更改，则可能导致错误）。 自定义Docker镜像允许用户确保任务环境，配置和依赖关系完全是幂等的。
+
+ 
+
+<!--
+
+ * Usage of kubernetes secrets for added security:
+
+Handling sensitive data is a core responsibility of any DevOps engineer. At every opportunity, Airflow users want to isolate any API keys, database passwords, and login credentials on a strict need-to-know basis. With the Kubernetes operator, users can utilize the Kubernetes Vault technology to store all sensitive data. This means that the Airflow workers will never have access to this information, and can simply request that pods be built with only the secrets they need.
+
+-->
+
+ 
+
+* 使用kubernetes Secret以增加安全性：
+
+处理敏感数据是任何开发工程师的核心职责。 Airflow用户总有机会在严格条款的基础上隔离任何API密钥，数据库密码和登录凭据。 使用Kubernetes运算符，用户可以利用Kubernetes Vault技术存储所有敏感数据。 这意味着Airflow工作人员将永远无法访问此信息，并且可以容易地请求仅使用他们需要的密码信息构建pod。
+
+ 
+
+<!--
+
+# Architecture
+
+ 
+
+
+
+ 
+
+The Kubernetes Operator uses the Kubernetes Python Client to generate a request that is processed by the APIServer (1). Kubernetes will then launch your pod with whatever specs you've defined (2). Images will be loaded with all the necessary environment variables, secrets and dependencies, enacting a single command. Once the job is launched, the operator only needs to monitor the health of track logs (3). Users will have the choice of gathering logs locally to the scheduler or to any distributed logging service currently in their Kubernetes cluster.
+
+-->
+
+ 
+
+＃架构
+
+ 
+
+<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow-architecture.png”width =“85％”alt =“Airflow Architecture”/>
+
+ 
+
+Kubernetes Operator使用[Kubernetes Python客户端]（https://github.com/kubernetes-client/Python)生成由APIServer处理的请求（1）。 然后，Kubernetes将使用您定义的需求启动您的pod（2）。映像文件中将加载环境变量，Secret和依赖项，执行单个命令。 一旦启动作业，operator只需要监视跟踪日志的状况（3）。 用户可以选择将日志本地收集到调度程序或当前位于其Kubernetes集群中的任何分布式日志记录服务。
+
+ 
+
+<!--
+
+# Using the Kubernetes Operator
+
+ 
+
+## A Basic Example
+
+ 
+
+The following DAG is probably the simplest example we could write to show how the Kubernetes Operator works. This DAG creates two pods on Kubernetes: a Linux distro with Python and a base Ubuntu distro without it. The Python pod will run the Python request correctly, while the one without Python will report a failure to the user. If the Operator is working correctly, the passing-task pod should complete, while the failing-task pod returns a failure to the Airflow webserver.
+
+-->
+
+ 
+
+＃使用Kubernetes Operator
+
+ 
+
+##一个基本的例子
+
+ 
+
+以下DAG可能是我们可以编写的最简单的示例，以显示Kubernetes Operator的工作原理。 这个DAG在Kubernetes上创建了两个pod：一个带有Python的Linux发行版和一个没有它的基本Ubuntu发行版。 Python pod将正确运行Python请求，而没有Python的那个将向用户报告失败。 如果Operator正常工作，则应该完成“passing-task”pod，而“falling-task”pod则向Airflow网络服务器返回失败。
+
+ 
+
+ 
+
+```Python
+
+from airflow import DAG
+
+from datetime import datetime, timedelta
+
+from airflow.contrib.operators.kubernetes_pod_operator import KubernetesPodOperator
+
+from airflow.operators.dummy_operator import DummyOperator
+
+
+default_args = {
+
+    'owner': 'airflow',
+
+    'depends_on_past': False,
+
+    'start_date': datetime.utcnow(),
+
+    'email': ['airflow@example.com'],
+
+    'email_on_failure': False,
+
+    'email_on_retry': False,
+
+    'retries': 1,
+
+    'retry_delay': timedelta(minutes=5)
+
+}
+
+ 
+
+dag = DAG(
+
+    'kubernetes_sample', default_args=default_args, schedule_interval=timedelta(minutes=10))
+
+start = DummyOperator(task_id='run_this_first', dag=dag)
+passing = KubernetesPodOperator(namespace='default',
+
+                          image="Python:3.6",
+
+                          cmds=["Python","-c"],
+
+                          arguments=["print('hello world')"],
+
+                          labels={"foo": "bar"},
+
+                          name="passing-test",
+
+                          task_id="passing-task",
+
+                          get_logs=True,
+
+                          dag=dag
+
+                          )
+
+ failing = KubernetesPodOperator(namespace='default',
+
+                          image="ubuntu:1604",
+
+                          cmds=["Python","-c"],
+
+                          arguments=["print('hello world')"],
+
+                          labels={"foo": "bar"},
+
+                          name="fail",
+
+                          task_id="failing-task",
+
+                          get_logs=True,
+
+                          dag=dag
+
+                          )
+
+passing.set_upstream(start)
+
+failing.set_upstream(start)
+
+```
+
+<!--
+
+## But how does this relate to my workflow?
+
+ 
+
+While this example only uses basic images, the magic of Docker is that this same DAG will work for any image/command pairing you want. The following is a recommended CI/CD pipeline to run production-ready code on an Airflow DAG.
+
+ 
+
+### 1: PR in github
+
+Use Travis or Jenkins to run unit and integration tests, bribe your favorite team-mate into PR'ing your code, and merge to the master branch to trigger an automated CI build.
+
+ 
+
+### 2: CI/CD via Jenkins -> Docker Image
+
+ 
+
+Generate your Docker images and bump release version within your Jenkins build.
+
+ 
+
+### 3: Airflow launches task
+
+ 
+
+Finally, update your DAGs to reflect the new release version and you should be ready to go!
+
+-->
+
+##但这与我的工作流程有什么关系？
+
+ 
+
+虽然这个例子只使用基本映像，但Docker的神奇之处在于，这个相同的DAG可以用于您想要的任何图像/命令配对。 以下是推荐的CI / CD管道，用于在Airflow DAG上运行生产就绪代码。
+
+ 
+
+### 1：github中的PR
+
+使用Travis或Jenkins运行单元和集成测试，请您的朋友PR您的代码，并合并到主分支以触发自动CI构建。
+
+ 
+
+### 2：CI / CD构建Jenkins - > Docker Image
+
+ 
+
+[在Jenkins构建中生成Docker镜像和缓冲版本]（https://getintodevops.com/blog/building-your-first-Docker-image-with-jenkins-2-guide-for-developers）。
+
+ 
+
+### 3：Airflow启动任务
+
+ 
+
+最后，更新您的DAG以反映新版本，您应该准备好了！
+
+ 
+
+```Python
+
+production_task = KubernetesPodOperator(namespace='default',
+
+                          # image="my-production-job:release-1.0.1", <-- old release
+
+                          image="my-production-job:release-1.0.2",
+
+                          cmds=["Python","-c"],
+
+                          arguments=["print('hello world')"],
+
+                          name="fail",
+
+                          task_id="failing-task",
+
+                          get_logs=True,
+
+                          dag=dag
+
+                          )
+
+```
+
+<!--
+
+# Launching a test deployment
+
+ 
+
+Since the Kubernetes Operator is not yet released, we haven't released an official helm chart or operator (however both are currently in progress). However, we are including instructions for a basic deployment below  and are actively looking for foolhardy beta testers to try this new feature. To try this system out please follow these steps:
+
+ 
+
+## Step 1: Set your kubeconfig to point to a kubernetes cluster
+
+ 
+
+## Step 2: Clone the Airflow Repo:
+
+ 
+
+Run git clone https://github.com/apache/incubator-airflow.git to clone the official Airflow repo.
+
+ 
+
+## Step 3: Run
+
+ 
+
+To run this basic deployment, we are co-opting the integration testing script that we currently use for the Kubernetes Executor (which will be explained in the next article of this series). To launch this deployment, run these three commands:
+
+-->
+
+ 
+
+＃启动测试部署
+
+ 
+
+由于Kubernetes运营商尚未发布，我们尚未发布官方[helm](https://helm.sh/) 图表或operator（但两者目前都在进行中）。 但是，我们在下面列出了基本部署的说明，并且正在积极寻找测试人员来尝试这一新功能。 要试用此系统，请按以下步骤操作：
+
+ 
+
+##步骤1：将kubeconfig设置为指向kubernetes集群
+
+ 
+
+##步骤2：clone Airflow 仓库：
+
+ 
+
+运行git clone https：// github.com / apache / incubator-airflow.git来clone官方Airflow仓库。
+
+ 
+
+##步骤3：运行
+
+ 
+
+为了运行这个基本Deployment，我们正在选择我们目前用于Kubernetes Executor的集成测试脚本（将在本系列的下一篇文章中对此进行解释）。 要启动此部署，请运行以下三个命令：
+
+ 
+
+```
+
+sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml
+
+./scripts/ci/kubernetes/Docker/build.sh
+
+./scripts/ci/kubernetes/kube/deploy.sh
+
+```
+
+<!--
+
+Before we move on, let's discuss what these commands are doing:
+
+ 
+
+### sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml
+
+ 
+
+The Kubernetes Executor is another Airflow feature that allows for dynamic allocation  of tasks as idempotent pods. The reason we are switching this to the LocalExecutor is simply to introduce one feature at a time. You are more then welcome to skip this step if you would like to try the Kubernetes Executor, however we will go into more detail in a future article.
+
+ 
+
+### ./scripts/ci/kubernetes/Docker/build.sh
+
+ 
+
+This script will tar the Airflow master source code build a Docker container based on the Airflow distribution
+
+ 
+
+### ./scripts/ci/kubernetes/kube/deploy.sh
+
+ 
+
+Finally, we create a full Airflow deployment on your cluster. This includes Airflow configs, a postgres backend, the webserver + scheduler, and all necessary services between. One thing to note is that the role binding supplied is a cluster-admin, so if you do not have that level of permission on the cluster, you can modify this at scripts/ci/kubernetes/kube/airflow.yaml
+
+ 
+
+## Step 4: Log into your webserver
+
+ 
+
+Now that your Airflow instance is running let's take a look at the UI! The UI lives in port 8080 of the Airflow pod, so simply run
+
+-->
+
+ 
+
+在我们继续之前，让我们讨论这些命令正在做什么：
+
+ 
+
+### sed -ie“s / KubernetesExecutor / LocalExecutor / g”scripts / ci / kubernetes / kube / configmaps.yaml
+
+ 
+
+Kubernetes Executor是另一种Airflow功能，允许动态分配任务已解决幂等pod的问题。我们将其切换到LocalExecutor的原因只是一次引入一个功能。如果您想尝试Kubernetes Executor，欢迎您跳过此步骤，但我们将在以后的文章中详细介绍。
+
+ 
+
+### ./scripts/ci/kubernetes/Docker/build.sh
+
+ 
+
+此脚本将对Airflow主分支代码进行打包，以根据Airflow的发行文件构建Docker容器
+
+ 
+
+### ./scripts/ci/kubernetes/kube/deploy.sh
+
+ 
+
+最后，我们在您的群集上创建完整的Airflow部署。这包括Airflow配置，postgres后端，webserver +调度程序以及之间的所有必要服务。需要注意的一点是，提供的角色绑定是集群管理员，因此如果您没有该集群的权限级别，可以在scripts / ci / kubernetes / kube / airflow.yaml中进行修改。
+
+ 
+
+##步骤4：登录您的网络服务器
+
+ 
+
+现在您的Airflow实例正在运行，让我们来看看UI！用户界面位于Airflow pod的8080端口，因此只需运行即可
+
+ 
+
+```
+
+WEB=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep "airflow" | head -1)
+
+kubectl port-forward $WEB 8080:8080
+
+ ```
+
+<!--
+
+ Now the Airflow UI will exist on http://localhost:8080. To log in simply enter airflow/airflow and you should have full access to the Airflow web UI.
+
+ 
+
+## Step 5: Upload a test document
+
+ 
+
+To modify/add your own DAGs, you can use kubectl cp to upload local files into the DAG folder of the Airflow scheduler. Airflow will then read the new DAG and automatically upload it to its system. The following command will upload any local file into the correct directory:
+
+-->
+
+ 
+
+现在，Airflow UI将存在于http://localhost:8080上。 要登录，只需输入airflow /airflow，您就可以完全访问Airflow Web UI。
+
+ 
+
+##步骤5：上传测试文档
+
+ 
+
+要修改/添加自己的DAG，可以使用kubectl cp将本地文件上传到Airflow调度程序的DAG文件夹中。 然后，Airflow将读取新的DAG并自动将其上传到其系统。 以下命令将任何本地文件上载到正确的目录中：
+
+ 
+
+kubectl cp <local file> <namespace>/<pod>:/root/airflow/dags -c scheduler
+
+ 
+
+<!--
+
+## Step 6: Enjoy!
+
+ 
+
+# So when will I be able to use this?
+
+ 
+
+ While this feature is still in the early stages, we hope to see it released for wide release in the next few months.
+
+ 
+
+# Get Involved
+
+ 
+
+This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the 1.10 release branch of Airflow (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributers can have a huge influence on the future of these features.
+
+ 
+
+For those interested in joining these efforts, I'd recommend checkint out these steps:
+
+ 
+
+ * Join the airflow-dev mailing list at dev@airflow.apache.org.
+
+ * File an issue in Apache Airflow JIRA
+
+ * Join our SIG-BigData meetings on Wednesdays at 10am PST.
+
+ * Reach us on slack at #sig-big-data on kubernetes.slack.com
+
+ 
+
+Special thanks to the Apache Airflow and Kubernetes communities, particularly Grant Nicholas, Ben Goldberg, Anirudh Ramanathan, Fokko Dreisprong, and Bolke de Bruin, for your awesome help on these features as well as our future efforts.
+
+-->
+
+ 
+
+##步骤6：使用它！
+
+ 
+
+#那么我什么时候可以使用它？
+
+ 
+
+ 虽然此功能仍处于早期阶段，但我们希望在未来几个月内发布该功能以进行广泛发布。
+
+ 
+
+#参与其中
+
+ 
+
+此功能只是将Apache Airflow集成到Kubernetes中的多项主要工作的开始。 Kubernetes Operator已合并到[Airflow的1.10发布分支]（https://github.com/apache/incubator-airflow/tree/v1-10-test）（实验模式中的执行模块），以及完整的k8s本地调度程序称为Kubernetes Executor（即将发布文章）。这些功能仍处于早期采用者/贡献者可能对这些功能的未来产生巨大影响的阶段。
+
+ 
+
+对于有兴趣加入这些工作的人，我建议按照以下步骤：
+
+ 
+
+ *加入airflow-dev邮件列表dev@airflow.apache.org。
+
+ *在[Apache Airflow JIRA]中提出问题（https://issues.apache.org/jira/projects/AIRFLOW/issues/）
+
+ *周三上午10点太平洋标准时间加入我们的SIG-BigData会议。
+
+ *在kubernetes.slack.com上的＃sig-big-data找到我们。
+
+ 
+
+特别感谢Apache Airflow和Kubernetes社区，特别是Grant Nicholas，Ben Goldberg，Anirudh Ramanathan，Fokko Dreisprong和Bolke de Bruin，感谢您对这些功能的巨大帮助以及我们未来的努力。
diff --git a/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md b/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md
new file mode 100644
index 0000000000000..560fe618bcf1b
--- /dev/null
+++ b/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md
@@ -0,0 +1,401 @@
+---
+title: 基于IPVS的集群内部负载均衡
+cn-approvers:
+- congfairy
+layout: blog
+title:  'IPVS-Based In-Cluster Load Balancing Deep Dive'
+date:   2018-07-09
+---
+
+<!--
+
+Author: Jun Du(Huawei), Haibin Xie(Huawei), Wei Liang(Huawei)
+
+Editor’s note: this post is part of a series of in-depth articles on what’s new in Kubernetes 1.11
+
+-->
+
+作者: Jun Du(华为), Haibin Xie(华为), Wei Liang(华为)
+
+注意: 这篇文章出自 系列深度文章 介绍 Kubernetes 1.11 的新特性
+
+<!--
+
+Introduction
+
+Per the Kubernetes 1.11 release blog post , we announced that IPVS-Based In-Cluster Service Load Balancing graduates to General Availability. In this blog, we will take you through a deep dive of the feature.
+
+-->
+
+介绍
+
+根据 Kubernetes 1.11 发布的博客文章, 我们宣布基于 IPVS 的集群内部服务负载均衡已达到一般可用性。 在这篇博客中，我们将带您深入了解该功能。
+
+<!--
+
+What Is IPVS?
+
+IPVS (IP Virtual Server) is built on top of the Netfilter and implements transport-layer load balancing as part of the Linux kernel.
+
+IPVS is incorporated into the LVS (Linux Virtual Server), where it runs on a host and acts as a load balancer in front of a cluster of real servers. IPVS can direct requests for TCP- and UDP-based services to the real servers, and make services of the real servers appear as virtual services on a single IP address. Therefore, IPVS naturally supports Kubernetes Service.
+
+-->
+
+什么是 IPVS ?
+
+IPVS (IP Virtual Server)是在 Netfilter 上层构建的，并作为 Linux 内核的一部分，实现传输层负载均衡。
+
+IPVS 集成在 LVS（Linux Virtual Server，Linux 虚拟服务器）中，它在主机上运行，并在物理服务器集群前作为负载均衡器。IPVS 可以将基于 TCP 和 UDP 服务的请求定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。 因此，IPVS 自然支持 Kubernetes 服务。
+
+<!--
+
+Why IPVS for Kubernetes?
+
+As Kubernetes grows in usage, the scalability of its resources becomes more and more important. In particular, the scalability of services is paramount to the adoption of Kubernetes by developers/companies running large workloads.
+
+Kube-proxy, the building block of service routing has relied on the battle-hardened iptables to implement the core supported Service types such as ClusterIP and NodePort. However, iptables struggles to scale to tens of thousands of Services because it is designed purely for firewalling purposes and is based on in-kernel rule lists.
+
+Even though Kubernetes already support 5000 nodes in release v1.6, the kube-proxy with iptables is actually a bottleneck to scale the cluster to 5000 nodes. One example is that with NodePort Service in a 5000-node cluster, if we have 2000 services and each services have 10 pods, this will cause at least 20000 iptable records on each worker node, and this can make the kernel pretty busy.
+
+On the other hand, using IPVS-based in-cluster service load balancing can help a lot for such cases. IPVS is specifically designed for load balancing and uses more efficient data structures (hash tables) allowing for almost unlimited scale under the hood.
+
+-->
+
+为什么为 Kubernetes 选择 IPVS ?
+
+随着 Kubernetes 的使用增长，其资源的可扩展性变得越来越重要。特别是，服务的可扩展性对于运行大型工作负载的开发人员/公司采用 Kubernetes 至关重要。
+
+Kube-proxy 是服务路由的构建块，它依赖于经过强化攻击的 iptables 来实现支持核心的服务类型，如 ClusterIP 和 NodePort。 但是，iptables 难以扩展到成千上万的服务，因为它纯粹是为防火墙而设计的，并且基于内核规则列表。
+
+尽管 Kubernetes 在版本v1.6中已经支持5000个节点，但使用 iptables 的 kube-proxy 实际上是将集群扩展到5000个节点的瓶颈。 一个例子是，在5000节点集群中使用 NodePort 服务，如果我们有2000个服务并且每个服务有10个 pod，这将在每个工作节点上至少产生20000个 iptable 记录，这可能使内核非常繁忙。
+
+另一方面，使用基于 IPVS 的集群内服务负载均衡可以为这种情况提供很多帮助。 IPVS 专门用于负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张。
+
+<!--
+
+IPVS-based Kube-proxy
+
+Parameter Changes
+
+Parameter: --proxy-mode In addition to existing userspace and iptables modes, IPVS mode is configured via --proxy-mode=ipvs. It implicitly uses IPVS NAT mode for service port mapping.
+
+-->
+
+基于 IPVS 的 Kube-proxy
+
+参数更改
+
+参数: --proxy-mode 除了现有的用户空间和 iptables 模式，IPVS 模式通过--proxy-mode = ipvs 进行配置。 它隐式使用 IPVS NAT 模式进行服务端口映射。
+
+<!--
+
+Parameter: --ipvs-scheduler
+
+A new kube-proxy parameter has been added to specify the IPVS load balancing algorithm, with the parameter being --ipvs-scheduler. If it’s not configured, then round-robin (rr) is the default value.
+
+- rr: round-robin
+- lc: least connection
+- dh: destination hashing
+- sh: source hashing
+- sed: shortest expected delay
+- nq: never queue
+
+In the future, we can implement Service specific scheduler (potentially via annotation), which has higher priority and overwrites the value.
+
+-->
+
+参数: --ipvs-scheduler
+
+添加了一个新的 kube-proxy 参数来指定 IPVS 负载均衡算法，参数为 --ipvs-scheduler。 如果未配置，则默认为 round-robin 算法（rr）。
+
+- rr: round-robin
+- lc: least connection
+- dh: destination hashing
+- sh: source hashing
+- sed: shortest expected delay
+- nq: never queue
+
+将来，我们可以实现特定于服务的调度程序（可能通过注释），该调度程序具有更高的优先级并覆盖该值。
+
+<!--
+
+Parameter: --cleanup-ipvs Similar to the --cleanup-iptables parameter, if true, cleanup IPVS configuration and IPTables rules that are created in IPVS mode.
+
+Parameter: --ipvs-sync-period Maximum interval of how often IPVS rules are refreshed (e.g. '5s', '1m'). Must be greater than 0.
+
+Parameter: --ipvs-min-sync-period Minimum interval of how often the IPVS rules are refreshed (e.g. '5s', '1m'). Must be greater than 0.
+
+-->
+
+参数: --cleanup-ipvs 类似于 --cleanup-iptables 参数，如果为 true，则清除在 IPVS 模式下创建的 IPVS 配置和 IPTables 规则。
+
+参数: --ipvs-sync-period 刷新 IPVS 规则的最大间隔时间（例如'5s'，'1m'）。 必须大于0。
+
+参数: --ipvs-min-sync-period 刷新 IPVS 规则的最小间隔时间间隔（例如'5s'，'1m'）。 必须大于0。
+
+<!--
+
+Parameter: --ipvs-exclude-cidrs  A comma-separated list of CIDR's which the IPVS proxier should not touch when cleaning up IPVS rules because IPVS proxier can't distinguish kube-proxy created IPVS rules from user original IPVS rules. If you are using IPVS proxier with your own IPVS rules in the environment, this parameter should be specified, otherwise your original rule will be cleaned.
+
+-->
+
+参数: --ipvs-exclude-cidrs  清除 IPVS 规则时 IPVS 代理不应触及的 CIDR 的逗号分隔列表，因为 IPVS 代理无法区分 kube-proxy 创建的 IPVS 规则和用户原始规则 IPVS 规则。 如果您在环境中使用 IPVS proxier 和您自己的 IPVS 规则，则应指定此参数，否则将清除原始规则。
+
+<!--
+
+Design Considerations
+
+IPVS Service Network Topology
+
+When creating a ClusterIP type Service, IPVS proxier will do the following three things:
+
+- Make sure a dummy interface exists in the node, defaults to kube-ipvs0
+- Bind Service IP addresses to the dummy interface
+- Create IPVS virtual servers for each Service IP address respectively
+  -->
+
+设计注意事项
+
+IPVS 服务网络拓扑
+
+创建 ClusterIP 类型服务时，IPVS proxier 将执行以下三项操作：
+
+- 确保节点中存在虚拟接口，默认为 kube-ipvs0
+- 将服务 IP 地址绑定到虚拟接口
+- 分别为每个服务 IP 地址创建 IPVS  虚拟服务器
+
+<!--
+
+Here comes an example:
+
+    # kubectl describe svc nginx-service
+    Name:			nginx-service
+    ...
+    Type:			ClusterIP
+    IP:			    10.102.128.4
+    Port:			http	3080/TCP
+    Endpoints:		10.244.0.235:8080,10.244.1.237:8080
+    Session Affinity:	None
+    
+    # ip addr
+    ...
+    73: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
+        link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
+        inet 10.102.128.4/32 scope global kube-ipvs0
+           valid_lft forever preferred_lft forever
+    
+    # ipvsadm -ln
+    IP Virtual Server version 1.2.1 (size=4096)
+    Prot LocalAddress:Port Scheduler Flags
+      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn     
+    TCP  10.102.128.4:3080 rr
+      -> 10.244.0.235:8080            Masq    1      0          0         
+      -> 10.244.1.237:8080            Masq    1      0          0   
+
+-->
+
+这是一个例子:
+
+    # kubectl describe svc nginx-service
+    Name:			nginx-service
+    ...
+    Type:			ClusterIP
+    IP:			    10.102.128.4
+    Port:			http	3080/TCP
+    Endpoints:		10.244.0.235:8080,10.244.1.237:8080
+    Session Affinity:	None
+    
+    # ip addr
+    ...
+    73: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
+        link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
+        inet 10.102.128.4/32 scope global kube-ipvs0
+           valid_lft forever preferred_lft forever
+    
+    # ipvsadm -ln
+    IP Virtual Server version 1.2.1 (size=4096)
+    Prot LocalAddress:Port Scheduler Flags
+      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn     
+    TCP  10.102.128.4:3080 rr
+      -> 10.244.0.235:8080            Masq    1      0          0         
+      -> 10.244.1.237:8080            Masq    1      0          0   
+
+<!--
+
+Please note that the relationship between a Kubernetes Service and IPVS virtual servers is 1:N. For example, consider a Kubernetes Service that has more than one IP address. An External IP type Service has two IP addresses - ClusterIP and External IP. Then the IPVS proxier will create 2 IPVS virtual servers - one for Cluster IP and another one for External IP. The relationship between a Kubernetes Endpoint (each IP+Port pair) and an IPVS virtual server is 1:1.
+
+Deleting of a Kubernetes service will trigger deletion of the corresponding IPVS virtual server, IPVS real servers and its IP addresses bound to the dummy interface.
+
+Port Mapping
+
+There are three proxy modes in IPVS: NAT (masq), IPIP and DR. Only NAT mode supports port mapping. Kube-proxy leverages NAT mode for port mapping. The following example shows IPVS mapping Service port 3080 to Pod port 8080.
+
+-->
+
+请注意，Kubernetes 服务和 IPVS 虚拟服务器之间的关系是“1：N”。 例如，考虑具有多个 IP 地址的 Kubernetes 服务。 外部 IP 类型服务有两个 IP 地址 - 集群IP和外部 IP。 然后，IPVS 代理将创建2个 IPVS 虚拟服务器 - 一个用于集群 IP，另一个用于外部 IP。 Kubernetes 的 endpoint（每个IP +端口对）与 IPVS 虚拟服务器之间的关系是“1：1”。
+
+删除 Kubernetes 服务将触发删除相应的 IPVS 虚拟服务器，IPVS 物理服务器及其绑定到虚拟接口的 IP 地址。
+
+端口映射
+
+IPVS 中有三种代理模式：NAT（masq），IPIP 和 DR。 只有 NAT 模式支持端口映射。 Kube-proxy 利用 NAT 模式进行端口映射。 以下示例显示 IPVS 服务端口3080到Pod端口8080的映射。
+
+    TCP  10.102.128.4:3080 rr
+      -> 10.244.0.235:8080            Masq    1      0          0         
+      -> 10.244.1.237:8080            Masq    1      0       
+
+<!--
+
+Session Affinity
+
+IPVS supports client IP session affinity (persistent connection). When a Service specifies session affinity, the IPVS proxier will set a timeout value (180min=10800s by default) in the IPVS virtual server. For example:
+
+-->
+
+会话关系
+
+IPVS 支持客户端 IP 会话关联（持久连接）。 当服务指定会话关系时，IPVS 代理将在 IPVS 虚拟服务器中设置超时值（默认为180分钟= 10800秒）。 例如：
+
+    # kubectl describe svc nginx-service
+    Name:			nginx-service
+    ...
+    IP:			    10.102.128.4
+    Port:			http	3080/TCP
+    Session Affinity:	ClientIP
+    
+    # ipvsadm -ln
+    IP Virtual Server version 1.2.1 (size=4096)
+    Prot LocalAddress:Port Scheduler Flags
+      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
+    TCP  10.102.128.4:3080 rr persistent 10800
+
+<!--
+
+Iptables & Ipset in IPVS Proxier
+
+IPVS is for load balancing and it can't handle other workarounds in kube-proxy, e.g. packet filtering, hairpin-masquerade tricks, SNAT, etc.
+
+IPVS proxier leverages iptables in the above scenarios. Specifically, ipvs proxier will fall back on iptables in the following 4 scenarios:
+
+- kube-proxy start with --masquerade-all=true
+- Specify cluster CIDR in kube-proxy startup
+- Support Loadbalancer type service
+- Support NodePort type service
+
+However, we don't want to create too many iptables rules. So we adopt ipset for the sake of decreasing iptables rules. The following is the table of ipset sets that IPVS proxier maintains:
+
+-->
+
+IPVS 代理中的 Iptables 和 Ipset
+
+IPVS 用于负载均衡，它无法处理 kube-proxy 中的其他问题，例如 包过滤，数据包欺骗，SNAT 等
+
+IPVS proxier 在上述场景中利用 iptables。 具体来说，ipvs proxier 将在以下4种情况下依赖于 iptables：
+
+- kube-proxy 以 --masquerade-all = true 开头
+- 在 kube-proxy 启动中指定集群 CIDR
+- 支持 Loadbalancer 类型服务
+- 支持 NodePort 类型的服务
+
+但是，我们不想创建太多的 iptables 规则。 所以我们采用 ipset 来减少 iptables 规则。 以下是 IPVS proxier 维护的 ipset 集表：
+
+<!--
+
+  set name                      	members                                 	usage                                   
+  KUBE-CLUSTER-IP               	All Service IP + port                   	masquerade for cases that masquerade-all=true or clusterCIDR specified
+  KUBE-LOOP-BACK                	All Service IP + port + IP              	masquerade for resolving hairpin issue  
+  KUBE-EXTERNAL-IP              	Service External IP + port              	masquerade for packets to external IPs  
+  KUBE-LOAD-BALANCER            	Load Balancer ingress IP + port         	masquerade for packets to Load Balancer type service
+  KUBE-LOAD-BALANCER-LOCAL      	Load Balancer ingress IP + port with externalTrafficPolicy=local	accept packets to Load Balancer with externalTrafficPolicy=local
+  KUBE-LOAD-BALANCER-FW         	Load Balancer ingress IP + port with loadBalancerSourceRanges	Drop packets for Load Balancer type Service with loadBalancerSourceRanges specified
+  KUBE-LOAD-BALANCER-SOURCE-CIDR	Load Balancer ingress IP + port + source CIDR	accept packets for Load Balancer type Service with loadBalancerSourceRanges specified
+  KUBE-NODE-PORT-TCP            	NodePort type Service TCP port          	masquerade for packets to NodePort(TCP) 
+  KUBE-NODE-PORT-LOCAL-TCP      	NodePort type Service TCP port with externalTrafficPolicy=local	accept packets to NodePort Service with externalTrafficPolicy=local
+  KUBE-NODE-PORT-UDP            	NodePort type Service UDP port          	masquerade for packets to NodePort(UDP) 
+  KUBE-NODE-PORT-LOCAL-UDP      	NodePort type service UDP port with externalTrafficPolicy=local	accept packets to NodePort Service with externalTrafficPolicy=local
+
+-->
+
+  设置名称                          	成员                                      	用法                                      
+  KUBE-CLUSTER-IP               	所有服务 IP + 端口                             	masquerade-all=true 或 clusterCIDR 指定的情况下进行伪装
+  KUBE-LOOP-BACK                	所有服务 IP +端口+ IP                          	解决数据包欺骗问题                               
+  KUBE-EXTERNAL-IP              	服务外部 IP +端口                              	将数据包伪装成外部 IP                             
+  KUBE-LOAD-BALANCER            	负载均衡器入口 IP +端口                           	将数据包伪装成 Load Balancer 类型的服务               
+  KUBE-LOAD-BALANCER-LOCAL      	负载均衡器入口 IP +端口 以及 externalTrafficPolicy=local	接受数据包到 Load Balancer externalTrafficPolicy=local
+  KUBE-LOAD-BALANCER-FW         	负载均衡器入口 IP +端口 以及 loadBalancerSourceRanges	使用指定的 loadBalancerSourceRanges 丢弃 Load Balancer类型Service的数据包
+  KUBE-LOAD-BALANCER-SOURCE-CIDR	负载均衡器入口 IP +端口 + 源 CIDR                  	接受 Load Balancer 类型 Service 的数据包，并指定loadBalancerSourceRanges
+  KUBE-NODE-PORT-TCP            	NodePort 类型服务 TCP                         	将数据包伪装成 NodePort（TCP）                    
+  KUBE-NODE-PORT-LOCAL-TCP      	NodePort 类型服务 TCP 端口，带有 externalTrafficPolicy=local	接受数据包到 NodePort 服务 使用 externalTrafficPolicy=local
+  KUBE-NODE-PORT-UDP            	NodePort 类型服务 UDP 端口                       	将数据包伪装成 NodePort(UDP)                   
+  KUBE-NODE-PORT-LOCAL-UDP      	NodePort 类型服务 UDP 端口 使用 externalTrafficPolicy=local	接受数据包到NodePort服务 使用 externalTrafficPolicy=local
+
+<!--
+
+In general, for IPVS proxier, the number of iptables rules is static, no matter how many Services/Pods we have.
+
+-->
+
+通常，对于 IPVS proxier，无论我们有多少 Service/ Pod，iptables 规则的数量都是静态的。
+
+<!--
+
+Run kube-proxy in IPVS Mode
+
+Currently, local-up scripts, GCE scripts, and kubeadm support switching IPVS proxy mode via exporting environment variables (KUBE_PROXY_MODE=ipvs) or specifying flag (--proxy-mode=ipvs). Before running IPVS proxier, please ensure IPVS required kernel modules are already installed.
+
+    ip_vs
+    ip_vs_rr
+    ip_vs_wrr
+    ip_vs_sh
+    nf_conntrack_ipv4
+
+Finally, for Kubernetes v1.10, feature gate SupportIPVSProxyMode is set to true by default. For Kubernetes v1.11, the feature gate is entirely removed. However, you need to enable --feature-gates=SupportIPVSProxyMode=true explicitly for Kubernetes before v1.10.
+
+-->
+
+在 IPVS 模式下运行 kube-proxy
+
+目前，本地脚本，GCE 脚本和 kubeadm 支持通过导出环境变量（KUBE_PROXY_MODE=ipvs）或指定标志（--proxy-mode=ipvs）来切换 IPVS 代理模式。 在运行IPVS 代理之前，请确保已安装 IPVS 所需的内核模块。
+
+    ip_vs
+    ip_vs_rr
+    ip_vs_wrr
+    ip_vs_sh
+    nf_conntrack_ipv4
+
+最后，对于 Kubernetes v1.10，“SupportIPVSProxyMode” 默认设置为 “true”。 对于 Kubernetes v1.11 ，该选项已完全删除。 但是，您需要在v1.10之前为Kubernetes 明确启用 --feature-gates = SupportIPVSProxyMode = true。
+
+<!--
+
+Get Involved
+
+The simplest way to get involved with Kubernetes is by joining one of the many Special Interest Groups (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly community meeting, and through the channels below.
+
+Thank you for your continued feedback and support.
+
+Post questions (or answer questions) on Stack Overflow
+
+Join the community portal for advocates on K8sPort
+
+Follow us on Twitter @Kubernetesio for latest updates
+
+Chat with the community on Slack
+
+Share your Kubernetes story
+
+-->
+
+参与其中
+
+参与 Kubernetes 的最简单方法是加入众多[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIG）中与您的兴趣一致的小组。 你有什么想要向 Kubernetes 社区广播的吗？ 在我们的每周[社区会议](https://github.com/kubernetes/community/blob/master/communication.md#weekly-meeting)或通过以下渠道分享您的声音。
+
+感谢您的持续反馈和支持。
+在[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)上发布问题（或回答问题）
+
+加入[K8sPort](http://k8sport.org/)的倡导者社区门户网站
+
+在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio )获取最新更新
+
+在[Slack](http://slack.k8s.io/)上与社区聊天
+
+分享您的 Kubernetes [故事](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
diff --git a/content/cn/docs/.gitkeep b/content/zh/docs/.gitkeep
similarity index 100%
rename from content/cn/docs/.gitkeep
rename to content/zh/docs/.gitkeep
diff --git a/content/cn/docs/_index.md b/content/zh/docs/_index.md
similarity index 100%
rename from content/cn/docs/_index.md
rename to content/zh/docs/_index.md
diff --git a/content/cn/docs/admin/accessing-the-api.md b/content/zh/docs/admin/accessing-the-api.md
similarity index 100%
rename from content/cn/docs/admin/accessing-the-api.md
rename to content/zh/docs/admin/accessing-the-api.md
diff --git a/content/cn/docs/admin/authorization/_index.md b/content/zh/docs/admin/authorization/_index.md
similarity index 100%
rename from content/cn/docs/admin/authorization/_index.md
rename to content/zh/docs/admin/authorization/_index.md
diff --git a/content/cn/docs/admin/authorization/abac.md b/content/zh/docs/admin/authorization/abac.md
similarity index 100%
rename from content/cn/docs/admin/authorization/abac.md
rename to content/zh/docs/admin/authorization/abac.md
diff --git a/content/cn/docs/admin/authorization/webhook.md b/content/zh/docs/admin/authorization/webhook.md
similarity index 100%
rename from content/cn/docs/admin/authorization/webhook.md
rename to content/zh/docs/admin/authorization/webhook.md
diff --git a/content/cn/docs/admin/bootstrap-tokens.md b/content/zh/docs/admin/bootstrap-tokens.md
similarity index 100%
rename from content/cn/docs/admin/bootstrap-tokens.md
rename to content/zh/docs/admin/bootstrap-tokens.md
diff --git a/content/cn/docs/admin/cluster-large.md b/content/zh/docs/admin/cluster-large.md
similarity index 100%
rename from content/cn/docs/admin/cluster-large.md
rename to content/zh/docs/admin/cluster-large.md
diff --git a/content/cn/docs/admin/daemon.yaml b/content/zh/docs/admin/daemon.yaml
similarity index 100%
rename from content/cn/docs/admin/daemon.yaml
rename to content/zh/docs/admin/daemon.yaml
diff --git a/content/cn/docs/admin/high-availability/_index.md b/content/zh/docs/admin/high-availability/_index.md
similarity index 100%
rename from content/cn/docs/admin/high-availability/_index.md
rename to content/zh/docs/admin/high-availability/_index.md
diff --git a/content/cn/docs/admin/kube-apiserver.md b/content/zh/docs/admin/kube-apiserver.md
similarity index 100%
rename from content/cn/docs/admin/kube-apiserver.md
rename to content/zh/docs/admin/kube-apiserver.md
diff --git a/content/cn/docs/admin/kubelet-authentication-authorization.md b/content/zh/docs/admin/kubelet-authentication-authorization.md
similarity index 100%
rename from content/cn/docs/admin/kubelet-authentication-authorization.md
rename to content/zh/docs/admin/kubelet-authentication-authorization.md
diff --git a/content/cn/docs/admin/kubelet-tls-bootstrapping.md b/content/zh/docs/admin/kubelet-tls-bootstrapping.md
similarity index 100%
rename from content/cn/docs/admin/kubelet-tls-bootstrapping.md
rename to content/zh/docs/admin/kubelet-tls-bootstrapping.md
diff --git a/content/cn/docs/admin/multiple-zones.md b/content/zh/docs/admin/multiple-zones.md
similarity index 100%
rename from content/cn/docs/admin/multiple-zones.md
rename to content/zh/docs/admin/multiple-zones.md
diff --git a/content/cn/docs/admin/node-conformance.md b/content/zh/docs/admin/node-conformance.md
similarity index 100%
rename from content/cn/docs/admin/node-conformance.md
rename to content/zh/docs/admin/node-conformance.md
diff --git a/content/cn/docs/admin/ovs-networking.md b/content/zh/docs/admin/ovs-networking.md
similarity index 100%
rename from content/cn/docs/admin/ovs-networking.md
rename to content/zh/docs/admin/ovs-networking.md
diff --git a/content/cn/docs/admin/service-accounts-admin.md b/content/zh/docs/admin/service-accounts-admin.md
similarity index 100%
rename from content/cn/docs/admin/service-accounts-admin.md
rename to content/zh/docs/admin/service-accounts-admin.md
diff --git a/content/cn/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md
similarity index 100%
rename from content/cn/docs/concepts/architecture/cloud-controller.md
rename to content/zh/docs/concepts/architecture/cloud-controller.md
diff --git a/content/cn/docs/concepts/architecture/master-node-communication.md b/content/zh/docs/concepts/architecture/master-node-communication.md
similarity index 100%
rename from content/cn/docs/concepts/architecture/master-node-communication.md
rename to content/zh/docs/concepts/architecture/master-node-communication.md
diff --git a/content/cn/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md
similarity index 100%
rename from content/cn/docs/concepts/architecture/nodes.md
rename to content/zh/docs/concepts/architecture/nodes.md
diff --git a/content/cn/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/addons.md
rename to content/zh/docs/concepts/cluster-administration/addons.md
diff --git a/content/cn/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/certificates.md
rename to content/zh/docs/concepts/cluster-administration/certificates.md
diff --git a/content/cn/docs/concepts/cluster-administration/cloud-providers.md b/content/zh/docs/concepts/cluster-administration/cloud-providers.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/cloud-providers.md
rename to content/zh/docs/concepts/cluster-administration/cloud-providers.md
diff --git a/content/cn/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/cluster-administration-overview.md
rename to content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md
diff --git a/content/cn/docs/concepts/cluster-administration/device-plugins.md b/content/zh/docs/concepts/cluster-administration/device-plugins.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/device-plugins.md
rename to content/zh/docs/concepts/cluster-administration/device-plugins.md
diff --git a/content/cn/docs/concepts/cluster-administration/federation.md b/content/zh/docs/concepts/cluster-administration/federation.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/federation.md
rename to content/zh/docs/concepts/cluster-administration/federation.md
diff --git a/content/cn/docs/concepts/cluster-administration/proxies.md b/content/zh/docs/concepts/cluster-administration/proxies.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/proxies.md
rename to content/zh/docs/concepts/cluster-administration/proxies.md
diff --git a/content/cn/docs/concepts/cluster-administration/sysctl-cluster.md b/content/zh/docs/concepts/cluster-administration/sysctl-cluster.md
similarity index 100%
rename from content/cn/docs/concepts/cluster-administration/sysctl-cluster.md
rename to content/zh/docs/concepts/cluster-administration/sysctl-cluster.md
diff --git a/content/cn/docs/concepts/configuration/commands.yaml b/content/zh/docs/concepts/configuration/commands.yaml
similarity index 100%
rename from content/cn/docs/concepts/configuration/commands.yaml
rename to content/zh/docs/concepts/configuration/commands.yaml
diff --git a/content/cn/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md
similarity index 100%
rename from content/cn/docs/concepts/configuration/manage-compute-resources-container.md
rename to content/zh/docs/concepts/configuration/manage-compute-resources-container.md
diff --git a/content/cn/docs/concepts/configuration/pod-with-node-affinity.yaml b/content/zh/docs/concepts/configuration/pod-with-node-affinity.yaml
similarity index 100%
rename from content/cn/docs/concepts/configuration/pod-with-node-affinity.yaml
rename to content/zh/docs/concepts/configuration/pod-with-node-affinity.yaml
diff --git a/content/cn/docs/concepts/configuration/pod-with-pod-affinity.yaml b/content/zh/docs/concepts/configuration/pod-with-pod-affinity.yaml
similarity index 100%
rename from content/cn/docs/concepts/configuration/pod-with-pod-affinity.yaml
rename to content/zh/docs/concepts/configuration/pod-with-pod-affinity.yaml
diff --git a/content/cn/docs/concepts/configuration/pod.yaml b/content/zh/docs/concepts/configuration/pod.yaml
similarity index 100%
rename from content/cn/docs/concepts/configuration/pod.yaml
rename to content/zh/docs/concepts/configuration/pod.yaml
diff --git a/content/cn/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md
similarity index 98%
rename from content/cn/docs/concepts/configuration/secret.md
rename to content/zh/docs/concepts/configuration/secret.md
index 5d59573aa739a..fd1a9d03779fd 100644
--- a/content/cn/docs/concepts/configuration/secret.md
+++ b/content/zh/docs/concepts/configuration/secret.md
@@ -104,7 +104,7 @@ $ kubectl create -f ./secret.yaml
 secret "mysecret" created
 ```
 
-**编码注意：** secret 数据的序列化 JSON 和 YAML 值使用 base64 编码成字符串。换行符在这些字符串中无效，必须省略。当在 Darwin/macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来拆分长行。另外，对于 Linux 用户如果 `-w` 选项不可用的话，应该添加选项 `-w 0` 到 `base64` 命令或管道 `base64 | tr -d '\n' ` 。
+**编码注意：** secret 数据的序列化 JSON 和 YAML 值使用 base64 编码成字符串。换行符在这些字符串中无效，必须省略。当在 Darwin/OS X 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来拆分长行。另外，对于 Linux 用户如果 `-w` 选项不可用的话，应该添加选项 `-w 0` 到 `base64` 命令或管道 `base64 | tr -d '\n' ` 。
 
 #### 解码 Secret
 
diff --git a/content/zh/docs/concepts/configuration/taint-and-toleration.md b/content/zh/docs/concepts/configuration/taint-and-toleration.md
new file mode 100755
index 0000000000000..a3c0eda8dd859
--- /dev/null
+++ b/content/zh/docs/concepts/configuration/taint-and-toleration.md
@@ -0,0 +1,464 @@
+---
+approvers:
+- davidopp
+- kevin-wangzefeng
+- bsalamat
+cn-approvers:
+- linyouchong
+title: Taint 和 Toleration
+content_template: templates/concept
+weight: 40
+---
+
+<!--
+---
+approvers:
+- davidopp
+- kevin-wangzefeng
+- bsalamat
+  title: Taints and Tolerations
+  content_template: templates/concept
+  weight: 40
+---
+-->
+
+{{< toc >}}
+
+{{% capture overview %}}
+<!--
+Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
+is a property of *pods* that *attracts* them to a set of nodes (either as a
+preference or a hard requirement). Taints are the opposite -- they allow a
+*node* to *repel* a set of pods.
+-->
+节点亲和性（详见[这里](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature)），是 *pod* 的一种属性（偏好或硬性要求），它使 *pod* 被吸引到一类特定的节点。Taint 则相反，它使 *节点* 能够 *排斥* 一类特定的 pod。
+
+<!--
+Taints and tolerations work together to ensure that pods are not scheduled
+onto inappropriate nodes. One or more taints are applied to a node; this
+marks that the node should not accept any pods that do not tolerate the taints.
+Tolerations are applied to pods, and allow (but do not require) the pods to schedule
+onto nodes with matching taints.
+-->
+Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有匹配 taint 的节点上。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!--
+
+## Concepts
+
+-->
+
+## 概念
+
+<!--
+You add a taint to a node using [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
+For example,
+-->
+您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个 taint。比如，
+
+```shell
+kubectl taint nodes node1 key=value:NoSchedule
+```
+
+<!--
+places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
+This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
+You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
+taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
+to schedule onto `node1`:
+-->
+给节点 `node1` 增加一个 taint，它的 key 是 `key`，value 是 `value`，effect 是 `NoSchedule`。这表示只有拥有和这个 taint 相匹配的 toleration 的 pod 才能够被分配到 `node1` 这个节点。您可以在 PodSpec 中定义 pod 的 toleration。下面两个 toleration 均与上面例子中使用 `kubectl taint` 命令创建的 taint 相匹配，因此如果一个 pod 拥有其中的任何一个 toleration 都能够被分配到 `node1` ：
+
+<!--
+To remove the taint added by the command above, you can run:
+-->
+想删除上述命令添加的 taint ，您可以运行：
+```shell
+kubectl taint nodes kube11 key:NoSchedule-
+```
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Equal"
+  value: "value"
+  effect: "NoSchedule"
+```
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Exists"
+  effect: "NoSchedule"
+```
+
+<!--
+A toleration "matches" a taint if the keys are the same and the effects are the same, and:
+
+* the `operator` is `Exists` (in which case no `value` should be specified), or
+* the `operator` is `Equal` and the `value`s are equal
+
+`Operator` defaults to `Equal` if not specified.
+-->
+一个 toleration 和一个 taint 相“匹配”是指它们有一样的 key 和 effect ，并且：
+
+* 如果 `operator` 是 `Exists` （此时 toleration 不能指定 `value`），或者
+* 如果 `operator` 是 `Equal` ，则它们的 `value` 应该相等
+
+{{< note >}}
+<!--
+**Note:** There are two special cases:
+
+* An empty `key` with operator `Exists` matches all keys, values and effects which means this
+  will tolerate everything.
+  -->
+
+**注意：** 存在两种特殊情况：
+
+* 如果一个 toleration 的 `key` 为空且 operator 为 `Exists` ，表示这个 toleration 与任意的 key 、 value 和 effect 都匹配，即这个 toleration 能容忍任意 taint。
+
+```yaml
+tolerations:
+- operator: "Exists"
+```
+
+<!--
+
+* An empty `effect` matches all effects with key `key`.
+  -->
+* 如果一个 toleration 的 `effect` 为空，则 `key` 值与之相同的相匹配 taint 的 `effect` 可以是任意值。
+
+```yaml
+tolerations:
+- key: "key"
+  operator: "Exists"
+```
+{{< /note >}}
+
+<!--
+The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
+This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
+pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
+`NoExecute`, described later.
+-->
+上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。这是“优化”或“软”版本的 `NoSchedule`  ——系统会*尽量*避免将 pod 调度到存在其不能容忍 taint 的节点上，但这不是强制的。`effect` 的值还可以设置为 `NoExecute` ，下文会详细描述这个值。
+
+<!--
+You can put multiple taints on the same node and multiple tolerations on the same pod.
+The way Kubernetes processes multiple taints and tolerations is like a filter: start
+with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the
+remaining un-ignored taints have the indicated effects on the pod. In particular,
+-->
+您可以给一个节点添加多个 taint ，也可以给一个 pod 添加多个 toleration。Kubernetes 处理多个 taint 和 toleration 的过程就像一个过滤器：从一个节点的所有 taint 开始遍历，过滤掉那些 pod 中存在与之相匹配的 toleration 的 taint。余下未被过滤的 taint 的 effect 值决定了 pod 是否会被分配到该节点，特别是以下情况：
+
+<!--
+
+* if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule
+  the pod onto that node
+* if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with
+  effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node
+* if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from
+  the node (if it is already running on the node), and will not be
+  scheduled onto the node (if it is not yet running on the node).
+  -->
+* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。
+* 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会*尝试*将 pod 分配到该节点。
+* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。
+
+<!--
+For example, imagine you taint a node like this
+-->
+例如，假设您给一个节点添加了如下的 taint
+
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule
+kubectl taint nodes node1 key1=value1:NoExecute
+kubectl taint nodes node1 key2=value2:NoSchedule
+```
+
+<!--
+And a pod has two tolerations:
+-->
+然后存在一个 pod，它有两个 toleration
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoSchedule"
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+```
+
+<!--
+In this case, the pod will not be able to schedule onto the node, because there is no
+toleration matching the third taint. But it will be able to continue running if it is
+already running on the node when the taint is added, because the third taint is the only
+one of the three that is not tolerated by the pod.
+-->
+在这个例子中，上述 pod 不会被分配到上述节点，因为其没有 toleration 和第三个 taint 相匹配。但是如果在给节点添加 上述 taint 之前，该 pod 已经在上述节点运行，那么它还可以继续运行在该节点上，因为第三个 taint 是三个 taint 中唯一不能被这个 pod 容忍的。
+
+<!--
+Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do
+not tolerate the taint will be evicted immediately, and any pods that do tolerate the
+taint will never be evicted. However, a toleration with `NoExecute` effect can specify
+an optional `tolerationSeconds` field that dictates how long the pod will stay bound
+to the node after the taint is added. For example,
+-->
+通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的 taint，则任何不能忍受这个 taint 的 pod 都会马上被驱逐，任何可以忍受这个 taint 的 pod 都不会被驱逐。但是，如果 pod 存在一个 effect 值为 `NoExecute` 的 toleration 指定了可选属性 `tolerationSeconds` 的值，则表示在给节点添加了上述 taint 之后，pod 还能继续在节点上运行的时间。例如，
+
+```yaml
+tolerations:
+- key: "key1"
+  operator: "Equal"
+  value: "value1"
+  effect: "NoExecute"
+  tolerationSeconds: 3600
+```
+
+<!--
+means that if this pod is running and a matching taint is added to the node, then
+the pod will stay bound to the node for 3600 seconds, and then be evicted. If the
+taint is removed before that time, the pod will not be evicted.
+-->
+这表示如果这个 pod 正在运行，然后一个匹配的 taint 被添加到其所在的节点，那么 pod 还将继续在节点上运行 3600 秒，然后被驱逐。如果在此之前上述 taint 被删除了，则 pod 不会被驱逐。
+
+<!--
+
+## Example Use Cases
+
+-->
+
+## 使用例子
+
+<!--
+Taints and tolerations are a flexible way to steer pods *away* from nodes or evict
+pods that shouldn't be running. A few of the use cases are
+-->
+通过 taint 和 toleration ，可以灵活地让 pod *避开*某些节点或者将 pod 从某些节点驱逐。下面是几个使用例子：
+
+<!--
+
+* **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by
+  a particular set of users, you can add a taint to those nodes (say,
+  `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
+  toleration to their pods (this would be done most easily by writing a custom
+  [admission controller](/docs/reference/access-authn-authz/admission-controllers/)).
+  The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
+  well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
+  ensure they *only* use the dedicated nodes, then you should additionally add a label similar
+  to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission
+  controller should additionally add a node affinity to require that the pods can only schedule
+  onto nodes labeled with `dedicated=groupName`.
+  -->
+* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个 taint（即，
+  `kubectl taint nodes nodename dedicated=groupName:NoSchedule`），然后给这组用户的 pod 添加一个相对应的 toleration（通过编写一个自定义的[admission controller](/docs/admin/admission-controllers/)，很容易就能做到）。拥有上述 toleration 的 pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。如果您希望这些 pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 taint 类似的 label （例如：`dedicated=groupName`），同时 还要在上述 admission controller 中给 pod 增加节点亲和性要求上述 pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。
+
+<!--
+
+* **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized
+  hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
+  hardware off of those nodes, thus leaving room for later-arriving pods that do need the
+  specialized hardware. This can be done by tainting the nodes that have the specialized
+  hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
+  `kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
+  toleration to pods that use the special hardware. As in the dedicated nodes use case,
+  it is probably easiest to apply the tolerations using a custom
+  [admission controller](/docs/eference/access-authn-authz/admission-controllers/)).
+  For example, it is recommended to use [Extended
+  Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+  to represent the special hardware, taint your special hardware nodes with the
+  extended resource name and run the
+  [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
+  admission controller. Now, because the nodes are tainted, no pods without the
+  toleration will schedule on them. But when you submit a pod that requests the
+  extended resource, the `ExtendedResourceToleration` admission controller will
+  automatically add the correct toleration to the pod and that pod will schedule
+  on the special hardware nodes. This will make sure that these special hardware
+  nodes are dedicated for pods requesting such hardware and you don't have to
+  manually add tolerations to your pods.
+  -->
+* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中，我们希望不需要这类硬件的 pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 pod 保留资源。要达到这个目的，可以先给配备了特殊硬件的节点添加 taint（例如 `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`)，然后给使用了这类特殊硬件的 pod 添加一个相匹配的 toleration。和专用节点的例子类似，添加这个 toleration 的最简单的方法是使用自定义 [admission controller](/docs/reference/access-authn-authz/admission-controllers/)。比如，我们推荐使用 [Extended Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加 taint 时包含 extended resource 名称，然后运行一个 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) admission controller。此时，因为节点已经被 taint 了，没有对应 toleration 的 Pod 会被调度到这些节点。但当你创建一个使用了 extended resource 的 Pod 时，`ExtendedResourceToleration` admission controller 会自动给 Pod 加上正确的 toleration ，这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。这样就能够确保这些配置了特殊硬件的节点专门用于运行 需要使用这些硬件的 Pod，并且您无需手动给这些 Pod 添加 toleration。
+
+<!--
+
+* **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior
+  when there are node problems, which is described in the next section.
+  -->
+* **基于 taint 的驱逐 （alpha 特性）**: 这是在每个 pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性
+
+<!--
+
+## Taint based Evictions
+
+-->
+
+## 基于 taint 的驱逐
+
+<!--
+Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
+running on the node as follows
+
+ * pods that do not tolerate the taint are evicted immediately
+ * pods that tolerate the taint without specifying `tolerationSeconds` in
+  their toleration specification remain bound forever
+ * pods that tolerate the taint with a specified `tolerationSeconds` remain
+   bound for the specified amount of time
+  -->
+  前文我们提到过 taint 的 effect 值 `NoExecute`  ，它会影响已经在节点上运行的 pod
+ * 如果 pod 不能忍受effect 值为 `NoExecute` 的 taint，那么 pod 将马上被驱逐
+ * 如果 pod 能够忍受effect 值为 `NoExecute` 的 taint，但是在 toleration 定义中没有指定 `tolerationSeconds`，则 pod 还会一直在这个节点上运行。
+ * 如果 pod 能够忍受effect 值为 `NoExecute` 的 taint，而且指定了 `tolerationSeconds`，则 pod 还能在这个节点上继续运行这个指定的时间长度。
+
+<!--
+In addition, Kubernetes 1.6 introduced alpha support for representing node
+problems. In other words, the node controller automatically taints a node when
+certain condition is true. The following taints are built in:
+
+ * `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to
+   the NodeCondition `Ready` being "`False`".
+ * `node.kubernetes.io/unreachable`: Node is unreachable from the node
+   controller. This corresponds to the NodeCondition `Ready` being "`Unknown`".
+ * `node.kubernetes.io/out-of-disk`: Node becomes out of disk.
+ * `node.kubernetes.io/memory-pressure`: Node has memory pressure.
+ * `node.kubernetes.io/disk-pressure`: Node has disk pressure.
+ * `node.kubernetes.io/network-unavailable`: Node's network is unavailable.
+ * `node.kubernetes.io/unschedulable`: Node is unschedulable.
+ * `node.cloudprovider.kubernetes.io/uninitialized`: When the kubelet is started
+    with "external" cloud provider, this taint is set on a node to mark it
+    as unusable. After a controller from the cloud-controller-manager initializes
+    this node, the kubelet removes this taint.
+  -->
+  此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括：
+ * `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。
+ * `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
+ * `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。
+ * `node.kubernetes.io/memory-pressure`：节点存在内存压力。
+ * `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。
+ * `node.kubernetes.io/network-unavailable`：节点网络不可用。
+ * `node.kubernetes.io/unschedulable`: 节点不可调度。
+ * `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" cloud provider，它将给当前节点添加一个 taint 将其标志为不可用。在 cloud-controller-manager 的一个 controller 初始化这个节点后，kubelet 将删除这个 taint。
+
+<!--
+When the `TaintBasedEvictions` alpha feature is enabled (you can do this by
+including `TaintBasedEvictions=true` in `--feature-gates` for Kubernetes controller manager,
+such as `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
+added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
+based on the Ready NodeCondition is disabled.
+-->
+在启用了 `TaintBasedEvictions` 这个 alpha 功能特性后（在 Kubernetes controller manager 的 `--feature-gates` 参数中包含`TaintBasedEvictions=true` 开启这个功能特性，例如：`--feature-gates=FooBar=true,TaintBasedEvictions=true`），NodeController (或 kubelet)会自动给节点添加这类 taint，上述基于节点状态 Ready 对 pod 进行驱逐的逻辑会被禁用。
+
+{{< note >}}
+<!--
+**Note:** To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
+behavior of pod evictions due to node problems, the system actually adds the taints
+in a rate-limited way. This prevents massive pod evictions in scenarios such
+as the master becoming partitioned from the nodes.
+-->
+注意：为了保证由于节点问题引起的 pod 驱逐[rate limiting](/docs/concepts/architecture/nodes/)行为正常，系统实际上会以 rate-limited 的方式添加 taint。在像 master 和 node 通讯中断等场景下，这避免了 pod 被大量驱逐。
+{{< /note >}}
+
+<!--
+This alpha feature, in combination with `tolerationSeconds`, allows a pod
+to specify how long it should stay bound to a node that has one or both of these problems.
+-->
+使用这个 alpha 功能特性，结合 `tolerationSeconds` ，pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。
+
+<!--
+For example, an application with a lot of local state might want to stay
+bound to node for a long time in the event of network partition, in the hope
+that the partition will recover and thus the pod eviction can be avoided.
+The toleration the pod would use in that case would look like
+-->
+比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间，愿意等待网络恢复以避免被驱逐。在这种情况下，pod 的 toleration 可能是下面这样的：
+
+```yaml
+tolerations:
+- key: "node.alpha.kubernetes.io/unreachable"
+  operator: "Exists"
+  effect: "NoExecute"
+  tolerationSeconds: 6000
+```
+
+<!--
+Note that Kubernetes automatically adds a toleration for
+`node.kubernetes.io/not-ready` with `tolerationSeconds=300`
+unless the pod configuration provided
+by the user already has a toleration for `node.kubernetes.io/not-ready`.
+Likewise it adds a toleration for
+`node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300`
+unless the pod configuration provided
+by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`.
+-->
+注意，Kubernetes 会自动给 pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的 toleration。同样，Kubernetes 会给 pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/unreachable` 的 toleration。
+
+<!--
+These automatically-added tolerations ensure that
+the default pod behavior of remaining bound for 5 minutes after one of these
+problems is detected is maintained.
+The two default tolerations are added by the [DefaultTolerationSeconds
+admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
+-->
+这种自动添加 toleration 机制保证了在其中一种问题被检测到时 pod 默认能够继续停留在当前节点运行 5 分钟。这两个默认 toleration 是由 [DefaultTolerationSeconds
+admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds)添加的。
+
+<!--
+[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
+`NoExecute` tolerations for the following taints with no `tolerationSeconds`:
+
+  * `node.alpha.kubernetes.io/unreachable`
+  * `node.kubernetes.io/not-ready`
+
+This ensures that DaemonSet pods are never evicted due to these problems,
+which matches the behavior when this feature is disabled.
+-->
+[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 中的 pod 被创建时，针对以下 taint 自动添加的 `NoExecute` 的 toleration 将不会指定 `tolerationSeconds`：
+
+  * `node.alpha.kubernetes.io/unreachable`
+  * `node.kubernetes.io/not-ready`
+
+这保证了出现上述问题时 DaemonSet 中的 pod 永远不会被驱逐，这和 `TaintBasedEvictions` 这个特性被禁用后的行为是一样的。
+
+<!--
+
+## Taint Nodes by Condition
+
+-->
+
+## 基于节点状态添加 taint
+
+<!--
+Version 1.8 introduces an alpha feature that causes the node controller to create taints corresponding to
+Node conditions. When this feature is enabled (you can do this by including `TaintNodesByCondition=true` in the `--feature-gates` command line flag to the scheduler, such as
+`--feature-gates=FooBar=true,TaintNodesByCondition=true`), the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
+
+Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
+following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
+breaking.
+
+  * `node.kubernetes.io/memory-pressure`
+  * `node.kubernetes.io/disk-pressure`
+  * `node.kubernetes.io/out-of-disk` (*only for critical pods*)
+  * `node.kubernetes.io/unschedulable` (1.10 or later)
+  * `node.kubernetes.io/network-unavailable` (*host network only*)
+  -->
+1.8 版本引入了一个 alpha 特性，让 node controller 根据节点的状态创建 taint。当开启了这个特性时（通过给 scheduler 的 `--feature-gates` 添加 `TaintNodesByCondition=true` 参数，例如：`--feature-gates=FooBar=true,TaintNodesByCondition=true`），scheduler不会去检查节点的状态，而是检查节点的 taint。这确保了节点的状态不影响应该调度哪些 Pod 到节点上。用户可以通过给 Pod 添加 toleration 来选择忽略节点的一些问题（节点状态的形式表示）。
+从 Kubernetes 1.8 开始，DaemonSet controller 会自动添加如下 `NoSchedule` toleration，以防止 DaemonSet 中断。
+  * `node.kubernetes.io/memory-pressure`
+  * `node.kubernetes.io/disk-pressure`
+  * `node.kubernetes.io/out-of-disk` (*只适合 critical pod*)
+  * `node.kubernetes.io/unschedulable` (1.10 或更高版本)
+  * `node.kubernetes.io/network-unavailable` (*只适合 host network*)
+
+<!--
+Adding these tolerations ensures backward compatibility. You can also add
+arbitrary tolerations to DaemonSets.
+-->
+添加上述 toleration 确保了向后兼容，您也可以选择自由的向 DaemonSet 添加 toleration。
diff --git a/content/cn/docs/concepts/containers/container-environment-variables.md b/content/zh/docs/concepts/containers/container-environment-variables.md
similarity index 100%
rename from content/cn/docs/concepts/containers/container-environment-variables.md
rename to content/zh/docs/concepts/containers/container-environment-variables.md
diff --git a/content/cn/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md
similarity index 99%
rename from content/cn/docs/concepts/containers/images.md
rename to content/zh/docs/concepts/containers/images.md
index 11f902444889c..cc123251bef2c 100644
--- a/content/cn/docs/concepts/containers/images.md
+++ b/content/zh/docs/concepts/containers/images.md
@@ -87,7 +87,7 @@ Kubelet会获取并且定期刷新ECR的凭证。它需要以下权限
 
 - 验证是否满足以上要求
 - 获取工作站的$REGION (例如 `us-west-2`)凭证，使用凭证SSH到主机手动运行docker，检查是否运行
-- 验证kublet是否使用参数`--cloud-provider=aws`运行
+- 验证kubelet是否使用参数`--cloud-provider=aws`运行
 - 检查kubelet日志(例如 `journalctl -u kubelet`)，是否有类似的行
   - `plugins.go:56] Registering credential provider: aws-ecr-key`
   - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
diff --git a/content/cn/docs/concepts/example-concept-template.md b/content/zh/docs/concepts/example-concept-template.md
similarity index 100%
rename from content/cn/docs/concepts/example-concept-template.md
rename to content/zh/docs/concepts/example-concept-template.md
diff --git a/content/cn/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md
similarity index 100%
rename from content/cn/docs/concepts/overview/components.md
rename to content/zh/docs/concepts/overview/components.md
diff --git a/content/cn/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md
similarity index 100%
rename from content/cn/docs/concepts/overview/kubernetes-api.md
rename to content/zh/docs/concepts/overview/kubernetes-api.md
diff --git a/content/cn/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md
similarity index 100%
rename from content/cn/docs/concepts/overview/what-is-kubernetes.md
rename to content/zh/docs/concepts/overview/what-is-kubernetes.md
diff --git a/content/cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
similarity index 100%
rename from content/cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md
rename to content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
diff --git a/content/cn/docs/concepts/overview/working-with-objects/nginx-deployment.yaml b/content/zh/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
similarity index 100%
rename from content/cn/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
rename to content/zh/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
diff --git a/content/cn/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md
similarity index 100%
rename from content/cn/docs/concepts/policy/pod-security-policy.md
rename to content/zh/docs/concepts/policy/pod-security-policy.md
diff --git a/content/cn/docs/concepts/policy/psp.yaml b/content/zh/docs/concepts/policy/psp.yaml
similarity index 100%
rename from content/cn/docs/concepts/policy/psp.yaml
rename to content/zh/docs/concepts/policy/psp.yaml
diff --git a/content/cn/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md
similarity index 100%
rename from content/cn/docs/concepts/policy/resource-quotas.md
rename to content/zh/docs/concepts/policy/resource-quotas.md
diff --git a/content/cn/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
similarity index 100%
rename from content/cn/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
rename to content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
diff --git a/content/cn/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md
similarity index 100%
rename from content/cn/docs/concepts/services-networking/connect-applications-service.md
rename to content/zh/docs/concepts/services-networking/connect-applications-service.md
diff --git a/content/cn/docs/concepts/services-networking/curlpod.yaml b/content/zh/docs/concepts/services-networking/curlpod.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/curlpod.yaml
rename to content/zh/docs/concepts/services-networking/curlpod.yaml
diff --git a/content/cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md
similarity index 100%
rename from content/cn/docs/concepts/services-networking/dns-pod-service.md
rename to content/zh/docs/concepts/services-networking/dns-pod-service.md
diff --git a/content/cn/docs/concepts/services-networking/hostaliases-pod.yaml b/content/zh/docs/concepts/services-networking/hostaliases-pod.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/hostaliases-pod.yaml
rename to content/zh/docs/concepts/services-networking/hostaliases-pod.yaml
diff --git a/content/cn/docs/concepts/services-networking/ingress.yaml b/content/zh/docs/concepts/services-networking/ingress.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/ingress.yaml
rename to content/zh/docs/concepts/services-networking/ingress.yaml
diff --git a/content/cn/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md
similarity index 100%
rename from content/cn/docs/concepts/services-networking/network-policies.md
rename to content/zh/docs/concepts/services-networking/network-policies.md
diff --git a/content/cn/docs/concepts/services-networking/nginx-secure-app.yaml b/content/zh/docs/concepts/services-networking/nginx-secure-app.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/nginx-secure-app.yaml
rename to content/zh/docs/concepts/services-networking/nginx-secure-app.yaml
diff --git a/content/cn/docs/concepts/services-networking/nginx-svc.yaml b/content/zh/docs/concepts/services-networking/nginx-svc.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/nginx-svc.yaml
rename to content/zh/docs/concepts/services-networking/nginx-svc.yaml
diff --git a/content/cn/docs/concepts/services-networking/run-my-nginx.yaml b/content/zh/docs/concepts/services-networking/run-my-nginx.yaml
similarity index 100%
rename from content/cn/docs/concepts/services-networking/run-my-nginx.yaml
rename to content/zh/docs/concepts/services-networking/run-my-nginx.yaml
diff --git a/content/cn/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md
similarity index 100%
rename from content/cn/docs/concepts/services-networking/service.md
rename to content/zh/docs/concepts/services-networking/service.md
diff --git a/content/cn/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/cron-jobs.md
rename to content/zh/docs/concepts/workloads/controllers/cron-jobs.md
diff --git a/content/cn/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/daemonset.md
rename to content/zh/docs/concepts/workloads/controllers/daemonset.md
diff --git a/content/cn/docs/concepts/workloads/controllers/daemonset.yaml b/content/zh/docs/concepts/workloads/controllers/daemonset.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/daemonset.yaml
rename to content/zh/docs/concepts/workloads/controllers/daemonset.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/deployment.md
rename to content/zh/docs/concepts/workloads/controllers/deployment.md
diff --git a/content/cn/docs/concepts/workloads/controllers/frontend.yaml b/content/zh/docs/concepts/workloads/controllers/frontend.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/frontend.yaml
rename to content/zh/docs/concepts/workloads/controllers/frontend.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/garbage-collection.md b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/garbage-collection.md
rename to content/zh/docs/concepts/workloads/controllers/garbage-collection.md
diff --git a/content/cn/docs/concepts/workloads/controllers/hpa-rs.yaml b/content/zh/docs/concepts/workloads/controllers/hpa-rs.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/hpa-rs.yaml
rename to content/zh/docs/concepts/workloads/controllers/hpa-rs.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/job.yaml b/content/zh/docs/concepts/workloads/controllers/job.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/job.yaml
rename to content/zh/docs/concepts/workloads/controllers/job.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/my-repset.yaml b/content/zh/docs/concepts/workloads/controllers/my-repset.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/my-repset.yaml
rename to content/zh/docs/concepts/workloads/controllers/my-repset.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/nginx-deployment.yaml b/content/zh/docs/concepts/workloads/controllers/nginx-deployment.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/nginx-deployment.yaml
rename to content/zh/docs/concepts/workloads/controllers/nginx-deployment.yaml
diff --git a/content/cn/docs/concepts/workloads/controllers/replication.yaml b/content/zh/docs/concepts/workloads/controllers/replication.yaml
similarity index 100%
rename from content/cn/docs/concepts/workloads/controllers/replication.yaml
rename to content/zh/docs/concepts/workloads/controllers/replication.yaml
diff --git a/content/cn/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/pods/init-containers.md
rename to content/zh/docs/concepts/workloads/pods/init-containers.md
diff --git a/content/cn/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/pods/pod-lifecycle.md
rename to content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
diff --git a/content/cn/docs/concepts/workloads/pods/podpreset.md b/content/zh/docs/concepts/workloads/pods/podpreset.md
similarity index 100%
rename from content/cn/docs/concepts/workloads/pods/podpreset.md
rename to content/zh/docs/concepts/workloads/pods/podpreset.md
diff --git a/content/zh/docs/getting-started-guides/ubuntu/security.md b/content/zh/docs/getting-started-guides/ubuntu/security.md
new file mode 100644
index 0000000000000..49839858b20d4
--- /dev/null
+++ b/content/zh/docs/getting-started-guides/ubuntu/security.md
@@ -0,0 +1,68 @@
+---
+title: 安全考虑
+content_template: templates/task
+---
+<!--
+---
+title: Security Considerations
+content_template: templates/task
+---
+-->
+
+{{% capture overview %}}
+<!--
+By default all connections between every provided node are secured via TLS by easyrsa, including the etcd cluster.
+
+This page explains the security considerations of a deployed cluster and production recommendations.
+-->
+默认情况下，所有提供的节点之间的所有连接（包括 etcd 集群）都通过 easyrsa 的 TLS 进行保护。
+
+本文介绍已部署集群的安全注意事项和生产环境建议。
+{{% /capture %}}
+{{% capture prerequisites %}}
+<!--
+This page assumes you have a working Juju deployed cluster.
+-->
+本文假定您拥有一个使用 Juju 部署的正在运行的集群。
+{{% /capture %}}
+
+
+{{% capture steps %}}
+<!--
+## Implementation
+
+The TLS and easyrsa implementations use the following [layers](https://jujucharms.com/docs/2.2/developer-layers).
+
+[layer-tls-client](https://github.com/juju-solutions/layer-tls-client)
+[layer-easyrsa](https://github.com/juju-solutions/layer-easyrsa)
+-->
+## 实现
+
+TLS 和 easyrsa 的实现使用以下 [layers](https://jujucharms.com/docs/2.2/developer-layers)。
+
+[layer-tls-client](https://github.com/juju-solutions/layer-tls-client)
+[layer-easyrsa](https://github.com/juju-solutions/layer-easyrsa)
+
+<!--
+## Limiting ssh access
+
+By default the administrator can ssh to any deployed node in a cluster. You can mass disable ssh access to the cluster nodes by issuing the following command.
+
+    juju model-config proxy-ssh=true
+
+Note: The Juju controller node will still have open ssh access in your cloud, and will be used as a jump host in this case.
+
+Refer to the [model management](https://jujucharms.com/docs/2.2/models) page in the Juju documentation for instructions on how to manage ssh keys.
+-->
+## 限制 ssh 访问
+
+默认情况下，管理员可以 ssh 到集群中的任意已部署节点。您可以通过以下命令来批量禁用集群节点的 ssh 访问权限。
+
+    juju model-config proxy-ssh=true
+
+注意：Juju 控制器节点在您的云中仍然有开放的 ssh 访问权限，并且在这种情况下将被用作跳板机。
+
+有关如何管理 ssh 密钥的说明，请参阅 Juju 文档中的 [模型管理](https://jujucharms.com/docs/2.2/models) 页面。
+{{% /capture %}}
+
+
diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
new file mode 100755
index 0000000000000..d855803396f22
--- /dev/null
+++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
@@ -0,0 +1,563 @@
+---
+assignees:
+- bprashanth
+- davidopp
+- derekwaynecarr
+- erictune
+- janetkuo
+- thockin
+cn-approvers:
+- linyouchong
+title: 使用准入控制插件
+---
+<!--
+---
+assignees:
+- bprashanth
+- davidopp
+- derekwaynecarr
+- erictune
+- janetkuo
+- thockin
+title: Using Admission Controllers
+---
+-->
+
+* TOC
+{:toc}
+
+<!--
+## What are they?
+-->
+## 什么是准入控制插件？
+
+<!--
+An admission control plug-in is a piece of code that intercepts requests to the Kubernetes
+API server prior to persistence of the object, but after the request is authenticated
+and authorized.  The plug-in code is in the API server process
+and must be compiled into the binary in order to be used at this time.
+-->
+一个准入控制插件是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API server 的请求。插件代码运行在 API server 进程中，必须将其编译为二进制文件，以便在此时使用。
+
+<!--
+Each admission control plug-in is run in sequence before a request is accepted into the cluster.  If
+any of the plug-ins in the sequence reject the request, the entire request is rejected immediately
+and an error is returned to the end-user.
+-->
+在每个请求被集群接受之前，准入控制插件依次执行。如果插件序列中任何一个拒绝了该请求，则整个请求将立即被拒绝并且返回一个错误给终端用户。
+
+<!--
+Admission control plug-ins may mutate the incoming object in some cases to apply system configured
+defaults.  In addition, admission control plug-ins may mutate related resources as part of request
+processing to do things like increment quota usage.
+-->
+准入控制插件可能会在某些情况下改变传入的对象，从而应用系统配置的默认值。另外，作为请求处理的一部分，准入控制插件可能会对相关的资源进行变更，以实现类似增加配额使用量这样的功能。
+
+<!--
+## Why do I need them?
+-->
+## 为什么需要准入控制插件？
+
+<!--
+Many advanced features in Kubernetes require an admission control plug-in to be enabled in order
+to properly support the feature.  As a result, a Kubernetes API server that is not properly
+configured with the right set of admission control plug-ins is an incomplete server and will not
+support all the features you expect.
+-->
+Kubernetes 的许多高级功能都要求启用一个准入控制插件，以便正确地支持该特性。因此，一个没有正确配置准入控制插件的 Kubernetes API server 是不完整的，它不会支持您所期望的所有特性。
+
+<!--
+## How do I turn on an admission control plug-in?
+-->
+## 如何启用一个准入控制插件？
+
+<!--
+The Kubernetes API server supports a flag, `admission-control` that takes a comma-delimited,
+ordered list of admission control choices to invoke prior to modifying objects in the cluster.
+-->
+Kubernetes API server 支持一个标志参数 `admission-control` ，它指定了一个用于在集群修改对象之前调用的以逗号分隔的准入控制插件顺序列表。
+
+<!--
+## What does each plug-in do?
+-->
+## 每个插件的功能是什么？
+
+### AlwaysAdmit
+
+<!--
+Use this plugin by itself to pass-through all requests.
+-->
+使用这个插件自行通过所有的请求。
+
+### AlwaysPullImages
+
+<!--
+This plug-in modifies every new Pod to force the image pull policy to Always. This is useful in a
+multitenant cluster so that users can be assured that their private images can only be used by those
+who have the credentials to pull them. Without this plug-in, once an image has been pulled to a
+node, any pod from any user can use it simply by knowing the image's name (assuming the Pod is
+scheduled onto the right node), without any authorization check against the image. When this plug-in
+is enabled, images are always pulled prior to starting containers, which means valid credentials are
+required.
+-->
+这个插件修改每一个新创建的 Pod 的镜像拉取策略为 Always 。这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。没有这个插件，一旦镜像被拉取到节点上，任何用户的 pod 都可以通过已了解到的镜像的名称（假设 pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。当启用这个插件时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。
+
+### AlwaysDeny
+
+<!--
+Rejects all requests.  Used for testing.
+-->
+拒绝所有的请求。用于测试。
+
+<!--
+### DenyExecOnPrivileged (deprecated)
+-->
+### DenyExecOnPrivileged （已废弃）
+
+<!--
+This plug-in will intercept all requests to exec a command in a pod if that pod has a privileged container.
+-->
+如果一个 pod 拥有一个特权容器，这个插件将拦截所有在该 pod 中执行 exec 命令的请求。
+
+<!--
+If your cluster supports privileged containers, and you want to restrict the ability of end-users to exec
+commands in those containers, we strongly encourage enabling this plug-in.
+-->
+如果集群支持特权容器，并且希望限制最终用户在这些容器中执行 exec 命令的能力，我们强烈建议启用这个插件。
+
+<!--
+This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
+-->
+此功能已合并到 [DenyEscalatingExec](#denyescalatingexec)。
+
+### DenyEscalatingExec
+
+<!--
+This plug-in will deny exec and attach commands to pods that run with escalated privileges that
+allow host access.  This includes pods that run as privileged, have access to the host IPC namespace, and
+have access to the host PID namespace.
+-->
+这个插件将拒绝在拥有衍生特权而具备访问宿主机能力的 pod 中执行 exec 和 attach 命令。这包括在特权模式运行的 pod ，可以访问主机 IPC 命名空间的 pod ，和访问主机 PID 命名空间的 pod 。
+
+<!--
+If your cluster supports containers that run with escalated privileges, and you want to
+restrict the ability of end-users to exec commands in those containers, we strongly encourage
+enabling this plug-in.
+-->
+如果集群支持使用以衍生特权运行的容器，并且希望限制最终用户在这些容器中执行 exec 命令的能力，我们强烈建议启用这个插件。
+
+### ImagePolicyWebhook
+
+<!--
+The ImagePolicyWebhook plug-in allows a backend webhook to make admission decisions. You enable this plug-in by setting the admission-control option as follows:
+-->
+ImagePolicyWebhook 插件允许使用一个后端的 webhook 做出准入决策。您可以按照如下配置 admission-control 选项来启用这个插件:
+
+```shell
+--admission-control=ImagePolicyWebhook
+```
+
+<!--
+#### Configuration File Format
+-->
+#### 配置文件格式
+<!--
+ImagePolicyWebhook uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend. This file may be json or yaml and has the following format:
+-->
+ImagePolicyWebhook 插件使用了admission config 文件 `--admission-control-config-file` 来为后端行为设置配置选项。该文件可以是 json 或 yaml ，并具有以下格式:
+
+```javascript
+{
+  "imagePolicy": {
+     "kubeConfigFile": "path/to/kubeconfig/for/backend",
+     "allowTTL": 50,           // time in s to cache approval
+     "denyTTL": 50,            // time in s to cache denial
+     "retryBackoff": 500,      // time in ms to wait between retries
+     "defaultAllow": true      // determines behavior if the webhook backend fails
+  }
+}
+```
+
+<!--
+The config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
+-->
+这个配置文件必须引用一个 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 格式的文件，并在其中配置指向后端的连接。且需要在 TLS 上与后端进行通信。
+
+<!--
+The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
+-->
+kubeconfig 文件的 cluster 字段需要指向远端服务，user 字段需要包含已返回的授权者。
+
+```yaml
+# clusters refers to the remote service.
+clusters:
+- name: name-of-remote-imagepolicy-service
+  cluster:
+    certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
+    server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
+
+# users refers to the API server's webhook configuration.
+users:
+- name: name-of-api-server
+  user:
+    client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
+    client-key: /path/to/key.pem          # key matching the cert
+```
+<!--
+For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
+-->
+对于更多的 HTTP 配置，请参阅 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 文档。
+
+<!--
+#### Request Payloads
+-->
+#### 请求载荷
+
+<!--
+When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`.
+-->
+当面对一个准入决策时，API server 发送一个描述操作的 JSON 序列化的 api.imagepolicy.v1alpha1.ImageReview 对象。该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 pod 注释。
+
+<!--
+Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
+-->
+注意，webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段，以确保正确的反序列化。此外，API server 必须启用 imagepolicy.k8s.io/v1alpha1 API 扩展组 (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`)。
+
+<!--
+An example request body:
+-->
+请求载荷例子：
+
+```
+{  
+  "apiVersion":"imagepolicy.k8s.io/v1alpha1",
+  "kind":"ImageReview",
+  "spec":{  
+    "containers":[  
+      {  
+        "image":"myrepo/myimage:v1"
+      },
+      {  
+        "image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
+      }
+    ],
+    "annotations":[  
+      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
+    ],
+    "namespace":"mynamespace"
+  }
+}
+```
+
+<!--
+The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return:
+-->
+远程服务将填充请求的 ImageReviewStatus 字段，并返回允许或不允许访问。响应主体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回：
+
+```
+{
+  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
+  "kind": "ImageReview",
+  "status": {
+    "allowed": true
+  }
+}
+```
+
+<!--
+To disallow access, the service would return:
+-->
+不允许访问，服务将返回：
+
+```
+{
+  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
+  "kind": "ImageReview",
+  "status": {
+    "allowed": false,
+    "reason": "image currently blacklisted"
+  }
+}
+```
+
+<!--
+For further documentation refer to the `imagepolicy.v1alpha1` API objects and `plugin/pkg/admission/imagepolicy/admission.go`.
+-->
+更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象 和 `plugin/pkg/admission/imagepolicy/admission.go`。
+
+<!--
+#### Extending with Annotations
+-->
+使用注解进行扩展
+
+<!--
+All annotations on a Pod that match `*.image-policy.k8s.io/*` are sent to the webhook. Sending annotations allows users who are aware of the image policy backend to send extra information to it, and for different backends implementations to accept different information.
+-->
+一个 pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 webhook。这允许了解镜像策略后端的用户向它发送额外的信息，并为不同的后端实现接收不同的信息。
+
+<!--
+Examples of information you might put here are:
+-->
+您可以在这里输入的信息有：
+
+<!--
+ * request to "break glass" to override a policy, in case of emergency.
+-->
+ * 在紧急情况下，请求 "break glass" 覆盖一个策略。
+<!--
+ * a ticket number from a ticket system that documents the break-glass request
+-->
+ * 从一个记录了 break-glass 的请求的票证系统得到的一个票证编号
+<!--
+ * provide a hint to the policy server as to the imageID of the image being provided, to save it a lookup
+-->
+ * 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找
+
+<!--
+In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. In the future, if an annotation is determined to be widely useful, it may be promoted to a named field of ImageReviewSpec.
+-->
+在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。在将来，如果一个注解确定将被广泛使用，它可能会被提升为  ImageReviewSpec 的一个命名字段。
+
+### ServiceAccount
+
+<!--
+This plug-in implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
+We strongly recommend using this plug-in if you intend to make use of Kubernetes `ServiceAccount` objects.
+-->
+这个插件实现了 [serviceAccounts](/docs/user-guide/service-accounts) 的自动化。
+如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个插件。
+
+### SecurityContextDeny
+
+<!--
+This plug-in will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
+-->
+该插件将拒绝任何试图设置特定扩展 [SecurityContext](/docs/user-guide/security-context) 字段的 pod。如果集群没有使用 [ pod 安全策略](/docs/user-guide/pod-security-policy)  来限制安全上下文所能获取的值集，那么应该启用这个功能。
+
+### ResourceQuota
+
+<!--
+This plug-in will observe the incoming request and ensure that it does not violate any of the constraints
+enumerated in the `ResourceQuota` object in a `Namespace`.  If you are using `ResourceQuota`
+objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
+-->
+此插件将观察传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` 对象中枚举出来的约束。如果您在 Kubernetes 部署中使用了 `ResourceQuota`
+，您必须使用这个插件来强制执行配额限制。
+
+<!--
+See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
+-->
+请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) 和 [Resource Quota 例子](/docs/concepts/policy/resource-quotas/) 了解更多细节。
+
+<!--
+It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins.  This is
+so that quota is not prematurely incremented only for the request to be rejected later in admission control.
+-->
+强烈建议将这个插件配置在准入控制插件序列的末尾。这样配额就不会过早地增加，只会在稍后的准入控制中被拒绝。
+
+### LimitRanger
+
+<!--
+This plug-in will observe the incoming request and ensure that it does not violate any of the constraints
+enumerated in the `LimitRange` object in a `Namespace`.  If you are using `LimitRange` objects in
+your Kubernetes deployment, you MUST use this plug-in to enforce those constraints. LimitRanger can also
+be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
+applies a 0.1 CPU requirement to all Pods in the `default` namespace.
+-->
+这个插件将观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` 对象枚举的任何约束。如果您在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此插件来执行这些约束。LimitRanger 插件还可以用于将默认资源请求应用到没有指定任何内容的 Pod ；当前，默认的 LimitRanger 对 `default` 命名空间中的所有 pod 应用了0.1 CPU 的需求。
+
+<!--
+See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
+-->
+请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) 和 [Limit Range 例子](/docs/tasks/configure-pod-container/limit-range/) 了解更多细节。
+
+<!--
+### InitialResources (experimental)
+-->
+### InitialResources （试验）
+
+<!--
+This plug-in observes pod creation requests. If a container omits compute resource requests and limits,
+then the plug-in auto-populates a compute resource request based on historical usage of containers running the same image.
+If there is not enough data to make a decision the Request is left unchanged.
+When the plug-in sets a compute resource request, it annotates the pod with information on what compute resources it auto-populated.
+-->
+此插件观察 pod 创建请求。如果容器忽略了 requests 和 limits 计算资源，那么插件就会根据运行相同镜像的容器的历史使用记录来自动填充计算资源请求。如果没有足够的数据进行决策，则请求将保持不变。当插件设置了一个计算资源请求时，它会用它自动填充的计算资源对 pod 进行注解。
+
+<!--
+See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/initial-resources.md) for more details.
+-->
+请查看 [InitialResouces 建议书](https://git.k8s.io/community/contributors/design-proposals/initial-resources.md) 了解更多细节。
+
+### NamespaceLifecycle
+
+<!--
+This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it,
+and ensures that requests in a non-existent `Namespace` are rejected.
+-->
+这个插件强制不能在一个正在被终止的 `Namespace` 中创建新对象，和确保使用不存在 `Namespace` 的请求被拒绝。
+
+<!--
+A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that
+namespace.  In order to enforce integrity of that process, we strongly recommend running this plug-in.
+-->
+删除 `Namespace` 触发了在该命名空间中删除所有对象（ pod 、 services 等）的一系列操作。为了确保这个过程的完整性，我们强烈建议启用这个插件。
+
+### DefaultStorageClass
+
+<!--
+This plug-in observes creation of `PersistentVolumeClaim` objects that do not request any specific storage class
+and automatically adds a default storage class to them.
+This way, users that do not request any special storage class do no need to care about them at all and they
+will get the default one.
+-->
+这个插件观察不指定 storage class 字段的 `PersistentVolumeClaim` 对象的创建，并自动向它们添加默认的 storage class 。这样，不指定 storage class 字段的用户根本无需关心它们，它们将得到默认的 storage class 。
+
+<!--
+This plug-in does not do anything when no default storage class is configured. When more than one storage
+class is marked as default, it rejects any creation of `PersistentVolumeClaim` with an error and administrator
+must revisit `StorageClass` objects and mark only one as default.
+This plugin ignores any `PersistentVolumeClaim` updates, it acts only on creation.
+-->
+当没有配置默认 storage class 时，这个插件不会执行任何操作。当一个以上的 storage class 被标记为默认时，它拒绝 `PersistentVolumeClaim` 创建并返回一个错误，管理员必须重新检查 `StorageClass` 对象，并且只标记一个作为默认值。这个插件忽略了任何 `PersistentVolumeClaim` 更新，它只对创建起作用。
+
+<!--
+See [persistent volume](/docs/user-guide/persistent-volumes) documentation about persistent volume claims and
+storage classes and how to mark a storage class as default.
+-->
+查看 [persistent volume](/docs/user-guide/persistent-volumes) 文档了解 persistent volume claims 和 storage classes 并了解如何将一个 storage classes 标志为默认。
+
+### DefaultTolerationSeconds
+
+<!--
+This plug-in sets the default forgiveness toleration for pods, which have no forgiveness tolerations, to tolerate
+the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes.
+-->
+这个插件设置了 pod 默认的宽恕容忍时间，对于那些没有设置宽恕容忍时间的 pod ，可以容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 这些 taint 5分钟。
+
+### PodNodeSelector
+
+<!--
+This plug-in defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
+-->
+通过读取命名空间注释和全局配置,这个插件默认并限制了在一个命名空间中使用什么节点选择器。
+
+<!--
+#### Configuration File Format
+-->
+#### 配置文件格式
+<!--
+PodNodeSelector uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend.
+-->
+PodNodeSelector 插件使用准入配置文件 `--admission-control-config-file` 来设置后端行为的配置选项。
+
+<!--
+Note that the configuration file format will move to a versioned file in a future release.
+-->
+请注意，配置文件格式将在未来版本中移至版本化文件。
+
+<!--
+This file may be json or yaml and has the following format:
+-->
+这个文件可能是 json 或 yaml ，格式如下：
+
+```yaml
+podNodeSelectorPluginConfig:
+ clusterDefaultNodeSelector: <node-selectors-labels>
+ namespace1: <node-selectors-labels>
+ namespace2: <node-selectors-labels>
+```
+
+<!--
+#### Configuration Annotation Format
+-->
+#### 配置注解格式
+<!--
+PodNodeSelector uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
+-->
+PodNodeSelector 插件使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解将节点选择器分配给 namespace 。
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  annotations:
+    scheduler.alpha.kubernetes.io/node-selector: <node-selectors-labels>
+  name: namespace3
+```
+
+### PodSecurityPolicy
+
+<!--
+This plug-in acts on creation and modification of the pod and determines if it should be admitted
+based on the requested security context and the available Pod Security Policies.
+-->
+此插件负责在创建和修改 pod 时根据请求的安全上下文和可用的 pod 安全策略确定是否应该通过 pod。
+
+<!--
+For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
+extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
+-->
+对于 Kubernetes < 1.6.0 的版本，API Server 必须启用 extensions/v1beta1/podsecuritypolicy API 扩展组 (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`)。
+
+<!--
+See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
+for more information.
+-->
+查看 [Pod 安全策略文档](/docs/concepts/policy/pod-security-policy/) 了解更多细节。
+
+### NodeRestriction
+
+<!--
+This plug-in limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission plugin,
+kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`. 
+Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
+-->
+这个插件限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个入场插件的限制，kubelet 必须在 `system：nodes` 组中使用凭证，并使用 `system：node：<nodeName>` 形式的用户名。这样的 kubelet 只允许修改自己的 `Node` API 对象，只能修改绑定到节点本身的 `Pod` 对象。
+<!--
+Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly.
+-->
+未来的版本可能会添加额外的限制，以确保 kubelet 具有正确操作所需的最小权限集。
+
+<!--
+## Is there a recommended set of plug-ins to use?
+-->
+## 是否有推荐的一组插件可供使用？
+
+<!--
+Yes.
+For Kubernetes >= 1.6.0, we strongly recommend running the following set of admission control plug-ins (order matters):
+-->
+有。
+对于 Kubernetes >= 1.6.0 版本，我们强烈建议运行以下一系列准入控制插件（顺序也很重要）
+
+```shell
+--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
+```
+
+<!--
+For Kubernetes >= 1.4.0, we strongly recommend running the following set of admission control plug-ins (order matters):
+-->
+对于 Kubernetes >= 1.4.0 版本，我们强烈建议运行以下一系列准入控制插件（顺序也很重要）
+
+```shell
+--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota
+```
+
+<!--
+For Kubernetes >= 1.2.0, we strongly recommend running the following set of admission control plug-ins (order matters):
+-->
+对于 Kubernetes >= 1.2.0 版本，我们强烈建议运行以下一系列准入控制插件（顺序也很重要）
+
+```shell
+--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota
+```
+
+<!--
+For Kubernetes >= 1.0.0, we strongly recommend running the following set of admission control plug-ins (order matters):
+-->
+对于 Kubernetes >= 1.0.0 版本，我们强烈建议运行以下一系列准入控制插件（顺序也很重要）
+
+```shell
+--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,PersistentVolumeLabel,ResourceQuota
+```
diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md
new file mode 100644
index 0000000000000..e8d8d8043e095
--- /dev/null
+++ b/content/zh/docs/reference/access-authn-authz/authorization.md
@@ -0,0 +1,304 @@
+---
+reviewers:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+cnapprove:
+- fatalc
+<!-- title: Authorization Overview -->
+title: 授权概述
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+<!-- Learn more about Kubernetes authorization, including details about creating
+policies using the supported authorization modules. -->
+了解有关 Kubernetes 授权的更多信息，包括使用支持的授权模块创建策略的详细信息。
+{{% /capture %}}
+
+{{% capture body %}}
+<!-- In Kubernetes, you must be authenticated (logged in) before your request can be
+authorized (granted permission to access). For information about authentication,
+see [Accessing Control Overview](/docs/reference/access-authn-authz/controlling-access/).
+
+Kubernetes expects attributes that are common to REST API requests. This means
+that Kubernetes authorization works with existing organization-wide or
+cloud-provider-wide access control systems which may handle other APIs besides
+the Kubernetes API. -->
+
+在Kubernetes中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
+请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/).
+
+Kubernetes期望REST API请求中常见的属性。
+这意味着Kubernetes授权适用于现有的组织范围或云提供商范围的访问控制系统，
+除了Kubernetes API之外，它还可以处理其他API。
+
+<!-- ## Determine Whether a Request is Allowed or Denied
+Kubernetes authorizes API requests using the API server. It evaluates all of the
+request attributes against all policies and allows or denies the request. All
+parts of an API request must be allowed by some policy in order to proceed. This
+means that permissions are denied by default.
+
+(Although Kubernetes uses the API server, access controls and policies that
+depend on specific fields of specific kinds of objects are handled by Admission
+Controllers.)
+
+When multiple authorization modules are configured, each is checked in sequence.
+If any authorizer approves or denies a request, that decision is immediately
+returned and no other authorizer is consulted. If all modules have no opinion on
+the request, then the request is denied. A deny returns an HTTP status code 403. -->
+
+## 确定是允许还是拒绝请求
+Kubernetes 使用 API ​​服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。
+一个API请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。
+
+（尽管 Kubernetes 使用 API ​​服务器，但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。）
+
+配置多个授权模块时，将按顺序检查每个模块。
+如果任何授权模块批准或拒绝请求，则立即返回该决定，并且不会与其他授权模块协商。
+如果所有模块对请求没有意见，则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。
+
+<!--
+## Review Your Request Attributes
+Kubernetes reviews only the following API request attributes:
+
+ * **user** - The `user` string provided during authentication.
+ * **group** - The list of group names to which the authenticated user belongs.
+ * **extra** - A map of arbitrary string keys to string values, provided by the authentication layer.
+ * **API** - Indicates whether the request is for an API resource.
+ * **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
+ * **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [Determine the request verb](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied) below.
+ * **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests.
+ * **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
+ * **Subresource** - The subresource that is being accessed (for resource requests only).
+ * **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
+ * **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
+-->
+
+## 审查您的请求属性
+Kubernetes仅审查以下API请求属性：
+
+ * **user** - 身份验证期间提供的`user`字符串。
+ * **group** - 经过身份验证的用户所属的组名列表。
+ * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。
+ * **API** - 指示请求是否针对 API 资源。
+ * **Request path** - 各种非资源端点的路径，如`/api`或`/healthz`。
+ * **API request verb** - API 动词`get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete`和`deletecollection`用于资源请求。要确定资源API端点的请求动词，请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
+ * **HTTP request verb** - HTTP 动词`get`，`post`，`put`和`delete`用于非资源请求。
+ * **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用`get`，`update`，`patch`和`delete`动词的资源请求，您必须提供资源名称。
+ * **Subresource** - 正在访问的子资源（仅限资源请求）。
+ * **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
+ * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心API组](/docs/concepts/overview/kubernetes-api/)。
+
+<!--
+## Determine the Request Verb
+To determine the request verb for a resource API endpoint, review the HTTP verb
+used and whether or not the request acts on an individual resource or a
+collection of resources:
+
+HTTP verb | request verb
+----------|---------------
+POST      | create
+GET, HEAD | get (for individual resources), list (for collections)
+PUT       | update
+PATCH     | patch
+DELETE    | delete (for individual resources), deletecollection (for collections)
+
+Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
+
+* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
+* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization 
+of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
+* [Authentication](/docs/reference/access-authn-authz/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
+-->
+
+## 确定请求动词
+
+要确定资源API端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用：
+
+HTTP 动词 | request 动词
+----------|---------------
+POST      | create
+GET, HEAD | get (单个资源), list (资源集合)
+PUT       | update
+PATCH     | patch
+DELETE    | delete (单个资源), deletecollection (资源集合)
+
+Kubernetes有时使用专门的动词检查授权以获得额外的权限。例如：
+
+* [Pod安全策略](/docs/concepts/policy/pod-security-policy/) 检查`policy` API组中`podsecuritypolicies`资源的`use`动词的授权。
+* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查`rbac.authorization.k8s.io` API 组中`roles`和`clusterroles`资源的`bind`动词的授权。
+* [认证](/docs/reference/access-authn-authz/authentication/) layer检查核心API组中`users`，`groups`和`serviceaccounts`的`impersonate`动词的授权，以及`authentication.k8s.io` API组中的`userextras`。
+
+<!--
+## Authorization Modules
+ * **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
+ * **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/reference/access-authn-authz/abac/).
+ * **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/reference/access-authn-authz/rbac/)
+   * When specified RBAC (Role-Based Access Control) uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
+   * To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
+ * **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/).
+ -->
+ 
+## 授权模块
+ * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/).
+ * **ABAC** - 基于属性的访问控制（ABAC) 定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅[ABAC 模式](/docs/reference/access-authn-authz/abac/)。
+ * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅[RBAC 模式](/docs/reference/access-authn-authz/rbac/)。
+   * 当指定的RBAC（基于角色的访问控制）使用`rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
+   * 要启用RBAC，请使用`--authorization-mode = RBAC`启动 apiserver 。
+ * **Webhook** - WebHook 是一个 HTTP 回调: 发生某些事情时调用的 HTTP POST;通过 HTTP POST 进行简单的事件通知。实现 WebHooks 的 Web 应用程序会在发生某些事情时将消息发布到URL。要了解有关使用 Webhook 模式的更多信息，请参阅[Webhook 模式](/docs/reference/access-authn-authz/webhook/)。
+
+<!--
+#### Checking API Access
+
+`kubectl` provides the `auth can-i` subcommand for quickly querying the API authorization layer.
+The command uses the `SelfSubjectAccessReview` API to determine if the current user can perform
+a given action, and works regardless of the authorization mode used.
+-->
+
+#### 检查API访问
+
+`kubectl`提供`auth can-i`子命令，用于快速查询 API 授权层。
+该命令使用`SelfSubjectAccessReview` API来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。
+
+```bash
+$ kubectl auth can-i create deployments --namespace dev
+yes
+$ kubectl auth can-i create deployments --namespace prod
+no
+```
+<!-- 
+Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
+to determine what action other users can perform.
+-->
+管理员可以将此与[用户模拟](/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
+
+```bash
+$ kubectl auth can-i list secrets --namespace dev --as dave
+no
+```
+<!--
+`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
+exposes the API server authorization to external services. Other resources in
+this group include:
+
+* `SubjectAccessReview` - Access review for any user, not just the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
+* `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace.
+* `SelfSubjectRulesReview` - A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.
+
+These APIs can be queried by creating normal Kubernetes resources, where the response "status"
+field of the returned object is the result of the query.
+-->
+
+`SelfSubjectAccessReview`是`authorization.k8s.io` API组的一部分，它将 API 服务器授权公开给外部服务。
+该组中的其他资源包括：
+
+* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给API服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的API的访问权限。
+* `LocalSubjectAccessReview` - 与`SubjectAccessReview`类似，但仅限于特定的命名空间。
+* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于隐藏/显示操作的UI。
+
+可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应“status”字段是查询的结果。
+
+```bash
+$ kubectl create -f - -o yaml << EOF
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+spec:
+  resourceAttributes:
+    group: apps
+    name: deployments
+    verb: create
+    namespace: dev
+EOF
+
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+metadata:
+  creationTimestamp: null
+spec:
+  resourceAttributes:
+    group: apps
+    name: deployments
+    namespace: dev
+    verb: create
+status:
+  allowed: true
+  denied: false
+```
+
+<!--
+## Using Flags for Your Authorization Module
+
+You must include a flag in your policy to indicate which authorization module
+your policies include:
+
+The following flags can be used:
+
+  * `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
+  * `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
+  * `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST endpoint.
+  * `--authorization-mode=Node` Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
+  * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
+  * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
+
+You can choose more than one authorization module. Modules are checked in order
+so an earlier module has higher priority to allow or deny a request.
+-->
+
+## 为您的授权模块使用标志
+
+您必须在策略中包含一个标志，以指明您的策略包含哪个授权模块：
+
+可以使用以下标志：
+
+  * `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。
+  * `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。
+  * `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程REST端点管理授权。
+  * `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的API请求。
+  * `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。
+  * `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。
+
+您可以选择多个授权模块。按顺序检查模块，以便较早的模块具有更高的优先级来允许或拒绝请求。
+
+<!--
+## Privilege escalation via pod creation
+
+Users who have the ability to create pods in a namespace can potentially
+escalate their privileges within that namespace.  They can create pods that
+access their privileges within that namespace. They can create pods that access
+secrets the user cannot themselves read, or that run under a service account
+with different/greater permissions.
+-->
+## 通过pod创建权限升级
+
+能够在命名空间中创建 pod 的用户可能会升级其在该命名空间内的权限。
+他们可以创建在该命名空间内访问其权限的 pod 。
+他们可以创建用户无法自己读取 secret 的 pod ，或者在具有不同/更高权限的服务帐户下运行的 pod 。
+
+{{< caution >}}
+<!--
+**Caution:** System administrators, use care when granting access to pod
+creation.  A user granted permission to create pods (or controllers that create
+pods) in the namespace can: read all secrets in the namespace; read all config
+maps in the namespace; and impersonate any service account in the namespace and
+take any action the account could take. This applies regardless of authorization
+mode.
+-->
+**注意：** 系统管理员在授予对 pod 创建的访问权限时要小心。
+授予在命名空间中创建 pod（或创建pod的控制器）的权限的用户可以：
+读取命名空间中的所有秘密;读取命名空间中的所有配置映射;
+并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。
+无论采用何种授权方式，这都适用。
+{{< /caution >}}
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!--
+* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
+* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
+-->
+* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对Kubernetes API的访问](/docs/reference/access-authn-authz/controlling-access/).
+* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/).
+{{% /capture %}}
\ No newline at end of file
diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md
new file mode 100644
index 0000000000000..80acad7403fb8
--- /dev/null
+++ b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md
@@ -0,0 +1,491 @@
+---
+title: kube-proxy
+notitle: true
+---
+## kube-proxy
+
+
+<!--
+### Synopsis
+
+
+The Kubernetes network proxy runs on each node. This
+reflects services as defined in the Kubernetes API on each node and can do simple
+TCP and UDP stream forwarding or round robin TCP and UDP forwarding across a set of backends.
+Service cluster IPs and ports are currently found through Docker-links-compatible
+environment variables specifying ports opened by the service proxy. There is an optional
+addon that provides cluster DNS for these cluster IPs. The user must create a service
+with the apiserver API to configure the proxy.
+-->
+### 概要
+
+Kubernetes 在每个节点上运行网络代理。这反映每个节点上 Kubernetes API 中定义的服务，并且可以做简单的
+TCP 和 UDP 流转发或在一组后端中轮询，进行 TCP 和 UDP 转发。目前服务集群 IP 和端口通过由服务代理打开的端口
+的 Docker-links-compatible 环境变量找到。有一个可选的为这些集群 IP 提供集群 DNS 的插件。用户必须
+通过 apiserver API 创建服务去配置代理。
+
+```
+kube-proxy [flags]
+```
+
+<!--
+### Options
+-->
+### 选项
+
+<table style="width: 100%; table-layout: fixed;">
+  <colgroup>
+    <col span="1" style="width: 10px;" />
+    <col span="1" />
+  </colgroup>
+  <tbody>
+
+    <tr>
+      <td colspan="2">--azure-container-registry-config string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">包含 Azure 容器仓库配置信息的文件的路径。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
+    -->
+      <td colspan="2">--bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 0.0.0.0</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the proxy server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">要服务的代理服务器的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--cleanup</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true cleanup iptables and ipvs rules and exit.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果为 true，清理 iptables 和 ipvs 规则并退出。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--cleanup-ipvs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+    -->
+      <td colspan="2">--cleanup-ipvs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: true</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true make kube-proxy cleanup ipvs rules before running.  Default is true</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果为 true，则使 kube-proxy 在运行之前清理 ipvs 规则。 默认为 true</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--cluster-cidr string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">集群中的 CIDR 范围。 配置后，从该范围之外发送到服务集群 IP 的流量将被伪装，从 pod 发送到外部 LoadBalancer IP 的流量将被定向到相应的集群 IP</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--config string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the configuration file.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">配置文件的路径。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--config-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 15m0s</td>
+    -->
+      <td colspan="2">--config-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 15m0s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">How often configuration from the apiserver is refreshed.  Must be greater than 0.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">来自 apiserver 的配置的刷新频率。必须大于 0。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--conntrack-max-per-core int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 32768</td>
+    -->
+      <td colspan="2">--conntrack-max-per-core int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 32768</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of NAT connections to track per CPU core (0 to leave the limit as-is and ignore conntrack-min).</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">每个 CPU 核跟踪的最大 NAT 连接数（0 表示保留原样限制并忽略 conntrack-min）。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--conntrack-min int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 131072</td>
+    -->
+      <td colspan="2">--conntrack-min int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 131072</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum number of conntrack entries to allocate, regardless of conntrack-max-per-core (set conntrack-max-per-core=0 to leave the limit as-is).</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">要分配的最小 conntrack 条目数，不管 conntrack-max-per-core（设置 conntrack-max-per-core = 0 保留原样限制）。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--conntrack-tcp-timeout-close-wait duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1h0m0s</td>
+    -->
+      <td colspan="2">--conntrack-tcp-timeout-close-wait duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 1h0m0s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">NAT timeout for TCP connections in the CLOSE_WAIT state</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">处于 CLOSE_WAIT 状态的 TCP 连接的 NAT 超时</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--conntrack-tcp-timeout-established duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 24h0m0s</td>
+    -->
+      <td colspan="2">--conntrack-tcp-timeout-established duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 24h0m0s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Idle timeout for established TCP connections (0 to leave as-is)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">已建立的 TCP 连接的空闲超时（0 保持原样）</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--feature-gates mapStringBool</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (ALPHA - default=false)<br/>AdvancedAuditing=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (ALPHA - default=false)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (ALPHA - default=false)<br/>CSIPersistentVolume=true|false (BETA - default=true)<br/>CustomPodDNS=true|false (BETA - default=true)<br/>CustomResourceSubresources=true|false (BETA - default=true)<br/>CustomResourceValidation=true|false (BETA - default=true)<br/>DebugContainers=true|false (ALPHA - default=false)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>DynamicProvisioningScheduling=true|false (ALPHA - default=false)<br/>EnableEquivalenceClassCache=true|false (ALPHA - default=false)<br/>ExpandInUsePersistentVolumes=true|false (ALPHA - default=false)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>GCERegionalPersistentDisk=true|false (BETA - default=true)<br/>HugePages=true|false (BETA - default=true)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>Initializers=true|false (ALPHA - default=false)<br/>KubeletPluginsWatcher=true|false (ALPHA - default=false)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>MountContainers=true|false (ALPHA - default=false)<br/>MountPropagation=true|false (BETA - default=true)<br/>PersistentLocalVolumes=true|false (BETA - default=true)<br/>PodPriority=true|false (BETA - default=true)<br/>PodReadinessGates=true|false (BETA - default=false)<br/>PodShareProcessNamespace=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>ReadOnlyAPIDataVolumes=true|false (DEPRECATED - default=true)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (ALPHA - default=false)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (ALPHA - default=false)<br/>RunAsGroup=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceProxyAllowExternalIPs=true|false (DEPRECATED - default=false)<br/>StorageObjectInUseProtection=true|false (default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportIPVSProxyMode=true|false (default=true)<br/>SupportPodPidsLimit=true|false (ALPHA - default=false)<br/>Sysctls=true|false (BETA - default=true)<br/>TaintBasedEvictions=true|false (ALPHA - default=false)<br/>TaintNodesByCondition=true|false (ALPHA - default=false)<br/>TokenRequest=true|false (ALPHA - default=false)<br/>TokenRequestProjection=true|false (ALPHA - default=false)<br/>VolumeScheduling=true|false (BETA - default=true)<br/>VolumeSubpath=true|false (default=true)<br/>VolumeSubpathEnvExpansion=true|false (ALPHA - default=false)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">一组 key=value 对，用于描述 alpha/experimental 特征的特征门。选项包括：<br/>APIListChunking=true|false (BETA - 默认=true)<br/>APIResponseCompression=true|false (ALPHA - 默认=false)<br/>AdvancedAuditing=true|false (BETA - 默认=true)<br/>AllAlpha=true|false (ALPHA - 默认=false)<br/>AppArmor=true|false (BETA - 默认=true)<br/>AttachVolumeLimit=true|false (ALPHA - 默认=false)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - 默认=false)<br/>BlockVolume=true|false (ALPHA - 默认=false)<br/>CPUManager=true|false (BETA - 默认=true)<br/>CRIContainerLogRotation=true|false (BETA - 默认=true)<br/>CSIBlockVolume=true|false (ALPHA - 默认=false)<br/>CSIPersistentVolume=true|false (BETA - 默认=true)<br/>CustomPodDNS=true|false (BETA - 默认=true)<br/>CustomResourceSubresources=true|false (BETA - 默认=true)<br/>CustomResourceValidation=true|false (BETA - 默认=true)<br/>DebugContainers=true|false (ALPHA - 默认=false)<br/>DevicePlugins=true|false (BETA - 默认=true)<br/>DynamicKubeletConfig=true|false (BETA - 默认=true)<br/>DynamicProvisioningScheduling=true|false (ALPHA - 默认=false)<br/>EnableEquivalenceClassCache=true|false (ALPHA - 默认=false)<br/>ExpandInUsePersistentVolumes=true|false (ALPHA - 默认=false)<br/>ExpandPersistentVolumes=true|false (BETA - 默认=true)<br/>ExperimentalCriticalPodAnnotation=true|false (ALPHA - 默认=false)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认=false)<br/>GCERegionalPersistentDisk=true|false (BETA - 默认=true)<br/>HugePages=true|false (BETA - 默认=true)<br/>HyperVContainer=true|false (ALPHA - 默认=false)<br/>Initializers=true|false (ALPHA - 默认=false)<br/>KubeletPluginsWatcher=true|false (ALPHA - 默认=false)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>MountContainers=true|false (ALPHA - 默认=false)<br/>MountPropagation=true|false (BETA - 默认=true)<br/>PersistentLocalVolumes=true|false (BETA - 默认=true)<br/>PodPriority=true|false (BETA - 默认=true)<br/>PodReadinessGates=true|false (BETA - 默认=false)<br/>PodShareProcessNamespace=true|false (ALPHA - 默认=false)<br/>QOSReserved=true|false (ALPHA - 默认=false)<br/>ReadOnlyAPIDataVolumes=true|false (弃用 - 默认=true)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - 默认=false)<br/>ResourceQuotaScopeSelectors=true|false (ALPHA - 默认=false)<br/>RotateKubeletClientCertificate=true|false (BETA - 默认=true)<br/>RotateKubeletServerCertificate=true|false (ALPHA - 默认=false)<br/>RunAsGroup=true|false (ALPHA - 默认=false)<br/>ScheduleDaemonSetPods=true|false (ALPHA - 默认=false)<br/>ServiceNodeExclusion=true|false (ALPHA - 默认=false)<br/>ServiceProxyAllowExternalIPs=true|false (弃用 - 默认=false)<br/>StorageObjectInUseProtection=true|false (default=true)<br/>StreamingProxyRedirects=true|false (BETA - 默认=true)<br/>SupportIPVSProxyMode=true|false (默认=true)<br/>SupportPodPidsLimit=true|false (ALPHA - 默认=false)<br/>Sysctls=true|false (BETA - 默认=true)<br/>TaintBasedEvictions=true|false (ALPHA - 默认=false)<br/>TaintNodesByCondition=true|false (ALPHA - 默认=false)<br/>TokenRequest=true|false (ALPHA - 默认=false)<br/>TokenRequestProjection=true|false (ALPHA - 默认=false)<br/>VolumeScheduling=true|false (BETA - 默认=true)<br/>VolumeSubpath=true|false (默认=true)<br/>VolumeSubpathEnvExpansion=true|false (ALPHA - 默认=false)</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--healthz-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0:10256</td>
+    -->
+      <td colspan="2">--healthz-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 0.0.0.0:10256</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address and port for the health check server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">服务健康检查的 IP 地址和端口（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--healthz-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10256</td>
+    -->
+      <td colspan="2">--healthz-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 10256</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port to bind the health check server. Use 0 to disable.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">绑定健康检查服务的端口。使用 0 禁用。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">-h, --help</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kube-proxy</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kube-proxy 帮助信息</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--hostname-override string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, will use this string as identification instead of the actual hostname.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果非空，将使用此字符串作为标识而不是实际的主机名。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--iptables-masquerade-bit int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 14</td>
+    -->
+      <td colspan="2">--iptables-masquerade-bit int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 14</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If using the pure iptables proxy, the bit of the fwmark space to mark packets requiring SNAT with.  Must be within the range [0, 31].</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果使用纯 iptables 代理，则 fwmark 空间的位用于标记需要 SNAT 的数据包。 必须在 [0,31] 范围内。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--iptables-min-sync-period duration</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum interval of how often the iptables rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m').</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">当端点和服务发生变化时，iptables 规则的刷新的最小间隔（例如 '5s'，'1m'，'2h22m'）。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--iptables-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 30s</td>
+    -->
+      <td colspan="2">--iptables-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 30s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">iptables 规则刷新的最大时间间隔（例如 '5s'，'1m'，'2h22m'）。必须大于 0。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--ipvs-exclude-cidrs stringSlice</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A comma-separated list of CIDR's which the ipvs proxier should not touch when cleaning up IPVS rules.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">以逗号分隔的 CIDR 列表，在清理 IPVS 规则时，不应该触及 ipvs proxier。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--ipvs-min-sync-period duration</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The minimum interval of how often the ipvs rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m').</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">当端点和服务发生变化时，ipvs 规则的刷新的最小间隔（例如 '5s'，'1m'，'2h22m'）。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--ipvs-scheduler string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The ipvs scheduler type when proxy mode is ipvs</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">代理模式为 ipvs 时的 ipvs 调度器类型</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--ipvs-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 30s</td>
+    -->
+      <td colspan="2">--ipvs-sync-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 30s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The maximum interval of how often ipvs rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">ipvs 规则刷新的最大时间间隔（例如 '5s'，'1m'，'2h22m'）。必须大于 0。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10</td>
+    -->
+      <td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 10</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Burst to use while talking with kubernetes apiserver</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">每秒与 kubernetes apiserver 交互的数量</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-content-type string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "application/vnd.kubernetes.protobuf"</td>
+    -->
+      <td colspan="2">--kube-api-content-type string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "application/vnd.kubernetes.protobuf"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Content type of requests sent to apiserver.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">发送到 apiserver 的请求的内容类型。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-qps float32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5</td>
+    -->
+      <td colspan="2">--kube-api-qps float32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 5</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">QPS to use while talking with kubernetes apiserver</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">与 kubernetes apiserver 交互时使用的 QPS</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--kubeconfig string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to kubeconfig file with authorization information (the master location is set by the master flag).</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">包含授权信息的 kubeconfig 文件的路径（master 位置由 master 标志设置）。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5s</td>
+    -->
+      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 5s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">日志刷新最大间隔</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--masquerade-all</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If using the pure iptables proxy, SNAT all traffic sent via Service cluster IPs (this not commonly needed)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果使用纯 iptables 代理，SNAT 所有通过服务句群 IP 发送的流量（这通常不需要）</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--master string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The address of the Kubernetes API server (overrides any value in kubeconfig)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值）</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--metrics-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 127.0.0.1:10249</td>
+    -->
+      <td colspan="2">--metrics-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 127.0.0.1:10249</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address and port for the metrics server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">要服务的度量服务器的 IP 地址和端口（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--nodeport-addresses stringSlice</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A string slice of values which specify the addresses to use for NodePorts. Values may be valid IP blocks (e.g. 1.2.3.0/24, 1.2.3.4/32). The default empty string slice ([]) means to use all local addresses.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">一个字符串值，指定用于 NodePorts 的地址。 值可以是有效的 IP 块（例如 1.2.3.0/24, 1.2.3.4/32）。 默认的空字符串切片（[]）表示使用所有本地地址。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--oom-score-adj int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: -999</td>
+    -->
+      <td colspan="2">--oom-score-adj int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: -999</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The oom-score-adj value for kube-proxy process. Values must be within the range [-1000, 1000]</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kube-proxy 进程的 oom-score-adj 值。 值必须在 [-1000,1000] 范围内</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--profiling</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true enables profiling via web interface on /debug/pprof handler.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果为 true，则通过 Web 接口 /debug/pprof 启用性能分析。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--proxy-mode ProxyMode</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Which proxy mode to use: 'userspace' (older) or 'iptables' (faster) or 'ipvs' (experimental). If blank, use the best-available proxy (currently iptables).  If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are insufficient, this always falls back to the userspace proxy.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">使用哪种代理模式：'userspace'（较旧）或 'iptables'（较快）或 'ipvs'（实验）。 如果为空，使用最佳可用代理（当前为 iptables）。 如果选择了 iptables 代理，无论如何，但系统的内核或 iptables 版本不足，这总是会回退到用户空间代理。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--proxy-port-range port-range</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusive) that may be consumed in order to proxy service traffic. If (unspecified, 0, or 0-0) then ports will be randomly chosen.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">主机端口的范围（beginPort-endPort，单端口或 beginPort + offset，包括），可以被代理服务流量消耗。 如果（未指定，0 或 0-0）则随机选择端口。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--udp-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 250ms</td>
+    -->
+      <td colspan="2">--udp-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 250ms</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">How long an idle UDP connection will be kept open (e.g. '250ms', '2s').  Must be greater than 0. Only applicable for proxy-mode=userspace</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">空闲 UDP 连接将保持打开的时长（例如 '250ms'，'2s'）。 必须大于 0。仅适用于 proxy-mode=userspace</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--version version[=true]</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Print version information and quit</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">打印版本信息并退出</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--write-config-to string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If set, write the default configuration values to this file and exit.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果设置，将配置值写入此文件并退出。</td>
+    </tr>
+
+  </tbody>
+</table>
diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md
new file mode 100644
index 0000000000000..4180967d696cc
--- /dev/null
+++ b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md
@@ -0,0 +1,380 @@
+---
+title: kube-scheduler
+notitle: true
+---
+## kube-scheduler
+
+
+
+<!--
+### Synopsis
+
+
+The Kubernetes scheduler is a policy-rich, topology-aware,
+workload-specific function that significantly impacts availability, performance,
+and capacity. The scheduler needs to take into account individual and collective
+resource requirements, quality of service requirements, hardware/software/policy
+constraints, affinity and anti-affinity specifications, data locality, inter-workload
+interference, deadlines, and so on. Workload-specific requirements will be exposed
+through the API as necessary.
+-->
+### 概要
+
+
+Kubernetes 调度器是一个策略丰富、拓扑感知、工作负载特定的功能，显著影响可用性、性能和容量。调度器需要考虑个人和集体
+的资源要求、服务质量要求、硬件/软件/政策约束、亲和力和反亲和力规范、数据局部性、负载间干扰、完成期限等。
+工作负载特定的要求必要时将通过 API 暴露。
+
+```
+kube-scheduler [flags]
+```
+
+<!--
+### Options
+-->
+### 选项
+
+<table style="width: 100%; table-layout: fixed;">
+  <colgroup>
+    <col span="1" style="width: 10px;" />
+    <col span="1" />
+  </colgroup>
+  <tbody>
+
+    <tr>
+    <!--
+      <td colspan="2">--address string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "0.0.0.0"</td>
+    -->
+      <td colspan="2">--address string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "0.0.0.0"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--algorithm-provider string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the scheduling algorithm provider to use, one of: ClusterAutoscalerProvider | DefaultProvider</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider |DefaultProvider</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--azure-container-registry-config string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">包含 Azure 容器仓库配置信息的文件的路径。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--config string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the configuration file. Flags override values in this file.</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">配置文件的路径。标志会覆盖此文件中的值。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--contention-profiling</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: enable lock contention profiling, if profiling is enabled</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 如果启用了性能分析，则启用锁竞争分析</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--feature-gates mapStringBool</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (ALPHA - default=false)<br/>AdvancedAuditing=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (ALPHA - default=false)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (ALPHA - default=false)<br/>CSIPersistentVolume=true|false (BETA - default=true)<br/>CustomPodDNS=true|false (BETA - default=true)<br/>CustomResourceSubresources=true|false (BETA - default=true)<br/>CustomResourceValidation=true|false (BETA - default=true)<br/>DebugContainers=true|false (ALPHA - default=false)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>DynamicProvisioningScheduling=true|false (ALPHA - default=false)<br/>EnableEquivalenceClassCache=true|false (ALPHA - default=false)<br/>ExpandInUsePersistentVolumes=true|false (ALPHA - default=false)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>GCERegionalPersistentDisk=true|false (BETA - default=true)<br/>HugePages=true|false (BETA - default=true)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>Initializers=true|false (ALPHA - default=false)<br/>KubeletPluginsWatcher=true|false (ALPHA - default=false)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>MountContainers=true|false (ALPHA - default=false)<br/>MountPropagation=true|false (BETA - default=true)<br/>PersistentLocalVolumes=true|false (BETA - default=true)<br/>PodPriority=true|false (BETA - default=true)<br/>PodReadinessGates=true|false (BETA - default=false)<br/>PodShareProcessNamespace=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>ReadOnlyAPIDataVolumes=true|false (DEPRECATED - default=true)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (ALPHA - default=false)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (ALPHA - default=false)<br/>RunAsGroup=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceProxyAllowExternalIPs=true|false (DEPRECATED - default=false)<br/>StorageObjectInUseProtection=true|false (default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportIPVSProxyMode=true|false (default=true)<br/>SupportPodPidsLimit=true|false (ALPHA - default=false)<br/>Sysctls=true|false (BETA - default=true)<br/>TaintBasedEvictions=true|false (ALPHA - default=false)<br/>TaintNodesByCondition=true|false (ALPHA - default=false)<br/>TokenRequest=true|false (ALPHA - default=false)<br/>TokenRequestProjection=true|false (ALPHA - default=false)<br/>VolumeScheduling=true|false (BETA - default=true)<br/>VolumeSubpath=true|false (default=true)<br/>VolumeSubpathEnvExpansion=true|false (ALPHA - default=false)</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">一组 key=value 对，用于描述 alpha/experimental 特征的特征门。选项包括：<br/>APIListChunking=true|false (BETA - 默认=true)<br/>APIResponseCompression=true|false (ALPHA - 默认=false)<br/>AdvancedAuditing=true|false (BETA - 默认=true)<br/>AllAlpha=true|false (ALPHA - 默认=false)<br/>AppArmor=true|false (BETA - 默认=true)<br/>AttachVolumeLimit=true|false (ALPHA - 默认=false)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - 默认=false)<br/>BlockVolume=true|false (ALPHA - 默认=false)<br/>CPUManager=true|false (BETA - 默认=true)<br/>CRIContainerLogRotation=true|false (BETA - 默认=true)<br/>CSIBlockVolume=true|false (ALPHA - 默认=false)<br/>CSIPersistentVolume=true|false (BETA - 默认=true)<br/>CustomPodDNS=true|false (BETA - 默认=true)<br/>CustomResourceSubresources=true|false (BETA - 默认=true)<br/>CustomResourceValidation=true|false (BETA - 默认=true)<br/>DebugContainers=true|false (ALPHA - 默认=false)<br/>DevicePlugins=true|false (BETA - 默认=true)<br/>DynamicKubeletConfig=true|false (BETA - 默认=true)<br/>DynamicProvisioningScheduling=true|false (ALPHA - 默认=false)<br/>EnableEquivalenceClassCache=true|false (ALPHA - 默认=false)<br/>ExpandInUsePersistentVolumes=true|false (ALPHA - 默认=false)<br/>ExpandPersistentVolumes=true|false (BETA - 默认=true)<br/>ExperimentalCriticalPodAnnotation=true|false (ALPHA - 默认=false)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认=false)<br/>GCERegionalPersistentDisk=true|false (BETA - 默认=true)<br/>HugePages=true|false (BETA - 默认=true)<br/>HyperVContainer=true|false (ALPHA - 默认=false)<br/>Initializers=true|false (ALPHA - 默认=false)<br/>KubeletPluginsWatcher=true|false (ALPHA - 默认=false)<br/>LocalStorageCapacityIsolation=true|false (BETA - 默认=true)<br/>MountContainers=true|false (ALPHA - 默认=false)<br/>MountPropagation=true|false (BETA - 默认=true)<br/>PersistentLocalVolumes=true|false (BETA - 默认=true)<br/>PodPriority=true|false (BETA - 默认=true)<br/>PodReadinessGates=true|false (BETA - 默认=false)<br/>PodShareProcessNamespace=true|false (ALPHA - 默认=false)<br/>QOSReserved=true|false (ALPHA - 默认=false)<br/>ReadOnlyAPIDataVolumes=true|false (弃用 - 默认=true)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - 默认=false)<br/>ResourceQuotaScopeSelectors=true|false (ALPHA - 默认=false)<br/>RotateKubeletClientCertificate=true|false (BETA - 默认=true)<br/>RotateKubeletServerCertificate=true|false (ALPHA - 默认=false)<br/>RunAsGroup=true|false (ALPHA - 默认=false)<br/>ScheduleDaemonSetPods=true|false (ALPHA - 默认=false)<br/>ServiceNodeExclusion=true|false (ALPHA - 默认=false)<br/>ServiceProxyAllowExternalIPs=true|false (弃用 - 默认=false)<br/>StorageObjectInUseProtection=true|false (默认=true)<br/>StreamingProxyRedirects=true|false (BETA - 默认=true)<br/>SupportIPVSProxyMode=true|false (默认=true)<br/>SupportPodPidsLimit=true|false (ALPHA - 默认=false)<br/>Sysctls=true|false (BETA - 默认=true)<br/>TaintBasedEvictions=true|false (ALPHA - 默认=false)<br/>TaintNodesByCondition=true|false (ALPHA - 默认=false)<br/>TokenRequest=true|false (ALPHA - 默认=false)<br/>TokenRequestProjection=true|false (ALPHA - 默认=false)<br/>VolumeScheduling=true|false (BETA - 默认=true)<br/>VolumeSubpath=true|false (默认=true)<br/>VolumeSubpathEnvExpansion=true|false (ALPHA - 默认=false)</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">-h, --help</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kube-scheduler</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kube-scheduler 帮助信息</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 100</td>
+    -->
+      <td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 100</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: burst to use while talking with kubernetes apiserver</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 每秒与 kubernetes apiserver 交互的数量</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-content-type string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "application/vnd.kubernetes.protobuf"</td>
+    -->
+      <td colspan="2">--kube-api-content-type string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "application/vnd.kubernetes.protobuf"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: content type of requests sent to apiserver.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 发送到 apiserver 的请求的内容类型</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--kube-api-qps float32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 50</td>
+    -->
+      <td colspan="2">--kube-api-qps float32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 50</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: QPS to use while talking with kubernetes apiserver</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 与 kubernetes apiserver 交互时使用的 QPS</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--kubeconfig string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: path to kubeconfig file with authorization and master location information.</td>
+    -->
+    <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 包含授权和 master 位置信息的 kubeconfig 文件的路径。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--leader-elect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+    -->
+      <td colspan="2">--leader-elect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: true</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">在执行主循环之前，启动 leader 选举客户端并获得领导能力。在运行复制组件以实现高可用性时启用此选项。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--leader-elect-lease-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 15s</td>
+    -->
+      <td colspan="2">--leader-elect-lease-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 15s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">非 leader 候选人在观察领导层续约之后将等待的时间，直到试图获得领导但尚未更新的 leader 位置。这实际上是 leader 在被另一个候选人替换之前可以停止的最长持续时间。这仅适用于启用 leader 选举的情况。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--leader-elect-renew-deadline duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10s</td>
+    -->
+      <td colspan="2">--leader-elect-renew-deadline duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 10s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">代理 master 在停止领导之前更新领导位置的时间间隔。这必须小于或等于租约期限。这仅适用于启用 leader 选举的情况</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--leader-elect-resource-lock endpoints&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "endpoints"</td>
+    -->
+      <td colspan="2">--leader-elect-resource-lock endpoints&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "endpoints"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and `configmaps`.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">在 leader 选举期间用于锁定的资源对象的类型。支持的选项是 endpoints (默认) 和 `configmaps`。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--leader-elect-retry-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 2s</td>
+    -->
+      <td colspan="2">--leader-elect-retry-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 2s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">客户端在尝试获取和更新领导之间应该等待的持续时间。这仅适用于启用leader选举的情况。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--lock-object-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "kube-scheduler"</td>
+    -->
+      <td colspan="2">--lock-object-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "kube-scheduler"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: define the name of the lock object.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 定义锁对象的名称。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--lock-object-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "kube-system"</td>
+    -->
+      <td colspan="2">--lock-object-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "kube-system"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: define the namespace of the lock object.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 定义锁对象的命名空间。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5s</td>
+    -->
+      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 5s</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">日志刷新最大间隔</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--master string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The address of the Kubernetes API server (overrides any value in kubeconfig)</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值）</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--policy-config-file string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: file with scheduler policy configuration. This file is used if policy ConfigMap is not provided or --use-legacy-policy-config=true</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 包含调度器策略配置的文件。如果未提供策略 ConfigMap 或 --use-legacy-policy-config==true，则使用此文件</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--policy-configmap string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: name of the ConfigMap object that contains scheduler's policy configuration. It must exist in the system namespace before scheduler initialization if --use-legacy-policy-config=false. The config must be provided as the value of an element in 'Data' map with the key='policy.cfg'</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 包含调度器策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config==false，它必须在调度器初始化之前存在于系统命名空间中。配置必须作为 'Data' 映射中元素的值提供，其中 key='policy.cfg'</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--policy-configmap-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "kube-system"</td>
+    -->
+      <td colspan="2">--policy-configmap-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "kube-system"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the namespace where policy ConfigMap is located. The kube-system namespace will be used if this is not provided or is empty.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 策略 ConfigMap 所在的命名空间。 如果未提供此命名空间或为空，则将使用系统命名空间。</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10251</td>
+    -->
+      <td colspan="2">--port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 10251</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve HTTPS at all. See --secure-port instead.</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 不安全地提供没有身份验证和授权的 HTTP 端口。 如果为0，则根本不提供 HTTPS。 请参阅 --secure-port。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--profiling</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: enable profiling via web interface host:port/debug/pprof/</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 通过 web 接口 host:port/debug/pprof/ 启动性能分析</td>
+    </tr>
+
+    <tr>
+    <!--
+      <td colspan="2">--scheduler-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default-scheduler"</td>
+    -->
+      <td colspan="2">--scheduler-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: "default-scheduler"</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's "spec.schedulerName".</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 调度器名称，用于根据 pod 的 "spec.SchedulerName" 选择哪些 pod 将被此调度器处理。</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--use-legacy-policy-config</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses policy config file</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">弃用: 当设置为 true 时，调度器将忽略策略 ConfigMap 并使用策略配置文件</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--version version[=true]</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Print version information and quit</td>
+    -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">打印版本信息并退出</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--write-config-to string</td>
+    </tr>
+    <tr>
+    <!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If set, write the configuration values to this file and exit.</td>
+      -->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">如果设置，将配置值写入此文件并退出。</td>
+    </tr>
+
+  </tbody>
+</table>
diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh/docs/reference/command-line-tools-reference/kubelet.md
new file mode 100644
index 0000000000000..0413ade7d9168
--- /dev/null
+++ b/content/zh/docs/reference/command-line-tools-reference/kubelet.md
@@ -0,0 +1,112 @@
+---
+title: kubelet
+notitle: true
+---
+## kubelet
+
+
+
+<!--
+### Synopsis
+-->
+### 概要
+
+
+<!--
+The kubelet is the primary "node agent" that runs on each
+node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object
+that describes a pod. The kubelet takes a set of PodSpecs that are provided through
+various mechanisms (primarily through the apiserver) and ensures that the containers
+described in those PodSpecs are running and healthy. The kubelet doesn't manage
+containers which were not created by Kubernetes.
+-->
+kubelet 是在每个节点上运行的主要 "节点代理"。kubelet 以 PodSpec 为单位来运行任务，PodSpec 是一个描述 pod 的 YAML 或 JSON 对象。
+kubelet 运行多种机制（主要通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpecs 中描述的容器健康运行。
+不是 Kubernetes 创建的容器将不在 kubelet 的管理范围。
+
+<!--
+Other than from a PodSpec from the apiserver, there are three ways that a container
+manifest can be provided to the Kubelet.
+
+File: Path passed as a flag on the command line. Files under this path will be monitored
+periodically for updates. The monitoring period is 20s by default and is configurable
+via a flag.
+
+HTTP endpoint: HTTP endpoint passed as a parameter on the command line. This endpoint
+is checked every 20 seconds (also configurable with a flag).
+
+HTTP server: The kubelet can also listen for HTTP and respond to a simple API
+(underspec'd currently) to submit a new manifest.
+-->
+除了来自 apiserver 的 PodSpec 之外，还有三种方法可以将容器清单提供给 Kubelet。
+
+文件：通过命令行传入的文件路径。kubelet 将定期监听该路径下的文件以获得更新。监视周期默认为 20 秒，可通过参数进行配置。
+
+HTTP 端点：HTTP 端点以命令行参数传入。每 20 秒检查一次该端点（该时间间隔也是可以通过命令行配置的）。
+
+HTTP 服务：kubelet 还可以监听 HTTP 并响应简单的 API（当前未指定）以提交新的清单。
+
+```
+kubelet [flags]
+```
+
+<!--
+### Options
+-->
+### 选项
+
+<table style="width: 100%; table-layout: fixed;">
+  <colgroup>
+    <col span="1" style="width: 10px;" />
+    <col span="1" />
+  </colgroup>
+  <tbody>
+
+    <tr>
+      <td colspan="2">--azure-container-registry-config string</td>
+    </tr>
+    <tr>
+<!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
+-->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">包含 Azure 容器注册配置信息的文件路径</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">-h, --help</td>
+    </tr>
+    <tr>
+<!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kubelet</td>
+-->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubelet 的帮助信息</td>
+    </tr>
+
+    <tr>
+<!--
+      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5s</td>
+-->
+      <td colspan="2">--log-flush-frequency 间隔&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认: 5s</td>
+    </tr>
+    <tr>
+<!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes</td>
+-->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">日志刷新间隔的最大秒数</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--version version[=true]</td>
+    </tr>
+    <tr>
+<!--
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Print version information and quit</td>
+-->
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">打印版本信息并退出</td>
+    </tr>
+
+  </tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/kubectl/kubectl.md b/content/zh/docs/reference/kubectl/kubectl.md
new file mode 100644
index 0000000000000..052ce700a6e9e
--- /dev/null
+++ b/content/zh/docs/reference/kubectl/kubectl.md
@@ -0,0 +1,178 @@
+---
+title: kubectl
+notitle: true
+---
+
+## kubectl
+<!--
+kubectl controls the Kubernetes cluster manager
+-->
+kubectl ���Բٿ� Kubernetes ��Ⱥ��
+
+<!--
+### Synopsis
+
+kubectl controls the Kubernetes cluster manager. 
+
+Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
+-->
+### ���
+
+kubectl ���Բٿ� Kubernetes ��Ⱥ��
+
+��ȡ������Ϣ������ʣ�https://kubernetes.io/docs/reference/kubectl/overview/
+
+```
+kubectl [flags]
+```
+<!--
+### Options
+
+```
+      --alsologtostderr                  log to standard error as well as files
+      --as string                        Username to impersonate for the operation
+      --as-group stringArray             Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
+      --cache-dir string                 Default HTTP cache directory (default "/home/username/.kube/http-cache")
+      --certificate-authority string     Path to a cert file for the certificate authority
+      --client-certificate string        Path to a client certificate file for TLS
+      --client-key string                Path to a client key file for TLS
+      --cluster string                   The name of the kubeconfig cluster to use
+      --context string                   The name of the kubeconfig context to use
+  -h, --help                             help for kubectl
+      --insecure-skip-tls-verify         If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
+      --kubeconfig string                Path to the kubeconfig file to use for CLI requests.
+      --log-backtrace-at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
+      --log-dir string                   If non-empty, write log files in this directory
+      --logtostderr                      log to standard error instead of files
+      --match-server-version             Require server version to match client version
+  -n, --namespace string                 If present, the namespace scope for this CLI request
+      --request-timeout string           The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
+  -s, --server string                    The address and port of the Kubernetes API server
+      --stderrthreshold severity         logs at or above this threshold go to stderr (default 2)
+      --token string                     Bearer token for authentication to the API server
+      --user string                      The name of the kubeconfig user to use
+  -v, --v Level                          log level for V logs
+      --vmodule moduleSpec               comma-separated list of pattern=N settings for file-filtered logging
+```
+-->
+### ѡ��
+```
+      --alsologtostderr                  ͬʱ�����־����׼�������̨���ļ�
+      --as string                        ��ָ���û�ִ�в���
+	  --as-group stringArray             ģ��������飬����ʹ�������ʶ��ָ������顣
+      --cache-dir string                 Ĭ�� HTTP ����Ŀ¼��Ĭ��ֵ "/home/username/.kube/http-cache" ��
+      --certificate-authority string     ���ڽ�����֤��Ȩ�� .cert �ļ�·��
+      --client-certificate string        TLS ʹ�õĿͻ���֤��·��
+      --client-key string                TLS ʹ�õĿͻ�����Կ�ļ�·��
+      --cluster string                   ָ��Ҫʹ�õ� kubeconfig �ļ��м�Ⱥ��
+      --context string                   ָ��Ҫʹ�õ� kubeconfig �ļ���������
+  -h, --help                             kubectl ����
+      --insecure-skip-tls-verify         ֵΪ true���򲻻����������֤�����Ч�ԡ� �⽫ʹ����HTTPS���Ӳ���ȫ
+      --kubeconfig string                CLI ����ʹ�õ� kubeconfig �����ļ�·����
+      --log-backtrace-at traceLocation   ����־���ȳ����涨������ʱ�����Զ�ջ��Ϣ��Ĭ��ֵ��0��
+      --log-dir string                   �����Ϊ�գ�����־�ļ�д���Ŀ¼
+      --logtostderr                      ��־�������׼�������̨����������ļ�
+      --match-server-version             Ҫ��ͻ��˰汾�ͷ���˰汾��ƥ��
+  -n, --namespace string                 ������ڣ�CLI ����ʹ�ô������ռ�
+      --request-timeout string           ����һ���򵥷�������ǰ�ĵȴ�ʱ�䣬����ֵ��Ҫ������Ӧʱ�䵥λ(���磺1s, 2m, 3h)����ֵ����Ϊ������ʱ���� (Ĭ��ֵ "0")
+  -s, --server string                    Kubernetes API server �ĵ�ַ�Ͷ˿�
+      --stderrthreshold severity         ���ڻ���ڴ���ֵ����־�������׼�������̨��Ĭ��ֵ2��
+      --token string                     ���� API server ����������֤�ij�������
+      --user string                      ָ��ʹ�õ� kubeconfig �����ļ��е��û���
+  -v, --v Level                          ָ�������־����־����
+      --vmodule moduleSpec               ָ�������־��ģ�飬��ʽ���£�pattern=N��ʹ�ö��ŷָ�
+```
+<!--
+### SEE ALSO
+
+* [kubectl alpha](kubectl_alpha.md)	 - Commands for features in alpha
+* [kubectl annotate](kubectl_annotate.md)	 - Update the annotations on a resource
+* [kubectl api-resources](kubectl_api-resources.md)	 - Print the supported API resources on the server
+* [kubectl api-versions](kubectl_api-versions.md)	 - Print the supported API versions on the server, in the form of "group/version"
+* [kubectl apply](kubectl_apply.md)	 - Apply a configuration to a resource by filename or stdin
+* [kubectl attach](kubectl_attach.md)	 - Attach to a running container
+* [kubectl auth](kubectl_auth.md)	 - Inspect authorization
+* [kubectl autoscale](kubectl_autoscale.md)	 - Auto-scale a Deployment, ReplicaSet, or ReplicationController
+* [kubectl certificate](kubectl_certificate.md)	 - Modify certificate resources.
+* [kubectl cluster-info](kubectl_cluster-info.md)	 - Display cluster info
+* [kubectl completion](kubectl_completion.md)	 - Output shell completion code for the specified shell (bash or zsh)
+* [kubectl config](kubectl_config.md)	 - Modify kubeconfig files
+* [kubectl convert](kubectl_convert.md)	 - Convert config files between different API versions
+* [kubectl cordon](kubectl_cordon.md)	 - Mark node as unschedulable
+* [kubectl cp](kubectl_cp.md)	 - Copy files and directories to and from containers.
+* [kubectl create](kubectl_create.md)	 - Create a resource from a file or from stdin.
+* [kubectl delete](kubectl_delete.md)	 - Delete resources by filenames, stdin, resources and names, or by resources and label selector
+* [kubectl describe](kubectl_describe.md)	 - Show details of a specific resource or group of resources
+* [kubectl drain](kubectl_drain.md)	 - Drain node in preparation for maintenance
+* [kubectl edit](kubectl_edit.md)	 - Edit a resource on the server
+* [kubectl exec](kubectl_exec.md)	 - Execute a command in a container
+* [kubectl explain](kubectl_explain.md)	 - Documentation of resources
+* [kubectl expose](kubectl_expose.md)	 - Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service
+* [kubectl get](kubectl_get.md)	 - Display one or many resources
+* [kubectl label](kubectl_label.md)	 - Update the labels on a resource
+* [kubectl logs](kubectl_logs.md)	 - Print the logs for a container in a pod
+* [kubectl options](kubectl_options.md)	 - Print the list of flags inherited by all commands
+* [kubectl patch](kubectl_patch.md)	 - Update field(s) of a resource using strategic merge patch
+* [kubectl plugin](kubectl_plugin.md)	 - Runs a command-line plugin
+* [kubectl port-forward](kubectl_port-forward.md)	 - Forward one or more local ports to a pod
+* [kubectl proxy](kubectl_proxy.md)	 - Run a proxy to the Kubernetes API server
+* [kubectl replace](kubectl_replace.md)	 - Replace a resource by filename or stdin
+* [kubectl rollout](kubectl_rollout.md)	 - Manage the rollout of a resource
+* [kubectl run](kubectl_run.md)	 - Run a particular image on the cluster
+* [kubectl scale](kubectl_scale.md)	 - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job
+* [kubectl set](kubectl_set.md)	 - Set specific features on objects
+* [kubectl taint](kubectl_taint.md)	 - Update the taints on one or more nodes
+* [kubectl top](kubectl_top.md)	 - Display Resource (CPU/Memory/Storage) usage.
+* [kubectl uncordon](kubectl_uncordon.md)	 - Mark node as schedulable
+* [kubectl version](kubectl_version.md)	 - Print the client and server version information
+* [kubectl wait](kubectl_wait.md)	 - Experimental: Wait for one condition on one or many resources
+-->
+### ��������
+
+* [kubectl alpha](kubectl_alpha.md)	 - alpha��������������
+* [kubectl annotate](kubectl_annotate.md)	 - ������Դ��ע��
+* [kubectl api-resources](kubectl_api-resources.md)	 - �ڷ������ϴ�ӡ֧�ֵ� API ��Դ
+* [kubectl api-versions](kubectl_api-versions.md)	 - �� "group/version" ����ʽ�ڷ������ϴ�ӡ֧�ֵ� API �汾
+* [kubectl apply](kubectl_apply.md)	 - ͨ���ļ������׼���뽫�������Ӹ���Դ
+* [kubectl attach](kubectl_attach.md)	 - ���ӵ��������е�����
+* [kubectl auth](kubectl_auth.md)	 - �����Ȩ
+* [kubectl autoscale](kubectl_autoscale.md)	 - �Զ���չ Deployment, ReplicaSet �� ReplicationController
+* [kubectl certificate](kubectl_certificate.md)	 - �޸�֤����Դ��
+* [kubectl cluster-info](kubectl_cluster-info.md)	 - չʾ��Ⱥ��Ϣ
+* [kubectl completion](kubectl_completion.md)	 - Ϊ������ shell �����ɴ��루 bash �� zsh��
+* [kubectl config](kubectl_config.md)	 - �޸� kubeconfig �����ļ�
+* [kubectl convert](kubectl_convert.md)	 - �ڲ�ͬ�� API �汾֮��ת�������ļ�
+* [kubectl cordon](kubectl_cordon.md)	 - �� node �ڵ���Ϊ���ɵ���
+* [kubectl cp](kubectl_cp.md)	 - �����������ļ���Ŀ¼��Ҳ�ɽ��ļ���Ŀ¼���Ƶ�������
+* [kubectl create](kubectl_create.md)	 - ͨ���ļ������׼���봴����Դ��
+* [kubectl delete](kubectl_delete.md)	 - ͨ���ļ�������׼���룬��Դ�����ƻ���Դ�ͱ�ǩѡ����ɾ����Դ
+* [kubectl describe](kubectl_describe.md)	 - ��ʾ�ض���Դ����Դ�����ϸ��Ϣ
+* [kubectl drain](kubectl_drain.md)	 - Ϊ����ά������Ҫ��ǰ����node�ڵ�
+* [kubectl edit](kubectl_edit.md)	 - �ڷ������༭��Դ
+* [kubectl exec](kubectl_exec.md)	 - �������˳�����
+* [kubectl explain](kubectl_explain.md)	 - ��Դ�ĵ�
+* [kubectl expose](kubectl_expose.md)	 - ��ȡ replication controller, service, deployment �� pod ��Դ������Ϊ�µ� Kubernetes ����¶
+* [kubectl get](kubectl_get.md)	 - չʾһ��������Դ
+* [kubectl label](kubectl_label.md)	 - ������Դ��ǩ
+* [kubectl logs](kubectl_logs.md)	 - Ϊ pod �е�������ӡ��־
+* [kubectl options](kubectl_options.md)	 - ��ӡ��������̳еı�ʶ�б�
+* [kubectl patch](kubectl_patch.md)	 - ʹ��ս���Ժϲ�����������Դ�ֶ�
+* [kubectl plugin](kubectl_plugin.md)	 - ����������
+* [kubectl port-forward](kubectl_port-forward.md)	 - �� pod ����һ���������ض˿�
+* [kubectl proxy](kubectl_proxy.md)	 - Ϊ Kubernetes API server ���д���
+* [kubectl replace](kubectl_replace.md)	 - ͨ���ļ����׼�����滻��Դ
+* [kubectl rollout](kubectl_rollout.md)	 - ������Դչʾ
+* [kubectl run](kubectl_run.md)	 - �ڼ�Ⱥ������ָ������
+* [kubectl scale](kubectl_scale.md)	 - �� Deployment, ReplicaSet, Replication Controller �� Job �����¸�����ģ
+* [kubectl set](kubectl_set.md)	 - �����������ض�����
+* [kubectl taint](kubectl_taint.md)	 - ����һ������ node �ڵ���۵���Ϣ
+* [kubectl top](kubectl_top.md)	 - չʾ��Դ (CPU/Memory/Storage) ʹ����Ϣ��
+* [kubectl uncordon](kubectl_uncordon.md)	 - ��� node �ڵ�Ϊ�ɵ���
+* [kubectl version](kubectl_version.md)	 - ��ӡ�ͻ��˺ͷ���˰汾��Ϣ
+* [kubectl wait](kubectl_wait.md)	 - ����: ��һ��������Դ�ϵȴ��������
+
+<!--
+###### Auto generated by spf13/cobra on 16-Jun-2018
+-->
+######2018��6��16�գ�ͨ��spf13/cobra�Զ�����
+
diff --git a/content/cn/docs/reference/labels-annotations-taints.md b/content/zh/docs/reference/labels-annotations-taints.md
similarity index 100%
rename from content/cn/docs/reference/labels-annotations-taints.md
rename to content/zh/docs/reference/labels-annotations-taints.md
diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md
new file mode 100644
index 0000000000000..565d94b2fe860
--- /dev/null
+++ b/content/zh/docs/reference/tools.md
@@ -0,0 +1,112 @@
+<!--
+---
+reviewers:
+- janetkuo
+title: Tools
+content_template: templates/concept
+---
+-->
+---
+reviewers:
+- janetkuo
+title: ����
+content_template: templates/concept
+---
+
+<!--
+{{% capture overview %}}
+Kubernetes contains several built-in tools to help you work with the Kubernetes system.
+{{% /capture %}}
+-->
+{{% capture overview %}}
+Kubernetes ����һЩ���ù��ߣ����԰����û����õ�ʹ�� Kubernetes ϵͳ��
+{{% /capture %}}
+
+{{% capture body %}}
+## Kubectl
+
+<!--
+[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
+-->
+[`kubectl`](/docs/tasks/tools/install-kubectl/) �� Kubernetes �����й��ߣ����������ٿ� Kubernetes ��Ⱥ��
+
+## Kubeadm 
+
+<!--
+[`kubeadm`](/docs/tasks/tools/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
+-->
+[`kubeadm`](/docs/tasks/tools/install-kubeadm/) ��һ�������й��ߣ��������������������Ʒ��������������Ŀǰ���� alpha �׶Σ������ɲ���һ����ȫ�ɿ��� Kubernetes ��Ⱥ��
+
+## Kubefed
+
+<!--
+[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the command line tool
+to help you administrate your federated clusters.
+-->
+[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) ��һ�������й��ߣ��������������û��������Ⱥ��
+
+
+## Minikube
+
+<!--
+[`minikube`](/docs/tasks/tools/install-minikube/) is a tool that makes it
+easy to run a single-node Kubernetes cluster locally on your workstation for
+development and testing purposes.
+-->
+[`minikube`](/docs/tasks/tools/install-minikube/) ��һ�����Է����û����乤��վ�㱾�ز���һ�����ڵ� Kubernetes ��Ⱥ�Ĺ��ߣ����ڿ����Ͳ��ԡ�
+
+
+## Dashboard 
+
+<!--
+[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
+to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. 
+-->
+[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), �� Kubernetes ���� Web ���û��������棬�����û�����������Ӧ�õ� Kubernetes ��Ⱥ�����й����Ų��Լ�������Ⱥ�ͼ�Ⱥ��Դ�� 
+
+## Helm
+
+<!--
+[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
+Kubernetes resources, aka Kubernetes charts.
+-->
+[`Kubernetes Helm`](https://github.com/kubernetes/helm) ��һ������Ԥ������ Kubernetes ��Դ���Ĺ��ߣ��������Դ�� Helm ��Ҳ������ Kubernetes charts��
+
+<!--
+Use Helm to:
+
+* Find and use popular software packaged as Kubernetes charts
+* Share your own applications as Kubernetes charts
+* Create reproducible builds of your Kubernetes applications
+* Intelligently manage your Kubernetes manifest files
+* Manage releases of Helm packages
+-->
+ʹ�� Helm��
+
+*���Ҳ�ʹ���Ѿ����Ϊ Kubernetes charts ����������
+*�������Լ���Ӧ����Ϊ Kubernetes charts
+*Ϊ Kubernetes Ӧ�ô������ظ�ִ�еĹ���
+*Ϊ���� Kubernetes �嵥�ļ��ṩ�����ܻ��Ĺ���
+*���� Helm �������ķ���
+
+## Kompose
+
+<!--
+[`Kompose`](https://github.com/kubernetes-incubator/kompose) is a tool to help Docker Compose users move to Kubernetes.
+-->
+[`Kompose`](https://github.com/kubernetes-incubator/kompose) һ��ת�����ߣ��������� Docker Compose �û�Ǩ���� Kubernetes��
+
+<!--
+Use Kompose to:
+
+* Translate a Docker Compose file into Kubernetes objects
+* Go from local Docker development to managing your application via Kubernetes
+* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
+{{% /capture %}}
+-->
+ʹ�� Kompose:
+
+* ��һ�� Docker Compose �ļ����ͳ� Kubernetes ����
+* ������ Docker ���� ת���ͨ�� Kubernetes ������
+* ת�� v1 �� v2 Docker Compose `yaml` �ļ� �� [�ֲ�ʽӦ�ó����](https://docs.docker.com/compose/bundles/)
+{{% /capture %}}
\ No newline at end of file
diff --git a/content/zh/docs/setup/salt.md b/content/zh/docs/setup/salt.md
new file mode 100755
index 0000000000000..aa5ef2a87dedf
--- /dev/null
+++ b/content/zh/docs/setup/salt.md
@@ -0,0 +1,244 @@
+---
+cn-approvers:
+- linyouchong
+reviewers:
+- davidopp
+title: 使用 Salt 配置 Kubernetes 集群
+weight: 70
+content_template: templates/concept
+---
+<!--
+reviewers:
+- davidopp
+title: Configuring Kubernetes with Salt
+weight: 70
+content_template: templates/concept
+---
+-->
+
+{{% capture overview %}}
+
+<!--
+The Kubernetes cluster can be configured using Salt.
+-->
+Kubernetes 集群可以使用 Salt 进行配置
+
+<!--
+The Salt scripts are shared across multiple hosting providers and depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
+-->
+这些 Salt 脚本可以跨多个托管提供商共享，这取决于您在何处托管 Kubernetes 集群，您可能正在使用多种不同的操作系统和多种不同的网络配置。因此，在做修改 Salt 配置之前了解一些背景信息是很重要的，以便在使用其他主机托管提供商时降低集群配置失败的可能。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!--
+## Salt cluster setup
+-->
+## 创建 Salt 集群
+
+<!--
+The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others).
+-->
+**salt-master** 服务运行在 kubernetes-master 节点 [（除了在默认的 GCE 环境和 OpenStack-Heat 环境）](#standalone-salt-configuration-on-gce-and-others)。
+
+<!--
+The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster.
+-->
+**salt-minion** 服务运行在 kubernetes-master 节点和每个 kubernetes-node 节点。
+
+<!--
+Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others).
+-->
+每个 salt-minion 服务在 **master.conf** 文件中配置与 kubernetes-master 节点上的 **salt-master** 服务进行交互 [（除了 GCE 环境和 OpenStack-Heat 环境）](#standalone-salt-configuration-on-gce-and-others)。
+
+```shell
+cat /etc/salt/minion.d/master.conf
+```
+
+```none
+master: kubernetes-master
+```
+
+<!--
+The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes.
+-->
+每个 salt-minion 都会与 salt-master 联系，根据其提供的机器信息，salt-master 会向其提供作为 kubernetes-master 或 kubernetes-node 用于运行 Kubernetes 所需要的能力。
+
+<!--
+If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master.  It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
+-->
+如果您正使用基于 Vagrant 的环境，**salt-api** 服务运行在 kubernetes-master 节点。它被配置为使 Vagrant 用户能够对 Salt 集群进行内省，以便通过 REST API 了解 Vagrant 环境中的机器的信息。
+
+<!--
+## Standalone Salt Configuration on GCE and others
+-->
+## 在 GCE 和其它环境下独立配置 Salt
+
+<!--
+On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state.
+-->
+在 GCE 和 OpenStack 环境，使用 Openstack-Heat 提供商，master 和 node 节点被配置为 [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html)。每个 VM 的配置都源于它的 [instance metadata](https://cloud.google.com/compute/docs/metadata) 并被保存在 Salt grains (`/etc/salt/minion.d/grains.conf`) 和本地 Salt 用于保存执行状态的 pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) 中。
+
+<!--
+All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes.
+-->
+对于 GCE 和 OpenStack ，所有引用 master/minion 设置的其余部分都应该被忽略。这种设置的一个后果是，Salt 不存在 - 节点之间不存在配置共享。
+
+<!--
+## Salt security
+-->
+## Salt 安全
+
+<!--
+*(Not applicable on default GCE and OpenStack-Heat setup.)*
+-->
+*（不适用于 默认的 GCE 和 OpenStack-Heat 配置环境。）*
+
+<!--
+Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions.  It is not recommended to use this security configuration in production environments without deeper study.  (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
+-->
+salt-master 没有启用安全功能，salt-master 被配置为自动接受所有来自 minion 的接入请求。在深入研究之前，不推荐在生产环境中启用安全配置。（在某些环境中，如果 salt-master 端口不能从外部访问，并且您信任您的网络上的每个节点，这并不像它看起来那么糟糕）
+
+```shell
+cat /etc/salt/master.d/auto-accept.conf
+```
+
+```shell
+open_mode: True
+auto_accept: True
+```
+
+<!--
+## Salt minion configuration
+-->
+## 配置 Salt minion
+
+<!--
+Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.
+-->
+Salt 集群中的每个 minion 都有一个相关的配置，它指示 salt-master 如何在机器上提供所需的资源。
+
+<!--
+An example file is presented below using the Vagrant based environment.
+-->
+下面是一个基于 Vagrant 环境的示例文件：
+
+```shell
+cat /etc/salt/minion.d/grains.conf
+```
+
+```yaml
+grains:
+  etcd_servers: $MASTER_IP
+  cloud: vagrant
+  roles:
+    - kubernetes-master
+```
+
+<!--
+Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files.
+-->
+每个托管环境都使用了略微不同的 grains.conf 文件，用于在需要的 Salt 文件中构建条件逻辑。
+
+<!--
+The following enumerates the set of defined key/value pairs that are supported today.  If you add new ones, please make sure to update this list.
+-->
+下面列举了目前支持的定义键/值对的集合。如果你添加了新的，请确保更新这个列表。
+
+<!--
+Key | Value
+-->
+键 | 值
+-----------------------------------|----------------------------------------------------------------
+<!--
+`api_servers` | (Optional) The IP address / host name where a kubelet can get read-only access to kube-apiserver
+-->
+`api_servers` | （可选） IP 地址/主机名 ，kubelet 用其访问 kube-apiserver
+<!--
+`cbr-cidr` | (Optional) The minion IP address range used for the docker container bridge.
+-->
+`cbr-cidr` | （可选） docker 容器网桥分配给 minion 节点的 IP 地址范围
+<!--
+`cloud` | (Optional) Which IaaS platform is used to host Kubernetes, *gce*, *azure*, *aws*, *vagrant*
+-->
+`cloud` | （可选） 托管 Kubernetes 的 IaaS 平台， *gce*, *azure*, *aws*, *vagrant*
+<!--
+`etcd_servers` | (Optional) Comma-delimited list of IP addresses the kube-apiserver and kubelet use to reach etcd.  Uses the IP of the first machine in the kubernetes_master role, or 127.0.0.1 on GCE.
+-->
+`etcd_servers` | （可选） 以逗号分隔的 IP 地址列表，kube-apiserver 和 kubelet 使用其访问 etcd。kubernetes_master 角色的节点使用第一个机器的 IP ，在 GCE 环境上使用 127.0.0.1。
+<!--
+`hostnamef` | (Optional) The full host name of the machine, i.e. uname -n
+-->
+`hostnamef` | （可选） 机器的完整主机名，即：uname -n
+<!--
+`node_ip` | (Optional) The IP address to use to address this node
+-->
+`node_ip` | （可选）用于定位本节点的 IP 地址
+<!--
+`hostname_override` | (Optional) Mapped to the kubelet hostname-override
+-->
+`hostname_override` | （可选）对应 kubelet 的 hostname-override 参数
+<!--
+`network_mode` | (Optional) Networking model to use among nodes: *openvswitch*
+-->
+`network_mode` | （可选）节点间使用的网络模型：*openvswitch*
+<!--
+`networkInterfaceName` | (Optional) Networking interface to use to bind addresses, default value *eth0*
+-->
+`networkInterfaceName` | （可选）用于绑定地址的网络接口，默认值 *eth0*
+<!--
+`publicAddressOverride` | (Optional) The IP address the kube-apiserver should use to bind against for external read-only access
+-->
+`publicAddressOverride` | （可选）kube-apiserver 用于外部只读访问而绑定的IP地址
+<!--
+`roles` | (Required) 1. `kubernetes-master` means this machine is the master in the Kubernetes cluster.  2. `kubernetes-pool` means this machine is a kubernetes-node.  Depending on the role, the Salt scripts will provision different resources on the machine.
+-->
+`roles` | （必选）1、`kubernetes-master` 表示本节点是 Kubernetes 集群的 master。2、`kubernetes-pool` 表示本节点是一个 kubernetes-node。根据角色，Salt 脚本会在机器上提供不同的资源
+
+<!--
+These keys may be leveraged by the Salt sls files to branch behavior.
+-->
+Salt sls 文件可以应用这些键到分支行为。
+
+<!--
+In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.).  As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following.
+-->
+此外，一个集群可能运行在基于 Debian 的操作系统或基于 Red Hat 的操作系统（Centos、Fedora、RHEL等）。因此，有时区分基于操作系统的行为（如果像下面这样的分支）是很重要的。
+
+```liquid
+
+{% if grains['os_family'] == 'RedHat' %}
+// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc.
+{% else %}
+// something specific to Debian environment (apt-get, initd)
+{% endif %}
+
+```
+
+<!--
+## Best Practices
+-->
+## 最佳实践
+
+<!--
+When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments.  This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
+-->
+在为进程配置默认参数时，最好避免使用环境文件（ Red Hat 环境中的 Systemd ）或 init.d 文件（ Debian 发行版）以保留在操作系统环境中应该通用的默认值。这有助于保持我们的 Salt 模板文件易于理解，因为管理员可能不熟悉每个发行版的细节。
+
+<!--
+## Future enhancements (Networking)
+-->
+## 未来的增强（网络）
+
+<!--
+Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.)
+-->
+每个 pod IP 配置都是特定于提供商的，因此在进行网络更改时，必须将这些设置为沙箱，因为不同的提供商可能不会使用相同的机制（ iptables 、openvswitch 等）。
+
+<!--
+We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers.
+-->
+我们应该定义一个 grains.conf 键，这样能更明确地捕获正在使用的网络环境配置，以避免将来在不同的提供商之间产生混淆。
+
+{{% /capture %}}
\ No newline at end of file
diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
new file mode 100644
index 0000000000000..3b6f66b203e03
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
@@ -0,0 +1,573 @@
+<!--
+---
+title: Accessing Clusters
+weight: 20
+content_template: templates/concept
+---
+-->
+---
+title: 访问集群
+weight: 20
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+<!--
+This topic discusses multiple ways to interact with clusters.
+-->
+本文阐述多种与集群交互的方法。
+
+{{% /capture %}}
+
+{{< toc >}}
+
+{{% capture body %}}
+
+<!--
+## Accessing for the first time with kubectl
+
+When accessing the Kubernetes API for the first time, we suggest using the
+Kubernetes CLI, `kubectl`.
+
+To access a cluster, you need to know the location of the cluster and have credentials
+to access it.  Typically, this is automatically set-up when you work through
+a [Getting started guide](/docs/setup/),
+or someone else setup the cluster and provided you with credentials and a location.
+
+Check the location and credentials that kubectl knows about with this command:
+-->
+## 使用 kubectl 完成集群的第一次访问
+
+当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。
+
+访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
+
+通过以下命令检查 kubectl 是否知道集群地址及凭证：
+
+```shell
+$ kubectl config view
+```
+
+<!--
+Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
+kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
+
+## Directly accessing the REST API
+
+Kubectl handles locating and authenticating to the apiserver.
+If you want to directly access the REST API with an http client like
+curl or wget, or a browser, there are several ways to locate and authenticate:
+
+  - Run kubectl in proxy mode.
+    - Recommended approach.
+    - Uses stored apiserver location.
+    - Verifies identity of apiserver using self-signed cert.  No MITM possible.
+    - Authenticates to apiserver.
+    - In future, may do intelligent client-side load-balancing and failover.
+  - Provide the location and credentials directly to the http client.
+    - Alternate approach.
+    - Works with some types of client code that are confused by using a proxy.
+    - Need to import a root cert into your browser to protect against MITM.
+-->
+有许多 [例子](/docs/user-guide/kubectl-cheatsheet) 介绍了如何使用 kubectl，可以在 [kubectl手册](/docs/user-guide/kubectl-overview) 中找到更完整的文档。
+
+## 直接访问 REST API
+Kubectl 处理 apiserver 的定位和身份验证。
+如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过多种方式查找和验证：
+
+
+  - 以代理模式运行 kubectl。
+    - 推荐此方式。
+    - 使用已存储的 apiserver 地址。
+    - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
+    - 对 apiserver 进行身份验证。
+    - 未来可能会实现智能化的客户端负载均衡和故障恢复。
+  - 直接向 http 客户端提供位置和凭据。
+    - 可选的方案。
+    - 适用于代理可能引起混淆的某些客户端类型。
+    - 需要引入根证书到您的浏览器以防止 MITM 攻击。
+
+<!--
+### Using kubectl proxy
+
+The following command runs kubectl in a mode where it acts as a reverse proxy.  It handles
+locating the apiserver and authenticating.
+Run it like this:
+-->
+### 使用 kubectl 代理
+
+以下命令以反向代理的模式运行kubectl。它处理 apiserver 的定位和验证。
+像这样运行：
+
+```shell
+$ kubectl proxy --port=8080 &
+```
+
+<!--
+See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details.
+
+Then you can explore the API with curl, wget, or a browser, replacing localhost
+with [::1] for IPv6, like so:
+-->
+参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多详细信息。
+
+然后，您可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，如下所示：
+
+```shell
+$ curl http://localhost:8080/api/
+{
+  "versions": [
+    "v1"
+  ]
+}
+```
+
+
+<!--
+### Without kubectl proxy
+
+In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
+-->
+### 不使用 kubectl 代理
+
+在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
+
+```shell
+$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
+$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+<!--
+The above examples use the `--insecure` flag.  This leaves it subject to MITM
+attacks.  When kubectl accesses the cluster it uses a stored root certificate
+and client certificates to access the server.  (These are installed in the
+`~/.kube` directory).  Since cluster certificates are typically self-signed, it
+may take special configuration to get your http client to use root
+certificate.
+
+On some clusters, the apiserver does not require authentication; it may serve
+on localhost, or be protected by a firewall.  There is not a standard
+for this.  [Configuring Access to the API](/docs/admin/accessing-the-api)
+describes how a cluster admin can configure this.  Such approaches may conflict
+with future high-availability support.
+-->
+上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。
+
+在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/docs/admin/accessing-the-api) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
+
+<!--
+## Programmatic access to the API
+
+Kubernetes officially supports [Go](#go-client) and [Python](#python-client)
+client libraries.
+
+### Go client
+
+* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
+* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
+
+The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
+
+If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
+-->
+## 以编程方式访问 API
+
+Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客户端库支持。
+
+### Go 客户端
+
+* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 来查看目前支持哪些版本。
+* 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
+
+Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
+
+如果应用程序以 Pod 的形式部署在集群中，那么请参阅 [下一章](#accessing-the-api-from-a-pod)。
+
+<!--
+### Python client
+
+To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
+
+The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples/example1.py).
+
+### Other languages
+
+There are [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages.
+See documentation for other libraries for how they authenticate.
+-->
+### Python 客户端
+
+如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。
+
+Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples/example1.py)。
+
+### 其它语言
+
+目前有多个 [客户端库](/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
+参阅其它库的相关文档以获取他们是如何验证的。
+
+<!--
+## Accessing the API from a Pod
+
+When accessing the API from a pod, locating and authenticating
+to the apiserver are somewhat different.
+
+The recommended way to locate the apiserver within the pod is with
+the `kubernetes.default.svc` DNS name, which resolves to a Service IP which in turn
+will be routed to an apiserver.
+
+The recommended way to authenticate to the apiserver is with a
+[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
+is associated with a service account, and a credential (token) for that
+service account is placed into the filesystem tree of each container in that pod,
+at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
+-->
+### 从 Pod 中访问 API
+
+当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
+
+在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc` 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
+
+向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
+通过 kube-system，pod 与服务帐户相关联，并且该服务帐户的凭证（token）被放置在该 pod 中每个容器的文件系统中，位于 `/var/run/secrets/kubernetes.io/serviceaccount/token`。
+
+<!--
+If available, a certificate bundle is placed into the filesystem tree of each
+container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
+used to verify the serving certificate of the apiserver.
+
+Finally, the default namespace to be used for namespaced API operations is placed in a file
+at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
+
+From within a pod the recommended ways to connect to API are:
+
+  - run `kubectl proxy` in a sidecar container in the pod, or as a background
+    process within the container. This proxies the
+    Kubernetes API to the localhost interface of the pod, so that other processes
+    in any container of the pod can access it.
+  - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
+    They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
+
+In each case, the credentials of the pod are used to communicate securely with the apiserver.
+-->
+如果可用，则将证书放入每个容器的文件系统中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，并且应该用于验证 apiserver 的服务证书。
+
+最后，命名空间化的 API 操作所使用的默认命名空间将被放置在每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
+
+在 pod 中，建议连接 API 的方法是：
+
+  - 在 pod 的 sidecar 容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
+    这将把 Kubernetes API 代理到当前 pod 的 localhost interface，所以 pod 中的所有容器中的进程都能访问它。
+  - 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。
+    他们处理 apiserver 的定位和身份验证。[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
+
+在每种情况下，pod 的凭证都是为了与 apiserver 安全地通信。
+
+<!--
+## Accessing services running on the cluster
+
+The previous section was about connecting the Kubernetes API server.  This section is about
+connecting to other services running on Kubernetes cluster.  In Kubernetes, the
+[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
+their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
+routable, so they will not be reachable from a machine outside the cluster,
+such as your desktop machine.
+-->
+## 访问集群中正在运行的服务
+
+上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。 
+在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。
+在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。
+
+<!--
+### Ways to connect
+
+You have several options for connecting to nodes, pods and services from outside the cluster:
+
+  - Access services through public IPs.
+    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
+      the cluster.  See the [services](/docs/user-guide/services) and
+      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
+    - Depending on your cluster environment, this may just expose the service to your corporate network,
+      or it may expose it to the internet.  Think about whether the service being exposed is secure.
+      Does it do its own authentication?
+    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
+      place a unique label on the pod and create a new service which selects this label.
+    - In most cases, it should not be necessary for application developer to directly access
+      nodes via their nodeIPs.
+  - Access services, nodes, or pods using the Proxy Verb.
+    - Does apiserver authentication and authorization prior to accessing the remote service.
+      Use this if the services are not secure enough to expose to the internet, or to gain
+      access to ports on the node IP, or for debugging.
+    - Proxies may cause problems for some web applications.
+    - Only works for HTTP/HTTPS.
+    - Described [here](#manually-constructing-apiserver-proxy-urls).
+  - Access from a node or pod in the cluster.
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
+      Connect to other nodes, pods, and services from that shell.
+    - Some clusters may allow you to ssh to a node in the cluster.  From there you may be able to
+      access cluster services.  This is a non-standard method, and will work on some clusters but
+      not others.  Browsers and other tools may or may not be installed.  Cluster DNS may not work.
+-->
+### 连接的方法
+
+有多种方式可以从集群外部连接节点、pod 和服务：
+
+  - 通过公共 IP 访问服务。
+    - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
+      请参阅 [服务](/docs/user-guide/services) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
+    - 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。
+      请考虑公开该服务是否安全。它是否进行自己的身份验证？
+    - 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。
+    - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
+  - 使用 Proxy Verb 访问服务、node 或者 pod。
+    - 在访问远程服务之前进行 apiserver 身份验证和授权。
+      如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。
+    - 代理可能会给一些 web 应用带来问题。
+    - 只适用于 HTTP/HTTPS。
+    - 更多详细信息在 [这里]。
+  - 从集群中的 node 或者 pod 中访问。
+    - 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。
+      然后从 shell 中连接其它的节点、pod 和服务。
+    - 有些集群可能允许您通过 ssh 连接到 node，从那您可能可以访问集群的服务。
+      这是一个非正式的方式，可能可以运行在个别的集群上。
+      浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
+
+<!--
+### Discovering builtin services
+
+Typically, there are several services which are started on a cluster by kube-system. Get a list of these
+with the `kubectl cluster-info` command:
+-->
+### 发现内建服务
+
+通常来说，集群中会有 kube-system 创建的一些运行的服务。
+
+通过 `kubectl cluster-info` 命令获得这些服务列表：
+
+```shell
+$ kubectl cluster-info
+
+  Kubernetes master is running at https://104.197.5.247
+  elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
+  kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
+  kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
+  grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+  heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+```
+
+<!--
+This shows the proxy-verb URL for accessing each service.
+For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
+at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed.  Logging can also be reached through a kubectl proxy, for example at:
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
+(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
+-->
+这展示了访问每个服务的 proxy-verb URL。
+例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，那么可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 进行访问。日志也能通过 kubectl 代理获取，例如：
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
+（参阅 [上面的内容](#accessing-the-cluster-api) 来获取如何使用 kubectl 代理来传递凭证）
+
+<!--
+#### Manually constructing apiserver proxy URLs
+
+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 simply append to the service's proxy URL:
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`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.
+
+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/`*`https:service_name:[port_name]`*`/proxy`
+
+The supported formats for the 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 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 using https
+-->
+#### 手动构建 apiserver 代理 URL
+
+如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
+
+如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。
+
+默认情况下，API server 使用 http 代理您的服务。要使用 https，请在服务名称前加上 `https:`：
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
+
+URL 名称段支持的格式为：
+
+* `<service_name>` - 使用 http 代理到默认或未命名的端口
+* `<service_name>:<port_name>` - 使用 http 代理到指定的端口
+* `https:<service_name>:` - 使用 https 代理到默认或未命名的端口（注意后面的冒号）
+* `https:<service_name>:<port_name>` - 使用 https 代理到指定的端口
+
+<!--
+##### Examples
+
+ * To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:   `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
+ * To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:   `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
+-->
+##### 示例
+
+ * 要访问 Elasticsearch  服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
+ * 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
+
+```json
+  {
+    "cluster_name" : "kubernetes_logging",
+    "status" : "yellow",
+    "timed_out" : false,
+    "number_of_nodes" : 1,
+    "number_of_data_nodes" : 1,
+    "active_primary_shards" : 5,
+    "active_shards" : 5,
+    "relocating_shards" : 0,
+    "initializing_shards" : 0,
+    "unassigned_shards" : 5
+  }
+```
+
+<!--
+### Using web browsers to access services running on the cluster
+
+You may be able to put an apiserver proxy url into the address bar of a browser. However:
+
+  - Web browsers cannot usually pass tokens, so you may need to use basic (password) auth.  Apiserver can be configured to accept basic auth,
+    but your cluster may not be configured to accept basic auth.
+  - Some web apps may not work, particularly those with client side javascript that construct urls in a
+    way that is unaware of the proxy path prefix.
+-->
+### 使用 web 浏览器访问运行在集群上的服务
+
+您可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
+
+  - Web 浏览器通常不能传递 token，因此您可能需要使用基本（密码）身份验证。Apiserver 可以配置为接受基本身份验证，但您的集群可能未进行配置。
+  - 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。
+
+<!--
+## Requesting redirects
+
+The redirect capabilities have been deprecated and removed.  Please use a proxy (see below) instead.
+-->
+## 请求重定向
+
+已弃用并删除了重定向功能。请改用代理（见下文）。
+
+<!--
+## So Many Proxies
+
+There are several different proxies you may encounter when using Kubernetes:
+
+1.  The [kubectl proxy](#directly-accessing-the-rest-api):
+  
+    - runs on a user's desktop or in a pod
+    - proxies from a localhost address to the Kubernetes apiserver
+    - client to proxy uses HTTP
+    - proxy to apiserver uses HTTPS
+    - locates apiserver
+    - adds authentication headers
+    
+-->
+## 多种代理
+
+使用 Kubernetes 时可能会遇到几种不同的代理：
+
+1.  [kubectl 代理](#directly-accessing-the-rest-api)：
+
+    - 在用户的桌面或 pod 中运行
+    - 代理从本地主机地址到 Kubernetes apiserver
+    - 客户端到代理将使用 HTTP
+    - 代理到 apiserver 使用 HTTPS
+    - 定位 apiserver
+    - 添加身份验证 header
+    
+<!--
+1.  The [apiserver proxy](#discovering-builtin-services):
+  
+    - is a bastion built into the apiserver
+    - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
+    - runs in the apiserver processes
+    - client to proxy uses HTTPS (or http if apiserver so configured)
+    - proxy to target may use HTTP or HTTPS as chosen by proxy using available information
+    - can be used to reach a Node, Pod, or Service
+    - does load balancing when used to reach a Service
+-->
+1.  [apiserver 代理](#discovering-builtin-services)：
+
+    - 内置于 apiserver 中
+    - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
+    - 运行在 apiserver 进程中
+    - 客户端代理使用 HTTPS（也可配置为 http）
+    - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
+    - 可用于访问节点、Pod 或服务
+    - 在访问服务时进行负载平衡
+    
+<!--
+1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+  
+    - runs on each node
+    - proxies UDP and TCP
+    - does not understand HTTP
+    - provides load balancing
+    - is just used to reach services
+-->
+1.  [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
+  
+    - 运行在每个节点上
+    - 代理 UDP 和 TCP
+    - 不能代理 HTTP
+    - 提供负载均衡
+    - 只能用来访问服务
+    
+<!--
+1.  A Proxy/Load-balancer in front of apiserver(s):
+  
+    - existence and implementation varies from cluster to cluster (e.g. nginx)
+    - sits between all clients and one or more apiservers
+    - acts as load balancer if there are several apiservers.
+-->
+1.  位于 apiserver 之前的 Proxy/Load-balancer：
+  
+    - 存在和实现因集群而异（例如 nginx）
+    - 位于所有客户和一个或多个 apiserver 之间
+    - 如果有多个 apiserver，则充当负载均衡器
+    
+<!--
+1.  Cloud Load Balancers on external services:
+  
+    - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
+    - are created automatically when the Kubernetes service has type `LoadBalancer`
+    - use UDP/TCP only
+    - implementation varies by cloud provider.
+
+Kubernetes users will typically not need to worry about anything other than the first two types.  The cluster admin
+will typically ensure that the latter types are setup correctly.
+-->
+1.  外部服务上的云负载均衡器：
+  
+    - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
+    - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
+    - 只使用 UDP/TCP
+    - 具体实现因云提供商而异。
+
+除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。
+
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
rename to content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
diff --git a/content/cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
rename to content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
diff --git a/content/cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
rename to content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md
new file mode 100644
index 0000000000000..48cc0a019a75a
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md
@@ -0,0 +1,26 @@
+<!--
+---
+title: Configure DNS for a Cluster
+weight: 120
+content_template: templates/concept
+---
+-->
+---
+title: 为集群配置 DNS
+weight: 120
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+<!--
+Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. 
+-->
+Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。
+{{% /capture %}}
+{{% capture body %}}
+<!--
+For more information on how to configure DNS for a Kubernetes cluster, see the [Kubernetes DNS sample plugin.](https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns)
+-->
+有关如何为 Kubernetes 集群配置 DNS 的详细信息，请参阅 [Kubernetes DNS 插件示例.](https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns)
+
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
similarity index 98%
rename from content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
rename to content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index 74ba22eaa49cb..0c12f2410d450 100644
--- a/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -34,7 +34,7 @@ content_template: templates/tutorial
 
 * 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)，
   所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
-  [NodePort](/docs/user-guide/services/#nodeport) 类型的服务代替。
+  [NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。
 
 {{% /capture %}}
 
diff --git a/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
new file mode 100644
index 0000000000000..45ba1aa7e842e
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -0,0 +1,322 @@
+<!--
+---
+title: Create an External Load Balancer
+content_template: templates/task
+weight: 80
+---
+-->
+---
+title: 创建一个外部负载均衡器
+content_template: templates/task
+weight: 80
+---
+
+
+{{% capture overview %}}
+
+<!--
+This page shows how to create an External Load Balancer.
+
+When creating a service, you have the option of automatically creating a
+cloud network load balancer. This provides an externally-accessible IP address
+that sends traffic to the correct port on your cluster nodes
+_provided your cluster runs in a supported environment and is configured with
+the correct cloud load balancer provider package_.
+
+For information on provisioning and using an Ingress resource that can give
+services externally-reachable URLs, load balance the traffic, terminate SSL etc.,
+please check the [Ingress](/docs/concepts/services-networking/ingress/)
+documentation.
+-->
+本文展示如何创建一个外部负载均衡器。
+
+创建服务时，您可以选择自动创建云网络负载均衡器。这提供了一个外部可访问的 IP 地址，可将流量分配到集群节点上的正确端口上 _假设集群在支持的环境中运行，并配置了正确的云负载平衡器提供商包_。
+
+有关如何配置和使用 Ingress 资源以为服务提供外部可访问的 URL、负载均衡流量、终止 SSL 等功能，请查看 [Ingress](/docs/concepts/services-networking/ingress/) 文档。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Configuration file
+
+To create an external load balancer, add the following line to your
+[service configuration file](/docs/concepts/services-networking/service/#type-loadbalancer):
+-->
+## 配置文件
+
+要创建外部负载均衡器，请将以下内容添加到 [服务配置文件](/docs/concepts/services-networking/service/#type-loadbalancer)：
+
+```json
+    "type": "LoadBalancer"
+```
+
+<!--
+Your configuration file might look like:
+-->
+您的配置文件可能会如下所示：
+
+```json
+    {
+      "kind": "Service",
+      "apiVersion": "v1",
+      "metadata": {
+        "name": "example-service"
+      },
+      "spec": {
+        "ports": [{
+          "port": 8765,
+          "targetPort": 9376
+        }],
+        "selector": {
+          "app": "example"
+        },
+        "type": "LoadBalancer"
+      }
+    }
+```
+
+<!--
+## Using kubectl
+
+You can alternatively create the service with the `kubectl expose` command and
+its `--type=LoadBalancer` flag:
+-->
+## 使用 kubectl
+
+您也可以使用 `kubectl expose` 命令及其 `--type=LoadBalancer` 参数创建服务：
+
+```bash
+kubectl expose rc example --port=8765 --target-port=9376 \
+        --name=example-service --type=LoadBalancer
+```
+
+<!--
+This command creates a new service using the same selectors as the referenced
+resource (in the case of the example above, a replication controller named
+`example`).
+
+For more information, including optional flags, refer to the
+[`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).
+-->
+此命令通过使用与引用资源（在上面的示例的情况下，名为 `example` 的 replication controller）相同的选择器来创建一个新的服务。
+
+更多信息（包括更多的可选参数），请参阅 [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose)。
+
+<!--
+## Finding your IP address
+
+You can find the IP address created for your service by getting the service
+information through `kubectl`:
+-->
+## 找到您的 IP 地址
+
+您可以通过 `kubectl` 获取服务信息，找到为您的服务创建的 IP 地址：
+
+```bash
+kubectl describe services example-service
+```
+
+<!--
+which should produce output like this:
+-->
+这将获得如下输出：
+
+```bash
+    Name:                   example-service
+    Namespace:              default
+    Labels:                 <none>
+    Annotations:            <none>
+    Selector:               app=example
+    Type:                   LoadBalancer
+    IP:                     10.67.252.103
+    LoadBalancer Ingress:   123.45.678.9
+    Port:                   <unnamed> 80/TCP
+    NodePort:               <unnamed> 32445/TCP
+    Endpoints:              10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
+    Session Affinity:       None
+    Events:                 <none>
+```
+
+<!--
+The IP address is listed next to `LoadBalancer Ingress`.
+-->
+IP 地址列在 `LoadBalancer Ingress` 旁边。
+
+{{< note >}}
+<!--
+**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
+-->
+**注意：** 如果您在 Minikube 上运行服务，您可以通过以下命令找到分配的 IP 地址和端口：
+{{< /note >}}
+```bash
+minikube service example-service --url
+```
+
+<!--
+## Preserving the client source IP
+
+Due to the implementation of this feature, the source IP seen in the target
+container will *not be the original source IP* of the client. To enable
+preservation of the client IP, the following fields can be configured in the
+service spec (supported in GCE/Google Kubernetes Engine environments):
+
+* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
+external traffic to node-local or cluster-wide endpoints. There are two available
+options: "Cluster" (default) and "Local". "Cluster" obscures the client source
+IP and may cause a second hop to another node, but should have good overall
+load-spreading. "Local" preserves the client source IP and avoids a second hop
+for LoadBalancer and NodePort type services, but risks potentially imbalanced
+traffic spreading.
+* `service.spec.healthCheckNodePort` - specifies the healthcheck nodePort
+(numeric port number) for the service. If not specified, healthCheckNodePort is
+created by the service API backend with the allocated nodePort. It will use the
+user-specified nodePort value if specified by the client. It only has an
+effect when type is set to "LoadBalancer" and externalTrafficPolicy is set
+to "Local".
+
+This feature can be activated by setting `externalTrafficPolicy` to "Local" in the
+Service Configuration file.
+-->
+## 保留客户端源 IP
+
+由于此功能的实现，目标容器中看到的源 IP 将 *不是客户端的原始源 IP*。要启用保留客户端 IP，可以在服务的 spec 中配置以下字段（支持 GCE/Google Kubernetes Engine  环境）：
+
+* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项："Cluster"（默认）和 "Local"。"Cluster" 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。 "Local" 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，但存在潜在的不均衡流量传播风险。
+* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定，则 serviceCheckNodePort 由服务 API 后端使用已分配的 nodePort 创建。如果客户端指定，它将使用客户端指定的 nodePort 值。仅当 type 设置为 "LoadBalancer" 并且 externalTrafficPolicy 设置为 "Local" 时才生效。
+
+可以通过在服务的配置文件中将 `externalTrafficPolicy` 设置为 "Local" 来激活此功能。
+
+```json
+    {
+      "kind": "Service",
+      "apiVersion": "v1",
+      "metadata": {
+        "name": "example-service"
+      },
+      "spec": {
+        "ports": [{
+          "port": 8765,
+          "targetPort": 9376
+        }],
+        "selector": {
+          "app": "example"
+        },
+        "type": "LoadBalancer",
+        "externalTrafficPolicy": "Local"
+      }
+    }
+```
+
+<!--
+### Feature availability
+
+| k8s version | Feature support |
+| :---------: |:-----------:|
+| 1.7+ | Supports the full API fields |
+| 1.5 - 1.6 | Supports Beta Annotations |
+| <1.5 | Unsupported |
+
+Below you could find the deprecated Beta annotations used to enable this feature
+prior to its stable version. Newer Kubernetes versions may stop supporting these
+after v1.7. Please update existing applications to use the fields directly.
+
+* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` field
+* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` field
+
+`service.beta.kubernetes.io/external-traffic` annotation has a different set of values
+compared to the `service.spec.externalTrafficPolicy` field. The values match as follows:
+
+* "OnlyLocal" for annotation <-> "Local" for field
+* "Global" for annotation <-> "Cluster" for field
+
+**Note that this feature is not currently implemented for all cloudproviders/environments.**
+-->
+### 特性可用性
+
+| k8s 版本    | 特性支持     |
+| :---------: |:-----------:|
+| 1.7+ | 支持完整的 API 字段 |
+| 1.5 - 1.6 | 支持 Beta Annotation |
+| <1.5 | 不支持 |
+
+您可以在下面找到已弃用的 Beta annotation，在稳定版本前使用它来使用该功能。较新的 Kubernetes 版本可能会在 v1.7 之后停止支持这些功能。
+请更新现有应用程序以直接使用这些字段。
+
+* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` 字段
+* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` 字段
+
+`service.beta.kubernetes.io/external-traffic` annotation 与 `service.spec.externalTrafficPolicy` 字段相比拥有一组不同的值。值匹配如下：
+
+* "OnlyLocal" annotation <-> "Local" 字段
+* "Global" annotation <-> "Cluster" 字段
+
+**请注意，此功能目前尚未实现在所有云提供商/环境中。**
+
+<!--
+Known issues:
+-->
+已知的问题：
+
+* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
+* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+<!--
+## External Load Balancer Providers
+
+It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
+
+When the service type is set to `LoadBalancer`, Kubernetes provides functionality equivalent to `type=<ClusterIP>` to pods within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object.
+-->
+## 外部负载均衡器提供商
+
+请务必注意，此功能的数据路径由 Kubernetes 集群外部的负载均衡器提供。
+
+当服务类型设置为 `LoadBalancer` 时，Kubernetes 向集群中的 pod 提供与 `type=<ClusterIP>` 等效的功能，并通过使用 Kubernetes pod 的条目对负载均衡器（从外部到 Kubernetes）进行编程来扩展它。 Kubernetes 服务控制器自动创建外部负载均衡器，健康检查（如果需要），防火墙规则（如果需要），并获取云提供商分配的外部 IP 并将其填充到服务对象中。
+
+<!--
+## Caveats and Limitations when preserving source IPs
+
+GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB
+kube-proxy rules which would correctly balance across all endpoints.
+
+With the new functionality, the external traffic will not be equally load balanced across pods, but rather
+equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability
+for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
+pods on each node).
+
+We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal
+distribution will be seen, even without weights.
+
+Once the external load balancers provide weights, this functionality can be added to the LB programming path.
+*Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date*
+
+Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
+-->
+## 保留源 IP 时的注意事项和限制
+
+GCE/AWS 负载均衡器不为其目标池提供权重。对于旧的 LB kube-proxy 规则来说，这不是一个问题，它可以在所有端点之间正确平衡。
+
+使用新功能，外部流量不会在 pod 之间平均负载，而是在节点级别平均负载（因为 GCE/AWS 和其他外部 LB 实现无法指定每个节点的权重，因此它们的平衡跨所有目标节点，并忽略每个节点上的 pod 数量）。
+
+但是，我们可以声明，对于 NumServicePods << NumNodes 或 NumServicePods >> NumNodes 时，即使没有权重，也会看到接近相等的分布。
+
+一旦外部负载平衡器提供权重，就可以将此功能添加到 LB 编程路径中。
+*未来工作：1.4 版本不提供权重支持，但可能会在将来版本中添加*
+
+内部 pod 到 pod 的流量应该与 ClusterIP 服务类似，所有 pod 的概率相同。
+
+{{% /capture %}}
+
+
diff --git a/content/cn/docs/tasks/access-application-cluster/frontend.yaml b/content/zh/docs/tasks/access-application-cluster/frontend.yaml
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/frontend.yaml
rename to content/zh/docs/tasks/access-application-cluster/frontend.yaml
diff --git a/content/cn/docs/tasks/access-application-cluster/frontend/frontend.conf b/content/zh/docs/tasks/access-application-cluster/frontend/frontend.conf
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/frontend/frontend.conf
rename to content/zh/docs/tasks/access-application-cluster/frontend/frontend.conf
diff --git a/content/cn/docs/tasks/access-application-cluster/hello-service.yaml b/content/zh/docs/tasks/access-application-cluster/hello-service.yaml
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/hello-service.yaml
rename to content/zh/docs/tasks/access-application-cluster/hello-service.yaml
diff --git a/content/cn/docs/tasks/access-application-cluster/hello.yaml b/content/zh/docs/tasks/access-application-cluster/hello.yaml
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/hello.yaml
rename to content/zh/docs/tasks/access-application-cluster/hello.yaml
diff --git a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000000..a376b4c0980d7
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,193 @@
+<!--
+---
+title: List All Container Images Running in a Cluster
+content_template: templates/task
+weight: 100
+---
+-->
+---
+title: 列出集群中所有运行容器的镜像
+content_template: templates/task
+weight: 100
+---
+
+{{% capture overview %}}
+
+<!--
+This page shows how to use kubectl to list all of the Container images
+for Pods running in a cluster.
+-->
+本文展示如何使用 kubectl 来列出集群中所有运行 pod 的容器的镜像
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+In this exercise you will use kubectl to fetch all of the Pods
+running in a cluster, and format the output to pull out the list
+of Containers for each.
+-->
+在本练习中，您将使用 kubectl 来获取集群中运行的所有 Pod，并格式化输出来提取每个 pod 中的容器列表。
+
+<!--
+## List all Containers in all namespaces
+
+- Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
+- Format the output to include only the list of Container image names
+  using `-o jsonpath={..image}`.  This will recursively parse out the
+  `image` field from the returned json.
+  - See the [jsonpath reference](/docs/user-guide/jsonpath/)
+    for further information on how to use jsonpath.
+- Format the output using standard tools: `tr`, `sort`, `uniq`
+  - Use `tr` to replace spaces with newlines
+  - Use `sort` to sort the results
+  - Use `uniq` to aggregate image counts
+-->
+## 列出所有命名空间下的所有容器
+
+- 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
+- 使用 `-o jsonpath={..image}` 来格式化输出，以仅包含容器镜像名称。
+  这将以递归方式从返回的 json 中解析出 `image` 字段。
+  - 参阅 [jsonpath reference](/docs/user-guide/jsonpath/) 来获取更多关于如何使用 jsonpath 的信息。
+- 使用标准化工具来格式化输出：`tr`, `sort`, `uniq`
+  - 使用 `tr` 以用换行符替换空格
+  - 使用 `sort` 来对结果进行排序
+  - 使用 `uniq` 来聚合镜像计数
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+<!--
+The above command will recursively return all fields named `image`
+for all items returned.
+
+As an alternative, it is possible to use the absolute path to the image
+field within the Pod.  This ensures the correct field is retrieved
+even when the field name is repeated,
+e.g. many fields are called `name` within a given item:
+-->
+上面的命令将递归获取所有返回项目的名为 `image` 的字段。
+
+作为替代方案，可以使用 Pod 的镜像字段的绝对路径。这确保即使字段名称重复的情况下也能检索到正确的字段，例如，特定项目中的许多字段都称为 `name`：
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+<!--
+The jsonpath is interpreted as follows:
+
+- `.items[*]`: for each returned value
+- `.spec`: get the spec
+- `.containers[*]`: for each container
+- `.image`: get the image
+-->
+jsonpath 解释如下：
+
+- `.items[*]`: 对于每个返回的值
+- `.spec`: 获取 spec
+- `.containers[*]`: 对于每个容器
+- `.image`: 获取镜像
+
+{{< note >}}
+<!--
+**Note:** When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
+the `.items[*]` portion of the path should be omitted because a single
+Pod is returned instead of a list of items.
+-->
+**注意：** 按名字获取单个 Pod 时，例如 `kubectl get pod nginx`，路径的 `.items[*]` 部分应该省略，因为返回的是一个 Pod 而不是一个项目列表。
+{{< /note >}}
+
+<!--
+## List Containers by Pod
+
+The formatting can be controlled further by using the `range` operation to
+iterate over elements individually.
+-->
+## 列出 Pod 中的容器
+
+可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+<!--
+## List Containers filtering by Pod label
+
+To target only Pods matching a specific label, use the -l flag.  The
+following matches only Pods with labels matching `app=nginx`.
+-->
+## 列出以 label 过滤后的 Pod 的所有容器
+
+要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+<!--
+## List Containers filtering by Pod namespace
+
+To target only pods in a specific namespace, use the namespace flag. The
+following matches only Pods in the `kube-system` namespace.
+-->
+## 列出以命名空间过滤后的 Pod 的所有容器
+
+要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+<!--
+## List Containers using a go-template instead of jsonpath
+
+As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
+for formatting the output:
+-->
+## 使用 go-template 代替 jsonpath 来获取容器
+
+作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://golang.org/pkg/text/template/) 来格式化输出：
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+<!--
+### Reference
+
+* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
+* [Go template](https://golang.org/pkg/text/template/) reference guide
+-->
+### 参考
+
+* [Jsonpath](/docs/user-guide/jsonpath/) 参考指南
+* [Go template](https://golang.org/pkg/text/template/) 参考指南
+
+{{% /capture %}}
+
+
diff --git a/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
new file mode 100644
index 0000000000000..3308069220a81
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
@@ -0,0 +1,190 @@
+<!--
+---
+title: Provide Load-Balanced Access to an Application in a Cluster
+content_template: templates/tutorial
+weight: 50
+---
+-->
+---
+title: 提供对集群中应用程序的负载均衡访问
+content_template: templates/tutorial
+weight: 50
+---
+
+{{% capture overview %}}
+
+<!--
+This page shows how to create a Kubernetes Service object that provides
+load-balanced access to an application running in a cluster.
+-->
+本文展示如何创建一个 Kubernetes 服务对象，来提供负载均衡入口以访问集群内正在运行的应用程序。
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+
+{{% capture objectives %}}
+
+<!--
+* Run two instances of a Hello World application
+* Create a Service object
+* Use the Service object to access the running application
+-->
+* 运行两个 Hello World 应用示例
+* 创建一个服务对象
+* 使用这个服务对象来访问正在运行的应用
+
+{{% /capture %}}
+
+
+{{% capture lessoncontent %}}
+
+<!--
+## Creating a Service for an application running in two pods
+
+1. Run a Hello World application in your cluster:
+-->
+## 为在两个 pod 中运行的应用程序创建服务
+
+1. 在您的集群中运行一个 Hello World 应用：
+
+       ```
+       kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
+       ```
+       
+<!--
+1. List the pods that are running the Hello World application:
+-->
+1. 列出运行 Hello World 应用的 pod：
+
+       ```
+       kubectl get pods --selector="run=load-balancer-example"
+       ```
+
+<!--
+    The output is similar to this:
+-->
+    输出应类似于：
+
+       ```
+       NAME                           READY     STATUS    RESTARTS   AGE
+       hello-world-2189936611-8fyp0   1/1       Running   0          6m
+       hello-world-2189936611-9isq8   1/1       Running   0          6m
+       ```
+
+<!--
+1. Create a Service object that exposes the deployment:
+-->
+1. 创建一个服务对象来暴露这个 deployment：
+
+       ```
+       kubectl expose deployment <your-deployment-name> --type=NodePort --name=example-service
+       ```
+
+<!--
+    where `<your-deployment-name>` is the name of your deployment.
+
+1. Display the IP addresses for your service:
+-->
+    这里的 `<your-deployment-name>` 是您的 deployment 的名称。
+
+1. 显示您服务的 IP 地址：
+
+       ```
+       kubectl get services example-service
+       ```
+   
+<!--
+   The output shows the internal IP address and the external IP address of
+   your service. If the external IP address shows as `<pending>`, repeat the
+   command.
+-->
+   输出展示了您服务的内部和外部 IP 地址。如果外部 IP 地址显示 `<pending>`，那么您需要重复运行以上命令。
+
+   {{< note >}}
+<!--
+   **Note:** If you are using Minikube, you don't get an external IP address. The
+   external IP address remains in the pending state.
+-->
+   **注意：** 如果您使用 Minikube，那么您将不会获得外部 IP 地址。外部 IP 地址将保持 pending 状态。
+   {{< /note >}}
+
+       NAME              CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+       example-service   10.0.0.160   <pending>     8080/TCP   40s
+
+<!--
+1. Use your Service object to access the Hello World application:
+-->
+1. 使用您的服务对象来访问这个 Hello World 应用：
+
+       curl <your-external-ip-address>:8080
+
+<!--
+   where `<your-external-ip-address>` is the external IP address of your
+   service.
+
+   The output is a hello message from the application:
+-->
+   这里的 `<your-external-ip-address>` 是您服务的外部 IP 地址。
+
+   输出是来自应用的 hello 消息：
+
+       Hello Kubernetes!
+
+   {{< note >}}
+<!--
+   **Note:** If you are using Minikube, enter these commands:
+-->
+   **注意：** 如果您使用 Minikube，输入以下命令：
+   {{< /note >}}
+
+       kubectl cluster-info
+       kubectl describe services example-service
+
+<!--
+   The output displays the IP address of your Minikube node and the NodePort
+   value for your service. Then enter this command to access the Hello World
+   application:
+-->
+   输出将展示您的 Minikube 节点的 IP 地址和您服务的 NodePort 值。然后输入以下命令来访问这个 Hello World 应用：
+
+       curl <minikube-node-ip-address>:<service-node-port>
+
+<!--
+   where `<minikube-node-ip-address>` us the IP address of your Minikube node,
+   and `<service-node-port>` is the NodePort value for your service.
+-->
+   这里的 `<minikube-node-ip-address>` 是您的 Minikube 节点的 IP 地址，`<service-node-port>` 是您服务的 NodePort 值。
+
+<!--
+## Using a service configuration file
+
+As an alternative to using `kubectl expose`, you can use a
+[service configuration file](/docs/concepts/services-networking/service/)
+to create a Service.
+-->
+## 使用服务配置文件
+
+作为 `kubectl expose` 的替代方法，您可以使用 [服务配置文件](/docs/concepts/services-networking/service/) 来创建服务。
+
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+
+<!--
+Learn more about
+[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
+-->
+学习更多关于如何 [通过服务连接应用](/docs/concepts/services-networking/connect-applications-service/)。
+{{% /capture %}}
+
+
+
diff --git a/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
new file mode 100644
index 0000000000000..6bccf05cda7d5
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -0,0 +1,222 @@
+<!--
+---
+title: Use Port Forwarding to Access Applications in a Cluster
+content_template: templates/task
+weight: 40
+---
+-->
+---
+title: 使用端口转发来访问集群中的应用
+content_template: templates/task
+weight: 40
+---
+
+{{% capture overview %}}
+
+<!--
+This page shows how to use `kubectl port-forward` to connect to a Redis
+server running in a Kubernetes cluster. This type of connection can be useful
+for database debugging.
+-->
+本文展示如何使用 `kubectl port-forward` 连接到在 Kubernetes 集群中运行的 Redis 服务。这种类型的连接对数据库调试很有用。
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!--
+* Install [redis-cli](http://redis.io/topics/rediscli).
+-->
+* 安装 [redis-cli](http://redis.io/topics/rediscli)。
+
+{{% /capture %}}
+
+
+{{% capture steps %}}
+
+<!--
+## Creating Redis deployment and service
+
+1. Create a Redis deployment:
+-->
+## 创建 Redis deployment 和服务
+
+1. 创建一个 Redis deployment：
+
+       kubectl create -f https://k8s.io/docs/tutorials/stateless-application/guestbook/redis-master-deployment.yaml
+
+<!--
+    The output of a successful command verifies that the deployment was created:
+-->
+    查看输出是否成功，以验证是否成功创建 deployment：
+
+        deployment "redis-master" created
+ 
+<!--
+    When the pod is ready, you can get:
+-->
+    当 pod 是 ready 时，您将得到：
+       
+       kubectl get pods
+
+        NAME                            READY     STATUS    RESTARTS   AGE
+        redis-master-765d459796-258hz   1/1       Running   0          50s
+
+       kubectl get deployment
+       
+        NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+        redis-master 1         1         1            1           55s
+
+       kubectl get rs
+       
+        NAME                      DESIRED   CURRENT   READY     AGE
+        redis-master-765d459796   1         1         1         1m
+
+
+<!--
+2. Create a Redis service:
+-->
+2. 创建一个 Redis 服务：
+
+       kubectl create -f https://k8s.io/docs/tutorials/stateless-application/guestbook/redis-master-service.yaml
+
+<!--
+    The output of a successful command verifies that the service was created:
+-->
+    查看输出是否成功，以验证是否成功创建服务：
+
+        service "redis-master" created
+
+<!--
+    Check the service created:
+-->
+    检查服务是否创建：
+
+       kubectl get svc | grep redis
+
+        NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+        redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+
+<!--
+3. Verify that the Redis server is running in the pod and listening on port 6379:
+-->
+3. 验证 Redis 服务是否运行在 pod 中并且监听 6379 端口：
+
+        
+       kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+        
+
+<!--
+    The output displays the port:
+-->
+    输出应该显示端口：
+
+        6379
+
+
+<!--
+## Forward a local port to a port on the pod
+
+1.  `kubectl port-forward` allows using resource name, such as a service name, to select a matching pod to port forward to since Kubernetes v1.10.
+-->
+## 转发一个本地端口到 pod 端口
+
+1. 从 Kubernetes v1.10 开始，`kubectl port-forward` 允许使用资源名称（例如服务名称）来选择匹配的 pod 来进行端口转发。
+
+        kubectl port-forward redis-master-765d459796-258hz 6379:6379 
+
+<!--
+    which is the same as
+-->
+    这相当于
+
+        kubectl port-forward pods/redis-master-765d459796-258hz 6379:6379
+
+<!--
+    or  
+-->
+    或者
+
+        kubectl port-forward deployment/redis-master 6379:6379 
+
+<!--
+    or
+-->
+    或者
+
+        kubectl port-forward rs/redis-master 6379:6379 
+
+<!--
+    or
+-->
+    或者
+
+        kubectl port-forward svc/redis-master 6379:6379
+
+<!--
+    Any of the above commands works. The output is similar to this:
+-->
+    以上所有命令都应该有效。输出应该类似于：
+
+        I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
+        I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379
+
+<!--
+2.  Start the Redis command line interface:
+-->
+2. 启动 Redis 命令行接口：
+
+        redis-cli
+
+<!--
+3.  At the Redis command line prompt, enter the `ping` command:
+-->
+3. 在 Redis 命令行提示符下，输入 `ping` 命令：
+
+        127.0.0.1:6379>ping
+
+<!--
+    A successful ping request returns PONG.
+-->
+    成功的 ping 请求应该返回 PONG。
+
+{{% /capture %}}
+
+
+{{% capture discussion %}}
+
+<!--
+## Discussion
+
+Connections made to local port 6379 are forwarded to port 6379 of the pod that
+is running the Redis server. With this connection in place you can use your
+local workstation to debug the database that is running in the pod.
+-->
+## 讨论
+
+与本地 6379 端口建立的连接将转发到运行 Redis 服务器的 pod 的 6379 端口。通过此连接，您可以使用本地工作站来调试在 pod 中运行的数据库。
+
+{{< warning >}}
+<!--
+**Warning**: Due to known limitations, port forward today only works for TCP protocol.
+The support to UDP protocol is being tracked in
+[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
+-->
+**警告：** 由于已知的限制，目前的端口转发仅适用于 TCP 协议。
+在 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862) 中正在跟踪对 UDP 协议的支持。
+{{< /warning >}}
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+<!--
+Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
+-->
+学习更多关于 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)。
+{{% /capture %}}
+
+
+
diff --git a/content/cn/docs/tasks/access-application-cluster/redis-master.yaml b/content/zh/docs/tasks/access-application-cluster/redis-master.yaml
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/redis-master.yaml
rename to content/zh/docs/tasks/access-application-cluster/redis-master.yaml
diff --git a/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
new file mode 100644
index 0000000000000..908280e29d3d4
--- /dev/null
+++ b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -0,0 +1,225 @@
+<!--
+---
+title: Use a Service to Access an Application in a Cluster
+content_template: templates/tutorial
+weight: 60
+---
+-->
+---
+title: 使用服务来访问集群中的应用
+content_template: templates/tutorial
+weight: 60
+---
+
+{{% capture overview %}}
+
+<!--
+This page shows how to create a Kubernetes Service object that external
+clients can use to access an application running in a cluster. The Service
+provides load balancing for an application that has two running instances.
+-->
+本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。该服务为一个应用的两个运行实例提供负载均衡。
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+
+{{% capture objectives %}}
+
+<!--
+* Run two instances of a Hello World application.
+* Create a Service object that exposes a node port.
+* Use the Service object to access the running application.
+-->
+* 运行 Hello World 应用的两个实例。
+* 创建一个服务对象来暴露一个 node port。
+* 使用服务对象来访问正在运行的应用。
+
+{{% /capture %}}
+
+
+{{% capture lessoncontent %}}
+
+<!--
+## Creating a service for an application running in two pods
+
+1. Run a Hello World application in your cluster:
+-->
+## 为运行在两个 pod 中的应用创建一个服务：
+
+1. 在您的集群中运行一个 Hello World 应用：
+   ```shell
+   kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
+   ```   
+<!--
+    The preceding command creates a
+    [Deployment](/docs/concepts/workloads/controllers/deployment/)
+    object and an associated
+    [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
+    object. The ReplicaSet has two
+    [Pods](/docs/concepts/workloads/pods/pod/),
+    each of which runs the Hello World application.
+-->
+    上面的命令创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) 对象和一个关联的 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 对象。这个 ReplicaSet 有两个 [Pod](/docs/concepts/workloads/pods/pod/)，每个 Pod 都运行着 Hello World 应用。
+
+<!--
+1. Display information about the Deployment:
+-->
+1. 展示 Deployment 的信息：
+   ```shell
+   kubectl get deployments hello-world
+   kubectl describe deployments hello-world
+   ```
+
+<!--
+1. Display information about your ReplicaSet objects:
+-->
+1. 展示您的 ReplicaSet 对象信息：
+   ```shell
+   kubectl get replicasets
+   kubectl describe replicasets
+   ```
+
+<!--
+1. Create a Service object that exposes the deployment:
+-->
+1. 创建一个服务对象来暴露 deployment：
+   ```shell
+   kubectl expose deployment hello-world --type=NodePort --name=example-service
+   ```
+
+<!--
+1. Display information about the Service:
+-->
+1. 展示服务信息：
+   ```shell
+   kubectl describe services example-service
+   ```
+<!--
+   The output is similar to this:
+-->
+   输出类似于：
+   ```shell
+   Name:                   example-service
+   Namespace:              default
+   Labels:                 run=load-balancer-example
+   Annotations:            <none>
+   Selector:               run=load-balancer-example
+   Type:                   NodePort
+   IP:                     10.32.0.16
+   Port:                   <unset> 8080/TCP
+   TargetPort:             8080/TCP
+   NodePort:               <unset> 31496/TCP
+   Endpoints:              10.200.1.4:8080,10.200.2.5:8080
+   Session Affinity:       None
+   Events:                 <none>
+   ```
+<!--
+   Make a note of the NodePort value for the service. For example,
+   in the preceding output, the NodePort value is 31496.
+-->
+   注意服务中的 NodePort 值。例如在上面的输出中，NodePort 是 31496。
+
+<!--
+1. List the pods that are running the Hello World application:
+-->
+1. 列出运行 Hello World 应用的 pod：
+   ```shell
+   kubectl get pods --selector="run=load-balancer-example" --output=wide
+   ```
+<!--
+   The output is similar to this:
+-->
+   输出类似于：
+   ```shell
+   NAME                           READY   STATUS    ...  IP           NODE
+   hello-world-2895499144-bsbk5   1/1     Running   ...  10.200.1.4   worker1
+   hello-world-2895499144-m1pwt   1/1     Running   ...  10.200.2.5   worker2
+   ```
+<!--
+1. Get the public IP address of one of your nodes that is running
+   a Hello World pod. How you get this address depends on how you set
+   up your cluster. For example, if you are using Minikube, you can
+   see the node address by running `kubectl cluster-info`. If you are
+   using Google Compute Engine instances, you can use the
+   `gcloud compute instances list` command to see the public addresses of your
+   nodes.
+
+1. On your chosen node, create a firewall rule that allows TCP traffic
+   on your node port. For example, if your Service has a NodePort value of
+   31568, create a firewall rule that allows TCP traffic on port 31568. Different
+   cloud providers offer different ways of configuring firewall rules.
+
+1. Use the node address and node port to access the Hello World application:
+-->
+1. 获取运行 Hello World 的 pod 的其中一个节点的公共 IP 地址。如何获得此地址取决于您设置集群的方式。
+   例如，如果您使用的是 Minikube，则可以通过运行 `kubectl cluster-info` 来查看节点地址。
+   如果您使用的是 Google Compute Engine 实例，则可以使用 `gcloud compute instances list` 命令查看节点的公共地址。
+
+1. 在您选择的节点上，创建一个防火墙规则以开放 node port 上的 TCP 流量。
+   例如，如果您的服务的 NodePort 值为 31568，请创建一个防火墙规则以允许 31568 端口上的 TCP 流量。
+   不同的云提供商提供了不同方法来配置防火墙规则。
+
+1. 使用节点地址和 node port 来访问 Hello World 应用：
+   ```shell
+   curl http://<public-node-ip>:<node-port>
+   ```
+<!--
+   where `<public-node-ip>` is the public IP address of your node,
+   and `<node-port>` is the NodePort value for your service. The
+   response to a successful request is a hello message:
+-->
+   这里的 `<public-node-ip>` 是您节点的公共 IP 地址，`<node-port>` 是您服务的 NodePort 值。
+   对于请求成功的响应是一个 hello 消息：
+   ```shell
+   Hello Kubernetes!
+   ```
+
+<!--
+## Using a service configuration file
+
+As an alternative to using `kubectl expose`, you can use a
+[service configuration file](/docs/concepts/services-networking/service/)
+to create a Service.
+-->
+## 使用服务配置文件
+
+作为 `kubectl expose` 的替代方法，您可以使用 [服务配置文件](/docs/concepts/services-networking/service/) 来创建服务。
+
+{{% /capture %}}
+
+
+{{% capture cleanup %}}
+
+<!--
+To delete the Service, enter this command:
+-->
+想要删除服务，输入以下命令：
+
+    kubectl delete services example-service
+
+<!--
+To delete the Deployment, the ReplicaSet, and the Pods that are running
+the Hello World application, enter this command:
+-->
+想要删除运行 Hello World 应用的 Deployment、ReplicaSet 和 Pod，输入以下命令：
+
+    kubectl delete deployment hello-world
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+
+<!--
+Learn more about
+[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
+-->
+学习更多关于如何 [通过服务连接应用](/docs/concepts/services-networking/connect-applications-service/)。
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/access-application-cluster/two-container-pod.yaml b/content/zh/docs/tasks/access-application-cluster/two-container-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/access-application-cluster/two-container-pod.yaml
rename to content/zh/docs/tasks/access-application-cluster/two-container-pod.yaml
diff --git a/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
new file mode 100644
index 0000000000000..f7b3fff81a32d
--- /dev/null
+++ b/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
@@ -0,0 +1,112 @@
+<!--
+---
+title: Setup an extension API server
+reviewers:
+- lavalamp
+- cheftako
+- chenopis
+content_template: templates/task
+weight: 15
+---
+-->
+---
+title: 设置一个扩展的 API server
+reviewers:
+- lavalamp
+- cheftako
+- chenopis
+content_template: templates/task
+weight: 15
+---
+
+{{% capture overview %}}
+
+<!--
+Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. 
+-->
+设置一个扩展的 API server 来使用聚合层以让 Kubernetes apiserver 使用其它 API 进行扩展，这些 API 不是核心 Kubernetes API 的一部分。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+<!--
+* You need to have a Kubernetes cluster running.
+* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
+-->
+* 您需要拥有一个运行的 Kubernetes 集群。
+* 您必须 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并且启用 apiserver 的相关参数。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Setup an extension api-server to work with the aggregation layer
+
+The following steps describe how to set up an extension-apiserver *at a high level*. These steps apply regardless if you're using YAML configs or using APIs. An attempt is made to specifically identify any differences between the two. For a concrete example of how they can be implemented using YAML configs, you can look at the [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md) in the Kubernetes repo.
+
+Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
+-->
+## 设置一个扩展的 api-server 来使用聚合层
+
+以下步骤描述如何 *在一个高层次* 设置一个扩展的 apiserver。无论您使用的是 YAML 配置还是使用 API，这些步骤都适用。目前我们正在尝试区分出两者的区别。有关使用 YAML 配置的具体示例，您可以在 Kubernetes 库中查看 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)。
+
+或者，您可以使用现有的第三方解决方案，例如 [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md)，它将生成框架并自动执行以下所有步骤。
+
+<!--
+1. Make sure the APIService API is enabled (check `--runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster.
+1. You may need to make an RBAC rule allowing you to add APIService objects, or get your cluster administrator to make one. (Since API extensions affect the entire cluster, it is not recommended to do testing/development/debug of an API extension in a live cluster.)
+1. Create the Kubernetes namespace you want to run your extension api-service in.
+1. Create/get a CA cert to be used to sign the server cert the extension api-server uses for HTTPS.
+1. Create a server cert/key for the api-server to use for HTTPS. This cert should be signed by the above CA. It should also have a CN of the Kube DNS name. This is derived from the Kubernetes service and be of the form `<service name>.<service name namespace>.svc`
+1. Create a Kubernetes secret with the server cert/key in your namespace.
+1. Create a Kubernetes deployment for the extension api-server and make sure you are loading the secret as a volume. It should contain a reference to a working image of your extension api-server. The deployment should also be in your namespace.
+1. Make sure that your extension-apiserver loads those certs from that volume and that they are used in the HTTPS handshake.
+1. Create a Kubernetes service account in your namespace.
+1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
+1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you just created.
+1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
+1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
+1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
+1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
+-->
+1. 确保启用了 APIService API（检查 `--runtime-config`）。默认应该是启用的，除非被特意关闭了。
+1. 您可能需要制定一个 RBAC 规则，以允许您添加 APIService 对象，或让您的集群管理员创建一个。（由于 API 扩展会影响整个集群，因此不建议在实时集群中对 API 扩展进行测试/开发/调试）
+1. 创建 Kubernetes 命名空间，扩展的 api-service 将运行在该命名空间中。
+1. 创建（或获取）用来签署服务器证书的 CA 证书，扩展 api-server 中将使用该证书做 HTTPS 连接。
+1. 为 api-server 创建一个服务端的证书（或秘钥）以使用 HTTPS。这个证书应该由上述的 CA 签署。同时应该还要有一个 Kube DNS 名称的 CN，这是从 Kubernetes 服务派生而来的，格式为 `<service name>.<service name namespace>.svc`。
+1. 使用命名空间中的证书（或秘钥）创建一个 Kubernetes secret。
+1. 为扩展 api-server 创建一个 Kubernetes deployment，并确保以卷的方式挂载了 secret。它应该包含对扩展 api-server 镜像的引用。Deployment 也应该在同一个命名空间中。
+1. 确保您的扩展 apiserver 从该卷中加载了那些证书，并在 HTTPS 握手过程中使用它们。
+1. 在您的命令空间中创建一个 Kubernetes service account。
+1. 为资源允许的操作创建 Kubernetes 集群角色。
+1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到您刚创建的角色上。
+1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator` 集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。
+1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `extension-apiserver-authentication-reader` 角色。这将让您的扩展 api-server 能够访问 `extension-apiserver-authentication` configmap。
+1. 创建一个 Kubernetes apiservice。上述的 CA 证书应该使用 base64 编码，剥离新行并用作 apiservice 中的 spec.caBundle。这不应该是命名空间化的。如果使用了 [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)，那么只需要传入 PEM 编码的 CA 绑定，因为 base 64 编码已经完成了。
+1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。这意味着一切正常，但您目前还没有创建该资源类型的对象。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+<!--
+* If you haven't already, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
+* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation).
+* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
+-->
+* 如果你还未配置，请 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并启用 apiserver 的相关参数。
+* 高级概述，请参阅 [使用聚合层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation)。
+* 了解如何 [使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。
+
+{{% /capture %}}
+
+
+
diff --git a/content/cn/docs/tasks/administer-cluster/access-cluster-services.md b/content/zh/docs/tasks/administer-cluster/access-cluster-services.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/access-cluster-services.md
rename to content/zh/docs/tasks/administer-cluster/access-cluster-services.md
diff --git a/content/cn/docs/tasks/administer-cluster/apply-resource-quota-limit.md b/content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/apply-resource-quota-limit.md
rename to content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md
diff --git a/content/cn/docs/tasks/administer-cluster/calico-network-policy.md b/content/zh/docs/tasks/administer-cluster/calico-network-policy.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/calico-network-policy.md
rename to content/zh/docs/tasks/administer-cluster/calico-network-policy.md
diff --git a/content/cn/docs/tasks/administer-cluster/change-default-storage-class.md b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/change-default-storage-class.md
rename to content/zh/docs/tasks/administer-cluster/change-default-storage-class.md
diff --git a/content/cn/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
rename to content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
diff --git a/content/cn/docs/tasks/administer-cluster/cluster-management.md b/content/zh/docs/tasks/administer-cluster/cluster-management.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cluster-management.md
rename to content/zh/docs/tasks/administer-cluster/cluster-management.md
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-2.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-3.yaml b/content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-3.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-3.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-4.yaml b/content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-4.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-constraints-pod-4.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-constraints-pod-4.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-constraints-pod.yaml b/content/zh/docs/tasks/administer-cluster/cpu-constraints-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-constraints-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-constraints-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-constraints.yaml b/content/zh/docs/tasks/administer-cluster/cpu-constraints.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-constraints.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-constraints.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-defaults-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/cpu-defaults-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-defaults-pod-2.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-defaults-pod-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml b/content/zh/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-defaults-pod.yaml b/content/zh/docs/tasks/administer-cluster/cpu-defaults-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-defaults-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-defaults-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-defaults.yaml b/content/zh/docs/tasks/administer-cluster/cpu-defaults.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-defaults.yaml
rename to content/zh/docs/tasks/administer-cluster/cpu-defaults.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-management-policies.md b/content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/cpu-management-policies.md
rename to content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
diff --git a/content/cn/docs/tasks/administer-cluster/cpu-memory-limit.md b/content/zh/docs/tasks/administer-cluster/cpu-memory-limit.md
similarity index 99%
rename from content/cn/docs/tasks/administer-cluster/cpu-memory-limit.md
rename to content/zh/docs/tasks/administer-cluster/cpu-memory-limit.md
index d867fc14b720f..3988b9b9c8fd0 100644
--- a/content/cn/docs/tasks/administer-cluster/cpu-memory-limit.md
+++ b/content/zh/docs/tasks/administer-cluster/cpu-memory-limit.md
@@ -195,7 +195,7 @@ spec:
 
 注意到这个 Pod 显式地指定了资源 *limits* 和 *requests*，所以它不会使用该 Namespace 的默认值。
 
-注意：在物理节点上默认安装的 Kubernetes 集群中，CPU 资源的 *limits* 是被强制使用的，该 Kubernetes 集群运行容器，除非管理员在部署 kublet 时使用了如下标志：
+注意：在物理节点上默认安装的 Kubernetes 集群中，CPU 资源的 *limits* 是被强制使用的，该 Kubernetes 集群运行容器，除非管理员在部署 kubelet 时使用了如下标志：
 
 ```shell
 $ kubelet --help
diff --git a/content/cn/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/declare-network-policy.md
rename to content/zh/docs/tasks/administer-cluster/declare-network-policy.md
diff --git a/content/cn/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/dns-custom-nameservers.md
rename to content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
diff --git a/content/cn/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml b/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
rename to content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
diff --git a/content/zh/docs/tasks/administer-cluster/encrypt-data.md b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
new file mode 100644
index 0000000000000..c454ec9945251
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
@@ -0,0 +1,323 @@
+<!--
+---
+reviewers:
+- smarterclayton
+title: Encrypting Secret Data at Rest
+content_template: templates/task
+---
+-->
+---
+reviewers:
+- smarterclayton
+title: 加密静态 Secret 数据
+content_template: templates/task
+---
+
+{{% capture overview %}}
+<!--
+This page shows how to enable and configure encryption of secret data at rest.
+-->
+本文展示如何启用和配置静态 Secret 数据的加密
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!--
+* Kubernetes version 1.7.0 or later is required
+
+* etcd v3 or later is required
+
+* Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
+-->
+* 需要 Kubernetes 1.7.0 或者更高版本
+
+* 需要 etcd v3 或者更高版本
+
+* 静态数据加密在 1.7.0 中仍然是 alpha 版本，这意味着它可能会在没有通知的情况下进行更改。在升级到 1.8.0 之前，用户可能需要解密他们的数据。
+
+{{% /capture %}}
+
+{{< toc >}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Configuration and determining whether encryption at rest is already enabled
+
+The `kube-apiserver` process accepts an argument `--experimental-encryption-provider-config`
+that controls how API data is encrypted in etcd. An example configuration
+is provided below.
+
+## Understanding the encryption at rest configuration.
+-->
+## 配置并确定是否已启用静态数据加密
+
+`kube-apiserver` 的参数 `--experimental-encryption-provider-config` 控制 API 数据在 etcd 中的加密方式。
+下面提供一个配置示例。
+
+## 理解静态数据加密
+
+```yaml
+kind: EncryptionConfig
+apiVersion: v1
+resources:
+  - resources:
+    - secrets
+    providers:
+    - identity: {}
+    - aesgcm:
+        keys:
+        - name: key1
+          secret: c2VjcmV0IGlzIHNlY3VyZQ==
+        - name: key2
+          secret: dGhpcyBpcyBwYXNzd29yZA==
+    - aescbc:
+        keys:
+        - name: key1
+          secret: c2VjcmV0IGlzIHNlY3VyZQ==
+        - name: key2
+          secret: dGhpcyBpcyBwYXNzd29yZA==
+    - secretbox:
+        keys:
+        - name: key1
+          secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
+```
+
+<!--
+Each `resources` array item is a separate config and contains a complete configuration. The
+`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
+that should be encrypted. The `providers` array is an ordered list of the possible encryption
+providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
+but not both in the same item).
+
+The first provider in the list is used to encrypt resources going into storage. When reading
+resources from storage each provider that matches the stored data attempts to decrypt the data in
+order. If no provider can read the stored data due to a mismatch in format or secret key, an error
+is returned which prevents clients from accessing that resource.
+
+**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
+the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
+read that resource will fail until it is deleted or a valid decryption key is provided.
+-->
+每个 `resources` 数组项目是一个单独的完整的配置。 `resources.resources` 字段是要加密的 Kubernetes 资源名称（`resource` 或 `resource.group`）的数组。
+`providers` 数组是可能的加密 provider 的有序列表。每个条目只能指定一个 provider 类型（可以是 `identity` 或 `aescbc`，但不能在同一个项目中同时指定）。
+
+列表中的第一个提供者用于加密进入存储的资源。当从存储器读取资源时，与存储的数据匹配的所有提供者将尝试按顺序解密数据。
+如果由于格式或密钥不匹配而导致提供者无法读取存储的数据，则会返回一个错误，以防止客户端访问该资源。
+
+**重要：** 如果通过加密配置无法读取资源（因为密钥已更改），唯一的方法是直接从基础 etcd 中删除该密钥。任何尝试读取资源的调用将会失败，直到它被删除或提供有效的解密密钥。
+
+### Providers:
+
+<!--
+Name | Encryption | Strength | Speed | Key Length | Other Considerations
+-----|------------|----------|-------|------------|---------------------
+`identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
+`aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`.
+`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
+`aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
+`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes |  The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
+
+Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
+is the first provider, the first key is used for encryption.
+-->
+名称 | 加密类型 | 强度 | 速度 | 密钥长度 | 其它事项
+-----|------------|----------|-------|------------|---------------------
+`identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时，资源将在新值写入时被解密。
+`aescbc` | 填充 PKCS#7 的 AES-CBC | 最强 | 快 | 32字节 | 建议使用的加密项，但可能比 `secretbox` 稍微慢一些。
+`secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准，在需要高度评审的环境中可能不被接受。
+`aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24, 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。
+`kms` | 使用信封加密方案：数据使用带有 PKCS#7 填充的 AES-CBC 通过 data encryption keys（DEK）加密，DEK 根据 Key Management Service（KMS）中的配置通过 key encryption keys（KEK）加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK，并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/docs/tasks/administer-cluster/kms-provider/)
+
+每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。
+
+<!--
+## Encrypting your data
+
+Create a new encryption config file:
+-->
+## 加密您的数据
+
+创建一个新的加密配置文件：
+
+```yaml
+kind: EncryptionConfig
+apiVersion: v1
+resources:
+  - resources:
+    - secrets
+    providers:
+    - aescbc:
+        keys:
+        - name: key1
+          secret: <BASE 64 ENCODED SECRET>
+    - identity: {}
+```
+
+<!--
+To create a new secret perform the following steps:
+
+1. Generate a 32 byte random key and base64 encode it. If you're on Linux or Mac OS X, run the following command:
+-->
+遵循如下步骤来创建一个新的 secret：
+
+1. 生成一个 32 字节的随机密钥并进行 base64 编码。如果您在 Linux 或 Mac OS X 上，请运行以下命令：
+
+    ```
+    head -c 32 /dev/urandom | base64
+    ```
+
+<!--
+2. Place that value in the secret field.
+3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
+4. Restart your API server.
+
+**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
+-->
+2. 将这个值放入到 secret 字段中。
+3. 设置 `kube-apiserver` 的 `--experimental-encryption-provider-config` 参数，将其指定到配置文件所在位置。
+4. 重启您的 API server。
+
+**重要：** 您的配置文件包含可以解密 etcd 内容的密钥，因此您必须正确限制主设备的权限，以便只有能运行 kube-apiserver 的用户才能读取它。
+
+
+<!--
+## Verifying that data is encrypted
+
+Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or
+updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line
+program to retrieve the contents of your secret.
+
+1. Create a new secret called `secret1` in the `default` namespace:
+-->
+## 验证数据是否被加密
+
+数据在写入 etcd 时会被加密。重新启动你的 `kube-apiserver` 后，任何新创建或更新的密码在存储时都应该被加密。
+如果想要检查，你可以使用 `etcdctl` 命令行程序来检索你的加密内容。
+
+1. 创建一个新的 secret，名称为 `secret1`，命名空间为 `default`：
+
+    ```
+    kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
+    ```
+
+<!--
+2. Using the etcdctl commandline, read that secret out of etcd:
+-->
+2. 使用 etcdctl 命令行，从 etcd 中读取 secret：
+
+    ```
+    ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
+    ```
+
+<!--
+    where `[...]` must be the additional arguments for connecting to the etcd server.
+3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
+4. Verify the secret is correctly decrypted when retrieved via the API:
+-->
+    这里的 `[...]` 是用来连接 etcd 服务的额外参数。
+3. 验证存储的密钥前缀是否为 `k8s:enc:aescbc:v1:`，这表明 `aescbc` provider 已加密结果数据。
+4. 通过 API 检索，验证 secret 是否被正确解密：
+
+    ```
+    kubectl describe secret secret1 -n default
+    ```
+
+<!--
+    should match `mykey: mydata`
+-->
+    必须匹配 `mykey: mydata`
+
+
+<!--
+## Ensure all secrets are encrypted
+
+Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
+-->
+## 确保所有 secret 都被加密
+
+由于 secret 是在写入时被加密，因此对 secret 执行更新也会加密该内容。
+
+```
+kubectl get secrets --all-namespaces -o json | kubectl replace -f -
+```
+
+<!--
+The command above reads all secrets and then updates them to apply server side encryption.
+If an error occurs due to a conflicting write, retry the command.
+For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
+-->
+上面的命令读取所有 secret，然后使用服务端加密来进行更新。
+如果由于冲突写入而发生错误，请重试该命令。
+对于较大的集群，您可能希望通过命名空间或更新脚本来分割 secret。
+
+
+<!--
+## Rotating a decryption key
+
+Changing the secret without incurring downtime requires a multi step operation, especially in
+the presence of a highly available deployment where multiple `kube-apiserver` processes are running.
+
+1. Generate a new key and add it as the second key entry for the current provider on all servers
+2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
+3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
+4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
+5. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
+6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets
+
+With a single `kube-apiserver`, step 2 may be skipped.
+-->
+## 回滚解密密钥
+
+在不发生停机的情况下更改 secret 需要多步操作，特别是在有多个 `kube-apiserver` 进程正在运行的高可用部署的情况下。
+
+1. 生成一个新密钥并将其添加为所有服务器上当前提供程序的第二个密钥条目
+2. 重新启动所有 `kube-apiserver` 进程以确保每台服务器都可以使用新密钥进行解密
+3. 将新密钥设置为 `keys` 数组中的第一个条目，以便在配置中使用其进行加密
+4. 重新启动所有 `kube-apiserver` 进程以确保每个服务器现在都使用新密钥进行加密
+5. 运行 `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` 以用新密钥加密所有现有的秘密
+6. 在使用新密钥备份 etcd 后，从配置中删除旧的解密密钥并更新所有密钥
+
+如果只有一个 `kube-apiserver`，第 2 步可能可以忽略。
+
+
+<!--
+## Decrypting all data
+
+To disable encryption at rest place the `identity` provider as the first entry in the config:
+-->
+## 解密所有数据
+
+要禁用 rest 加密，请将 `identity` provider 作为配置中的第一个条目：
+
+```yaml
+kind: EncryptionConfig
+apiVersion: v1
+resources:
+  - resources:
+    - secrets
+    providers:
+    - identity: {}
+    - aescbc:
+        keys:
+        - name: key1
+          secret: <BASE 64 ENCODED SECRET>
+```
+
+<!--
+and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -`
+to force all secrets to be decrypted.
+-->
+并重新启动所有 `kube-apiserver` 进程。然后运行命令 `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` 强制解密所有 secret。
+
+{{% /capture %}}
+
+
diff --git a/content/cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
rename to content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md
new file mode 100644
index 0000000000000..56dae7aa976a8
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md
@@ -0,0 +1,453 @@
+---
+reviewers:
+- pipejakob
+- luxas
+- roberthbailey
+- jbeda
+title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级 
+content_template: templates/task
+---
+
+<!--
+
+---
+reviewers:
+- pipejakob
+- luxas
+- roberthbailey
+- jbeda
+title: Upgrading/downgrading kubeadm clusters between v1.8 to v1.9
+content_template: templates/task
+---
+
+--->
+
+{{% capture overview %}}
+
+<!--
+
+This guide is for upgrading `kubeadm` clusters from version 1.8.x to 1.9.x, as well as 1.8.x to 1.8.y and 1.9.x to 1.9.y where `y > x`.
+See also [upgrading kubeadm clusters from 1.7 to 1.8](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/) if you're on a 1.7 cluster currently.
+
+--->
+本文主要描述如何将 `kubeadm` 集群从 1.8.x 版本升级到 1.9.x 版本，包括从 1.8.x 版本升级到 1.8.y 版本，和从版本 1.9.x 版本到 1.9.y 版本（`y > x`）。
+如果您目前安装的是集群是 1.7 版本，也可以查看[ kubeadm clusters 集群从 1.7 版本升级到 1.8 版本](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+<!--
+
+Before proceeding:
+
+- You need to have a functional `kubeadm` Kubernetes cluster running version 1.8.0 or higher in order to use the process described here. Swap also needs to be disabled.
+- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md) carefully.
+- `kubeadm upgrade` now allows you to upgrade etcd. `kubeadm upgrade` will also upgrade of etcd to 3.1.10 as part of upgrading from v1.8 to v1.9 by default. This is due to the fact that etcd 3.1.10 is the officially validated etcd version for Kubernetes v1.9. The upgrade is handled automatically by kubeadm for you.
+- Note that `kubeadm upgrade` will not touch any of your workloads, only Kubernetes-internal components. As a best-practice you should back up what's important to you. For example, any app-level state, such as a database an app might depend on (like MySQL or MongoDB) must be backed up beforehand.
+
+--->
+升级之前：
+
+- 您需要先安装一个版本为 1.8.0 或更高版本的 `kubeadm` Kubernetes 集群。另外还需要禁用节点的交换分区。
+- 一定要认真阅读[发布说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md)
+- `kubeadm upgrade` 可以更新 etcd。默认情况下，从 Kubernetes 1.8 版本升级到 1.9 版本时，`kubeadm upgrade` 也会升级 etcd 到 3.1.10 版本。这是由于 etcd3.1.10 是官方验证的 etcd 版本对于 kubernetes1.9。kubeadm 为您提供了自动化的升级过程。
+- 请注意，`kubeadm upgrade`命令 不会触及任何工作负载，只有 kubernetes 内部组件。作为最佳实践，您应当备份，因为备份相当的重要。例如，任何应用程序级别的状态（如应用程序可能依赖的数据库，如 mysql 或 mongoDB）必须预先备份。
+{{< caution >}}
+<!--
+
+**Caution:** All the containers will get restarted after the upgrade, due to container spec hash value gets changed.
+
+--->
+**注意:** 由于容器的具体哈希值改变了，所有的容器在升级之后会重新启动。
+
+{{< /caution >}}
+
+<!--
+
+Also, note that only one minor version upgrade is supported. For example, you can only upgrade from 1.8 to 1.9, not from 1.7 to 1.9.
+
+--->
+同时，也要注意只有小范围的升级是支持的。例如，您只可以从 1.8 版本升级到 1.9 版本，但是不能从 1.7 版本升级到 1.9 版本。
+
+
+{{% /capture %}}
+
+{{% capture steps %}}
+<!--
+
+## Upgrading your control plane
+
+-->
+## 升级控制面板
+<!--
+
+Execute these commands on your master node:
+
+1. Install the most recent version of `kubeadm` using `curl` like so:
+
+-->
+在您的 master 节点上执行这些命令：
+
+1. 使用 `curl` 命令进行安装最新的版本的 `kubeadm` ，例如：
+```shell
+export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
+export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
+curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
+chmod a+rx /usr/bin/kubeadm
+```
+
+{{< caution >}}
+<!--
+
+**Caution:** Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade. 
+Even though `kubeadm` ships in the Kubernetes repositories, it's important to install `kubeadm` manually. The kubeadm 
+team is working on fixing this limitation. 
+
+--->
+**注意:** 在您的系统上升级控制面板之前升级 `kubeadm` 包会导致升级失败。
+尽管 `kubeadm` ships 在 kubernetes 仓库中，手动安装 `kubeadm` 是重要的。kubeadm 团队在努力解决这种手动安装的限制。
+{{< /caution >}}
+<!--
+
+Verify that this download of kubeadm works and has the expected version:
+
+--->
+验证 kubeadm 下载工作是否正常，并是否有达到预期的版本：
+```shell
+kubeadm version
+```
+<!--
+
+2. On the master node, run the following:
+
+--->
+2. 在master节点上运行如下命令：
+```shell
+kubeadm upgrade plan
+```
+<!--
+
+You should see output similar to this:
+
+--->
+可以得到类型的结果：
+<!--
+
+```shell
+[preflight] Running pre-flight checks
+[upgrade] Making sure the cluster is healthy:
+[upgrade/health] Checking API Server health: Healthy
+[upgrade/health] Checking Node health: All Nodes are healthy
+[upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
+[upgrade/config] Making sure the configuration is correct:
+[upgrade/config] Reading configuration from the cluster...
+[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
+[upgrade] Fetching available versions to upgrade to:
+[upgrade/versions] Cluster version: v1.8.1
+[upgrade/versions] kubeadm version: v1.9.0
+[upgrade/versions] Latest stable version: v1.9.0
+[upgrade/versions] Latest version in the v1.8 series: v1.8.6
+
+Components that must be upgraded manually after you've upgraded the control plane with 'kubeadm upgrade apply':
+
+COMPONENT   CURRENT      AVAILABLE
+Kubelet     1 x v1.8.1   v1.8.6
+
+Upgrade to the latest version in the v1.8 series:
+
+COMPONENT            CURRENT   AVAILABLE
+API Server           v1.8.1    v1.8.6
+Controller Manager   v1.8.1    v1.8.6
+Scheduler            v1.8.1    v1.8.6
+Kube Proxy           v1.8.1    v1.8.6
+Kube DNS             1.14.4    1.14.5
+
+You can now apply the upgrade by executing the following command:
+
+    kubeadm upgrade apply v1.8.6
+
+    _____________________________________________________________________
+
+    Components that must be upgraded manually after you've upgraded the control plane with 'kubeadm upgrade apply':
+
+    COMPONENT   CURRENT      AVAILABLE
+    Kubelet     1 x v1.8.1   v1.9.0
+
+    Upgrade to the latest stable version:
+
+    COMPONENT            CURRENT   AVAILABLE
+    API Server           v1.8.1    v1.9.0
+    Controller Manager   v1.8.1    v1.9.0
+    Scheduler            v1.8.1    v1.9.0
+    Kube Proxy           v1.8.1    v1.9.0
+    Kube DNS             1.14.5    1.14.7
+
+    You can now apply the upgrade by executing the following command:
+
+        kubeadm upgrade apply v1.9.0
+
+        Note: Before you do can perform this upgrade, you have to update kubeadm to v1.9.0
+
+_____________________________________________________________________
+```
+         
+--->
+
+  ```shell
+ [preflight] Running pre-flight checks
+ [upgrade] Making sure the cluster is healthy:
+ [upgrade/health] Checking API Server health: Healthy
+ [upgrade/health] Checking Node health: All Nodes are healthy
+ [upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
+ [upgrade/config] Making sure the configuration is correct:
+ [upgrade/config] Reading configuration from the cluster...
+ [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
+ [upgrade] Fetching available versions to upgrade to:
+ [upgrade/versions] Cluster version: v1.8.1
+ [upgrade/versions] kubeadm version: v1.9.0
+ [upgrade/versions] Latest stable version: v1.9.0
+ [upgrade/versions] Latest version in the v1.8 series: v1.8.6
+
+   在升级控制面板并使用 'kubeadm upgrade apply' 后，必须手动升级组件：
+    COMPONENT   CURRENT      AVAILABLE
+     Kubelet     1 x v1.8.1   v1.8.6
+
+    升级到最新的 v1.8 系列的版本：
+    COMPONENT            CURRENT   AVAILABLE
+    API Server           v1.8.1    v1.8.6
+    Controller Manager   v1.8.1    v1.8.6
+    Scheduler            v1.8.1    v1.8.6
+    Kube Proxy           v1.8.1    v1.8.6
+    Kube DNS             1.14.4    1.14.5
+
+    您可以通过以下的命令来进行升级：
+      kubeadm upgrade apply v1.8.6
+
+    _____________________________________________________________________
+
+    在升级控制面板并使用 'kubeadm upgrade apply' 后，必须手动升级组件：
+    COMPONENT   CURRENT      AVAILABLE
+    Kubelet     1 x v1.8.1   v1.9.0
+
+    升级到最新和稳定的版本：
+    COMPONENT            CURRENT   AVAILABLE
+    API Server           v1.8.1    v1.9.0
+    Controller Manager   v1.8.1    v1.9.0
+    Scheduler            v1.8.1    v1.9.0
+    Kube Proxy           v1.8.1    v1.9.0
+    Kube DNS             1.14.5    1.14.7
+
+    您可以通过以下命令来进行升级：
+    kubeadm upgrade apply v1.9.0
+
+    请注意：在您执行升级之前，您必须升级 kubeadm 到 v1.9.0 版本
+_____________________________________________________________________
+```
+                 
+<!--
+
+The `kubeadm upgrade plan` checks that your cluster is upgradeable and fetches the versions available to upgrade to in an user-friendly way.
+
+To check CoreDNS version, include the `--feature-gates=CoreDNS=true` flag to verify the CoreDNS version which will be installed in place of kube-dns.
+
+3. Pick a version to upgrade to and run. For example:
+
+--->
+`kubeadm upgrade plan` 命令检查您的集群是否处于可升级的状态并且获取可以以用户友好方式升级的版本。
+
+检查 coreDNS 版本，包括 `--feature-gates=CoreDNS=true` 标志来验证存放 kube-dns 在某个位置的 coreDNS 版本。
+
+3. 选择一个版本来进行升级和运行，例如：
+```shell
+kubeadm upgrade apply v1.9.0
+```
+<!--
+
+You should see output similar to this:
+
+--->
+可以得到如下类似的输出：
+```shell
+[preflight] Running pre-flight checks.
+[upgrade] Making sure the cluster is healthy:
+[upgrade/config] Making sure the configuration is correct:
+[upgrade/config] Reading configuration from the cluster...
+[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
+[upgrade/version] You have chosen to upgrade to version "v1.9.0"
+[upgrade/versions] Cluster version: v1.8.1
+[upgrade/versions] kubeadm version: v1.9.0
+[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
+[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
+[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.9.0"...
+[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/etcd.yaml"
+[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/etcd.yaml"
+[upgrade/staticpods] Waiting for the kubelet to restart the component
+[apiclient] Found 1 Pods for label selector component=etcd
+[upgrade/staticpods] Component "etcd" upgraded successfully!
+[upgrade/staticpods] Writing upgraded Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804"
+[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-apiserver.yaml"
+[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-controller-manager.yaml"
+[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-scheduler.yaml"
+[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-apiserver.yaml"
+[upgrade/staticpods] Waiting for the kubelet to restart the component
+[apiclient] Found 1 Pods for label selector component=kube-apiserver
+[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
+[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-controller-manager.yaml"
+[upgrade/staticpods] Waiting for the kubelet to restart the component
+[apiclient] Found 1 Pods for label selector component=kube-controller-manager
+[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
+[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-scheduler.yaml"
+[upgrade/staticpods] Waiting for the kubelet to restart the component
+[apiclient] Found 1 Pods for label selector component=kube-scheduler
+[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
+[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
+[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
+[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
+[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
+[addons] Applied essential addon: kube-dns
+[addons] Applied essential addon: kube-proxy
+
+[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.9.0". Enjoy!
+
+[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets in turn.
+```
+<!--
+
+To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm upgrade apply` with the `--feature-gates=CoreDNS=true` flag.
+`kubeadm upgrade apply` does the following:
+
+- Checks that your cluster is in an upgradeable state:
+  - The API server is reachable,
+  - All nodes are in the `Ready` state
+  - The control plane is healthy
+- Enforces the version skew policies.
+- Makes sure the control plane images are available or available to pull to the machine.
+- Upgrades the control plane components or rollbacks if any of them fails to come up.
+- Applies the new `kube-dns` and `kube-proxy` manifests and enforces that all necessary RBAC rules are created.
+- Creates new certificate and key files of apiserver and backs up old files if they're about to expire in 180 days.
+
+--->
+                       
+升级具有默认内部的 DNS 的 coreDNS 集群，调用具有 `--feature-gates=CoreDNS=true` 标记的 `kubeadm upgrade apply`。
+`kubeadm upgrade apply`按照如下进行：
+
+- 检查集群是否处于可升级状态：
+  -API服务器是否可达
+  -所有的节点处于`Ready`状态
+  -控制面板是健康的
+- 强制执行版本倾斜策略
+- 确保控制面板镜像可用或者可用于机器pull
+- 升级控制面板组件或者回滚如果其中一个无法出现
+- 应用新的`kube-dns`和`kube-proxy`清单并强制创建所必须的RBAC规则
+- 创建API服务器新的证书和秘钥文件，并备份旧文件（如果它们即将在180天到期）
+<!--
+
+4. Manually upgrade your Software Defined Network (SDN).
+
+   Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
+   Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional      upgrade steps necessary.
+                                            
+--->
+
+4. 手动升级定义网络（SDN）的软件
+
+   容器网络接口（CNI）提供者具有升级说明指导。
+   检查这个[插件](/docs/concepts/cluster-administration/addons/)页面来找到 CNI 提供者和查看是否需要额外的升级步骤。
+                                                     
+<!--
+
+## Upgrading your master and node packages
+
+--->
+
+## 升级master和node包
+<!--
+For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet` by executing the following commands:
+
+1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:
+--->
+在集群中涉及 `$HOST` 的每个主机，执行如下命令来升级 `kubelet` ：
+
+1. 准备主机维修，并标记为不可调度和驱逐工作负载：
+```shell
+kubectl drain $HOST --ignore-daemonsets
+```
+<!--
+
+When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
+
+--->
+当在 master 主机上运行这个命令，这个错误是可以预料的并且可以忽略（因为静态的 pods 运行在 master 上）
+```shell
+node "master" already cordoned
+error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to override): etcd-kubeadm, kube-apiserver-kubeadm, kube-controller-manager-kubeadm, kube-scheduler-kubeadm
+```
+<!-- 
+
+2. Upgrade the Kubernetes package versions on the `$HOST` node by using a Linux distribution-specific package manager:
+
+If the host is running a Debian-based distro such as Ubuntu, run:
+
+--->
+2.  在 `$HOST` 节点上使用特定的包管理器升级 kubernetes 包版本：
+
+如果主机运行 Debian-based 发行版如 ubuntu，运行如下：
+```shell
+apt-get update
+apt-get upgrade
+```
+<!--
+
+If the host is running CentOS or the like, run:
+
+--->
+如果主机运行centos或者类似，运行如下:
+```shell
+yum update
+```
+<!--
+Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:
+--->
+现在 `kubelet` 新的版本运行在主机上。在` $HOST` 上使用如下命令验证：
+```shell
+systemctl status kubelet
+```
+<!--
+
+3. Bring the host back online by marking it schedulable:
+
+--->
+3. 通过标记可计划的将主机从新联机：
+```shell
+kubectl uncordon $HOST
+```
+<!--
+4. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):
+--->
+在所以主机升级 `kubelet` 后，通过从任意位置运行以下命令例如从集群外来验证所有节点是否可用：
+```shell
+kubectl get nodes
+```
+<!--
+If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
+--->
+如果上面命令的 `STATUS` 列显示所有的主机的 `Ready`，就完成了。
+<!--
+## Recovering from a failure state
+--->
+## ##从坏的状态中恢复
+<!--
+
+If `kubeadm upgrade` somehow fails and fails to roll back, for example due to an unexpected shutdown during execution,
+you can run `kubeadm upgrade` again as it is idempotent and should eventually make sure the actual state is the desired state you are declaring.
+--->
+如果 `kubeadm upgrade` 以某种方式失败了并无法回滚，原因有在执行过程中出现意外关机，可以再次运行 `kubeadm upgrade`，因为它是幂等的，并且最终确保实际状态是期待的状态。
+
+<!--
+You can use `kubeadm upgrade` to change a running cluster with `x.x.x -> x.x.x` with `--force`, which can be used to recover from a bad state.
+--->
+
+可以使用 `kubeadm upgrade` 来更改运行的集群并使用具有  `--force` 参数的 `x.x.x --> x.x.x`，这样可以恢复坏的状态。
+
+{{% /capture %}}
+
+
diff --git a/content/cn/docs/tasks/administer-cluster/kubelet-config-file.md b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/kubelet-config-file.md
rename to content/zh/docs/tasks/administer-cluster/kubelet-config-file.md
diff --git a/content/cn/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-constraints-pod-3.yaml b/content/zh/docs/tasks/administer-cluster/memory-constraints-pod-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-constraints-pod-3.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-constraints-pod-3.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-constraints-pod-4.yaml b/content/zh/docs/tasks/administer-cluster/memory-constraints-pod-4.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-constraints-pod-4.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-constraints-pod-4.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-constraints-pod.yaml b/content/zh/docs/tasks/administer-cluster/memory-constraints-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-constraints-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-constraints-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-constraints.yaml b/content/zh/docs/tasks/administer-cluster/memory-constraints.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-constraints.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-constraints.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml
similarity index 81%
rename from content/cn/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml
index aa80610d84492..1013293eddeba 100644
--- a/content/cn/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml
+++ b/content/zh/docs/tasks/administer-cluster/memory-defaults-pod-2.yaml
@@ -4,7 +4,7 @@ metadata:
   name: default-mem-demo-2
 spec:
   containers:
-  - name: default-mem-demo-2-ctr
+  - name: defalt-mem-demo-2-ctr
     image: nginx
     resources:
       limits:
diff --git a/content/cn/docs/tasks/administer-cluster/memory-defaults-pod-3.yaml b/content/zh/docs/tasks/administer-cluster/memory-defaults-pod-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-defaults-pod-3.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-defaults-pod-3.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-defaults-pod.yaml b/content/zh/docs/tasks/administer-cluster/memory-defaults-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-defaults-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-defaults-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/memory-defaults.yaml b/content/zh/docs/tasks/administer-cluster/memory-defaults.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/memory-defaults.yaml
rename to content/zh/docs/tasks/administer-cluster/memory-defaults.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/my-scheduler.yaml b/content/zh/docs/tasks/administer-cluster/my-scheduler.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/my-scheduler.yaml
rename to content/zh/docs/tasks/administer-cluster/my-scheduler.yaml
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
new file mode 100644
index 0000000000000..78d0d8e675381
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
@@ -0,0 +1,86 @@
+---
+reviewers:
+- caseydavenport
+title: 使用 Calico 作为 NetworkPolicy
+content_template: templates/task
+weight: 10
+---
+
+{{% capture overview %}}
+<!-- This page shows a couple of quick ways to create a Calico cluster on Kubernetes. -->
+本页展示了两种在 Kubernetes 上快速创建 Calico 集群的方法。
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+<!-- Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster. -->
+
+决定您想部署一个[云](#在-Google-Kubernetes-Engine-GKE-上创建一个-Calico-集群) 还是 [本地](#使用-kubeadm-创建一个本地-Calico-集群) 集群。
+{{% /capture %}}
+
+{{% capture steps %}}
+<!-- ## Creating a Calico cluster with Google Kubernetes Engine (GKE)
+
+**Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
+
+1.  To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
+
+    **Syntax**
+    ```shell
+    gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
+    ```
+
+    **Example**
+    ```shell
+    gcloud container clusters create my-calico-cluster --enable-network-policy
+    ```
+
+1.  To verify the deployment, use the following command.
+
+    ```shell
+    kubectl get pods --namespace=kube-system
+    ```
+
+    The Calico pods begin with `calico`. Check to make sure each one has a status of `Running`.
+ -->
+## 在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群
+
+**先决条件**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts)
+
+1.  启动一个带有 Calico 的 GKE 集群，只需加上flag `--enable-network-policy`。
+
+    **语法**
+    ```shell
+    gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
+    ```
+
+    **示例**
+    ```shell
+    gcloud container clusters create my-calico-cluster --enable-network-policy
+    ```
+
+1.  使用如下命令验证部署是否正确。
+
+    ```shell
+    kubectl get pods --namespace=kube-system
+    ```
+
+    Calico 的 pods 名以 `calico` 打头，检查确认每个 pods 状态为 `Running`。
+<!-- 
+## Creating a local Calico cluster with kubeadm
+
+To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the 
+[Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
+ -->
+
+## 使用 kubeadm 创建一个本地 Calico 集群
+
+在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考 
+[Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+<!-- Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
+集群运行后，您可以按照 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
+{{% /capture %}}
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
new file mode 100644
index 0000000000000..61be3718b35ed
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -0,0 +1,133 @@
+---
+reviewers:
+- danwent
+title: 使用 Cilium 作为 NetworkPolicy
+content_template: templates/task
+weight: 20
+---
+
+{{% capture overview %}}
+<!-- This page shows how to use Cilium for NetworkPolicy.
+
+For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro). -->
+
+本页展示了如何使用 Cilium 作为 NetworkPolicy。
+
+关于 Cilium 的背景知识，请阅读 [Cilium 介绍](https://cilium.readthedocs.io/en/latest/intro)。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+<!-- 
+## Deploying Cilium on Minikube for Basic Testing
+
+To get familiar with Cilium easily you can follow the
+[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
+to perform a basic DaemonSet installation of Cilium in minikube.
+
+Installation in a minikube setup uses a simple ''all-in-one'' YAML
+file that includes DaemonSet configurations for Cilium, to connect
+to the minikube's etcd instance as well as appropriate RBAC settings:
+ -->
+
+## 在 Minikube 上部署 Cilium 用于基本测试
+
+为了轻松熟悉 Cilium 您可以根据[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/latest/gettingstarted/minikube/)在 minikube 中执行一个 cilium 的基本的 DaemonSet 安装。
+
+在 minikube 中的安装配置使用一个简单的“一体化” YAML 文件，包括了 Cilium 的 DaemonSet 配置，连接 minikube 的 etcd 实例，以及适当的 RBAC 设置。
+
+```shell
+$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
+configmap "cilium-config" created
+secret "cilium-etcd-secrets" created
+serviceaccount "cilium" created
+clusterrolebinding "cilium" created
+daemonset "cilium" created
+clusterrole "cilium" created
+```
+<!-- 
+The remainder of the Getting Started Guide explains how to enforce both L3/L4
+(i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
+policies using an example application.
+ -->
+入门指南其余的部分用一个示例应用说明了如何强制执行L3/L4（即 IP 地址+端口）的安全策略以及L7 （如 HTTP）的安全策略。
+
+<!-- 
+## Deploying Cilium for Production Use
+
+For detailed instructions around deploying Cilium for production, see:
+[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
+This documentation includes detailed requirements, instructions and example
+production DaemonSet files.
+ -->
+
+## 部署 Cilium 用于生产用途
+关于部署 Cilium 用于生产的详细说明，请见[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
+，此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+<!-- 
+##  Understanding Cilium components
+
+Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
+this list of Pods run:
+ -->
+##  了解 Cilium 组件
+
+部署使用 Cilium 的集群会添加 Pods 到`kube-system`命名空间。 要查看此Pod列表，运行：
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+
+<!-- You'll see a list of Pods similar to this: -->
+您将看到像这样的 Pods 列表：
+
+```console
+NAME            DESIRED   CURRENT   READY     NODE-SELECTOR   AGE
+cilium          1         1         1         <none>          2m
+...
+```
+<!-- 
+There are two main components to be aware of:
+
+- One `cilium` Pod runs on each node in your cluster and enforces network policy
+on the traffic to/from Pods on that node using Linux BPF.
+- For production deployments, Cilium should leverage the key-value store cluster
+(e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.
+The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
+includes an example DaemonSet which can be customized to point to this key-value
+store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such
+configuration because it automatically connects to the minikube's etcd instance.
+ -->
+有两个主要组件需要注意：
+
+- 在集群中的每个节点上都会运行一个 `cilium` Pod，并利用Linux BPF执行网络策略管理该节点上进出 Pod 的流量。
+- 对于生产部署，Cilium 应该复用 Kubernetes 所使用的键值存储集群（如 etcd），其通常在Kubernetes 的 master 节点上运行。
+[Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
+包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。 
+简单的 minikube 的“一体化” DaemonSet 不需要这样的配置，因为它会自动连接到 minikube 的 etcd 实例。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!-- Once your cluster is running, you can follow the
+[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
+to try out Kubernetes NetworkPolicy with Cilium.
+Have fun, and if you have questions, contact us using the
+[Cilium Slack Channel](https://cilium.herokuapp.com/). -->
+群集运行后，您可以按照[声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/)
+用 Cilium 试用 Kubernetes NetworkPolicy。
+玩得开心，如果您有任何疑问，请联系我们
+[Cilium Slack Channel](https://cilium.herokuapp.com/)。
+
+{{% /capture %}}
+
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
new file mode 100644
index 0000000000000..901184cb25241
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
@@ -0,0 +1,31 @@
+---
+reviewers:
+- murali-reddy
+title: 使用 Kube-router 作为 NetworkPolicy
+content_template: templates/task
+weight: 30
+---
+
+{{% capture overview %}}
+<!-- This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy. -->
+本页展示了如何使用 [Kube-router](https://github.com/cloudnativelabs/kube-router) 作为 NetworkPolicy。
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+<!-- You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc. -->
+
+您需要拥有一个正在运行的 Kubernetes 集群。如果您还没有集群，可以使用任意的集群安装器如 Kops，Bootkube，Kubeadm 等创建一个。
+{{% /capture %}}
+
+{{% capture steps %}}
+<!-- ## Installing Kube-router addon
+The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon. -->
+
+## 安装 Kube-router 插件
+Kube-router 插件自带一个Network Policy 控制器，监视来自于Kubernetes API server 的 NetworkPolicy 和 pods 的变化，根据策略指示配置 iptables 规则和 ipsets 来允许或阻止流量。请根据 [尝试通过集群安装器使用 Kube-router](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 指南安装 Kube-router 插件。
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!-- Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
+在您安装 Kube-router 插件后，可以根据 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
+{{% /capture %}}
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
new file mode 100644
index 0000000000000..5867bfec5c25d
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -0,0 +1,57 @@
+---
+reviewers:
+- chrismarino
+title: 使用 Romana 作为 NetworkPolicy
+content_template: templates/task
+weight: 40
+---
+
+{{% capture overview %}}
+
+<!-- This page shows how to use Romana for NetworkPolicy. -->
+本页展示如何使用 Romana 作为 NetworkPolicy。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+<!-- Complete steps 1, 2, and 3 of  the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -->
+完成[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)中的1、2、3步。
+
+{{% /capture %}}
+
+{{% capture steps %}}
+<!-- 
+## Installing Romana with kubeadm
+
+Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadmin.
+
+## Applying network policies
+
+To apply network policies use one of the following:
+
+* [Romana network policies](https://github.com/romana/romana/wiki/Romana-policies).
+    * [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
+* The NetworkPolicy API.
+ -->
+## 使用 kubeadm 安装 Romana
+
+按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)获取 kubeadmin。
+
+## 运用网络策略
+
+使用以下的一种方式去运用网络策略：
+
+* [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
+    * [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
+* NetworkPolicy API
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!-- 
+Once your have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
+ -->
+Romana 安装完成后，您可以按照[声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 Kubernetes NetworkPolicy。
+
+{{% /capture %}}
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
new file mode 100644
index 0000000000000..26eb7434baed3
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -0,0 +1,78 @@
+---
+reviewers:
+- bboreham
+title: 使用 Weave Net 作为 NetworkPolicy
+content_template: templates/task
+weight: 50
+---
+
+{{% capture overview %}}
+
+<!-- This page shows how to use Weave Net for NetworkPolicy. -->
+
+本页展示了如何使用使用 Weave Net 作为 NetworkPolicy。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+<!-- 
+You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
+ -->
+您需要拥有一个 Kubernetes 集群。按照[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)来引导一个。
+{{% /capture %}}
+
+{{% capture steps %}}
+<!-- 
+## Install the Weave Net addon
+
+Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
+
+The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
+ -->
+## 安装 Weave Net 插件
+
+按照[通过插件集成Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)指南。
+
+Kubernetes 的 Weave Net 插件带有[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，可自动监控 Kubernetes 所有名称空间中的任何 NetworkPolicy 注释。 配置`iptables`规则以允许或阻止策略指示的流量。
+<!-- 
+## Test the installation
+
+Verify that the weave works.
+
+Enter the following command:
+ -->
+
+## 测试安装
+
+验证 weave 是否有效。
+
+输入以下命令：
+
+```shell
+kubectl get po -n kube-system -o wide
+```
+
+<!-- The output is similar to this: -->
+输出类似这样：
+
+```
+NAME                                    READY     STATUS    RESTARTS   AGE       IP              NODE
+weave-net-1t1qg                         2/2       Running   0          9d        192.168.2.10    worknode3
+weave-net-231d7                         2/2       Running   1          7d        10.2.0.17       worknodegpu
+weave-net-7nmwt                         2/2       Running   3          9d        192.168.2.131   masternode
+weave-net-pmw8w                         2/2       Running   0          9d        192.168.2.216   worknode2
+```
+
+<!-- Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.) -->
+每个 Node 都有一个 weave Pod，所有 Pod 都是`Running`和`2/2 READY`。（`2/2`表示每个Pod都有`weave`和`weave-npc`。）
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!-- 
+Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
+ -->
+
+安装Weave Net插件后，您可以按照[声明网络策略](/docs/tasks/administration-cluster/declare-network-policy/)来试用 Kubernetes NetworkPolicy。 如果您有任何疑问，请联系我们[#weave-community on Slack 或 Weave User Group](https://github.com/weaveworks/weave#getting-help)。
+{{% /capture %}}
+
diff --git a/content/cn/docs/tasks/administer-cluster/pod1.yaml b/content/zh/docs/tasks/administer-cluster/pod1.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/pod1.yaml
rename to content/zh/docs/tasks/administer-cluster/pod1.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/pod2.yaml b/content/zh/docs/tasks/administer-cluster/pod2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/pod2.yaml
rename to content/zh/docs/tasks/administer-cluster/pod2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/pod3.yaml b/content/zh/docs/tasks/administer-cluster/pod3.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/pod3.yaml
rename to content/zh/docs/tasks/administer-cluster/pod3.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-mem-cpu.yaml b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-mem-cpu.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-mem-cpu.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-objects-pvc-2.yaml b/content/zh/docs/tasks/administer-cluster/quota-objects-pvc-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-objects-pvc-2.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-objects-pvc-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-objects-pvc.yaml b/content/zh/docs/tasks/administer-cluster/quota-objects-pvc.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-objects-pvc.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-objects-pvc.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-objects.yaml b/content/zh/docs/tasks/administer-cluster/quota-objects.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-objects.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-objects.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-pod-deployment.yaml b/content/zh/docs/tasks/administer-cluster/quota-pod-deployment.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-pod-deployment.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-pod-deployment.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-pod-namespace.md b/content/zh/docs/tasks/administer-cluster/quota-pod-namespace.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-pod-namespace.md
rename to content/zh/docs/tasks/administer-cluster/quota-pod-namespace.md
diff --git a/content/cn/docs/tasks/administer-cluster/quota-pod.yaml b/content/zh/docs/tasks/administer-cluster/quota-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-pod.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-pod.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/quota-pvc-2.yaml b/content/zh/docs/tasks/administer-cluster/quota-pvc-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/quota-pvc-2.yaml
rename to content/zh/docs/tasks/administer-cluster/quota-pvc-2.yaml
diff --git a/content/cn/docs/tasks/administer-cluster/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/romana-network-policy.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/romana-network-policy.md
rename to content/zh/docs/tasks/administer-cluster/romana-network-policy.md
diff --git a/content/cn/docs/tasks/administer-cluster/static-pod.md b/content/zh/docs/tasks/administer-cluster/static-pod.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/static-pod.md
rename to content/zh/docs/tasks/administer-cluster/static-pod.md
diff --git a/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md b/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
new file mode 100644
index 0000000000000..9ca39883f3a5d
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -0,0 +1,329 @@
+---
+title: 在 Kubernetes 集群中使用 sysctl
+reviewers:
+- sttts
+content_template: templates/task
+---
+
+<!--
+
+---
+title: Using sysctls in a Kubernetes Cluster
+reviewers:
+- sttts
+content_template: templates/task
+---
+
+--->
+
+{{% capture overview %}}
+{{< feature-state for_k8s_version="v1.11" state="beta" >}}
+
+<!--
+This document describes how to configure and use kernel parameters within a
+Kubernetes cluster using the sysctl interface.
+--->
+本文档介绍如何通过 sysctl 接口在 Kubernetes 集群中配置和使用内核参数。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Listing all Sysctl Parameters
+--->
+## 获取 Sysctl 的参数列表
+
+<!--
+In Linux, the sysctl interface allows an administrator to modify kernel
+parameters at runtime. Parameters are available via the `/proc/sys/` virtual
+process file system. The parameters cover various subsystems such as:
+--->
+在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/` 虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
+
+<!--
+- kernel (common prefix: `kernel.`)
+- networking (common prefix: `net.`)
+- virtual memory (common prefix: `vm.`)
+- MDADM (common prefix: `dev.`)
+- More subsystems are described in [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
+--->
+- 内核子系统 (通常前缀为: `kernel.`)
+- 网络子系统 (通常前缀为: `net.`)
+- 虚拟内存子系统 (通常前缀为: `vm.`)
+- MDADM 子系统 (通常前缀为: `dev.`)
+- 更多子系统请参见 [内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
+
+<!--
+To get a list of all parameters, you can run
+--->
+若要获取完整的参数列表，请执行以下命令
+
+```shell
+$ sudo sysctl -a
+```
+
+<!--
+## Enabling Unsafe Sysctls
+--->
+## 启用非安全的 Sysctl 参数
+
+<!--
+Sysctls are grouped into _safe_  and _unsafe_ sysctls. In addition to proper
+namespacing a _safe_ sysctl must be properly _isolated_ between pods on the same
+node. This means that setting a _safe_ sysctl for one pod
+--->
+sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod 之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
+
+<!--
+- must not have any influence on any other pod on the node
+- must not allow to harm the node's health
+- must not allow to gain CPU or memory resources outside of the resource limits
+  of a pod.
+--->
+- 必须不能影响到节点上的其他 Pod
+- 必须不能损害节点的健康
+- 必须不允许使用超出 Pod 的资源限制的 CPU 或内存资源。
+
+<!--
+By far, most of the _namespaced_ sysctls are not necessarily considered _safe_.
+The following sysctls are supported in the _safe_ set:
+--->
+至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。以下几种 sysctl 参数是 _安全的_：
+
+- `kernel.shm_rmid_forced`,
+- `net.ipv4.ip_local_port_range`,
+- `net.ipv4.tcp_syncookies`.
+
+{{< note >}}
+<!--
+**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
+--->
+**注意**: 示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
+{{< /note >}}
+
+<!--
+This list will be extended in future Kubernetes versions when the kubelet
+supports better isolation mechanisms.
+--->
+在未来的 Kubernetes 版本中，若kubelet 支持更好的隔离机制，则上述列表中将会列出更多 _安全的_ sysctl 参数。
+
+<!--
+All _safe_ sysctls are enabled by default.
+--->
+所有 _安全的_ sysctl 参数都默认启用。
+
+<!--
+All _unsafe_ sysctls are disabled by default and must be allowed manually by the
+cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
+scheduled, but will fail to launch.
+--->
+所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
+
+<!--
+With the warning above in mind, the cluster admin can allow certain _unsafe_
+sysctls for very special situations like e.g. high-performance or real-time
+application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
+flag of the kubelet, e.g.:
+--->
+参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），才可以启用特定的 _非安全的_ sysctl 参数。如需启用 _非安全的_ sysctl 参数，请您在每个节点上分别设置 kubelet 命令行参数，例如：
+
+```shell
+$ kubelet --allowed-unsafe-sysctls \
+  'kernel.msg*,net.ipv4.route.min_pmtu' ...
+```
+<!--
+For minikube, this can be done via the `extra-config` flag:
+--->
+如果您使用 minikube，可以通过 `extra-config` 参数来配置：
+
+```shell
+$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
+```
+<!--
+Only _namespaced_ sysctls can be enabled this way.
+--->
+只有 _有命名空间的_ sysctl 参数可以通过该方式启用。
+
+<!--
+## Setting Sysctls for a Pod
+--->
+## 设置 Pod 的 Sysctl 参数
+
+<!--
+A number of sysctls are _namespaced_ in today's Linux kernels. This means that
+they can be set independently for each pod on a node. Only namespaced sysctls
+are configurable via the pod securityContext within Kubernetes.
+--->
+目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。 这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。 在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
+
+<!--
+The following sysctls are known to be namespaced. This list could change
+in future versions of the Linux kernel.
+--->
+以下列出有命名空间的 sysctl 参数，在未来的 Linux 内核版本中，此列表可能会发生变化。
+
+- `kernel.shm*`,
+- `kernel.msg*`,
+- `kernel.sem`,
+- `fs.mqueue.*`,
+- `net.*`.
+
+<!--
+Sysctls with no namespace are called _node-level_ sysctls. If you need to set
+them, you must manually configure them on each node's operating system, or by
+using a DaemonSet with privileged containers.
+--->
+没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。 如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，或者通过在 DaemonSet 中运行特权模式容器来配置。
+
+<!--
+Use the pod securityContext to configure namespaced sysctls. The securityContext
+applies to all containers in the same pod.
+--->
+可使用 pod 的 securityContext 来配置有命名空间的 sysctl 参数，securityContext 应用于同一个 pod 中的所有容器。
+
+<!--
+This example uses the pod securityContext to set a safe sysctl
+`kernel.shm_rmid_forced` and two unsafe sysctls `net.ipv4.route.min_pmtu` and
+`kernel.msgmax` There is no distinction between _safe_ and _unsafe_ sysctls in
+the specification.
+--->
+此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数 `kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数 `net.ipv4.route.min_pmtu`和 `kernel.msgmax` 进行设置。在 Pod 规格中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
+
+{{< warning >}}
+<!--
+Only modify sysctl parameters after you understand their effects, to avoid
+destabilizing your operating system.
+--->
+为了避免破坏操作系统的稳定性，请您在了解变更后果之后再修改 sysctl 参数。
+{{< /warning >}}
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: sysctl-example
+spec:
+  securityContext:
+    sysctls:
+    - name: kernel.shm_rmid_forced
+      value: "0"
+    - name: net.ipv4.route.min_pmtu
+      value: "552"
+    - name: kernel.msgmax
+      value: "65536"
+  ...
+```
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+{{< warning >}}
+<!--
+**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
+is at-your-own-risk and can lead to severe problems like wrong behavior of
+containers, resource shortage or complete breakage of a node.
+--->
+**警告**：由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，用户需自行承担风险。
+{{< /warning >}}
+
+<!--
+It is good practice to consider nodes with special sysctl settings as
+_tainted_ within a cluster, and only schedule pods onto them which need those
+sysctl settings. It is suggested to use the Kubernetes [_taints and toleration_
+feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) to implement this.
+--->
+最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _受感染的_，并且只调度需要使用到特殊 sysctl 设置的 Pod 到这些节点上。 建议使用 Kubernetes 的 [ _taints 和  toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
+
+<!--
+A pod with the _unsafe_ sysctls will fail to launch on any node which has not
+enabled those two _unsafe_ sysctls explicitly. As with _node-level_ sysctls it
+is recommended to use
+[_taints and toleration_ feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) or
+[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
+to schedule those pods onto the right nodes.
+--->
+设置了 _非安全的_ sysctl 参数的 pod，在禁用了以下两种 _非安全的_ sysctl 参数配置的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
+[_taints 和 toleration_  特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
+[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
+以便将 Pod 调度到正确的节点之上。
+
+## PodSecurityPolicy
+
+<!--
+You can further control which sysctls can be set in pods by specifying lists of
+sysctls or sysctl patterns in the `forbiddenSysctls` and/or
+`allowedUnsafeSysctls` fields of the PodSecurityPolicy. A sysctl pattern ends
+with a `*` character, such as `kernel.*`. A `*` character on its own matches
+all sysctls.
+--->
+您可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls` 字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。 单独的 `*`  字符匹配所有 sysctl 参数。
+
+<!--
+By default, all safe sysctls are allowed.
+--->
+所有 _安全的_ sysctl 参数都默认启用。
+
+<!--
+Both `forbiddenSysctls` and `allowedUnsafeSysctls` are lists of plain sysctl names
+or sysctl patterns (which end with `*`). The string `*` matches all sysctls.
+--->
+`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。 只填写 `*` 则匹配所有的 sysctl 参数。
+
+<!--
+The `forbiddenSysctls` field excludes specific sysctls. You can forbid a
+combination of safe and unsafe sysctls in the list. To forbid setting any
+sysctls, use `*` on its own.
+--->
+`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。 您可以在列表中禁用安全和非安全的 sysctl 参数的组合。 要禁用所有的 sysctl 参数，请设置为 `*`。
+
+<!--
+If you specify any unsafe sysctl in the `allowedUnsafeSysctls` field and it is
+not present in the `forbiddenSysctls` field, that sysctl can be used in Pods
+using this PodSecurityPolicy. To allow all unsafe sysctls in the
+PodSecurityPolicy to be set, use `*` on its own.
+--->
+如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，并且它在`forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过 PodSecurityPolicy 启用该 sysctl 参数。 若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，请设 `allowedUnsafeSysctls` 字段值为 `*`。
+
+<!--
+Do not configure these two fields such that there is overlap, meaning that a
+given sysctl is both allowed and forbidden.
+--->
+`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
+
+{{< warning >}}
+<!--
+**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
+in a PodSecurityPolicy, any pod using such a sysctl will fail to start
+if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
+flag as well on that node.
+--->
+**警告**：如果您通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl 参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数 `--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl 参数的 Pod 将会启动失败。
+{{< /warning >}}
+
+<!--
+This example allows unsafe sysctls prefixed with `kernel.msg` to be set and
+disallows setting of the `kernel.shm_rmid_forced` sysctl.
+--->
+以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，以及禁用了 sysctl 参数 `kernel.shm_rmid_forced`。
+
+```yaml
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: sysctl-psp
+spec:
+  allowedUnsafeSysctls:
+  - kernel.msg*
+  forbiddenSysctls:
+  - kernel.shm_rmid_forced
+ ...
+```
+
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/administer-cluster/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/weave-network-policy.md
similarity index 100%
rename from content/cn/docs/tasks/administer-cluster/weave-network-policy.md
rename to content/zh/docs/tasks/administer-cluster/weave-network-policy.md
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
new file mode 100644
index 0000000000000..ec3952530487e
--- /dev/null
+++ b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
@@ -0,0 +1,135 @@
+---
+title: 将 Pod 分配给节点
+content_template: templates/task
+weight: 120
+---
+<!--
+---
+title: Assign Pods to Nodes
+content_template: templates/task
+weight: 120
+---
+-->
+
+{{% capture overview %}}
+<!--
+This page shows how to assign a Kubernetes Pod to a particular node in a
+Kubernetes cluster.
+-->
+此页面显示如何将 Kubernetes Pod 分配给 Kubernetes 集群中的特定节点。
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Add a label to a node
+-->
+## 给节点添加标签
+
+<!--
+1. List the nodes in your cluster:
+-->
+1. 列出集群中的节点
+
+        kubectl get nodes
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似如下：
+
+        NAME      STATUS    AGE     VERSION
+        worker0   Ready     1d      v1.6.0+fff5156
+        worker1   Ready     1d      v1.6.0+fff5156
+        worker2   Ready     1d      v1.6.0+fff5156
+
+<!--
+1. Chose one of your nodes, and add a label to it:
+-->
+1. 选择其中一个节点，为它添加标签：
+
+        kubectl label nodes <your-node-name> disktype=ssd
+
+    <!--
+    where `<your-node-name>` is the name of your chosen node.
+    -->
+    `<your-node-name>` 是你选择的节点的名称。
+
+<!--
+1. Verify that your chosen node has a `disktype=ssd` label:
+-->
+1. 验证你选择的节点是否有 `disktype=ssd` 标签：
+
+       kubectl get nodes --show-labels
+
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似如下：
+
+        NAME      STATUS    AGE     VERSION            LABELS
+        worker0   Ready     1d      v1.6.0+fff5156     ...,disktype=ssd,kubernetes.io/hostname=worker0
+        worker1   Ready     1d      v1.6.0+fff5156     ...,kubernetes.io/hostname=worker1
+        worker2   Ready     1d      v1.6.0+fff5156     ...,kubernetes.io/hostname=worker2
+
+    <!--
+    In the preceding output, you can see that the `worker0` node has a
+    `disktype=ssd` label.
+    -->
+    在前面的输出中，你可以看到 `worker0` 节点有 `disktype=ssd` 标签。
+
+<!--
+## Create a pod that gets scheduled to your chosen node
+-->
+## 创建一个调度到你选择的节点的 pod
+
+<!--
+This pod configuration file describes a pod that has a node selector,
+`disktype: ssd`. This means that the pod will get scheduled on a node that has
+a `disktype=ssd` label.
+-->
+该 pod 配置文件描述了一个拥有节点选择器 `disktype: ssd` 的 pod。这表明该 pod 将被调度到
+有 `disktype=ssd` 标签的节点。
+
+{{< codenew file="pods/pod-nginx.yaml" >}}
+
+<!--
+1. Use the configuration file to create a pod that will get scheduled on your
+   chosen node:
+-->
+1. 使用该配置文件去创建一个 pod，该 pod 将被调度到你选择的节点上：
+
+        kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
+
+<!--
+1. Verify that the pod is running on your chosen node:
+-->
+1. 验证 pod 是不是运行在你选择的节点上：
+
+        kubectl get pods --output=wide
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似如下：
+
+        NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+        nginx    1/1       Running   0          13s    10.200.0.4   worker0
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+<!--
+Learn more about
+[labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
+-->
+了解更多关于
+[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml b/content/zh/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml
rename to content/zh/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/cpu-request-limit.yaml b/content/zh/docs/tasks/configure-pod-container/cpu-request-limit.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/cpu-request-limit.yaml
rename to content/zh/docs/tasks/configure-pod-container/cpu-request-limit.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/exec-liveness.yaml b/content/zh/docs/tasks/configure-pod-container/exec-liveness.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/exec-liveness.yaml
rename to content/zh/docs/tasks/configure-pod-container/exec-liveness.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/http-liveness.yaml b/content/zh/docs/tasks/configure-pod-container/http-liveness.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/http-liveness.yaml
rename to content/zh/docs/tasks/configure-pod-container/http-liveness.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/init-containers.yaml b/content/zh/docs/tasks/configure-pod-container/init-containers.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/init-containers.yaml
rename to content/zh/docs/tasks/configure-pod-container/init-containers.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/lifecycle-events.yaml b/content/zh/docs/tasks/configure-pod-container/lifecycle-events.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/lifecycle-events.yaml
rename to content/zh/docs/tasks/configure-pod-container/lifecycle-events.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/mem-limit-range.yaml b/content/zh/docs/tasks/configure-pod-container/mem-limit-range.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/mem-limit-range.yaml
rename to content/zh/docs/tasks/configure-pod-container/mem-limit-range.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/memory-request-limit-2.yaml b/content/zh/docs/tasks/configure-pod-container/memory-request-limit-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/memory-request-limit-2.yaml
rename to content/zh/docs/tasks/configure-pod-container/memory-request-limit-2.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/memory-request-limit-3.yaml b/content/zh/docs/tasks/configure-pod-container/memory-request-limit-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/memory-request-limit-3.yaml
rename to content/zh/docs/tasks/configure-pod-container/memory-request-limit-3.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/memory-request-limit.yaml b/content/zh/docs/tasks/configure-pod-container/memory-request-limit.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/memory-request-limit.yaml
rename to content/zh/docs/tasks/configure-pod-container/memory-request-limit.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/oir-pod-2.yaml b/content/zh/docs/tasks/configure-pod-container/oir-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/oir-pod-2.yaml
rename to content/zh/docs/tasks/configure-pod-container/oir-pod-2.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/oir-pod.yaml b/content/zh/docs/tasks/configure-pod-container/oir-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/oir-pod.yaml
rename to content/zh/docs/tasks/configure-pod-container/oir-pod.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/opaque-integer-resource.md b/content/zh/docs/tasks/configure-pod-container/opaque-integer-resource.md
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/opaque-integer-resource.md
rename to content/zh/docs/tasks/configure-pod-container/opaque-integer-resource.md
diff --git a/content/cn/docs/tasks/configure-pod-container/pod-redis.yaml b/content/zh/docs/tasks/configure-pod-container/pod-redis.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/pod-redis.yaml
rename to content/zh/docs/tasks/configure-pod-container/pod-redis.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/pod.yaml b/content/zh/docs/tasks/configure-pod-container/pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/pod.yaml
rename to content/zh/docs/tasks/configure-pod-container/pod.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/private-reg-pod.yaml b/content/zh/docs/tasks/configure-pod-container/private-reg-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/private-reg-pod.yaml
rename to content/zh/docs/tasks/configure-pod-container/private-reg-pod.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/projected-volume.yaml b/content/zh/docs/tasks/configure-pod-container/projected-volume.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/projected-volume.yaml
rename to content/zh/docs/tasks/configure-pod-container/projected-volume.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/qos-pod-2.yaml b/content/zh/docs/tasks/configure-pod-container/qos-pod-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/qos-pod-2.yaml
rename to content/zh/docs/tasks/configure-pod-container/qos-pod-2.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/qos-pod-3.yaml b/content/zh/docs/tasks/configure-pod-container/qos-pod-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/qos-pod-3.yaml
rename to content/zh/docs/tasks/configure-pod-container/qos-pod-3.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/qos-pod-4.yaml b/content/zh/docs/tasks/configure-pod-container/qos-pod-4.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/qos-pod-4.yaml
rename to content/zh/docs/tasks/configure-pod-container/qos-pod-4.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/qos-pod.yaml b/content/zh/docs/tasks/configure-pod-container/qos-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/qos-pod.yaml
rename to content/zh/docs/tasks/configure-pod-container/qos-pod.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/rq-compute-resources.yaml b/content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/rq-compute-resources.yaml
rename to content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/security-context-2.yaml b/content/zh/docs/tasks/configure-pod-container/security-context-2.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/security-context-2.yaml
rename to content/zh/docs/tasks/configure-pod-container/security-context-2.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/security-context-3.yaml b/content/zh/docs/tasks/configure-pod-container/security-context-3.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/security-context-3.yaml
rename to content/zh/docs/tasks/configure-pod-container/security-context-3.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/security-context-4.yaml b/content/zh/docs/tasks/configure-pod-container/security-context-4.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/security-context-4.yaml
rename to content/zh/docs/tasks/configure-pod-container/security-context-4.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/security-context.yaml b/content/zh/docs/tasks/configure-pod-container/security-context.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/security-context.yaml
rename to content/zh/docs/tasks/configure-pod-container/security-context.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/task-pv-claim.yaml b/content/zh/docs/tasks/configure-pod-container/task-pv-claim.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/task-pv-claim.yaml
rename to content/zh/docs/tasks/configure-pod-container/task-pv-claim.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/task-pv-pod.yaml b/content/zh/docs/tasks/configure-pod-container/task-pv-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/task-pv-pod.yaml
rename to content/zh/docs/tasks/configure-pod-container/task-pv-pod.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/task-pv-volume.yaml b/content/zh/docs/tasks/configure-pod-container/task-pv-volume.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/task-pv-volume.yaml
rename to content/zh/docs/tasks/configure-pod-container/task-pv-volume.yaml
diff --git a/content/cn/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml b/content/zh/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml
similarity index 100%
rename from content/cn/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml
rename to content/zh/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml
diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md
new file mode 100644
index 0000000000000..fe551d011db76
--- /dev/null
+++ b/content/zh/docs/tasks/debug-application-cluster/audit.md
@@ -0,0 +1,612 @@
+---
+reviewers:
+- soltysh
+- sttts
+- ericchiang
+content_template: templates/concept
+title: Auditing
+---
+
+{{% capture overview %}}
+
+{{< feature-state state="beta" >}}
+
+<!--
+Kubernetes auditing provides a security-relevant chronological set of records documenting
+the sequence of activities that have affected system by individual users, administrators
+or other components of the system. It allows cluster administrator to
+answer the following questions:
+-->
+Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。
+它能帮助集群管理员处理以下问题：
+
+<!--
+ - what happened?
+ - when did it happen?
+ - who initiated it?
+ - on what did it happen?
+ - where was it observed?
+ - from where was it initiated?
+ - to where was it going?
+-->
+ - 发生了什么？
+ - 什么时候发生的？
+ - 谁触发的？
+ - 活动发生在哪个（些）对象上？
+ - 在哪观察到的？
+ - 它从哪触发的？
+ - 活动的后续处理行为是什么？
+
+{{% /capture %}}
+
+{{< toc >}}
+
+{{% capture body %}}
+
+<!--
+[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
+of its execution generates an event, which is then pre-processed according to
+a certain policy and written to a backend. The policy determines what's recorded
+and the backends persist the records. The current backend implementations
+include logs files and webhooks.
+-->
+[Kube-apiserver][kube-apiserver] 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。
+您可以在 [设计方案][auditing-proposal] 中找到更多详细信息。
+该策略确定记录的内容并且在后端存储记录。当前的后端支持日志文件和 webhook。
+
+<!--
+Each request can be recorded with an associated "stage". The known stages are:
+
+- `RequestReceived` - The stage for events generated as soon as the audit
+  handler receives the request, and before it is delegated down the handler
+  chain.
+- `ResponseStarted` - Once the response headers are sent, but before the
+  response body is sent. This stage is only generated for long-running requests
+  (e.g. watch).
+- `ResponseComplete` - The response body has been completed and no more bytes
+  will be sent.
+- `Panic` - Events generated when a panic occurred.
+-->
+
+每个请求都可以用相关的 "stage" 记录。已知的 stage 有：
+
+- `RequestReceived` - 事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。
+
+- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。
+
+- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
+- `Panic` - 当 panic 发生时生成。
+
+{{< note >}}
+<!--
+**Note** The audit logging feature increases the memory consumption of the API
+server because some context required for auditing is stored for each request.
+Additionally, memory consumption depends on the audit logging configuration.
+-->
+**注意** 审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
+此外，内存消耗取决于审计日志记录的配置。
+{{< /note >}}
+
+<!--
+## Audit Policy
+
+Audit policy defines rules about what events should be recorded and what data
+they should include. The audit policy object structure is defined in the
+[`audit.k8s.io` API group][auditing-api]. When an event is processed, it's
+compared against the list of rules in order. The first matching rule sets the
+"audit level" of the event. The known audit levels are:
+-->
+## 审计策略
+
+审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。审计策略对象结构在 [`audit.k8s.io` API 组][auditing-api] 中定义。
+处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有：
+
+<!--
+- `None` - don't log events that match this rule.
+- `Metadata` - log request metadata (requesting user, timestamp, resource,
+  verb, etc.) but not request or response body.
+- `Request` - log event metadata and request body but not response body.
+  This does not apply for non-resource requests.
+- `RequestResponse` - log event metadata, request and response bodies.
+  This does not apply for non-resource requests.
+-->
+- `None` - 符合这条规则的日志将不会记录。
+- `Metadata` - 记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。
+- `Request` - 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。
+- `RequestResponse` - 记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。
+
+<!--
+You can pass a file with the policy to [kube-apiserver][kube-apiserver]
+using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
+Note that the `rules` field __must__ be provided in the audit policy file.
+A policy with no (0) rules is treated as illegal.
+
+Below is an example audit policy file:
+-->
+您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 
+注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。
+
+以下是一个审计策略文件的示例：
+
+{{< codenew file="audit/audit-policy.yaml" >}}
+
+<!--
+You can use a minimal audit policy file to log all requests at the `Metadata` level:
+-->
+您可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求：
+
+```yaml
+# Log all requests at the Metadata level.
+apiVersion: audit.k8s.io/v1beta1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+<!--
+The [audit profile used by GCE][gce-audit-profile] should be used as reference by
+admins constructing their own audit profiles.
+-->
+管理员构建自己的审计配置文件时，应使用 [GCE 使用的审计配置文件][gce-audit-profile] 作为参考。
+
+<!--
+## Audit backends
+
+Audit backends persist audit events to an external storage.
+[Kube-apiserver][kube-apiserver] out of the box provides two backends:
+
+- Log backend, which writes events to a disk
+- Webhook backend, which sends events to an external API
+
+In both cases, audit events structure is defined by the API in the
+`audit.k8s.io` API group. The current version of the API is
+[`v1beta1`][auditing-api].
+-->
+## 审计后端
+
+审计后端实现将审计事件导出到外部存储。
+[Kube-apiserver][kube-apiserver] 提供两个后端：
+
+- Log 后端，将事件写入到磁盘
+- Webhook 后端，将事件发送到外部 API
+
+在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。当前版本的 API 是 [`v1beta1`][auditing-api]。
+
+{{< note >}}
+<!--
+**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
+with an appropriate Kubernetes API object. For example, the following request body is a valid patch
+request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
+-->
+**注意：** 在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作，而不是一个完整的 Kubernetes API 对象 JSON 串。
+例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。
+
+```json
+[
+  {
+    "op": "replace",
+    "path": "/spec/parallelism",
+    "value": 0
+  },
+  {
+    "op": "remove",
+    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
+  }
+]
+```
+{{< /note >}}
+
+<!--
+### Log backend
+
+Log backend writes audit events to a file in JSON format. You can configure
+log audit backend using the following [kube-apiserver][kube-apiserver] flags:
+-->
+### Log 后端
+
+Log 后端将审计事件写入 JSON 格式的文件。您可以使用以下 [kube-apiserver][kube-apiserver] 标志配置 Log 审计后端：
+
+<!--
+- `--audit-log-path` specifies the log file path that log backend uses to write
+  audit events. Not specifying this flag disables log backend. `-` means standard out
+- `--audit-log-maxage` defined the maximum number of days to retain old audit log files
+- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
+- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+-->
+- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化
+- `--audit-log-maxage` 定义了保留旧审计日志文件的最大天数
+- `--audit-log-maxbackup` 定义了要保留的审计日志文件的最大数量
+- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节）
+
+<!--
+### Webhook backend
+
+Webhook backend sends audit events to a remote API, which is assumed to be the
+same API as [kube-apiserver][kube-apiserver] exposes. You can configure webhook
+audit backend using the following kube-apiserver flags:
+-->
+### Webhook 后端
+
+Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 [kube-apiserver][kube-apiserver] 相同的API。
+您可以使用如下 kube-apiserver 标志来配置 webhook 审计后端：
+
+<!--
+- `--audit-webhook-config-file` specifies the path to a file with a webhook
+  configuration. Webhook configuration is effectively a [kubeconfig][kubeconfig].
+- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed
+  request before retrying. Subsequent requests are retried with exponential backoff.
+
+The webhook config file uses the kubeconfig format to specify the remote address of
+the service and credentials used to connect to it.
+-->
+- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个 [kubeconfig][kubeconfig]。
+- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
+
+webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
+
+### Batching
+
+<!--
+Both log and webhook backends support batching. Using webhook as an example, here's the list of
+available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag
+name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default
+throttling is enabled in `webhook` and disabled in `log`.
+
+- `--audit-webhook-mode` defines the buffering strategy. One of the following:
+  - `batch` - buffer events and asynchronously process them in batches. This is the default.
+  - `blocking` - block API server responses on processing each individual event.
+-->
+
+log 和 webhook 后端都支持 batch。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。
+默认情况下，在 `webhook` 中启用 batch，在 `log` 中禁用 batch。同样，默认情况下，在 `webhook` 中启用限制，在 `log` 中禁用限制。
+
+- `--audit-webhook-mode` 定义缓存策略，可选值如下：
+  - `batch` - 以批处理缓存事件和异步的过程。这是默认值。
+  - `blocking` - 阻止 API server 处理每个单独事件的响应。
+
+<!--
+The following flags are used only in the `batch` mode.
+
+- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching.
+  If the rate of incoming events overflows the buffer, events are dropped.
+- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch.
+- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally
+  batching events in the queue.
+- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated
+  per second.
+- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same
+  moment if the allowed QPS was underutilized previously.
+-->
+以下参数仅用于 `batch` 模式。
+
+- `--audit-webhook-batch-buffer-size` 定义 batch 之前要缓存的事件数。
+  如果传入事件的速率溢出缓存区，则会丢弃事件。
+- `--audit-webhook-batch-max-size` 定义一个 batch 中的最大事件数。
+- `--audit-webhook-batch-max-wait` 无条件 batch 队列中的事件前等待的最大事件。
+- `--audit-webhook-batch-throttle-qps` 每秒生成的最大 batch 平均值。
+- `--audit-webhook-batch-throttle-burst` 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。
+
+<!--
+#### Parameter tuning
+
+Parameters should be set to accommodate the load on the apiserver.
+
+For example, if kube-apiserver receives 100 requests each second, and each request is audited only
+on `ResponseStarted` and `ResponseComplete` stages, you should account for ~200 audit
+events being generated each second. Assuming that there are up to 100 events in a batch,
+you should set throttling level at least 2 QPS. Assuming that the backend can take up to
+5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events, i.e.
+10 batches, i.e. 1000 events.
+-->
+#### 参数调整
+
+需要设置参数以适应 apiserver 上的负载。
+
+
+例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 `ResponseStarted` 和 `ResponseComplete` 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。
+假设批处理中最多有 100 个事件，则应将限制级别设置为至少 2 个 QPS。
+假设后端最多需要 5 秒钟来写入事件，您应该设置缓冲区大小以容纳最多 5 秒的事件，即 10 个 batch，即 1000 个事件。
+
+<!--
+In most cases however, the default parameters should be sufficient and you don't have to worry about
+setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver
+and in the logs to monitor the state of the auditing subsystem.
+
+- `apiserver_audit_event_total` metric contains the total number of audit events exported.
+- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error
+  during exporting.
+-->
+但是，在大多数情况下，默认参数应该足够了，您不必手动设置它们。您可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。
+
+- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。
+- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。
+
+<!--
+## Multi-cluster setup
+
+If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also
+set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the
+same format as described above to the aggregated apiserver and set up the log ingesting pipeline
+to pick up audit logs. Different apiservers can have different audit configurations and different
+audit policies.
+-->
+## 多集群配置
+
+如果您通过 [aggregation layer][kube-aggregator] 对 Kubernetes API 进行扩展，那么您也可以为聚合的 apiserver 设置审计日志。
+想要这么做，您需要以上述的格式给聚合的 apiserver 配置参数，并且配置日志管道以采用审计日志。不同的 apiserver 可以配置不同的审计配置和策略。
+
+<!--
+## Log Collector Examples
+
+### Use fluentd to collect and distribute audit events from log file
+
+[Fluentd][fluentd] is an open source data collector for unified logging layer.
+In this example, we will use fluentd to split audit events by different namespaces.
+
+1. install [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc] in the kube-apiserver node
+1. create a config file for fluentd
+-->
+## 日志选择器示例
+
+### 使用 fluentd 从日志文件中选择并且分发审计日志
+
+[Fluentd][fluentd] 是一个开源的数据采集器，可以从统一的日志层中采集。
+在以下示例中，我们将使用 fluentd 来按照命名空间划分审计事件。
+
+1. 在 kube-apiserver node 节点上安装 [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc]
+1. 为 fluentd 创建一个配置文件
+
+    ```none
+    $ cat <<EOF > /etc/fluentd/config
+    # fluentd conf runs in the same host with kube-apiserver
+    <source>
+        @type tail
+        # audit log path of kube-apiserver
+        path /var/log/audit
+        pos_file /var/log/audit.pos
+        format json
+        time_key time
+        time_format %Y-%m-%dT%H:%M:%S.%N%z
+        tag audit
+    </source>
+
+    <filter audit>
+        #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
+        type record_transformer
+        enable_ruby
+        <record>
+         namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ?  "none":record["objectRef"]["namespace"])}
+        </record>
+    </filter>
+
+    <match audit>
+        # route audit according to namespace element in context
+        @type rewrite_tag_filter
+        rewriterule1 namespace ^(.+) ${tag}.$1
+    </match>
+
+    <filter audit.**>
+       @type record_transformer
+       remove_keys namespace
+    </filter>
+
+    <match audit.**>
+        @type forest
+        subtype file
+        remove_prefix audit
+        <template>
+            time_slice_format %Y%m%d%H
+            compress gz
+            path /var/log/audit-${tag}.*.log
+            format json
+            include_time_key true
+        </template>
+    </match>
+    ```
+
+<!--
+1. start fluentd
+-->
+1. 启动 fluentd
+
+    ```shell
+    $ fluentd -c /etc/fluentd/config  -vv
+    ```
+
+<!--
+1. start kube-apiserver with the following options:
+-->
+1. 给 kube-apiserver 配置以下参数并启动：
+
+    ```shell
+    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
+    ```
+
+<!--
+1. check audits for different namespaces in `/var/log/audit-*.log`
+-->
+1. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件
+
+<!--
+### Use logstash to collect and distribute audit events from webhook backend
+
+[Logstash][logstash] is an open source, server-side data processing tool. In this example,
+we will use logstash to collect audit events from webhook backend, and save events of
+different users into different files.
+
+1. install [logstash][logstash_install_doc]
+1. create config file for logstash
+-->
+### 使用 logstash 采集并分发 webhook 后端的审计事件
+
+[Logstash][logstash] 是一个开源的、服务器端的数据处理工具。在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。
+
+1. 安装 [logstash][logstash_install_doc]
+1. 为 logstash 创建配置文件
+
+    ```none
+    $ cat <<EOF > /etc/logstash/config
+    input{
+        http{
+            #TODO, figure out a way to use kubeconfig file to authenticate to logstash
+            #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
+            port=>8888
+        }
+    }
+    filter{
+        split{
+            # Webhook audit backend sends several events together with EventList
+            # split each event here.
+            field=>[items]
+            # We only need event subelement, remove others.
+            remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
+        }
+        mutate{
+            rename => {items=>event}
+        }
+    }
+    output{
+        file{
+            # Audit events from different users will be saved into different files.
+            path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
+        }
+    }
+    ```
+
+<!--
+1. start logstash
+-->
+1. 启动 logstash
+
+    ```shell
+    $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
+    ```
+
+<!--
+1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
+-->
+1. 为 kube-apiserver webhook 审计后端创建一个 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+
+    ```none
+    $ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
+    apiVersion: v1
+    clusters:
+    - cluster:
+        server: http://<ip_of_logstash>:8888
+      name: logstash
+    contexts:
+    - context:
+        cluster: logstash
+        user: ""
+      name: default-context
+    current-context: default-context
+    kind: Config
+    preferences: {}
+    users: []
+    EOF
+    ```
+
+<!--
+1. start kube-apiserver with the following options:
+-->
+1. 为 kube-apiserver 配置以下参数并启动：
+
+    ```shell
+    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
+    ```
+
+<!--
+1. check audits in logstash node's directories `/var/log/kube-audit-*/audit`
+
+Note that in addition to file output plugin, logstash has a variety of outputs that
+let users route data where they want. For example, users can emit audit events to elasticsearch
+plugin which supports full-text search and analytics.
+-->
+1. 在 logstash node 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件
+
+注意到，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。
+
+<!--
+## Legacy Audit
+
+__Note:__ Legacy Audit is deprecated and is disabled by default since 1.8 and 
+will be removed in 1.12. To fallback to this legacy audit, disable the advanced
+auditing feature using the `AdvancedAuditing` feature gate in [kube-apiserver][kube-apiserver]:
+-->
+## 传统的审计
+
+__注意：__ 传统审计已被弃用，自 1.8 版本以后默认禁用，并且将会在 1.12 版本中彻底移除。
+如果想要回退到传统的审计功能，请使用 [kube-apiserver][kube-apiserver] 中 feature gate 的 `AdvancedAuditing` 功能来禁用高级审核功能：
+
+```
+--feature-gates=AdvancedAuditing=false
+```
+
+<!--
+In legacy format, each audit log entry contains two lines:
+
+1. The request line containing a unique ID to match the response and request
+   metadata, such as the source IP, requesting user, impersonation information,
+   resource being requested, etc.
+2. The response line containing a unique ID matching the request line and the response code.
+
+Example output for `admin` user listing pods in the `default` namespace:
+-->
+在传统格式中，每个审计文件条目包含两行：
+
+1. 请求行包含唯一 ID 以匹配响应和请求元数据，例如源 IP、请求用户、模拟信息和请求的资源等。
+2. 响应行包含与请求行和响应代码相匹配的唯一 ID。
+
+```
+2017-03-21T03:57:09.106841886-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1" method="GET" user="admin" groups="\"system:masters\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
+2017-03-21T03:57:09.108403639-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200"
+```
+
+<!--
+### Configuration
+
+[Kube-apiserver][kube-apiserver] provides the following options which are responsible
+for configuring where and how audit logs are handled:
+-->
+### 配置
+
+[Kube-apiserver][kube-apiserver] 提供以下选项，负责配置审核日志的位置和处理方式：
+
+<!--
+- `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to, '-' means standard out.
+- `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
+- `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
+- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
+-->
+- `audit-log-path` - 使审计日志指向请求被记录到的文件，'-' 表示标准输出。
+- `audit-log-maxage` - 根据文件名中编码的时间戳指定保留旧审计日志文件的最大天数。
+- `audit-log-maxbackup` - 指定要保留的旧审计日志文件的最大数量。
+- `audit-log-maxsize` - 指定审核日志文件的最大大小（兆字节）。默认为100MB。
+
+<!--
+If an audit log file already exists, Kubernetes appends new audit logs to that file.
+Otherwise, Kubernetes creates an audit log file at the location you specified in
+`audit-log-path`. If the audit log file exceeds the size you specify in `audit-log-maxsize`,
+Kubernetes will rename the current log file by appending the current timestamp on
+the file name (before the file extension) and create a new audit log file.
+Kubernetes may delete old log files when creating a new log file; you can configure
+how many files are retained and how old they can be by specifying the `audit-log-maxbackup`
+and `audit-log-maxage` options.
+-->
+如果审核日志文件已经存在，则 Kubernetes 会将新的审核日志附加到该文件。
+否则，Kubernetes 会在您在 `audit-log-path` 中指定的位置创建一个审计日志文件。
+如果审计日志文件超过了您在 `audit-log-maxsize` 中指定的大小，则 Kubernetes 将通过在文件名（在文件扩展名之前）附加当前时间戳并重新创建一个新的审计日志文件来重命名当前日志文件。
+Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您可以通过指定 `audit-log-maxbackup` 和 `audit-log-maxage` 选项来配置保留多少文件以及它们的保留时间。
+
+[kube-apiserver]: /docs/admin/kube-apiserver
+[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
+[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1beta1/types.go
+[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
+[kubeconfig]: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
+[fluentd]: http://www.fluentd.org/
+[fluentd_install_doc]: http://docs.fluentd.org/v0.12/articles/quickstart#step1-installing-fluentd
+[logstash]: https://www.elastic.co/products/logstash
+[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
+[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
+
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md
similarity index 100%
rename from content/cn/docs/tasks/debug-application-cluster/debug-application.md
rename to content/zh/docs/tasks/debug-application-cluster/debug-application.md
diff --git a/content/cn/docs/tasks/debug-application-cluster/debug-cluster.md b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
similarity index 100%
rename from content/cn/docs/tasks/debug-application-cluster/debug-cluster.md
rename to content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
diff --git a/content/cn/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
similarity index 100%
rename from content/cn/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
rename to content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
diff --git a/content/cn/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
similarity index 100%
rename from content/cn/docs/tasks/debug-application-cluster/debug-stateful-set.md
rename to content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
diff --git a/content/cn/docs/tasks/inject-data-application/commands.yaml b/content/zh/docs/tasks/inject-data-application/commands.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/commands.yaml
rename to content/zh/docs/tasks/inject-data-application/commands.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/dapi-envars-container.yaml b/content/zh/docs/tasks/inject-data-application/dapi-envars-container.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/dapi-envars-container.yaml
rename to content/zh/docs/tasks/inject-data-application/dapi-envars-container.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/dapi-envars-pod.yaml b/content/zh/docs/tasks/inject-data-application/dapi-envars-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/dapi-envars-pod.yaml
rename to content/zh/docs/tasks/inject-data-application/dapi-envars-pod.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/dapi-volume-resources.yaml b/content/zh/docs/tasks/inject-data-application/dapi-volume-resources.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/dapi-volume-resources.yaml
rename to content/zh/docs/tasks/inject-data-application/dapi-volume-resources.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/dapi-volume.yaml b/content/zh/docs/tasks/inject-data-application/dapi-volume.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/dapi-volume.yaml
rename to content/zh/docs/tasks/inject-data-application/dapi-volume.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/define-command-argument-container.md b/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/define-command-argument-container.md
rename to content/zh/docs/tasks/inject-data-application/define-command-argument-container.md
diff --git a/content/cn/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
similarity index 96%
rename from content/cn/docs/tasks/inject-data-application/define-environment-variable-container.md
rename to content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
index 3b5a721ebc1b0..e422fc750d9cb 100644
--- a/content/cn/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -63,7 +63,7 @@ content_template: templates/task
 
 {{% capture whatsnext %}}
 
-* 有关环境变量的更多信息，请参阅[这里](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)。
+* 有关环境变量的更多信息，请参阅[这里](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)。
 * 有关如何通过环境变量来使用Secret，请参阅[这里](/docs/user-guide/secrets/#using-secrets-as-environment-variables)。
 * 关于[EnvVarSource](/docs/api-reference/{{< param "version" >}}/#envvarsource-v1-core)资源的信息。
 
diff --git a/content/cn/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/distribute-credentials-secure.md
rename to content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
diff --git a/content/cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
similarity index 98%
rename from content/cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
rename to content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
index dd9ee032a95c4..a230f57afdfab 100644
--- a/content/cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+++ b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -22,7 +22,7 @@ content_template: templates/task
 
 有两种方式可以将Pod和Container字段呈现给运行中的容器：
 
-* [环境变量](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
+* [环境变量](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)
 * DownwardAPIVolumeFile
 
 这两种呈现Pod和Container字段的方式都称为*Downward API*。
diff --git a/content/cn/docs/tasks/inject-data-application/envars.yaml b/content/zh/docs/tasks/inject-data-application/envars.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/envars.yaml
rename to content/zh/docs/tasks/inject-data-application/envars.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
rename to content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-allow-db.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-allow-db.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-allow-db.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-allow-db.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-configmap.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-configmap.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-configmap.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-configmap.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-merged.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-merged.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-merged.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-merged.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-multi-merged.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-pod.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-pod.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-pod.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-preset.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-preset.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-preset.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-preset.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-proxy.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-proxy.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-proxy.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-proxy.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-replicaset-merged.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset-replicaset.yaml b/content/zh/docs/tasks/inject-data-application/podpreset-replicaset.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset-replicaset.yaml
rename to content/zh/docs/tasks/inject-data-application/podpreset-replicaset.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/podpreset.md b/content/zh/docs/tasks/inject-data-application/podpreset.md
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/podpreset.md
rename to content/zh/docs/tasks/inject-data-application/podpreset.md
diff --git a/content/cn/docs/tasks/inject-data-application/secret-envars-pod.yaml b/content/zh/docs/tasks/inject-data-application/secret-envars-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/secret-envars-pod.yaml
rename to content/zh/docs/tasks/inject-data-application/secret-envars-pod.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/secret-pod.yaml b/content/zh/docs/tasks/inject-data-application/secret-pod.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/secret-pod.yaml
rename to content/zh/docs/tasks/inject-data-application/secret-pod.yaml
diff --git a/content/cn/docs/tasks/inject-data-application/secret.yaml b/content/zh/docs/tasks/inject-data-application/secret.yaml
similarity index 100%
rename from content/cn/docs/tasks/inject-data-application/secret.yaml
rename to content/zh/docs/tasks/inject-data-application/secret.yaml
diff --git a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
new file mode 100755
index 0000000000000..4d4d3432dca14
--- /dev/null
+++ b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
@@ -0,0 +1,380 @@
+---
+cn-approvers:
+- linyouchong
+title: 使用工作队列进行精细的并行处理
+content_template: templates/task
+weight: 40
+---
+<!--
+---
+title: Fine Parallel Processing Using a Work Queue
+content_template: templates/task
+weight: 40
+---
+-->
+
+{{% capture overview %}}
+
+<!--
+In this example, we will run a Kubernetes Job with multiple parallel
+worker processes in a given pod.
+-->
+在这个例子中，我们会运行一个Kubernetes Job，其中的 Pod 会运行多个并行工作进程。
+
+<!--
+In this example, as each pod is created, it picks up one unit of work
+from a task queue, processes it, and repeats until the end of the queue is reached.
+-->
+在这个例子中，当每个pod被创建时，它会从一个任务队列中获取一个工作单元，处理它，然后重复，直到到达队列的尾部。
+
+
+<!--
+Here is an overview of the steps in this example:
+-->
+下面是这个示例的步骤概述
+
+<!--
+1. **Start a storage service to hold the work queue.**  In this example, we use Redis to store
+  our work items.  In the previous example, we used RabbitMQ.  In this example, we use Redis and
+  a custom work-queue client library because AMQP does not provide a good way for clients to
+  detect when a finite-length work queue is empty.  In practice you would set up a store such
+  as Redis once and reuse it for the work queues of many jobs, and other things.
+-->
+1. **启动存储服务用于保存工作队列。** 在这个例子中，我们使用 Redis 来存储工作项。在上一个例子中，我们使用了 RabbitMQ。在这个例子中，由于 AMQP 不能为客户端提供一个良好的方法来检测一个有限长度的工作队列是否为空，我们使用了 Redis 和一个自定义的工作队列客户端库。在实践中，您可能会设置一个类似于 Redis 的存储库，并将其同时用于多项任务或其他事务的工作队列。
+<!--
+1. **Create a queue, and fill it with messages.**  Each message represents one task to be done.  In
+  this example, a message is just an integer that we will do a lengthy computation on.
+-->
+1. **创建一个队列，然后向其中填充消息。** 每个消息表示一个将要被处理的工作任务。在这个例子中，消息只是一个我们将用于进行长度计算的整数。
+<!--
+1. **Start a Job that works on tasks from the queue**.  The Job starts several pods.  Each pod takes
+  one task from the message queue, processes it, and repeats until the end of the queue is reached.
+-->
+1. **启动一个 Job 对队列中的任务进行处理**。这个 Job 启动了若干个 Pod 。每个 Pod 从消息队列中取出一个工作任务，处理它，然后重复，直到到达队列的尾部。
+
+{{% /capture %}}
+
+{{< toc >}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+Be familiar with the basic,
+non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
+-->
+熟秋基础知识，非并行方式运行 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)。
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+<!--
+## Starting Redis
+-->
+## 启动 Redis
+
+<!--
+For this example, for simplicity, we will start a single instance of Redis.
+See the [Redis Example](https://github.com/kubernetes/examples/tree/master/guestbook) for an example
+of deploying Redis scalably and redundantly.
+-->
+对于这个例子，为了简单起见，我们将启动一个单实例的 Redis。
+了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook) 
+
+<!--
+If you are working from the website source tree, you can go to the following
+directory and start  a temporary Pod running Redis and a service so we can find it.
+-->
+如果您在使用本文档库的源代码目录，您可以进入如下目录，然后启动一个临时的 Pod 用于运行 Redis 和 一个临时的 service 以便我们能够找到这个 Pod
+
+```shell
+$ cd content/en/examples/application/job/redis
+$ kubectl create -f ./redis-pod.yaml
+pod/redis-master created
+$ kubectl create -f ./redis-service.yaml
+service/redis created
+```
+
+<!--
+If you're not working from the source tree, you could also download the following
+files directly:
+-->
+如果您没有使用本文档库的源代码目录，您可以直接下载如下文件：
+
+- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
+- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
+- [`Dockerfile`](/examples/application/job/redis/Dockerfile)
+- [`job.yaml`](/examples/application/job/redis/job.yaml)
+- [`rediswq.py`](/examples/application/job/redis/rediswq.py)
+- [`worker.py`](/examples/application/job/redis/worker.py)
+
+<!--
+## Filling the Queue with tasks
+-->
+## 使用任务填充队列
+
+<!--
+Now let's fill the queue with some "tasks".  In our example, our tasks are just strings to be
+printed.
+-->
+现在，让我们往队列里添加一些“任务”。在这个例子中，我们的任务只是一些将被打印出来的字符串。
+
+<!--
+Start a temporary interactive pod for running the Redis CLI.
+-->
+启动一个临时的可交互的 pod 用于运行 Redis 命令行界面。
+
+```shell
+$ kubectl run -i --tty temp --image redis --command "/bin/sh"
+Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+<!--
+Now hit enter, start the redis CLI, and create a list with some work items in it.
+-->
+现在按回车键，启动 redis 命令行界面，然后创建一个存在若干个工作项的列表。
+
+```
+# redis-cli -h redis
+redis:6379> rpush job2 "apple"
+(integer) 1
+redis:6379> rpush job2 "banana"
+(integer) 2
+redis:6379> rpush job2 "cherry"
+(integer) 3
+redis:6379> rpush job2 "date"
+(integer) 4
+redis:6379> rpush job2 "fig"
+(integer) 5
+redis:6379> rpush job2 "grape"
+(integer) 6
+redis:6379> rpush job2 "lemon"
+(integer) 7
+redis:6379> rpush job2 "melon"
+(integer) 8
+redis:6379> rpush job2 "orange"
+(integer) 9
+redis:6379> lrange job2 0 -1
+1) "apple"
+2) "banana"
+3) "cherry"
+4) "date"
+5) "fig"
+6) "grape"
+7) "lemon"
+8) "melon"
+9) "orange"
+```
+
+<!--
+So, the list with key `job2` will be our work queue.
+-->
+因此，这个键为 `job2` 的列表就是我们的工作队列。
+
+<!--
+Note: if you do not have Kube DNS setup correctly, you may need to change
+the first step of the above block to `redis-cli -h $REDIS_SERVICE_HOST`.
+-->
+注意：如果您还没有正确地配置 Kube DNS，您可能需要将上面的第一步改为 `redis-cli -h $REDIS_SERVICE_HOST`。
+
+
+<!--
+## Create an Image
+-->
+创建镜像
+
+<!--
+Now we are ready to create an image that we will run.
+-->
+现在我们已经准备好创建一个我们要运行的镜像
+
+<!--
+We will use a python worker program with a redis client to read
+the messages from the message queue.
+-->
+我们会使用一个带有 redis 客户端的 python 工作程序从消息队列中读出消息。
+
+<!--
+A simple Redis work queue client library is provided,
+called rediswq.py ([Download](/examples/application/job/redis/rediswq.py)).
+-->
+这里提供了一个简单的 Redis 工作队列客户端库，叫 rediswq.py ([下载](/examples/application/job/redis/rediswq.py))。
+
+<!--
+The "worker" program in each Pod of the Job uses the work queue
+client library to get work.  Here it is:
+-->
+Job 中每个 Pod 内的 “工作程序” 使用工作队列客户端库获取工作。如下：
+
+{{< codenew language="python" file="application/job/redis/worker.py" >}}
+
+<!--
+If you are working from the source tree,
+change directory to the `content/en/examples/application/job/redis/` directory.
+Otherwise, download [`worker.py`](/examples/application/job/redis/worker.py), [`rediswq.py`](/examples/application/job/redis/rediswq.py), and [`Dockerfile`](/examples/application/job/redis/Dockerfile)
+using above links. Then build the image:
+-->
+如果您在使用本文档库的源代码目录，请将当前目录切换到 `content/en/examples/application/job/redis/`。否则，请点击链接下载 [`worker.py`](/examples/application/job/redis/worker.py)、 [`rediswq.py`](/examples/application/job/redis/rediswq.py) 和 [`Dockerfile`](/examples/application/job/redis/Dockerfile)。然后构建镜像：
+
+```shell
+docker build -t job-wq-2 .
+```
+
+<!--
+### Push the image
+-->
+### Push 镜像
+
+<!--
+For the [Docker Hub](https://hub.docker.com/), tag your app image with
+your username and push to the Hub with the below commands. Replace
+`<username>` with your Hub username.
+-->
+对于 [Docker Hub](https://hub.docker.com/)，请先用您的用户名给镜像打上标签，然后使用下面的命令 push 您的镜像到仓库。请将 `<username>` 替换为您自己的用户名。
+
+```shell
+docker tag job-wq-2 <username>/job-wq-2
+docker push <username>/job-wq-2
+```
+
+<!--
+You need to push to a public repository or [configure your cluster to be able to access
+your private repository](/docs/concepts/containers/images/).
+-->
+您需要将镜像 push 到一个公共仓库或者 [配置集群访问您的私有仓库](/docs/concepts/containers/images/)。
+
+<!--
+If you are using [Google Container
+Registry](https://cloud.google.com/tools/container-registry/), tag
+your app image with your project ID, and push to GCR. Replace
+`<project>` with your project ID.
+-->
+如果您使用的是 [Google Container
+Registry](https://cloud.google.com/tools/container-registry/)，请先用您的 project ID 给您的镜像打上标签，然后 push 到 GCR 。请将 `<project>` 替换为您自己的 project ID
+
+```shell
+docker tag job-wq-2 gcr.io/<project>/job-wq-2
+gcloud docker -- push gcr.io/<project>/job-wq-2
+```
+
+<!--
+## Defining a Job
+-->
+## 定义一个 Job
+
+<!--
+Here is the job definition:
+-->
+这是 job 定义：
+
+{{< codenew file="application/job/redis/job.yaml" >}}
+
+<!--
+Be sure to edit the job template to
+change `gcr.io/myproject` to your own path.
+-->
+请确保将 job 模板中的 `gcr.io/myproject` 更改为您自己的路径。
+
+<!--
+In this example, each pod works on several items from the queue and then exits when there are no more items.
+Since the workers themselves detect when the workqueue is empty, and the Job controller does not
+know about the workqueue, it relies on the workers to signal when they are done working.
+The workers signal that the queue is empty by exiting with success.  So, as soon as any worker
+exits with success, the controller knows the work is done, and the Pods will exit soon.
+So, we set the completion count of the Job to 1.  The job controller will wait for the other pods to complete
+too.
+-->
+在这个例子中，每个 pod 处理了队列中的多个项目，直到队列中没有项目时便退出。因为是由工作程序自行检测工作队列是否为空，并且 Job 控制器不知道工作队列的存在，所以依赖于工作程序在完成工作时发出信号。工作程序以成功退出的形式发出信号表示工作队列已经为空。所以，只要有任意一个工作程序成功退出，控制器就知道工作已经完成了，所有的 Pod 将很快会退出。因此，我们将 Job 的 completion count 设置为 1 。尽管如此，Job 控制器还是会等待其它 Pod 完成。
+
+
+<!--
+## Running the Job
+-->
+## 运行 Job
+
+<!--
+So, now run the Job:
+-->
+现在运行这个 Job ：
+
+```shell
+kubectl create -f ./job.yaml
+```
+
+<!--
+Now wait a bit, then check on the job.
+-->
+稍等片刻，然后检查这个 Job。
+
+```shell
+$ kubectl describe jobs/job-wq-2
+Name:             job-wq-2
+Namespace:        default
+Selector:         controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+Labels:           controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                  job-name=job-wq-2
+Annotations:      <none>
+Parallelism:      2
+Completions:      <unset>
+Start Time:       Mon, 11 Jan 2016 17:07:59 -0800
+Pods Statuses:    1 Running / 0 Succeeded / 0 Failed
+Pod Template:
+  Labels:       controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                job-name=job-wq-2
+  Containers:
+   c:
+    Image:              gcr.io/exampleproject/job-wq-2
+    Port:
+    Environment:        <none>
+    Mounts:             <none>
+  Volumes:              <none>
+Events:
+  FirstSeen    LastSeen    Count    From            SubobjectPath    Type        Reason            Message
+  ---------    --------    -----    ----            -------------    --------    ------            -------
+  33s          33s         1        {job-controller }                Normal      SuccessfulCreate  Created pod: job-wq-2-lglf8
+
+
+$ kubectl logs pods/job-wq-2-7r7b2
+Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
+Initial queue state: empty=False
+Working on banana
+Working on date
+Working on lemon
+```
+
+<!--
+As you can see, one of our pods worked on several work units.
+-->
+您可以看到，其中的一个 pod 处理了若干个工作单元。
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+<!--
+## Alternatives
+-->
+## 其它
+
+<!--
+If running a queue service or modifying your containers to use a work queue is inconvenient, you may
+want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
+-->
+如果您不方便运行一个队列服务或者修改您的容器用于运行一个工作队列，您可以考虑其它的 [job 模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
+
+<!--
+If you have a continuous stream of background processing work to run, then
+consider running your background workers with a `replicationController` instead,
+and consider running a background processing library such as
+[https://github.com/resque/resque](https://github.com/resque/resque).
+-->
+如果您有连续的后台处理业务，那么可以考虑使用 `replicationController` 来运行您的后台业务，和运行一个类似 [https://github.com/resque/resque](https://github.com/resque/resque) 的后台处理库。
+
+{{% /capture %}}
diff --git a/content/cn/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md
similarity index 100%
rename from content/cn/docs/tasks/manage-daemon/rollback-daemon-set.md
rename to content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md
diff --git a/content/cn/docs/tasks/manage-gpus/scheduling-gpus.md b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
similarity index 100%
rename from content/cn/docs/tasks/manage-gpus/scheduling-gpus.md
rename to content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
diff --git a/content/cn/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
similarity index 100%
rename from content/cn/docs/tasks/manage-hugepages/scheduling-hugepages.md
rename to content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
diff --git a/content/cn/docs/tasks/run-application/deployment-patch-demo.yaml b/content/zh/docs/tasks/run-application/deployment-patch-demo.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/deployment-patch-demo.yaml
rename to content/zh/docs/tasks/run-application/deployment-patch-demo.yaml
diff --git a/content/cn/docs/tasks/run-application/deployment-scale.yaml b/content/zh/docs/tasks/run-application/deployment-scale.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/deployment-scale.yaml
rename to content/zh/docs/tasks/run-application/deployment-scale.yaml
diff --git a/content/cn/docs/tasks/run-application/deployment-update.yaml b/content/zh/docs/tasks/run-application/deployment-update.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/deployment-update.yaml
rename to content/zh/docs/tasks/run-application/deployment-update.yaml
diff --git a/content/cn/docs/tasks/run-application/deployment.yaml b/content/zh/docs/tasks/run-application/deployment.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/deployment.yaml
rename to content/zh/docs/tasks/run-application/deployment.yaml
diff --git a/content/cn/docs/tasks/run-application/gce-volume.yaml b/content/zh/docs/tasks/run-application/gce-volume.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/gce-volume.yaml
rename to content/zh/docs/tasks/run-application/gce-volume.yaml
diff --git a/content/cn/docs/tasks/run-application/mysql-configmap.yaml b/content/zh/docs/tasks/run-application/mysql-configmap.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/mysql-configmap.yaml
rename to content/zh/docs/tasks/run-application/mysql-configmap.yaml
diff --git a/content/cn/docs/tasks/run-application/mysql-deployment.yaml b/content/zh/docs/tasks/run-application/mysql-deployment.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/mysql-deployment.yaml
rename to content/zh/docs/tasks/run-application/mysql-deployment.yaml
diff --git a/content/cn/docs/tasks/run-application/mysql-services.yaml b/content/zh/docs/tasks/run-application/mysql-services.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/mysql-services.yaml
rename to content/zh/docs/tasks/run-application/mysql-services.yaml
diff --git a/content/cn/docs/tasks/run-application/mysql-statefulset.yaml b/content/zh/docs/tasks/run-application/mysql-statefulset.yaml
similarity index 100%
rename from content/cn/docs/tasks/run-application/mysql-statefulset.yaml
rename to content/zh/docs/tasks/run-application/mysql-statefulset.yaml
diff --git a/content/cn/docs/tasks/run-application/rolling-update-replication-controller.md b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md
similarity index 100%
rename from content/cn/docs/tasks/run-application/rolling-update-replication-controller.md
rename to content/zh/docs/tasks/run-application/rolling-update-replication-controller.md
diff --git a/content/cn/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md
similarity index 100%
rename from content/cn/docs/tasks/run-application/run-single-instance-stateful-application.md
rename to content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md
diff --git a/content/cn/docs/tasks/run-application/run-stateless-application-deployment.md b/content/zh/docs/tasks/run-application/run-stateless-application-deployment.md
similarity index 100%
rename from content/cn/docs/tasks/run-application/run-stateless-application-deployment.md
rename to content/zh/docs/tasks/run-application/run-stateless-application-deployment.md
diff --git a/content/cn/docs/tasks/run-application/scale-stateful-set.md b/content/zh/docs/tasks/run-application/scale-stateful-set.md
similarity index 100%
rename from content/cn/docs/tasks/run-application/scale-stateful-set.md
rename to content/zh/docs/tasks/run-application/scale-stateful-set.md
diff --git a/content/cn/docs/tasks/tls/certificate-rotation.md b/content/zh/docs/tasks/tls/certificate-rotation.md
similarity index 100%
rename from content/cn/docs/tasks/tls/certificate-rotation.md
rename to content/zh/docs/tasks/tls/certificate-rotation.md
diff --git a/content/cn/docs/templates/index.md b/content/zh/docs/templates/index.md
similarity index 100%
rename from content/cn/docs/templates/index.md
rename to content/zh/docs/templates/index.md
diff --git a/content/cn/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md
similarity index 100%
rename from content/cn/docs/tutorials/configuration/configure-redis-using-configmap.md
rename to content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md
diff --git a/content/cn/docs/tutorials/kubernetes-basics/_index.html b/content/zh/docs/tutorials/kubernetes-basics/_index.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/_index.html
rename to content/zh/docs/tutorials/kubernetes-basics/_index.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/cluster-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/cluster-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/cluster-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/cluster-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/cluster-intro.html b/content/zh/docs/tutorials/kubernetes-basics/cluster-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/cluster-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/cluster-intro.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/deploy-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/deploy-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/deploy-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/deploy-intro.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/deploy-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/deploy-intro.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/explore-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/explore-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/explore-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/explore-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/explore-intro.html b/content/zh/docs/tutorials/kubernetes-basics/explore-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/explore-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/explore-intro.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/expose-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/expose-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/expose-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/expose-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/expose-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/expose-intro.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/scale-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/scale-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/scale-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/scale-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/scale-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/scale-intro.html
diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
new file mode 100644
index 0000000000000..aeff0243828bd
--- /dev/null
+++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -0,0 +1,136 @@
+<!-- ---
+title: Running Multiple Instances of Your App
+weight: 10
+--- -->
+---
+title: 运行应用程序的多个实例
+weight: 10
+---
+
+<!DOCTYPE html>
+<html lang="en">
+<body>
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<div class="layout" id="top">
+    <main class="content">
+        <div class="row">
+     <div class="col-md-8">
+					<!-- <h3>Objectives</h3> -->
+					<h3>目的</h3>
+                <ul>
+										<!-- <li>Scale an app using kubectl.</li> -->
+										<li>用 kubectl 扩缩应用程序</li>
+                </ul>
+            </div>
+
+            <div class="col-md-8">
+			 <!-- <h3>Scaling an application</h3> -->
+			 <h3>扩缩应用程序</h3>
+
+						<!-- <p>In the previous modules we created a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/"> Deployment</a>,
+							and then exposed it publicly via a <a href="https://kubernetes.io/docs/concepts/services-networking/service/">Service</a>.
+							The Deployment created only one Pod for running our application.  When traffic increases, we will need to scale the application to keep up with  user demand.</p> -->
+						<p>在之前的模块中，我们创建了一个 <a href="http://kubernetes.io/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="http://kubernetes.io/docs/user-guide/services/">Service</a>让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。</p>
+
+						<!-- <p><b>Scaling</b> is accomplished by changing the number of replicas in a Deployment</p> -->
+						<p><b>扩缩</b> 是通过改变 Deployment 中的副本数量来实现的。</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_lined">
+										<!-- <h3>Summary:</h3> -->
+										<h3>小结:</h3>
+                    <ul>
+												<!-- <li>Scaling a Deployment</li> -->
+												<li>扩缩一个 Deployment</li>
+                    </ul>
+                </div>
+                <div class="content__box content__box_fill">
+										<!-- <p><i> You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl run command </i></p> -->
+										<p><i> 在运行 kubectl run 命令时，你可以通过设置 --replicas 参数来设置 Deployment 的副本数。</i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+								<!-- <h2 style="color: #3771e3;">Scaling overview</h2> -->
+								<h2 style="color: #3771e3;">扩缩概述</h2>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-1"></div>
+            <div class="col-md-8">
+                <div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
+                    <ol class="carousel-indicators">
+                        <li data-target="#myCarousel" data-slide-to="0" class="active"></li>
+                        <li data-target="#myCarousel" data-slide-to="1"></li>
+                    </ol>
+                      <div class="carousel-inner" role="listbox">
+                        <div class="item active">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
+                        </div>
+
+                        <div class="item">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
+                        </div>
+                      </div>
+
+                      <a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
+                        <span class="sr-only ">Previous</span>
+                      </a>
+                      <a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
+                        <span class="sr-only">Next</span>
+                      </a>
+
+                    </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+
+                <!-- <p>Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling in will reduce the number of Pods to the new desired state. Kubernetes also supports
+									<a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/">autoscaling</a> of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.</p> -->
+								<p>扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的<a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/">自动缩放</a>，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。</p>
+
+								<!-- <p>Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment.
+									Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.</p> -->
+								<p>运行应用程序的多个实例需要在它们之间分配流量。服务 (Service)有一种负载均衡器类型，可以将网络流量均衡分配到外部可访问的 Pods 上。服务将会一直通过端点来监视 Pods 的运行，保证流量只分配到可用的 Pods 上。</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+										<!-- <p><i>Scaling is accomplished by changing the number of replicas in a Deployment.</i></p> -->
+										<p><i>扩缩是通过改变 Deployment 中的副本数量来实现的。</i></p>
+                </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+								<!-- <p> Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime. We'll cover that in the next module. Now, let's go to the online terminal and scale our application.</p> -->
+								<p>一旦有了多个应用实例，就可以没有宕机地滚动更新。我们将会在下面的模块中介绍这些。现在让我们使用在线终端来体验一下应用程序的扩缩过程。</p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-12">
+								<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> -->
+								<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/cn/docs/tutorials/kubernetes-basics/update-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/update-interactive.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/update-interactive.html
rename to content/zh/docs/tutorials/kubernetes-basics/update-interactive.html
diff --git a/content/cn/docs/tutorials/kubernetes-basics/update-intro.html b/content/zh/docs/tutorials/kubernetes-basics/update-intro.html
similarity index 100%
rename from content/cn/docs/tutorials/kubernetes-basics/update-intro.html
rename to content/zh/docs/tutorials/kubernetes-basics/update-intro.html
diff --git a/content/cn/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
similarity index 100%
rename from content/cn/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
rename to content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
diff --git a/content/cn/docs/tutorials/object-management-kubectl/object-management.md b/content/zh/docs/tutorials/object-management-kubectl/object-management.md
similarity index 100%
rename from content/cn/docs/tutorials/object-management-kubectl/object-management.md
rename to content/zh/docs/tutorials/object-management-kubectl/object-management.md
diff --git a/content/cn/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md
similarity index 95%
rename from content/cn/docs/tutorials/services/source-ip.md
rename to content/zh/docs/tutorials/services/source-ip.md
index c4b4bd34e9e17..77da6af9d071c 100644
--- a/content/cn/docs/tutorials/services/source-ip.md
+++ b/content/zh/docs/tutorials/services/source-ip.md
@@ -116,7 +116,7 @@ command=GET
 ## Type=NodePort 类型 Services 的 Source IP
 
 
-对于 Kubernetes 1.5，发送给类型为 [Type=NodePort](/docs/user-guide/services/#nodeport) Services 的数据包默认进行源地址 NAT。你可以创建一个 `NodePort` Service 来进行测试：
+对于 Kubernetes 1.5，发送给类型为 [Type=NodePort](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以创建一个 `NodePort` Service 来进行测试：
 
 ```console
 $ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
@@ -210,7 +210,7 @@ client_address=104.132.1.79
 ## Type=LoadBalancer 类型 Services 的 Source IP
 
 
-对于 Kubernetes 1.5，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#nodeport) Services 的数据包默认进行源地址 NAT，这是由于所有处于 `Ready` 状态的 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
+对于 Kubernetes 1.5，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是由于所有处于 `Ready` 状态的 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
 
 
 你可以通过在一个 loadbalancer 上暴露这个 source-ip-app 来进行测试。
diff --git a/content/cn/docs/tutorials/stateful-application/Dockerfile b/content/zh/docs/tutorials/stateful-application/Dockerfile
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/Dockerfile
rename to content/zh/docs/tutorials/stateful-application/Dockerfile
diff --git a/content/cn/docs/tutorials/stateful-application/FETCH_HEAD b/content/zh/docs/tutorials/stateful-application/FETCH_HEAD
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/FETCH_HEAD
rename to content/zh/docs/tutorials/stateful-application/FETCH_HEAD
diff --git a/content/cn/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md
similarity index 99%
rename from content/cn/docs/tutorials/stateful-application/basic-stateful-set.md
rename to content/zh/docs/tutorials/stateful-application/basic-stateful-set.md
index 9a5bfd9ed3af7..81a6b1b3566cb 100644
--- a/content/cn/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -107,9 +107,10 @@ web-1     1/1       Running   0         18s
 
 请注意在 `web-0` Pod 处于 [Running和Ready](/docs/user-guide/pod-states) 状态后 `web-1` Pod 才会被启动。
 
-<!-
+<!--
 ## Pods in a StatefulSet
 -->
+
 ## StatefulSet 中的 Pod
 
 
diff --git a/content/cn/docs/tutorials/stateful-application/cassandra-service.yaml b/content/zh/docs/tutorials/stateful-application/cassandra-service.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/cassandra-service.yaml
rename to content/zh/docs/tutorials/stateful-application/cassandra-service.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/cassandra-statefulset.yaml b/content/zh/docs/tutorials/stateful-application/cassandra-statefulset.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/cassandra-statefulset.yaml
rename to content/zh/docs/tutorials/stateful-application/cassandra-statefulset.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/cassandra.md b/content/zh/docs/tutorials/stateful-application/cassandra.md
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/cassandra.md
rename to content/zh/docs/tutorials/stateful-application/cassandra.md
diff --git a/content/cn/docs/tutorials/stateful-application/dev b/content/zh/docs/tutorials/stateful-application/dev
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/dev
rename to content/zh/docs/tutorials/stateful-application/dev
diff --git a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
similarity index 98%
rename from content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
rename to content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
index 5d521f02c71e2..030d2c24e5428 100644
--- a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -15,7 +15,7 @@ approvers:
 
 * [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) 定义持久化磁盘（磁盘生命周期不和 Pods 绑定）。
 * [Services](https://kubernetes.io/docs/concepts/services-networking/service/) 使得 Pods 能够找到其它 Pods。
-* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) 对外暴露 Services。
+* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 对外暴露 Services。
 * [Deployments](http://kubernetes.io/docs/user-guide/deployments/) 确保 Pods 持续运行。
 * [Secrets](http://kubernetes.io/docs/user-guide/secrets/) 保存敏感密码信息。
 
@@ -66,7 +66,7 @@ kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/m
 Kubernetes本质是模块化的，可以在各种环境中运行。但并不是所有集群都相同。此处是本示例的一些要求：
 * 需要 1.2 版本以上的 Kubernetes，以使用更新的特性，例如 PV Claims 和 Deployments。运行 `kubectl version` 来查看你的集群版本。
 * [Cluster DNS](https://github.com/kubernetes/dns) 将被用于服务发现。
-* 一个 [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) 将被用于接入 WordPress。
+* 一个 [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 将被用于接入 WordPress。
 * 使用了 [Persistent Volume Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。你必须创建集群中需要的 Persistent Volumes。本示例将展示两种类型的 volume 的创建方法，但是任何类型的 volume 都是足够使用的。
 
 
diff --git a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml
rename to content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml
rename to content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml
rename to content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/web.yaml b/content/zh/docs/tutorials/stateful-application/web.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/web.yaml
rename to content/zh/docs/tutorials/stateful-application/web.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/webp.yaml b/content/zh/docs/tutorials/stateful-application/webp.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/webp.yaml
rename to content/zh/docs/tutorials/stateful-application/webp.yaml
diff --git a/content/cn/docs/tutorials/stateful-application/zookeeper.md b/content/zh/docs/tutorials/stateful-application/zookeeper.md
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/zookeeper.md
rename to content/zh/docs/tutorials/stateful-application/zookeeper.md
diff --git a/content/cn/docs/tutorials/stateful-application/zookeeper.yaml b/content/zh/docs/tutorials/stateful-application/zookeeper.yaml
similarity index 100%
rename from content/cn/docs/tutorials/stateful-application/zookeeper.yaml
rename to content/zh/docs/tutorials/stateful-application/zookeeper.yaml
diff --git a/content/cn/docs/user-guide/bad-nginx-deployment.yaml b/content/zh/docs/user-guide/bad-nginx-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/bad-nginx-deployment.yaml
rename to content/zh/docs/user-guide/bad-nginx-deployment.yaml
diff --git a/content/cn/docs/user-guide/curlpod.yaml b/content/zh/docs/user-guide/curlpod.yaml
similarity index 100%
rename from content/cn/docs/user-guide/curlpod.yaml
rename to content/zh/docs/user-guide/curlpod.yaml
diff --git a/content/cn/docs/user-guide/deployment.yaml b/content/zh/docs/user-guide/deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/deployment.yaml
rename to content/zh/docs/user-guide/deployment.yaml
diff --git a/content/cn/docs/user-guide/docker-cli-to-kubectl.md b/content/zh/docs/user-guide/docker-cli-to-kubectl.md
similarity index 100%
rename from content/cn/docs/user-guide/docker-cli-to-kubectl.md
rename to content/zh/docs/user-guide/docker-cli-to-kubectl.md
diff --git a/content/cn/docs/user-guide/ingress.yaml b/content/zh/docs/user-guide/ingress.yaml
similarity index 100%
rename from content/cn/docs/user-guide/ingress.yaml
rename to content/zh/docs/user-guide/ingress.yaml
diff --git a/content/cn/docs/user-guide/job.yaml b/content/zh/docs/user-guide/job.yaml
similarity index 100%
rename from content/cn/docs/user-guide/job.yaml
rename to content/zh/docs/user-guide/job.yaml
diff --git a/content/cn/docs/user-guide/jsonpath.md b/content/zh/docs/user-guide/jsonpath.md
similarity index 100%
rename from content/cn/docs/user-guide/jsonpath.md
rename to content/zh/docs/user-guide/jsonpath.md
diff --git a/content/cn/docs/user-guide/kubectl-overview.md b/content/zh/docs/user-guide/kubectl-overview.md
similarity index 100%
rename from content/cn/docs/user-guide/kubectl-overview.md
rename to content/zh/docs/user-guide/kubectl-overview.md
diff --git a/content/cn/docs/user-guide/multi-pod.yaml b/content/zh/docs/user-guide/multi-pod.yaml
similarity index 100%
rename from content/cn/docs/user-guide/multi-pod.yaml
rename to content/zh/docs/user-guide/multi-pod.yaml
diff --git a/content/cn/docs/user-guide/new-nginx-deployment.yaml b/content/zh/docs/user-guide/new-nginx-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/new-nginx-deployment.yaml
rename to content/zh/docs/user-guide/new-nginx-deployment.yaml
diff --git a/content/cn/docs/user-guide/nginx-app.yaml b/content/zh/docs/user-guide/nginx-app.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-app.yaml
rename to content/zh/docs/user-guide/nginx-app.yaml
diff --git a/content/cn/docs/user-guide/nginx-deployment.yaml b/content/zh/docs/user-guide/nginx-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-deployment.yaml
rename to content/zh/docs/user-guide/nginx-deployment.yaml
diff --git a/content/cn/docs/user-guide/nginx-init-containers.yaml b/content/zh/docs/user-guide/nginx-init-containers.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-init-containers.yaml
rename to content/zh/docs/user-guide/nginx-init-containers.yaml
diff --git a/content/cn/docs/user-guide/nginx-lifecycle-deployment.yaml b/content/zh/docs/user-guide/nginx-lifecycle-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-lifecycle-deployment.yaml
rename to content/zh/docs/user-guide/nginx-lifecycle-deployment.yaml
diff --git a/content/cn/docs/user-guide/nginx-probe-deployment.yaml b/content/zh/docs/user-guide/nginx-probe-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-probe-deployment.yaml
rename to content/zh/docs/user-guide/nginx-probe-deployment.yaml
diff --git a/content/cn/docs/user-guide/nginx-secure-app.yaml b/content/zh/docs/user-guide/nginx-secure-app.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-secure-app.yaml
rename to content/zh/docs/user-guide/nginx-secure-app.yaml
diff --git a/content/cn/docs/user-guide/nginx-svc.yaml b/content/zh/docs/user-guide/nginx-svc.yaml
similarity index 100%
rename from content/cn/docs/user-guide/nginx-svc.yaml
rename to content/zh/docs/user-guide/nginx-svc.yaml
diff --git a/content/cn/docs/user-guide/pod-w-message.yaml b/content/zh/docs/user-guide/pod-w-message.yaml
similarity index 100%
rename from content/cn/docs/user-guide/pod-w-message.yaml
rename to content/zh/docs/user-guide/pod-w-message.yaml
diff --git a/content/cn/docs/user-guide/pod.yaml b/content/zh/docs/user-guide/pod.yaml
similarity index 100%
rename from content/cn/docs/user-guide/pod.yaml
rename to content/zh/docs/user-guide/pod.yaml
diff --git a/content/cn/docs/user-guide/redis-deployment.yaml b/content/zh/docs/user-guide/redis-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/redis-deployment.yaml
rename to content/zh/docs/user-guide/redis-deployment.yaml
diff --git a/content/cn/docs/user-guide/redis-resource-deployment.yaml b/content/zh/docs/user-guide/redis-resource-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/redis-resource-deployment.yaml
rename to content/zh/docs/user-guide/redis-resource-deployment.yaml
diff --git a/content/cn/docs/user-guide/redis-secret-deployment.yaml b/content/zh/docs/user-guide/redis-secret-deployment.yaml
similarity index 100%
rename from content/cn/docs/user-guide/redis-secret-deployment.yaml
rename to content/zh/docs/user-guide/redis-secret-deployment.yaml
diff --git a/content/cn/docs/user-guide/run-my-nginx.yaml b/content/zh/docs/user-guide/run-my-nginx.yaml
similarity index 100%
rename from content/cn/docs/user-guide/run-my-nginx.yaml
rename to content/zh/docs/user-guide/run-my-nginx.yaml
diff --git a/content/cn/docs/whatisk8s.md b/content/zh/docs/whatisk8s.md
similarity index 100%
rename from content/cn/docs/whatisk8s.md
rename to content/zh/docs/whatisk8s.md
diff --git a/layouts/shortcodes/language-repos-list.html b/layouts/shortcodes/language-repos-list.html
deleted file mode 100644
index 293efa1ffc942..0000000000000
--- a/layouts/shortcodes/language-repos-list.html
+++ /dev/null
@@ -1,38 +0,0 @@
-{{- $languages := .Site.Home.AllTranslations }}
-<table>
-    <thead>
-        <tr>
-            <th>
-                Language
-            </th>
-            <th>
-                Language code
-            </th>
-            <th>
-                Repository
-            </th>
-        </tr>
-    </thead>
-    <tbody>
-        {{- range $languages.ByWeight }}
-        {{- $name := .Language.LanguageName }}
-        {{- $code := string .Language }}
-        {{- $repo := printf "https://github.com/%s" (index .Site.Data.repos $code) }}
-        <tr>
-            <td>
-                <a href="{{ .Permalink }}">
-                    {{ $name }}
-                </a>
-            </td>
-            <td>
-                <code>{{ $code }}</code>
-            </td>
-            <td>
-                <a href="{{ $repo }}">
-                    {{ $repo }}
-                </a>
-            </td>
-        </tr>
-        {{- end }}
-    </tbody>
-</table>
\ No newline at end of file