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 commit2c4545e105. * 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 commit5dbfaafe1a. * 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>
This commit is contained in:
Vineeth Pothulapati
committed by
GitHub
GitHub
parent
fb1c0e8b77
commit
63f30b086a
@@ -0,0 +1,272 @@
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Kubernetes on MIPS"
|
||||
date: 2020-01-15
|
||||
slug: Kubernetes-on-MIPS
|
||||
-->
|
||||
---
|
||||
layout: blog
|
||||
title: "基于 MIPS 架构的 Kubernetes 方案"
|
||||
date: 2020-01-15
|
||||
slug: Kubernetes-on-MIPS
|
||||
---
|
||||
|
||||
<!--
|
||||
**Authors:** TimYin Shi, Dominic Yin, Wang Zhan, Jessica Jiang, Will Cai, Jeffrey Gao, Simon Sun (Inspur)
|
||||
-->
|
||||
**作者:** 石光银，尹东超，展望，江燕，蔡卫卫，高传集，孙思清（浪潮）
|
||||
|
||||
<!--
|
||||
## Background
|
||||
-->
|
||||
## 背景
|
||||
|
||||
<!--
|
||||
[MIPS](https://en.wikipedia.org/wiki/MIPS_architecture) (Microprocessor without Interlocked Pipelined Stages) is a reduced instruction set computer (RISC) instruction set architecture (ISA), appeared in 1981 and developed by MIPS Technologies. Now MIPS architecture is widely used in many electronic products.
|
||||
-->
|
||||
[MIPS](https://zh.wikipedia.org/wiki/MIPS%E6%9E%B6%E6%A7%8B) (Microprocessor without Interlocked Pipelined Stages) 是一种采取精简指令集（RISC）的处理器架构 (ISA)，出现于 1981 年，由 MIPS 科技公司开发。如今 MIPS 架构被广泛应用于许多电子产品上。
|
||||
|
||||
<!--
|
||||
[Kubernetes](https://kubernetes.io) has officially supported a variety of CPU architectures such as x86, arm/arm64, ppc64le, s390x. However, it's a pity that Kubernetes doesn't support MIPS. With the widespread use of cloud native technology, users under MIPS architecture also have an urgent demand for Kubernetes on MIPS.
|
||||
-->
|
||||
[Kubernetes](https://kubernetes.io) 官方目前支持众多 CPU 架构诸如 x86, arm/arm64, ppc64le, s390x 等。然而目前还不支持 MIPS 架构，始终是一个遗憾。随着云原生技术的广泛应用，MIPS 架构下的用户始终对 Kubernetes on MIPS 有着迫切的需求。
|
||||
|
||||
<!--
|
||||
## Achievements
|
||||
-->
|
||||
|
||||
## 成果
|
||||
|
||||
<!--
|
||||
For many years, to enrich the ecology of the open-source community, we have been working on adjusting MIPS architecture for Kubernetes use cases. With the continuous iterative optimization and the performance improvement of the MIPS CPU, we have made some breakthrough progresses on the mips64el platform.
|
||||
-->
|
||||
多年来，为了丰富开源社区的生态，我们一直致力于在 MIPS 架构下适配 Kubernetes。随着 MIPS CPU 的不断迭代优化和性能的提升，我们在 mips64el 平台上取得了一些突破性的进展。
|
||||
|
||||
<!--
|
||||
Over the years, we have been actively participating in the Kubernetes community and have rich experience in the using and optimization of Kubernetes technology. Recently, we tried to adapt the MIPS architecture platform for Kubernetes and achieved a new a stage on that journey. The team has completed migration and adaptation of Kubernetes and related components, built not only a stable and highly available MIPS cluster but also completed the conformance test for Kubernetes v1.16.2.
|
||||
-->
|
||||
多年来，我们一直积极投入 Kubernetes 社区，在 Kubernetes 技术应用和优化方面具备了丰富的经验。最近，我们在研发过程中尝试将 Kubernetes 适配到 MIPS 架构平台，并取得了阶段性成果。成功完成了 Kubernetes 以及相关组件的迁移适配，不仅搭建出稳定高可用的 MIPS 集群，同时完成了 Kubernetes v1.16.2 版本的一致性测试。
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
_Figure 1 Kubernetes on MIPS_
|
||||
-->
|
||||
_图一 Kubernetes on MIPS_
|
||||
|
||||
<!--
|
||||
## K8S-MIPS component build
|
||||
-->
|
||||
## K8S-MIPS 组件构建
|
||||
|
||||
<!--
|
||||
Almost all native cloud components related to Kubernetes do not provide a MIPS version installation package or image. The prerequisite of deploying Kubernetes on the MIPS platform is to compile and build all required components on the mips64el platform. These components include:
|
||||
-->
|
||||
几乎所有的 Kubernetes 相关的云原生组件都没有提供 MIPS 版本的安装包或镜像，在 MIPS 平台上部署 Kubernetes 的前提是自行编译构建出全部所需组件。这些组件主要包括：
|
||||
|
||||
- golang
|
||||
- docker-ce
|
||||
- hyperkube
|
||||
- pause
|
||||
- etcd
|
||||
- calico
|
||||
- coredns
|
||||
- metrics-server
|
||||
|
||||
<!--
|
||||
Thanks to the excellent design of Golang and its good support for the MIPS platform, the compilation processes of the above cloud native components are greatly simplified. First of all, we compiled Golang on the latest stable version for the mips64el platform, and then we compiled most of the above components with source code.
|
||||
-->
|
||||
得益于 Golang 优秀的设计以及对于 MIPS 平台的良好支持，极大地简化了上述云原生组件的编译过程。首先，我们在 mips64el 平台编译出了最新稳定的 golang, 然后通过源码构建的方式编译完成了上述大部分组件。
|
||||
|
||||
<!--
|
||||
During the compilation processes, we inevitably encountered many platform compatibility problems, such as a Golang system call compatibility problem (syscall), typecasting of syscall. Stat_t from uint32 to uint64, patching for EpollEvent, and so on.
|
||||
-->
|
||||
在编译过程中，我们不可避免地遇到了很多平台兼容性的问题，比如关于 golang 系统调用 (syscall) 的兼容性问题, syscall.Stat_t 32 位 与 64 位类型转换，EpollEvent 修正位缺失等等。
|
||||
|
||||
<!--
|
||||
To build K8S-MIPS components, we used cross-compilation technology. Our process involved integrating a QEMU tool to translate MIPS CPU instructions and modifying the build script of Kubernetes and E2E image script of Kubernetes, Hyperkube, and E2E test images on MIPS architecture.
|
||||
-->
|
||||
构建 K8S-MIPS 组件主要使用了交叉编译技术。构建过程包括集成 QEMU 工具来实现 MIPS CPU 指令的转换。同时修改 Kubernetes 和 E2E 镜像的构建脚本，构建了 Hyperkube 和 MIPS 架构的 E2E 测试镜像。
|
||||
|
||||
<!--
|
||||
After successfully building the above components, we use tools such as kubespray and kubeadm to complete kubernetes cluster construction.
|
||||
-->
|
||||
成功构建出以上组件后，我们使用工具完成 Kubernetes 集群的搭建，比如 kubespray、kubeadm 等。
|
||||
|
||||
<!--
|
||||
| Name | Version | MIPS Repository |
|
||||
|--------------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| golang on MIPS | 1.12.5 | - |
|
||||
| docker-ce on MIPS | 18.09.8 | - |
|
||||
| metrics-server for CKE on MIPS | 0.3.2 | `registry.inspurcloud.cn/library/cke/kubernetes/metrics-server-mips64el:v0.3.2` |
|
||||
| etcd for CKE on MIPS | 3.2.26 | `registry.inspurcloud.cn/library/cke/etcd/etcd-mips64el:v3.2.26` |
|
||||
| pause for CKE on MIPS | 3.1 | `registry.inspurcloud.cn/library/cke/kubernetes/pause-mips64el:3.1` |
|
||||
| hyperkube for CKE on MIPS | 1.14.3 | `registry.inspurcloud.cn/library/cke/kubernetes/hyperkube-mips64el:v1.14.3` |
|
||||
| coredns for CKE on MIPS | 1.6.5 | `registry.inspurcloud.cn/library/cke/kubernetes/coredns-mips64el:v1.6.5` |
|
||||
| calico for CKE on MIPS | 3.8.0 | `registry.inspurcloud.cn/library/cke/calico/cni-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/ctl-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/node-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/kube-controllers-mips64el:v3.8.0` |
|
||||
-->
|
||||
|
||||
| 名称 | 版本 | MIPS 镜像仓库 |
|
||||
|-----------------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| MIPS 版本 golang | 1.12.5 | - |
|
||||
| MIPS 版本 docker-ce | 18.09.8 | - |
|
||||
| MIPS 版本 CKE 构建 metrics-server | 0.3.2 | `registry.inspurcloud.cn/library/cke/kubernetes/metrics-server-mips64el:v0.3.2` |
|
||||
| MIPS 版本 CKE 构建 etcd | 3.2.26 | `registry.inspurcloud.cn/library/cke/etcd/etcd-mips64el:v3.2.26` |
|
||||
| MIPS 版本 CKE 构建 pause | 3.1 | `registry.inspurcloud.cn/library/cke/kubernetes/pause-mips64el:3.1` |
|
||||
| MIPS 版本 CKE 构建 hyperkube | 1.14.3 | `registry.inspurcloud.cn/library/cke/kubernetes/hyperkube-mips64el:v1.14.3` |
|
||||
| MIPS 版本 CKE 构建 coredns | 1.6.5 | `registry.inspurcloud.cn/library/cke/kubernetes/coredns-mips64el:v1.6.5` |
|
||||
| MIPS 版本 CKE 构建 calico | 3.8.0 | `registry.inspurcloud.cn/library/cke/calico/cni-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/ctl-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/node-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/kube-controllers-mips64el:v3.8.0` |
|
||||
|
||||
<!--
|
||||
**Note**: CKE is a Kubernetes-based cloud container engine launched by Inspur
|
||||
-->
|
||||
**注**: CKE 是浪潮推出的一款基于 Kubernetes 的容器云服务引擎
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
_Figure 2 K8S-MIPS Cluster Components_
|
||||
-->
|
||||
_图二 K8S-MIPS 集群组件_
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
_Figure 3 CPU Architecture_
|
||||
-->
|
||||
_图三 CPU 架构_
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
_Figure 4 Cluster Node Information_
|
||||
-->
|
||||
_图四 集群节点信息_
|
||||
|
||||
<!--
|
||||
## Run K8S Conformance Test
|
||||
-->
|
||||
## 运行 K8S 一致性测试
|
||||
|
||||
<!--
|
||||
The most straightforward way to verify the stability and availability of the K8S-MIPS cluster is to run a Kubernetes [conformance test](https://github.com/kubernetes/kubernetes/blob/v1.16.2/cluster/images/conformance/README.md).
|
||||
-->
|
||||
验证 K8S-MIP 集群稳定性和可用性最简单直接的方式是运行 Kubernetes 的 [一致性测试](https://github.com/kubernetes/kubernetes/blob/v1.16.2/cluster/images/conformance/README.md)。
|
||||
|
||||
<!--
|
||||
Conformance is a standalone container to launch Kubernetes end-to-end tests for conformance testing.
|
||||
-->
|
||||
一致性测试是一个独立的容器，用于启动 Kubernetes 端到端的一致性测试。
|
||||
|
||||
<!--
|
||||
Once the test has started, it launches several pods for various end-to-end tests. The source code of those images used by these pods is mostly from `kubernetes/test/images`, and the built images are at `gcr.io/kubernetes-e2e-test-images`. Since there are no MIPS images in the repository, we must first build all needed images to run the test.
|
||||
-->
|
||||
当执行一致性测试时，测试程序会启动许多 Pod 进行各种端到端的行为测试，这些 Pod 使用的镜像源码大部分来自于 `kubernetes/test/images` 目录下，构建的镜像位于 `gcr.io/kubernetes-e2e-test-images/`。由于镜像仓库中目前并不存在 MIPS 架构的镜像，我们要想运行 E2E 测试，必须首先构建出测试所需的全部镜像。
|
||||
|
||||
<!--
|
||||
### Build needed images for test
|
||||
-->
|
||||
### 构建测试所需镜像
|
||||
|
||||
<!--
|
||||
The first step is to find all needed images for the test. We can run `sonobuoy images-p e2e` command to list all images, or we can find those images in [/test/utils/image/manifest.go](https://github.com/kubernetes/kubernetes/blob/master/test/utils/image/manifest.go). Although Kubernetes officially has a complete Makefile and shell-script that provides commands for building test images, there are still a number of architecture-related issues that have not been resolved, such as the incompatibilities of base images and dependencies. So we cannot directly build mips64el architecture images by executing these commands.
|
||||
-->
|
||||
第一步是找到测试所需的所有镜像。我们可以执行 `sonobuoy images-p e2e` 命令来列出所有镜像，或者我们可以在 [/test/utils/image/manifest.go](https://github.com/kubernetes/kubernetes/blob/master/test/utils/image/manifest.go) 中找到这些镜像。尽管 Kubernetes 官方提供了完整的 Makefile 和 shell 脚本，为构建测试映像提供了命令，但是仍然有许多与体系结构相关的问题未能解决，比如基础映像和依赖包的不兼容问题。因此，我们无法通过直接执行这些构建命令来制作 mips64el 架构镜像。
|
||||
|
||||
<!--
|
||||
Most test images are in golang, then compiled into binaries and built as Docker image based on the corresponding Dockerfile. These images are easy to build. But note that most images are using alpine as their base image, which does not officially support mips64el architecture for now. For this moment, we are unable to make mips64el version of [alpine](https://www.alpinelinux.org/), so we have to replace the alpine to existing MIPS images, such as Debian-stretch, fedora, ubuntu. Replacing the base image also requires replacing the command to install the dependencies, even the version of these dependencies.
|
||||
-->
|
||||
多数测试镜像都是使用 golang 编写，然后编译出二进制文件，并基于相应的 Dockerfile 制作出镜像。这些镜像对我们来说可以轻松地制作出来。但是需要注意一点：测试镜像默认使用的基础镜像大多是 alpine, 目前 [Alpine](https://www.alpinelinux.org/) 官方并不支持 mips64el 架构，我们暂时未能自己制作出 mips64el 版本的 alpine 础镜像，只能将基础镜像替换为我们目前已有的 mips64el 基础镜像，比如 debian-stretch,fedora, ubuntu 等。替换基础镜像的同时也需要替换安装依赖包的命令，甚至依赖包的版本等。
|
||||
|
||||
<!--
|
||||
Some images are not in `kubernetes/test/images`, such as `gcr.io/google-samples/gb-frontend:v6`. There is no clear documentation explaining where these images are locaated, though we found the source code in repository [github.com/GoogleCloudPlatform/kubernetes-engine-samples](https://github.com/GoogleCloudPlatform/kubernetes-engine-samples). We soon ran into new problems: to build these google sample images, we have to build the base image it uses, even the base image of the base images, such as `php:5-apache`, `redis`, and `perl`.
|
||||
-->
|
||||
有些测试所需镜像的源码并不在 `kubernetes/test/images` 下,比如 `gcr.io/google-samples/gb-frontend:v6` 等，没有明确的文档说明这类镜像来自于何方，最终还是在 [github.com/GoogleCloudPlatform/kubernetes-engine-samples](github.com/GoogleCloudPlatform/kubernetes-engine-samples) 这个仓库找到了原始的镜像源代码。但是很快我们遇到了新的问题，为了制作这些镜像，还要制作它依赖的基础镜像，甚至基础镜像的基础镜像，比如 `php:5-apache`、`redis`、`perl` 等等。
|
||||
|
||||
<!--
|
||||
After a long process of building an image, we finished with about four dozen images, including the images used by the test pod, and the base images. The last step before we run the tests is to place all those images into every node in the cluster and make sure the Pod image pull policy is `imagePullPolicy: ifNotPresent`.
|
||||
-->
|
||||
经过漫长庞杂的的镜像重制工作，我们完成了总计约 40 个镜像的制作 ，包括测试镜像以及直接和间接依赖的基础镜像。
|
||||
最终我们将所有镜像在集群内准备妥当，并确保测试用例内所有 Pod 的镜像拉取策略设置为 `imagePullPolicy: ifNotPresent`。
|
||||
|
||||
<!--
|
||||
Here are some of the images we built
|
||||
-->
|
||||
这是我们构建出的部分镜像列表：
|
||||
|
||||
- `docker.io/library/busybox:1.29`
|
||||
- `docker.io/library/nginx:1.14-alpine`
|
||||
- `docker.io/library/nginx:1.15-alpine`
|
||||
- `docker.io/library/perl:5.26`
|
||||
- `docker.io/library/httpd:2.4.38-alpine`
|
||||
- `docker.io/library/redis:5.0.5-alpine`
|
||||
- `gcr.io/google-containers/conformance:v1.16.2`
|
||||
- `gcr.io/google-containers/hyperkube:v1.16.2`
|
||||
- `gcr.io/google-samples/gb-frontend:v6`
|
||||
- `gcr.io/kubernetes-e2e-test-images/agnhost:2.6`
|
||||
- `gcr.io/kubernetes-e2e-test-images/apparmor-loader:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/dnsutils:1.1`
|
||||
- `gcr.io/kubernetes-e2e-test-images/echoserver:2.2`
|
||||
- `gcr.io/kubernetes-e2e-test-images/ipc-utils:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/jessie-dnsutils:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/kitten:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/metadata-concealment:1.2`
|
||||
- `gcr.io/kubernetes-e2e-test-images/mounttest-user:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/mounttest:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/nautilus:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/nonewprivs:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/nonroot:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/resource-consumer-controller:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/resource-consumer:1.5`
|
||||
- `gcr.io/kubernetes-e2e-test-images/sample-apiserver:1.10`
|
||||
- `gcr.io/kubernetes-e2e-test-images/test-webserver:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/volume/gluster:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/volume/iscsi:2.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/volume/nfs:1.0`
|
||||
- `gcr.io/kubernetes-e2e-test-images/volume/rbd:1.0.1`
|
||||
- `k8s.gcr.io/etcd:3.3.15`
|
||||
- `k8s.gcr.io/pause:3.1`
|
||||
|
||||
<!--
|
||||
Finally, we ran the tests and got the test result, include `e2e.log`, which showed that all test cases passed. Additionally, we submitted our test result to [k8s-conformance](https://github.com/cncf/k8s-conformance) as a [pull request](https://github.com/cncf/k8s-conformance/pull/779).
|
||||
-->
|
||||
最终我们执行一致性测试并且得到了测试报告，包括 `e2e.log`，显示我们通过了全部的测试用例。此外，我们将测试结果以 [pull request](https://github.com/cncf/k8s-conformance/pull/779) 的形式提交给了 [k8s-conformance](https://github.com/cncf/k8s-conformance) 。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
_Figure 5 Pull request for conformance test results_
|
||||
-->
|
||||
_图五 一致性测试结果的 PR_
|
||||
|
||||
<!--
|
||||
## What's next
|
||||
-->
|
||||
## 后续计划
|
||||
|
||||
<!--
|
||||
We built the kubernetes-MIPS component manually and finished the conformance test, which verified the feasibility of Kubernetes On the MIPS platform and greatly enhanced our confidence in promoting the support of the MIPS architecture by Kubernetes.
|
||||
-->
|
||||
我们手动构建了 K8S-MIPS 组件以及执行了 E2E 测试，验证了 Kubernetes on MIPS 的可行性，极大的增强了我们对于推进 Kubernetes 支持 MIPS 架构的信心。
|
||||
|
||||
<!--
|
||||
In the future, we plan to actively contribute our experience and achievements to the community, submit PR, and patch for MIPS. We hope that more developers and companies in the community join us and promote Kubernetes on MIPS.
|
||||
-->
|
||||
后续，我们将积极地向社区贡献我们的工作经验以及成果，提交 PR 以及 Patch For MIPS 等， 希望能够有更多的来自社区的力量加入进来，共同推进 Kubernetes for MIPS 的进程。
|
||||
|
||||
<!--
|
||||
Contribution plan：
|
||||
-->
|
||||
后续开源贡献计划：
|
||||
|
||||
<!--
|
||||
- contribute the source of e2e test images for MIPS
|
||||
- contribute the source of hyperkube for MIPS
|
||||
- contribute the source of deploy tools like kubeadm for MIPS
|
||||
-->
|
||||
- 贡献构建 E2E 测试镜像代码
|
||||
- 贡献构建 MIPS 版本 hyperkube 代码
|
||||
- 贡献构建 MIPS 版本 kubeadm 等集群部署工具
|
||||
|
||||
---
|
||||
@@ -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 提供监控和管理日志的能力。
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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 — 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 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 — 在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。
|
||||
|
||||
<!--
|
||||
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 — the endpoint controller just watches pods
|
||||
* clean composition of Kubelet-level functionality with cluster-level functionality — 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 — the endpoint controller just watches Pods
|
||||
* clean composition of Kubelet-level functionality with cluster-level functionality — 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，例如在计划驱逐或镜像预先提取的情况下。
|
||||
* 控制器和服务的解耦 — 端点控制器只监视 Pod
|
||||
* kubelet 级别的功能与集群级别功能的清晰组合 — 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 %}}
|
||||
|
||||
@@ -170,4 +170,22 @@ documentation, but it should help you get started.
|
||||
- 对文档测试提出改进建议
|
||||
- 对 Kubernetes 网站或其他工具提出改进建议
|
||||
|
||||
<!--
|
||||
## Additional ways to contribute
|
||||
-->
|
||||
|
||||
## 其他贡献途径
|
||||
|
||||
<!--
|
||||
- To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/).
|
||||
-->
|
||||
|
||||
- 如果您要通过 Twitter 或 Stack Overflow 等在线论坛为社区做贡献，或了解本地会议及 Kubernetes 事件，请查看 [Kubernetes 社区网站](/community/).
|
||||
|
||||
<!--
|
||||
- To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started.
|
||||
-->
|
||||
|
||||
- 如果您要开发新的特性，请阅读 [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -1405,8 +1405,8 @@ or in `#sig-docs` on Slack if you are interested in helping out.
|
||||
Kubernetes 文档首先是用英语编写的，但是我们希望人们能够使用他们选择的语言来阅读它。
|
||||
如果您愿意用另一种语言编写，尤其是在软件领域，则可以帮助本地化 Kubernetes 文档
|
||||
或提供有关现有本地化内容的反馈。
|
||||
请参阅[本地化](/docs/contribute/localization/)，
|
||||
并在 [kubernetes-sig-docs 邮件列表][kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) #sig-docs 上询问，或者在 Slack 上询问是否有帮助的兴趣。
|
||||
如果您有兴趣提供帮助，请参阅 [本地化](/docs/contribute/localization/)，
|
||||
并在 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 或者 Slack 的 `#sig-docs` 群组内咨询。
|
||||
|
||||
<!--
|
||||
### Working with localized content
|
||||
|
||||
@@ -38,7 +38,7 @@ template to use for a new topic, start with the
|
||||
[concept template](#concept-template).
|
||||
-->
|
||||
|
||||
每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板，请从[概念模板](#concept-template)开始。
|
||||
每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板，请从[概念模板](#概念模板)开始。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
@@ -16,7 +16,6 @@ weight: 20
|
||||
<!--
|
||||
This page shows how to create a new topic for the Kubernetes docs.
|
||||
-->
|
||||
|
||||
本页面展示如何为 Kubernetes 文档库创建新主题。
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -26,7 +25,7 @@ Create a fork of the Kubernetes documentation repository as described in
|
||||
[Start contributing](/docs/contribute/start/).
|
||||
-->
|
||||
|
||||
创建 Kubernetes 文档仓库的一个分支，如[开始贡献](/docs/contribute/start/)中所述。
|
||||
如[开始贡献](/docs/contribute/start/)中所述，创建 Kubernetes 文档库的分支。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
@@ -44,44 +43,22 @@ As you prepare to write a new topic, think about the page type that would fit yo
|
||||
当你准备写一个新的主题时，考虑一下最适合你的内容的页面类型：
|
||||
|
||||
<!--
|
||||
<table>
|
||||
|
||||
<tr>
|
||||
<td>Concept</td>
|
||||
<td>A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Task</td>
|
||||
<td>A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Tutorial</td>
|
||||
<td>A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
Guidelines for choosing a page type
|
||||
Type | Description
|
||||
:--- | :----------
|
||||
Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.
|
||||
Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a>
|
||||
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
|
||||
-->
|
||||
|
||||
<table>
|
||||
|
||||
<tr>
|
||||
<td>概念</td>
|
||||
<td>每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。一个概念主题的示例，请参见 <a href="/docs/concepts/architecture/nodes/">节点</a>.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>任务</td>
|
||||
<td>任务页面展示了如何完成单个任务。这样做的目的是给读者一系列步骤，让他们在阅读时能够真正做到这一点。任务页面可长可短，前提是它始终聚焦在一个区域。在任务页面中，可以将简短的解释与要执行的步骤混合在一起，但如果需要提供冗长的解释，则应在概念主题中进行。相关联的任务和概念主题可以相互链接。一个简短的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">配置一个使用卷进行存储的 Pod</a>. 一个较长的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活动性和就绪性探测器</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>教程</td>
|
||||
<td>教程页面展示了如何实现将几个 Kubernetes 特性联系在一起的目标。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的演练。教程可以包括对 Kubernetes 几个关联特性的简要解释，但应该链接到相关概念主题，以便深入解释各个特性。</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
{{< table caption = "选择页面类型的准则" >}}
|
||||
类型 | 描述
|
||||
:--- | :----------
|
||||
概念 | 每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。一个概念主题的示例，请参见 <a href="/docs/concepts/architecture/nodes/">节点</a>。
|
||||
任务 | 任务页面展示了如何完成单个任务。这样做的目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">配置一个使用卷进行存储的 Pod</a>。一个较长的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活动性和就绪性探针</a>。
|
||||
教程 | 教程页面展示如何实现某个目标，该目标将几个 Kubernetes 特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但应该链接到相关概念主题，以便深入解释各个特性。
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
Use a template for each new page. Each page type has a
|
||||
@@ -89,8 +66,7 @@ Use a template for each new page. Each page type has a
|
||||
that you can use as you write your topic. Using templates helps ensure
|
||||
consistency among topics of a given type.
|
||||
-->
|
||||
|
||||
为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。
|
||||
为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)，这个模板可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。
|
||||
|
||||
<!--
|
||||
## Choosing a title and filename
|
||||
@@ -120,12 +96,12 @@ URL for the topic, for example:
|
||||
|
||||
<!--
|
||||
In your topic, put a `title` field in the
|
||||
[front matter](https://jekyllrb.com/docs/frontmatter/).
|
||||
[front matter](https://gohugo.io/content-management/front-matter/).
|
||||
The front matter is the YAML block that is between the
|
||||
triple-dashed lines at the top of the page. Here's an example:
|
||||
-->
|
||||
|
||||
在你的主题中，在[页面头部](https://jekyllrb.com/docs/frontmatter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子：
|
||||
在你的主题中，在[页面头部](https://gohugo.io/content-management/front-matter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子：
|
||||
|
||||
<!--
|
||||
---
|
||||
@@ -191,7 +167,7 @@ use multiples of 10, to account for adding topics later. For instance, a topic
|
||||
with weight `10` will come before one with weight `20`.
|
||||
-->
|
||||
|
||||
默认情况下，目录中的其他文件按字母顺序排序。这几乎不是最好的顺序。要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数。通常我们使用10的倍数，添加后续主题时权重值递增。例如，权重为 `10` 的主题将位于权重为 `20` 的主题之前。
|
||||
默认情况下，目录中的其他文件按字母顺序排序。这几乎不是最好的顺序。要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数。通常我们使用 10 的倍数，添加后续主题时 `weight` 值递增。例如，`weight` 为 `10` 的主题将位于 `weight` 为 `20` 的主题之前。
|
||||
|
||||
<!--
|
||||
## Embedding code in your topic
|
||||
@@ -205,7 +181,7 @@ file directly using the markdown code block syntax. This is recommended for the
|
||||
following cases (not an exhaustive list):
|
||||
-->
|
||||
|
||||
如果你想在主题中包含一些代码，可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况（并非详尽列表）：
|
||||
如果你想在主题中嵌入一些代码，可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况（并非详尽列表）：
|
||||
|
||||
<!--
|
||||
- The code shows the output from a command such as
|
||||
@@ -213,7 +189,7 @@ following cases (not an exhaustive list):
|
||||
- The code is not generic enough for users to try out. As an example, you can
|
||||
embed the YAML
|
||||
file for creating a Pod which depends on a specific
|
||||
[Flexvolume](/docs/concepts/storage/volumes#flexvolume) implementation.
|
||||
[FlexVolume](/docs/concepts/storage/volumes#flexvolume) implementation.
|
||||
- The code is an incomplete example because its purpose is to highlight a
|
||||
portion of a larger file. For example, when describing ways to
|
||||
customize the [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
|
||||
@@ -225,7 +201,7 @@ following cases (not an exhaustive list):
|
||||
-->
|
||||
|
||||
- 代码显示来自命令的输出，例如 `kubectl get deploy mydeployment -o json | jq '.status'`。
|
||||
- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定 [Flexvolume](/docs/concepts/storage/volumes#flexvolume)实现的 Pod。
|
||||
- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定 [FlexVolume](/docs/concepts/storage/volumes#flexvolume)实现的 Pod。
|
||||
- 该代码是一个不完整的示例，因为它的目的是高亮显示大文件的部分内容。例如，在描述自定义 [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)的方法时，出于某些原因，你可以直接在主题文件中提供一个简短的片段。
|
||||
- 由于其他原因，该代码不适合用户验证。例如，当使用 `kubectl edit` 命令描述如何将新属性添加到资源时，你可以提供一个仅包含要添加的属性的简短示例。
|
||||
|
||||
@@ -266,13 +242,12 @@ file located at `/content/en/examples/pods/storage/gce-volume.yaml`.
|
||||
{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
To show raw Hugo shortcodes as in the above example and prevent Hugo
|
||||
from interpreting them, use C-style comments directly after the `<` and before
|
||||
the `>` characters. View the code for this page for an example.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释，请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -300,14 +275,13 @@ In your topic, show this command:
|
||||
kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
When adding new YAML files to the `<LANG>/examples` directory, make
|
||||
sure the file is also included into the `<LANG>/examples_test.go` file. The
|
||||
Travis CI for the Website automatically runs this test case when PRs are
|
||||
submitted to ensure all examples pass the tests.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
将新的 YAML 文件添加到 `<LANG>/examples` 目录时，请确保该文件也在 `<LANG>/examples_test.go` 文件中被引用。当提交拉取请求时，网站的 Travis CI 会自动运行此测试用例，以确保所有示例都通过测试。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -333,13 +307,12 @@ image format is SVG.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
* Learn about [using page templates](/docs/home/contribute/page-templates/).
|
||||
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/).
|
||||
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
|
||||
-->
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* 学习[使用页面模板](/docs/home/contribute/page-templates/)。
|
||||
* 学习[展示你的修改](/docs/home/contribute/stage-documentation-changes/)。
|
||||
* 学习[创建一个拉取请求](/docs/home/contribute/create-pull-request/)。
|
||||
|
||||
+672
-585
File diff suppressed because it is too large
Load Diff
@@ -44,6 +44,7 @@ Read operations:
|
||||
* nodes
|
||||
* pods
|
||||
* secrets、configmaps、以及绑定到 kubelet 的节点的 pod 的持久卷申领和持久卷
|
||||
|
||||
<!--
|
||||
* services
|
||||
* endpoints
|
||||
@@ -60,6 +61,7 @@ Write operations:
|
||||
* 节点和节点状态（启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点）
|
||||
* Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
|
||||
* 事件
|
||||
|
||||
<!--
|
||||
* nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node)
|
||||
* pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself)
|
||||
@@ -73,6 +75,7 @@ Auth-related operations:
|
||||
|
||||
* 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限
|
||||
* 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力
|
||||
|
||||
<!--
|
||||
* read/write access to the certificationsigningrequests API for TLS bootstrapping
|
||||
* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
|
||||
|
||||
@@ -37,7 +37,7 @@ etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Ku
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
Always have a backup plan for etcd's data for your Kubernetes cluster. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
|
||||
Always have a backup plan for etcd's data for your Kubernetes cluster. For in-depth information on etcd, see [etcd documentation](https://etcd.io/docs).
|
||||
-->
|
||||
|
||||
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)。
|
||||
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://etcd.io/docs)。
|
||||
|
||||
@@ -1,16 +1,33 @@
|
||||
---
|
||||
title: Kubernetes 问题追踪
|
||||
weight: 10
|
||||
aliases: [cve/,cves/]
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Kubernetes Issue Tracker
|
||||
weight: 10
|
||||
aliases: [/cve/,/cves/]
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Work on Kubernetes code is tracked using [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/).
|
||||
To report a security issue, please follow the [Kubernetes security disclosure process](/docs/reference/issues-security/security/#report-a-vulnerability).
|
||||
-->
|
||||
Kubernetes 代码的问题追踪基于 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 进行。
|
||||
要报告安全问题，请遵循 [Kubernetes 安全问题公开流程](/docs/reference/issues-security/security/#report-a-vulnerability)。
|
||||
|
||||
<!--
|
||||
Work on Kubernetes code and public issues are tracked using [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/).
|
||||
-->
|
||||
使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 跟踪 Kubernetes 编码工作和公开问题。
|
||||
|
||||
<!--
|
||||
* [CVE-related issues](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE)
|
||||
-->
|
||||
* [CVE 相关问题](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE)
|
||||
|
||||
<!--
|
||||
Security-related announcements are sent to the [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) mailing list.
|
||||
-->
|
||||
与安全性相关的公告请发送到 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 邮件列表。
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: Kubernetes 安全和信息披露
|
||||
aliases: [security/]
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Kubernetes Security and Disclosure Information
|
||||
aliases: [/security/]
|
||||
reviewers:
|
||||
@@ -15,7 +15,6 @@ reviewers:
|
||||
- jessfraz
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
@@ -36,6 +35,11 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete
|
||||
-->
|
||||
加入 [kubernets-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 组，以获取关于安全性和主要 API 公告的电子邮件。
|
||||
|
||||
<!--
|
||||
You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50).
|
||||
-->
|
||||
您也可以使用[此链接](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)订阅上述的 RSS 反馈。
|
||||
|
||||
<!--
|
||||
## Report a Vulnerability
|
||||
-->
|
||||
@@ -52,6 +56,10 @@ To make a report, please email the private [security@kubernetes.io](mailto:secur
|
||||
-->
|
||||
如需报告，请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)详细信息电邮到[security@kubernetes.io](mailto:security@kubernetes.io) 列表。
|
||||
|
||||
<!--
|
||||
You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md).
|
||||
-->
|
||||
您还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含[所有 Kubernetes 错误报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)所需的详细信息。
|
||||
<!--
|
||||
You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.
|
||||
-->
|
||||
@@ -66,11 +74,13 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur
|
||||
<!--
|
||||
- You think you discovered a potential security vulnerability in Kubernetes
|
||||
- You are unsure how a vulnerability affects Kubernetes
|
||||
- You think you discovered a vulnerability in another project that Kubernetes depends on (e.g. docker, rkt, etcd)
|
||||
- You think you discovered a vulnerability in another project that Kubernetes depends on
|
||||
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
|
||||
-->
|
||||
- 您认为在 Kubernetes 中发现了一个潜在的安全漏洞
|
||||
- 您不确定漏洞如何影响 Kubernetes
|
||||
- 您认为您在 Kubernetes 依赖的另一个项目中发现了一个漏洞（例如 docker、rkt、etcd）
|
||||
- 您认为您在 Kubernetes 依赖的另一个项目中发现了一个漏洞
|
||||
- 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告
|
||||
|
||||
<!--
|
||||
### When Should I NOT Report a Vulnerability?
|
||||
@@ -117,7 +127,7 @@ A public disclosure date is negotiated by the Kubernetes product security team a
|
||||
公开披露日期由 Kubernetes 产品安全团队和 bug 提交者协商。我们倾向于在用户缓解措施可用时尽快完全披露该 bug。
|
||||
|
||||
<!--
|
||||
It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination.
|
||||
It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination.
|
||||
-->
|
||||
当 bug 或其修复还没有被完全理解，解决方案没有经过良好的测试，或者为了处理供应商协调问题时，延迟披露是合理的。
|
||||
|
||||
|
||||
@@ -529,6 +529,7 @@ kubectl [flags]
|
||||
* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - 以“组/版本”的格式输出服务端所支持的 API 版本
|
||||
* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - 基于文件名或标准输入，将新的配置应用到资源上
|
||||
* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - 连接到一个正在运行的容器
|
||||
|
||||
<!--
|
||||
* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Inspect authorization
|
||||
* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
||||
@@ -543,6 +544,7 @@ kubectl [flags]
|
||||
* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - 显示集群信息
|
||||
* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - 根据已经给出的 Shell（bash 或 zsh），输出 Shell 补全后的代码
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - 修改 kubeconfig 配置文件
|
||||
|
||||
<!--
|
||||
* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Convert config files between different API versions
|
||||
* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Mark node as unschedulable
|
||||
@@ -555,6 +557,7 @@ kubectl [flags]
|
||||
* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - 将文件和目录拷入/拷出容器。
|
||||
* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - 通过文件或标准输入来创建资源
|
||||
* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - 通过文件名、标准输入、资源和名字删除资源，或者通过资源和标签选择器来删除资源
|
||||
|
||||
<!--
|
||||
* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Show details of a specific resource or group of resources
|
||||
* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Diff live version against would-be applied version
|
||||
@@ -571,6 +574,7 @@ kubectl [flags]
|
||||
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - 在容器中执行相关命令
|
||||
* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - 显示资源文档说明
|
||||
* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - 给定副本控制器、服务、Deployment 或 Pod，将其暴露为新的 kubernetes Service
|
||||
|
||||
<!--
|
||||
* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Display one or many resources
|
||||
* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Build a kustomization target from a directory or a remote url.
|
||||
@@ -585,6 +589,7 @@ kubectl [flags]
|
||||
* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - 输出 pod 中某容器的日志
|
||||
* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - 打印所有命令都支持的共有参数列表
|
||||
* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - 基于策略性合并修补（Stategic Merge Patch）规则更新某资源中的字段
|
||||
|
||||
<!--
|
||||
* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Provides utilities for interacting with plugins.
|
||||
* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Forward one or more local ports to a pod
|
||||
@@ -599,6 +604,7 @@ kubectl [flags]
|
||||
* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - 基于文件名或标准输入替换资源
|
||||
* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - 管理资源的上线
|
||||
* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - 在集群中使用指定镜像启动容器
|
||||
|
||||
<!--
|
||||
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job
|
||||
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Set specific features on objects
|
||||
|
||||
-12
@@ -107,15 +107,3 @@ kubeadm config print init-defaults [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm config print](kubeadm_config_print.md) - Print configuration
|
||||
-->
|
||||
* [kubeadm config print](kubeadm_config_print.md) - 打印配置
|
||||
|
||||
|
||||
-13
@@ -106,16 +106,3 @@ kubeadm config print join-defaults [flags]
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm config print](kubeadm_config_print.md) - Print configuration
|
||||
-->
|
||||
* [kubeadm config print](kubeadm_config_print.md) - 打印配置
|
||||
|
||||
|
||||
@@ -91,15 +91,3 @@ kubeadm config view [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm config](kubeadm_config.md) - Manage configuration for a kubeadm cluster persisted in a ConfigMap in the cluster
|
||||
-->
|
||||
* [kubeadm config](kubeadm_config.md) - 管理 kubeadm 集群的配置，该配置保留在集群的 ConfigMap 中
|
||||
|
||||
|
||||
@@ -435,16 +435,3 @@ kubeadm init [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm](kubeadm.md) - kubeadm: easily bootstrap a secure Kubernetes cluster
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
* [kubeadm](kubeadm.md) - kubeadm: 轻松引导安全的 Kubernetes 集群
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
|
||||
@@ -66,37 +66,3 @@ Use this command to invoke single phase of the init workflow
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init](kubeadm_init.md) - Run this command in order to set up the Kubernetes control plane
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - Install required addons for passing Conformance tests
|
||||
* [kubeadm init phase bootstrap-token](kubeadm_init_phase_bootstrap-token.md) - Generates bootstrap tokens used to join a node to a cluster
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - Certificate generation
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - Generate all static Pod manifest files necessary to establish the control plane
|
||||
* [kubeadm init phase etcd](kubeadm_init_phase_etcd.md) - Generate static Pod manifest file for local etcd
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
|
||||
* [kubeadm init phase kubelet-start](kubeadm_init_phase_kubelet-start.md) - Write kubelet settings and (re)start the kubelet
|
||||
* [kubeadm init phase mark-control-plane](kubeadm_init_phase_mark-control-plane.md) - Mark a node as a control-plane
|
||||
* [kubeadm init phase preflight](kubeadm_init_phase_preflight.md) - Run pre-flight checks
|
||||
* [kubeadm init phase upload-certs](kubeadm_init_phase_upload-certs.md) - Upload certificates to kubeadm-certs
|
||||
* [kubeadm init phase upload-config](kubeadm_init_phase_upload-config.md) - Upload the kubeadm and kubelet configuration to a ConfigMap
|
||||
-->
|
||||
* [kubeadm init](kubeadm_init.md) - 运行此命令以设置 Kubernetes 控制平面
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - 安装通过一致性测试所需的插件
|
||||
* [kubeadm init phase bootstrap-token](kubeadm_init_phase_bootstrap-token.md) - 生成用于将节点加入集群的引导令牌
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - 生成证书
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - 生成建立控制平面所需的所有静态 Pod 清单文件
|
||||
* [kubeadm init phase etcd](kubeadm_init_phase_etcd.md) - 为本地 etcd 生成静态 Pod 清单文件
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - 生成建立控制平面所需的 kubeconfig 文件和管理员用的 kubeconfig 文件
|
||||
* [kubeadm init phase kubelet-start](kubeadm_init_phase_kubelet-start.md) - 编写 kubelet 设置并（重新）启动 kubelet
|
||||
* [kubeadm init phase mark-control-plane](kubeadm_init_phase_mark-control-plane.md) - 将节点标记为控制平面
|
||||
* [kubeadm init phase preflight](kubeadm_init_phase_preflight.md) - 运行 pre-flight（启动） 检查
|
||||
* [kubeadm init phase upload-certs](kubeadm_init_phase_upload-certs.md) - 将证书上传到 kubeadm-certs
|
||||
* [kubeadm init phase upload-config](kubeadm_init_phase_upload-config.md) - 将 kubeadm 和 kubelet 配置上传到 ConfigMap
|
||||
|
||||
|
||||
@@ -70,20 +70,3 @@ kubeadm init phase addon [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
* [kubeadm init phase addon all](kubeadm_init_phase_addon_all.md) - Install all the addons
|
||||
* [kubeadm init phase addon coredns](kubeadm_init_phase_addon_coredns.md) - Install the CoreDNS addon to a Kubernetes cluster
|
||||
* [kubeadm init phase addon kube-proxy](kubeadm_init_phase_addon_kube-proxy.md) - Install the kube-proxy addon to a Kubernetes cluster
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
* [kubeadm init phase addon all](kubeadm_init_phase_addon_all.md) - 安装所有的插件
|
||||
* [kubeadm init phase addon coredns](kubeadm_init_phase_addon_coredns.md) - 将 CoreDNS 插件安装到 Kubernetes 集群
|
||||
* [kubeadm init phase addon kube-proxy](kubeadm_init_phase_addon_kube-proxy.md) - 将 kube-proxy 插件安装到 Kubernetes 集群
|
||||
|
||||
-12
@@ -231,15 +231,3 @@ kubeadm init phase addon all [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - Install required addons for passing Conformance tests
|
||||
-->
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - 安装通过一致性测试所需的插件
|
||||
|
||||
|
||||
-11
@@ -179,14 +179,3 @@ kubeadm init phase addon coredns [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - Install required addons for passing Conformance tests
|
||||
-->
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - 安装通过一致性测试所需的插件
|
||||
|
||||
-12
@@ -185,15 +185,3 @@ kubeadm init phase addon kube-proxy [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - Install required addons for passing Conformance tests
|
||||
-->
|
||||
* [kubeadm init phase addon](kubeadm_init_phase_addon.md) - 安装通过一致性测试所需的插件
|
||||
|
||||
|
||||
-12
@@ -130,15 +130,3 @@ kubeadm init phase bootstrap-token [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的某个阶段
|
||||
|
||||
|
||||
-12
@@ -126,15 +126,3 @@ kubeadm init phase certs front-proxy-ca [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - Certificate generation
|
||||
-->
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - 生成证书
|
||||
|
||||
|
||||
+1
-13
@@ -8,7 +8,7 @@
|
||||
<!--
|
||||
Generate the certificate for the front proxy client, and save them into front-proxy-client.cert and front-proxy-client.key files.
|
||||
|
||||
If both files already exist, kubeadm skips the generation step and existing files will be used.
|
||||
If both files already exist, kubeadm skips the generation step and existing files will be used.
|
||||
|
||||
Alpha Disclaimer: this command is currently alpha.
|
||||
-->
|
||||
@@ -147,15 +147,3 @@ kubeadm init phase certs front-proxy-client [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - Certificate generation
|
||||
-->
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - 生成证书
|
||||
|
||||
|
||||
-12
@@ -92,15 +92,3 @@ kubeadm init phase certs sa [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - Certificate generation
|
||||
-->
|
||||
* [kubeadm init phase certs](kubeadm_init_phase_certs.md) - 生成证书
|
||||
|
||||
|
||||
-20
@@ -71,23 +71,3 @@ kubeadm init phase control-plane [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
* [kubeadm init phase control-plane all](kubeadm_init_phase_control-plane_all.md) - Generate all static Pod manifest files
|
||||
* [kubeadm init phase control-plane apiserver](kubeadm_init_phase_control-plane_apiserver.md) - Generates the kube-apiserver static Pod manifest
|
||||
* [kubeadm init phase control-plane controller-manager](kubeadm_init_phase_control-plane_controller-manager.md) - Generates the kube-controller-manager static Pod manifest
|
||||
* [kubeadm init phase control-plane scheduler](kubeadm_init_phase_control-plane_scheduler.md) - Generates the kube-scheduler static Pod manifest
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
* [kubeadm init phase control-plane all](kubeadm_init_phase_control-plane_all.md) - 生成所有静态 Pod 清单文件
|
||||
* [kubeadm init phase control-plane apiserver](kubeadm_init_phase_control-plane_apiserver.md) - 生成 kube-apiserver 静态 Pod 清单
|
||||
* [kubeadm init phase control-plane controller-manager](kubeadm_init_phase_control-plane_controller-manager.md) - 生成 kube-controller-manager 静态 Pod 清单
|
||||
* [kubeadm init phase control-plane scheduler](kubeadm_init_phase_control-plane_scheduler.md) - 生成 kube-scheduler 静态 Pod 清单
|
||||
|
||||
|
||||
+1
-12
@@ -276,15 +276,4 @@ kubeadm init phase control-plane all --config config.yaml
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - Generate all static Pod manifest files necessary to establish the control plane
|
||||
-->
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - 生成建立控制平面所需的所有静态 Pod 的清单文件
|
||||
</table>
|
||||
-12
@@ -226,15 +226,3 @@ kubeadm init phase control-plane apiserver [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - Generate all static Pod manifest files necessary to establish the control plane
|
||||
-->
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - 生成建立控制平面所需的所有静态 Pod 清单文件
|
||||
|
||||
|
||||
-12
@@ -169,15 +169,3 @@ kubeadm init phase control-plane controller-manager [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - Generate all static Pod manifest files necessary to establish the control plane
|
||||
-->
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - 生成建立控制平面所需的所有静态 Pod 清单文件
|
||||
|
||||
|
||||
-12
@@ -157,15 +157,3 @@ kubeadm init phase control-plane scheduler [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - Generate all static Pod manifest files necessary to establish the control plane
|
||||
-->
|
||||
* [kubeadm init phase control-plane](kubeadm_init_phase_control-plane.md) - 生成建立控制平面所需的所有静态 Pod 清单文件
|
||||
|
||||
|
||||
-22
@@ -70,25 +70,3 @@ kubeadm init phase kubeconfig [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
* [kubeadm init phase kubeconfig admin](kubeadm_init_phase_kubeconfig_admin.md) - Generate a kubeconfig file for the admin to use and for kubeadm itself
|
||||
* [kubeadm init phase kubeconfig all](kubeadm_init_phase_kubeconfig_all.md) - Generate all kubeconfig files
|
||||
* [kubeadm init phase kubeconfig controller-manager](kubeadm_init_phase_kubeconfig_controller-manager.md) - Generate a kubeconfig file for the controller manager to use
|
||||
* [kubeadm init phase kubeconfig kubelet](kubeadm_init_phase_kubeconfig_kubelet.md) - Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
|
||||
* [kubeadm init phase kubeconfig scheduler](kubeadm_init_phase_kubeconfig_scheduler.md) - Generate a kubeconfig file for the scheduler to use
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
* [kubeadm init phase kubeconfig admin](kubeadm_init_phase_kubeconfig_admin.md) - 为管理员和 kubeadm 本身生成一个 kubeconfig 文件
|
||||
* [kubeadm init phase kubeconfig all](kubeadm_init_phase_kubeconfig_all.md) - 生成所有 kubeconfig 文件
|
||||
* [kubeadm init phase kubeconfig controller-manager](kubeadm_init_phase_kubeconfig_controller-manager.md) - 生成 kubeconfig 文件给控制器管理器使用
|
||||
* [kubeadm init phase kubeconfig kubelet](kubeadm_init_phase_kubeconfig_kubelet.md) - 为 kubelet 生成 kubeconfig 文件，*仅*用于集群引导
|
||||
* [kubeadm init phase kubeconfig scheduler](kubeadm_init_phase_kubeconfig_scheduler.md) - 生成 kubeconfig 文件给调度程序使用
|
||||
|
||||
|
||||
-13
@@ -174,16 +174,3 @@ kubeadm init phase kubeconfig admin [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
|
||||
-->
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - 生成建立控制平面所需的 kubeconfig 文件和管理员用的 kubeconfig 文件
|
||||
|
||||
|
||||
-13
@@ -186,16 +186,3 @@ kubeadm init phase kubeconfig all [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
|
||||
-->
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - 生成建立控制平面所需的 kubeconfig 文件和管理员用的 kubeconfig 文件
|
||||
|
||||
|
||||
|
||||
-10
@@ -171,13 +171,3 @@ kubeadm init phase kubeconfig controller-manager [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
|
||||
-->
|
||||
|
||||
查看其他
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - 生成建立控制平面所需的 kubeconfig 文件和管理员用的 kubeconfig 文件
|
||||
|
||||
|
||||
|
||||
|
||||
-12
@@ -174,15 +174,3 @@ kubeadm init phase kubeconfig scheduler [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
|
||||
-->
|
||||
* [kubeadm init phase kubeconfig](kubeadm_init_phase_kubeconfig.md) - 生成建立控制平面所需的 kubeconfig 文件和管理员用的 kubeconfig 文件
|
||||
|
||||
|
||||
-12
@@ -118,15 +118,3 @@ kubeadm init phase kubelet-start [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
|
||||
|
||||
-9
@@ -114,12 +114,3 @@ kubeadm init phase mark-control-plane [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
|
||||
查看其他
|
||||
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令调用 `init` 工作流程的单个阶段
|
||||
|
||||
|
||||
-12
@@ -108,15 +108,3 @@ kubeadm init phase preflight [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
|
||||
|
||||
-12
@@ -118,15 +118,3 @@ kubeadm init phase upload-certs [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
|
||||
|
||||
-15
@@ -68,18 +68,3 @@ kubeadm init phase upload-config [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - Use this command to invoke single phase of the init workflow
|
||||
* [kubeadm init phase upload-config all](kubeadm_init_phase_upload-config_all.md) - Upload all configuration to a config map
|
||||
* [kubeadm init phase upload-config kubeadm](kubeadm_init_phase_upload-config_kubeadm.md) - Upload the kubeadm ClusterConfiguration to a ConfigMap
|
||||
* [kubeadm init phase upload-config kubelet](kubeadm_init_phase_upload-config_kubelet.md) - Upload the kubelet component config to a ConfigMap
|
||||
-->
|
||||
* [kubeadm init phase](kubeadm_init_phase.md) - 使用此命令可以调用 `init` 工作流程的单个阶段
|
||||
* [kubeadm init phase upload-config all](kubeadm_init_phase_upload-config_all.md) - 将所有的配置上传到 ConfigMap 中
|
||||
* [kubeadm init phase upload-config kubeadm](kubeadm_init_phase_upload-config_kubeadm.md) - 将 kubeadm 的集群配置上传到 ConfigMap 中
|
||||
* [kubeadm init phase upload-config kubelet](kubeadm_init_phase_upload-config_kubelet.md) - 将 kubelet 的组件配置上传到 ConfigMap 中
|
||||
|
||||
+115
-128
@@ -1,128 +1,115 @@
|
||||
|
||||
<!--
|
||||
### Synopsis
|
||||
-->
|
||||
### 概要
|
||||
|
||||
|
||||
<!--
|
||||
Upload kubelet configuration extracted from the kubeadm InitConfiguration object to a ConfigMap of the form kubelet-config-1.X in the cluster, where X is the minor version of the current (API Server) Kubernetes version.
|
||||
-->
|
||||
将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上传到集群中 kubelet-config-1.X 形式的 ConfigMap，其中 X 是当前（API 服务器）Kubernetes 版本的次要版本。
|
||||
|
||||
```
|
||||
kubeadm init phase upload-config kubelet [flags]
|
||||
```
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
-->
|
||||
### 示例
|
||||
|
||||
<!--
|
||||
```
|
||||
# Upload the kubelet configuration from the kubeadm Config file to a ConfigMap in the cluster.
|
||||
kubeadm init phase upload-config kubelet --config kubeadm.yaml
|
||||
```
|
||||
-->
|
||||
```
|
||||
# 将 kubelet 配置从 kubeadm 配置文件上传到集群中的 ConfigMap。
|
||||
kubeadm init phase upload-config kubelet --config kubeadm.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
### Options
|
||||
-->
|
||||
### 选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
Path to a kubeadm configuration file.
|
||||
-->
|
||||
到 kubeadm 配置文件的路径。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
help for kubelet
|
||||
-->
|
||||
kubelet 操作的帮助命令
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">
|
||||
<!--
|
||||
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
|
||||
-->
|
||||
--kubeconfig string 默认值："/etc/kubernetes/admin.conf"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
|
||||
-->
|
||||
与集群通信时使用的 kubeconfig 文件。如果未设置该标签，则可以通过一组标准路径来寻找已有的 kubeconfig 文件。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Options inherited from parent commands
|
||||
-->
|
||||
### 从父命令继承的选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--rootfs string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
[EXPERIMENTAL] The path to the 'real' host root filesystem.
|
||||
-->
|
||||
[实验] 到 '真实' 主机根文件系统的路径。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm init phase upload-config](kubeadm_init_phase_upload-config.md) - Upload the kubeadm and kubelet configuration to a ConfigMap
|
||||
-->
|
||||
* [kubeadm init phase upload-config](kubeadm_init_phase_upload-config.md) - 将 kubeadm 和 kubelet 配置上传到 ConfigMap
|
||||
|
||||
|
||||
<!--
|
||||
### Synopsis
|
||||
-->
|
||||
### 概要
|
||||
|
||||
|
||||
<!--
|
||||
Upload kubelet configuration extracted from the kubeadm InitConfiguration object to a ConfigMap of the form kubelet-config-1.X in the cluster, where X is the minor version of the current (API Server) Kubernetes version.
|
||||
-->
|
||||
将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上传到集群中 kubelet-config-1.X 形式的 ConfigMap，其中 X 是当前（API 服务器）Kubernetes 版本的次要版本。
|
||||
|
||||
```
|
||||
kubeadm init phase upload-config kubelet [flags]
|
||||
```
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
-->
|
||||
### 示例
|
||||
|
||||
<!--
|
||||
```
|
||||
# Upload the kubelet configuration from the kubeadm Config file to a ConfigMap in the cluster.
|
||||
kubeadm init phase upload-config kubelet --config kubeadm.yaml
|
||||
```
|
||||
-->
|
||||
```
|
||||
# 将 kubelet 配置从 kubeadm 配置文件上传到集群中的 ConfigMap。
|
||||
kubeadm init phase upload-config kubelet --config kubeadm.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
### Options
|
||||
-->
|
||||
### 选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
Path to a kubeadm configuration file.
|
||||
-->
|
||||
到 kubeadm 配置文件的路径。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
help for kubelet
|
||||
-->
|
||||
kubelet 操作的帮助命令
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">
|
||||
<!--
|
||||
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
|
||||
-->
|
||||
--kubeconfig string 默认值："/etc/kubernetes/admin.conf"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
|
||||
-->
|
||||
与集群通信时使用的 kubeconfig 文件。如果未设置该标签，则可以通过一组标准路径来寻找已有的 kubeconfig 文件。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Options inherited from parent commands
|
||||
-->
|
||||
### 从父命令继承的选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--rootfs string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">
|
||||
<!--
|
||||
[EXPERIMENTAL] The path to the 'real' host root filesystem.
|
||||
-->
|
||||
[实验] 到 '真实' 主机根文件系统的路径。
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
-12
@@ -231,15 +231,3 @@ kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - Prepare the machine for serving a control plane
|
||||
-->
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - 准备为控制平面服务的机器
|
||||
|
||||
|
||||
-12
@@ -190,15 +190,3 @@ kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - Prepare the machine for serving a control plane
|
||||
-->
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - 准备为控制平面服务的机器
|
||||
|
||||
|
||||
-12
@@ -135,15 +135,3 @@ kubeadm join phase control-plane-prepare control-plane [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - Prepare the machine for serving a control plane
|
||||
-->
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - 准备机器用于控制平面服务
|
||||
|
||||
|
||||
-12
@@ -178,15 +178,3 @@ kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [f
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - Prepare the machine for serving a control plane
|
||||
-->
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - 准备为控制平面服务的机器
|
||||
|
||||
|
||||
-12
@@ -178,15 +178,3 @@ kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - Prepare the machine for serving a control plane
|
||||
-->
|
||||
* [kubeadm join phase control-plane-prepare](kubeadm_join_phase_control-plane-prepare.md) - 准备为控制平面服务的机器
|
||||
|
||||
|
||||
-12
@@ -94,15 +94,3 @@ kubeadm reset phase preflight [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm reset phase](kubeadm_reset_phase.md) - Use this command to invoke single phase of the reset workflow
|
||||
-->
|
||||
* [kubeadm reset phase](kubeadm_reset_phase.md) - 使用此命令来调用 `reset` 工作流程的某个阶段
|
||||
|
||||
|
||||
-12
@@ -70,15 +70,3 @@ kubeadm reset phase update-cluster-status [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm reset phase](kubeadm_reset_phase.md) - Use this command to invoke single phase of the reset workflow
|
||||
-->
|
||||
* [kubeadm reset phase](kubeadm_reset_phase.md) - 使用此命令来调用 `reset` 工作流程的某个阶段
|
||||
|
||||
|
||||
@@ -143,22 +143,3 @@ kubeadm token [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其它
|
||||
|
||||
<!--
|
||||
* [kubeadm](kubeadm.md) - kubeadm: easily bootstrap a secure Kubernetes cluster
|
||||
* [kubeadm token create](kubeadm_token_create.md) - Create bootstrap tokens on the server
|
||||
* [kubeadm token delete](kubeadm_token_delete.md) - Delete bootstrap tokens on the server
|
||||
* [kubeadm token generate](kubeadm_token_generate.md) - Generate and print a bootstrap token, but do not create it on the server
|
||||
* [kubeadm token list](kubeadm_token_list.md) - List bootstrap tokens on the server
|
||||
-->
|
||||
* [kubeadm](kubeadm.md) - kubeadm：轻松引导安全的 Kubernetes 集群
|
||||
* [kubeadm token create](kubeadm_token_create.md) - 在服务器上创建引导令牌（bootstrap token）
|
||||
* [kubeadm token delete](kubeadm_token_delete.md) - 在服务器上删除引导令牌（bootstrap token）
|
||||
* [kubeadm token generate](kubeadm_token_generate.md) - 生成并打印引导令牌（bootstrap token），但不在服务器上创建引导令牌（bootstrap token）
|
||||
* [kubeadm token list](kubeadm_token_list.md) - 列出服务器上的引导令牌列表（bootstrap token）
|
||||
@@ -197,15 +197,3 @@ kubeadm token create [token]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm token](kubeadm_token.md) - Manage bootstrap tokens
|
||||
-->
|
||||
* [kubeadm token](kubeadm_token.md) - 管理引导令牌（bootstrap tokens）
|
||||
|
||||
|
||||
@@ -106,15 +106,3 @@ kubeadm token delete [token-value] ...
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm token](kubeadm_token.md) - Manage bootstrap tokens
|
||||
-->
|
||||
* [kubeadm token](kubeadm_token.md) - 管理引导令牌（bootstrap token）
|
||||
|
||||
|
||||
@@ -112,13 +112,3 @@ kubeadm token generate [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm token](kubeadm_token.md) - Manage bootstrap tokens -->
|
||||
* [kubeadm token](kubeadm_token.md) - 管理引导令牌（bootstrap token）
|
||||
|
||||
@@ -101,14 +101,3 @@ kubeadm token list [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm token](kubeadm_token.md) - Manage bootstrap tokens -->
|
||||
* [kubeadm token](kubeadm_token.md) - 管理引导令牌（bootstrap token）
|
||||
|
||||
|
||||
@@ -69,21 +69,3 @@ kubeadm upgrade [flags]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
|
||||
* [kubeadm](kubeadm.md) - kubeadm: easily bootstrap a secure Kubernetes cluster
|
||||
* [kubeadm upgrade apply](kubeadm_upgrade_apply.md) - Upgrade your Kubernetes cluster to the specified version
|
||||
* [kubeadm upgrade diff](kubeadm_upgrade_diff.md) - Show what differences would be applied to existing static pod manifests. See also: kubeadm upgrade apply --dry-run
|
||||
* [kubeadm upgrade node](kubeadm_upgrade_node.md) - Upgrade commands for a node in the cluster
|
||||
* [kubeadm upgrade plan](kubeadm_upgrade_plan.md) - Check which versions are available to upgrade to and validate whether your current cluster is upgradeable. To skip the internet check, pass in the optional [version] parameter
|
||||
-->
|
||||
|
||||
查看其他
|
||||
|
||||
* [kubeadm](kubeadm.md) - kubeadm: 轻松引导一个安全的 Kubernetes 集群
|
||||
* [kubeadm upgrade apply](kubeadm_upgrade_apply.md) - 升级你的 Kubernetes 集群到指定的版本
|
||||
* [kubeadm upgrade diff](kubeadm_upgrade_diff.md) - 显示现有的静态 pod 清单有什么不同。查看其它: kubeadm upgrade apply --dry-run
|
||||
* [kubeadm upgrade node](kubeadm_upgrade_node.md) - 集群中某个节点的升级命令
|
||||
* [kubeadm upgrade plan](kubeadm_upgrade_plan.md) - 检查哪些版本可以升级，并验证当前集群是否可以升级。要跳过网络检查，请传入可选的 [version] 参数
|
||||
|
||||
|
||||
@@ -252,14 +252,3 @@ kubeadm upgrade apply [version]
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
SEE ALSO
|
||||
-->
|
||||
查看其他
|
||||
|
||||
<!--
|
||||
* [kubeadm upgrade](kubeadm_upgrade.md) - Upgrade your cluster smoothly to a newer version with this command
|
||||
-->
|
||||
* [kubeadm 升级](kubeadm_upgrade.md) - 使用此命令将集群平滑升级到新版本
|
||||
@@ -181,7 +181,7 @@ After you initialize your master, the kubelet runs normally.
|
||||
请查阅[安装 kubeadm](/docs/setup/independent/install-kubeadm/)。
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 如果您的机器已经安装了 kubeadm, 请运行 `apt-get update &&
|
||||
如果您的机器已经安装了 kubeadm, 请运行 `apt-get update &&
|
||||
apt-get upgrade` 或者 `yum update` 来升级至最新版本的 kubeadm.
|
||||
|
||||
升级过程中，kubelet 会每隔几秒钟重启并陷入了不断循环等待 kubeadm 发布指令的状态。
|
||||
@@ -849,7 +849,7 @@ A few seconds later, you should notice this node in the output from `kubectl get
|
||||
nodes` when run on the master. -->
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 若需为 `<master-ip>:<master-port>` 参数设定一个 IPv6 的元组，地址必须写在一对方括号里面，比如: `[fd00::101]:2073`。
|
||||
若需为 `<master-ip>:<master-port>` 参数设定一个 IPv6 的元组，地址必须写在一对方括号里面，比如: `[fd00::101]:2073`。
|
||||
{{< /note >}}
|
||||
|
||||
输出类似这样:
|
||||
@@ -905,7 +905,7 @@ kubectl --kubeconfig ./admin.conf get nodes
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 上面的例子生效的前提是 SSH 允许 root 用户连接登录。
|
||||
上面的例子生效的前提是 SSH 允许 root 用户连接登录。
|
||||
如果root 用户不能连接的话，您可以将 `admin.conf` 复制到允许其他用户访问的其他地方并将 `scp` 命令里的用户改成相对应的用户再复制。
|
||||
|
||||
这个 `admin.conf` 文件给予了用户整个集群的超级用户权限，因此这个操作必须小心谨慎。对于普通用户来说，
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ content_template: templates/task
|
||||
本文展示如何使用配置文件来配置对多个集群的访问。 在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用 `kubectl config use-context` 命令快速地在集群之间进行切换。
|
||||
|
||||
{{< note >}}
|
||||
**注意：** 用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -186,6 +186,7 @@ for LoadBalancer and NodePort type services, but risks potentially imbalanced
|
||||
traffic spreading.
|
||||
-->
|
||||
* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：Cluster（默认）和 Local。Cluster 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，但存在潜在的不均衡流量传播风险。
|
||||
|
||||
<!--
|
||||
* `service.spec.healthCheckNodePort` - specifies the health check nodePort
|
||||
(numeric port number) for the service. If not specified, `healthCheckNodePort` is
|
||||
|
||||
@@ -176,7 +176,7 @@ The deploy wizard expects that you provide the following information:
|
||||
<!--
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). For external Services, you may need to open up one or more ports to do so. Find more details [here](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
|
||||
-->
|
||||
- **服务**（可选）：对于部分应用（比如前端），您可能想对外暴露一个 [Service](/docs/concepts/services-networking/service/) ，这个 Service（外部 Service）可能用的是集群之外的公网 IP 地址。对于外部 Service 的情况，需要开放一个或者多个端口来满足。更多信息请参考 [这里](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/。
|
||||
- **服务**（可选）：对于部分应用（比如前端），您可能想对外暴露一个 [Service](/docs/concepts/services-networking/service/) ，这个 Service（外部 Service）可能用的是集群之外的公网 IP 地址。对于外部 Service 的情况，需要开放一个或者多个端口来满足。更多信息请参考 [这里](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)。
|
||||
|
||||
<!--
|
||||
Other Services that are only visible from inside the cluster are called internal Services.
|
||||
|
||||
@@ -194,7 +194,7 @@ kubectl apply -f dns-horizontal-autoscaler.yaml
|
||||
|
||||
The output of a successful command is:
|
||||
|
||||
deployment.apps/kube-dns-autoscaler created
|
||||
deployment.apps/dns-autoscaler created
|
||||
|
||||
DNS horizontal autoscaling is now enabled.
|
||||
-->
|
||||
@@ -216,7 +216,7 @@ kubectl apply -f dns-horizontal-autoscaler.yaml
|
||||
|
||||
一个成功的命令输出是：
|
||||
|
||||
deployment.apps/kube-dns-autoscaler created
|
||||
deployment.apps/dns-autoscaler created
|
||||
|
||||
DNS 水平自动伸缩在已经启用了。
|
||||
|
||||
|
||||
@@ -44,18 +44,21 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
|
||||
-->
|
||||
* **NAT (网络地址解析)**
|
||||
是一种通过修改 IP 地址头中的源和/或目标地址信息将一个 IP 地址重新映射到另一个 IP 地址的方法。通常由执行 IP 路由的设备执行。
|
||||
|
||||
<!--
|
||||
* **Masquerading**
|
||||
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
|
||||
-->
|
||||
* **伪装**
|
||||
NAT 的一种形式，通常用于执行多对一地址转换，其中多个源 IP 地址被隐藏在单个地址后面，该地址通常是执行 IP 路由的设备。在 Kubernetes 中，这是节点的 IP 地址。
|
||||
|
||||
<!--
|
||||
* **CIDR (Classless Inter-Domain Routing)**
|
||||
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
|
||||
-->
|
||||
* **CIDR (无类别域间路由)**
|
||||
基于可变长度子网掩码，允许指定任意长度的前缀。CIDR 引入了一种新的 IP 地址表示方法，现在通常称为**CIDR表示法**，其中地址或路由前缀后添加一个后缀，用来表示前缀的位数，例如 192.168.2.0/24。
|
||||
|
||||
<!--
|
||||
* **Link Local**
|
||||
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
|
||||
@@ -79,10 +82,12 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
|
||||
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
|
||||
-->
|
||||
* **nonMasqueradeCIDRs:** [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1) 表示法中的字符串列表，用于指定不需伪装的地址范围。
|
||||
|
||||
<!--
|
||||
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
|
||||
-->
|
||||
* **masqLinkLocal:** 布尔值 (true / false)，表示是否将流量伪装到本地链路前缀169.254.0.0/16。 默认为 false。
|
||||
|
||||
<!--
|
||||
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
|
||||
-->
|
||||
|
||||
@@ -120,6 +120,7 @@ This works for e2e clusters created on GCE. On all other environments, the follo
|
||||
* A yaml similar to [this](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) can be applied using `kubectl create -f` command.
|
||||
-->
|
||||
* 可以使用 `kubectl create -f` 命令应用类似于[这个](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml)的 Yaml 。
|
||||
|
||||
<!--
|
||||
* --cluster-dns flag to kubelet needs to be modified to use the LOCAL_DNS IP that NodeLocal DNSCache is listening on (169.254.20.10 by default)
|
||||
-->
|
||||
|
||||
@@ -40,6 +40,7 @@ applications, such as key-value stores (such as Redis) and databases.
|
||||
## 为 Pod 配置卷
|
||||
|
||||
在本练习中，您将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷，在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
|
||||
|
||||
<!--
|
||||
## Configure a volume for a Pod
|
||||
|
||||
@@ -149,10 +150,10 @@ of `Always`.
|
||||
-->
|
||||
|
||||
1. 用 shell 终端进入重新启动的容器中：
|
||||
|
||||
<!--
|
||||
1.Get a shell into the restarted Container:
|
||||
-->
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis -- /bin/bash
|
||||
```
|
||||
@@ -161,6 +162,7 @@ of `Always`.
|
||||
<!--
|
||||
1.In your shell, goto `/data/redis`, and verify that `test-file` is still there.
|
||||
-->
|
||||
|
||||
```shell
|
||||
root@redis:/data/redis# cd /data/redis/
|
||||
root@redis:/data/redis# ls
|
||||
@@ -168,10 +170,10 @@ of `Always`.
|
||||
```
|
||||
|
||||
1. 删除为此练习所创建的 Pod：
|
||||
|
||||
<!--
|
||||
1.Delete the Pod that you created for this exercise:
|
||||
-->
|
||||
|
||||
```shell
|
||||
kubectl delete pod redis
|
||||
```
|
||||
@@ -185,6 +187,7 @@ of `Always`.
|
||||
* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
|
||||
|
||||
* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，例如安装和卸载设备。了解更多详情请参阅[卷](/docs/concepts/storage/volumes/)。
|
||||
|
||||
<!--
|
||||
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
|
||||
|
||||
|
||||
@@ -36,6 +36,7 @@ parallelism and completions exist across the registered clusters.
|
||||
|
||||
* {{< include "federated-task-tutorial-prereqs.md" >}}
|
||||
* 你需要具备基本的 [Kubernetes 的工作知识](/docs/tutorials/kubernetes-basics/)，特别是 [job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
|
||||
|
||||
<!--
|
||||
* You should also have a basic
|
||||
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
|
||||
|
||||
@@ -41,7 +41,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**注意：** 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
|
||||
如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
|
||||
+1
-1
@@ -40,7 +40,7 @@ content_template: templates/task
|
||||
第二个元素指示Pod的`annotations`字段的值保存在名为`annotations`的文件中。
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
{{< /note >}}
|
||||
|
||||
创建 Pod：
|
||||
|
||||
+1
-1
@@ -43,7 +43,7 @@ content_template: templates/task
|
||||
数组中第一个元素指定`MY_NODE_NAME`这个环境变量从Pod的`spec.nodeName`字段获取变量值。同样，其它环境变量也是从Pod的字段获取它们的变量值。
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
{{< /note >}}
|
||||
|
||||
创建Pod：
|
||||
|
||||
@@ -423,7 +423,7 @@ Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载
|
||||
image.
|
||||
* By copying the profiles to each node and loading them through SSH, as demonstrated in the
|
||||
[Example](#example). -->
|
||||
* 通过在每个节点上运行 Pod 的[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor loader)。
|
||||
* 通过在每个节点上运行 Pod 的[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。
|
||||
* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或图像。
|
||||
* 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ content_template: templates/tutorial
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
Kubernetes 集群中运行的应用通过抽象的 Service 查找彼此，相互通信和连接外部世界。本文揭示了发送到不同类型 Services 的数据包源 IP 的内幕，你可以根据需求改变这个行为。
|
||||
Kubernetes 集群中运行的应用通过 Service 抽象来互相查找、通信和与外部世界沟通。本文介绍被发送到不同类型 Services 的数据包源 IP 的变化过程，你可以根据你的需求改变这些行为。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -31,11 +31,14 @@ Kubernetes 集群中运行的应用通过抽象的 Service 查找彼此，相互
|
||||
## 准备工作
|
||||
|
||||
|
||||
你必须拥有一个正常工作的 Kubernetes 1.5 集群，用来运行本文中的示例。该示例使用一个简单的 nginx webserver 回送它接收到的请求的 HTTP 头中的源 IP 地址。你可以像下面这样创建它：
|
||||
你必须拥有一个正常工作的 Kubernetes 1.5 集群来运行此文档中的示例。该示例使用一个简单的 nginx webserver，通过一个HTTP消息头返回它接收到请求的源IP。你可以像下面这样创建它：
|
||||
|
||||
```console
|
||||
$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
||||
deployment "source-ip-app" created
|
||||
kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
||||
```
|
||||
输出结果为
|
||||
```
|
||||
deployment.apps/source-ip-app created
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -45,7 +48,7 @@ deployment "source-ip-app" created
|
||||
|
||||
* 通过多种类型的 Services 暴露一个简单应用
|
||||
* 理解每种 Service 类型如何处理源 IP NAT
|
||||
* 理解保留源 IP 的折中
|
||||
* 理解保留源IP所涉及的折中
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -59,33 +62,50 @@ deployment "source-ip-app" created
|
||||
如果你的 kube-proxy 运行在 [iptables 模式](/docs/user-guide/services/#proxy-mode-iptables)下，从集群内部发送到 ClusterIP 的包永远不会进行源地址 NAT，这从 Kubernetes 1.2 开始是默认选项。Kube-proxy 通过一个 `proxyMode` endpoint 暴露它的模式。
|
||||
|
||||
```console
|
||||
$ kubectl get nodes
|
||||
NAME STATUS AGE VERSION
|
||||
kubernetes-minion-group-6jst Ready 2h v1.6.0+fff5156
|
||||
kubernetes-minion-group-cx31 Ready 2h v1.6.0+fff5156
|
||||
kubernetes-minion-group-jj1t Ready 2h v1.6.0+fff5156
|
||||
|
||||
kubernetes-minion-group-6jst $ curl localhost:10249/proxyMode
|
||||
kubectl get nodes
|
||||
```
|
||||
输出结果与以下结果类似:
|
||||
```
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
kubernetes-node-6jst Ready <none> 2h v1.13.0
|
||||
kubernetes-node-cx31 Ready <none> 2h v1.13.0
|
||||
kubernetes-node-jj1t Ready <none> 2h v1.13.0
|
||||
```
|
||||
从其中一个节点中得到代理模式
|
||||
```console
|
||||
kubernetes-node-6jst $ curl localhost:10249/proxyMode
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
iptables
|
||||
```
|
||||
|
||||
|
||||
你可以通过在 source IP 应用上创建一个服务来测试源 IP 保留。
|
||||
你可以通过在source IP应用上创建一个Service来测试源IP保留。
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
||||
service "clusterip" exposed
|
||||
|
||||
$ kubectl get svc clusterip
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
clusterip 10.0.170.92 <none> 80/TCP 51s
|
||||
kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
service/clusterip exposed
|
||||
```
|
||||
```console
|
||||
kubectl get svc clusterip
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
||||
```
|
||||
|
||||
|
||||
从相同集群中的一个 pod 访问这个 `ClusterIP`：
|
||||
|
||||
```console
|
||||
$ kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
|
||||
@@ -116,21 +136,29 @@ command=GET
|
||||
## Type=NodePort 类型 Services 的 Source IP
|
||||
|
||||
|
||||
对于 Kubernetes 1.5，发送给类型为 [Type=NodePort](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以创建一个 `NodePort` Service 来进行测试：
|
||||
从 Kubernetes 1.5 开始，发送给类型为 [Type=NodePort](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以通过创建一个 `NodePort` Service 来进行测试：
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
||||
service "nodeport" exposed
|
||||
kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
service/nodeport exposed
|
||||
```
|
||||
|
||||
$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||
$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
|
||||
```console
|
||||
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
|
||||
```
|
||||
|
||||
如果你的集群运行在一个云服务上，你可能需要为上面报告的 `nodes:nodeport` 开启一条防火墙规则。
|
||||
现在，你可以通过上面分配的节点端口从外部访问这个 Service。
|
||||
|
||||
```console
|
||||
$ for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
||||
for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
client_address=10.180.1.1
|
||||
client_address=10.240.0.5
|
||||
client_address=10.240.0.3
|
||||
@@ -146,7 +174,7 @@ client_address=10.240.0.3
|
||||
* Pod 的回复被发送回给客户端
|
||||
|
||||
|
||||
形象的：
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
@@ -167,15 +195,21 @@ client_address=10.240.0.3
|
||||
设置 `service.spec.externalTrafficPolicy` 字段如下：
|
||||
|
||||
```console
|
||||
$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
service "nodeport" patched
|
||||
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
service/nodeport patched
|
||||
```
|
||||
|
||||
|
||||
现在，重新运行测试：
|
||||
|
||||
```console
|
||||
$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
||||
for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
client_address=104.132.1.79
|
||||
```
|
||||
|
||||
@@ -191,7 +225,7 @@ client_address=104.132.1.79
|
||||
* node1 使用正确的源 IP 地址将数据包路由到 endpoint
|
||||
|
||||
|
||||
形象的：
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
@@ -210,20 +244,34 @@ client_address=104.132.1.79
|
||||
## Type=LoadBalancer 类型 Services 的 Source IP
|
||||
|
||||
|
||||
对于 Kubernetes 1.5，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是由于所有处于 `Ready` 状态的 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
|
||||
从Kubernetes1.5开始，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是因为所有处于 `Ready` 状态的可调度 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
|
||||
|
||||
|
||||
你可以通过在一个 loadbalancer 上暴露这个 source-ip-app 来进行测试。
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
||||
service "loadbalancer" exposed
|
||||
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
||||
```
|
||||
输出结果为：
|
||||
```
|
||||
service/loadbalancer exposed
|
||||
```
|
||||
|
||||
$ kubectl get svc loadbalancer
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
loadbalancer 10.0.65.118 104.198.149.140 80/TCP 5m
|
||||
打印Service的IPs：
|
||||
```console
|
||||
kubectl get svc loadbalancer
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
loadbalancer LoadBalancer 10.0.65.118 104.198.149.140 80/TCP 5m
|
||||
```
|
||||
|
||||
$ curl 104.198.149.140
|
||||
```console
|
||||
curl 104.198.149.140
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=10.240.0.5
|
||||
...
|
||||
@@ -233,7 +281,7 @@ client_address=10.240.0.5
|
||||
然而，如果你的集群运行在 Google Kubernetes Engine/GCE 上，设置 `service.spec.externalTrafficPolicy` 字段值为 `Local` 可以强制使*没有* endpoints 的节点把他们自己从负载均衡流量的可选节点名单中删除。这是通过故意使它们健康检查失败达到的。
|
||||
|
||||
|
||||
形象的：
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
@@ -251,29 +299,44 @@ health check ---> node 1 node 2 <--- health check
|
||||
你可以设置 annotation 来进行测试：
|
||||
|
||||
```console
|
||||
$ kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
```
|
||||
|
||||
|
||||
你应该能够立即看到 Kubernetes 分配的 `service.spec.healthCheckNodePort` 字段：
|
||||
|
||||
```console
|
||||
$ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
||||
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
healthCheckNodePort: 32122
|
||||
```
|
||||
|
||||
|
||||
`service.spec.healthCheckNodePort` 字段指向每个节点在 `/healthz` 路径上提供的用于健康检查的端口。你可以这样测试：
|
||||
|
||||
```console
|
||||
kubectl get pod -o wide -l run=source-ip-app
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
$ kubectl get pod -o wide -l run=source-ip-app
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-minion-group-6jst
|
||||
|
||||
kubernetes-minion-group-6jst $ curl localhost:32122/healthz
|
||||
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
|
||||
```
|
||||
使用 curl 命令发送请求到每个节点的 `/healthz` 路径。
|
||||
```console
|
||||
kubernetes-node-6jst $ curl localhost:32122/healthz
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
1 Service Endpoints found
|
||||
|
||||
kubernetes-minion-group-jj1t $ curl localhost:32122/healthz
|
||||
```
|
||||
```console
|
||||
kubernetes-node-jj1t $ curl localhost:32122/healthz
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
No Service Endpoints Found
|
||||
```
|
||||
|
||||
@@ -281,7 +344,10 @@ No Service Endpoints Found
|
||||
主节点运行的 service 控制器负责分配 cloud loadbalancer。在这样做的同时，它也会分配指向每个节点的 HTTP 健康检查的 port/path。等待大约 10 秒钟之后，没有 endpoints 的两个节点的健康检查会失败，然后 curl 负载均衡器的 ip：
|
||||
|
||||
```console
|
||||
$ curl 104.198.149.140
|
||||
curl 104.198.149.140
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=104.132.1.79
|
||||
...
|
||||
@@ -291,7 +357,7 @@ client_address=104.132.1.79
|
||||
__跨平台支持__
|
||||
|
||||
|
||||
由于 Kubernetes 1.5 在类型为 Type=LoadBalancer 的 Services 中支持源 IP 保存的特性仅在 cloudproviders 的子集中实现（GCP and Azure）。你的集群运行的 cloudprovider 可能以某些不同的方式满足 loadbalancer 的要求：
|
||||
从 Kubernetes 1.5 开始，通过类型为 Type=LoadBalancer 的 Services 进行源 IP 保存的支持仅在一部分 cloudproviders 中实现（GCP and Azure）。你的集群运行的 cloudprovider 可能以某些不同的方式满足 loadbalancer 的要求：
|
||||
|
||||
|
||||
1. 使用一个代理终止客户端连接并打开一个到你的 nodes/endpoints 的新连接。在这种情况下，源 IP 地址将永远是云负载均衡器的地址而不是客户端的。
|
||||
@@ -327,5 +393,3 @@ $ kubectl delete deployment source-ip-app
|
||||
* 学习更多关于 [通过 services 连接应用](/docs/concepts/services-networking/connect-applications-service/)
|
||||
* 学习更多关于 [负载均衡](/docs/user-guide/load-balancer)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -223,7 +223,7 @@ Each Pod has a stable hostname based on its ordinal index. Use
|
||||
|
||||
### 使用稳定的网络身份标识
|
||||
|
||||
每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用[`kubectl exec`](/docs/user-guide/kubectl/{{< param "version" >}}/#exec)在每个 Pod 中执行`hostname`。
|
||||
每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)在每个 Pod 中执行`hostname`。
|
||||
|
||||
```shell
|
||||
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
||||
|
||||
@@ -1,194 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: 基础知识
|
||||
track: "USERS › CLUSTER OPERATOR › FOUNDATIONAL"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Foundational
|
||||
track: "USERS › CLUSTER OPERATOR › FOUNDATIONAL"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
If you want to learn how to get started managing and operating a Kubernetes cluster, this page and the linked topics introduce you to the foundational concepts and tasks.
|
||||
This page introduces you to a Kubernetes cluster and key concepts to understand and manage it. The content focuses primarily on the cluster itself rather than the software running within the cluster.
|
||||
-->
|
||||
如果您想学习如何开始管理和操作 Kubernetes 集群，本页面和链接主题将向您介绍基础概念和任务。本页面向您介绍 Kubernetes 集群以及理解和管理它的关键概念。内容主要关注集群本身，而不是集群中运行的软件。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
<!-- Foundational
|
||||
Nodes, Pods, Networks, Deployments, Services, ConfigMaps, Secrets
|
||||
Labels, Selectors, Annotations
|
||||
Metrics
|
||||
-->
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Get an overview of Kubernetes
|
||||
-->
|
||||
## Kubernetes 概要
|
||||
|
||||
<!--
|
||||
If you have not already done so, start your understanding by reading through [What is Kubernetes?](/docs/concepts/overview/what-is-kubernetes/), which introduces a number of basic concepts and terms.
|
||||
-->
|
||||
如果你还没有这样做，请通过阅读[什么是 Kubernetes?](/docs/concepts/overview/what-is-kubernetes/)开始理解，其中介绍了许多基本概念和术语。
|
||||
|
||||
<!--
|
||||
Kubernetes is quite flexible, and a cluster can be run in a wide variety of places. You can interact with Kubernetes entirely on your own laptop or local development machine with it running within a virtual machine. Kubernetes can also run on virtual machines hosted either locally or in a cloud provider, and you can run a Kubernetes cluster on bare metal.
|
||||
-->
|
||||
Kubernetes 非常灵活，集群可以在各种各样的地方运行。您可以在自己的笔记本电脑或本地开发机器上完全与 Kubernetes 交互，并在虚拟机中运行。Kubernetes 还可以在本地或云提供商托管的虚拟机上运行，并且您也可以在裸机上运行 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
A cluster is made up of one or more [Nodes](/docs/concepts/architecture/nodes/); where a node is a physical or virtual machine.
|
||||
If there is more than one node in your cluster then the nodes are connected with a [cluster network](/docs/concepts/cluster-administration/networking/).
|
||||
Regardless of how many nodes, all Kubernetes clusters generally have the same components, which are described in [Kubernetes Components](/docs/concepts/overview/components).
|
||||
-->
|
||||
集群由一个或多个[节点](/docs/concepts/architecture/nodes/)组成；节点是物理机或虚拟机的位置。
|
||||
如果集群中有多个节点，则节点将与[集群网络](/docs/concepts/cluster-administration/networking/)连接。
|
||||
无论有多少个节点，所有 Kubernetes 集群通常具有相同的组件，这些组件在[Kubernetes 组件](/docs/concepts/overview/components)中有所描述。
|
||||
|
||||
|
||||
<!--
|
||||
## Learn about Kubernetes basics
|
||||
-->
|
||||
## 了解 Kubernetes 基础知识
|
||||
|
||||
<!--
|
||||
A good way to become familiar with how to manage and operate a Kubernetes cluster is by setting one up.
|
||||
One of the most compact ways to experiment with a cluster is [Installing and using Minikube](/docs/tasks/tools/install-minikube/).
|
||||
Minikube is a command line tool for setting up and running a single-node cluster within a virtual machine on your local laptop or development computer. Minikube is even available through your browser at the [Katacoda Kubernetes Playground](https://www.katacoda.com/courses/kubernetes/playground).
|
||||
Katacoda provides a browser-based connection to a single-node cluster, using minikube behind the scenes, to support a number of tutorials to explore Kubernetes. You can also leverage the web-based [Play with Kubernetes](http://labs.play-with-k8s.com/) to the same ends - a temporary cluster to play with on the web.
|
||||
-->
|
||||
一个熟悉如果管理和操作 Kubernetes 集群的好方法就是设置一个。
|
||||
实验集群最紧凑的方法之一是[安装和使用 Minikube](/docs/tasks/tools/install-minikube/)。
|
||||
Minikube 是一个命令行工具，用于在笔记本电脑或开发计算机上的虚拟机中设置和运行单节点集群。甚至可以通过[Katacoda Kubernetes Playground](https://www.katacoda.com/courses/kubernetes/playground)的浏览器获取 Minikube。
|
||||
Katacoda 提供一个基于浏览器的连接到单节点集群，在幕后使用 minikube，支持一些教程来探索 Kubernetes。您还可以利用基于网络的[Play with Kubernetes](http://labs.play-with-k8s.com/)来实现相同目的——在网络上使用的临时集群。
|
||||
|
||||
<!--
|
||||
You interact with Kubernetes either through a dashboard, an API, or using a command-line tool (such as `kubectl`) that interacts with the Kubernetes API.
|
||||
Be familiar with [Organizing Cluster Access](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) by using configuration files.
|
||||
The Kubernetes API exposes a number of resources that provide the building blocks and abstractions that are used to run software on Kubernetes.
|
||||
Learn more about these resources at [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects).
|
||||
These resources are covered in a number of articles within the Kubernetes documentation.
|
||||
-->
|
||||
您可以通过 dashboard，API 或者使用命令行工具（例如`kubectl`）与 Kubernetes API 进行交互。
|
||||
通过使用配置文件熟悉[组织群集访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 。
|
||||
Kubernetes API 公开了许多资源，这些资源提供了在 Kubernetes 上运行软件的构建块和抽象。
|
||||
在[Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects)中了解有关这些资源的更多信息。
|
||||
Kubernetes 文档中的许多文章都涵盖了这些资源。
|
||||
|
||||
<!--
|
||||
* [Pod Overview](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployments](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [Garbage Collection](/docs/concepts/workloads/controllers/garbage-collection/)
|
||||
* [Container Images](/docs/concepts/containers/images/)
|
||||
* [Container Environment Variables](/docs/concepts/containers/container-environment-variables/)
|
||||
* [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
* [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
* [Namespaces Walkthrough](/docs/tasks/administer-cluster/namespaces-walkthrough/)
|
||||
* [Services](/docs/concepts/services-networking/service/)
|
||||
* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* [Secrets](/docs/concepts/configuration/secret/)
|
||||
-->
|
||||
* [Pod Overview](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployments](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [垃圾收集](/docs/concepts/workloads/controllers/garbage-collection/)
|
||||
* [容器镜像](/docs/concepts/containers/images/)
|
||||
* [容器环境变量](/docs/concepts/containers/container-environment-variables/)
|
||||
* [标签和选择器](/docs/concepts/overview/working-with-objects/labels/)
|
||||
* [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
* [Namespaces 演练](/docs/tasks/administer-cluster/namespaces-walkthrough/)
|
||||
* [服务](/docs/concepts/services-networking/service/)
|
||||
* [注解](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* [Secrets](/docs/concepts/configuration/secret/)
|
||||
|
||||
<!--
|
||||
As a cluster operator you may not need to use all these resources, although you should be familiar with them to understand how the cluster is being used.
|
||||
There are a number of additional resources that you should be aware of, some listed under [Intermediate Resources](/docs/user-journeys/users/cluster-operator/intermediate#section-1).
|
||||
You should also be familiar with [how to manage kubernetes resources](/docs/concepts/cluster-administration/manage-deployment/)
|
||||
and [supported versions and version skew between cluster components](/docs/setup/release/version-skew-policy/).
|
||||
-->
|
||||
作为集群运算符，您可能不需要使用所有这些资源，尽管您应该熟悉它们以了解集群的使用方式。
|
||||
您应该了解许多其他资源，其中一些列在[中间资源](/docs/user-journeys/users/cluster-operator/intermediate#section-1)下。
|
||||
您还应该熟悉[如何管理 kubernetes 资源](/docs/concepts/cluster-administration/manage-deployment/)
|
||||
和[支持的版本和集群组件之间的版本偏差](/docs/setup/release/version-skew-policy/)。
|
||||
|
||||
<!--
|
||||
## Get information about your cluster
|
||||
-->
|
||||
## 获取有关集群的信息
|
||||
|
||||
<!--
|
||||
You can [access clusters using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/).
|
||||
If you are not already familiar with how to do this, you can review the [introductory tutorial](/docs/tutorials/kubernetes-basics/explore-intro/).
|
||||
Using `kubectl`, you can retrieve information about your Kubernetes cluster very quickly.
|
||||
To get basic information about the nodes in your cluster run the command `kubectl get nodes`.
|
||||
You can get more detailed information for the same nodes with the command `kubectl describe nodes`.
|
||||
You can see the status of the core of kubernetes with the command `kubectl get componentstatuses`.
|
||||
-->
|
||||
您可以[使用 Kubernetes API 访问集群](/docs/tasks/administer-cluster/access-cluster-api/)。
|
||||
如果您还不熟悉如何执行此操作，可以查看[入门教程](/docs/tutorials/kubernetes-basics/explore-intro/)。
|
||||
使用`kubectl`，您可以快速检索有关 Kubernetes 集群的信息。
|
||||
要获取有关集群中节点的基本信息，请运行命令`kubectl get nodes`。
|
||||
您可以使用命令`kubectl describe nodes`获取相同节点的更多详细信息。
|
||||
您可以使用命令`kubectl get componentstatuses`查看 kubernetes 的核心状态。
|
||||
|
||||
<!--
|
||||
Some additional resources for getting information about your cluster and how it is operating include:
|
||||
|
||||
* [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* [Resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
|
||||
* [Metrics](/docs/concepts/cluster-administration/controller-metrics/)
|
||||
-->
|
||||
用于获取有关集群及其运行方式信息的一些其他资源包括：
|
||||
|
||||
* [用于监控计算，存储和网络资源的工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* [资源指标管道](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
|
||||
* [指标](/docs/concepts/cluster-administration/controller-metrics/)
|
||||
|
||||
<!--
|
||||
## Explore additional resources
|
||||
-->
|
||||
## 探索其他资源
|
||||
|
||||
<!--
|
||||
### Tutorials
|
||||
-->
|
||||
### 教程
|
||||
|
||||
<!--
|
||||
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)
|
||||
* [Configuring Redis with a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* Stateless Applications
|
||||
* [Deploying PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [Expose an External IP address to access an application](/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
-->
|
||||
* [Kubernetes 基础](/docs/tutorials/kubernetes-basics/)
|
||||
* [使用 ConfigMap 配置 Redis](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* 无国籍申请
|
||||
* [使用 Redis 部署 PHP 留言薄](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [公开外部 IP 地址以访问应用程序](/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,221 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: 中级
|
||||
track: "USERS > CLUSTER OPERATOR > INTERMEDIATE"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Intermediate
|
||||
track: "USERS > CLUSTER OPERATOR > INTERMEDIATE"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
If you are a cluster operator looking to expand your grasp of Kubernetes, this page and its linked topics extend the information provided on the [foundational cluster operator page](/docs/user-journeys/users/cluster-operator/foundational). From this page you can get information on key Kubernetes tasks needed to manage a complete production cluster.
|
||||
-->
|
||||
如果您是一个集群操作者，希望扩展对 Kubernetes 的理解，本页及其相关主题会扩展[基础集群操作者页面](/docs/user-journeys/users/cluster-operator/foundational)上提供的信息。在本页中，你可以获得如何管理一个完整生产集群的关键 Kubernetes 任务的信息。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
<!--
|
||||
## Work with ingress, networking, storage, and workloads
|
||||
-->
|
||||
## 使用 ingress，网络，存储和工作负载
|
||||
|
||||
<!--
|
||||
Introductions to Kubernetes typically discuss simple stateless applications. As you move into more complex development, testing, and production environments, you need to consider more complex cases:
|
||||
-->
|
||||
Kubernetes 的介绍通常讨论简单的无状态应用程序。当您进入更复杂的开发，测试和生产环境时，您需要考虑更复杂的情况：
|
||||
|
||||
<!--
|
||||
Communication: Ingress and Networking
|
||||
|
||||
* [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
-->
|
||||
通信： Ingress 和网络
|
||||
|
||||
* [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
|
||||
<!--
|
||||
Storage: Volumes and PersistentVolumes
|
||||
|
||||
* [Volumes](/docs/concepts/storage/volumes/)
|
||||
* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
-->
|
||||
存储：Volumes 和 PersistentVolumes
|
||||
|
||||
* [Volumes](/docs/concepts/storage/volumes/)
|
||||
* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
<!--
|
||||
Workloads
|
||||
|
||||
* [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [Stateful Sets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
* [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
-->
|
||||
工作负载
|
||||
|
||||
* [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [Stateful Sets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
* [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
<!--
|
||||
Pods
|
||||
|
||||
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
* [Init Containers](/docs/concepts/workloads/pods/init-containers/)
|
||||
* [Pod Presets](/docs/concepts/workloads/pods/podpreset/)
|
||||
* [Container Lifecycle Hooks](/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
-->
|
||||
Pods
|
||||
|
||||
* [Pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
* [初始化容器](/docs/concepts/workloads/pods/init-containers/)
|
||||
* [Pod 预置](/docs/concepts/workloads/pods/podpreset/)
|
||||
* [容器生命周期挂钩](/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
|
||||
<!--
|
||||
And how Pods work with scheduling, priority, disruptions:
|
||||
|
||||
* [Taints and Tolerations](/docs/concepts/configuration/taint-and-toleration/)
|
||||
* [Pods and Priority](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [Disruptions](/docs/concepts/workloads/pods/disruptions/)
|
||||
* [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)
|
||||
* [Managing Compute Resources for Containers](/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
* [Configuration Best Practices](/docs/concepts/configuration/overview/)
|
||||
-->
|
||||
以及 Pod 如何处理调度，优先级，中断：
|
||||
|
||||
* [污点和容忍度](/docs/concepts/configuration/taint-and-toleration/)
|
||||
* [Pod 和优先级](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [中断](/docs/concepts/workloads/pods/disruptions/)
|
||||
* [分配 Pod 到工作节点](/docs/concepts/configuration/assign-pod-node/)
|
||||
* [管理容器的计算资源](/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
* [配置最佳实践](/docs/concepts/configuration/overview/)
|
||||
|
||||
<!--
|
||||
## Implement security best practices
|
||||
-->
|
||||
## 实施安全最佳实践
|
||||
|
||||
<!--
|
||||
Securing your cluster includes work beyond the scope of Kubernetes itself.
|
||||
|
||||
In Kubernetes, you configure access control:
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/)
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/)
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
-->
|
||||
保护集群的工作超出了 Kubernetes 本身的范围。
|
||||
|
||||
在Kubernetes中，你可以配置访问的控制：
|
||||
|
||||
* [控制对 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)
|
||||
* [身份认证](/docs/reference/access-authn-authz/authentication/)
|
||||
* [使用准入控制](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
|
||||
<!--
|
||||
You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.
|
||||
|
||||
* [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
|
||||
* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/)
|
||||
|
||||
You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).
|
||||
-->
|
||||
您还可以配置授权。也就是说，您不仅可以决定用户和服务如何向 API 服务器进行身份认证，或者确定他们是否可以访问，还可以决定他们有权访问哪些资源。基于角色的访问控制（RBAC）是控制对 Kubernetes 资源授权的推荐机制。其他授权模式可以用于更具体的使用场景。
|
||||
|
||||
* [授权概述](/docs/reference/access-authn-authz/authorization/)
|
||||
* [使用 RBAC 授权](/docs/reference/access-authn-authz/rbac/)
|
||||
|
||||
您应该创建 Secrets 来保存敏感数据，例如密码，令牌或者密钥。但请注意，Secret 可以提供的保护存在限制。请参阅 [Secrets 文档中的风险部分](/docs/concepts/configuration/secret/#risks)。
|
||||
|
||||
<!-- TODO: Other security content? -->
|
||||
|
||||
<!--
|
||||
## Implement custom logging and monitoring
|
||||
-->
|
||||
## 实现自定义日志和监控
|
||||
|
||||
<!--
|
||||
Monitoring the health and state of your cluster is important. Collecting metrics, logging, and providing access to that information are common needs. Kubernetes provides some basic logging structure, and you may want to use additional tools to help aggregate and analyze log data.
|
||||
-->
|
||||
监控集群的健康和状态非常重要。收集指标，日志，并提供对这些信息的访问是常见的需求。Kubernetes 提供了一些基本的日志记录结构，您可能需要使用其他工具来帮助汇总和分析日志数据。
|
||||
|
||||
<!--
|
||||
Start with the [basics on Kubernetes logging](/docs/concepts/cluster-administration/logging/) to understand how containers do logging and common patterns. Cluster operators often want to add something to gather and aggregate those logs. See the following topics:
|
||||
|
||||
* [Logging Using Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
|
||||
* [Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
-->
|
||||
从 [Kubernetes 日志基础知识](/docs/concepts/cluster-administration/logging/) 开始，了解容器如何执行日志记录和常见模式。集群运维人员通常希望添加一些东西来收集和聚合这些日志。请参阅以下主题：
|
||||
|
||||
* [使用 Elasticsearch 和 Kibana 记录日志](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
|
||||
* [使用 Stackdriver 记录日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
|
||||
<!--
|
||||
Like log aggregation, many clusters utilize additional software to help capture metrics and display them. There is an overview of tools at [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/).
|
||||
Kubernetes also supports a [resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) which can be used by Horizontal Pod Autoscaler with custom metrics.
|
||||
-->
|
||||
与日志聚合一样，许多集群使用其他软件来帮助捕获 metrics 并显示它们。这里是相关工具的概述：[用于监视计算，存储和网络资源的工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)。Kubernetes 还支持[资源指标管道](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)，还可以在水平 Pod 自动伸缩器（Horizontal Pod Autoscaler）中使用自定义 metrics。
|
||||
|
||||
<!--
|
||||
[Prometheus](https://prometheus.io/), another {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project, is a common choice to support capture and temporary collection of metrics. There are several options for installing Prometheus, including using the [stable/prometheus](https://github.com/kubernetes/charts/tree/master/stable/prometheus) [helm](https://helm.sh/) chart, and CoreOS provides a [prometheus operator](https://github.com/coreos/prometheus-operator) and [kube-prometheus](https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus), which adds on Grafana dashboards and common configurations.
|
||||
-->
|
||||
[Prometheus](https://prometheus.io/), 是另一个 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 项目, 它是支持捕获和临时收集指标的常用选择。安装 Prometheus 有几种方式，包括使用 [stable/prometheus](https://github.com/kubernetes/charts/tree/master/stable/prometheus) [helm](https://helm.sh/) chart, and CoreOS provides a [prometheus operator](https://github.com/coreos/prometheus-operator) and [kube-prometheus](https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus), 增加了 Grafana 仪表板和常用配置。
|
||||
|
||||
<!--
|
||||
A common configuration on [Minikube](https://github.com/kubernetes/minikube) and some Kubernetes clusters uses [Heapster](https://github.com/kubernetes/heapster)
|
||||
[along with InfluxDB and Grafana](https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md).
|
||||
There is a [walkthrough of how to install this configuration in your cluster](https://blog.kublr.com/how-to-utilize-the-heapster-influxdb-grafana-stack-in-kubernetes-for-monitoring-pods-4a553f4d36c9).
|
||||
As of Kubernetes 1.11, Heapster is deprecated, as per [sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation). See [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/) for more information alternatives.
|
||||
-->
|
||||
[Minikube](https://github.com/kubernetes/minikube) 和某些 Kubernetes 集群的通常配置是[与 InfluxDB 和 Grafana 一起](https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md)使用[Heapster](https://github.com/kubernetes/heapster)。这里有一个[如何在集群中安装这个配置的参考](https://blog.kublr.com/how-to-utilize-the-heapster-influxdb-grafana-stack-in-kubernetes-for-monitoring-pods-4a553f4d36c9)。截止 Kubernetes 1.11，根据[sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation)，Heapster 已经弃用。更多信息，请参阅 [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/) 。
|
||||
|
||||
<!--
|
||||
Hosted monitoring, APM, or data analytics services such as [Datadog](https://docs.datadoghq.com/integrations/kubernetes/) or [Instana](https://www.instana.com/supported-integrations/kubernetes-monitoring/) also offer Kubernetes integration.
|
||||
-->
|
||||
托管监控，APM 或数据分析服务，例如[Datadog](https://docs.datadoghq.com/integrations/kubernetes/) 或者 [Instana](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 也提供 Kubernetes 集成。
|
||||
|
||||
<!--
|
||||
## Additional resources
|
||||
-->
|
||||
## 其他资源
|
||||
|
||||
<!--
|
||||
Cluster Administration:
|
||||
|
||||
* [Troubleshoot Clusters](/docs/tasks/debug-application-cluster/debug-cluster/)
|
||||
* [Debug Pods and Replication Controllers](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)
|
||||
* [Debug Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
* [Debug Stateful Sets](/docs/tasks/debug-application-cluster/debug-stateful-set/)
|
||||
* [Debug Applications](/docs/tasks/debug-application-cluster/debug-application/)
|
||||
* [Using explorer to investigate your cluster](https://github.com/kubernetes/examples/blob/master/staging/explorer/README.md)
|
||||
-->
|
||||
集群管理：
|
||||
|
||||
* [集群故障排除](/docs/tasks/debug-application-cluster/debug-cluster/)
|
||||
* [调试 Pod 和 Replication Controller](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)
|
||||
* [调试初始化容器](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
* [调试 Stateful Set](/docs/tasks/debug-application-cluster/debug-stateful-set/)
|
||||
* [调试应用程序](/docs/tasks/debug-application-cluster/debug-application/)
|
||||
* [使用资源管理器来调查您的集群](https://github.com/kubernetes/examples/blob/master/staging/explorer/README.md)
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user