Sync up between dev-1.18 and master branches (#19055)

* Fixed outdated ECR credential debug message (#18631) * Fixed outdated ECR credential debug message The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3: - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - `aws_credentials.go:116] Got ECR credentials from ECR API for <Your ECR AWS Account ID>.dkr.ecr.us-east-1.amazonaws.com` This is based on the kubelet source code: https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91 This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue. * Update content/en/docs/concepts/containers/images.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix deployment name in docs/tasks/administer-cluster/dns-horizontal-autoscaling.md (#18772) * ru/docs/tutorials/hello-minikube.md: sync with English translation. (#18687) * content/ru/docs/concepts/_index.md: use English names for kinds. (#18613) * Fix French typo in "when" section (#18786) * First Japanese l10n work for release-1.16 (#18790) * Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710) * Translate concepts/services-networking/connect-applications-service/ into Japanese * Apply review * Translate content/ja/docs/tasks/_index.md into Japanese (#17789) * add task index * huge page * ja-docs: Update kops Installation Steps (#17804) * Update /ja/docs/tasks/tools/install-minikube/ (#17711) * Update /ja/docs/tasks/tools/install-minikube/ * Apply review * Apply review * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160) * copy from content/en/docs/tasks/configure-pod-container/ to ja * translate assign-cpu-resource.md in Japanese * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update assign-cpu-resource.md ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく * fix translation "Pod scheduling is based on requests." の箇所。 requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述 * Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794) * ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * little fix (#18135) * update index (#18136) * Update /ja/docs/setup/_index.md (#18139) * Update /ja/docs/tasks/tools/install-kubectl/ (#18137) * update /docs/ja/tasks/tools/install-kubectl/ * fix mongon * apply reveiw * Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141) * Update feature agete * tidy up feature gates list * translate new lines * table caption * blank * する -> します * apply review * fix broken link * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * update translation * remove line * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * rollpack * Update /ja/docs/concepts/services-networking/service/ (#18138) * update /ja/docs/concepts/services-networking/service/ * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * consider Endpoints as a Kubernetes resource * full * Update content/ja/docs/concepts/_index.md (#18145) * Update concepts * control plane * apply review * fix bold (#18165) * Update /ja/docs/concepts/overview/components.md (#18153) * update /ja/docs/concepts/overview/components.md * some japanese docs are already there * translate prepend * apply upstream changes (#18278) * Translate concepts/services-networking/ingress into Japanese #17741 (#18234) * ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * Update pod overview in Japanese (#18277) * Update pod-overview * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ノード * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796) * ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans:conetent/ja/casestudies/nav (#18450) * Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395) * Translate tasks/debug-application-cluster/debug-service/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Change all `Pods` to `Pod` and `Endpoints` to `Endpoint` * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Updated content pointed out in review * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review * Apply suggestions form review * Apply suggestions from review * Apply suggestions from review * Apply suggestions from code review Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200) * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese * Apply suggestions from code review between L1 an L120 by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update CustomResourceDefinition not to localize into Japanese * Revert the link to customresourcedefinitions to English Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py and inductor Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply a suggestion from review by inductor * Apply a suggestion from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173) * copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese Guaranteed, Burstable, BestEffortは用語として存在するので訳さない Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285) * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Translated kubectl cheet sheet. * Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Modify translation for casestudies (#18767) * modify terminology * add ten * update translation * update * update * update * fix typo (#18769) * remove english comment (#18770) * ja-trans:conetent/ja/casestudies/spotify (#18451) * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Updated with the proposal from inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Updated with inductor 's proposal Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate Japanese headers (#18776) * translate headers * add index for references * Update content/ja/docs/setup/production-environment/tools/_index.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * translate controller Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * ja-docs: translate install-kubeadm into Japanese (#18198) * ja-docs: translate install-kubeadm into Japanese * translate table title in install-kubeadm to Japanese * update kubeadm install doc * remove extra spaces * fix translation miss * translate url title into japanese * fix translation miss * remove line break in sentence and translate title * remove extra line break * remove extra line break * fix translation miss Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> * delete zh SEE ALSO(51-54) (#18788) * Added missing brackets in markdown (#18783) * Fix broken links in api_changes doc (#18743) * fix jump (#18781) * fix redundant note (#18780) * Fix typo: default-manager -> default-scheduler (#18709) like #18649 #18708 * fix issue #18738 (#18773) Signed-off-by: Dominic Yin <yindongchao@inspur.com> * Correct description of kubectl (#18172) * Correct description of kubectl Given that `kubectl` is not a [command line interface (CLI)](https://en.wikipedia.org/wiki/Command-line_interface), I suggest calling it what it is -- a control utility (ctl = control). The term "tool" is commonly used in place of "utility," including the `kubectl` docs. A CLI presents the user with a command prompt at which the user can enter multiple command lines that a command-line interpreter interprets and processes. Think of `bash`, `emacs`, or a SQL shell. Since `kubectl` is not run in a shell, it is not a CLI. Here are related docs that correctly refer to `kubectl` as a "command-line tool": - https://kubernetes.io/docs/reference/tools/#kubectl - https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-kubectl - https://kubernetes.io/docs/tasks/tools/install-kubectl/ - https://kubernetes.io/docs/reference/kubectl/kubectl/ * Update content/en/docs/reference/kubectl/overview.md Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Add blog post: Reviewing 2019 in Docs (#18662) Tiny fix Feedback from onlydole Add missing link Incremental fixes Revise Jim's job title Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md Co-Authored-By: Celeste Horgan <celeste@cncf.io> Feedback from celeste, change date * Update OWNERS_ALIASES (#18803) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> * blog: introduce CSI support for ephemeral inline volumes (#16832) * csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI drivers already support it (soon...). * csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume) * csi-ephemeral-inline-volumes: add examples and next steps * csi-ephemeral-inline-volumes: rename file, minor edits * csi-ephemeral-inline-volumes: include Docker example * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md (#18062) * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-22-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revert "Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)" (#18805) This reverts commit 2c4545e105. * add blog k8s on mips (#18795) * add blog k8s on mips * modify english title to chinese * modify some error * Remove user-journeys legacy content #18615 (#18779) * Use monospace for HostFolder and VM in the French Minikube setup guide. (#18749) * Add French version of persistent volume page concept page (#18706) * Add French version of persistent volume page concept page * Fix * Fix * Fix * Fix * sync content/zh/docs/reference/issues-security/ en zh (#18727) * update zh-translation: /docs/concepts/storage/volume-snapshots.md (#18650) * Clean up user journeys content for zh (#18815) * Followup fixes for: Add resource version section to api-concepts (#18069) * Followup fixes for: Add resource version section to api-concepts documentation * Apply feedback * Apply feedback * Switch paragraph to active voice * Add Community and Code of Conduct for ID (#18828) * Add additional ways to contribute part to update zh doc (#18762) * Add additional ways to contribute part to update zh doc * Add original English text * Update content/zh/docs/contribute/_index.md Co-Authored-By: chentanjun <tanjunchen20@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> * Clean up extensions/v1beta1 in docs (#18839) * fix an example path (#18848) * Translating network plugins (#17184) * Fix for a typo (#18822) * tą instalację -> tę instalację / (https://sjp.pwn.pl/poradnia/haslo/te-czy-ta;1598.html) (#18801) * Fix typo in Scalability section (#18866) The phrase `very larger` is not valid, it is supposed to be either `very large` or `larger`. Propose to have it `very large`. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add Polish translation of Contribute index page (#18775) Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Clean up extensions/v1beta1 in docs (#18838) * Add Indonesian Manage Compute Resources page (#18468) * Add Indonesian Manage Compute Resources page * Updates to id Manage Compute Resources page * Add DaemonSet docs ID localization (#18632) Signed-off-by: giovanism <giovanism@outlook.co.id> * Fix typo in en/docs/contribute/style/content-guilde.md (#18862) * partial fix for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted #18411 (#18875) * See Also removed file 31 * see also removed file 32 * see also removed file 33 * see also removed file 34 * see also removed file 35 * Modify pod.md (#18818) website/content/ko/docs/concepts/workloads/pods/pod.md 23 line 쿠버네티스는는 -> 쿠버네티스는 modify * remove $ following the style guide (#18855) * Add Hyperlink to Kubernetes API (#18852) * Drive by copy edit of blog post (#18881) * Medium copy edit. * more fixes * Translate Events Calendar (#18860) * Adding Bahasa Indonesia translation for Device Plugin page #18676 (#18676) Co-Authored-By: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> * change escaped chars to markdown (#18858) Helps to keep doc clean for long term * Fix header layout on Safari (#18888) * Fix references to sig-docs-l10n-admins (#18661) * Add French deployment concept page (#18516) * Add French deployment concept page * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix ZH security aliases (#18895) * disable simplytunde as an approver due to inactivity. (#18899) Always welcome to come back if able to become active again Signed-off-by: Brad Topol <btopol@us.ibm.com> * install container runtimes without prompts (#18893) In Kubernetes docs, all of the packages that are required to set up the Kubernetes are installed without requiring any prompts through the package manager (like apt or yum) except for the container runtimes. https://kubernetes.io/docs/setup/production-environment/container-runtimes/ So, it would be better to have these installations with prompts (yes) disabled. * Fix small typos (#18886) * Fix small typos Small typos noticed and fixed in: - configure-upgrade-etcd.md - reconfigure-kubelet.md Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Rephrase a paragraph on etcd upgrade en\docs\tasks\administer-cluster\configure-upgrade-etcd.md Following a suggestion in #18886, I've rephrased a sentence on etcd upgrade prerequisites. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Clean up extensions/v1beta1 in docs (#18841) * Update _index.md (#18825) * Run minikube docker-env in a shell-independent way (#18823) * doc: correct pv status for pv protection example. (#18816) * Small editorial fixes in glossary entries (#18807) * Small editorial fixes in glossary entries * Revert the wording in the glossary term for proxy * fix doc conflict regarding postStart (#18806) * kubeadm: improvements to the cert management documentation (#18397) - move the sections about custom certificates and external CA to the kubeadm-certs page - minor cleanups to the kubeadm-certs page, including updated output for the check-expiration command - link the implementation details page to the new locations for custom certs and external CA * fix doc conflict regarding postStart * Grammar (#18785) * grammar: 'to' distributes over 'or' * grammar: reword per app.grammarly.com * grammar: simplify from app.grammarly.com * spelling: etc. * feat: add ephermeral container approach inside pod debug page. (#18754) * doc: add pod security policy reference link to document. (#18729) * doc: add pod security policy reference link to document. * doc: add what's next for pod-security-policy ref. * Revise version requirements (#18688) Assume that the reader is running a version of Kubernetes that supports the Secret resource. * en: Remove kubectl duplicate example (#18656) With #16974 and the removal of --include-uninitialized flag, the second and third examples of kubectl delete become equal, thus leading to duplication and being confusing. Suggest to remove the duplicate and replace it with another example in the future if needed. Observed in v1.16 and v1.17 documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Fix typo for tasks/access-kubernetes-api/configure-aggregation-layer.md (#18652) * Unify runtime references (#18493) - Use the glossary to correctly reference runtimes - Updated runtime class documentation for CRI-O - Removed rktlet from runtimes since its EOL Signed-off-by: Sascha Grunert <sgrunert@suse.com> * Clean up admission controller deprecation example (#18399) * sync zh-trans content/zh/docs/concepts/workloads/pods/ephemeral-containers.md (#18883) * Remove redundant information when deploy flannel on kubernetes include windows node (#18272) * sync zh-trans content/zh/docs/concepts/workloads/pods/pod-overview.md (#18882) * partial fix for for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted (#18879) * see also removed from file 36 * see also removed from file 37 * see also removed from file 38 * see also removed from file 39 * see also removed from file 40 * update zh content/zh/docs/contribute/style/write-new-topic.md (#18859) * sync zh-trans /docs/concepts/_index.md and /docs/concepts/example-concept-template.md (#18863) * See also removed file 56 & 57 (#18912) * see also removed file 56 * see also removed file 57 * Third Korean L10n Work For Release 1.17 (#18915) * Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668) * Update to Outdated files in dev-1.17-ko.3 branch. (#18580) * Translate content/ko/docs/concepts/services-networking/service in Korean (#18195) * Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721) * Translate controllers/garbage-collection.md in Korean. (#18595) Co-Authored-by: Seokho Son <shsongist@gmail.com> Co-Authored-by: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-by: Jesang Myung <jesang.myung@gmail.com> Co-Authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> * clean up makefile, config (#18517) Added target for createversiondirs (shell script) in Makefile. updates for tagged release regenerate api ref, rm Makefile_temp add parens to pip check * Improve Russian translation of Home page (#17841) * Improve Russian translation of Home page * Update i18n/ru.toml Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> * update ref link for v1.16 (#18837) Related to issue #18820. remove links to prev API refs * Cleanup user journeys related configs and scripts (#18814) * See also removed file 81 to 85 (#18909) * see also removed file 81 * see also removed file 82 * see also removed file 83 * see also removed file 84 * see also removed file 85 * See also removed file 65 to 70 (#18908) * see also removed file 65 * see also removed file 66 * see also removed file 67 * see also removed file 68 * see also removed file 69 * see also removed file 70 * Translate Task index page into Polish (#18876) Co-Authored-By: Karol Pucyński <kpucynski@gmail.com> Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Document dry-run authorization requirements (#18235) * Document dry-run write access requirement. - Add section on dry-run authorization - Refer to dry-run authorization for diff - Consistently hyphenate dry-run * Update content/en/docs/reference/using-api/api-concepts.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * reword storage release note to match the change in k/k PR #87090 (#18921) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18868) * See also removed file 60 to 63 (#18907) * see also removed file 60 * see also removed file 61 * see also removed file 62 * see also removed file 63 * See also removed file 91 to 95 (#18910) * see also removed file 91 * see also removed file 93 * see also removed file 94 * see also removed file 95 * content/zh/docs/concepts/workloads/pods/podpreset.md (#18870) * fix: fixed eating initial 2 spaces inside code. (#18914) * Update Calico section of kubeadm install guide (#18821) * Update Calico section of kubeadm install guide * Address review feedback * See also removed file 96 to 100 (#18911) * see also removed file 96 * see also removed file 97 * see also removed file 98 * see also removed file 99 * see also removed file 100 * repair zh docs in kubeadm (#18949) * repair zh docs about kubeadm (#18950) * Update apparmor.md (#18951) * Update basic-stateful-set.md (#18952) * Add missing hyperlink for pod-overhead (#18936) * Update service.md (#18480) make article reads more smoothly * zh-trans update content/zh/docs/concepts/workloads/controllers/deploy… (#18657) * zh-trans update content/zh/docs/concepts/workloads/controllers/deployment.md * zh-trans update content\zh\docs\concepts\workloads\controllers\deployment.md * Update source-ip documentation (#18760) * sync zh-trans /docs/concepts/workloads/pods/pod.md (#18880) * sync zh-trans /docs/concepts/workloads/controllers/cron-jobs.md and /docs/concepts/workloads/controllers/daemonset.md (#18864) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18867) * Add a French version of Secret concept page (#18604) * Add a French version of Secret concept page * Fix * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Aurélien Perrier <aperrier@universe.sh> * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> * (refactor): Corrections (grammatical) in service.md file (#18944) * Update service.md * Fixed the invaild changes Signed-off-by: Udit Gaurav <uditgaurav@gmail.com> * Update container-runtimes.md (#18608) for debian install of docker, also install gnupg2 for apt-key add to work * Fix that dual-stack does not require Kubenet specifically (#18924) * Fix that dual-stack does not require Kubenet specifically Rather it requires a network plugin that supports dual-stack, and others are available, including Calico. * Update content/en/docs/tasks/network/validate-dual-stack.md Added link to doc about network plugins Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Revert "Configurable Scaling for the HPA (#18157)" (#18963) This reverts commit 5dbfaafe1a. * Update horizontal-pod-autoscale-walkthrough.md (#18960) Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.` * doc: add link for type=LoadBalancer service in tutorial. (#18916) * Typo fix (#18830) * sync zh-trans content/zh/docs/concepts/workloads/controllers/statefulset.md (#18869) * Revise pull request template (#18744) * Revise pull request template * Reference compiled docs in PR template Refer readers to https://k8s.io/contribute/start/ This keeps the template short, and it lets Hugo use templating for the current version. * Update certificates.md (#18970) * Add web-ui-dashboard to French (#17974) * Add web-ui-dashboard to French * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> * Added a translated code of conduct (#18981) * Added a translated code of conduct * fixed some minor mistakes and capitalization * Moved to informal speech * Translate the contribute advanced page to French (#13425) * Translate the contribute advanced page to French * Corrections * Correction * Correction * Correction * Correction * Correction * Fix typo in hello-minikube.md (#18991) * Add note for LB behaviour for cordoned nodes. (#18784) * Add note for LB behaviour for cordoned nodes. See also https://github.com/kubernetes/kubernetes/issues/65013 This is a reasonably common pitfall: `kubectl cordon <all nodes>` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late. * Update with feedback * Add KIND as the options for spinning up a test kubernetes environment (#17860) * fix typo in /ja/docs/concepts/workloads/pods/init-containers (#18997) * hide some original comments in translate docs (#18986) * hide original comment * hide some original comments * Fix code of conduct title (#19006) * Added a note about built-in priority-classes (#18979) * Added a note about build-in priority-classes * Update content/en/docs/concepts/configuration/pod-priority-preemption.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Add description for TTL (#19001) * Fix whitespace on deployment page (#18990) * Add details to the API deprecations blog post (#19014) * Document list/map/structType and listMapKeys (#18977) These markers where introduced to describe topology of lists, maps, structs - primarily in support of server-side apply. Secondarily, a small typo fix:) * Remove "Unschedulable" pod condition type from the pod lifecycle docs (#18956) The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type. * Revise “Encrypting Secret Data at Rest” (#18810) * Drop reference to old Kubernetes versions At the time of writing, Kubernetes v1.13 is the oldest supported version, and encryption-at-rest is no longer alpha. * Tidy whitespace * Add table caption * Set metadata for required Kubernetes version * maintain the current relative path when switching to other site versions (#18871) * Update kubectl create configmap section (#18885) * Add common examples to Service Topology documentation (#18712) * service topology: add missing 'enabling service topology' page Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * service topology: add common examples Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * updating contrib for ref docs (#18787) more cleanup * fix translate docs format (#19018) * Update nodes.md (#19019) * Translate Contribute index page into Russian (#19022) * Added german translation for Addons page (#19010) * Added german translation for Addons page * Smaller adjustments * removed a english leftover-sentence * consistent spelling of "Add-Ons" * Removed english entry for CoreDNS * Update content/de/docs/concepts/cluster-administration/addons.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Translated a heading Co-authored-by: Tim Bannister <tim@scalefactory.com> * (fix) Removed `-n test` from `kubectl get pv` command (#18877) - PV are cluster scoped rather than namespaced scope - So, there is no need to list it by namespace Signed-off-by: Aman Gupta <aman.gupta@mayadata.io> * Link to setup page about Kind (#18996) Link from /docs/setup/ to /docs/setup/learning-environment/kind/ now that the target page exists. * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#18808) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update and rename Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md to 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revise glossary entry for Device Plugin (#16291) * Document control plane monitoring (#17578) * Document control plane monitoring * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Merge controller-metrics.md into monitoring.md Co-authored-by: Tim Bannister <tim@scalefactory.com> * Document none driver compatibility with non docker runtime. (#17952) * Refined unclear sentence on 3rd party dependencies (#18015) * Refined unclear sentence on 3rd party dependencies I reworded the sentence on third party dependencies a bit in order to make it more sound * Update content/en/docs/concepts/security/overview.md Sounds much better Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Improve network policies concept (#18091) * Adopt website style guidelines * Tweak wording Co-Authored-By: cmluciano <cmluciano@cruznet.org> * Make sample NetworkPolicies downloadable Co-authored-by: cmluciano <cmluciano@cruznet.org> * clean up secret generators (#18320) * Use built-in version check & metadata (#18542) * Reword kubelet live reconfiguration task (#18629) - Revise version requirements - Use glossary tooltips in summary - Use sentence case for headings - Write kubelet in lowercase where appropriate - Add “What's next” section * fix: add dns search record limit note. (#18913) * Remove duplicate content: Roles & Responsibilities (#18920) * Remove duplicate content: Roles & Responsibilities Signed-off-by: Celeste <celeste@cncf.io> Address feedback Signed-off-by: Celeste <celeste@cncf.io> * Apply suggestions from review Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> * Link to contribution guidelines Signed-off-by: Celeste Horgan <celeste@cncf.io> * Address PR feedback Signed-off-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Fix of pull request #18960 (#18974) * Fix of pull request #18960 * Add yaml configuration file snippets * Remove redundant code snippet for command * Update cheatsheet.md (#18975) * Update cheatsheet.md "List all pods in the namespace, with more details" command corrected by adding --all-namespaces * Update content/en/docs/reference/kubectl/cheatsheet.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Correct description of Knitter CNI plugin (#18983) * Add Elastic metricbeat to examples of DaemonSets and rename logstash (#19024) * Add Elastic metricbeat to examples of DaemonSets The URL points to the docs related to how to configure metricbeat on k8s * Filebeat is the next thing * Separated commands from output (#19023) * Update KubeCon URLs (#19027) The URLs had changed (and were being redirected). Also, added parameters to better identify the traffic source. * remove see also and close issue (#19032) * sync zh-trans content/zh/docs/concepts/workloads/controllers/garbage-collection.md (#18865) * zh trans /docs/reference/access-authn-authz/extensible-admission-controllers.md (#18856) * Update zh/docs/concepts/services-networking/dns-pod-service.md#pods (#18992) * Adding contribution best practice in contribute docs (#18059) * Add kubectl patch example with quotes on Windows (#18853) * Add kubectl patch example with quotes on Windows When running the `kubectl patch` example, on Windows systems you get an error when passing the patch request in single quotes. Passing it in double quotes with the inner ones escaped produced the desired behavior as is in the example given for Linux systems. I've added a small note for Windows users to have that in mind. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Use Hugo note shortcode Windows note is placed inside a [shortcode](https://kubernetes.io/docs/contribute/style/style-guide/#shortcodes) to be consistent with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove shell Markdown syntax I've removed the shell syntax from the Windows example and have changed the description to be the same as the one used in [jsonpath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) document to be more consistent. The jsonpath example uses cmd syntax, though it is note inside a note shortcode, therefore I've opted out of using any syntax as it seems to break rendering inside the shortcode. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add cmd markdown syntax and fix order list I've tested this locally with `make docker-serve` on my Linux machine and finally things are looking better, I've managed to address these two issues: - the Windows example is now inside `note` shortcode and also the cmd syntax renders correctly on the page - the list of steps broke after the first one, I've indented a paragraph and now the steps are in the expected order Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove command prompt from example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included when showing an example. This commit removes it for consistency with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * cleanup /docs/concepts/workloads/pods/pod-lifecycle/ (#19009) * update nodes.md (#18987) 将“用量低”更改为“可用量低”，避免歧义 * Remove command prompt from Windows example (#18906) * Remove command prompt from Windows example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included in the examples. Removing the Windows command prompt from the jsonpath example. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Put Windows example inside note shortcode I'm putting the Windows example in a Hug note shortcode to be consistent with the rest of the documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Updated CHANGELOG-11 link (#19036) * update command used to create deployment (#19005) The previous one was showing a deprecation warning when used. * Update Korean localization guide (#19004) rev1-Update Korean localization guide * docs: fix broken etcd's official documents link (#19021) * Update automated-tasks-with-cron-jobs.md (#19043) Co-authored-by: Xin Chen <xchen@opq.com.au> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: lemon <lemonli@users.noreply.github.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Olivier Cloirec <5033885+clook@users.noreply.github.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> Co-authored-by: hato wang <26351545+wyyxd2017@users.noreply.github.com> Co-authored-by: xieyanker <xjsisnice@gmail.com> Co-authored-by: zhouya0 <50729202+zhouya0@users.noreply.github.com> Co-authored-by: littleboy <zhaoze01@inspur.com> Co-authored-by: camper42 <camper.xlii@gmail.com> Co-authored-by: Dominic Yin <hi@ydcool.me> Co-authored-by: Steve Bang <stevebang@gmail.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Ryan McGinnis <ryanmcginnis@users.noreply.github.com> Co-authored-by: Shunde Zhang <shunde.p.zhang@gmail.com> Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Patrick Ohly <patrick.ohly@intel.com> Co-authored-by: Eugenio Marzo <eugenio.marzo@yahoo.it> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> Co-authored-by: TimYin <shiguangyin@inspur.com> Co-authored-by: Shivang Goswami <shivang.goswami@infosys.com> Co-authored-by: Fabian Baumanis <fabian.baumanis@gmx.de> Co-authored-by: Rémy Léone <remy.leone@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: helight <helight@helight.info> Co-authored-by: Jie Shen <drfish.me@gmail.com> Co-authored-by: Joe Betz <jpbetz@google.com> Co-authored-by: Danni Setiawan <danninov@users.noreply.github.com> Co-authored-by: GoodGameZoo <gaoguangze111@gmail.com> Co-authored-by: makocchi <makocchi@gmail.com> Co-authored-by: babang <prabangkoro@users.noreply.github.com> Co-authored-by: Sharjeel Aziz <sharjeel.aziz@gmail.com> Co-authored-by: Wojtek Cichoń <wojtek.cichon@protonmail.com> Co-authored-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> Co-authored-by: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Yudi A Phanama <11147376+phanama@users.noreply.github.com> Co-authored-by: Giovan Isa Musthofa <giovanism@outlook.co.id> Co-authored-by: Park Sung Taek <tjdxor8223@gmail.com> Co-authored-by: Kyle Smith <kylessmith@protonmail.com> Co-authored-by: craigbox <craig.box@gmail.com> Co-authored-by: Afrizal Fikri <laser.survivor@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Anshu Prateek <333902+anshprat@users.noreply.github.com> Co-authored-by: Sergei Zyubin <sergei@crate.io> Co-authored-by: Christoph Blecker <admin@toph.ca> Co-authored-by: Brad Topol <btopol@us.ibm.com> Co-authored-by: Venkata Harshavardhan Reddy Allu <venkataharshavardhan_ven@srmuniv.edu.in> Co-authored-by: KYamani <yamani.kamel@gmail.com> Co-authored-by: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Co-authored-by: Jacky Wu <Colstuwjx@gmail.com> Co-authored-by: Gerasimos Dimitriadis <gedimitr@gmail.com> Co-authored-by: Rajat Toshniwal <rnt.rajat@gmail.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Sascha Grunert <sgrunert@suse.com> Co-authored-by: wawa <xiaozhang0210@hotmail.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Karen Bradshaw <kbhawkey@gmail.com> Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Julian V. Modesto <julianvmodesto@gmail.com> Co-authored-by: Jeremy L. Morris <jeremylevanmorris@gmail.com> Co-authored-by: Casey Davenport <caseydavenport@users.noreply.github.com> Co-authored-by: zhanwang <zhanw15@gmail.com> Co-authored-by: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Co-authored-by: harleyliao <357857613@qq.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> Co-authored-by: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com> Co-authored-by: Rene Luria <rene@luria.ch> Co-authored-by: Neil Jerram <neiljerram@gmail.com> Co-authored-by: Arjun <arjunrn@users.noreply.github.com> Co-authored-by: Katarzyna Kańska <katarzyna.m.kanska@gmail.com> Co-authored-by: Laurens Versluis <lfdversluis@users.noreply.github.com> Co-authored-by: Ray76 <rayfoo55@gmail.com> Co-authored-by: Alexander Zimmermann <7714821+alexzimmer96@users.noreply.github.com> Co-authored-by: Christian Meter <cmeter@googlemail.com> Co-authored-by: MMeent <boekewurm@gmail.com> Co-authored-by: RA489 <rohit.anand@india.nec.com> Co-authored-by: Akira Tanimura <autopp.inc@gmail.com> Co-authored-by: Patouche <Patouche@users.noreply.github.com> Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Maria Ntalla <maria.ntalla@gmail.com> Co-authored-by: Marko Lukša <marko.luksa@gmail.com> Co-authored-by: John Morrissey <jwm@horde.net> Co-authored-by: Andrew Sy Kim <kim.andrewsy@gmail.com> Co-authored-by: ngsw <ngsw@ngsw.jp> Co-authored-by: Aman Gupta <aman.gupta@mayadata.io> Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com> Co-authored-by: tom1299 <tom1299@users.noreply.github.com> Co-authored-by: cmluciano <cmluciano@cruznet.org> Co-authored-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Prasad Honavar <prasadhonavar@gmail.com> Co-authored-by: Sam <sammcj@users.noreply.github.com> Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com> Co-authored-by: Dan Kohn <dan@linuxfoundation.org> Co-authored-by: vishakha <54327666+vishakhanihore@users.noreply.github.com> Co-authored-by: liyinda246 <liyinda0000@163.com> Co-authored-by: Kabir Kwatra <kabir@kwatra.me> Co-authored-by: Armand Grillet <2117580+armandgrillet@users.noreply.github.com> Co-authored-by: Junwoo Ji <jydrogen@gmail.com> Co-authored-by: rm <rajib.jolite@gmail.com>
2020-02-11 04:15:53 +05:30
parent fb1c0e8b77
commit 63f30b086a
313 changed files with 18391 additions and 6502 deletions
@@ -37,10 +37,10 @@ To work with Kubernetes, you use *Kubernetes API objects* to describe your clust
 要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。

 <!--
-Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator (PLEG). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
+Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
 -->

-一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器( PLEG )，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：
+一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：

 <!--
 * The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
@@ -49,7 +49,7 @@ Once you've set your desired state, the *Kubernetes Control Plane* makes the clu
  * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
 -->

-*  **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
+* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，主控组件通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
 * 集群中的每个非 master 节点都运行两个进程：
  * **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
  * **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
@@ -61,10 +61,10 @@ Once you've set your desired state, the *Kubernetes Control Plane* makes the clu
 ## Kubernetes 对象

 <!--
-Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details.
+Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
 -->

-Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
+Kubernetes 包含若干用来表示系统状态的抽象层，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。有关更多详细信息，请参阅[了解 Kubernetes 对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)。

 <!--
 The basic Kubernetes objects include:
@@ -78,15 +78,15 @@ The basic Kubernetes objects include:
 * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)

 <!--
-In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include:
+Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
 -->

-另外，Kubernetes 包含大量的被称作*控制器（controllers）* 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：
+Kubernetes 也包含大量的被称作 [Controller](/docs/concepts/architecture/controller/) 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：

-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
 * [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
 * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
+* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
 * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)

 <!--
@@ -137,17 +137,6 @@ The nodes in a cluster are the machines (VMs, physical servers, etc) that run yo

 集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。

-<!--
-#### Object Metadata
-
-
-* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
-->
-
-#### 对象元数据
-
-
-* [注解](/docs/concepts/overview/working-with-objects/annotations/)

 {{% /capture %}}

@@ -111,7 +111,7 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
 | `Ready`        | 表示节点是健康的并已经准备好接受 pods；`False` 表示节点不健康而且不能接受 pods；`Unknown` 表示节点控制器在最近 40 秒内没有收到节点的消息 |
 | `MemoryPressure`    | `True` 表示节点存在内存压力 -- 即节点内存用量低，否则为 `False` |
 | `PIDPressure`    | `True` 表示节点存在进程压力 -- 即进程过多；否则为 `False` |
-| `DiskPressure`    | `True` 表示节点存在磁盘压力 -- 即磁盘用量低，否则为 `False` |
+| `DiskPressure`    | `True` 表示节点存在磁盘压力 -- 即磁盘可用量低，否则为 `False` |
 | `NetworkUnavailable`    | `True` 表示节点网络配置不正确；否则为 `False` |

 <!--
@@ -29,7 +29,7 @@ It does not mean that there is a file named `kubeconfig`.
 {{< /note >}}
 --->
 {{< note >}}
-注意：用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件
+用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件
 {{< /note >}}

 <!--
@@ -55,7 +55,7 @@ You need to make sure that the `PodOverhead`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is off by default)
 across your cluster. This means:
 -->
