zh-trans: merge zh content from release-1.16-temporary into release-1.16 (#18216)
* Update http-proxy-access-api.md (#16932) * Update coredns.md (#16930) * zh-trans:/docs/docs/concepts/workloads/pods/ephemeral-containers.md (#16948) * update zh-trans of define-environment-variable-container.md (#16999) Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> * update chinese docs (#16985) * Fix ordered list (#16988) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md (#16951) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * Remove redundant symbol and fix some ordered list (#17000) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * update-zh-translation/docs/reference/setup-tools/kubeadm/kubeadm-init.md (#16997) * update zh translation kubeadm-reset.md kubeadm-upgrade.md (#16992) * Create kubeadm_join_phase_control-plane-join_all.md (#16987) * Update web-ui-dashboard.md (#16976) * update format problem (#16956) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/docs/concepts/storage/volume-pvc-datasource.md (#17021) * update zh translation /docs/reference/access-authn-authz/webhook.md (#16860) * fix confict update zh translation (#16863) * zh-trans:/docs/concepts/workloads/pods/disruptions.md (#16983) * zh-trans:/docs/concepts/workloads/pods/disruptions.md * Update content/zh/docs/concepts/workloads/pods/disruptions.md Co-Authored-By: Qiming <tengqim@cn.ibm.com> * update zh translation content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md (#17006) * Update RC's link (#16935) Signed-off-by: PingWang <wang.ping5@zte.com.cn> Update Signed-off-by: PingWang <wang.ping5@zte.com.cn> update the style Signed-off-by: PingWang <wang.ping5@zte.com.cn> * Update the links for /zh/docs/setup (#16938) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/docs/concepts/services-networking/dual-stack.md (#17024) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm.md (#17036) * update zh tanslation /reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md (#17037) * update zh translation -/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md (#17038) * update zh translation /docs/contribute/participating.md (#17040) * Fix cri-o's links to match English docs (#16936) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * update zh translation content/zh/docs/reference/kubectl/jsonpath.md (#16862) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md (#17049) * update Unkown -> Unknown (#17062) * zh-translation:high-availability.md (#16960) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update Runnning -> Running (#17061) * zh-trans:/docs/docs/concepts/storage/volume-snapshots.md (#17054) * update zh transation /docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md (#17060) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md (#17052) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#17055) * update zh translation update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md (#17048) * update zh-translation:ha-topology.md (#17099) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md (#17093) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md (#17083) * Add Chinese translation for scheduler-perf-tuning (#17087) Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> * zh trans content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md (#17121) * update zh trans content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md (#17122) * zh-translation:content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md (#17105) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md (#17091) * update zh trans /docs/setup/learning-environment/minikube.md (#17143) * update zh trans /zh/docs/reference/_index.md (#17146) * update zh trans /docs/tasks/access-application-cluster/port-forward-access-application-cluster.md (#17134) * update zh translation 20191020-update-zh-translation-/docs/contribute/localization.md (#17046) * update zh trans /docs/reference/using-api/client-libraries.md (#17144) * update zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md (#17145) * update zh /docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md (#17131) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md (#17081) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md (#17078) * add zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md (#17076) * update zh trans content/zh/docs/contribute/generate-ref-docs/kubectl.md (#17165) * update zh translation /reference/command-line-tools-reference/kube-proxy.md (#17107) * zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-const… (#16955) * zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-constraints.md * Update pod-topology-spread-constraints.md * zh-trans:/docs/concepts/configuration/scheduling-framework.md (#17088) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md (#17079) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md (#17077) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md (#17075) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md (#17050) * update zh trans /docs/concepts/overview/working-with-objects/namespaces.md (#17205) * update zh trans /docs/concepts/overview/what-is-kubernetes.md (#17203) * pr_release-1.16_crictl (#17201) * update zh docs/tasks/administer-cluster/dns-debugging-resolution.md (#17186) * update zh trans content/zh/docs/concepts/overview/working-with-objects/field-selectors.md (#17191) * translate configure_upgrade_etcd (#17160) * translate kubeadm_upgrade_apply (#17159) * update zh /docs/tasks/job/coarse-parallel-processing-work-queue.md (#17155) * translate docs/setup/release/version-skew-policy.md to Chinese (#17142) * update zh trans content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md (#17124) * zh-trans replace the wrong translation (#17103) zh-trans replace the wrong translation * Merged 1.14~1.16 changes (#17117) * zh-trans:/docs/concepts/configuration/assign-pod-node.md (#17129) * update zh trans /docs/contribute/generate-ref-docs/kubernetes-api.md (#17161) * pr_release-1.16_basic-ss (#17169) * Add zh-trans of assign-cpu-resource.md (#17063) Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> * update zh trans content/zh/docs/concepts/overview/working-with-objects/common-labels.md (#17193) * update zh translation /docs/contribute/intermediate.md (#17041) * zh-trans:docs/setup/production-environment/turnkey/tencent.md (#17207) * pr_release-1.16_mysql-wordpress-pv (#17202) * pr_release-1.16_reconfig-kubelet (#17200) * zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completio… (#17020) * zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completion.md * Update jobs-run-completion.md * Update jobs-run-completion.md * update zh trans content/zh/docs/concepts/extend-kubernetes/extend-cluster.md (#17212) * update zh trans content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md (#17213) * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md (#17220) kubeadm_join_phase_control-plane-prepare_download-certs.md * add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md and /reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md (#17219) * update zh trans content/zh/docs/concepts/containers/images.md (#17216) * ZH-trans: add _index.md (#17214) * ZH-trans: add _index.md * add _index.md file * add _index.md files * pr_release-1.16_crd-versions (#17198) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md (#17092) * zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images.md (#17094) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md (#17222) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md (#17221) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md (#17223) * 013 /docs/concepts/services networking/ingress.md (#17185) * x * update zh trans content/zh/docs/concepts/services-networking/ingress.md * zh-trans:/reference/setup-tools/kubeadm/generated/kubeadm_completion.md and kubeadm_config.md (#17097) * add zh trans reference/glossary/pod-lifecycle (#17226) * update zh-translation document (#17096) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh-translation:setup-ha-etcd-with-kubeadm.md (#17098) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md (#17227) * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md (#17228) * zh-translation:content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md (#17089) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md (#17080) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_config_view.md (#17085) * zh-translation:troubleshooting-kubeadm.md (#17069) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans: docs/concepts/scheduling/kube-scheduler.md (#17067) * Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> * Update kube-scheduler.md * Add Chinese translation for kube-scheduler * Update kube-scheduler.md * Update kube-scheduler.md * Update kube-scheduler.md * translate pods.md and init-containers.md for branch release-1.16 (#17208) * update zh translation /docs/contribute/start.md (#17039) * zh-translation:2017-10-00-Five-Days-Of-Kubernetes-18.md (#17229) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * translate kubeadm-certs.md (#17090) * update the Illegal comment such as : (<！--、<--) (#17266) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md (#17268) * update zh /docs/concepts/architecture/cloud-controller.md (#17263) * update zh /docs/concepts/cluster-administration/logging.md (#17247) * modify the show of zh translation /concepts/overview/what-is-kubernetes.md /reference/setup-tools/kubeadm/generated/kubeadm_init.md /reference/setup-tools/kubeadm/kubeadm-init.md (#17246) * zh-translation:kubeadm_init_phase_control-plane_all.md (#17243) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-translation:kubeadm_join_phase_control-plane-join_etcd.md (#17236) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md (#17230) * add content/zh/docs/reference/glossary/container-runtime.md file fix-up to pass the ci and trans content/zh/docs/reference/glossary/container-runtime.md、content/zh/docs/concepts/overview/components.md (#17211) * zh-translation:mirror-pod.md (#17231) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-translation:kubeadm_init_phase_upload-config.md (#17238) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh /docs/concepts/workloads/pods/pod-overview.md (#17239) * update the format of zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md (#17248) * Create advanced.md (#17256) * Create advanced.md * trans the advanced.md and fix the build bugs * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md (#17269) * zh-translation:kubelet-integration.md (#17272) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * pr_release-1.16_out-of-resource (#17199) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md (#17267) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md (#17271) * pr_release-1.16_ext-admission-ctl (#17196) * update zh translation /docs/contribute/advanced.md (#17042) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md (#17275) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md (#17282) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated… (#17287) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md * Update kubeadm_init_phase_etcd.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17285) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-server.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver.md * Update kubeadm_alpha_kubelet.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md fix-up bad comment kubeadm_alpha_certs_renew.md、kubeadm_alpha_certs_renew_apiserver-etcd-client.md、kubeadm_init_phase_addon_all.md (#17276) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17281) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md * Update kubeadm_init_phase_etcd_local.md * zh trans update-daemon-set.md (#16872) * zh trans update-daemon-set.md * Update update-daemon-set.md * managing-tls-in-a-cluster.md (#16874) * update-api-object-kubectl-patch.md (#16875) * improve the zh trans /kubeadm/generated/kubeadm_init_phase_.* 1 (#17295) * improve the zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_.* (#17294) * modify the zh translation content/zh/docs/reference/setup-tools/kubea… (#17293) * modify the zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_.* * Update kubeadm_alpha.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md (#17280) * add zh /docs/reference/glossary/cgroup.md (#17291) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md (#17288) * improve zh trans of command in /kubeadm/generated/kubeadm_init_phase_.* files (#17297) * improve zh command translation /kubeadm/generated/kubeadm_init_.* files (#17298) * update zh trans in /kubeadm/generated/kubeadm_.* files (#17306) * add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-peer.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md (#17308) * Improve previously translated documents (#17327) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans: docs/setup/production-environment/turnkey/aws.md (#17320) * Update zh.toml * update zh trans /generated/kubeadm_join_phase_.* files (#17301) * Update zh.toml * add zh /docs/reference/glossary/pod-disruption-budget.md (#17344) * pr_release-1.16_config-aggregation-layer (#17197) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_controller-manager.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_scheduler.conf.md (#17390) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md (#17381) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md (#17380) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md (#17383) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_certificate-key.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md (#17385) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_admin.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md (#17387) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_front-proxy-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md (#17384) * add zh /docs/reference/glossary/limitrange.md (#17324) * add zh trans content/zh/docs/setup/best-practices/cluster-large.md (#17321) * add zh trans content/zh/docs/setup/best-practices/cluster-large.md * Update cluster-large.md * add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/do… (#17403) * add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md * Update kubeadm_init_phase_certs_etcd-server.md * add zh /docs/reference/glossary/cluster-operations.md (#17300) * add zh /docs/reference/glossary/applications.md (#17419) * update zh trans kubelet (#17379) * update zh trans kubelet * update the file according to feedback from reviewer tengqm * update 1000-1757 lines * update the advice zh trans * add zh /docs/reference/glossary/static-pod.md (#17418) * add zh /docs/reference/glossary/preemption.md (#17423) * add zh /docs/reference/glossary/pod-priority.md (#17421) * add zh /docs/reference/glossary/control-plane.md (#17425) * add zh /docs/reference/glossary/cluster-infrastructure.md (#17424) * pr_release-1.16_api-overview (#17444) * pr_release-1.16_daemonset (#17435) * pr_release-1.16_gc (#17445) * pr_release-1.16_qos-class (#17442) * fix QoS Class to QoS 类 (#17464) * pr_release-1.16-abac (#17427) * zh-trans:docs/setup/production-environment/turnkey/alibaba-cloud.md (#17345) * pr_release-1.16_endpoint-slice (#17468) * pr_release-1.16_taint (#17469) * pr_release-1.16_operator-pattern (#17467) * pr_release-1.16_ss (#17433) * pr_release-1.16_admission-controller (#17440) * pr_release-1.16_containerd (#17441) * pr_release-1.16_app-container (#17466) * add zh-trans content/zh/docs/setup/_index.md、content/zh/docs/setup/release/_index.md (#17503) * pr-release-1.16_enabling-endpoint-slices (#17504) * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495) * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md、content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md * add content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md * pr-release-1.16_logging (#17491) * pr-release-1.16_cri (#17486) * add zh-trans:docs/setup/production-environment/turnkey/azure.md (#17482) * pattern translate into 模式 (#17485) * fix zk affinity description in zh trans (#17393) * pr-release-1.16_ephemeral-container (#17487) * pr-release-1.16_data-plane (#17489) * pr-release-1.16_cncf (#17490) * zh-trans add content\zh\docs\tools\install-minikube.md (#16920) * zh-trans add content\zh\docs\tools\install-minikube.md * zh-trans update content\zh\docs\tools\install-minikube.md * zh-trans update content\zh\docs\tools\install-minikube.md * update \docs\tasks\tools\install-minikube.md * update docs\concepts\workloads\controllers\deployment.md * update deployment.md * pr-release-1.16_extensions (#17492) * pr-release-1.16_toleration (#17493) * Revert "update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495)" (#17521) This reverts commit 1134c14e0a39bdc3d1a920ac9797139a6dcccf4b. * motidy extensions in content/zh/docs/reference/glossary/extensions (#17524) * motidy toleration in content/zh/docs/reference/glossary/toleration.md (#17523) * motidy toleration in content/zh/docs/reference/glossary/toleration.md * Update toleration.md * improve zh-trans in content/zh/docs/setup/_index.md (#17526) * add zh-trans /zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md (#17527) * Broken Link (#17546) Issue available at https://kubernetes.io/zh/docs/concepts/containers/runtime-class/ and introduced by original English documentation (see #17543) * Update trans kubeadm_upgrade_plan.md (#17395) * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * update zh-trans of define-command-argument-container.md (#17022) Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update zh-trans of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> Add back the Original English Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update title of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update table title and reference Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update reference of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> * ZH-trans: fix multiple jump links and update files (#17603) * ZH-trans: fix multiple jump links and update files * Update _index.html * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md (#17528) * update zh trans /doc/concepts/architecture/nodes.md (#17617) * update zh trans content/zh/docs/concepts/architecture/nodes.md * fix-up content/zh/docs/concepts/architecture/nodes.md * add zh-trans /docs/setup/release/notes.md (#17519) * add zh-trans /docs/setup/release/notes.md update-750 * fix-up 1575 line and udpate 2483 line * update to line 2980 * update to the last line 3160 * add zh-trans:docs/setup/production-environment/turnkey/icp.md (#17568) * zh-trans: /docs/setup/production-environment/container-runtimes.md (#17646) * zh-trs:container-runtimes.md Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * Update container-runtimes.md * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese (#17791) * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Sorry, wrong commit, roll back... * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Create trans kubeadm_upgrade_diff.md (#17392) * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Create _index.md (#17831) * zh-trans zh-trans-/docs/reference/command-line-tools-reference/feature-gates.md (#17658) * Update volume-snapshots.md (#17829) * Update volume-snapshots.md * Update volume-snapshots.md * Update volume-snapshots.md * Create ovirt.md (#17849) * Create ovirt.md * Update ovirt.md * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese (#17761) * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Sorry, wrong commit, roll back... * Update translation after tengqm's review. * Update cloud-providers.md * Update dual-stack.md (#17836) * Update dual-stack.md * Update dual-stack.md * Update dual-stack.md * Update dual-stack.md * Create validate-dual-stack.md (#17833) * Create validate-dual-stack.md * Update validate-dual-stack.md * translation content/zh/docs/reference/setup-tools/kubeadm/ kubeadm-join-phase、kubeadm-reset-phase (#17881) * zh-trans content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md (#17882) * Chinese translation /docs/tasks/administer-cluster/highly-available-master.md (#17884) * Chinese translation /docs/tasks/administer-cluster/highly-available-master.md * Apply suggestions from code review Co-Authored-By: Qiming <tengqim@cn.ibm.com> * Fix format issue (#17921) * Create topology-manager.md (#17901) * Create topology-manager.md * Update topology-manager.md * add zh-trans:docs/setup/production-environment/windows/user-guide-windows-containers.md (#17876) * Update pod-overhead.md (#17931) * Update scheduler-perf-tuning.md (#17934) * Create dcos.md (#17932) * Create dcos.md * Update dcos.md * Update object-management.md (#17937) * zh-translation content/zh/docs/setup/production-environment/tools/kops.md (#17991) * Create imperative-config.md (#17956) * Create imperative-config.md * Update imperative-config.md * Create self-hosting.md (#17950) * Create resource-bin-packing.md (#17935) * Create nodelocaldns.md (#17938) * Update config.toml(release-1.16) for 1.17 (#18025) * Update config.toml(release-1.16) for 1.17 * Update config.toml * Remove ru language * fix shotcode mismatch Co-authored-by: zhangx501 <zhang0000xun@gmail.com> Co-authored-by: ZhongliangXiong <xiong.zhongliang@zte.com.cn> Co-authored-by: Yixiang Wang <wang.yixiang@zte.com.cn> Co-authored-by: li mengyang <hwdef97@gmail.com> Co-authored-by: PingWang <wang.ping5@zte.com.cn> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: Sophy417 <53026875+Sophy417@users.noreply.github.com> Co-authored-by: Qiming <tengqim@cn.ibm.com> Co-authored-by: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com> Co-authored-by: senwang <wang.sen2@zte.com.cn> Co-authored-by: lichuqiang <lichuqiang@huawei.com> Co-authored-by: lpf7551321 <liupengfei20@huawei.com> Co-authored-by: Hongcai Ren <renhongcai@huawei.com> Co-authored-by: jiajie <jiaj12@chinaunicom.cn> Co-authored-by: heqg <56527988+heqg@users.noreply.github.com> Co-authored-by: IreneByron <zhangbingqing7@huawei.com> Co-authored-by: LiuDui <1693291525@qq.com> Co-authored-by: Wang Bing <wangbing.adam@gmail.com> Co-authored-by: Damini Satya <daminisatya@gmail.com> Co-authored-by: liufangwai <liufangwai@huawei.com> Co-authored-by: wangcong <congfairy2536@gmail.com> Co-authored-by: XuefeiWang2 <wangxuefei2@huawei.com> Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com> Co-authored-by: Ziqiu Zhu <zzqshu@126.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com> Co-authored-by: jiazxjason <52809535+jiazxjason@users.noreply.github.com> Co-authored-by: Coffey Gao <coffiney@qq.com> Co-authored-by: Bingshen Wang <bingshen.wbs@alibaba-inc.com>
This commit is contained in:
SataQiu
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
6be3e1414d
commit
0f2bd2871b
@@ -1,12 +1,11 @@
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,533 @@
|
||||
---
|
||||
title: 干扰
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
- foxish
|
||||
- davidopp
|
||||
title: Disruptions
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
This guide is for application owners who want to build
|
||||
highly available applications, and thus need to understand
|
||||
what types of Disruptions can happen to Pods.
|
||||
-->
|
||||
|
||||
本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 pod 上的干扰类型。
|
||||
|
||||
<!--
|
||||
It is also for Cluster Administrators who want to perform automated
|
||||
cluster actions, like upgrading and autoscaling clusters.
|
||||
-->
|
||||
|
||||
文档同样适用于想要执行自动化集群操作（例如升级和自动扩展集群）的集群管理员。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Voluntary and Involuntary Disruptions
|
||||
-->
|
||||
|
||||
## 自愿干扰和非自愿干扰
|
||||
|
||||
<!--
|
||||
Pods do not disappear until someone (a person or a controller) destroys them, or
|
||||
there is an unavoidable hardware or system software error.
|
||||
-->
|
||||
|
||||
Pod 不会消失，除非有人（用户或控制器）将其销毁，或者出现了不可避免的硬件或软件系统错误。
|
||||
|
||||
<!--
|
||||
We call these unavoidable cases *involuntary disruptions* to
|
||||
an application. Examples are:
|
||||
-->
|
||||
|
||||
我们把这些不可避免的情况称为应用的*非自愿干扰*。例如：
|
||||
|
||||
<!--
|
||||
- a hardware failure of the physical machine backing the node
|
||||
- cluster administrator deletes VM (instance) by mistake
|
||||
- cloud provider or hypervisor failure makes VM disappear
|
||||
- a kernel panic
|
||||
- the node disappears from the cluster due to cluster network partition
|
||||
- eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/).
|
||||
-->
|
||||
|
||||
- 节点下层物理机的硬件故障
|
||||
- 集群管理员错误地删除虚拟机（实例）
|
||||
- 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
|
||||
- 内核错误
|
||||
- 节点由于集群网络隔离从集群中消失
|
||||
- 由于节点[资源不足](/docs/tasks/administer-cluster/out-of-resource/)导致 pod 被驱逐。
|
||||
|
||||
<!--
|
||||
Except for the out-of-resources condition, all these conditions
|
||||
should be familiar to most users; they are not specific
|
||||
to Kubernetes.
|
||||
-->
|
||||
|
||||
除了资源不足的情况，大多数用户应该都熟悉这些情况；它们不是特定于 Kubernetes 的。
|
||||
|
||||
<!--
|
||||
We call other cases *voluntary disruptions*. These include both
|
||||
actions initiated by the application owner and those initiated by a Cluster
|
||||
Administrator. Typical application owner actions include:
|
||||
-->
|
||||
|
||||
我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的
|
||||
作包括：
|
||||
|
||||
<!--
|
||||
- deleting the deployment or other controller that manages the pod
|
||||
- updating a deployment's pod template causing a restart
|
||||
- directly deleting a pod (e.g. by accident)
|
||||
-->
|
||||
|
||||
- 删除 deployment 或其他管理 pod 的控制器
|
||||
- 更新了 deployment 的 pod 模板导致 pod 重启
|
||||
- 直接删除 pod（例如，因为误操作）
|
||||
|
||||
<!--
|
||||
Cluster Administrator actions include:
|
||||
-->
|
||||
|
||||
集群管理员操作包括：
|
||||
|
||||
<!--
|
||||
- [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade.
|
||||
- Draining a node from a cluster to scale the cluster down (learn about
|
||||
[Cluster Autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)
|
||||
).
|
||||
- Removing a pod from a node to permit something else to fit on that node.
|
||||
-->
|
||||
|
||||
- [排空（drain）节点](/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
|
||||
- 从集群中排空节点以缩小集群（了解[集群自动扩缩](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)）。
|
||||
- 从节点中移除一个 pod，以允许其他 pod 使用该节点。
|
||||
|
||||
<!--
|
||||
These actions might be taken directly by the cluster administrator, or by automation
|
||||
run by the cluster administrator, or by your cluster hosting provider.
|
||||
-->
|
||||
|
||||
这些操作可能由集群管理员直接执行，也可能由集群管理员所使用的自动化工具执行，或者由集群托管提供商自动执行。
|
||||
|
||||
<!--
|
||||
Ask your cluster administrator or consult your cloud provider or distribution documentation
|
||||
to determine if any sources of voluntary disruptions are enabled for your cluster.
|
||||
If none are enabled, you can skip creating Pod Disruption Budgets.
|
||||
-->
|
||||
|
||||
咨询集群管理员或联系云提供商，或者查询发布文档，以确定是否为集群启用了任何资源干扰源。如果没有启用，可以不用创建 Pod Disruption Budgets（Pod 干扰预算）
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
<!--
|
||||
Not all voluntary disruptions are constrained by Pod Disruption Budgets. For example,
|
||||
deleting deployments or pods bypasses Pod Disruption Budgets.
|
||||
-->
|
||||
|
||||
并非所有的自愿干扰都会受到 pod 干扰预算的限制。例如，删除 deployment 或 pod 的删除操作就会跳过 pod 干扰预算检查。
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
## Dealing with Disruptions
|
||||
-->
|
||||
|
||||
## 处理干扰
|
||||
|
||||
<!--
|
||||
Here are some ways to mitigate involuntary disruptions:
|
||||
-->
|
||||
|
||||
以下是减轻非自愿干扰的一些方法：
|
||||
|
||||
<!--
|
||||
- Ensure your pod [requests the resources](/docs/tasks/configure-pod-container/assign-cpu-ram-container) it needs.
|
||||
- Replicate your application if you need higher availability. (Learn about running replicated
|
||||
[stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
|
||||
- For even higher availability when running replicated applications,
|
||||
spread applications across racks (using
|
||||
[anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature))
|
||||
or across zones (if using a
|
||||
[multi-zone cluster](/docs/setup/multiple-zones).)
|
||||
-->
|
||||
|
||||
- 确保 pod[请求所需资源](/docs/tasks/configure-pod-container/assign-cpu-ram-container)。
|
||||
- 如果需要更高的可用性，请复制应用程序。（了解有关运行多副本的[无状态](/docs/tasks/run-application/run-stateless-application-deployment/)和[有状态](/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
|
||||
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用[反亲和性](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)）或跨区域（如果使用[多区域集群](/docs/setup/multiple-zones)）扩展应用程序。
|
||||
|
||||
<!--
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
no voluntary disruptions at all. However, your cluster administrator or hosting provider
|
||||
may run some additional services which cause voluntary disruptions. For example,
|
||||
rolling out node software updates can cause voluntary disruptions. Also, some implementations
|
||||
of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
|
||||
Your cluster administrator or hosting provider should have documented what level of voluntary
|
||||
disruptions, if any, to expect.
|
||||
-->
|
||||
|
||||
自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，根本没有自愿干扰。然而，集群管理
|
||||
或托管提供商可能运行一些可能导致自愿干扰的额外服务。例如，节点软
|
||||
更新可能导致自愿干扰。另外，集群（节点）自动缩放的某些
|
||||
现可能导致碎片整理和紧缩节点的自愿干扰。集群
|
||||
理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。
|
||||
|
||||
<!--
|
||||
Kubernetes offers features to help run highly available applications at the same
|
||||
time as frequent voluntary disruptions. We call this set of features
|
||||
*Disruption Budgets*.
|
||||
-->
|
||||
|
||||
Kubernetes 提供特性来满足在出现频繁自愿干扰的同时运行高可用的应用程序。我们称这些特性为*干扰预算*
|
||||
|
||||
<!--
|
||||
## How Disruption Budgets Work
|
||||
-->
|
||||
|
||||
## 干扰预算工作原理
|
||||
|
||||
<!--
|
||||
An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
|
||||
A PDB limits the number of pods of a replicated application that are down simultaneously from
|
||||
voluntary disruptions. For example, a quorum-based application would
|
||||
like to ensure that the number of replicas running is never brought below the
|
||||
number needed for a quorum. A web front end might want to
|
||||
ensure that the number of replicas serving load never falls below a certain
|
||||
percentage of the total.
|
||||
-->
|
||||
|
||||
应用程序所有者可以为每个应用程序创建 `PodDisruptionBudget` 对象（PDB）。PDB 将限制在同一时间因自愿干扰导致的复制应用程序中宕机的 pod 数量。例如，基于定额的应用程序希望确保运行的副本数
|
||||
永远不会低于仲裁所需的数量。Web 前端可能希望确保提供负载的副本数量永远不会低于总数的某个百分比。
|
||||
|
||||
<!--
|
||||
Cluster managers and hosting providers should use tools which
|
||||
respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
|
||||
instead of directly deleting pods or deployments. Examples are the `kubectl drain` command
|
||||
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
|
||||
-->
|
||||
|
||||
集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口（通过调用[驱逐 API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），而不是直接删除 pod 或 deployment。示例包括 `kubectl drain` 命令和 Kubernetes-on-GCE 集群升级脚本（`cluster/gce/upgrade.sh`）。
|
||||
|
||||
<!--
|
||||
When a cluster administrator wants to drain a node
|
||||
they use the `kubectl drain` command. That tool tries to evict all
|
||||
the pods on the machine. The eviction request may be temporarily rejected,
|
||||
and the tool periodically retries all failed requests until all pods
|
||||
are terminated, or until a configurable timeout is reached.
|
||||
-->
|
||||
|
||||
当集群管理员想排空一个节点时，可以使用 `kubectl drain` 命令。该命令试图驱逐机器上的所有 pod。驱逐请求可能会暂时被拒绝，且该工具定时重试失败的请求直到所有的 pod 都被终止，或者达到配置的超时时间。
|
||||
|
||||
<!--
|
||||
A PDB specifies the number of replicas that an application can tolerate having, relative to how
|
||||
many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is
|
||||
supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time,
|
||||
then the Eviction API will allow voluntary disruption of one, but not two pods, at a time.
|
||||
-->
|
||||
|
||||
PDB 指定应用程序可以容忍的副本数量（相当于应该有多少副本）。例如，具有 `.spec.replicas: 5` 的 deployment 在任何时间都应该有 5 个 pod。如果 PDB 允许其在某一时刻有 4 个副本，那么驱逐 API 将允许同一时刻仅有一个而不是两个 pod 自愿干扰。
|
||||
|
||||
<!--
|
||||
The group of pods that comprise the application is specified using a label selector, the same
|
||||
as the one used by the application's controller (deployment, stateful-set, etc).
|
||||
-->
|
||||
|
||||
使用标签选择器来指定构成应用程序的一组 pod，这与应用程序的控制器（deployment，stateful-set 等）选择 pod 的逻辑一样。
|
||||
|
||||
<!--
|
||||
The "intended" number of pods is computed from the `.spec.replicas` of the pods controller.
|
||||
The controller is discovered from the pods using the `.metadata.ownerReferences` of the object.
|
||||
-->
|
||||
|
||||
Pod 控制器的 `.spec.replicas` 计算“预期的” pod 数量。根据 pod 对象的 `.metadata.ownerReferences` 字段来发现控制器。
|
||||
|
||||
<!--
|
||||
PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from
|
||||
occurring, but they do count against the budget.
|
||||
-->
|
||||
|
||||
PDB 不能阻止[非自愿干扰](#voluntary-and-involuntary-disruptions)的发生，但是确实会计入
|
||||
算。
|
||||
|
||||
<!--
|
||||
Pods which are deleted or unavailable due to a rolling upgrade to an application do count
|
||||
against the disruption budget, but controllers (like deployment and stateful-set)
|
||||
are not limited by PDBs when doing rolling upgrades -- the handling of failures
|
||||
during application updates is configured in the controller spec.
|
||||
(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
|
||||
-->
|
||||
|
||||
由于应用程序的滚动升级而被删除或不可用的 pod 确实会计入干扰预算，但是控制器（如 deployment 和 stateful-set）在进行滚动升级时不受 PDB
|
||||
的限制。应用程序更新期间的故障处理是在控制器的 spec 中配置的。（了解[更新 deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)。）
|
||||
|
||||
<!--
|
||||
When a pod is evicted using the eviction API, it is gracefully terminated (see
|
||||
`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
|
||||
-->
|
||||
|
||||
当使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `terminationGracePeriodSeconds`）。
|
||||
|
||||
<!--
|
||||
## PDB Example
|
||||
-->
|
||||
|
||||
## PDB 例子
|
||||
|
||||
<!--
|
||||
Consider a cluster with 3 nodes, `node-1` through `node-3`.
|
||||
The cluster is running several applications. One of them has 3 replicas initially called
|
||||
`pod-a`, `pod-b`, and `pod-c`. Another, unrelated pod without a PDB, called `pod-x`, is also shown.
|
||||
Initially, the pods are laid out as follows:
|
||||
-->
|
||||
|
||||
假设集群有 3 个节点，`node-1` 到 `node-3`。集群上运行了一些应用。其中一个应用有 3 个副本，分别是 `pod-a`，`pod-b` 和 `pod-c`。另外，还有一个不带 PDB 的无关 pod `pod-x` 也同样显示。最初，所有的 pod 分布如下：
|
||||
|
||||
|
||||
| node-1 | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *available* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *available* | | |
|
||||
|
||||
<!--
|
||||
All 3 pods are part of a deployment, and they collectively have a PDB which requires
|
||||
there be at least 2 of the 3 pods to be available at all times.
|
||||
-->
|
||||
|
||||
3 个 pod 都是 deployment 的一部分，并且共同拥有同一个 PDB，要求 3 个 pod 中至少有 2 个 pod 始终处于可用状态。
|
||||
|
||||
<!--
|
||||
For example, assume the cluster administrator wants to reboot into a new kernel version to fix a bug in the kernel.
|
||||
The cluster administrator first tries to drain `node-1` using the `kubectl drain` command.
|
||||
That tool tries to evict `pod-a` and `pod-x`. This succeeds immediately.
|
||||
Both pods go into the `terminating` state at the same time.
|
||||
This puts the cluster in this state:
|
||||
-->
|
||||
|
||||
例如，假设集群管理员想要重启系统，升级内核版本来修复内核中的 bug。集群管理员首先使用 `kubectl drain` 命令尝试排空 `node-1` 节点。命令尝试驱逐 `pod-a` 和 `pod-x`。操作立即就成功了。两个 pod 同时进入 `terminating` 状态。这时的集群处于下面的状态：
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | | |
|
||||
|
||||
<!--
|
||||
The deployment notices that one of the pods is terminating, so it creates a replacement
|
||||
called `pod-d`. Since `node-1` is cordoned, it lands on another node. Something has
|
||||
also created `pod-y` as a replacement for `pod-x`.
|
||||
-->
|
||||
|
||||
Deployment 控制器观察到其中一个 pod 正在终止，因此它创建了一个替代 pod `pod-d`。由于 `node-1` 被封锁（cordon），`pod-d` 落在另一个节点上。同样其他控制器也创建了 `pod-y` 作为 `pod-x` 的替代品。
|
||||
|
||||
<!--
|
||||
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need
|
||||
to terminate completely before its replacement, which is also called `pod-0` but has a
|
||||
different UID, could be created. Otherwise, the example applies to a StatefulSet as well.)
|
||||
-->
|
||||
|
||||
（注意：对于 StatefulSet 来说，`pod-a`（也称为 `pod-0`）需要在替换 pod 创建之前完全终止，替代它的也称为 `pod-0`，但是具有不同的 UID。反之，样例也适用于 StatefulSet。）
|
||||
|
||||
<!--
|
||||
Now the cluster is in this state:
|
||||
-->
|
||||
|
||||
当前集群的状态如下：
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | pod-d *starting* | pod-y |
|
||||
|
||||
<!--
|
||||
At some point, the pods terminate, and the cluster looks like this:
|
||||
-->
|
||||
|
||||
在某一时刻，pod 被终止，集群如下所示：
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *starting* | pod-y |
|
||||
|
||||
<!--
|
||||
At this point, if an impatient cluster administrator tries to drain `node-2` or
|
||||
`node-3`, the drain command will block, because there are only 2 available
|
||||
pods for the deployment, and its PDB requires at least 2. After some time passes, `pod-d` becomes available.
|
||||
-->
|
||||
|
||||
此时，如果一个急躁的集群管理员试图排空（drain）`node-2` 或 `node-3`，drain 命令将被阻塞，因为对于 deployment 来说只有 2 个可用的 pod，并且它的 PDB 至少需要 2 个。经过一段时间，`pod-d` 变得可用。
|
||||
|
||||
<!--
|
||||
The cluster state now looks like this:
|
||||
-->
|
||||
|
||||
集群状态如下所示：
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *available* | pod-y |
|
||||
|
||||
<!--
|
||||
Now, the cluster administrator tries to drain `node-2`.
|
||||
The drain command will try to evict the two pods in some order, say
|
||||
`pod-b` first and then `pod-d`. It will succeed at evicting `pod-b`.
|
||||
But, when it tries to evict `pod-d`, it will be refused because that would leave only
|
||||
one pod available for the deployment.
|
||||
-->
|
||||
|
||||
现在，集群管理员试图排空（drain）`node-2`。drain 命令将尝试按照某种顺序驱逐两个 pod，假设先是 `pod-b`，然后是 `pod-d`。命令成功驱逐 `pod-b`，但是当它尝试驱逐 `pod-d`时将被拒绝，因为对于 deployment 来说只剩一个可用的 pod 了。
|
||||
|
||||
<!--
|
||||
The deployment creates a replacement for `pod-b` called `pod-e`.
|
||||
Because there are not enough resources in the cluster to schedule
|
||||
`pod-e` the drain will again block. The cluster may end up in this
|
||||
state:
|
||||
-->
|
||||
|
||||
Deployment 创建 `pod-b` 的替代 pod `pod-e`。因为集群中没有足够的资源来调度 `pod-e`，drain 命令再次阻塞。集群最终将是下面这种状态：
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 | *no node* |
|
||||
|:--------------------:|:-------------------:|:------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* | pod-e *pending* |
|
||||
| | pod-d *available* | pod-y | |
|
||||
|
||||
<!--
|
||||
At this point, the cluster administrator needs to
|
||||
add a node back to the cluster to proceed with the upgrade.
|
||||
-->
|
||||
|
||||
此时，集群管理员需要增加一个节点到集群中以继续升级操作。
|
||||
|
||||
<!--
|
||||
You can see how Kubernetes varies the rate at which disruptions
|
||||
can happen, according to:
|
||||
-->
|
||||
|
||||
可以看到 Kubernetes 如何改变干扰发生的速率，根据：
|
||||
|
||||
<!--
|
||||
- how many replicas an application needs
|
||||
- how long it takes to gracefully shutdown an instance
|
||||
- how long it takes a new instance to start up
|
||||
- the type of controller
|
||||
- the cluster's resource capacity
|
||||
-->
|
||||
|
||||
- 应用程序需要多少个副本
|
||||
- 优雅关闭应用实例需要多长时间
|
||||
- 启动应用新实例需要多长时间
|
||||
- 控制器的类型
|
||||
- 集群的资源能力
|
||||
|
||||
<!--
|
||||
## Separating Cluster Owner and Application Owner Roles
|
||||
-->
|
||||
|
||||
## 分离集群所有者和应用所有者角色
|
||||
|
||||
<!--
|
||||
Often, it is useful to think of the Cluster Manager
|
||||
and Application Owner as separate roles with limited knowledge
|
||||
of each other. This separation of responsibilities
|
||||
may make sense in these scenarios:
|
||||
-->
|
||||
|
||||
通常，将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的：
|
||||
|
||||
<!--
|
||||
- when there are many application teams sharing a Kubernetes cluster, and
|
||||
there is natural specialization of roles
|
||||
- when third-party tools or services are used to automate cluster management
|
||||
-->
|
||||
|
||||
- 当有许多应用程序团队共用一个 Kubernetes 集群，并且有自然的专业角色
|
||||
- 当第三方工具或服务用于集群自动化管理
|
||||
|
||||
<!--
|
||||
Pod Disruption Budgets support this separation of roles by providing an
|
||||
interface between the roles.
|
||||
-->
|
||||
|
||||
Pod 干扰预算通过在角色之间提供接口来支持这种分离。
|
||||
|
||||
<!--
|
||||
If you do not have such a separation of responsibilities in your organization,
|
||||
you may not need to use Pod Disruption Budgets.
|
||||
-->
|
||||
|
||||
如果你的组织中没有这样的责任分离，则可能不需要使用 Pod 干扰预算。
|
||||
|
||||
<!--
|
||||
## How to perform Disruptive Actions on your Cluster
|
||||
-->
|
||||
|
||||
## 如何在集群上执行干扰操作
|
||||
|
||||
<!--
|
||||
If you are a Cluster Administrator, and you need to perform a disruptive action on all
|
||||
the nodes in your cluster, such as a node or system software upgrade, here are some options:
|
||||
-->
|
||||
|
||||
如果你是集群管理员，并且需要对集群中的所有节点执行干扰操作，例如节点或系统软件升级，则可以使用以下选项
|
||||
|
||||
|
||||
<!--
|
||||
- Accept downtime during the upgrade.
|
||||
- Failover to another complete replica cluster.
|
||||
- No downtime, but may be costly both for the duplicated nodes
|
||||
and for human effort to orchestrate the switchover.
|
||||
- Write disruption tolerant applications and use PDBs.
|
||||
- No downtime.
|
||||
- Minimal resource duplication.
|
||||
- Allows more automation of cluster administration.
|
||||
- Writing disruption-tolerant applications is tricky, but the work to tolerate voluntary
|
||||
disruptions largely overlaps with work to support autoscaling and tolerating
|
||||
involuntary disruptions.
|
||||
-->
|
||||
|
||||
- 接受升级期间的停机时间。
|
||||
- 故障转移到另一个完整的副本集群。
|
||||
- 没有停机时间，但是对于重复的节点和人工协调成本可能是昂贵的。
|
||||
- 编写可容忍干扰的应用程序和使用 PDB。
|
||||
- 没有停机
|
||||
间。
|
||||
- 最小的资源重复。
|
||||
- 允许更多的集群管理自动化。
|
||||
- 编写可容忍干扰的应用程序是棘手的，但对于支持容忍自愿干扰所做的工作，和支持自动扩缩和容忍非
|
||||
愿干扰所做工作相比，有大量的重叠
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
|
||||
-->
|
||||
|
||||
* 参考[配置 Pod 干扰预算](/docs/tasks/run-application/configure-pdb/)中的方法来保护你的
|
||||
用。
|
||||
|
||||
<!--
|
||||
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
|
||||
-->
|
||||
|
||||
* 了解更多关于[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,313 @@
|
||||
---
|
||||
title: 临时容器
|
||||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- verb
|
||||
- yujuhong
|
||||
title: Ephemeral Containers
|
||||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
<!--
|
||||
This page provides an overview of ephemeral containers: a special type of container
|
||||
that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to accomplish user-initiated actions such
|
||||
as troubleshooting. You use ephemeral containers to inspect services rather than
|
||||
to build applications.
|
||||
-->
|
||||
|
||||
此页面概述了临时容器：一种特殊的容器，该容器在现有 {{< glossary_tooltip term_id="pod" >}} 中临时运行，为了完成用户启动的操作，例如故障排查。使用临时容器来检查服务，而不是构建应用程序。
|
||||
|
||||
<!--
|
||||
Ephemeral containers are in early alpha state and are not suitable for production
|
||||
clusters. You should expect the feature not to work in some situations, such as
|
||||
when targeting the namespaces of a container. In accordance with the [Kubernetes
|
||||
Deprecation Policy](/docs/reference/using-api/deprecation-policy/), this alpha
|
||||
feature could change significantly in the future or be removed entirely.
|
||||
-->
|
||||
|
||||
{{< warning >}}
|
||||
临时容器处于早期的 alpha 阶段，不适用于生成环境集群。应该预料到临时容器在某些情况下不起作用，例如在定位容器的名称命名空间。根据 [Kubernetes
|
||||
弃用政策](/docs/reference/using-api/deprecation-policy/)，该 alpha 功能将来可能发生重大变化或完全删除。
|
||||
{{< /warning >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Understanding ephemeral containers
|
||||
-->
|
||||
|
||||
## 了解临时容器
|
||||
|
||||
<!--
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} are the fundamental building
|
||||
block of Kubernetes applications. Since Pods are intended to be disposable and
|
||||
replaceable, you cannot add a container to a Pod once it has been created.
|
||||
Instead, you usually delete and replace Pods in a controlled fashion using
|
||||
{{< glossary_tooltip text="deployments" term_id="deployment" >}}.
|
||||
-->
|
||||
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} 是 Kubernetes 应用程序的基本构建块。由于 pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。取而代之的是，通常使用 {{< glossary_tooltip text="deployments" term_id="deployment" >}} 以受控的方式来删除并替换 Pod。
|
||||
|
||||
<!--
|
||||
Sometimes it's necessary to inspect the state of an existing Pod, however, for
|
||||
example to troubleshoot a hard-to-reproduce bug. In these cases you can run
|
||||
an ephemeral container in an existing Pod to inspect its state and run
|
||||
arbitrary commands.
|
||||
-->
|
||||
|
||||
有时有必要检查现有 Pod 的状态，例如，对于难以复现的故障进行排查。在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。
|
||||
|
||||
<!--
|
||||
### What is an ephemeral container?
|
||||
-->
|
||||
|
||||
### 什么是临时容器？
|
||||
|
||||
<!--
|
||||
Ephemeral containers differ from other containers in that they lack guarantees
|
||||
for resources or execution, and they will never be automatically restarted, so
|
||||
they are not appropriate for building applications. Ephemeral containers are
|
||||
described using the same `ContainerSpec` as regular containers, but many fields
|
||||
are incompatible and disallowed for ephemeral containers.
|
||||
-->
|
||||
|
||||
临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，因此不适用于构建应用程序。临时容器使用与常规容器相同的 `ContainerSpec` 段进行描述，但许多字段是不相容且不允许的。
|
||||
|
||||
<!--
|
||||
- Ephemeral containers may not have ports, so fields such as `ports`,
|
||||
`livenessProbe`, `readinessProbe` are disallowed.
|
||||
- Pod resource allocations are immutable, so setting `resources` is disallowed.
|
||||
- For a complete list of allowed fields, see the [EphemeralContainer reference
|
||||
documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core).
|
||||
-->
|
||||
|
||||
- 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe` 这样的字段是不允许的。
|
||||
- Pod 资源分配是不可变的，因此 `resources` 配置是不允许的。
|
||||
- 有关允许字段的完整列表，请参见[临时容器参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)。
|
||||
|
||||
<!--
|
||||
Ephemeral containers are created using a special `ephemeralcontainers` handler
|
||||
in the API rather than by adding them directly to `pod.spec`, so it's not
|
||||
possible to add an ephemeral container using `kubectl edit`.
|
||||
-->
|
||||
|
||||
临时容器是使用 API 中的一种特殊的 `ephemeralcontainers` 处理器进行创建的，而不是直接添加到 `pod.spec` 段，因此无法使用 `kubectl edit` 来添加一个临时容器。
|
||||
|
||||
<!--
|
||||
Like regular containers, you may not change or remove an ephemeral container
|
||||
after you have added it to a Pod.
|
||||
-->
|
||||
|
||||
与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。
|
||||
|
||||
<!--
|
||||
## Uses for ephemeral containers
|
||||
-->
|
||||
|
||||
## 临时容器的用途
|
||||
|
||||
<!--
|
||||
Ephemeral containers are useful for interactive troubleshooting when `kubectl
|
||||
exec` is insufficient because a container has crashed or a container image
|
||||
doesn't include debugging utilities.
|
||||
-->
|
||||
|
||||
当容器崩溃或容器镜像中不包含调试工具时，使用 `kubectl
|
||||
exec` 命令进行故障排查不足，临时容器对于交互式故障处理很有用。
|
||||
|
||||
<!--
|
||||
In particular, [distroless images](https://github.com/GoogleContainerTools/distroless)
|
||||
enable you to deploy minimal container images that reduce attack surface
|
||||
and exposure to bugs and vulnerabilities. Since distroless images do not include a
|
||||
shell or any debugging utilities, it's difficult to troubleshoot distroless
|
||||
images using `kubectl exec` alone.
|
||||
-->
|
||||
|
||||
尤其是，[distroless 镜像](https://github.com/GoogleContainerTools/distroless)能够使得部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。由于 distroless 镜像不包含 shell 或任何的调试工具，因此很难单独使用 `kubectl exec` 命令进行故障排查。
|
||||
|
||||
<!--
|
||||
When using ephemeral containers, it's helpful to enable [process namespace
|
||||
sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
|
||||
you can view processes in other containers.
|
||||
-->
|
||||
|
||||
使用临时容器时，启用[进程命名空间共享](/docs/tasks/configure-pod-container/share-process-namespace/)很有帮助，可以查看其他容器中的进程。
|
||||
|
||||
<!--
|
||||
### 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.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
本节中的示例要求启用 `EphemeralContainers` [特性](/docs/reference/command-line-tools-reference/feature-gates/)，并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
本节中的示例演示了临时容器如何在 API 中出现。用户通常会使用 `kubectl` 插件来进行故障排查，从而自动化执行这些步骤。
|
||||
|
||||
<!--
|
||||
Ephemeral containers are created using the `ephemeralcontainers` subresource
|
||||
of Pod, which can be demonstrated using `kubectl --raw`. First describe
|
||||
the ephemeral container to add as an `EphemeralContainers` list:
|
||||
-->
|
||||
|
||||
临时容器是使用 Pod 的 `ephemeralcontainers` 子资源创建的，可以使用 `kubectl --raw` 命令进行显示。首先描述临时容器被添加为一个 `EphemeralContainers` 列表：
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"kind": "EphemeralContainers",
|
||||
"metadata": {
|
||||
"name": "example-pod"
|
||||
},
|
||||
"ephemeralContainers": [{
|
||||
"command": [
|
||||
"sh"
|
||||
],
|
||||
"image": "busybox",
|
||||
"imagePullPolicy": "IfNotPresent",
|
||||
"name": "debugger",
|
||||
"stdin": true,
|
||||
"tty": true,
|
||||
"terminationMessagePolicy": "File"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
To update the ephemeral containers of the already running `example-pod`:
|
||||
-->
|
||||
|
||||
使用如下命令更新已运行的临时容器 `example-pod`：
|
||||
|
||||
```shell
|
||||
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
|
||||
```
|
||||
|
||||
<!--
|
||||
This will return the new list of ephemeral containers:
|
||||
-->
|
||||
|
||||
这将返回临时容器的新列表：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind":"EphemeralContainers",
|
||||
"apiVersion":"v1",
|
||||
"metadata":{
|
||||
"name":"example-pod",
|
||||
"namespace":"default",
|
||||
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
|
||||
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
|
||||
"resourceVersion":"15886",
|
||||
"creationTimestamp":"2019-08-29T06:41:42Z"
|
||||
},
|
||||
"ephemeralContainers":[
|
||||
{
|
||||
"name":"debugger",
|
||||
"image":"busybox",
|
||||
"command":[
|
||||
"sh"
|
||||
],
|
||||
"resources":{
|
||||
|
||||
},
|
||||
"terminationMessagePolicy":"File",
|
||||
"imagePullPolicy":"IfNotPresent",
|
||||
"stdin":true,
|
||||
"tty":true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
You can view the state of the newly created ephemeral container using `kubectl describe`:
|
||||
-->
|
||||
|
||||
可以使用以下命令查看新创建的临时容器的状态：
|
||||
|
||||
```shell
|
||||
kubectl describe pod example-pod
|
||||
```
|
||||
|
||||
```
|
||||
...
|
||||
Ephemeral Containers:
|
||||
debugger:
|
||||
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
|
||||
Image: busybox
|
||||
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
|
||||
Port: <none>
|
||||
Host Port: <none>
|
||||
Command:
|
||||
sh
|
||||
State: Running
|
||||
Started: Thu, 29 Aug 2019 06:42:21 +0000
|
||||
Ready: False
|
||||
Restart Count: 0
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
You can attach to the new ephemeral container using `kubectl attach`:
|
||||
-->
|
||||
|
||||
可以使用以下命令连接到新的临时容器：
|
||||
|
||||
```shell
|
||||
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:
|
||||
-->
|
||||
|
||||
如果启用了进程命名空间共享，则可以从该 Pod 的所有容器中查看进程。如下所示：
|
||||
|
||||
```shell
|
||||
/ # ps auxww
|
||||
PID USER TIME COMMAND
|
||||
1 root 0:00 /pause
|
||||
6 root 0:00 nginx: master process nginx -g daemon off;
|
||||
11 101 0:00 nginx: worker process
|
||||
12 101 0:00 nginx: worker process
|
||||
13 101 0:00 nginx: worker process
|
||||
14 101 0:00 nginx: worker process
|
||||
15 101 0:00 nginx: worker process
|
||||
16 101 0:00 nginx: worker process
|
||||
17 101 0:00 nginx: worker process
|
||||
18 101 0:00 nginx: worker process
|
||||
19 root 0:00 /pause
|
||||
24 root 0:00 sh
|
||||
29 root 0:00 ps auxww
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -12,63 +12,119 @@ content_template: templates/concept
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本页提供了 Init 容器的概览，它是一种专用的容器，在应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
|
||||
<!--
|
||||
This page provides an overview of init containers: specialized containers that run before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
|
||||
Init containers can contain utilities or setup scripts not present in an app image.
|
||||
-->
|
||||
|
||||
本页提供了 Init 容器的概览，它是一种专用的容器，在{{< glossary_tooltip text="Pod" term_id="pod" >}}内的应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
|
||||
这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中有效 QoS 层同应用的 `containers` 数组一起来指定。
|
||||
beta 注解的值将仍然需要保留，并覆盖 PodSpec 字段值。
|
||||
|
||||
<!--
|
||||
You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers).
|
||||
-->
|
||||
你可以在Pod的规格信息中与containers数组同级的位置指定 Init 容器。
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
<!--
|
||||
## Understanding init containers
|
||||
|
||||
A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers running apps within it, but it can also have one or more init containers, which are run before the app containers are started.
|
||||
|
||||
-->
|
||||
|
||||
## 理解 Init 容器
|
||||
|
||||
|
||||
|
||||
[Pod](/docs/concepts/abstractions/pod/) 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}} 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
|
||||
|
||||
|
||||
<!--
|
||||
Init containers are exactly like regular containers, except:
|
||||
* Init containers always run to completion.
|
||||
* Each init container must complete successfully before the next one starts.
|
||||
-->
|
||||
Init 容器与普通的容器非常像，除了如下两点：
|
||||
|
||||
|
||||
|
||||
* 它们总是运行到完成。
|
||||
* 每个都必须在下一个启动之前成功完成。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod.
|
||||
-->
|
||||
如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 值为 Never，它不会重新启动。
|
||||
|
||||
指定容器为 Init 容器，需要在 PodSpec 中添加 `initContainers` 字段，以 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。
|
||||
|
||||
<!--
|
||||
To specify an init container for a Pod, add the `initContainers` field into the Pod specification, as an array of objects of type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), alongside the app `containers` array.
|
||||
|
||||
The status of the init containers is returned in `.status.initContainerStatuses` field as an array of the container statuses (similar to the `.status.containerStatuses` field).
|
||||
-->
|
||||
指定容器为 Init 容器，需要在 Pod 的 spec 中添加 `initContainers` 字段， 该字段內以[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 类型对象数组的形式组织，和应用的 `containers` 数组同级相邻。
|
||||
Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。
|
||||
|
||||
|
||||
<!--
|
||||
### Differences from regular containers
|
||||
Init containers support all the fields and features of app containers, including resource limits, volumes, and security settings. However, the resource requests and limits for an init container are handled differently, as documented in [Resources](#resources).
|
||||
Also, init containers do not support readiness probes because they must run to completion before the Pod can be ready.
|
||||
If you specify multiple init containers for a Pod, Kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, Kubelet initializes the application containers for the Pod and runs them as usual.
|
||||
-->
|
||||
|
||||
### 与普通容器的不同之处
|
||||
|
||||
Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。
|
||||
然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#资源) 处有说明。
|
||||
而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
|
||||
|
||||
如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。
|
||||
每个 Init 容器必须运行成功，下一个才能够运行。
|
||||
当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
|
||||
Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#资源) 处有说明。
|
||||
|
||||
同时 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
|
||||
|
||||
如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时，Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。
|
||||
|
||||
|
||||
<!--
|
||||
## Using init containers
|
||||
Because init containers have separate images from app containers, they have some advantages for start-up related code:
|
||||
* Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image `FROM` another image just to use a tool like `sed`, `awk`, `python`, or `dig` during setup.
|
||||
* Init containers can securely run utilities that would make an app container image less secure.
|
||||
* The application image builder and deployer roles can work independently without the need to jointly build a single app image.
|
||||
* Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to {{< glossary_tooltip text="Secrets" term_id="secret" >}} that app containers cannot access.
|
||||
* Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.
|
||||
-->
|
||||
## Init 容器能做什么？
|
||||
|
||||
因为 Init 容器具有与应用容器分离的单独镜像，它们的启动相关代码具有如下优势：
|
||||
因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：
|
||||
|
||||
* 它们可以包含并运行实用工具，出于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
|
||||
* 它们可以包含用于安装的工具和定制化代码，这些都是在应用镜像中没有的。例如，创建镜像没必要 `FROM` 另一个镜像，只需要在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具。
|
||||
* 应用镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
|
||||
* 它们使用 Linux Namespace，所以对应用容器具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用容器不能够访问。
|
||||
* 它们在应用容器启动之前运行完成，然而应用容器并行运行，所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动，直到满足了一组先决条件。
|
||||
* Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具而去`FROM` 一个镜像来生成一个新的镜像。
|
||||
* Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
|
||||
* 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
|
||||
* Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 {{< glossary_tooltip text="Secrets" term_id="secret" >}} 的权限，而应用容器不能够访问。
|
||||
* 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
|
||||
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
Here are some ideas for how to use init containers:
|
||||
* Wait for a {{< glossary_tooltip text="Service" term_id="service">}} to
|
||||
be created, using a shell one-line command like:
|
||||
```shell
|
||||
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
|
||||
```
|
||||
* Register this Pod with a remote server from the downward API with a command like:
|
||||
```shell
|
||||
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
|
||||
```
|
||||
* Wait for some time before starting the app container with a command like
|
||||
```shell
|
||||
sleep 60
|
||||
```
|
||||
|
||||
* Clone a Git repository into a {{< glossary_tooltip text="Volume" term_id="volume" >}}
|
||||
* Place values into a configuration file and run a template tool to dynamically generate a configuration file for the main app container. For example, place the `POD_IP` value in a configuration and generate the main app configuration file using Jinja.
|
||||
|
||||
-->
|
||||
|
||||
### 示例
|
||||
|
||||
@@ -82,50 +138,38 @@ Init 容器支持应用容器的全部字段和特性，包括资源限制、数
|
||||
|
||||
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
|
||||
|
||||
* 在启动应用容器之前等一段时间，使用类似 `sleep 60` 的命令。
|
||||
* 克隆 Git 仓库到数据卷。
|
||||
* 在启动应用容器之前等一段时间，使用类似命令：
|
||||
|
||||
`sleep 60`
|
||||
|
||||
* 克隆 Git 仓库到 {{< glossary_tooltip text="Volume" term_id="volume" >}}。
|
||||
* 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。
|
||||
|
||||
更多详细用法示例，可以在 [StatefulSet 文档](/docs/concepts/abstractions/controllers/statefulsets/) 和 [Pod 初始化](/docs/tasks/configure-pod-container/configure-pod-initialization) 中找到。
|
||||
|
||||
|
||||
|
||||
### 使用 Init 容器
|
||||
|
||||
下面是 Kubernetes 1.5 版本 yaml 文件，展示了一个具有 2 个 Init 容器的简单 Pod。
|
||||
第一个等待 `myservice` 启动，第二个等待 `mydb` 启动。
|
||||
一旦这两个 Service 都启动完成，Pod 将开始启动。
|
||||
|
||||
<!--
|
||||
#### Init containers in use
|
||||
This example defines a simple Pod that has two init containers. The first waits for `myservice`, and the second waits for `mydb`. Once both init containers complete, the Pod runs the app container from its `spec` section.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
annotations:
|
||||
pod.beta.kubernetes.io/init-containers: '[
|
||||
{
|
||||
"name": "init-myservice",
|
||||
"image": "busybox",
|
||||
"command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
|
||||
},
|
||||
{
|
||||
"name": "init-mydb",
|
||||
"image": "busybox",
|
||||
"command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
|
||||
}
|
||||
]'
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
|
||||
```
|
||||
|
||||
The following YAML file outlines the `mydb` and `myservice` services:
|
||||
```yaml
|
||||
|
||||
```
|
||||
|
||||
|
||||
You can start this Pod by running:
|
||||
```shell
|
||||
```
|
||||
|
||||
这是 Kubernetes 1.6 版本的新语法，尽管老的 annotation 语法仍然可以使用。我们已经把 Init 容器的声明移到 `spec` 中：
|
||||
And check on its status with:
|
||||
```shell
|
||||
```
|
||||
-->
|
||||
### 使用 Init 容器
|
||||
|
||||
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 `myservice` 启动，第二个等待 `mydb` 启动。 一旦这两个 Init容器 都启动完成，Pod 将启动`spec`区域中的应用容器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -137,23 +181,17 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
initContainers:
|
||||
- name: init-myservice
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
|
||||
- name: init-mydb
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
|
||||
```
|
||||
|
||||
|
||||
|
||||
1.5 版本的语法在 1.6 版本仍然可以使用，但是我们推荐使用 1.6 版本的新语法。
|
||||
在 Kubernetes 1.6 版本中，Init 容器在 API 中新建了一个字段。
|
||||
虽然期望使用 beta 版本的 annotation，但在未来发行版将会被废弃掉。
|
||||
|
||||
下面的 yaml 文件展示了 `mydb` 和 `myservice` 两个 Service：
|
||||
|
||||
```
|
||||
@@ -179,16 +217,35 @@ spec:
|
||||
```
|
||||
|
||||
|
||||
|
||||
这个 Pod 可以使用下面的命令进行启动和调试：
|
||||
要启动这个 Pod，可以执行如下命令：
|
||||
|
||||
```
|
||||
kubectl apply -f myapp.yaml
|
||||
```
|
||||
|
||||
```
|
||||
pod/myapp-pod created
|
||||
```
|
||||
|
||||
|
||||
|
||||
要检查其状态：
|
||||
```
|
||||
kubectl get -f myapp.yaml
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl create -f myapp.yaml
|
||||
pod "myapp-pod" created
|
||||
$ kubectl get -f myapp.yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 0/1 Init:0/2 0 6m
|
||||
$ kubectl describe -f myapp.yaml
|
||||
```
|
||||
|
||||
如需更详细的信息：
|
||||
|
||||
```
|
||||
kubectl describe -f myapp.yaml
|
||||
```
|
||||
|
||||
```
|
||||
Name: myapp-pod
|
||||
Namespace: default
|
||||
[...]
|
||||
@@ -221,111 +278,175 @@ Events:
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox"
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
|
||||
```
|
||||
|
||||
如需查看Pod内 Init 容器的日志，请执行:
|
||||
|
||||
```
|
||||
$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
|
||||
$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
|
||||
```
|
||||
|
||||
<!--
|
||||
At this point, those init containers will be waiting to discover Services named `mydb` and `myservice`.
|
||||
|
||||
Here's a configuration you can use to make those Services appear:
|
||||
-->
|
||||
|
||||
一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建：
|
||||
在这一刻，Init 容器将会等待至发现名称为`mydb`和`myservice`的 Service。
|
||||
|
||||
如下为创建这些 Service 的配置文件：
|
||||
|
||||
```
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: myservice
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: mydb
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9377
|
||||
```
|
||||
|
||||
|
||||
创建`mydb`和`myservice`的 service 命令：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f services.yaml
|
||||
```
|
||||
|
||||
```
|
||||
service "myservice" created
|
||||
service "mydb" created
|
||||
```
|
||||
|
||||
这样你将能看到这些 Init容器 执行完毕，随后`my-app`的Pod转移进入 Running 状态：
|
||||
```shell
|
||||
$ kubectl get -f myapp.yaml
|
||||
```
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 1/1 Running 0 9m
|
||||
```
|
||||
|
||||
一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建：
|
||||
|
||||
|
||||
这个例子非常简单，但是应该能够为创建自己的 Init 容器提供一些启发。
|
||||
<!--
|
||||
This simple example should provide some inspiration for you to create your own init containers. [What's next](#what-s-next) contains a link to a more detailed example.
|
||||
-->
|
||||
这个简单的例子应该能为你创建自己的 Init 容器提供一些启发。 [What's next](#what-s-next) 部分提供了更详细例子的链接。
|
||||
|
||||
|
||||
<!--
|
||||
During the startup of a Pod, each init container starts in order, after the network and volumes are initialized. Each container must exit successfully before the next container starts. If a container fails to start due to the runtime or exits with failure, it is retried according to the Pod `restartPolicy`. However, if the Pod `restartPolicy` is set to Always, the init containers use `restartPolicy` OnFailure.
|
||||
|
||||
A Pod cannot be `Ready` until all init containers have succeeded. The ports on an init container are not aggregated under a Service. A Pod that is initializing
|
||||
is in the `Pending` state but should have a condition `Initializing` set to true.
|
||||
|
||||
If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers must execute again.
|
||||
|
||||
Changes to the init container spec are limited to the container image field. Altering an init container image field is equivalent to restarting the Pod.
|
||||
|
||||
Because init containers can be restarted, retried, or re-executed, init container code should be idempotent. In particular, code that writes to files on `EmptyDirs` should be prepared for the possibility that an output file already exists.
|
||||
|
||||
Init containers have all of the fields of an app container. However, Kubernetes prohibits `readinessProbe` from being used because init containers cannot define readiness distinct from completion. This is enforced during validation.
|
||||
|
||||
Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the container to prevent init containers from failing forever. The active deadline includes init containers.
|
||||
|
||||
The name of each app and init container in a Pod must be unique; avalidation error is thrown for any container sharing a name with another.
|
||||
|
||||
-->
|
||||
|
||||
## 具体行为
|
||||
|
||||
在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。
|
||||
每个容器必须在下一个容器启动之前成功退出。
|
||||
如果由于运行时或失败退出，导致容器启动失败，它会根据 Pod 的 `restartPolicy` 指定的策略进行重试。
|
||||
然而，如果 Pod 的 `restartPolicy` 设置为 Always，Init 容器失败时会使用 `RestartPolicy` 策略。
|
||||
在 Pod 启动过程中，每个Init 容器在网络和数据卷初始化之后会按顺序启动。每个 Init容器 成功退出后才会启动下一个 Init容器。 如果因为运行或退出时失败引发容器启动失败，它会根据 Pod 的 `restartPolicy` 策略进行重试。
|
||||
然而，如果 Pod 的 `restartPolicy` 设置为 Always，Init 容器失败时会使用 `restartPolicy` 的 OnFailure 策略。
|
||||
|
||||
|
||||
|
||||
在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。
|
||||
Init 容器的端口将不会在 Service 中进行聚集。
|
||||
正在初始化中的 Pod 处于 `Pending` 状态，但应该会将条件 `Initialized` 设置为 true。
|
||||
在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。 Init 容器的端口将不会在 Service 中进行聚集。 正在初始化中的 Pod 处于 `Pending` 状态，但会将条件 `Initializing` 设置为 true。
|
||||
|
||||
如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。
|
||||
|
||||
对 Init 容器 spec 的修改，被限制在容器 image 字段中。
|
||||
更改 Init 容器的 image 字段，等价于重启该 Pod。
|
||||
对 Init 容器 spec 的修改仅限于容器的 image 字段。 更改 Init 容器的 image 字段，等同于重启该 Pod。
|
||||
|
||||
因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 特别地，基于 `EmptyDirs` 写文件的代码，应该对输出文件可能已经存在做好准备。
|
||||
|
||||
Init 容器具有应用容器的所有字段。 然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能定义不同于完成（completion）的就绪（readiness）。 这一点会在校验时强制执行。
|
||||
|
||||
在 Pod 上使用 `activeDeadlineSeconds`和在容器上使用 `livenessProbe` 可以避免 Init 容器一直重复失败。 `activeDeadlineSeconds` 时间包含了 Init 容器启动的时间。
|
||||
|
||||
在 Pod 中的每个应用容器和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在校验时抛出错误。
|
||||
|
||||
|
||||
<!--
|
||||
### Resources
|
||||
Given the ordering and execution for init containers, the following rules for resource usage apply:
|
||||
* The highest of any particular resource request or limit defined on all init containers is the *effective init request/limit*
|
||||
* The Pod's *effective request/limit* for a resource is the higher of:
|
||||
* the sum of all app containers request/limit for a resource
|
||||
* the effective init request/limit for a resource
|
||||
* Scheduling is done based on effective requests/limits, which means init containers can reserve resources for initialization that are not used during the life of the Pod.
|
||||
* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the QoS tier for init containers and app containers alike.
|
||||
|
||||
因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。
|
||||
特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。
|
||||
|
||||
Init 容器具有应用容器的所有字段。
|
||||
然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。
|
||||
这会在验证过程中强制执行。
|
||||
|
||||
|
||||
|
||||
在 Pod 上使用 `activeDeadlineSeconds`，在容器上使用 `livenessProbe`，这样能够避免 Init 容器一直失败。
|
||||
这就为 Init 容器活跃设置了一个期限。
|
||||
|
||||
在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。
|
||||
|
||||
|
||||
Quota and limits are applied based on the effective Pod request and limit.
|
||||
Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler.
|
||||
-->
|
||||
|
||||
### 资源
|
||||
|
||||
为 Init 容器指定顺序和执行逻辑，下面对资源使用的规则将被应用：
|
||||
给定Init 容器的执行顺序下，资源使用适用于如下规则：
|
||||
|
||||
* 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod *有效初始 request/limit*
|
||||
* Pod 对资源的 *有效 limit/request * 是如下两者的较大者：
|
||||
* 所有应用容器对某个资源的 limit/request 之和
|
||||
* 对某个资源的有效初始 limit/request
|
||||
* 基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
|
||||
* Pod 的 *有效 QoS 层* ，与 Init 容器和应用容器的一样。
|
||||
|
||||
配额和限制适用于有效 Pod的 limit/request。
|
||||
Pod 级别的 cgroups 是基于有效 Pod 的 limit/request，和调度器相同。
|
||||
|
||||
|
||||
|
||||
* 在所有 Init 容器上定义的，任何特殊资源请求或限制的最大值，是 *有效初始请求/限制*
|
||||
* Pod 对资源的 *有效请求/限制* 要高于：
|
||||
* 所有应用容器对某个资源的请求/限制之和
|
||||
* 对某个资源的有效初始请求/限制
|
||||
* 基于有效请求/限制完成调度，这意味着 Init 容器能够为初始化预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
|
||||
* Pod 的 *有效 QoS 层* ，是 Init 容器和应用容器相同的 QoS 层。
|
||||
|
||||
|
||||
|
||||
基于有效 Pod 请求和限制来应用配额和限制。
|
||||
Pod 级别的 cgroups 是基于有效 Pod 请求和限制，和调度器相同。
|
||||
|
||||
<!--
|
||||
### Pod restart reasons
|
||||
A Pod can restart, causing re-execution of init containers, for the following reasons:
|
||||
* A user updates the Pod specification, causing the init container image to change. Any changes to the init container image restarts the Pod. App container image changes only restart the app container.
|
||||
* The Pod infrastructure container is restarted. This is uncommon and would have to be done by someone with root access to nodes.
|
||||
* All containers in a Pod are terminated while `restartPolicy` is set to Always, forcing a restart, and the init container completion record has been lost due to garbage collection.
|
||||
|
||||
|
||||
-->
|
||||
### Pod 重启的原因
|
||||
|
||||
Pod 能够重启，会导致 Init 容器重新执行，主要有如下几个原因：
|
||||
Pod重启导致 Init 容器重新执行，主要有如下几个原因：
|
||||
|
||||
* 用户更新 PodSpec 导致 Init 容器镜像发生改变。应用容器镜像的变更只会重启应用容器。
|
||||
* Pod 基础设施容器被重启。这不多见，但某些具有 root 权限可访问 Node 的人可能会这样做。
|
||||
* 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止，强制重启，由于垃圾收集导致 Init 容器完成的记录丢失。
|
||||
* 用户更新 Pod 的 Spec 导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启. 应用容器镜像的变更仅会重启应用容器。
|
||||
* Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。 这种情况不多见，必须由具备 root 权限访问 Node 的人员来完成。
|
||||
* 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止而强制重启，由于垃圾收集导致 Init 容器的完成记录丢失。
|
||||
|
||||
|
||||
|
||||
## 支持与兼容性
|
||||
|
||||
Apiserver 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。
|
||||
之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。
|
||||
`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 apiserver 能够安全的回退到 1.5.x 版本，而不会使存在的已创建 Pod 失去 Init 容器的功能。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
-->
|
||||
|
||||
|
||||
* [创建具有 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
|
||||
|
||||
* 阅读[创建包含 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
|
||||
* 学习如何[调测 Init 容器](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,256 @@
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Pod 概览
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Pod Overview
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
|
||||
-->
|
||||
本节提供了 `Pod` 的概览信息，`Pod` 是最小可部署的 Kubernetes 对象模型。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## 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.
|
||||
-->
|
||||
|
||||
Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
|
||||
Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个容器或少量紧密耦合并共享资源的容器组成。
|
||||
|
||||
<!--
|
||||
> [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.
|
||||
|
||||
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.
|
||||
-->
|
||||
|
||||
* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
|
||||
* **运行多个协同工作的容器的 Pod**。
|
||||
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
|
||||
这些位于同一位置的容器可能形成单个内聚的服务单元——一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”容器则刷新或更新这些文件。
|
||||
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)
|
||||
-->
|
||||
|
||||
[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)
|
||||
|
||||
<!--
|
||||
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)。
|
||||
|
||||
<!--
|
||||
### 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 怎样管理多个容器
|
||||
|
||||
Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。
|
||||
Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。
|
||||
容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。
|
||||
|
||||
<!--
|
||||
Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
|
||||
-->
|
||||
|
||||
注意，在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。
|
||||
只在容器紧密耦合的特定实例中使用此模式。
|
||||
例如，您可能有个充当共享卷中文件的 Web 服务器的容器，以及从远程源更新这些文件的单独的"挂斗"容器，如下图所示：
|
||||
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
|
||||
|
||||
<!--
|
||||
Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
|
||||
-->
|
||||
|
||||
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` 互相通信。
|
||||
当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。
|
||||
|
||||
<!--
|
||||
#### 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 可以指定一组共享存储 *卷*。
|
||||
Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。
|
||||
卷还允许 Pod 中的持久数据在重启 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
|
||||
|
||||
你很少在 Kubernetes 中直接创建单独的 Pod，甚至是单个存在的 Pod。
|
||||
这是因为 Pod 被设计成了相对短暂的一次性的实体。
|
||||
当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的节点上运行。
|
||||
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.
|
||||
-->
|
||||
重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
|
||||
-->
|
||||
|
||||
Pod 本身并不能自愈。
|
||||
如果 Pod 被调度到失败的节点，或者如果调度操作本身失败，则删除该 Pod；同样，由于缺乏资源或进行节点维护，Pod 在被驱逐后将不再生存。
|
||||
Kubernetes 使用了一个更高级的称为 *控制器* 的抽象，由它处理相对可丢弃的 Pod 实例的管理工作。
|
||||
因此，虽然可以直接使用 Pod，但在 Kubernetes 中，更为常见的是使用控制器管理 Pod。
|
||||
有关 Kubernetes 如何使用控制器实现 Pod 伸缩和愈合的更多信息，请参考 [Pod 和控制器](#pods-and-controllers)。
|
||||
|
||||
<!--
|
||||
### 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/)
|
||||
|
||||
控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。
|
||||
|
||||
<!--
|
||||
## Pod Templates
|
||||
|
||||
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/)、和
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。
|
||||
控制器使用 Pod 模板来制作实际使用的 Pod。
|
||||
下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
```
|
||||
|
||||
<!--
|
||||
Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.
|
||||
-->
|
||||
|
||||
Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状态。
|
||||
一旦饼干被切掉，饼干就与切割器没有关系。
|
||||
没有“量子纠缠”。
|
||||
随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。
|
||||
类似地，由副本控制器创建的 Pod 随后可以被直接更新。
|
||||
这与 Pod 形成有意的对比，Pod 指定了属于 Pod 的所有容器的当前期望状态。
|
||||
这种方法从根本上简化了系统语义，增加了原语的灵活性。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
* Learn more about Pod behavior:
|
||||
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* Other Pod Topics
|
||||
-->
|
||||
* 进一步了解 Pod 的行为：
|
||||
* [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* 其他 Pod 话题
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,402 @@
|
||||
---
|
||||
title: Pod 拓扑扩展约束
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Pod Topology Spread Constraints
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
|
||||
-->
|
||||
|
||||
可以使用_拓扑扩展约束_来控制 {{< glossary_tooltip text="Pods" term_id="Pod" >}} 在集群内故障域（例如地区，区域，节点和其他用户自定义拓扑域）之间的分布。这可以帮助实现高可用以及提升资源利用率。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Prerequisites
|
||||
-->
|
||||
|
||||
## 先决条件
|
||||
|
||||
<!--
|
||||
### Enable Feature Gate
|
||||
-->
|
||||
|
||||
### 启用功能
|
||||
|
||||
<!--
|
||||
Ensure the `EvenPodsSpread` feature gate is enabled (it is disabled by default
|
||||
in 1.16). See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
for an explanation of enabling feature gates. The `EvenPodsSpread` feature gate must be enabled for the
|
||||
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **and**
|
||||
{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}.
|
||||
-->
|
||||
|
||||
确保 `EvenPodsSpread` 功能已开启（在 1.16 版本中该功能默认关闭）。阅读[功能选项](/docs/reference/command-line-tools-reference/feature-gates/)了解如何开启该功能。`EvenPodsSpread` 必须在 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **和** {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} 中都要开启。
|
||||
|
||||
<!--
|
||||
### Node Labels
|
||||
-->
|
||||
|
||||
### 节点标签
|
||||
|
||||
<!--
|
||||
Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: `node=node1,zone=us-east-1a,region=us-east-1`
|
||||
-->
|
||||
|
||||
拓扑扩展约束依赖于节点标签来标识每个节点所在的拓扑域。例如，一个节点可能具有标签：`node=node1,zone=us-east-1a,region=us-east-1`
|
||||
|
||||
<!--
|
||||
Suppose you have a 4-node cluster with the following labels:
|
||||
-->
|
||||
|
||||
假设你拥有一个具有以下标签的 4 节点集群：
|
||||
|
||||
```
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
|
||||
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
|
||||
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
|
||||
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
|
||||
```
|
||||
|
||||
<!--
|
||||
Then the cluster is logically viewed as below:
|
||||
-->
|
||||
|
||||
然后从逻辑上看集群如下：
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters.
|
||||
-->
|
||||
|
||||
可以复用在大多数集群上自动创建和填充的[知名标签](/docs/reference/kubernetes-api/labels-annotations-taints/)，而不是手动添加标签。
|
||||
|
||||
<!--
|
||||
## Spread Constraints for Pods
|
||||
-->
|
||||
|
||||
## Pod 的拓扑约束
|
||||
|
||||
### API
|
||||
|
||||
<!--
|
||||
The field `pod.spec.topologySpreadConstraints` is introduced in 1.16 as below:
|
||||
-->
|
||||
|
||||
`pod.spec.topologySpreadConstraints` 字段定义如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: <integer>
|
||||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
```
|
||||
|
||||
<!--
|
||||
You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are:
|
||||
-->
|
||||
|
||||
可以定义一个或多个 `topologySpreadConstraint` 来指示 kube-scheduler 如何将每个传入的 Pod 根据与现有的 Pod 的关联关系在集群中部署。字段包括：
|
||||
|
||||
<!--
|
||||
- **maxSkew** describes the degree to which Pods may be unevenly distributed. It's the maximum permitted difference between the number of matching Pods in any two topology domains of a given topology type. It must be greater than zero.
|
||||
- **topologyKey** is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain.
|
||||
- **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
|
||||
- `DoNotSchedule` (default) tells the scheduler not to schedule it.
|
||||
- `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
|
||||
- **labelSelector** is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) for more details.
|
||||
-->
|
||||
|
||||
- **maxSkew** 描述 pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中匹配的 pod 之间的最大允许差值。它必须大于零。
|
||||
- **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值，则调度器会将这两个节点视为处于同一拓扑中。调度器试图在每个拓扑域中放置数量均衡的 pod。
|
||||
- **whenUnsatisfiable** 指示如果 pod 不满足扩展约束时如何处理：
|
||||
- `DoNotSchedule`（默认）告诉调度器不用进行调度。
|
||||
- `ScheduleAnyway` 告诉调度器在对最小化倾斜的节点进行优先级排序时仍对其进行调度。
|
||||
- **labelSelector** 用于查找匹配的 pod。匹配此标签的 pod 将被统计，以确定相应拓扑域中 pod 的数量。有关详细信息，请参考[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
|
||||
|
||||
<!--
|
||||
You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
|
||||
-->
|
||||
|
||||
执行 `kubectl explain Pod.spec.topologySpreadConstraints` 命令了解更多关于 topologySpreadConstraints 的信息。
|
||||
|
||||
<!--
|
||||
### Example: One TopologySpreadConstraint
|
||||
-->
|
||||
|
||||
### 例子：单个拓扑扩展约束
|
||||
|
||||
<!--
|
||||
Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
|
||||
-->
|
||||
|
||||
假设你拥有一个 4 节点集群，其中标记为 `foo:bar` 的 3 个 pod 分别位于 node1，node2 和 node3 中（`P` 表示 pod）：
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:
|
||||
-->
|
||||
|
||||
如果希望传入的 pod 均匀散布在现有的 pod 区域，则可以指定字段如下：
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
|
||||
|
||||
<!--
|
||||
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
|
||||
-->
|
||||
|
||||
`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:<any value>" 的节点上。`whenUnsatisfiable: DoNotSchedule` 告诉调度器，如果传入的 pod 不满足约束，则让它保持挂起状态。
|
||||
|
||||
<!--
|
||||
If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
|
||||
-->
|
||||
|
||||
如果调度器将传入的 pod 放入 "zoneA"，pod 分布将变为 [3, 1]，因此实际的倾斜为 2（3 - 1）。这违反了 `maxSkew: 1`。此示例中，传入的 pod 只能放置在 "zoneB" 上：
|
||||
|
||||
```
|
||||
+---------------+---------------+ +---------------+---------------+
|
||||
| zoneA | zoneB | | zoneA | zoneB |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| P | P | P | P | | P | P | P P | |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
You can tweak the Pod spec to meet various kinds of requirements:
|
||||
-->
|
||||
|
||||
可以调整 pod 规格以满足各种要求：
|
||||
|
||||
<!--
|
||||
- Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed onto "zoneA" as well.
|
||||
- Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4".
|
||||
- Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it’s preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.)
|
||||
-->
|
||||
|
||||
- 将 `maxSkew` 更改为更大的值，比如 "2"，这样传入的 pod 也可以放在 "zoneA" 上。
|
||||
- 将 `topologyKey` 更改为 "node"，以便将 pod 均匀分布在节点上而不是区域中。在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 pod 只能放在 "node4" 上。
|
||||
- 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`，以确保传入的 pod 始终可以调度（假设满足其他的调度 API）。但是，最好将其放置在具有较少匹配 pod 的拓扑域中。（请注意，此优先性与其他内部调度优先级（如资源使用率等）一起进行标准化。）
|
||||
|
||||
<!--
|
||||
### Example: Multiple TopologySpreadConstraints
|
||||
-->
|
||||
|
||||
### 例子：多个拓扑扩展约束
|
||||
|
||||
<!--
|
||||
This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
|
||||
-->
|
||||
|
||||
下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，其中 3 个标记为 `foo:bar` 的 pod 分别位于 node1，node2 和 node3 上（`P` 表示 pod）：
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:
|
||||
-->
|
||||
|
||||
可以使用 2 个拓扑扩展约束来控制 pod 在 区域和节点两个维度上进行分布：
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
|
||||
|
||||
<!--
|
||||
In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4".
|
||||
-->
|
||||
|
||||
在这种情况下，为了匹配第一个约束，传入的 pod 只能放置在 "zoneB" 中；而在第二个约束中，传入的 pod 只能放置在 "node4" 上。然后两个约束的结果加在一起，因此唯一可行的选择是放置在 "node4" 上。
|
||||
|
||||
<!--
|
||||
Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
|
||||
-->
|
||||
|
||||
多个约束可能导致冲突。假设有一个跨越 2 个区域的 3 节点集群：
|
||||
|
||||
```
|
||||
+---------------+-------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+
|
||||
| node1 | node2 | nod3 |
|
||||
+-------+-------+-------+
|
||||
| P P | P | P P |
|
||||
+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
|
||||
-->
|
||||
|
||||
如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求 "mypod" 只能放在 "node2" 上。pod 调度无法满足两种约束。
|
||||
|
||||
<!--
|
||||
To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`.
|
||||
-->
|
||||
|
||||
为了克服这种情况，可以增加 `maxSkew` 或修改其中一个约束，让其使用 `whenUnsatisfiable: ScheduleAnyway`。
|
||||
|
||||
<!--
|
||||
### Conventions
|
||||
-->
|
||||
|
||||
### 约定
|
||||
|
||||
<!--
|
||||
There are some implicit conventions worth noting here:
|
||||
-->
|
||||
|
||||
这里有一些值得注意的隐式约定：
|
||||
|
||||
<!--
|
||||
- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
|
||||
-->
|
||||
|
||||
- 只有与传入 pod 具有相同命名空间的 pod 才能作为匹配候选者。
|
||||
|
||||
<!--
|
||||
- Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that:
|
||||
1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA".
|
||||
2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
|
||||
-->
|
||||
|
||||
- 没有 `topologySpreadConstraints[*].topologyKey` 的节点将被忽略。这意味着：
|
||||
1. 位于这些节点上的 pod 不影响 `maxSkew` 的计算。在上面的例子中，假设 "node1" 没有标签 "zone"，那么 2 个 pod 将被忽略，因此传入的 pod 将被调度到 "zoneA" 中。
|
||||
2. 传入的 pod 没有机会被调度到这类节点上。在上面的例子中，假设一个带有标签 `{zone-typo: zoneC}` 的 "node5" 加入到集群，它将由于没有标签键 "zone" 而被忽略。
|
||||
|
||||
<!--
|
||||
- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
|
||||
-->
|
||||
|
||||
注意，如果传入 pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的标签不匹配，将会发生什么。在上面的例子中，如果移除传入 pod 的标签，pod 仍然可以调度到 "zoneB"，因为约束仍然满足。然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 pod，zoneB 有 1 个带有 {foo:bar} 标签的 pod。因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector` 与其自身的标签匹配。
|
||||
|
||||
<!--
|
||||
- If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.
|
||||
-->
|
||||
|
||||
- 如果传入的 pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，则将忽略不匹配的节点。
|
||||
|
||||
<!--
|
||||
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
|
||||
-->
|
||||
|
||||
假设有一个从 zonea 到 zonec 的 5 节点集群：
|
||||
|
||||
|
||||
```
|
||||
+---------------+---------------+-------+
|
||||
| zoneA | zoneB | zoneC |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | node5 |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| P | P | P | | |
|
||||
+-------+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
<!--
|
||||
and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
|
||||
-->
|
||||
|
||||
你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector` 也要一样处理。
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
|
||||
<!--
|
||||
## Comparison with PodAffinity/PodAntiAffinity
|
||||
-->
|
||||
|
||||
## 与 PodAffinity/PodAntiAffinity 相比较
|
||||
|
||||
<!--
|
||||
In Kubernetes, directives related to "Affinity" control how Pods are
|
||||
scheduled - more packed or more scattered.
|
||||
-->
|
||||
|
||||
在 Kubernetes 中，与 "Affinity" 相关的指令控制 pod 的调度方式（更密集或更分散）。
|
||||
|
||||
<!--
|
||||
- For `PodAffinity`, you can try to pack any number of Pods into qualifying
|
||||
topology domain(s)
|
||||
- For `PodAntiAffinity`, only one Pod can be scheduled into a
|
||||
single topology domain.
|
||||
-->
|
||||
|
||||
- 对于 `PodAffinity`，可以尝试将任意数量的 pod 打包到符合条件的拓扑域中。
|
||||
- 对于 `PodAntiAffinity`，只能将一个 pod 调度到单个拓扑域中。
|
||||
|
||||
<!--
|
||||
The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
|
||||
topology domains - to achieve high availability or cost-saving. This can also help on rolling update
|
||||
workloads and scaling out replicas smoothly.
|
||||
See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) for more details.
|
||||
-->
|
||||
|
||||
"EvenPodsSpread" 功能提供灵活的选项来将 pod 均匀分布到不同的拓扑域中，以实现高可用性或节省成本。这也有助于滚动更新工作负载和平滑扩展副本。有关详细信息，请参考[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation)。
|
||||
|
||||
<!--
|
||||
## Known Limitations
|
||||
-->
|
||||
|
||||
## 已知局限性
|
||||
|
||||
<!--
|
||||
As of 1.16, at which this feature is Alpha, there are some known limitations:
|
||||
-->
|
||||
|
||||
1.16 版本（此功能为 alpha）存在下面的一些限制：
|
||||
|
||||
<!--
|
||||
- Scaling down a `Deployment` may result in imbalanced Pods distribution.
|
||||
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
|
||||
-->
|
||||
|
||||
- `Deployment` 的缩容可能导致 pod 分布不平衡。
|
||||
- pod 匹配到污点节点是允许的。参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,399 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Pods
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
title: Pods
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
_Pods_ are the smallest deployable units of computing that can be created and
|
||||
managed in Kubernetes.
|
||||
-->
|
||||
|
||||
_Pods_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## What is a 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
|
||||
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 以特定于应用的“逻辑主机”为模型，它包含一个或多个应用容器，这些容器是相对紧密的耦合在一起；在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。
|
||||
|
||||
<!--
|
||||
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 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
|
||||
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
|
||||
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
|
||||
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
|
||||
filesystem.
|
||||
-->
|
||||
|
||||
Pod 中的所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信（如 SystemV 信号量或 POSIX 共享内存）方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。
|
||||
|
||||
Pod 中的应用也能访问共享卷，共享卷是 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/).
|
||||
|
||||
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
|
||||
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,
|
||||
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/))。
|
||||
|
||||
<!--
|
||||
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 的相关的资源（如卷等）也会被销毁进行重新创建。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
|
||||
|
||||
<!--
|
||||
*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%" >}}
|
||||
|
||||
|
||||
<!--
|
||||
## Motivation for pods
|
||||
|
||||
### 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.
|
||||
-->
|
||||
|
||||
## 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.
|
||||
-->
|
||||
|
||||
### 资源共享和通信
|
||||
|
||||
Pod 使它的组成容器间能够进行数据共享和通信。
|
||||
|
||||
Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个IP地址，该空间能与整个网络上的其他物理机或虚拟机进行完全通信。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
主机名被设置为 Pod 内的应用程序容器的 Pod 名称。请参考[组网的更多信息](/docs/concepts/cluster-administration/networking/)。
|
||||
|
||||
Pod 除了定义了 Pod 中运行的应用程序容器之外，Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留，并能在 Pod 内的应用程序之间共享。
|
||||
|
||||
<!--
|
||||
## Uses of pods
|
||||
|
||||
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:
|
||||
|
||||
* content management systems, file and data loaders, local cache managers, etc.
|
||||
* log and checkpoint backup, compression, rotation, snapshotting, etc.
|
||||
* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
|
||||
* proxies, bridges, and adapters
|
||||
* controllers, managers, configurators, and updaters
|
||||
-->
|
||||
|
||||
## 使用 Pod
|
||||
|
||||
Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的动机是支持位于同一位置的、共同管理的帮助程序，例如：
|
||||
|
||||
* 内容管理系统、文件和数据加载器、本地缓存管理器等。
|
||||
* 日志和检查点备份、压缩、旋转、快照等。
|
||||
* 数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。
|
||||
* 代理、桥接器和适配器
|
||||
* 控制器、管理器、配置器和更新器
|
||||
|
||||
|
||||
<!--
|
||||
Individual pods are not intended to run multiple instances of the same
|
||||
application, in general.
|
||||
|
||||
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)
|
||||
|
||||
<!--
|
||||
## Alternatives considered
|
||||
|
||||
_Why not just run multiple programs in a single (Docker) container?_
|
||||
|
||||
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.
|
||||
1. Decoupling software dependencies. The individual containers may be
|
||||
versioned, rebuilt and redeployed independently. Kubernetes may even support
|
||||
live updates of individual containers someday.
|
||||
1. Ease of use. Users don't need to run their own process managers, worry about
|
||||
signal and exit-code propagation, etc.
|
||||
1. Efficiency. Because the infrastructure takes on more responsibility,
|
||||
containers can be lighter weight.
|
||||
-->
|
||||
|
||||
## 备选方案的思考
|
||||
|
||||
_为什么不在单个（Docker）容器中运行多个程序？_
|
||||
|
||||
1. 透明度。Pod 内的容器对基础设施可见，使得基础设施能够向这些容器提供服务，例如流程管理和资源监控。这为用户提供了许多便利。
|
||||
1. 解耦软件依赖关系。可以独立地对单个容器进行版本控制、重新构建和重新部署。Kubernetes 有一天甚至可能支持单个容器的实时更新。
|
||||
1. 易用性。用户不需要运行他们自己的进程管理器、也不用担心信号和退出代码传播等。
|
||||
1. 效率。因为基础结构承担了更多的责任，所以容器可以变得更加轻量化。
|
||||
|
||||
<!--
|
||||
_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
|
||||
simplified management.
|
||||
-->
|
||||
|
||||
_为什么不支持基于亲和性的容器联合调度？_
|
||||
|
||||
这种处理方法尽管可以提供同址，但不能提供 Pod 的大部分好处，如资源共享、IPC、有保证的命运共享和简化的管理。
|
||||
|
||||
<!--
|
||||
## Durability of pods (or lack thereof)
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
-->
|
||||
|
||||
## Pod 的持久性（或稀缺性）
|
||||
|
||||
Pod 并没想被视为持久的实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。
|
||||
|
||||
一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。
|
||||
控制器提供集群范围的自修复以及复制和滚动管理。
|
||||
像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。
|
||||
|
||||
<!--
|
||||
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
|
||||
-->
|
||||
|
||||
在集群调度系统中，使用 API 合集作为面向用户的主要原语是比较常见的，包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、和 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
|
||||
|
||||
<!--
|
||||
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 暴露为原语是为了便于：
|
||||
|
||||
* 调度器和控制器可插拔性
|
||||
* 支持 Pod 级别的操作，而不需要通过控制器 API "代理" 它们
|
||||
* 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 的终止
|
||||
|
||||
因为 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. 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 中消失，从客户端也不再可见。
|
||||
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
默认情况下，所有删除在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` 标志。
|
||||
|
||||
<!--
|
||||
### 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 还是会在被强制删除前设置一个小的宽限期。
|
||||
|
||||
强制删除对某些 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'`
|
||||
|
||||
<!--
|
||||
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'`
|
||||
-->
|
||||
|
||||
如果主节点的版本低于 v1.1，那么特权 Pod 就不能被创建。如果用户尝试创建有特权容器的 Pod，将会得到下面的错误信息：
|
||||
`The Pod "FooPodName" is invalid.
|
||||
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
|
||||
|
||||
<!--
|
||||
## 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)。
|
||||
@@ -1,72 +1,151 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- jessfraz
|
||||
title: Pod Preset
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
本文提供了 PodPreset 的概述。 在 pod 创建时，用户可以使用 `podpreset` 对象将特定信息注入
|
||||
pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
本文提供了 PodPreset 的概述。 在 Pod 创建时，用户可以使用 PodPreset 对象将特定信息注入 Pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Understanding Pod Presets
|
||||
|
||||
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。
|
||||
`Pod Preset` 是一种 API 资源，在 Pod 创建时，用户可以用它将额外的运行时需求信息注入 Pod。
|
||||
使用[标签选择器（label selector）](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 Pod。
|
||||
|
||||
使用 Pod Preset 使得 pod 模板编写者不必显式地为每个 pod 设置信息。
|
||||
这样，使用特定服务的 pod 模板编写者不需要了解该服务的所有细节。
|
||||
<!--
|
||||
Using a Pod Preset allows pod template authors to not have to explicitly provide
|
||||
all information for every pod. This way, authors of pod templates consuming a
|
||||
specific service do not need to know all the details about that service.
|
||||
-->
|
||||
|
||||
使用 Pod Preset 使得 Pod 模板编写者不必显式地为每个 Pod 设置信息。
|
||||
这样，使用特定服务的 Pod 模板编写者不需要了解该服务的所有细节。
|
||||
|
||||
<!--
|
||||
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
|
||||
-->
|
||||
|
||||
了解更多的相关背景信息，请参考 [ PodPreset 设计提案](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)。
|
||||
|
||||
<!--
|
||||
## How It Works
|
||||
|
||||
Kubernetes provides an admission controller (`PodPreset`) which, when enabled,
|
||||
applies Pod Presets to incoming pod creation requests.
|
||||
When a pod creation request occurs, the system does the following:
|
||||
-->
|
||||
|
||||
## PodPreset 如何工作
|
||||
|
||||
Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset
|
||||
应用于接收到的 pod 创建请求中。
|
||||
当出现 pod 创建请求时，系统会执行以下操作：
|
||||
Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset
|
||||
应用于接收到的 Pod 创建请求中。
|
||||
当出现 Pod 创建请求时，系统会执行以下操作：
|
||||
|
||||
<!--
|
||||
1. Retrieve all `PodPresets` available for use.
|
||||
1. Check if the label selectors of any `PodPreset` matches the labels on the
|
||||
pod being created.
|
||||
1. Attempt to merge the various resources defined by the `PodPreset` into the
|
||||
Pod being created.
|
||||
1. On error, throw an event documenting the merge error on the pod, and create
|
||||
the pod _without_ any injected resources from the `PodPreset`.
|
||||
1. Annotate the resulting modified Pod spec to indicate that it has been
|
||||
modified by a `PodPreset`. The annotation is of the form
|
||||
`podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>"`.
|
||||
-->
|
||||
|
||||
1. 检索所有可用 `PodPresets` 。
|
||||
1. 检查 `PodPreset` 的标签选择器与要创建的 pod 的标签是否匹配。
|
||||
1. 尝试合并 `PodPreset` 中定义的各种资源，并注入要创建的 pod。
|
||||
1. 发生错误时抛出事件，该事件记录了 pod 信息合并错误，同时在 _不注入_ `PodPreset` 信息的情况下创建 pod。
|
||||
1. 为改动的 pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如：
|
||||
1. 检查 `PodPreset` 的标签选择器与要创建的 Pod 的标签是否匹配。
|
||||
1. 尝试合并 `PodPreset` 中定义的各种资源，并注入要创建的 Pod。
|
||||
1. 发生错误时抛出事件，该事件记录了 pod 信息合并错误，同时在 _不注入_ `PodPreset` 信息的情况下创建 Pod。
|
||||
1. 为改动的 Pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如：
|
||||
`podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"`。
|
||||
|
||||
一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset`
|
||||
<!--
|
||||
Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be
|
||||
applied to zero or more pods. When a `PodPreset` is applied to one or more
|
||||
Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
|
||||
`VolumeMounts`, Kubernetes modifies the container spec for all containers in
|
||||
the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
|
||||
-->
|
||||
|
||||
一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset`
|
||||
可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes
|
||||
修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod
|
||||
中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。
|
||||
|
||||
|
||||
{{< note >}}
|
||||
**注意：** Pod Preset 能够在适当的时候修改 Pod spec 的 `spec.containers` 字段，
|
||||
但是不会应用于 `initContainers` 字段。
|
||||
<!--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` 字段。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Disable Pod Preset for a Specific Pod
|
||||
|
||||
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"` 的注解。
|
||||
在一些情况下，用户不希望 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
|
||||
|
||||
为了在集群中使用 Pod Preset，必须确保以下几点：
|
||||
|
||||
1. 已启用 api 类型 `settings.k8s.io/v1alpha1/podpreset`。 这可以通过在 API 服务器的
|
||||
`--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。
|
||||
1. 已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--admission-control`
|
||||
配置项中包含 `PodPreset` 。
|
||||
1. 已经通过在相应的名字空间中创建 `PodPreset` 对象，定义了 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.
|
||||
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.
|
||||
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. 已经通过在相应的命名空间中创建 `PodPreset` 对象，定义了 Pod Preset。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [使用 PodPreset 将信息注入 Pods](/docs/tasks/inject-data-application/podpreset/)
|
||||
|
||||
<!--
|
||||
* [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
|
||||
-->
|
||||
* [使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user