-您需要确保在集群中启用了 `PodOverhead` [特性门](默认情况下是关闭的)。这意味着：
+您需要确保在集群中启用了 `PodOverhead` [特性门](/docs/reference/command-line-tools-reference/feature-gates/)（默认情况下是关闭的）。这意味着：

 <!--
 - in {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
@@ -1,13 +1,30 @@
 ---
 title: 概念模板示例
-approvers:
- chenopis
 content_template: templates/concept
+toc_hide: true
 ---

+<!--
+---
+title: Example Concept Template
+content_template: templates/concept
+toc_hide: true
+---
+-->
+
 {{% capture overview %}}

-**注意:** 注意为新文档 [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) 。
+<!--
+Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
+-->
+
+{{< note >}}
+确保您的新文档也可以[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。
+{{< /note >}}
+
+<!--
+This page explains ...
+-->

 本页解释了 ...

@@ -15,22 +32,43 @@ content_template: templates/concept

 {{% capture body %}}

+<!--
+## Understanding ...
+-->
 ## 了解 ...

+<!--
+Kubernetes provides ...
+-->
 Kubernetes 提供 ...

+<!--
+## Using ...
+-->
 ## 使用 ...

+<!--
+To use ...
+-->
 使用 ...

 {{% /capture %}}

 {{% capture whatsnext %}}

+
+<!--
+**[Optional Section]**
+-->
 **[可选章节]**

-* 了解更多 [Writing a New Topic](/docs/home/contribute/write-new-topic/)。
-* 查看 [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) 了解如何使用本模板。
+
+<!--
+* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
+* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
+-->
+* 了解有关[撰写新主题](/docs/home/contribute/write-new-topic/)的更多信息。
+* 有关如何使用此模板的信息，请参阅[使用页面模板 - 概念模板](/docs/home/contribute/page-templates/#concept_template)。

 {{% /capture %}}

@@ -138,7 +138,7 @@ Different API versions imply different levels of stability and support.  The cri
 in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).  They are summarized here:
 -->

-不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下：
+不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下：

 <!--
 - Alpha level:
@@ -138,17 +138,9 @@ Example:

 当前，创建 Pod 后，它的主机名是该 Pod 的 `metadata.name` 值。

-在 v1.2 版本中，用户可以配置 Pod annotation， 通过 `pod.beta.kubernetes.io/hostname` 来设置 Pod 的主机名。
-如果为 Pod 配置了 annotation，会优先使用 Pod 的名称作为主机名。
-例如，给定一个 Pod，它具有 annotation `pod.beta.kubernetes.io/hostname: my-pod-name`，该 Pod 的主机名被设置为 “my-pod-name”。
+PodSpec 有一个可选的 `hostname` 字段，可以用来指定 Pod 的主机名。当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。举个例子，给定一个 `hostname` 设置为 "`my-host`" 的 Pod，该 Pod 的主机名将被设置为 "`my-host`"。

-在 v1.3 版本中，PodSpec 具有 `hostname` 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation `pod.beta.kubernetes.io/hostname`。
-在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 `pod.beta.kubernetes.io/subdomain` 指定了 Pod 的子域名。
-最终的域名将是 “<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>”。
-举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。
-
-在 v1.3 版本中，PodSpec 具有 `subdomain` 字段，可以用来指定 Pod 的子域名。
-这个字段的值优先于 annotation `pod.beta.kubernetes.io/subdomain` 的值。
+PodSpec 还有一个可选的 `subdomain` 字段，可以用来指定 Pod 的子域名。举个例子，一个 Pod 的 `hostname` 设置为 “`foo`”，`subdomain` 设置为 “`bar`”，在 namespace “`my-namespace`” 中对应的完全限定域名（FQDN）为 “`foo.bar.my-namespace.svc.cluster-domain.example`”。

 实例:
 ```yaml
@@ -118,9 +118,9 @@ balancer in between your application and the backend Pods.
 -->
 ### 云原生服务发现

-如果您能够在应用程序中使用 Kubernetes 接口进行服务发现，则可以查询 {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} 的 endpoint 资源，只要服务中的Pod集合发生更改，端点就会更新。
+如果您想要在应用程序中使用 Kubernetes 接口进行服务发现，则可以查询 {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} 的 endpoint 资源，只要服务中的Pod集合发生更改，端点就会更新。

-对于非本机应用程序，Kubernetes提供了在应用程序和后端Pod之间放置网络端口或负载平衡器的方法。
+对于非本机应用程序，Kubernetes提供了在应用程序和后端Pod之间放置网络端口或负载均衡器的方法。

 <!--
 ## Defining a Service
@@ -205,7 +205,7 @@ Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget`
 这为部署和发展服务提供了很大的灵活性。
 例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。

-服务的默认协议是TCP；默认协议是TCP。 您还可以使用任何其他 [受支持的协议](#protocol-support)。
+服务的默认协议是TCP。 您还可以使用任何其他 [受支持的协议](#protocol-support)。

 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
 每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。
@@ -596,7 +596,7 @@ For example, the names `123-abc` and `web` are valid, but `123_abc` and `-web` a

 与一般的Kubernetes名称一样，端口名称只能包含 小写字母数字字符 和 `-`。 端口名称还必须以字母数字字符开头和结尾。

-例如，名称 `123_abc` 和 `web` 有效，但是 `123_abc` 和 `-web` 无效。
+例如，名称 `123-abc` 和 `web` 有效，但是 `123_abc` 和 `-web` 无效。
 {{< /note >}}

 <!--
@@ -431,6 +431,7 @@ parameters:
  type: pd-standard
  replication-type: none
 ```
+
 <!--
 * `type`: `pd-standard` or `pd-ssd`. Default: `pd-standard`
 * `zone` (Deprecated): GCE zone. If neither `zone` nor `zones` is specified, volumes are
@@ -518,6 +519,7 @@ parameters:
 * `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用，当在指定 `restuser`，`restuserkey`，`secretName` 或  `secretNamespace` 时，身份验证被启用。
 * `restuser`：在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。
 * `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。
+
 <!--
 * `secretNamespace`, `secretName` : Identification of Secret instance that
  contains user password to use when talking to Gluster REST service. These
@@ -544,6 +546,7 @@ parameters:
    ```

    secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。
+
 <!--
 * `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster
  which will be used by Heketi when provisioning the volume. It can also be a
@@ -559,6 +562,7 @@ parameters:
 * `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
  `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
 * `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
+
 <!--
 * `volumetype` : The volume type and its parameters can be configured with this
  optional value. If the volume type is not mentioned, it's up to the provisioner
@@ -766,6 +770,7 @@ parameters:
 * `adminSecretNamespace`：`adminSecret` 的命名空间。默认是 "default"。
 * `pool`: Ceph RBD 池. 默认是 "rbd"。
 * `userId`：Ceph 客户端 ID，用于映射 RBD 镜像。默认与 `adminId` 相同。
+
 <!--
 * `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It
  must exist in the same namespace as PVCs. This parameter is required.
@@ -56,7 +56,7 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
 <!--
 `VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attibutes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
 -->
-`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。从存储系统上相同卷上获取的不同快照，这些参数可能会不一样，因此不能用一个 `PersistentVolumeClaim` 的相同 `StorageClass` 来指卷快照。
+`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。

 <!--
 Users need to be aware of the following when using this feature:
@@ -108,7 +108,7 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be
 -->
 #### 动态的 {#dynamic}

-可以从一个 `PersistentVolumeClaim` 申请动态的获取一个快照，而不用使用已经存在的快照。在使用快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定确切的存储提供者参数。
+可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。在获取快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定要用的特定于存储提供程序的参数。

 <!--
 ### Binding
@@ -133,7 +133,7 @@ The purpose of this protection is to ensure that in-use PersistentVolumeClaim AP
 -->
 ### 快照源的持久性卷声明保护

-这种保护的目的是确保当从 `PersistentVolumeClaim` API 对象中做快照的时候，它不会被从系统中删除（因为这可能会导致数据丢失）。
+这种保护的目的是确保在从系统中获取快照时，不会将正在使用的 `PersistentVolumeClaim` API 对象从系统中删除（因为这可能会导致数据丢失）。

 <!--

@@ -186,7 +186,7 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
 <!--
 For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
 -->
-对于预配置的快照，像下面的例子一样，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的
+如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。

 ```
 apiVersion: snapshot.storage.k8s.io/v1beta1
@@ -1,4 +1,11 @@
 ---
+title: CronJob
+content_template: templates/concept
+weight: 80
+---
+
+<!--
+---
 reviewers:
 - erictune
 - soltysh
@@ -7,9 +14,12 @@ title: CronJob
 content_template: templates/concept
 weight: 80
 ---
+-->

 {{% capture overview %}}

+{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+
 <!--
 A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule.

@@ -19,18 +29,30 @@ on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) forma

 _Cron Job_ 创建基于时间调度的 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。

-一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，并周期性的在给定的调度时间执行 Job。
+一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，并周期性地在给定的调度时间执行 Job。
+
+<!--
+All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
+-->

 {{< note >}}
-<!--All **CronJob** `schedule:` times are denoted in UTC.-->
-所有 **CronJob** 的 `schedule:` 时间都是用 UTC 表示。
+所有 **CronJob** 的 `schedule:` 时间都是基于初始 Job 的主控节点的时区。
 {{< /note >}}

+<!--
+When creating the manifest for a CronJob resource, make sure the name you provide
+is no longer than 52 characters. This is because the CronJob controller will automatically
+append 11 characters to the job name provided and there is a constraint that the
+maximum length of a Job name is no more than 63 characters.
+-->
+为 CronJob 资源创建清单时，请确保创建的名称不超过 52 个字符。这是因为 CronJob 控制器将自动在提供的作业名称后附加 11 个字符，并且存在一个限制，即作业名称的最大长度不能超过 63 个字符。
+
+
 <!--
 For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
 -->

-有关创建和使用 CronJob 的说明及规范文件的示例，请参见 [使用 CronJob 运行自动任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。
+有关创建和使用 CronJob 的说明及规范文件的示例，请参见[使用 CronJob 运行自动化任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。


 {{% /capture %}}
@@ -61,21 +83,20 @@ at least once.
 如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且 `concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。

 <!--
-For every CronJob, the CronJob controller checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
+For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
 -->

-对于每个 CronJob，CronJob 控制器检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次，那么它就不会启动这个任务，并记录这个错误:
+对于每个 CronJob，CronJob  {{< glossary_tooltip term_text="控制器" term_id="controller" >}} 检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次，那么它就不会启动这个任务，并记录这个错误:

 ````
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
-
 ````

 <!--
 It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds.
 -->

-需要注意的是，如果设置 `startingDeadlineSeconds` 字段非空，则控制器会统计从 `startingDeadlineSeconds` 的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如，如果 `startingDeadlineSeconds` 是 `200`，则控制器会统计在过去 200 秒中错过了多少次 Job。
+需要注意的是，如果 `startingDeadlineSeconds` 字段非空，则控制器会统计从 `startingDeadlineSeconds` 设置的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如，如果 `startingDeadlineSeconds` 是 `200`，则控制器会统计在过去 200 秒中错过了多少次 Job。

 <!--
 A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.
@@ -84,163 +105,26 @@ A CronJob is counted as missed if it has failed to be created at its scheduled t
 如果未能在调度时间内创建 CronJob，则计为错过。例如，如果 `concurrencyPolicy` 被设置为 `Forbid`，并且当前有一个调度仍在运行的情况下，试图调度的 CronJob 将被计算为错过。

 <!--
-For example, suppose a cron job is set to start at exactly `08:30:00` and its
-`startingDeadlineSeconds` is set to 10, if the CronJob controller happens to
-be down from `08:29:00` to `08:42:00`, the job will not start.
-Set a longer `startingDeadlineSeconds` if starting later is better than not
-starting at all.
+For example, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
+`startingDeadlineSeconds` field is not set. If the CronJob controller happens to
+be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
 -->

-例如，假设一个 CronJob 被设置为`08:30:00` 准时开始，它的 `startingDeadlineSeconds` 属性被设置为10，如果在`08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。
+例如，假设一个 CronJob 被设置为 `08:30:00` 准时开始，它的 `startingDeadlineSeconds` 字段被设置为 10，如果在 `08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。
 如果觉得晚些开始比没有启动好，那请设置一个较长的 `startingDeadlineSeconds`。

 <!--
-The Cronjob is only responsible for creating Jobs that match its schedule, and
+To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
+`startingDeadlineSeconds` is set to 200 seconds. If the CronJob controller happens to
+be down for the same period as the previous example (`08:29:00` to `10:21:00`,) the Job will still start at 10:22:00. This happens as the controller now checks how many missed schedules happened in the last 200 seconds (ie, 3 missed schedules), rather than from the last scheduled time until now.
+-->
+为了进一步阐述这个概念，假设将 CronJob 设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job，并将其 `startingDeadlineSeconds` 字段设置为 200 秒。 如果 CronJob 控制器恰好在与上一个示例相同的时间段（`08:29:00` 到 `10:21:00`）停机，则 Job 仍将从 `10:22:00` 开始。造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 Job 调度，而不是从现在为止的最后一个调度时间开始。
+
+<!--
+The CronJob is only responsible for creating Jobs that match its schedule, and
 the Job in turn is responsible for the management of the Pods it represents.
 -->
+CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。

-CronJob 只负责创建与其时间表相匹配的 Job，相应的 Job 又会负责管理它所代表的Pod。
-
-创建该 Cron Job 之后，通过如下命令获取它的状态信息：
-
-```shell
-$ kubectl get cronjob hello
-NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
-hello     */1 * * * *   False     0         <none>
-```
-
-
-
-如上所示，既没有 active 的 Job，也没有被调度的 Job。
-
-等待并观察创建的 Job，大约一分钟时间：
-
-```shell
-$ kubectl get jobs --watch
-NAME               DESIRED   SUCCESSFUL   AGE
-hello-4111706356   1         1         2s
-```
-
-
-
-现在能看到一个名称为 hello 的 Job 在运行。我们可以停止观察，并再次获取该 Job 的状态信息：
-
-```shell
-$ kubectl get cronjob hello
-NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
-hello     */1 * * * *   False     0         Mon, 29 Aug 2016 14:34:00 -0700
-```
-
-
-应该能够看到名称为 “hello” 的 Job 在 `LAST-SCHEDULE` 指定的时间点被调度了。当前存在 0 个活跃（Active）的 Job，说明该 Job 已经被调度运行完成或失败。
-
-现在，找到最近一次被调度的 Job 创建的 Pod，能够看到其中一个 Pod 的标准输出。注意，Job 名称和 Pod 名称是不一样的。
-
-```shell
-# Replace "hello-4111706356" with the job name in your system
-$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
-
-$ echo $pods
-hello-4111706356-o9qcm
-
-$ kubectl logs $pods
-Mon Aug 29 21:34:09 UTC 2016
-Hello from the Kubernetes cluster
-```
-
-
-## 删除 Cron Job
-
-一旦不再需要 Cron Job，简单地可以使用 `kubectl` 命令删除它：
-
-```shell
-$ kubectl delete cronjob hello
-cronjob "hello" deleted
-```
-
-
-
-这将会终止正在创建的 Job。然而，运行中的 Job 将不会被终止，不会删除 Job 或 它们的 Pod。为了清理那些 Job 和 Pod，需要列出该 Cron Job 创建的全部 Job，然后删除它们：
-
-```shell
-$ kubectl get jobs
-NAME               DESIRED   SUCCESSFUL   AGE
-hello-1201907962   1         1            11m
-hello-1202039034   1         1            8m
-...
-
-$ kubectl delete jobs hello-1201907962 hello-1202039034 ...
-job "hello-1201907962" deleted
-job "hello-1202039034" deleted
-...
-```
-
-
-
-一旦 Job 被删除，由 Job 创建的 Pod 也会被删除。注意，所有由名称为 “hello” 的 Cron Job 创建的 Job 会以前缀字符串 “hello-” 进行命名。如果想要删除当前 Namespace 中的所有 Job，可以通过命令 `kubectl delete jobs --all` 立刻删除它们。
-
-
-
-## Cron Job 限制
-
-Cron Job 在每次调度运行时间内 _大概_ 会创建一个 Job 对象。我们之所以说 _大概_ ，是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。我们尝试少发生这种情况，但却不能完全避免。因此，创建 Job 操作应该是 _幂等的_。
-
-Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决定这一组 Pod 的成功或失败。Cron Job 根本不会去检查 Pod。
-
-
-
-## 编写 Cron Job 规约
-
-和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。
-关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、
-[配置容器](/docs/user-guide/configuring-containers) 和
-[使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。
-
-Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
-
-**注意：** 对一个 Cron Job 的所有修改，尤其是对其 `.spec` 的修改，仅会在下一次运行的时候生效。
-
-
-### 调度
-
- `.spec.schedule` 是 `.spec` 中必需的字段，它的值是 [Cron](https://en.wikipedia.org/wiki/Cron) 格式字的符串，例如：`0 * * * *`，或者 `@hourly`，根据指定的调度时间 Job 会被创建和执行。
-
-
-
-### Job 模板
-
-`.spec.jobTemplate` 是另一个 `.spec` 中必需的字段。它是 Job 的模板。
-除了它可以是嵌套的，并且不具有 `apiVersion` 或 `kind` 字段之外，它和 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 一样具有完全相同的模式（schema）。
-参考 [编写 Job 规格](/docs/concepts/jobs/run-to-completion-finite-workloads/#writing-a-job-spec)。
-
-
-
-### 启动 Job 的期限（秒级别）
-
-`.spec.startingDeadlineSeconds` 字段是可选的。它表示启动 Job 的期限（秒级别），如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限。
-
-
-
-### 并发策略
-
-`.spec.concurrencyPolicy` 字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
-
-* `Allow`（默认）：允许并发运行 Job
-* `Forbid`：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
-* `Replace`：取消当前正在运行的 Job，用一个新的来替换
-
-注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。
-
-
-
-### 挂起
-
-`.spec.suspend` 字段也是可选的。如果设置为 `true`，后续所有执行都将被挂起。它对已经开始执行的 Job 不起作用。默认值为 `false`。
-
-
-
-### Job 历史限制
-
-`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 这两个字段是可选的。它们指定了可以保留完成和失败 Job 数量的限制。
-
-默认没有限制，所有成功和失败的 Job 都会被保留。然而，当运行一个 Cron Job 时，很快就会堆积很多 Job，推荐设置这两个字段的值。设置限制值为 `0`，相关类型的 Job 完成后将不会被保留。
+{{% /capture %}}
+ 
@@ -1,10 +1,4 @@
 ---
-reviewers:
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
 title: DaemonSet
 content_template: templates/concept
 weight: 50
@@ -39,13 +33,13 @@ Some typical uses of a DaemonSet are:

 - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
 - running a logs collection daemon on every node, such as `fluentd` or `logstash`.
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
-  https://github.com/prometheus/node_exporter), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or Instana agent.
+- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/).
 -->
+DaemonSet 的一些典型用法：

- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、[Sysdig 代理](https://sysdigdocs.atlassian.net/wiki/spaces/Platform)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、[AppDynamics 代理](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、[Datadog 代理](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic 代理](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)，Ganglia `gmond` 或 [Instana 代理](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。
+- 在每个节点上运行集群存储 DaemonSet，例如 `glusterd`、`ceph`。
+- 在每个节点上运行日志收集 DaemonSet，例如 `fluentd`、`logstash`。
+- 在每个节点上运行监控 DaemonSet，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig 代理](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、[AppDynamics 代理](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、[Datadog 代理](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic 代理](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Ganglia `gmond` 或者 [Instana 代理](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。

 <!--
 In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
@@ -55,7 +49,7 @@ different flags and/or different memory and cpu requests for different hardware
 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。

 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，
-和/或对不同硬件类型具有不同的内存、CPU要求。
+并且对不同硬件类型具有不同的内存、CPU 要求。

 {{% /capture %}}

@@ -73,18 +67,14 @@ different flags and/or different memory and cpu requests for different hardware

 <!--
 You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
-
-{{< codenew file="controllers/daemonset.yaml" >}}
-
-* Create a DaemonSet based on the YAML file:
-```
-kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
-```
 -->
 您可以在 YAML 文件中描述 DaemonSet。例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet：

 {{< codenew file="controllers/daemonset.yaml" >}}

+<!--
+* Create a DaemonSet based on the YAML file:
+-->
 * 基于 YAML 文件创建 DaemonSet:
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
@@ -100,13 +90,16 @@ general information about working with config files, see [deploying applications
 A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.
 -->
 ### 必需字段
-和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。有关配置文件的基本信息，详见文档 [部署应用](/docs/user-guide/deploying-applications/)、[配置容器](/docs/tasks/) 和 [使用kubectl进行对象管理](/docs/concepts/overview/object-management-kubectl/overview/)。
+和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。有关配置文件的基本信息，详见文档 [部署应用](/docs/user-guide/deploying-applications/)、[配置容器](/docs/tasks/) 和 [使用 kubectl 进行对象管理](/docs/concepts/overview/object-management-kubectl/overview/)。

 DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 配置段。

 <!--
 ### Pod Template
+-->
+### Pod 模板

+<!--
 The `.spec.template` is one of the required fields in `.spec`.

 The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
@@ -114,14 +107,12 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overv
 In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
 labels (see [pod selector](#pod-selector)).

-A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod-states)
+A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
 equal to `Always`, or be unspecified, which defaults to `Always`.
 -->
-### Pod 模板
+`.spec` 中唯一必需的字段是 `.spec.template`。

-`.spec` 唯一必需的字段是 `.spec.template`。
-
-`.spec.template` 是一个 [Pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它与 [Pod](/docs/concepts/workloads/pods/pod/) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
+`.spec.template` 是一个 [Pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段，它与 [Pod](/docs/concepts/workloads/pods/pod/) 具有相同的 schema。

 除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。

@@ -129,7 +120,10 @@ A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod

 <!--
 ### Pod Selector
+-->
+### Pod Selector {#pod-selector}

+<!--
 The `.spec.selector` field is a pod selector.  It works the same as the `.spec.selector` of
 a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).

@@ -139,53 +133,56 @@ defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is cr
 its `.spec.selector` can not be mutated. Mutating the pod selector can lead to the
 unintentional orphaning of Pods, and it was found to be confusing to users.
 -->
-### Pod Selector {#pod-selector}
-
 `.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 的 `.spec.selector` 的作用是相同的。

-从 Kubernetes 1.8开始，您必须指定与 `.spec.template` 的标签匹配的 pod selector。当不配置时，pod selector 将不再有默认值。selector 默认与 `kubectl apply` 不兼容。 此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。修改 pod selector 可能导致成为 孤儿Pod，并且这对用户来说是困惑的。
+从 Kubernetes 1.8 开始，您必须指定与 `.spec.template` 的标签匹配的 pod selector。当不配置时，pod selector 将不再有默认值。selector 默认与 `kubectl apply` 不兼容。 此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。修改 pod selector 可能导致 Pod 意外悬浮，并且这对用户来说是困惑的。

 <!--
 The `.spec.selector` is an object consisting of two fields:
-
-* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
-* `matchExpressions` - allows to build more sophisticated selectors by specifying key,
-  list of values and an operator that relates the key and values.
-
-When the two are specified the result is ANDed.
-
-If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
-
-Also you should not normally create any Pods whose labels match this selector, either directly, via
-another DaemonSet, or via other controller such as ReplicaSet.  Otherwise, the DaemonSet
-controller will think that those Pods were created by it.  Kubernetes will not stop you from doing
-this.  One case where you might want to do this is manually create a Pod with a different value on
-a node for testing.
 -->
 `spec.selector` 表示一个对象，它由如下两个字段组成：

+<!--
+* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchExpressions` - allows to build more sophisticated selectors by specifying key,
+  list of values and an operator that relates the key and values.
+-->
 * `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。
 * `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表
 ，以及与 key 和 value 列表相关的操作符。

+<!--
+When the two are specified the result is ANDed.
+-->
 当上述两个字段都指定时，结果表示的是 AND 关系。

+<!--
+If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
+-->
 如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果与它们配置的不匹配，则会被 API 拒绝。

-此外，您通常不应该创建任何 pods，它们的 label 与 selector 匹配，或者直接创建，或者通过另一个 DaemonSet、或者其他控制器，比如 ReplicaSet。否则，DaemonSet 控制器会认为这些 Pod 是由它创建的。Kubernetes 不会阻止你这样做。 您可能希望这样做的一种情况是在节点上手动创建具有不同值的 Pod 以进行测试。
+<!--
+Also you should not normally create any Pods whose labels match this selector, either directly, via
+another DaemonSet, or via another workload resource such as ReplicaSet.  Otherwise, the DaemonSet
+{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it.
+Kubernetes will not stop you from doing this. One case where you might want to do this is manually
+create a Pod with a different value on a node for testing.
+-->
+另外，通常不应直接通过另一个 DaemonSet 或另一个工作负载资源（例如 ReplicaSet）来创建其标签与该选择器匹配的任何 Pod。否则，DaemonSet {{< glossary_tooltip term_text="控制器" term_id="controller" >}}会认为这些 Pod 是由它创建的。Kubernetes 不会阻止你这样做。您可能要执行此操作的一种情况是，手动在节点上创建具有不同值的 Pod 进行测试。

 <!--
 ### Running Pods on Only Some Nodes
+-->
+### 仅在某些节点上运行 Pod

+<!--
 If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
 create Pods on nodes which match that [node
 selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
 then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
 If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
 -->
-### 仅在某些节点上运行 Pod
-
-如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配>的节点上创建 Pod。
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
 如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。

 <!--
@@ -197,10 +194,9 @@ If you do not specify either, then the DaemonSet controller will create Pods on

 ### 通过默认 scheduler 调度

-<!--
-
 {{< feature-state state="stable" for-kubernetes-version="1.17" >}}

+<!--
 A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
 node that a Pod runs on is selected by the Kubernetes scheduler. However,
 DaemonSet pods are created and scheduled by the DaemonSet controller instead.
@@ -213,10 +209,7 @@ That introduces the following issues:
   is handled by default scheduler. When preemption is enabled, the DaemonSet controller
   will make scheduling decisions without considering pod priority and preemption.
 -->
-
-{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
-
-DaemonSet 确保所有符合条件的节点都运行一个 Pod 的副本。通常，运行 Pod 的节点由 Kubernetes scheduler 选择。然而，DaemonSet pods 由 DaemonSet controller 创建和调度。这将引入以下问题：
+DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。通常，运行 Pod 的节点由 Kubernetes 调度器抉择。不过，DaemonSet pods 由 DaemonSet 控制器创建和调度。这将引入以下问题：

 * Pod 行为的不一致性：等待调度的正常 Pod 已被创建并处于 `Pending` 状态，但 DaemonSet pods 未在 `Pending` 状态下创建。 这使用户感到困惑。
 * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)由默认 scheduler 处理。 启用抢占后，DaemonSet 控制器将在不考虑 pod 优先级和抢占的情况下制定调度决策。
@@ -230,7 +223,7 @@ the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
 performs these operations when creating or modifying DaemonSet pods, and no
 changes are made to the `spec.template` of the DaemonSet.
 -->
-`ScheduleDaemonSetPods` 允许您使用默认 scheduler 而不是 DaemonSet 控制器来调度 DaemonSets，方法是将 `NodeAffinity` 添加到 DaemonSet pods，而不是 `.spec.nodeName`。 然后使用默认 scheduler 将 pod 绑定到目标主机。 如果 DaemonSet pod的亲和节点已存在，则替换它。 DaemonSet 控制器仅在创建或修改 DaemonSet pods 时执行这些操作，并且不对 DaemonSet的 `spec.template` 进行任何更改。
+`ScheduleDaemonSetPods` 允许您使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets，方法是将 `NodeAffinity` 添加到 DaemonSet pods，而不是 `.spec.nodeName`。 然后使用默认调度器将 pod 绑定到目标主机。 如果 DaemonSet pod 的亲和节点已存在，则替换它。 DaemonSet 控制器仅在创建或修改 DaemonSet pods 时执行这些操作，并且不对 DaemonSet 的 `spec.template` 进行任何更改。

 ```yaml
 nodeAffinity:
@@ -248,7 +241,7 @@ In addition, `node.kubernetes.io/unschedulable:NoSchedule` toleration is added
 automatically to DaemonSet Pods. The default scheduler ignores
 `unschedulable` Nodes when scheduling DaemonSet Pods.
 -->
-此外，`node.kubernetes.io/unschedulable：NoSchedule` toleration 会自动添加到 DaemonSet Pods。 在调度DaemonSet Pod 时，默认调度器会忽略 `unschedulable`节点。
+此外，系统会自动添加 `node.kubernetes.io/unschedulable：NoSchedule` 容忍度到 DaemonSet Pods。 在调度 DaemonSet Pod 时，默认调度器会忽略 `unschedulable` 节点。

 <!--
 ### Taints and Tolerations
@@ -258,11 +251,11 @@ Although Daemon Pods respect
 the following tolerations are added to DaemonSet Pods automatically according to
 the related features.
 -->
-### Taints and Tolerations
+### 污点和容忍度

-尽管 Daemon Pods 尊重[taints and tolerations](/docs/concepts/configuration/taint-and-toleration)，根据相关特性，会自动将以下 tolerations 添加到 DaemonSet Pods 中。
+尽管 Daemon Pods 遵循[污点和容忍度](/docs/concepts/configuration/taint-and-toleration) 规则，根据相关特性，会自动将以下容忍度添加到 DaemonSet Pods 中。

-| Toleration Key                           | Effect     | Version | Description                                                  |
+| 容忍度关键词                         | 影响     | 版本 | 描述                                                  |
 | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
 | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+    | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
 | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
@@ -275,7 +268,10 @@ the related features.

 <!--
 ## Communicating with Daemon Pods
+-->
+## 与 Daemon Pods 通信

+<!--
 Some possible patterns for communicating with Pods in a DaemonSet are:

 - **Push**: Pods in the DaemonSet are configured to send updates to another service, such
@@ -287,26 +283,32 @@ Some possible patterns for communicating with Pods in a DaemonSet are:
 - **Service**: Create a service with the same Pod selector, and use the service to reach a
  daemon on a random node. (No way to reach specific node.)
 -->
-## 与 Daemon Pods 通信
+与 DaemonSet 中的 Pod 进行通信的几种可能模式如下：

-与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：
-
- **Push**：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口
-。
- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/concepts/services-networking/service/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
+- **Push**：将 DaemonSet 中的 Pod 配置为将更新发送到另一个 Service，例如统计数据库。
+- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法获取节点 IP 列表，并且基于此也可以获取到相应的端口。
+- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/concepts/services-networking/service/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 中检索到多个 A 记录来发现 DaemonSet。
 - **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。

 <!--
 ## Updating a DaemonSet
+-->
+## 更新 DaemonSet

+<!--
 If node labels are changed, the DaemonSet will promptly add Pods to newly matching nodes and delete
 Pods from newly not-matching nodes.

 You can modify the Pods that a DaemonSet creates.  However, Pods do not allow all
 fields to be updated.  Also, the DaemonSet controller will use the original template the next
 time a node (even with the same name) is created.
+-->
+如果修改了节点标签，DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能够匹配的节点上的 Pod。

+您可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次
+节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
+
+<!--
 You can delete a DaemonSet.  If you specify `--cascade=false` with `kubectl`, then the Pods
 will be left on the nodes.  If you subsequently create a new DaemonSet with the same selector,
 the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces
@@ -314,14 +316,6 @@ them according to its `updateStrategy`.

 You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
 -->
-
-## 更新 DaemonSet
-
-如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能够匹配的节点上的 Pod。
-
-您可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次
-节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
-
 您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。
 如果有任何 Pod 需要替换，则 DaemonSet 根据它的 `updateStrategy` 来替换。

@@ -329,7 +323,12 @@ You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/)
 ## Alternatives to DaemonSet

 ### Init Scripts
+-->
+## DaemonSet 的可替代选择

+### init 脚本
+
+<!--
 It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
 `init`, `upstartd`, or `systemd`).  This is perfectly fine.  However, there are several advantages to
 running such processes via a DaemonSet:
@@ -340,10 +339,6 @@ running such processes via a DaemonSet:
  containers.  However, this can also be accomplished by running the daemons in a container but not in a Pod
  (e.g. start directly via Docker).
 -->
-## DaemonSet 的可替代选择
-
-### init 脚本
-
 我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处：

 - 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
@@ -1,11 +1,7 @@
 ---
 title: 垃圾收集
-redirect_from:
- "/docs/concepts/abstractions/controllers/garbage-collection/"
- "/docs/concepts/abstractions/controllers/garbage-collection.html"
- "/docs/user-guide/garbage-collection/"
- "/docs/user-guide/garbage-collection.html"
 content_template: templates/concept
+weight: 60
 ---

 <!--
@@ -59,7 +55,7 @@ Here's a configuration file for a ReplicaSet that has three Pods:

 有时，Kubernetes 会自动设置 `ownerReference` 的值。
 例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。
-在 1.6 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment 所创建或管理。
+在 Kubernetes 1.8 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job 和 CronJob 所创建或管理。
 也可以通过手动设置 `ownerReference` 的值，来指定所有者和附属之间的关系。

 这里有一个配置文件，表示一个具有 3 个 Pod 的 ReplicaSet：
@@ -84,7 +80,7 @@ The output shows that the Pod owner is a ReplicaSet named `my-repset`:

 输出显示了 Pod 的所有者是名为 my-repset 的 ReplicaSet：

-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -99,8 +95,6 @@ metadata:
  ...
 ```

-{{< note >}}
-
 <!--
 Cross-namespace owner references are disallowed by design. This means:
 1) Namespace-scoped dependents can only specify owners in the same namespace,
@@ -108,13 +102,10 @@ and owners that are cluster-scoped.
 2) Cluster-scoped dependents can only specify cluster-scoped owners, but not
 namespace-scoped owners.
 -->
-
+{{< note >}}
 根据设计，kubernetes 不允许跨命名空间指定所有者。这意味着：
-
 1）命名空间范围的附属只能在相同的命名空间中指定所有者，并且只能指定集群范围的所有者。
-
 2）集群范围的附属只能指定集群范围的所有者，不能指定命名空间范围的。
-
 {{< /note >}}

 <!--
@@ -130,16 +121,19 @@ automatically, the dependents are said to be *orphaned*.
 -->
 ## 控制垃圾收集器删除附属者

-当删除对象时，可以指定是否该对象的附属者也自动删除掉。
+当删除对象时，可以指定该对象的附属者是否也自动删除掉。
 自动删除 Dependent 也称为 *级联删除* 。
 Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。

-如果删除对象时，不自动删除它的附属者，这些附属者被称作是原对象的*孤儿* 。
+如果删除对象时，不自动删除它的附属者，这些附属者被称作是原对象的 *orphaned* 。


 <!--
 ### Foreground cascading deletion
+-->
+### 显式级联删除

+<!--
 In *foreground cascading deletion*, the root object first
 enters a "deletion in progress" state. In the "deletion in progress" state,
 the following things are true:
@@ -147,12 +141,23 @@ the following things are true:
 * The object is still visible via the REST API
 * The object's `deletionTimestamp` is set
 * The object's `metadata.finalizers` contains the value "foregroundDeletion".
+-->
+在*显式级联删除*模式下，根对象首先进入 `deletion in progress` 状态。在 `deletion in progress` 状态会有如下的情况：

+ * 对象仍然可以通过 REST API 可见。
+ * 会设置对象的 `deletionTimestamp` 字段。
+ * 对象的 `metadata.finalizers` 字段包含了值 `foregroundDeletion`。
+
+<!--
 Once the "deletion in progress" state is set, the garbage
 collector deletes the object's dependents. Once the garbage collector has deleted all
 "blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it deletes
 the owner object.
+-->
+一旦对象被设置为 `deletion in progress` 状态，垃圾收集器会删除对象的所有附属。
+垃圾收集器在删除了所有 `Blocking` 状态的附属（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除拥有者对象。

+<!--
 Note that in the "foregroundDeletion", only dependents with
 `ownerReference.blockOwnerDeletion=true` block the deletion of the owner object.
 Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set
@@ -162,22 +167,8 @@ unauthorized dependents cannot delay deletion of an owner object.
 If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
 blockOwnerDeletion is set automatically and you do not need to manually modify this field.
 -->
-
-### 显式级联删除
-
-在*显式级联删除*模式下，根对象首先进入 `deletion in progress` 状态。在 `deletion in progress` 状态会有如下的情况：
-
- * 对象仍然可以通过 REST API 可见。
- * 会设置对象的 `deletionTimestamp` 字段。
- * 对象的 `metadata.finalizers` 字段包含了值 `foregroundDeletion`。
-
-一旦对象被设置为 `deletion in progress` 状态，垃圾收集器会删除对象的所有附属。
- 垃圾收集器在删除了所有 `Blocking` 状态的附属（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除拥有者对象。
-
-
-
 注意，在 `foregroundDeletion` 模式下，只有设置了 `ownerReference.blockOwnerDeletion` 值的附属者才能阻止删除拥有者对象。
-在 Kubernetes 1.7 版本中将增加准入控制器（Admission Controller），基于拥有者对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的附属者不能够延迟拥有者对象的删除。
+在 Kubernetes 1.7 版本中将增加[准入控制器](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)，基于拥有者对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的附属者不能够延迟拥有者对象的删除。

 如果一个对象的 `ownerReferences` 字段被一个 Controller（例如 Deployment 或 ReplicaSet）设置，`blockOwnerDeletion` 会被自动设置，不需要手动修改这个字段。

@@ -191,7 +182,7 @@ the background.
 -->
 ### 隐式级联删除

-在 *隐式级联删除除* 模式下，Kubernetes 会立即删除拥有者对象，然后垃圾收集器会在后台删除这些附属。
+在 *隐式级联删除* 模式下，Kubernetes 会立即删除拥有者对象，然后垃圾收集器会在后台删除这些附属值。

 <!--
 ### Setting the cascading deletion policy
@@ -206,18 +197,20 @@ Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1b
 specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` 
 group version, dependent objects are deleted by default.

-Here's an example that deletes dependents in background:
 -->

 ### 设置级联删除策略

 通过为拥有者对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。
-可能的取值包括：`orphan`、`Foreground`或`Background`。
+可能的取值包括：`orphan`、`Foreground` 或者 `Background`。

 对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。
-因此，除非指定其它的垃圾收集策略，否则所有附属对象使用的都是 `orphan` 策略。
+因此，对于使用 `extensions/v1beta1`、`apps/v1beta1` 和 `apps/v1beta2` 组版本中的 `Kind`,除非指定其它的垃圾收集策略，否则所有附属对象默认使用的都是 `orphan` 策略。

-下面是一个在后台删除 Dependent 对象的例子：
+<!--
+Here's an example that deletes dependents in background:
+-->
+下面是一个在 `Background` 中删除 Dependent 对象的示例：

 ```shell
 kubectl proxy --port=8080
@@ -230,7 +223,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 Here's an example that deletes dependents in foreground:
 -->

-下面是一个在前台删除附属对象的例子：
+下面是一个在 `Foreground` 中删除附属对象的示例：

 ```shell
 kubectl proxy --port=8080
@@ -243,7 +236,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 Here's an example that orphans dependents:
 -->

-这里是一个孤儿附属的例子：
+这里是一个 `Orphan` 附属的示例：

 ```shell
 kubectl proxy --port=8080
@@ -281,7 +274,7 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment

 ### Deployment 的其他说明

-在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，您必须*使用* `propagationPolicy:Foreground`。这样不仅删除所创建的 ReplicaSet，还删除其 Pod。如果不使用这种类型的 `propagationPolicy`，则将只删除 ReplicaSet，而 Pod 被孤立。
+在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，您必须*使用* `propagationPolicy:Foreground` 模式。这样不仅删除所创建的 ReplicaSet，还删除其 Pod。如果不使用这种类型的 `propagationPolicy`，则将只删除 ReplicaSet，而 Pod 被孤立。

 更多信息，请参考 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)。

@@ -301,7 +294,11 @@ Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
 {{% capture whatsnext %}}


-## 控制垃圾收集器删除附属者
+<!--
+[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+
+[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+-->
 [设计文档 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)

 [设计文档 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
@@ -4,12 +4,16 @@ feature:
  title: 自我修复
  anchor: ReplicationController 如何工作
  description: >
-    重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会它们公布给客户端。
+    重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。

 content_template: templates/concept
 weight: 20
---
+---     
+
 <!--
+reviewers:
+- bprashanth
+- janetkuo
 title: ReplicationController
 feature:
  title: Self-healing
@@ -23,10 +27,10 @@ weight: 20

 {{% capture overview %}}

-{{< note >}}
 <!--
 A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
 -->
+{{< note >}}
 现在推荐使用配置 [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 的 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
 {{< /note >}}

@@ -44,7 +48,10 @@ _ReplicationController_ 确保在任何时候都有特定数量的 pod 副本处

 <!--
 ## How a ReplicationController Works
+-->
+## ReplicationController 如何工作

+<!--
 If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the
 ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a
 ReplicationController are automatically replaced if they fail, are deleted, or are terminated.
@@ -53,25 +60,24 @@ For this reason, you should use a ReplicationController even if your application
 only a single pod. A ReplicationController is similar to a process supervisor,
 but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods
 across multiple nodes.
+-->
+当 pod 数量过多时，ReplicationController 会终止多余的 pod。当 pod 数量太少时，ReplicationController 将会启动新的 pod。
+与手动创建的 pod 不同，由 ReplicationController 创建的 pod 在失败、被删除或被终止时会被自动替换。
+例如，在中断性维护（如内核升级）之后，您的 pod 会在节点上重新创建。
+因此，即使您的应用程序只需要一个 pod，您也应该使用 ReplicationController 创建 Pod。
+ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 pod。

-ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
+<!--
+ReplicationController is often abbreviated to "rc" in discussion, and as a shortcut in
 kubectl commands.

 A simple case is to create one ReplicationController object to reliably run one instance of
 a Pod indefinitely.  A more complex use case is to run several identical replicas of a replicated
 service, such as web servers.
 -->
-## ReplicationController 如何工作
+在讨论中，ReplicationController 通常缩写为 "rc"，并作为 kubectl 命令的快捷方式。

-当 pods 数量过多时，ReplicationController 会终止多余的 pods。当 pods 数量太少时，ReplicationController 将会启动新的 pods。
-与手动创建的 pod 不同，由 ReplicationController 创建的 pods 在失败、被删除或被终止时会被自动替换。
-例如，在中断性维护（如内核升级）之后，您的 pod 会在节点上重新创建。
-因此，即使您的应用程序只需要一个 pod，您也应该使用一个 ReplicationController。
-ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 pods。
-
-在讨论中，ReplicationController 通常缩写为 "rc" 或 "rcs"，并作为 kubectl 命令的快捷方式。
-
-一个简单的例子是创建一个 ReplicationController 对象来可靠地无限期地运行 Pod 的一个实例。
+一个简单的示例是创建一个 ReplicationController 对象来可靠地无限期地运行 Pod 的一个实例。
 更复杂的用例是运行一个多副本服务（如 web 服务器）的若干相同副本。

 <!--
@@ -134,8 +140,8 @@ Events:
 Here, three pods are created, but none is running yet, perhaps because the image is being pulled.
 A little later, the same command may show:
 -->
-此时，创建了三个 pod，但是还没有运行，可能正在拉取镜像。
-稍后，相同的命令可能显示：
+在这里，创建了三个 Pod，但没有一个 Pod 正在运行，这可能是因为正在拉取镜像。
+稍后，相同的命令可能会显示：

 ```shell
 Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
@@ -156,7 +162,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m

 <!--
 Here, the selector is the same as the selector for the ReplicationController (seen in the
-`kubectl describe` output, and in a different form in `replication.yaml`.  The `--output=jsonpath` option
+`kubectl describe` output), and in a different form in `replication.yaml`.  The `--output=jsonpath` option
 specifies an expression that just gets the name from each pod in the returned list.
 -->
 这里，选择器与 ReplicationController 的选择器相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。
@@ -172,18 +178,26 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
 -->
 ## 编写一个 ReplicationController Spec

-与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion` ，`kind` 和 `metadata` 字段。
+与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、`kind` 和 `metadata` 字段。
 有关使用配置文件的常规信息，参考[对象管理](/docs/concepts/overview/working-with-objects/object-management/)。

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

 <!--
 ### Pod Template
+-->
+### Pod 模板

+<!--
 The `.spec.template` is the only required field of the `.spec`.

 The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+-->
+`.spec.template` 是 `.spec` 的唯一必需字段。

+`.spec.template` 是一个 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它的模式与 [pod](/docs/concepts/workloads/pods/pod/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
+
+<!--
 In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
 labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).

@@ -192,14 +206,8 @@ Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-l
 For local container restarts, ReplicationControllers delegate to an agent on the node,
 for example the [Kubelet](/docs/admin/kubelet/) or Docker.
 -->
-### Pod 模板
-
-`.spec.template` 是 `.spec` 的唯一必需字段。
-
-`.spec.template` 是一个 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它的模式与 [pod](/docs/concepts/workloads/pods/pod/) 完全相同，只是它是嵌套的，并且没有 `apiVersion` 或 `kind`。
-
 除了 Pod 所需的字段外，ReplicationController 中的 pod 模板必须指定适当的标签和适当的重新启动策略。
-对于标签，请确保不与其他控制器重叠。参考 [pod 选择器](#pod-选择器)。
+对于标签，请确保不与其他控制器重叠。参考 [pod 选择器](#pod-selector)。

 只允许 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。

@@ -223,16 +231,29 @@ ReplicationController 本身可以有标签 （`.metadata.labels`）。

 <!--
 ### Pod Selector
+-->
+### Pod 选择器 {#pod-selector}

+<!--
 The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors). A ReplicationController
 manages all the pods with labels that match the selector. It does not distinguish
 between pods that it created or deleted and pods that another person or process created or
 deleted. This allows the ReplicationController to be replaced without affecting the running pods.
+-->
+`.spec.selector` 字段是一个[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 
+ReplicationController 管理标签与选择器匹配的所有 Pod。
+它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。
+这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。

+<!--
 If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will
 be rejected by the API.  If `.spec.selector` is unspecified, it will be defaulted to
 `.spec.template.metadata.labels`.
+-->
+如果指定了 `.spec.template.metadata.labels`，它必须和 `.spec.selector` 相同，否则它将被 API 拒绝。
+如果没有指定 `.spec.selector`，它将默认为 `.spec.template.metadata.labels`。

+<!--
 Also you should not normally create any pods whose labels match this selector, either directly, with
 another ReplicationController, or with another controller such as Job. If you do so, the
 ReplicationController thinks that it created the other pods.  Kubernetes does not stop you
@@ -241,21 +262,10 @@ from doing this.
 If you do end up with multiple controllers that have overlapping selectors, you
 will have to manage the deletion yourself (see [below](#working-with-replicationcontrollers)).
 -->
-### Pod 选择器
-
-`.spec.selector` 字段是一个[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 
-ReplicationController 管理标签与选择器匹配的所有 Pods。
-它不区分它创建或删除的 pod 以及另一个人或进程创建或删除的 pod。
-这允许在不影响正在运行的 pod 的情况下替换 ReplicationController。
-
-如果指定了 `.spec.template.metadata.labels`，它必须和 `.spec.selector` 相同，否则它将被 API 拒绝。
-如果没有指定 `.spec.selector`，它将默认为 `.spec.template.metadata.labels`。
-
-此外，用户通常不应创建标签与此选择器匹配的任何其他 Pods，无论是直接创建、使用另一个 ReplicationController 来创建或者别的控制器（如 Job ）来创建，都是不允许的。
-如果这样做， ReplicationController 会认为这些 Pods 是由它自己创建的。
+另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job）来创建其标签与该选择器匹配的任何 Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod。
 Kubernetes 并没有阻止你这样做。

-如果您的确创建了多个控制器并且其选择器之间存在重叠，那么您将不得不自己管理删除操作（参考[后文](#使用-replicationcontrollers)）。
+如果您的确创建了多个控制器并且其选择器之间存在重叠，那么您将不得不自己管理删除操作（参考[后文](#working-with-replicationcontrollers)）。

 <!--
 ### Multiple Replicas
@@ -269,15 +279,15 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
 -->
 ### 多个副本

-你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pods。
-在任何时候，处于运行状态的 Pods 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 pod 处于体面终止过程中而其替代副本已经提前开始创建时。
+你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pod。
+在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 pod 处于优雅终止过程中而其替代副本已经提前开始创建时。

-如果你没有指定 `.spec.replicas` ，那么它默认是1。
+如果你没有指定 `.spec.replicas` ，那么它默认是 1。

 <!--
 ## Working with ReplicationControllers
 -->
-## 使用 ReplicationController
+## 使用 ReplicationController {#working-with-replicationcontrollers}

 <!--
 ### Deleting a ReplicationController and its Pods
@@ -293,37 +303,39 @@ When using the REST API or go client library, you need to do the steps explicitl
 ### 删除一个 ReplicationController 以及它的 Pod

 要删除一个 ReplicationController 以及它的 Pod，使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)。
-Kubectl 将 ReplicationController 缩放为0并等待以便在删除 ReplicationController 本身之前删除每个 pod。
+kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
 如果这个 kubectl 命令被中断，可以重新启动它。

-当使用 REST API 或 go 客户端库时，您需要明确地执行这些步骤（缩放副本为0、 等待 Pod 删除，之后删除 ReplicationController 资源）。
+当使用 REST API 或 go 客户端库时，您需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。

 <!--
 ### Deleting just a ReplicationController
+-->
+### 只删除 ReplicationController

+<!--
 You can delete a ReplicationController without affecting any of its pods.

 Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).

 When using the REST API or go client library, simply delete the ReplicationController object.
-
-Once the original is deleted, you can create a new ReplicationController to replace it.  As long
-as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
-However, it will not make any effort to make existing pods match a new, different pod template.
-To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
 -->
-### 只删除 ReplicationController
-
 你可以删除一个 ReplicationController 而不影响它的任何 pod。

 使用 kubectl ，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。

 当使用 REST API 或 go 客户端库时， 只需删除 ReplicationController 对象。

+<!--
+Once the original is deleted, you can create a new ReplicationController to replace it.  As long
+as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
+However, it will not make any effort to make existing pods match a new, different pod template.
+To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
+-->
 一旦原始对象被删除，你可以创建一个新的 ReplicationController 来替换它。
-只要新的和旧的 `.spec.selector` 相同，那么新的控制器将领养旧的 Pods。
-但是，它不会做出任何努力使现有的 pod 匹配新的、不同的 pod 模板。
-如果希望以受控方式更新 Pods 以使用新的 spec，请执行[滚动更新](#滚动更新)操作。
+只要新的和旧的 `.spec.selector` 相同，那么新的控制器将领养旧的 Pod。
+但是，它不会做出任何努力使现有的 Pod 匹配新的、不同的 Pod 模板。
+如果希望以受控方式更新 Pod 以使用新的 spec，请执行[滚动更新](#rolling-updates)操作。

 <!--
 ### Isolating pods from a ReplicationController
@@ -347,7 +359,7 @@ As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
 -->
 ### 重新调度

-如上所述，无论您想要继续运行1个 pod 还是1000个，一个 ReplicationController 都将确保存在指定数量的 pod，即使在节点故障或 pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。
+如上所述，无论您想要继续运行 1 个 pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 pod，即使在节点故障或 pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。
 <!--
 ### Scaling

@@ -359,11 +371,19 @@ The ReplicationController makes it easy to scale the number of replicas up or do

 <!--
 ### Rolling updates
+-->
+### 滚动更新 {#rolling-updates}

+<!--
 The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one.

 As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures.
+-->
+ReplicationController 的设计目的是通过逐个替换 pod 以方便滚动更新服务。

+如 [#1353](http://issue.k8s.io/1353) PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController，逐个缩放新的（+1）和旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。
+
+<!--
 Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time.

 The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
@@ -371,34 +391,28 @@ The two ReplicationControllers would need to create pods with at least one diffe
 Rolling update is implemented in the client tool
 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
 -->
-### 滚动更新
-
-ReplicationController 的设计目的是通过逐个替换 pod 以方便滚动更新服务。
-
-如[#1353](http://issue.k8s.io/1353)所述，建议的方法是使用1个副本创建一个新的 ReplicationController，逐个缩放新的（+1）和旧的（-1）控制器，然后在旧的控制器达到0个副本后将其删除。这一方法能够实现可控的 Pods 集合更新，即使存在意外失效的状况。
-
-理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pods 有效地提供服务。
+理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。

 这两个 ReplicationController 将需要创建至少具有一个不同标签的 pod，比如 pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。

-滚动更新是在客户端工具
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)中实现的。 访问 [`kubectl rolling-update` 任务](/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
+滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 中实现的。 访问 [`kubectl rolling-update` 任务](/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。

 <!--
 ### Multiple release tracks
+-->
+### 多个版本跟踪

+<!--
 In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels.

 For instance, a service might target all pods with `tier in (frontend), environment in (prod)`.  Now say you have 10 replicated pods that make up this tier.  But you want to be able to 'canary' a new version of this component.  You could set up a ReplicationController with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another ReplicationController with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`.  Now the service is covering both the canary and non-canary pods.  But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc.
 -->
-### 多个版本跟踪
-
 除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。

 例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 pod 作为目标。
-现在假设您有10个副本的 pod 组成了这个层。但是你希望能够'金丝雀部署'这个组件的新版本。
-您可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为9，标签为 `tier=frontend, environment=prod, track=stable` 而为 canary 设置另一个 ReplicationController，其中 `replicas` 设置为1，标签为 `tier=frontend, environment=prod, track=canary`。
-现在这个服务覆盖了 canary 和非 canary pod。但您可以单独处理 ReplicationController，以测试、监控结果等。
+现在假设您有 10 个副本的 pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。
+您可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为 9，标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` 设置另一个 ReplicationController，其中 `replicas` 设置为 1，标签为 `tier=frontend, environment=prod, track=canary`。
+现在这个服务覆盖了 `canary` 和非 `canary` Pod。但您可以单独处理 ReplicationController，以测试、监控结果等。

 <!--
 ### Using ReplicationControllers with Services
@@ -412,8 +426,8 @@ A ReplicationController will never terminate on its own, but it isn't expected t

 多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本，一部分流量流向新版本。

-一个 ReplicationController 永远不会自行终止，但它不会像服务那样长寿。
-服务可以由多个 ReplicationController 控制的 pod 组成，并且在服务的生命周期内（例如，为了执行 pod 更新而运行服务），可以创建和销毁许多 ReplicationController。
+一个 ReplicationController 永远不会自行终止，但它不会像服务那样长时间存活。
+服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内（例如，为了执行 pod 更新而运行服务），可以创建和销毁许多 ReplicationController。
 服务本身和它们的客户端都应该忽略负责维护服务 Pod 的 ReplicationController 的存在。

 <!--
@@ -425,35 +439,38 @@ Pods created by a ReplicationController are intended to be fungible and semantic

 由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的，尽管随着时间的推移，它们的配置可能会变得异构。
 这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、分片和工作池应用程序的可用性。
-这样的应用程序应该使用动态的工作分配机制，例如 [RabbitMQ工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)，而不是静态的/一次性定制每个 pod 的配置，这被认为是一种反模式。
+这样的应用程序应该使用动态的工作分配机制，例如 [RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)，而不是静态的或者一次性定制每个 pod 的配置，这被认为是一种反模式。
 执行的任何 pod 定制，例如资源的垂直自动调整大小(例如，cpu 或内存)，都应该由另一个在线控制器进程执行，这与 ReplicationController 本身没什么不同。

 <!--
 ## Responsibilities of the ReplicationController
-
-The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
-
-The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
-
-The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
 -->
 ## ReplicationController 的职责

+<!--
+The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
+-->
 ReplicationController 只需确保所需的 pod 数量与其标签选择器匹配，并且是可操作的。
 目前，它的计数中只排除终止的 pod。
 未来，可能会考虑系统提供的[就绪状态](http://issue.k8s.io/620)和其他信息，我们可能会对替换策略添加更多控制，我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。

+<!--
+The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
+-->
 ReplicationController 永远被限制在这个狭隘的职责范围内。
 它本身既不执行就绪态探测，也不执行活跃性探测。
-它不负责执行自动缩放，而是由外部自动缩放器控制（如[#492](http://issue.k8s.io/492)中所述），后者负责更改其 `replicas` 字段取值。
+它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](http://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。
 我们不会向 ReplicationController 添加调度策略(例如，[spreading](http://issue.k8s.io/367#issuecomment-48428019))。
 它也不应该验证所控制的 pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。
 类似地，完成期限、整理依赖关系、配置扩展和其他特性也属于其他地方。
-我们甚至计划考虑批量创建 pod 的机制（[#170](http://issue.k8s.io/170)）。
+我们甚至计划考虑批量创建 pod 的机制（查阅 [#170](http://issue.k8s.io/170)）。

+<!--
+The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
+-->
 ReplicationController 旨在成为可组合的构建基元。
-我们希望在它和其他补充原语的基础上构建更高级别的 API 和/或工具，以便于将来的用户使用。
-Kubectl 目前支持的“宏”操作（运行、缩放、滚动更新）就是这方面的概念示例。
+我们希望在它和其他补充原语的基础上构建更高级别的 API 或者工具，以便于将来的用户使用。
+kubectl 目前支持的 "macro" 操作（运行、缩放、滚动更新）就是这方面的概念示例。
 例如，我们可以想象类似于 [Asgard](http://techblog.netflix.com/2012/06/asgaard-web-based-cloud-management-and.html) 的东西管理 ReplicationController、自动定标器、服务、调度策略、 canary 等。

 <!--
@@ -504,7 +521,7 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and

 Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker).
 -->
-### 裸 Pods
+### 裸 Pod

 与用户直接创建 pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。
 因此，我们建议您使用 ReplicationController，即使您的应用程序只需要一个 pod。
@@ -532,7 +549,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 ### DaemonSet

 对于提供机器级功能（例如机器监控或机器日志记录）的 pod ，使用 [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不是 ReplicationController。
-这些 pod 的生命期与机器的生命期绑定：它们需要在其他 pod 启动之前在机器上运行，并且在机器准备重新启动/关闭时安全地终止。
+这些 pod 的生命期与机器的生命期绑定：它们需要在其他 pod 启动之前在机器上运行，并且在机器准备重新启动或者关闭时安全地终止。

 <!--
 ## For more information
@@ -1,11 +1,4 @@
 ---
-reviewers:
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
- smarterclayton
 title: StatefulSets
 content_template: templates/concept
 weight: 40
@@ -34,13 +27,6 @@ StatefulSet is the workload API object used to manage stateful applications.

 StatefulSet 是用来管理有状态应用的工作负载 API 对象。

-{{< note >}}
-
-<!--**Note:** StatefulSets are stable (GA) in 1.9.-->
-**注意** StatefulSets 是在 1.9 版本中正式发布的。
-
-{{< /note >}}
-
 {{< glossary_definition term_id="statefulset" length="all" >}}
 {{% /capture %}}

@@ -48,15 +34,27 @@ StatefulSet 是用来管理有状态应用的工作负载 API 对象。

 <!--
 ## Using StatefulSets
+-->
+## 使用 StatefulSets

+<!--
 StatefulSets are valuable for applications that require one or more of the
 following.
+-->
+StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

+<!--
 * Stable, unique network identifiers.
 * Stable, persistent storage.
 * Ordered, graceful deployment and scaling.
 * Ordered, automated rolling updates.
+-->
+* 稳定的、唯一的网络标识符。
+* 稳定的、持久的存储。
+* 有序的、优雅的部署和缩放。
+* 有序的、自动的滚动更新。

+<!--
 In the above, stable is synonymous with persistence across Pod (re)scheduling.
 If an application doesn't require any stable identifiers or ordered deployment,
 deletion, or scaling, you should deploy your application using a workload object
@@ -64,21 +62,14 @@ that provides a set of stateless replicas.
 [Deployment](/docs/concepts/workloads/controllers/deployment/) or
 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
 -->
-
-## 使用 StatefulSets
-
-StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
-
-* 稳定的、唯一的网络标识符。
-* 稳定的、持久的存储。
-* 有序的、优雅的部署和缩放。
-* 有序的、自动的滚动更新。
-
-在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态需要。
+在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。

 <!--
 ## Limitations
+-->
+## 限制

+<!--
 * The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
 * Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
 * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
@@ -87,13 +78,9 @@ StatefulSets 对于需要满足以下一个或多个需求的应用程序很有
  [Pod Management Policy](#pod-management-policies) (`OrderedReady`),
  it's possible to get into a broken state that requires
  [manual intervention to repair](#forced-rollback).
-
 -->
-
-## 限制
-
 * 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。
-* 删除和／或收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
+* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
 * StatefulSet 当前需要 [headless 服务](/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。
 * 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。
 * 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates)，可能进入需要 [人工干预](#forced-rollback) 才能修复的损坏状态。
@@ -101,20 +88,11 @@ StatefulSets 对于需要满足以下一个或多个需求的应用程序很有
 <!--
 ## Components
 The example below demonstrates the components of a StatefulSet.
-
-* A Headless Service, named nginx, is used to control the network domain.
-* The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
-* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
 -->
-
 ## 组件
+
 下面的示例演示了 StatefulSet 的组件。

-* 名为 nginx 的无头服务用来控制网络域。
-* 名为 web 的 StatefulSet 有一个 Spec，它表明将在单个 Pod 中启动 nginx 容器的 3 个副本。
-* volumeClaimTemplates 将通过 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 驱动提供的 PersistentVolume 来提供稳定的存储。
-
-
 ```yaml
 apiVersion: v1
 kind: Service
@@ -166,39 +144,54 @@ spec:
          storage: 1Gi
 ```

+<!--
+* A Headless Service, named `nginx`, is used to control the network domain.
+* The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
+* The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
+-->
+* 名为 `nginx` 的 Headless Service 用来控制网络域名。
+* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
+* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+
 <!--
 ## Pod Selector
+-->
+## Pod 选择器 {#pod-selector}
+
+<!--
 You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
 -->
-
-## Pod 选择器
-您必须设置 StatefulSet 的 `.spec.selector` 字段来匹配它的`.spec.template.metadata.labels`标签。在 Kubernetes 1.8 版本之前，忽略`.spec.selector` 字段会提供默认设置。在 1.8 和以后的版本中，指定的 Pod 选择器匹配失败将在创建 StatefulSet 期间导致验证错误。
+您必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 `.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前，被忽略 `.spec.selector` 字段会获得默认设置值。在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。

 <!--
 ## Pod Identity
+-->
+## Pod 标识
+
+<!--
 StatefulSet Pods have a unique identity that is comprised of an ordinal, a
 stable network identity, and stable storage. The identity sticks to the Pod,
 regardless of which node it's (re)scheduled on.
 -->
-
-## Pod 的身份
-
 StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。

 <!--
 ### Ordinal Index
+-->
+### 有序索引

+<!--
 For a StatefulSet with N replicas, each Pod in the StatefulSet will be
 assigned an integer ordinal, from 0 up through N-1, that is unique over the Set.
 -->
-
-### 有序索引
-
 对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。

 <!--
 ### Stable Network ID
+-->
+### 稳定的网络 ID

+<!--
 Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet
 and the ordinal of the Pod. The pattern for the constructed hostname
 is `$(statefulset name)-$(ordinal)`. The example above will create three Pods
@@ -211,14 +204,10 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form:
 `$(podname).$(governing service domain)`, where the governing service is defined
 by the `serviceName` field on the StatefulSet.
 -->
-
-### 稳定的网络 ID
-
-StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为`$(statefulset name)-$(ordinal)`。上例将会创建三个名称为`web-0,web-1,web-2`的三个 Pod。
+StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
 StatefulSet 可以使用 [headless 服务](/docs/concepts/services-networking/service/#headless-services) 控制它的 Pod 的网络域。管理域的这个服务的格式为：
-`$(service name).$(namespace).svc.cluster.local`，其中`cluster.local`是集群域。
- 一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：`$(podname).$(governing service domain)`，其中管理服务由 StatefulSet 的 `serviceName` 域来定义。
-
+`$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
+一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：`$(pod 名称).$(所属服务的 DNS 域名)`，其中所属服务由 StatefulSet 的 `serviceName` 域来设定。

 <!--
 Here are some examples of choices for Cluster Domain, Service name,
@@ -233,19 +222,20 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name)  | StatefulSet Domain
 cluster.local | foo/nginx         | foo/web           | nginx.foo.svc.cluster.local     | web-{0..N-1}.nginx.foo.svc.cluster.local     | web-{0..N-1} |
 kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |

-{{< note >}}
-
 <!--
-**Note:** Cluster Domain will be set to `cluster.local` unless
+Cluster Domain will be set to `cluster.local` unless
 [otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
 -->
-**注意** 集群域会被设置为 `cluster.local` 除非有[其他配置](/docs/concepts/services-networking/dns-pod-service/#how-it-works)。
-
+{{< note >}}
+集群域会被设置为 `cluster.local`，除非有[其他配置](/docs/concepts/services-networking/dns-pod-service/#how-it-works)。
 {{< /note >}}

 <!--
 ### Stable Storage
+-->
+### 稳定的存储

+<!--
 Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each
 VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
 with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
@@ -255,38 +245,34 @@ PersistentVolume Claims. Note that, the PersistentVolumes associated with the
 Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
 This must be done manually.
 -->
-
-### 稳定的存储
-
-Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/docs/concepts/storage/persistent-volumes/)。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。当一个 Pod 被安排到节点上时，它的 `volumeMounts` 挂载了与其 PersistentVolumeClaims 相关联的 PersistentVolume。请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。
-
+Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/docs/concepts/storage/persistent-volumes/)。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 PersistentVolumeClaims 相关联的 PersistentVolume。请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。

 <!--
 ### Pod Name Label
+-->
+### Pod 名称标签

+<!--
 When the StatefulSet {{< glossary_tooltip term_id="controller" >}} creates a Pod,
 it adds a label, `statefulset.kubernetes.io/pod-name`, that is set to the name of
 the Pod. This label allows you to attach a Service to a specific Pod in
 the StatefulSet.
 -->
-
-### Pod 名称标签
-
 当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。

 <!--
 ## Deployment and Scaling Guarantees
+-->
+## 部署和扩缩保证

+<!--
 * For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
 * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
 * Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
 * Before a Pod is terminated, all of its successors must be completely shutdown.
 -->
-
-## 部署和伸缩保证
-
-* 对于包含 N 个 副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为`0..N-1`。
-* 当删除 Pod 时，它们是逆序终止的，顺序为`N-1..0`。
+* 对于包含 N 个 副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为 `0..N-1`。
+* 当删除 Pod 时，它们是逆序终止的，顺序为 `N-1..0`。
 * 在将缩放操作应用到 Pod 之前，它前面的所有 Pod 必须是 Running 和 Ready 状态。
 * 在 Pod 终止之前，所有的继任者必须完全关闭。

@@ -294,7 +280,7 @@ the StatefulSet.
 The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
 -->

-StatefulSet 不应该声明 `pod.Spec.TerminationGracePeriodSeconds` 为 0。这种做法是不安全的，要强烈阻止。更多的解释请参考 [强制删除 StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)。
+StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。这种做法是不安全的，要强烈阻止。更多的解释请参考 [强制删除 StatefulSet Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/)。

 <!--
 When the nginx example above is created, three Pods will be deployed in the order
@@ -315,67 +301,76 @@ is completely shutdown, but prior to web-1's termination, web-1 would not be ter
 until web-0 is Running and Ready.
 -->

- 如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。
+如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。

 <!--
 ### Pod Management Policies
+-->
+### Pod 管理策略 {#pod-management-policies}
+
+<!--
 In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
 preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field.
+-->
+在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
+在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。

+<!--
 #### OrderedReady Pod Management
+-->
+#### OrderedReady Pod 管理

+<!--
 `OrderedReady` pod management is the default for StatefulSets. It implements the behavior
 described [above](#deployment-and-scaling-guarantees).
+-->
+`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。

+<!--
 #### Parallel Pod Management
+-->
+#### Parallel Pod 管理

+<!--
 `Parallel` pod management tells the StatefulSet controller to launch or
 terminate all Pods in parallel, and to not wait for Pods to become Running
 and Ready or completely terminated prior to launching or terminating another
 Pod.
 -->
-
-### Pod 管理策略 {#pod-management-policies}
-在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放松其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
-
-#### 有序的 Pod 管理
-
-`有序的` Pod 管理是 StatefulSet 的默认功能。它实现了 [上面](#deployment-and-scaling-guarantees)描述的行为。
-
-#### 并行的 Pod 管理
-
-`并行` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。
+`Parallel` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。

 <!--
 ## Update Strategies
+-->
+## 更新策略

+<!--
 In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
 and disable automated rolling updates for containers, labels, resource request/limits, and
 annotations for the Pods in a StatefulSet.
 -->
-
-## 更新策略
-
-在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求／限制、以及注解。
-
+在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。

 <!--
 ### On Delete
+-->
+### 关于删除策略

+<!--
 The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. When a StatefulSet's
 `.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
 update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
 create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
 -->
-
-### On Delete
-
 `OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。


 <!--
 ### Rolling Updates
+-->
+### 滚动更新 {#rolling-updates}

+<!--
 The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
 StatefulSet. It is the default strategy when `.spec.updateStrategy` is left unspecified. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
 StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
@@ -383,16 +378,16 @@ in the same order as Pod termination (from the largest ordinal to the smallest),
 each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
 updating its predecessor.
 -->
-
-### 滚动更新 {#rolling-updates}
-
-`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明`.spec.updateStrategy`时，`RollingUpdate`是默认配置。
+`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。
 当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。
 它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。

 <!--
 #### Partitions
+-->
+#### 分区

+<!--
 The `RollingUpdate` update strategy can be partitioned, by specifying a
 `.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
 ordinal that is greater than or equal to the partition will be updated when the StatefulSet's
@@ -403,15 +398,15 @@ updates to its `.spec.template` will not be propagated to its Pods.
 In most cases you will not need to use a partition, but they are useful if you want to stage an
 update, roll out a canary, or perform a phased roll out.
 -->
-
-#### 分区
-
-通过声明 `.spec.updateStrategy.rollingUpdate.partition`的方式，`RollingUpdate`更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的`.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。
+通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。
 在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。

 <!--
 #### Forced Rollback
+-->
+#### 强制回滚 {#forced-rollback}

+<!--
 When using [Rolling Updates](#rolling-updates) with the default
 [Pod Management Policy](#pod-management-policies) (`OrderedReady`),
 it's possible to get into a broken state that requires manual intervention to repair.
@@ -430,14 +425,11 @@ After reverting the template, you must also delete any Pods that StatefulSet had
 already attempted to run with the bad configuration.
 StatefulSet will then begin to recreate the Pods using the reverted template.
 -->
-#### 强制回滚 {#forced-rollback}
-
 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。

 如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。

-在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于 [已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，
-StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。
+在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于[已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。

 恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样，StatefulSet 才会开始使用被还原的模板来重新创建 Pod。

@@ -447,11 +439,12 @@ StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生
 <!--
 * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
 * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
+* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
 -->

 * 示例一：[部署有状态应用](/docs/tutorials/stateful-application/basic-stateful-set/)。
 * 示例二：[使用 StatefulSet 部署 Cassandra](/docs/tutorials/stateful-application/cassandra/)。
-
+* 示例三：[运行多副本的有状态应用程序](/docs/tasks/run-application/run-replicated-stateful-application/)。

 {{% /capture %}}

@@ -1,6 +1,4 @@
 ---
-reviewers:
- janetkuo
 title: 已完成资源的 TTL 控制器
 content_template: templates/concept
 weight: 65
@@ -20,15 +18,20 @@ weight: 65
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 <!--
-The TTL controller provides a TTL mechanism to limit the lifetime of resource objects that have finished execution. TTL controller only handles[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for now, and may be expanded to handle other resources that will finish execution,such as Pods and custom resources.
+The TTL controller provides a TTL mechanism to limit the lifetime of resource
+objects that have finished execution. TTL controller only handles
+[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for
+now, and may be expanded to handle other resources that will finish execution,
+such as Pods and custom resources.
 -->
-TTL 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。TTL 控制器目前只处理[作业](/docs/concepts/workloads/controllers/jobs-run-to-completion/)，可能以后会扩展以处理将完成执行的其他资源，例如 Pod 和自定义资源。
+TTL 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。TTL 控制器目前只处理 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)，可能以后会扩展以处理将完成执行的其他资源，例如 Pod 和自定义资源。

 <!--
-Alpha Disclaimer: this feature is currently alpha, and can be enabled with[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)`TTLAfterFinished`.
+Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`TTLAfterFinished`.
 -->
-Alpha 免责声明：此功能目前是 alpha 版，可以通过[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished` 启用。
-
+Alpha 免责声明：此功能目前是 alpha 版，并且可以通过 kube-apiserver 和 kube-controller-manager [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished` 启用。

 {{% /capture %}}

@@ -41,16 +44,24 @@ Alpha 免责声明：此功能目前是 alpha 版，可以通过[feature gate](/
 ## TTL 控制器

 <!--
-The TTL controller only supports Jobs for now. A cluster operator can use this feature to cleanup finished Jobs (either `Complete` or `Failed`) automatically by specifying the`.spec.ttlSecondsAfterFinished` field of a Job, as in this[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
+up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
+`.spec.ttlSecondsAfterFinished` field of a Job, as in this
+[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
 -->
-TTL 控制器现在只支持 Jobs。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来自动清理已结束的作业（“完成”或“失败”），就像下边的[示例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)。
+TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如下所示的[示例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)。
 <!--
-The TTL controller will assume that a resource is eligible to be cleaned upTTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete its dependent objects together with it. Note that when the resource is deleted,its lifecycle guarantees, such as finalizers, will be honored.
+The TTL controller will assume that a resource is eligible to be cleaned up
+TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
+TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete
+its dependent objects together with it. Note that when the resource is deleted,
+its lifecycle guarantees, such as finalizers, will be honored.
 -->
-TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。当 TTL 控制器清理资源时，它将做级联删除，即删除资源对象的同时也删除其依赖对象。注意，当资源被删除时，由该资源的生命周期保证其终结器（finalizers）等被执行。
+TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。当 TTL 控制器清理资源时，它将做级联删除操作，如删除资源对象的同时也删除其依赖对象。注意，当资源被删除时，由该资源的生命周期保证其终结器（finalizers）等被执行。

 <!--
-The TTL seconds can be set at any time. Here are some examples for setting the`.spec.ttlSecondsAfterFinished` field of a Job:
+The TTL seconds can be set at any time. Here are some examples for setting the
+`.spec.ttlSecondsAfterFinished` field of a Job:
 -->
 可以随时设置 TTL 秒。以下是设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段的一些示例：

@@ -68,9 +79,9 @@ The TTL seconds can be set at any time. Here are some examples for setting the`.
  to set this field dynamically after the resource has finished, and choose
  different TTL values based on resource status, labels, etc.
 -->
-* 在资源清单（manifest）中指定此字段，以便作业在完成后的某个时间被自动清除。
+* 在资源清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。
 * 将此字段设置为存在的、已完成的资源，以采用此新功能。
-* 在资源创建时使用 [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。
+* 在创建资源时使用 [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。
 * 使用 [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 在资源完成后动态设置该字段，并根据资源状态、标签等选择不同的 TTL 值。

 <!--
@@ -84,9 +95,13 @@ The TTL seconds can be set at any time. Here are some examples for setting the`.
 ### 更新 TTL 秒

 <!--
-Note that the TTL period, e.g. `.spec.ttlSecondsAfterFinished` field of Jobs,can be modified after the resource is created or has finished. However, once the Job becomes eligible to be deleted (when the TTL has expired), the system won't guarantee that the Jobs will be kept, even if an update to extend the TTL returns a successful API response.
+Note that the TTL period, e.g. `.spec.ttlSecondsAfterFinished` field of Jobs,
+can be modified after the resource is created or has finished. However, once the
+Job becomes eligible to be deleted (when the TTL has expired), the system won't
+guarantee that the Jobs will be kept, even if an update to extend the TTL
+returns a successful API response.
 -->
-请注意，在创建资源后或已经执行结束后，仍可以修改其 TTL 周期，例如作业的 `.spec.ttlSecondsAfterFinished` 字段。但是，一旦作业变为可被删除状态（当其 TTL 已过期时），即使您通过 API 扩展其 TTL 时长得到了成功的响应，系统也不保证作业将被保留。
+请注意，在创建资源或已经执行结束后，仍可以修改其 TTL 周期，例如 Job 的 `.spec.ttlSecondsAfterFinished` 字段。但是，一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使您通过 API 扩展其 TTL 时长得到了成功的响应，系统也不保证 Job 将被保留。

 <!--
 ### Time Skew
@@ -94,14 +109,20 @@ Note that the TTL period, e.g. `.spec.ttlSecondsAfterFinished` field of Jobs,can
 ### 时间偏差

 <!--
-Because TTL controller uses timestamps stored in the Kubernetes resources to determine whether the TTL has expired or not, this feature is sensitive to time skew in the cluster, which may cause TTL controller to clean up resource objects at the wrong time.
+Because TTL controller uses timestamps stored in the Kubernetes resources to
+determine whether the TTL has expired or not, this feature is sensitive to time
+skew in the cluster, which may cause TTL controller to clean up resource objects
+at the wrong time.
 -->
 由于 TTL 控制器使用存储在 Kubernetes 资源中的时间戳来确定 TTL 是否已过期，因此该功能对集群中的时间偏差很敏感，这可能导致 TTL 控制器在错误的时间清理资源对象。

 <!--
-In Kubernetes, it's required to run NTP on all nodes(see [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058))to avoid time skew. Clocks aren't always correct, but the difference should bevery small. Please be aware of this risk when setting a non-zero TTL.
+In Kubernetes, it's required to run NTP on all nodes
+(see [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058))
+to avoid time skew. Clocks aren't always correct, but the difference should be
+very small. Please be aware of this risk when setting a non-zero TTL.
 -->
-在 Kubernetes 中，需要在所有节点上运行 NTP（参见[#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)）以避免时间偏差。时钟并不总是如此正确，但差异应该很小。设置非零 TTL 时请注意这种风险。
+在 Kubernetes 中，需要在所有节点上运行 NTP（参见 [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)）以避免时间偏差。时钟并不总是如此正确，但差异应该很小。设置非零 TTL 时请注意避免这种风险。

 {{% /capture %}}

@@ -110,7 +131,7 @@ In Kubernetes, it's required to run NTP on all nodes(see [#6159](https://github.
 <!--
 [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
 -->
-[自动清理作业](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[自动清理 Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)

 <!--
 [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
@@ -17,7 +17,7 @@ weight: 80

 {{% capture overview %}}

-{{< feature-state state="alpha" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.16" >}}

 <!--
 This page provides an overview of ephemeral containers: a special type of container
@@ -37,8 +37,7 @@ feature could change significantly in the future or be removed entirely.
 -->

 {{< warning >}}
-临时容器处于早期的 alpha 阶段，不适用于生成环境集群。应该预料到临时容器在某些情况下不起作用，例如在定位容器的名称命名空间。根据 [Kubernetes
-弃用政策](/docs/reference/using-api/deprecation-policy/)，该 alpha 功能将来可能发生重大变化或完全删除。
+临时容器处于早期的 alpha 阶段，不适用于生产环境集群。应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)，该 alpha 功能将来可能发生重大变化或完全删除。
 {{< /warning >}}

 {{% /capture %}}
@@ -125,8 +124,7 @@ exec` is insufficient because a container has crashed or a container image
 doesn't include debugging utilities.
 -->

-当容器崩溃或容器镜像中不包含调试工具时，使用 `kubectl
-exec` 命令进行故障排查不足，临时容器对于交互式故障处理很有用。
+当由于容器崩溃或容器镜像不包含调试实用程序而导致 `kubectl exec` 无用时，临时容器对于交互式故障排查很有用。

 <!--
 In particular, [distroless images](https://github.com/GoogleContainerTools/distroless)
@@ -150,12 +148,12 @@ you can view processes in other containers.
 ### Examples
 -->

-### 例子
+### 示例

 <!--
 The examples in this section require the `EphemeralContainers` [feature
 gate](/docs/reference/command-line-tools-reference/feature-gates/) to be
-enabled and kubernetes client and server version v1.16 or later.
+enabled, and Kubernetes client and server version v1.16 or later.
 -->

 {{< note >}}
@@ -164,11 +162,11 @@ enabled and kubernetes client and server version v1.16 or later.

 <!--
 The examples in this section demonstrate how ephemeral containers appear in
-the API. Users would normally use a `kubectl` plugin for troubleshooting that
-would automate these steps.
+the API. You would normally use a `kubectl` plugin for troubleshooting that
+automates these steps.
 -->

-本节中的示例演示了临时容器如何在 API 中出现。用户通常会使用 `kubectl` 插件来进行故障排查，从而自动化执行这些步骤。
+本节中的示例演示了临时容器如何出现在 API 中。 通常，您可以使用 `kubectl` 插件进行故障排查，从而自动化执行这些步骤。

 <!--
 Ephemeral containers are created using the `ephemeralcontainers` subresource
@@ -287,13 +285,26 @@ kubectl attach -it example-pod -c debugger
 ```

 <!--
-If process namespace sharing is enabled, you can see processes from all the containers in that Pod. For example:
+If process namespace sharing is enabled, you can see processes from all the containers in that Pod.
+For example, after attaching, you run `ps` in the debugger container:
 -->

-如果启用了进程命名空间共享，则可以从该 Pod 的所有容器中查看进程。如下所示：
+如果启用了进程命名空间共享，则可以查看该 Pod 所有容器中的进程。
+例如，运行上述 `attach` 操作后，在调试器容器中运行 `ps` 操作：
+
+<!--
+# Run this in a shell inside the "debugger" ephemeral container
+# 在 "debugger" 临时容器内中运行此 shell 命令
+The output is similar to:
+
+-->

 ```shell
-/ # ps auxww
+# 在 "debugger" 临时容器内中运行此 shell 命令
+ps auxww
+```
+运行命令后，输出类似于：
+```
 PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
@@ -1,9 +1,10 @@
 ---
-reviewers:
- erictune
 title: Pod 概览
 content_template: templates/concept
 weight: 10
+card: 
+  name: 概念
+  weight: 60
 ---

 <!--
@@ -13,13 +14,16 @@ reviewers:
 title: Pod Overview
 content_template: templates/concept
 weight: 10
+card: 
+  name: concepts
+  weight: 60
 ---
 -->

-{{% capture overview %}}
 <!--
 This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
 -->
+{{% capture overview %}}
 本节提供了 `Pod` 的概览信息，`Pod` 是最小可部署的 Kubernetes 对象模型。
 {{% /capture %}}

@@ -28,71 +32,65 @@ This page provides an overview of `Pod`, the smallest deployable object in the K

 <!--
 ## Understanding Pods
-
-A *Pod* is the basic building block of Kubernetes--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents a running process on your cluster.
 -->
-
 ## 理解 Pod

-*Pod* 是 Kubernetes 的基本构建块，它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。
-Pod 表示集群上正在运行的进程。
-
 <!--
-A Pod encapsulates an application container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.
+A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" >}}.
 -->
-
-Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
-Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个容器或少量紧密耦合并共享资源的容器组成。
+*Pod* 是 Kubernetes 应用程序的基本执行单元，即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 {{< glossary_tooltip term_id="cluster" >}} 上运行的进程。

 <!--
-> [Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) as well.
+A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
+-->
+Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
+Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个 {{< glossary_tooltip text="容器" term_id="container" >}} 或少量紧密耦合并共享资源的容器组成。

+<!--
+[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
+-->
+[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的[容器运行时](/docs/setup/production-environment/container-runtimes/)。
+
+
+<!--
 Pods in a Kubernetes cluster can be used in two main ways:
 -->
-[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的[容器运行时](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)。
-
 Kubernetes 集群中的 Pod 可被用于以下两个主要用途：

 <!--
 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
 * **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
+The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
 -->

 * **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
 * **运行多个协同工作的容器的 Pod**。
 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
-这些位于同一位置的容器可能形成单个内聚的服务单元——一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”容器则刷新或更新这些文件。
+这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。
 Pod 将这些容器和存储资源打包为一个可管理的实体。
+[Kubernetes 博客](https://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考：

 <!--
-The [Kubernetes Blog](http://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
-
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
-* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
+  * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+  * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
 -->
-
-[Kubernetes 博客](http://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考：
-
-* [分布式系统工具包：复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
-* [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns)
+  * [分布式系统工具包：容器组合的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+  * [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns)

 <!--
 Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
 -->

-每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个实例使用一个。
-在 Kubernetes 中，这通常被称为 _副本_。
-通常使用一个称为控制器的抽象来创建和管理一组被复制的 Pod。
-更多信息请参见 [POD 和控制器](#pods-and-controllers)。
+每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个应用实例使用一个 Pod 。在 Kubernetes 中，这通常被称为 _副本_。通常使用一个称为控制器的抽象来创建和管理一组副本 Pod。更多信息请参见 [Pod 和控制器](#pods-and-controllers)。

 <!--
 ### How Pods manage multiple Containers
-
-Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
 -->
-
 ### Pod 怎样管理多个容器

+<!--
+Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
+-->
 Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。
 Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。
 容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。
@@ -103,10 +101,16 @@ Note that grouping multiple co-located and co-managed containers in a single Pod

 注意，在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。
 只在容器紧密耦合的特定实例中使用此模式。
-例如，您可能有个充当共享卷中文件的 Web 服务器的容器，以及从远程源更新这些文件的单独的"挂斗"容器，如下图所示：
+例如，您可能有一个充当共享卷中文件的 Web 服务器的容器，以及一个单独的 sidecar 容器，该容器从远端更新这些文件，如下图所示：


-{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" alt="Pod 图例" width="50%" >}}
+
+
+<!--
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
+-->
+有些 Pod 具有 {{< glossary_tooltip text="初始容器" term_id="init-container" >}} 和 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。初始容器会在启动应用容器之前运行并完成。

 <!--
 Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
@@ -116,12 +120,12 @@ Pod 为其组成容器提供了两种共享资源：*网络* 和 *存储*。

 <!--
 #### Networking
+-->
+#### 网络

+<!--
 Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
 -->
-
-#### 联网
-
 每个 Pod 分配一个唯一的 IP 地址。
 Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。
 *Pod 内的容器* 可以使用 `localhost` 互相通信。
@@ -129,33 +133,34 @@ Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口

 <!--
 #### Storage
-
-A Pod can specify a set of shared storage *volumes*. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
 -->
-
 #### 存储

-一个 Pod 可以指定一组共享存储 *卷*。
+<!--
+A Pod can specify a set of shared storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
+-->
+一个 Pod 可以指定一组共享存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
 Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。
-卷还允许 Pod 中的持久数据在重启 Pod 中的某个容器时存活。
-有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息，请参考 [卷](/docs/concepts/storage/volumes/)。
+卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。
+有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息，请参考[卷](/docs/concepts/storage/volumes/)。

 <!--
 ## Working with Pods
-
-You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the pod is *evicted* for lack of resources, or the Node fails.
 -->
-
 ## 使用 Pod

+<!--
+You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the Node fails.
+-->
 你很少在 Kubernetes 中直接创建单独的 Pod，甚至是单个存在的 Pod。
 这是因为 Pod 被设计成了相对短暂的一次性的实体。
-当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的节点上运行。
+当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的 {{< glossary_tooltip term_id="node" >}} 上运行。
 Pod 会保持在该节点上运行，直到进程被终止、Pod 对象被删除、Pod 因资源不足而被 *驱逐* 或者节点失效为止。
-{{< note >}}
+
 <!--
 Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
 -->
+{{< note >}}
 重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。
 {{< /note >}}

@@ -171,47 +176,48 @@ Kubernetes 使用了一个更高级的称为 *控制器* 的抽象，由它处

 <!--
 ### Pods and Controllers
+-->
+### Pod 和控制器 {#pods-and-controllers}

+<!--
 A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
 -->
-
-### Pod 和控制器
-
 控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。
 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

 <!--
 Some examples of Controllers that contain one or more pods include:
-
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-
-In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
 -->
-
 包含一个或多个 Pod 的控制器一些示例包括：

+<!--
+* [Deployment](/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+-->
 * [Deployment](/docs/concepts/workloads/controllers/deployment/)
 * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
 * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)

+<!--
+In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
+-->
 控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。

 <!--
 ## Pod Templates
+-->
+## Pod 模板

+<!--
 Pod templates are pod specifications which are included in other objects, such as
 [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).  Controllers use Pod Templates to make actual pods.
 The sample below is a simple manifest for a Pod which contains a container that prints
 a message.
 -->
-
-## Pod 模板
-
 Pod 模板是包含在其他对象中的 Pod 规范，例如
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/)、和
+[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) 和
 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。
 控制器使用 Pod 模板来制作实际使用的 Pod。
 下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。
@@ -244,13 +250,15 @@ Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状

 {{% /capture %}}

-{{% capture whatsnext %}}
 <!--
+* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
 * Learn more about Pod behavior:
  * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
-  * Other Pod Topics
+  * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
 -->
-* 进一步了解 Pod 的行为：
+{{% capture whatsnext %}}
+* 详细了解 [Pod](/docs/concepts/workloads/pods/pod/)
+* 了解有关 Pod 行为的更多信息：
  * [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
-  * 其他 Pod 话题
+  * [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}
@@ -1,17 +1,14 @@
 ---
-reviewers:
 title: Pods
 content_template: templates/concept
 weight: 20
 ---

 <!--
---
 reviewers:
 title: Pods
 content_template: templates/concept
 weight: 20
---
 -->

 {{% capture overview %}}
@@ -21,7 +18,7 @@ _Pods_ are the smallest deployable units of computing that can be created and
 managed in Kubernetes.
 -->

-_Pods_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
+_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

 {{% /capture %}}

@@ -30,151 +27,152 @@ _Pods_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计

 <!--
 ## What is a Pod?
+-->
+## Pod 是什么？

-A _pod_ (as in a pod of whales or pea pod) is a group of one or more containers
-(such as Docker containers), with shared storage/network, and a specification
-for how to run the containers.  A pod's contents are always co-located and
-co-scheduled, and run in a shared context.  A pod models an
+<!--
+A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
+{{< glossary_tooltip text="containers" term_id="container" >}} (such as
+Docker containers), with shared storage/network, and a specification
+for how to run the containers.  A Pod's contents are always co-located and
+co-scheduled, and run in a shared context.  A Pod models an
 application-specific "logical host" - it contains one or more application
 containers which are relatively tightly coupled &mdash; in a pre-container
 world, being executed on the same physical or virtual machine would mean being
 executed on the same logical host.
 -->
-
-## Pod 是什么？
-
-_pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器（例如 Docker 容器），这些容器有共享存储、网络、以及怎样运行这些容器的声明。Pod 的内容总是共同定位和共同调度，并且在共享的上下文中运行。
-Pod 以特定于应用的“逻辑主机”为模型，它包含一个或多个应用容器，这些容器是相对紧密的耦合在一起；在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。
+_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）{{< glossary_tooltip text="容器" term_id="container" >}}（例如 Docker 容器），这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
+Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 &mdash; 在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。

 <!--
 While Kubernetes supports more container runtimes than just Docker, Docker is
-the most commonly known runtime, and it helps to describe pods in Docker terms.
+the most commonly known runtime, and it helps to describe Pods in Docker terms.
+-->
+虽然 Kubernetes 支持多种容器运行时，但 Docker 是最常见的一种运行时，它有助于使用 Docker 术语来描述 Pod。

-The shared context of a pod is a set of Linux namespaces, cgroups, and
+<!--
+The shared context of a Pod is a set of Linux namespaces, cgroups, and
 potentially other facets of isolation - the same things that isolate a Docker
-container.  Within a pod's context, the individual applications may have
+container.  Within a Pod's context, the individual applications may have
 further sub-isolations applied.
 -->
-
-虽然 Kubernetes 支持多种容器运行时，但 Docker 是最常见的一种运行时，它有助于描述 Docker 术语中的 Pod。
-
 Pod 的共享上下文是一组 Linux 命名空间、cgroups、以及其他潜在的资源隔离相关的因素，这些相同的东西也隔离了 Docker 容器。在 Pod 的上下文中，单个应用程序可能还会应用进一步的子隔离。

 <!--
-Containers within a pod share an IP address and port space, and
+Containers within a Pod share an IP address and port space, and
 can find each other via `localhost`. They can also communicate with each
 other using standard inter-process communications like SystemV semaphores or
-POSIX shared memory.  Containers in different pods have distinct IP addresses
+POSIX shared memory.  Containers in different Pods have distinct IP addresses
 and can not communicate by IPC without
 [special configuration](/docs/concepts/policy/pod-security-policy/).
 These containers usually communicate with each other via Pod IP addresses.

-Applications within a pod also have access to shared volumes, which are defined
-as part of a pod and are made available to be mounted into each application's
+Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
+as part of a Pod and are made available to be mounted into each application's
 filesystem.
 -->
-
 Pod 中的所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信（如 SystemV 信号量或 POSIX 共享内存）方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。

-Pod 中的应用也能访问共享卷，共享卷是 Pod 定义的一部分，可被用来挂载到每个应用的文件系统上。
+Pod 中的应用也能访问共享 {{< glossary_tooltip text="卷" term_id="volume" >}}，共享卷是 Pod 定义的一部分，可被用来挂载到每个应用的文件系统上。

 <!--
-In terms of [Docker](https://www.docker.com/) constructs, a pod is modelled as
-a group of Docker containers with shared namespaces and shared
-[volumes](/docs/concepts/storage/volumes/).
+In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
+a group of Docker containers with shared namespaces and shared filesystem
+volumes.
+-->
+在 [Docker](https://www.docker.com/) 体系的术语中，Pod 被建模为一组具有共享命名空间和共享文件系统[卷](/docs/concepts/storage/volumes/) 的 Docker 容器。

-Like individual application containers, pods are considered to be relatively
-ephemeral (rather than durable) entities. As discussed in [life of a
-pod](/docs/concepts/workloads/pods/pod-lifecycle/), pods are created, assigned a unique ID (UID), and
+<!--
+Like individual application containers, Pods are considered to be relatively
+ephemeral (rather than durable) entities. As discussed in
+[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
 scheduled to nodes where they remain until termination (according to restart
-policy) or deletion. If a node dies, the pods scheduled to that node are
-scheduled for deletion, after a timeout period. A given pod (as defined by a UID) is not
-"rescheduled" to a new node; instead, it can be replaced by an identical pod,
+policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
+scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
+"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
 with even the same name if desired, but with a new UID (see [replication
 controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
 -->
-
-在 [Docker](https://www.docker.com/) 体系的术语中，Pod 被建模为一组具有共享命名空间和共享 [卷](/docs/concepts/storage/volumes/) 的 Docker 容器。
-
-与单个应用程序容器一样，Pod被认为是相对短暂的（而不是持久的）实体。如 [Pod 的生命](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样：Pod 被创建、给它指定一个唯一 ID （UID）、被调度到节点、在节点上存续直到终止（取决于重启策略）或被删除。如果节点宕机，调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod （由 UID 定义）不会重新调度到新节点；相反，它会被一个完全相同的 Pod 替换掉，如果需要甚至连 Pod 名称都可以一样，除了 UID 是新的(更多信息请查阅 [副本控制器（replication
-controller）](/docs/concepts/workloads/controllers/replicationcontroller/))。
+与单个应用程序容器一样，Pod 被认为是相对短暂的（而不是持久的）实体。如 [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样：Pod 被创建、给它指定一个唯一 ID （UID）、被调度到节点、在节点上存续直到终止（取决于重启策略）或被删除。如果 {{< glossary_tooltip term_id="node" >}} 宕机，调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod （由 UID 定义）不会重新调度到新节点；相反，它会被一个完全相同的 Pod 替换掉，如果需要甚至连 Pod 名称都可以一样，除了 UID 是新的(更多信息请查阅 [副本控制器（replication
+controller）](/docs/concepts/workloads/controllers/replicationcontroller/)。

 <!--
-When something is said to have the same lifetime as a pod, such as a volume,
-that means that it exists as long as that pod (with that UID) exists. If that
-pod is deleted for any reason, even if an identical replacement is created, the
+When something is said to have the same lifetime as a Pod, such as a volume,
+that means that it exists as long as that Pod (with that UID) exists. If that
+Pod is deleted for any reason, even if an identical replacement is created, the
 related thing (e.g. volume) is also destroyed and created anew.
 -->
+当某些东西被说成与 Pod（如卷）具有相同的生命周期时，这表明只要 Pod（具有该 UID）存在，它就存在。如果出于任何原因删除了该 Pod，即使创建了相同的 Pod，相关的内容（例如卷）也会被销毁并重新创建。

-当某些东西被说成与 Pod（如卷）具有相同的生存期时，这意味着只要pod（具有该UID）存在，它就存在。如果那个 Pod 因为某种原因被删除了，即使创建了相同的 Pod 做替换，Pod 的相关的资源（如卷等）也会被销毁进行重新创建。
-
-{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}

 <!--
-*A multi-container pod that contains a file puller and a
+*A multi-container Pod that contains a file puller and a
 web server that uses a persistent volume for shared storage between the containers.*
 -->

-包含多个容器的 Pod 包含文件拉取器和 web 服务器，使用了持久卷在容器之间进行存储共享。
-
-{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
-
+*一个多容器 Pod，其中包含一个文件拉取器和一个 Web 服务器，该 Web 服务器使用持久卷在容器之间共享存储*

 <!--
 ## Motivation for pods
+-->
+## 设计 Pod 的目的

+<!--
 ### Management
+-->
+### 管理

+<!--
 Pods are a model of the pattern of multiple cooperating processes which form a
 cohesive unit of service.  They simplify application deployment and management
 by providing a higher-level abstraction than the set of their constituent
 applications. Pods serve as unit of deployment, horizontal scaling, and
 replication. Colocation (co-scheduling), shared fate (e.g. termination),
 coordinated replication, resource sharing, and dependency management are
-handled automatically for containers in a pod.
+handled automatically for containers in a Pod.
 -->
-
-## Pod 的动机
-
-### 管理
-
-Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象，从而简化了应用的部署和管理。Pod 可以用作部署单元、水平缩放和复制。在 Pod中，多个容器的共同定位（协同调度）、共享命运（例如，终止）、协调复制、资源共享和依赖项管理都是自动处理的。
-
+Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象，从而简化了应用的部署和管理。Pod 可以用作部署、水平扩展和制作副本的最小单元。在 Pod 中，系统自动处理多个容器的在并置运行（协同调度）、生命期共享（例如，终止），协同复制、资源共享和依赖项管理。

 <!--
 ### Resource sharing and communication
-
-Pods enable data sharing and communication among their constituents.
-
-The applications in a pod all use the same network namespace (same IP and port
-space), and can thus "find" each other and communicate using `localhost`.
-Because of this, applications in a pod must coordinate their usage of ports.
-Each pod has an IP address in a flat shared networking space that has full
-communication with other physical computers and pods across the network.
 -->
-
 ### 资源共享和通信

+<!--
+Pods enable data sharing and communication among their constituents.
+-->
 Pod 使它的组成容器间能够进行数据共享和通信。

-Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个IP地址，该空间能与整个网络上的其他物理机或虚拟机进行完全通信。
+<!--
+The applications in a Pod all use the same network namespace (same IP and port
+space), and can thus "find" each other and communicate using `localhost`.
+Because of this, applications in a Pod must coordinate their usage of ports.
+Each Pod has an IP address in a flat shared networking space that has full
+communication with other physical computers and Pods across the network.
+-->
+Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个 IP 地址，该空间通过网络与其他物理计算机和 Pod 进行全面通信。

 <!--
-The hostname is set to the pod's Name for the application containers within the
-pod. [More details on networking](/docs/concepts/cluster-administration/networking/).
-
-In addition to defining the application containers that run in the pod, the pod
-specifies a set of shared storage volumes. Volumes enable data to survive
-container restarts and to be shared among the applications within the pod.
+Containers within the Pod see the system hostname as being the same as the configured
+`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
+section.
 -->
+Pod 中的容器获取的系统主机名与为 Pod 配置的 `name` 相同。[网络](/docs/concepts/cluster-administration/networking/) 部分提供了更多有关此内容的信息。

-主机名被设置为 Pod 内的应用程序容器的 Pod 名称。请参考[组网的更多信息](/docs/concepts/cluster-administration/networking/)。
-
+<!--
+In addition to defining the application containers that run in the Pod, the Pod
+specifies a set of shared storage volumes. Volumes enable data to survive
+container restarts and to be shared among the applications within the Pod.
+-->
 Pod 除了定义了 Pod 中运行的应用程序容器之外，Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留，并能在 Pod 内的应用程序之间共享。

 <!--
 ## Uses of pods
+-->
+## 使用 Pod

+<!--
 Pods can be used to host vertically integrated application stacks (e.g. LAMP),
 but their primary motivation is to support co-located, co-managed helper
 programs, such as:
@@ -185,10 +183,7 @@ programs, such as:
 * proxies, bridges, and adapters
 * controllers, managers, configurators, and updaters
 -->
-
-## 使用 Pod
-
-Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的动机是支持位于同一位置的、共同管理的帮助程序，例如：
+Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的目的是支持位于同一位置的、共同管理的工具程序，例如：

 * 内容管理系统、文件和数据加载器、本地缓存管理器等。
 * 日志和检查点备份、压缩、旋转、快照等。
@@ -198,24 +193,27 @@ Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最


 <!--
-Individual pods are not intended to run multiple instances of the same
+Individual Pods are not intended to run multiple instances of the same
 application, in general.
+-->
+通常，不会用单个 Pod 来运行同一应用程序的多个实例。

+<!--
 For a longer explanation, see [The Distributed System ToolKit: Patterns for
 Composite
 Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
 -->
-
-通常，单个 Pod 并不打算运行同一应用程序的多个实例。
-
-更多解释，请参考 [分布式系统工具包：复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+有关详细说明，请参考 [分布式系统工具包：组合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)。

 <!--
 ## Alternatives considered
+-->
+## 可考虑的备选方案

+<!--
 _Why not just run multiple programs in a single (Docker) container?_

-1. Transparency. Making the containers within the pod visible to the
+1. Transparency. Making the containers within the Pod visible to the
   infrastructure enables the infrastructure to provide services to those
   containers, such as process management and resource monitoring. This
   facilitates a number of conveniences for users.
@@ -227,9 +225,6 @@ _Why not just run multiple programs in a single (Docker) container?_
 1. Efficiency. Because the infrastructure takes on more responsibility,
   containers can be lighter weight.
 -->
-
-## 备选方案的思考
-
 _为什么不在单个（Docker）容器中运行多个程序？_

 1. 透明度。Pod 内的容器对基础设施可见，使得基础设施能够向这些容器提供服务，例如流程管理和资源监控。这为用户提供了许多便利。
@@ -239,36 +234,37 @@ _为什么不在单个（Docker）容器中运行多个程序？_

 <!--
 _Why not support affinity-based co-scheduling of containers?_
+-->
+_为什么不支持基于亲和性的容器协同调度？_

+<!--
 That approach would provide co-location, but would not provide most of the
-benefits of pods, such as resource sharing, IPC, guaranteed fate sharing, and
+benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
 simplified management.
 -->
-
-_为什么不支持基于亲和性的容器联合调度？_
-
 这种处理方法尽管可以提供同址，但不能提供 Pod 的大部分好处，如资源共享、IPC、有保证的命运共享和简化的管理。

 <!--
 ## Durability of pods (or lack thereof)
+-->
+## Pod 的持久性（或稀缺性）

+<!--
 Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
+-->
+不得将 Pod 视为持久实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。

-In general, users shouldn't need to create pods directly. They should almost
+<!--
+In general, users shouldn't need to create Pods directly. They should almost
 always use controllers even for singletons, for example,
 [Deployments](/docs/concepts/workloads/controllers/deployment/).
 Controllers provide self-healing with a cluster scope, as well as replication
 and rollout management.
 Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
-can also provide support to stateful pods.
+can also provide support to stateful Pods.
 -->
-
-## Pod 的持久性（或稀缺性）
-
-Pod 并没想被视为持久的实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。
-
-一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。
-控制器提供集群范围的自修复以及复制和滚动管理。
+一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的 Pod 创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。
+控制器提供集群范围的自修复以及副本数和滚动管理。
 像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。

 <!--
@@ -279,121 +275,113 @@ The use of collective APIs as the primary user-facing primitive is relatively co

 <!--
 Pod is exposed as a primitive in order to facilitate:
-d
-* scheduler and controller pluggability
-* support for pod-level operations without the need to "proxy" them via controller APIs
-* decoupling of pod lifetime from controller lifetime, such as for bootstrapping
-* decoupling of controllers and services &mdash; the endpoint controller just watches pods
-* clean composition of Kubelet-level functionality with cluster-level functionality &mdash; Kubelet is effectively the "pod controller"
-* high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
 -->
-
 Pod 暴露为原语是为了便于：

+<!--
+* scheduler and controller pluggability
+* support for pod-level operations without the need to "proxy" them via controller APIs
+* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
+* decoupling of controllers and services &mdash; the endpoint controller just watches Pods
+* clean composition of Kubelet-level functionality with cluster-level functionality &mdash; Kubelet is effectively the "pod controller"
+* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
+-->
 * 调度器和控制器可插拔性
 * 支持 Pod 级别的操作，而不需要通过控制器 API "代理" 它们
 * Pod 生命与控制器生命的解耦，如自举
-* 控制器和服务的解耦；端点控制器只监视 Pod
-* Kubelet 级别的功能与集群级别功能的清晰组合；Kubelet 实际上是 "Pod 控制器"
-* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod，例如在计划驱逐或镜像预先提取的情况下。
+* 控制器和服务的解耦 &mdash; 端点控制器只监视 Pod
+* kubelet 级别的功能与集群级别功能的清晰组合 &mdash; kubelet 实际上是 "Pod 控制器"
+* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod，例如在计划驱逐或镜像预先拉取的情况下。

 <!--
 ## Termination of Pods
-
-Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod, the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
 -->
-
 ## Pod 的终止

+<!--
+Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
+-->
 因为 Pod 代表在集群中的节点上运行的进程，所以当不再需要这些进程时（与被 KILL 信号粗暴地杀死并且没有机会清理相比），允许这些进程优雅地终止是非常重要的。
 用户应该能够请求删除并且知道进程何时终止，但是也能够确保删除最终完成。当用户请求删除 Pod 时，系统会记录在允许强制删除 Pod 之前所期望的宽限期，并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期，KILL 信号就发送到这些进程，然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启，则终止操作将以完整的宽限期进行重试。


 <!--
 An example flow:
+-->
+流程示例：

+<!--
 1. User sends command to delete Pod, with default grace period (30s)
 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
 1. Pod shows up as "Terminating" when listed in client commands
-1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the pod shutdown process.
-    1. If the pod has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
-    1. The processes in the Pod are sent the TERM signal.
-1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
+1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
+    1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
+    1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
+1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
 1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
 1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
 -->
-
-流程示例：
-
 1. 用户发送命令删除 Pod，使用的是默认的宽限期（30秒）
-2. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 "死亡"。
-3. 当使用客户端命令查询 Pod 状态时，Pod 显示为 "Terminating"。
-4. （和第3步同步进行）当 Kubelet 看到 Pod 由于步骤2中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。
-    1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，就在 Pod 内部调用它。如果宽限期结束了 `preStop` 钩子还在运行，那么就用小的（2秒）扩展宽限期调用步骤2。
-
-    2. 给 Pod 内的进程发送 TERM 信号。
-5. （和第3步同步进行）从服务的端点列表中删除 Pod，Pod也不再被视为副本控制器的运行状态的 Pod 集的一部分。当负载平衡器（如服务代理）将 Pod 从轮换中移除时，关闭迟缓的 Pod 将不能继续为流量服务。
-6. 当宽限期结束后，Pod 中运行的任何进程都将被用 SIGKILL 杀死。
-7. Kubelet 将通过设置宽限期为0（立即删除）来完成删除 API 服务器上的 Pod。Pod 从 API 中消失，从客户端也不再可见。
+1. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 "死亡"。
+1. 当使用客户端命令查询 Pod 状态时，Pod 显示为 "Terminating"。
+1. （和第 3 步同步进行）当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。
+    1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，就在 Pod 内部调用它。如果宽限期结束了，但是 `preStop` 钩子还在运行，那么就用小的（2 秒）扩展宽限期调用步骤 2。
+    1. 给 Pod 内的进程发送 TERM 信号。请注意，并不是所有 Pod 中的容器都会同时收到 TERM 信号，如果它们关闭的顺序很重要，则每个容器可能都需要一个 `preStop` 钩子。
+1. （和第 3 步同步进行）从服务的端点列表中删除 Pod，Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器（如服务代理）会将其从轮换中删除，所以缓慢关闭的 Pod 无法继续为流量提供服务。
+1. 当宽限期到期时，仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。
+1. kubelet 将通过设置宽限期为 0 （立即删除）来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失，并且在客户端中不再可见。


 <!--
-By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=<seconds>` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the pod. In kubectl version >= 1.5, you must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=<seconds>` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
+You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
 -->
-
-默认情况下，所有删除在30秒内都是优雅的。`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 ‘0’ 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。在 kubectl 1.5以后的版本（含1.5版本）中，为了执行强制删除，您还必须为 `--grace-period=0` 声明一个额外的 `--force` 标志。
+默认情况下，所有删除操作宽限期是 30 秒。`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 `0` 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。您必须指定一个附加标志 `--force` 和 `--grace-period=0` 才能执行强制删除操作。

 <!--
 ### Force deletion of pods
-
-Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-
-Force deletions can be potentially dangerous for some pods and should be performed with caution. In case of StatefulSet pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
 -->
-
 ### Pod 的强制删除

-强制删除pod定义为从集群状态和 etcd 中立即删除 Pod。当执行强制删除时，apiserver 并不会等待 kubelet 的确认信息，该 Pod 已在所运行的节点上被终止了。强制删除操作从 API 中立即清除了 Pod， 因此可以用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。
+<!--
+Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
+-->
+强制删除 Pod 被定义为从集群状态与 etcd 中立即删除 Pod。当执行强制删除时，API 服务器并不会等待 kubelet 的确认信息，该 Pod 已在所运行的节点上被终止了。强制执行删除操作会从 API 服务器中立即清除 Pod， 因此可以用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。

-强制删除对某些 Pod 可能具有潜在危险，因此应该谨慎地执行。对于 StatefulSet 管理的 Pod，请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/)的任务文档。
+<!--
+Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+-->
+强制删除对某些 Pod 可能具有潜在危险，因此应该谨慎地执行。对于 StatefulSet 管理的 Pod，请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/) 的任务文档。

 <!--
 ## Privileged mode for pod containers
-
-From Kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.
-
-If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
-If user calls `kubectl describe pod FooPodName`, user can see the reason why the pod is in pending state. The events table in the describe command output will say:
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
 -->
-
 ## Pod 容器的特权模式

-从 Kubernetes v1.1 开始，Pod 内的任何容器都可以开启特权模式，开启的方法是在容器声明中的  `SecurityContext` 域使用  `privileged` 标志。这对于希望使用linux功能（如操作网络堆栈和访问设备）的容器非常有用。容器内的进程获得的特权与容器外的进程几乎相同。使用特权模式，将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。
-
-如果主节点的 Kubernetes 版本是 v1.1 或更高，而工作节点的版本低于 v1.1，新的特权 Pod 将被 API 服务器接受，但不会被启动。它们将处于 pending 状态。如果用户使用命令 `kubectl describe pod FooPodName`，就可以看到 Pod 处于 pending 状态的原因。`describe` 命令的输出事件列表将显示：
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
+<!--
+Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
+-->
+Pod 中的任何容器都可以使用容器规范 [security context](/docs/tasks/configure-pod-container/security-context/) 上的 `privileged` 参数启用特权模式。这对于想要使用 Linux 功能（如操纵网络堆栈和访问设备）的容器很有用。容器内的进程几乎可以获得与容器外的进程相同的特权。使用特权模式，将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。

 <!--
-If the master is running a version lower than v1.1, then privileged pods cannot be created. If user attempts to create a pod, that has a privileged container, the user will get the following error:
-`The Pod "FooPodName" is invalid.
-spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
+Your container runtime must support the concept of a privileged container for this setting to be relevant.
 -->

-如果主节点的版本低于 v1.1，那么特权 Pod 就不能被创建。如果用户尝试创建有特权容器的 Pod，将会得到下面的错误信息：
-`The Pod "FooPodName" is invalid.
-spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
+{{< note >}}
+您的容器运行时必须支持特权容器模式才能使用此设置。
+{{< /note >}}

 <!--
 ## API Object
-
-Pod is a top-level resource in the Kubernetes REST API. More details about the
-API object can be found at:
-[Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-
-{{% /capture %}}
 -->
-
 ## API 对象

-Pod 是 Kubernetes REST API 中的顶级资源。关于该 API 对象的更详细信息请参考 [Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
+<!--
+Pod is a top-level resource in the Kubernetes REST API.
+The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
+describes the object in detail.
+-->
+Pod 是 Kubernetes REST API 中的顶级资源。
+[Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)定义详细描述了该 Pod 对象。
+
+{{% /capture %}}
@@ -1,17 +1,25 @@
 ---
+title: Pod Preset
+content_template: templates/concept
+weight: 50
+---
+
+<!--
+---
 reviewers:
 - jessfraz
 title: Pod Preset
 content_template: templates/concept
 weight: 50
 ---
+-->

-{{% capture overview %}}
 <!--
 This page provides an overview of PodPresets, which are objects for injecting
 certain information into pods at creation time. The information can include
 secrets, volumes, volume mounts, and environment variables.
 -->
+{{% capture overview %}}
 本文提供了 PodPreset 的概述。 在 Pod 创建时，用户可以使用 PodPreset 对象将特定信息注入 Pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。
 {{% /capture %}}

@@ -20,15 +28,15 @@ secrets, volumes, volume mounts, and environment variables.

 <!--
 ## Understanding Pod Presets
+-->
+## 理解 Pod Preset

+<!--
 A `Pod Preset` is an API resource for injecting additional runtime requirements
 into a Pod at creation time.
 You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
 to specify the Pods to which a given Pod Preset applies.
 -->
-
-## 理解 Pod Preset
-
 `Pod Preset` 是一种 API 资源，在 Pod 创建时，用户可以用它将额外的运行时需求信息注入 Pod。
 使用[标签选择器（label selector）](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 Pod。

@@ -94,50 +102,65 @@ the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
 修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod
 中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。

-
+<!--
+A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
+- The `.spec.containers` field.
+- The `initContainers` field (requires Kubernetes version 1.14.0 or later).
+-->
 {{< note >}}
-<!--A Pod Preset is capable of modifying the `.spec.containers` field in a
-Pod spec when appropriate. *No* resource definition from the Pod Preset will be
-applied to the `initContainers` field.-->
-
-Pod Preset 能够在适当的时候修改 Pod spec 的 `spec.containers` 字段，但是不会应用于 `initContainers` 字段。
+适当时候，Pod Preset 可以修改 Pod 规范中的以下字段：
+- `.spec.containers` 字段
+- `initContainers` 字段 (需要 Kubernetes 1.14.0 或更高版本)。
 {{< /note >}}

 <!--
 ### Disable Pod Preset for a Specific Pod
+-->
+### 为特定 Pod 禁用 Pod Preset

+<!--
 There may be instances where you wish for a Pod to not be altered by any Pod
 Preset mutations. In these cases, you can add an annotation in the Pod Spec
 of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
 -->
-
-### 为特定 Pod 禁用 Pod Preset
-
 在一些情况下，用户不希望 Pod 被 Pod Preset 所改动，这时，用户可以在 Pod spec 中添加形如 `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。

 <!--
 ## Enable Pod Preset
-
-In order to use Pod Presets in your cluster you must ensure the following:
 -->
-
 ## 启用 Pod Preset

+<!--
+In order to use Pod Presets in your cluster you must ensure the following:
+-->
 为了在集群中使用 Pod Preset，必须确保以下几点：

 <!--
 1.  You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
    example, this can be done by including `settings.k8s.io/v1alpha1=true` in
-    the `--runtime-config` option for the API server.
+    the `--runtime-config` option for the API server. In minikube add this flag
+    `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
+    starting the cluster.
 1.  You have enabled the admission controller `PodPreset`. One way to doing this
    is to include `PodPreset` in the `--enable-admission-plugins` option value specified
-    for the API server.
+    for the API server. In minikube add this flag
+    
+    ```shell
+    --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+    ```
+    
+    while starting the cluster.
 1.  You have defined your Pod Presets by creating `PodPreset` objects in the
    namespace you will use.
 -->

-1.  已启用 API 类型 `settings.k8s.io/v1alpha1/podpreset`。 这可以通过在 API 服务器的 `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。
-1.  已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--admission-control` 配置项中包含 `PodPreset` 。
+1.  已启用 API 类型 `settings.k8s.io/v1alpha1/podpreset`。 例如，这可以通过在 API 服务器的 `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。在 minikube 部署的集群中，启动集群时添加此参数 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`。
+1.  已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--enable-admission-plugins` 配置项中包含 `PodPreset` 。在 minikube 部署的集群中，启动集群时添加以下参数：
+
+    ```shell
+    --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+    ```
+
 1.  已经通过在相应的命名空间中创建 `PodPreset` 对象，定义了 Pod Preset。


@@ -148,4 +171,5 @@ In order to use Pod Presets in your cluster you must ensure the following:
 * [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
 -->
 * [使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset/)
+
 {{% /capture %}}