Merge release 1.12 into release 1.13 (#14171)
* ZH-trans: Update coarse-parallel-processing-work-queue.md (#11862) * ZH-trans: Update coarse-parallel-processing-work-queue.md * Update coarse-parallel-processing-work-queue.md * zh-trans: add /docs/concepts/architecture/cloud-controller.md (#11799) * docs/concepts/architecture/cloud-controller.md * docs/concepts/architecture/cloud-controller.md * docs/concepts/architecture/cloud-controller.md * fix * fix * fix * zh-trans: /docs/contribute/style/kubernetes-components.md (#11838) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/generate-ref-docs/kubernetes-components.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * Update weave-network-policy.md (#11858) * ZH-trans: add Update define-environment-variable-container.md (#11859) * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update fine-parallel-processing-work-queue.md (#11863) * Update fine-parallel-processing-work-queue.md * Update fine-parallel-processing-work-queue.md * Update setup-extension-api-server.md (#11864) * zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md (#11798) * zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md * Update kubeadm-join.md * Create kubeadm_join.md * zh-trans: update docs/concepts/containers/images.md (#11877) * zh-trans: update docs/concepts/containers/images.md * zh-trans: update docs/concepts/containers/images.md * Update kubeadm_alpha_phase_controlplane.md (#11878) * 更新第 115 行翻译 * zh_trans: kubeadm_token_generate.md (#11884) * zh_trans: kubeadm_token_generate.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md * Better translation Better translation * zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md (#11886) zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md * zh-trans:add content/zh/docs/reference/issues-security (#11890) * zh-trans: add content/zh/docs/tutorials/online-training/overview.md (#11892) * zh_trans: kubeadm_token_delete.md (#11883) * zh_trans: kubeadm_token_delete.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md * fix tpye error fix tpye error * Better translation Better translation * zh_trans: independent/create-cluster-kubeadm.md (#11882) * zh_trans: independent/create-cluster-kubeadm.md zh_trans: docs/setup/independent/create-cluster-kubeadm.md * fix word style error * fix type error * better zhtran better zhtran * fix "Create" -> "create" fix "Create" -> "create" * zh-trans: add docs/concepts/storage/storage-classes.md (#11788) * ZH-trans: fixing formatting errors (#11661) * ZH-trans: fixing formatting errors * Update ZH-trans: fixing formatting errors storage-classes zh part 1 * storage-classes zh trans * fix typo update trans for provisioner & fix typo * fix typo * 根据校对更新翻译 * zh_trans: kubeadm-token.md (#11898) zh_trans: /docs/reference/setup-tools/kubeadm/kubeadm-token.md * zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md (#11900) * zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md * Update quality-service-pod.md * zh_trans: kubeadm_alpha_phase_bootstrap-token_node.md (#11897) zh_trans: Path：/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md * zh-trans: add /docs/concepts/storage/volumes.md (#11767) * zh-trans: add /docs/concepts/storage/volumes.md zh-trans: add /docs/concepts/storage/volumes.md * Update volumes.md * Update volumes.md * self-review * Update volumes.md * fix docs format error (#11934) fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/ * Update cloud-controller.md (#11922) * zh-trans: /docs/reference/glossary/approver.md (#11924) zh-trans: /docs/reference/glossary/approver.md * zh-trans: add docs/setup/on-premises-vm/dcos.md (#11891) * zh-trans: add docs/setup/on-premises-vm/dcos.md * Update content/zh/docs/setup/on-premises-vm/dcos.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: /docs/tasks/configure-pod-container/configure-persistent-vo… (#11915) * zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md * Update configure-persistent-volume-storage.md * zh_trans: kubeadm_alpha.md (#11902) * zh_trans: kubeadm_alpha.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md * Better translation Better translation * zh-trans: /docs/reference/glossary/downstream.md (#11931) * zh-trans: /docs/reference/glossary/downstream.md zh-trans: /docs/reference/glossary/downstream.md * Update downstream.md * Update downstream.md * ZH-trans: Update install-kubeadm.md (#11955) * fix typo of install-kubeadm.md fix typo of install-kubeadm.md * Update install-kubeadm.md * zh-trans: add kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md (#11952) * zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md * Update kubeadm_alpha_phase_certs_renew_all.md * renew 的翻译更新为续期 * zh-trans:kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md (#11953) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md * Update kubeadm_alpha_phase_certs_renew_etcd-peer.md * zh-trans: /docs/contribute/generate-ref-docs/kubectl.md (#11941) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * fix docs format error (#11936) fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/ * Update pull request (#11921) * Update pull request (#11960) * ZH-trans: add kubefed-options.md (#11956) * Update ZH-trans: add kubefed-options.md * Update kubefed-options.md * ZH-trans: add generated/... (#11880) * Update pull request * Update kubeadm_alpha_phase_certs_renew.md * Update pull request (#11881) * ZH-trans: add generated/... (#11879) * Update pull request * Resolving file conflicts * zh-trans: add zh/ docs/tasks/configure-pod-container/configure-servic… (#11889) * zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md * Update configure-service-account.md * Update configure-service-account.md * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md (#11875) * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md * zh-trans:update kubelet-garbage-collection.md * zh_trans: kubeadm_alpha_phase_kubeconfig_user.md (#11901) * zh_trans: kubeadm_alpha_phase_kubeconfig_user.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md * Better translation * zh-trans:add docs/reference/using-api/client-libraries.md (#11958) * zh-trans:add docs/reference/using-api/client-libraries.md * Update content/zh/docs/reference/using-api/client-libraries.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: add pull-image-private-registry.md (#11912) * zh-trans: add pull-image-private-registry.md zh-trans: add pull-image-private-registry.md * Update pull-image-private-registry.md * Update pull-image-private-registry.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config_annotate-cri.md (#11972) * Create kubeadm_alpha_phase_kubelet_config_annotate-cri.md * Update kubeadm_alpha_phase_kubelet_config_annotate-cri.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config.md (#11974) * Create kubeadm_alpha_phase_kubelet_config.md * Update kubeadm_alpha_phase_kubelet_config.md * fix Typo "##" -> "## " (#12011) * fix Typo "##" -> "## " fix Typo "##" -> "## " * update basic-stateful-set.md * fix web style error (#12010) fix web style error * Create kubeadm_alpha_phase_selfhosting.md (#12006) * Create kubeadm_alpha_phase_controlplane_apiserver.md (#12005) * zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitor… (#11995) * zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md * Update resource-usage-monitoring.md * Update resource-usage-monitoring.md * zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md (#11990) zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md * zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md (#11989) zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md * Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md (#11969) * Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md * Update kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md * zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md (#11962) * zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md * Update debug-init-containers.md * zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md (#11930) * zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md * Update horizontal-pod-autoscaler.md * zh-trans: add /docs/tasks/configure-pod-container/configure-projected… (#11911) * zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md * Update configure-projected-volume-storage.md * Update configure-projected-volume-storage.md * zh-trans: /docs/tasks/configure-pod-container/extended-resource.md (#11918) * zh-trans: /docs/tasks/configure-pod-container/extended-resource.md zh-trans: /docs/tasks/configure-pod-container/extended-resource.md * Update extended-resource.md * Update extended-resource.md * zh-trans: add translate-compose-kubernetes.md (#11910) * zh-trans: add translate-compose-kubernetes.md zh-trans: add translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * zh-trans: zh/docs/reference/glossary/flexvolume.md (#11925) * zh-trans: zh/docs/reference/glossary/flexvolume.md zh-trans: zh/docs/reference/glossary/flexvolume.md * Update flexvolume.md * zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md (#11947) * zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_create.md * better translation better translation * zh-trans:add docs/setup/turnkey/alibaba-cloud.md (#11959) * zh_trans: kubeadm_completion.md (#11895) * zh_trans: kubeadm_completion.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md * Better translation Better translation * Update kubeadm_completion.md * better translation better translation * zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md (#11961) * zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md * Update crictl.md * ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-ca.md (#11968) * ZH-trans: add kubeadm_alpha_phase_controlplane_all.md (#11970) * Create kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * ZH-trans: add kubeadm_alpha_phase_upload-config.md (#11971) * Create kubeadm_alpha_phase_upload-config.md * Update kubeadm_alpha_phase_upload-config.md * Update kubeadm_alpha_phase_upload-config.md * ZH-trans: Fixed some incorrect translations (#11973) * zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-… (#11977) * zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md * Update determine-reason-pod-failure.md * zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md (#11988) * zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md * Update local-debugging.md * zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md (#11996) zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md * zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-cont… (#11998) * zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md * Update get-shell-running-container.md * zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md (#12001) zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md * ZH-trans: ad kubeadm_alpha_phase_kubelet_config_write-to-disk.md (#12004) * Create kubeadm_alpha_phase_kubelet_config_write-to-disk.md * Update kubeadm_alpha_phase_kubelet_config_write-to-disk.md * Remove old-generated kubefed docs (generated on 25-march-2018) (#12093) * Update _index.md (#12061) * Update kubeadm_reset.md (#12047) * ZH-trasn: add kubeadm_alpha_phase_kubeconfig_controller-manager.md (#12032) * Create kubeadm_alpha_phase_kubeconfig_controller-manager.md * Update kubeadm_alpha_phase_kubeconfig_controller-manager.md * ZH-trans: add kubeadm_alpha_phase_preflight_node.md (#12035) * Create kubeadm_alpha_phase_preflight_node.md * Update kubeadm_alpha_phase_preflight_node.md * Update kubeadm_alpha_phase_preflight_node.md * ZH-trans: add kubeadm_alpha_phase_controlplane_scheduler.md (#12031) * Create kubeadm_alpha_phase_controlplane_scheduler.md * Update kubeadm_alpha_phase_controlplane_scheduler.md * ZH-trans: add kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md (#12039) * Create kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md * Update kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md * ZH-trans: add kubeadm_alpha_phase_kubelet_write-env-file.md (#12034) * Create kubeadm_alpha_phase_kubelet_write-env-file.md * Update kubeadm_alpha_phase_kubelet_write-env-file.md * ZH-trans: add kubeadm_upgrade_node_experimental-control-plane.md (#12036) * Create kubeadm_upgrade_node_experimental-control-plane.md * Update kubeadm_upgrade_node_experimental-control-plane.md * Create kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md (#12038) * Create kubeadm_alpha_phase_etcd.md (#12040) * ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-server.md (#12041) * Create kubeadm_alpha_phase_certs_renew_etcd-server.md * Update kubeadm_alpha_phase_certs_renew_etcd-server.md * Update advanced.md (#12044) * ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md (#12042) * Create kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_version.md (#12046) * Update _index.md (#12063) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md (#12085) zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md * ZH-trans: add kubeadm_alpha_phase_certs_etcd-peer.md (#12037) * Create kubeadm_alpha_phase_certs_etcd-peer.md * Update kubeadm_alpha_phase_certs_etcd-peer.md * Update kubeadm_alpha_phase_certs_etcd-peer.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config_download.md (#12033) * Create kubeadm_alpha_phase_kubelet_config_download.md * Update kubeadm_alpha_phase_kubelet_config_download.md * zh-trans: add docs/tasks/access-application-cluster/_index.md (#12048) * zh-trans: update cpu-constraint-namespace.md and cpu-default-namespace.md (#12106) * ZH-trans: update kubeadm_alpha_phase_upload-config.md (#12110) * zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md (#12022) * zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md * Update kubefed_unjoin.md * Update kubefed_unjoin.md * Update kubefed_unjoin.md * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12114) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md * Update kubeadm_alpha_phase_certs_apiserver.md * Update kubeadm_alpha_phase_certs_apiserver.md * zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md (#12088) * zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md * Update docker-cli-to-kubectl.md * zh-trans: /docs/reference/kubectl/conventions.md (#12089) * zh-trans: /docs/reference/kubectl/conventions.md zh-trans: /docs/reference/kubectl/conventions.md * Update conventions.md * zh-trans organize-cluster-access-kubeconfig.md (#12094) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md (#12086) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md * Update kubefed.md * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md (#12029) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md * Update kubefed_join.md * Update kubefed_join.md * zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md (#12020) * zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md * Update kubefed_init.md * Update kubefed_init.md * Update kubefed_init.md * zh-trans: add docs/setup/independent/control-plane-flags.md (#12043) * zh-trans: add docs/setup/independent/control-plane-flags.md * update content/zh/docs/setup/independent/control-plane-flags.md * zh-trans:/docs/tasks/tools/install-kubectl.md (#11992) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * zh-trans: add /docs/concepts/cluster-administration/manage-deployment.md (#11899) * add /docs/concepts/cluster-administration/manage-deployment.md * 更新部分翻译，去除多余的反引号 * 更新部分翻译 * zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md (#12045) * zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md * update docs/tasks/service-catalog/install-service-catalog-using-sc.md * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md (#12087) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md * Update kubefed_options.md * Update kubefed_options.md * zh-trans: Fix some blog links issue (#12115) * zh-trans: Fix some blog links issue * Revert the space change * update Set Kubelet parameters via a config file (#12150) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md (#12185) zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12184) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md * Update kubeadm_alpha_phase_etcd_local.md * zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md (#12130) zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md * zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md (#12131) zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md * zh-trans: /docs/contribute/generate-ref-docs/kubernetes-api.md (#12141) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * zh-trans:/docs/concepts/overview/object-management-kubectl/imperative… (#12151) * zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md * Update imperative-config.md * ZH-trans: added a blog post Chinese translation: 2018-05-01-developing-on-kubernetes.md (#12009) * added a blog post chinese translation * Update 2018-05-01-developing-on-kubernetes.md apply some suggested changes per review comments * Update 2018-05-01-developing-on-kubernetes.md cont to review and improve the wording, up to squash * more update and rewording * ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md (#12209) * ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md * Update kubeadm_alpha_phase_kubelet_config_enable-dynamic.md * ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md (#12210) * ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md * Update kubeadm_alpha_phase_certs_renew_apiserver.md * Update kubeadm_alpha_phase_certs_renew_apiserver.md * ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-client.md (#12212) * fix docs style (#12225) * fix docs style fix docs style * fix docs style fix docs style * ZH-trans: add rbac.md (#12263) * ZH-trans: add rbac.md * Update rbac.md * ZH-trans: add persistent-volume-claim.md (#12264) * ZH-trans: add persistent-volume-claim.md * Update persistent-volume-claim.md * Update persistent-volume-claim.md * Update docker-cli-to-kubectl.md (#12288) * ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md (#12285) * ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md * Update kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md * ZH-trans: add coredns.md (#12282) * ZH-trans: add coredns.md * Update coredns.md * ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md (#12286) * ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_etcd-healthcheck-client.md * ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md (#12284) * ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md * Update kubeadm_alpha_phase_kubeconfig_kubelet.md * ZH-trans: add service-account.md (#12261) * ZH-trans: add service-account.md * Update service-account.md * ZH-trans: add security-context.md (#12262) * ZH-trans: add security-context.md * Update security-context.md * Update security-context.md * Update security-context.md * fix typo "_必须_" -> "必须" (#12300) fix typo "_必须_" -> "必须" * fix docs style error (#12307) fix docs style error * Create explore-interactive.html (#12311) * fix docs style error (#12314) fix docs style error * ZH-trans: add kube-controller-manager.md (#12260) * ZH-trans: add kube-controller-manager.md * Update kube-controller-manager.md * Update kube-controller-manager.md * Update kube-controller-manager.md * zh-trans: /docs/contribute/localization.md (#12295) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/localization.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/localization.md; update2 Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * ZH-trans: update tools.md (#12320) ZH-trans: update tools.md * ZH-trans: fix "kubead -config" -> "kubeadm-config" (#12319) * ZH-trans: update kubeadm_config.md * fix style error * correct "availability” trans for chinese (#12394) * ZH-trans:/docs/tasks/debug-application-cluster/debug-service.md (#12275) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * Translate some remnant partials for localization (#12240) * zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md (#12415) * zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md * Update limit-storage-consumption.md * Update limit-storage-consumption.md * update link to SSH tunneling (#12615) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans: update content/zh/docs/setup/certificates.md (#12620) * ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md (#12619) * ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md * Update kubeadm_alpha_phase_certs_apiserver-kubelet-client.md * zh-trans: node-conformance.md (#12356) * zh-trans: node-conformance.md zh-trans: node-conformance.md * better translation better translation * zh-trans: translate docs/getting-started-guides/ubuntu/operational-co… (#12353) * zh-trans: translate docs/getting-started-guides/ubuntu/operational-considerations.md * Adopt PR suggestions * add period sign * zh-trans: krib.md (#12363) * zh-trans: krib.md zh-trans: krib.md * Update krib.md * Update krib.md * Update krib.md * Update krib.md * zh-trans: /docs/tasks/administer-federation/events.md (#12411) * zh-trans: /docs/tasks/administer-federation/events.md zh-trans: /docs/tasks/administer-federation/events.md * Update events.md * Update events.md * zh-trans: /docs/setup/turnkey/azure.md (#12412) zh-trans: /docs/setup/turnkey/azure.md * zh-trans:/docs/tasks/administer-federation/hpa.md & /docs/tasks/administer-cluster/extended-resource-node.md (#12432) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * Add arm64, ppc64le and s390x platforms for calico (#12666) Signed-off-by: PingWang <wang.ping5@zte.com.cn> add only Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans: developing-cloud-controller-manager.md (#12413) * zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md * Update developing-cloud-controller-manager.md * fix typo: delete useless "**" * Update developing-cloud-controller-manager.md * ZH-trans: add 2018-05-01-developing-on-kubernetes.md (#12814) * ZH-trans: update encrypt-data.md (#12939) * ZH-trans: update encrypt-data.md * Update encrypt-data.md * ZH-trans: add example-task-template.md (#12940) * ZH-trans: add example-task-template.md * Update example-task-template.md * Added Instana to tools (#12978) Instana is already available in the english version of the text, therefore I added it here too. Hope my skills were enough to make the text still correct :-) * ZH-trans: add expose-interactive.html (#12965) * ZH-trans: add expose-interactive.html * Update content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html Co-Authored-By: xichengliudui <1693291525@qq.com> * ZH-trans: add cloudstack.md (#12967) * Create cloudstack.md * Update cloudstack.md * Update cloudstack.md * Update cloudstack.md * ZH-trans: add container-lifecycle-hooks.md (#12941) * ZH-trans: add container-lifecycle-hooks.md * Update container-lifecycle-hooks.md * translate content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md to chinese (#12904) * ZH-trans: add expose-external-ip-address.md (#12955) * ZH-trans: add expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * ZH-trans: add dns-horizontal-autoscaling.md (#12948) * ZH-trans: add dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * zh-trans: update content/zh/docs/concepts/_index.md (#13182) * zh-trans: update content/zh/docs/reference/access-authn-authz/node.md (#13181) * Update dns-horizontal-autoscaling.md (#13119) * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * ZH-trans: add 2018-10-03-kubedirector.md (#13048) * ZH-trans: add 2018-10-03-kubedirector.md * Update 2018-10-03-kubedirector.md * Update 2018-10-03-kubedirector.md * ZH-trans: add guestbook.md (#12953) * ZH-trans: add guestbook.md * Update guestbook.md * Update guestbook.md * Update guestbook.md * Update guestbook.md * ZH-trans: add set-up-placement-policies-federation.md (#12947) * ZH-trans: add set-up-placement-policies-federation.md * update pull request * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * ZH-trans: add service-accounts-admin.md (#13047) * ZH-trans: add service-accounts-admin.md * Update service-accounts-admin.md * Update service-accounts-admin.md * ZH-trans: add update-api-object-kubectl-patch.md (#12943) * ZH-trans: add update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * ZH-trans: add parallel-processing-expansion.md (#12944) * ZH-trans: add parallel-processing-expansion.md * Update parallel-processing-expansion.md * Update parallel-processing-expansion.md * zh-trans: add 2018-12-05-new-contributor-shanghai.md (#12778) * add zh 2017-03-00-Five-Days-Of-Kubernetes-1-6.md add zh 2018-12-05-new-contributor-shanghai.md * Delete 2017-03-00-Five-Days-Of-Kubernetes-1-6.md * zh-trans: /docs/contribute/style/write-new-topic.md (#12572) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/style/write-new-topic.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * zh-trans: update content/zh/docs/setup/salt.md (#13202) * zh-trans: add docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#13198) * ZH-trans: add kubeadm_upgrade_diff.md (#13170) * ZH-trans: add kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * zh-trans: update docs/reference/access-authn-authz/authorization.md (#13180) * zh-trans: update docs/reference/setup-tools/kubeadm/kubeadm-config.md (#13179) * zh-trans: add docs/concepts/storage/dynamic-provisioning.md (#13171) * ZH-trans: add 2015-05-00-Kubernetes-On-Openstack.md (#13149) * ZH-trans: add Kubernetes开源项目产品经理 * Update 2015-05-00-Kubernetes-On-Openstack.md * ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md (#13131) * ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md * Update 2015-03-00-Welcome-To-Kubernetes-Blog.md * ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md (#13123) * ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md * Update 2015-06-00-Slides-Cluster-Management-With.md * Create 2015-03-00-Kubernetes-Gathering-Videos.md (#13124) * ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md (#13129) * ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md * Update 2015-03-00-Weekly-Kubernetes-Community-Hangout.md * ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md (#13130) * ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md * Update 2015-04-00-Kubernetes-Release-0150.md * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md (#13132) * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md (#13147) * ZH-trans: add 2015-05-00-Weekly-Kubernetes-Community-Hangout.md (#13148) * ZH-trans: add flannel_multi_node_cluster.md (#13195) * ZH-trans: add flannel_multi_node_cluster.md * Update flannel_multi_node_cluster.md * Update flannel_multi_node_cluster.md * zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md (#13200) * zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md * Update kubelet-authentication-authorization.md * zh-trans: /docs/tasks/administer-cluster/out-of-resource.md (#12879) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * . * zh-trans: update docs/setup/node-conformance.md (#13201) * zh-trans: update docs/setup/node-conformance.md * zh-trans: update docs/setup/on-premises-vm/dcos.md * zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md (#13227) * zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md * Update content/zh/blog/_posts/2018-10-15-steering-election-results.md Co-Authored-By: SataQiu <1527062125@qq.com> * Add @xichengliudui to sig-docs-zh-owners (release-1.12) (#13167) * Add @xichengliudui to sig-docs-zh-owners * Update OWNERS_ALIASES * ZH-trans: add coreos.md (#13193) * ZH-trans: coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * add SataQiu as a sig-docs-zh-owner (#13271) * Fix relative links issue in zh content (#13312) * `http://kubernetes.io/docs/` -> `/docs/` * `https://kubernetes.io/docs/` -> `/docs/` * zh-trans: add docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md (#13194) * zh-trans: add docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md * Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update kubeadm-upgrade.md * ZH-trans: add kubeadm-upgrade-ha-1-12.md (#13306) * ZH-trans: add kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update config.toml (#13408) * zh-trans: add content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md (#13221) * zh-trans: add content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md (#13236) * zh-trans: add content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md (#13274) * zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md (#13268) * zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md * ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13427) * ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md * Update 2017-10-00-Five-Days-Of-Kubernetes-18.md * zh-trans: add content/zh/docs/tasks/administer-federation/daemonset.md (#13239) * message * more message * remove data.json * ZH-trans: add aws.md (#13276) * ZH-trans: add aws.md * Update aws.md * Update aws.md * ZH-trans: add cluster-interactive.html (#13479) * ZH-trans: add cluster-interactive.html * Update cluster-interactive.html * ZH-trans: add update-intro.html (#13480) * Create update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * ZH-trans: add README.md (#13235) * ZH-trans: add vendoring * Update README.md * zh: docs/cocepts/cluster-administration/logging.md (#13541) * zh: docs/cocepts/cluster-administration/logging.md * Update logging.md * zh-trans: update docker-cli-to-kubectl.md (#13591) * Update docker-cli-to-kubectl.md * Update docker-cli-to-kubectl.md * zh-trans: update advanced.md (#13592) * ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md (#13424) * ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md * Update 2017-11-00-Autoscaling-In-Kubernetes.md * ZH-trans: add fedora_manual_config.md (#13439) * ZH-trans: add fedora_manual_config.md * Update fedora_manual_config.md * zh-trans: content/zh/docs/concepts/overview/working-with-objects/labe… (#12277) * zh-trans: content/zh/docs/concepts/overview/working-with-objects/labels.md * update trans * update trans * zh: docs/contribute/start.md trans (#13632) * zh：docs/contribute/start.md trans * Update start.md * Update start.md * Update start.md * Update start.md * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * zh-trans: update docs/reference/setup-tools/kubefed (#13729) * Update 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13472) * zh-trans: add configure-multiple-schedulers.md (#13492) * zh-trans: add configure-multiple-schedulers.md * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update configure-multiple-schedulers.md * Update configure-multiple-schedulers.md * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update configure-multiple-schedulers.md * zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md (#13551) * zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md * Update share-process-namespace.md * zh-trans: update docs/admin/accessing-the-api.md (#13744) * zh-trans: add content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md (#13303) * ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md (#13241) * ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * ZH-trans: add 2016-07-00-Citrix-Netscaler-And-Kubernetes.md (#13242) * ZH-trans: add 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * zh-trans: update docs/admin/bootstrap-tokens.md (#13770) * zh-trans: update content/zh/docs/admin/cluster-large.md (#13771) * zh-trans: update content/zh/docs/admin/kube-apiserver.md (#13774) * zh-trans: update content/zh/docs/admin/kube-apiserver.md * Update kube-apiserver.md * Update content/zh/docs/admin/kube-apiserver.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/admin/multiple-zones.md (#13775) * zh-trans: update content/zh/docs/admin/multiple-zones.md * Update multiple-zones.md * zh-trans: update node-conformance.md and ovs-networking.md (#13776) * zh-trans: update high-availability/_index.md and authorization/webhook.md (#13780) * zh-trans: update content/zh/docs/admin/authorization/_index.md (#13779) * zh-trans: update content/zh/docs/admin/authorization/_index.md * Update _index.md * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/admin/authorization/abac.md (#13777) * zh-trans: update content/zh/docs/admin/authorization/abac.md * Update content/zh/docs/admin/authorization/abac.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update abac.md * zh-trans: update content/zh/docs/admin/service-accounts-admin.md (#13778) * zh-trans: update content/zh/docs/admin/service-accounts-admin.md * Update content/zh/docs/admin/service-accounts-admin.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/concepts/architecture (#13797) * ZH-trans: add cluster.md (#13500) * ZH-trans: add cluster.md * Update cluster.md * Update cluster.md * Update cluster.md * zh-trans: update docs/concepts/cluster-administration (#13825) * Exclude content-en changes in the PR * Exclude content/ko changes in the PR * Exclude OWNERS_ALIASES change in the PR * rm kubeadm/generated/README.md to fix the build * Remove generated sass assets
This commit is contained in:
chenrui
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
d437c2e5e5
commit
577b431931
@@ -8,4 +8,4 @@ weight: 50
|
||||
title: "Workloads"
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
-->
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "控制器"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Controllers"
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "控制器"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -1,212 +1,104 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- erictune
|
||||
- soltysh
|
||||
- janetkuo
|
||||
title: Cron Job
|
||||
redirect_from:
|
||||
- "/docs/concepts/jobs/cron-jobs/"
|
||||
- "/docs/concepts/jobs/cron-jobs.html"
|
||||
- "/docs/user-guide/cron-jobs/"
|
||||
- "/docs/user-guide/cron-jobs.html"
|
||||
title: CronJob
|
||||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule.
|
||||
|
||||
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
-->
|
||||
|
||||
## Cron Job 是什么？
|
||||
_Cron Job_ 创建基于时间调度的 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
|
||||
|
||||
_Cron Job_ 管理基于时间的 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)，即：
|
||||
一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，并周期性的在给定的调度时间执行 Job。
|
||||
|
||||
* 在给定时间点只运行一次
|
||||
* 在给定时间点周期性地运行
|
||||
{{< note >}}
|
||||
<!--All **CronJob** `schedule:` times are denoted in UTC.-->
|
||||
所有 **CronJob** 的 `schedule:` 时间都是用 UTC 表示。
|
||||
{{< /note >}}
|
||||
|
||||
一个 CronJob 对象类似于 _crontab_ （cron table）文件中的一行。它根据指定的预定计划周期性地运行一个 Job，格式可以参考 [Cron](https://en.wikipedia.org/wiki/Cron) 。
|
||||
<!--
|
||||
For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
-->
|
||||
|
||||
有关创建和使用 CronJob 的说明及规范文件的示例，请参见 [使用 CronJob 运行自动任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。
|
||||
|
||||
|
||||
**注意：** 在预定计划中，问号（`?`）和星号（`*`）的意义是相同的，表示给定字段的取值是任意可用值。
|
||||
{{% /capture %}}
|
||||
|
||||
**注意：** 在 Kubernetes 1.4 版本引入了 ScheduledJob 资源，但从 1.5 版本开始改成了 CronJob。
|
||||
|
||||
典型的用法如下所示：
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Cron Job Limitations
|
||||
|
||||
A cron job creates a job object _about_ once per execution time of its schedule. We say "about" because there
|
||||
are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare,
|
||||
but do not completely prevent them. Therefore, jobs should be _idempotent_.
|
||||
-->
|
||||
|
||||
* 在给定的时间点调度 Job 运行
|
||||
* 创建周期性运行的 Job，例如：数据库备份、发送邮件。
|
||||
## CronJob 限制
|
||||
|
||||
### 前提条件
|
||||
CronJob 创建 Job 对象，每个 Job 的执行次数大约为一次。
|
||||
我们之所以说 "大约"，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。
|
||||
我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是 _幂等的_。
|
||||
|
||||
<!--
|
||||
If `startingDeadlineSeconds` is set to a large value or left unset (the default)
|
||||
and if `concurrencyPolicy` is set to `Allow`, the jobs will always run
|
||||
at least once.
|
||||
-->
|
||||
|
||||
如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且 `concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。
|
||||
|
||||
当使用的 Kubernetes 集群，版本 >= 1.4（对 ScheduledJob），>= 1.5（对 CronJob），当启动 API Server（参考 [为集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster) 获取更多信息）时，通过传递选项 `--runtime-config=batch/v2alpha1=true` 可以开启 batch/v2alpha1 API。
|
||||
<!--
|
||||
For every CronJob, the CronJob controller checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
|
||||
-->
|
||||
|
||||
## 创建 Cron Job
|
||||
对于每个 CronJob，CronJob 控制器检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次，那么它就不会启动这个任务，并记录这个错误:
|
||||
|
||||
下面是一个 Cron Job 的例子。它会每分钟运行一个 Job，打印出当前时间并输出问候语 hello。
|
||||
````
|
||||
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
|
||||
|
||||
% include code.html language="yaml" file="cronjob.yaml" ghlink="/docs/concepts/workloads/controllers/cronjob.yaml" %}
|
||||
````
|
||||
|
||||
下载并运行该示例 Cron Job，然后执行如下命令：
|
||||
<!--
|
||||
It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds.
|
||||
-->
|
||||
|
||||
```shell
|
||||
$ kubectl create -f ./cronjob.yaml
|
||||
cronjob "hello" created
|
||||
```
|
||||
需要注意的是，如果设置 `startingDeadlineSeconds` 字段非空，则控制器会统计从 `startingDeadlineSeconds` 的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如，如果 `startingDeadlineSeconds` 是 `200`，则控制器会统计在过去 200 秒中错过了多少次 Job。
|
||||
|
||||
<!--
|
||||
A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.
|
||||
-->
|
||||
|
||||
如果未能在调度时间内创建 CronJob，则计为错过。例如，如果 `concurrencyPolicy` 被设置为 `Forbid`，并且当前有一个调度仍在运行的情况下，试图调度的 CronJob 将被计算为错过。
|
||||
|
||||
可选地，使用 `kubectl run` 创建一个 Cron Job，不需要写完整的配置：
|
||||
<!--
|
||||
For example, suppose a cron job is set to start at exactly `08:30:00` and its
|
||||
`startingDeadlineSeconds` is set to 10, if the CronJob controller happens to
|
||||
be down from `08:29:00` to `08:42:00`, the job will not start.
|
||||
Set a longer `startingDeadlineSeconds` if starting later is better than not
|
||||
starting at all.
|
||||
-->
|
||||
|
||||
```shell
|
||||
$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
|
||||
cronjob "hello" created
|
||||
```
|
||||
例如，假设一个 CronJob 被设置为`08:30:00` 准时开始，它的 `startingDeadlineSeconds` 属性被设置为10，如果在`08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。
|
||||
如果觉得晚些开始比没有启动好，那请设置一个较长的 `startingDeadlineSeconds`。
|
||||
|
||||
<!--
|
||||
The Cronjob is only responsible for creating Jobs that match its schedule, and
|
||||
the Job in turn is responsible for the management of the Pods it represents.
|
||||
-->
|
||||
|
||||
CronJob 只负责创建与其时间表相匹配的 Job，相应的 Job 又会负责管理它所代表的Pod。
|
||||
|
||||
创建该 Cron Job 之后，通过如下命令获取它的状态信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 <none>
|
||||
```
|
||||
|
||||
|
||||
|
||||
如上所示，既没有 active 的 Job，也没有被调度的 Job。
|
||||
|
||||
等待并观察创建的 Job，大约一分钟时间：
|
||||
|
||||
```shell
|
||||
$ kubectl get jobs --watch
|
||||
NAME DESIRED SUCCESSFUL AGE
|
||||
hello-4111706356 1 1 2s
|
||||
```
|
||||
|
||||
|
||||
|
||||
现在能看到一个名称为 hello 的 Job 在运行。我们可以停止观察，并再次获取该 Job 的状态信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700
|
||||
```
|
||||
|
||||
|
||||
应该能够看到名称为 “hello” 的 Job 在 `LAST-SCHEDULE` 指定的时间点被调度了。当前存在 0 个活跃（Active）的 Job，说明该 Job 已经被调度运行完成或失败。
|
||||
|
||||
现在，找到最近一次被调度的 Job 创建的 Pod，能够看到其中一个 Pod 的标准输出。注意，Job 名称和 Pod 名称是不一样的。
|
||||
|
||||
```shell
|
||||
# Replace "hello-4111706356" with the job name in your system
|
||||
$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
|
||||
|
||||
$ echo $pods
|
||||
hello-4111706356-o9qcm
|
||||
|
||||
$ kubectl logs $pods
|
||||
Mon Aug 29 21:34:09 UTC 2016
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
|
||||
|
||||
## 删除 Cron Job
|
||||
|
||||
一旦不再需要 Cron Job，简单地可以使用 `kubectl` 命令删除它：
|
||||
|
||||
```shell
|
||||
$ kubectl delete cronjob hello
|
||||
cronjob "hello" deleted
|
||||
```
|
||||
|
||||
|
||||
|
||||
这将会终止正在创建的 Job。然而，运行中的 Job 将不会被终止，不会删除 Job 或 它们的 Pod。为了清理那些 Job 和 Pod，需要列出该 Cron Job 创建的全部 Job，然后删除它们：
|
||||
|
||||
```shell
|
||||
$ kubectl get jobs
|
||||
NAME DESIRED SUCCESSFUL AGE
|
||||
hello-1201907962 1 1 11m
|
||||
hello-1202039034 1 1 8m
|
||||
...
|
||||
|
||||
$ kubectl delete jobs hello-1201907962 hello-1202039034 ...
|
||||
job "hello-1201907962" deleted
|
||||
job "hello-1202039034" deleted
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
||||
一旦 Job 被删除，由 Job 创建的 Pod 也会被删除。注意，所有由名称为 “hello” 的 Cron Job 创建的 Job 会以前缀字符串 “hello-” 进行命名。如果想要删除当前 Namespace 中的所有 Job，可以通过命令 `kubectl delete jobs --all` 立刻删除它们。
|
||||
|
||||
|
||||
|
||||
## Cron Job 限制
|
||||
|
||||
Cron Job 在每次调度运行时间内 _大概_ 会创建一个 Job 对象。我们之所以说 _大概_ ，是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。我们尝试少发生这种情况，但却不能完全避免。因此，创建 Job 操作应该是 _幂等的_。
|
||||
|
||||
Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决定这一组 Pod 的成功或失败。Cron Job 根本不会去检查 Pod。
|
||||
|
||||
|
||||
|
||||
## 编写 Cron Job 规约
|
||||
|
||||
和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。
|
||||
关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、
|
||||
[配置容器](/docs/user-guide/configuring-containers) 和
|
||||
[使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。
|
||||
|
||||
Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)。
|
||||
|
||||
**注意：** 对一个 Cron Job 的所有修改，尤其是对其 `.spec` 的修改，仅会在下一次运行的时候生效。
|
||||
|
||||
|
||||
### 调度
|
||||
|
||||
`.spec.schedule` 是 `.spec` 中必需的字段，它的值是 [Cron](https://en.wikipedia.org/wiki/Cron) 格式字的符串，例如：`0 * * * *`，或者 `@hourly`，根据指定的调度时间 Job 会被创建和执行。
|
||||
|
||||
|
||||
|
||||
### Job 模板
|
||||
|
||||
`.spec.jobTemplate` 是另一个 `.spec` 中必需的字段。它是 Job 的模板。
|
||||
除了它可以是嵌套的，并且不具有 `apiVersion` 或 `kind` 字段之外，它和 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 一样具有完全相同的模式（schema）。
|
||||
参考 [编写 Job 规格](/docs/concepts/jobs/run-to-completion-finite-workloads/#writing-a-job-spec)。
|
||||
|
||||
|
||||
|
||||
### 启动 Job 的期限（秒级别）
|
||||
|
||||
`.spec.startingDeadlineSeconds` 字段是可选的。它表示启动 Job 的期限（秒级别），如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限。
|
||||
|
||||
|
||||
|
||||
### 并发策略
|
||||
|
||||
`.spec.concurrencyPolicy` 字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
|
||||
|
||||
* `Allow`（默认）：允许并发运行 Job
|
||||
* `Forbid`：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
|
||||
* `Replace`：取消当前正在运行的 Job，用一个新的来替换
|
||||
|
||||
注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。
|
||||
|
||||
|
||||
|
||||
### 挂起
|
||||
|
||||
`.spec.suspend` 字段也是可选的。如果设置为 `true`，后续所有执行都将被挂起。它对已经开始执行的 Job 不起作用。默认值为 `false`。
|
||||
|
||||
|
||||
|
||||
### Job 历史限制
|
||||
|
||||
`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 这两个字段是可选的。它们指定了可以保留完成和失败 Job 数量的限制。
|
||||
|
||||
默认没有限制，所有成功和失败的 Job 都会被保留。然而，当运行一个 Cron Job 时，很快就会堆积很多 Job，推荐设置这两个字段的值。设置限制值为 `0`，相关类型的 Job 完成后将不会被保留。
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -22,7 +22,7 @@ redirect_from:
|
||||
|
||||
- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
|
||||
- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
|
||||
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理，或 Ganglia `gmond`。
|
||||
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理, Ganglia `gmond`, 或 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。
|
||||
|
||||
一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
|
||||
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
|
||||
|
||||
@@ -0,0 +1,416 @@
|
||||
---
|
||||
reviewers:
|
||||
- Kashomon
|
||||
- bprashanth
|
||||
- madhusudancs
|
||||
title: ReplicaSet
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
ReplicaSet is the next-generation Replication Controller. The only difference
|
||||
between a _ReplicaSet_ and a
|
||||
[_Replication Controller_](/docs/concepts/workloads/controllers/replicationcontroller/) right now is
|
||||
the selector support. ReplicaSet supports the new set-based selector requirements
|
||||
as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
|
||||
whereas a Replication Controller only supports equality-based selector requirements.
|
||||
-->
|
||||
|
||||
ReplicaSet 是下一代的 Replication Controller。 _ReplicaSet_ 和 [_Replication Controller_](/docs/concepts/workloads/controllers/replicationcontroller/) 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求，这在[标签用户指南](/docs/concepts/overview/working-with-objects/labels/#label-selectors)中有描述。而 Replication Controller 仅支持基于相等选择器的需求。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## How to use a ReplicaSet
|
||||
|
||||
Most [`kubectl`](/docs/user-guide/kubectl/) commands that support
|
||||
Replication Controllers also support ReplicaSets. One exception is the
|
||||
[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) command. If
|
||||
you want the rolling update functionality please consider using Deployments
|
||||
instead. Also, the
|
||||
[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) command is
|
||||
imperative whereas Deployments are declarative, so we recommend using Deployments
|
||||
through the [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout) command.
|
||||
|
||||
While ReplicaSets can be used independently, today it's mainly used by
|
||||
[Deployments](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod
|
||||
creation, deletion and updates. When you use Deployments you don't have to worry
|
||||
about managing the ReplicaSets that they create. Deployments own and manage
|
||||
their ReplicaSets.
|
||||
-->
|
||||
|
||||
## 怎样使用 ReplicaSet
|
||||
|
||||
大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
|
||||
|
||||
虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
|
||||
当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。
|
||||
|
||||
<!--
|
||||
## When to use a ReplicaSet
|
||||
|
||||
A ReplicaSet ensures that a specified number of pod replicas are running at any given
|
||||
time. However, a Deployment is a higher-level concept that manages ReplicaSets and
|
||||
provides declarative updates to pods along with a lot of other useful features.
|
||||
Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless
|
||||
you require custom update orchestration or don't require updates at all.
|
||||
|
||||
This actually means that you may never need to manipulate ReplicaSet objects:
|
||||
use a Deployment instead, and define your application in the spec section.
|
||||
-->
|
||||
|
||||
## 什么时候使用 ReplicaSet
|
||||
|
||||
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
|
||||
然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。
|
||||
因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet，除非您需要自定义更新业务流程或根本不需要更新。
|
||||
|
||||
这实际上意味着，您可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义您的应用。
|
||||
|
||||
<!--
|
||||
## Example
|
||||
-->
|
||||
## 示例
|
||||
|
||||
{{< codenew file="controllers/frontend.yaml" >}}
|
||||
|
||||
<!--
|
||||
Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster should
|
||||
create the defined ReplicaSet and the pods that it manages.
|
||||
-->
|
||||
|
||||
将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群，应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。
|
||||
|
||||
```shell
|
||||
$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
|
||||
replicaset.apps/frontend created
|
||||
$ kubectl describe rs/frontend
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
Selector: tier=frontend,tier in (frontend)
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Annotations: <none>
|
||||
Replicas: 3 current / 3 desired
|
||||
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Containers:
|
||||
php-redis:
|
||||
Image: gcr.io/google_samples/gb-frontend:v3
|
||||
Port: 80/TCP
|
||||
Requests:
|
||||
cpu: 100m
|
||||
memory: 100Mi
|
||||
Environment:
|
||||
GET_HOSTS_FROM: dns
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
frontend-dnjpy 1/1 Running 0 1m
|
||||
frontend-qhloh 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Writing a ReplicaSet Spec
|
||||
|
||||
As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields. For
|
||||
general information about working with manifests, see [object management using kubectl](/docs/concepts/overview/object-management-kubectl/overview/).
|
||||
|
||||
A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
|
||||
-->
|
||||
|
||||
## 编写 ReplicaSet Spec
|
||||
|
||||
与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。
|
||||
|
||||
ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。
|
||||
|
||||
<!--
|
||||
### Pod Template
|
||||
|
||||
The `.spec.template` is the only required field of the `.spec`. The `.spec.template` is a
|
||||
[pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a
|
||||
[pod](/docs/concepts/workloads/pods/pod/), except that it is nested and does not have an `apiVersion` or `kind`.
|
||||
|
||||
In addition to required fields of a pod, a pod template in a ReplicaSet must specify appropriate
|
||||
labels and an appropriate restart policy.
|
||||
|
||||
For labels, make sure to not overlap with other controllers. For more information, see [pod selector](#pod-selector).
|
||||
|
||||
For [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), the only allowed value for `.spec.template.spec.restartPolicy` is `Always`, which is the default.
|
||||
|
||||
For local container restarts, ReplicaSet delegates to an agent on the node,
|
||||
for example the [Kubelet](/docs/admin/kubelet/) or Docker.
|
||||
-->
|
||||
|
||||
### Pod 模版
|
||||
|
||||
`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
|
||||
|
||||
除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。
|
||||
|
||||
对于标签，请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。
|
||||
|
||||
对于 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
|
||||
|
||||
对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。
|
||||
|
||||
<!--
|
||||
### Pod Selector
|
||||
|
||||
The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/). A ReplicaSet
|
||||
manages all the pods with labels that match the selector. It does not distinguish
|
||||
between pods that it created or deleted and pods that another person or process created or
|
||||
deleted. This allows the ReplicaSet to be replaced without affecting the running pods.
|
||||
|
||||
The `.spec.template.metadata.labels` must match the `.spec.selector`, or it will
|
||||
be rejected by the API.
|
||||
|
||||
In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
|
||||
-->
|
||||
|
||||
### Pod 选择器
|
||||
|
||||
`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
|
||||
|
||||
`.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。
|
||||
|
||||
Kubernetes 1.9 版本中，API 版本 `apps/v1` 中的 ReplicaSet 类型的版本是当前版本并默认开启。API 版本 `apps/v1beta2` 被弃用。
|
||||
|
||||
<!--
|
||||
Also you should not normally create any pods whose labels match this selector, either directly, with
|
||||
another ReplicaSet, or with another controller such as a Deployment. If you do so, the ReplicaSet thinks that it
|
||||
created the other pods. Kubernetes does not stop you from doing this.
|
||||
|
||||
If you do end up with multiple controllers that have overlapping selectors, you
|
||||
will have to manage the deletion yourself.
|
||||
-->
|
||||
|
||||
另外，通常您不应该创建标签与此选择器匹配的任何 Pod，或者直接与另一个 ReplicaSet 或另一个控制器（如 Deployment）标签匹配的任何 Pod。
|
||||
如果你这样做，ReplicaSet 会认为它创造了其他 Pod。Kubernetes 并不会阻止您这样做。
|
||||
|
||||
如果您最终使用了多个具有重叠选择器的控制器，则必须自己负责删除。
|
||||
|
||||
<!--
|
||||
### Labels on a ReplicaSet
|
||||
|
||||
The ReplicaSet can itself have labels (`.metadata.labels`). Typically, you
|
||||
would set these the same as the `.spec.template.metadata.labels`. However, they are allowed to be
|
||||
different, and the `.metadata.labels` do not affect the behavior of the ReplicaSet.
|
||||
|
||||
### Replicas
|
||||
|
||||
You can specify how many pods should run concurrently by setting `.spec.replicas`. The number running at any time may be higher
|
||||
or lower, such as if the replicas were just increased or decreased, or if a pod is gracefully
|
||||
shut down, and a replacement starts early.
|
||||
|
||||
If you do not specify `.spec.replicas`, then it defaults to 1.
|
||||
-->
|
||||
|
||||
### Replicas
|
||||
|
||||
通过设置 `.spec.replicas` 您可以指定要同时运行多少个 Pod。
|
||||
在任何时间运行的 Pod 数量可能高于或低于 `.spec.replicas` 指定的数量，例如在副本刚刚被增加或减少后、或者 Pod 正在被优雅地关闭、以及替换提前开始。
|
||||
|
||||
如果您没有指定 `.spec.replicas`, 那么默认值为 1。
|
||||
|
||||
<!--
|
||||
## Working with ReplicaSets
|
||||
|
||||
### Deleting a ReplicaSet and its Pods
|
||||
|
||||
To delete a ReplicaSet and all of its Pods, use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The [Garbage collector](/docs/concepts/workloads/controllers/garbage-collection/) automatically deletes all of the dependent Pods by default.
|
||||
|
||||
When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Background` or `Foreground` in delete option. e.g. :
|
||||
-->
|
||||
|
||||
## 使用 ReplicaSets 的具体方法
|
||||
|
||||
### 删除 ReplicaSet 和它的 Pod
|
||||
|
||||
要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
|
||||
默认情况下，[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
|
||||
|
||||
当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
|
||||
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
> -H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
<!--
|
||||
### Deleting just a ReplicaSet
|
||||
|
||||
You can delete a ReplicaSet without affecting any of its pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=false` option.
|
||||
When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`, e.g. :
|
||||
-->
|
||||
|
||||
### 只删除 ReplicaSet
|
||||
|
||||
您可以只删除 ReplicaSet 而不影响它的 Pod，方法是使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令并设置 `--cascade=false` 选项。
|
||||
|
||||
当使用 REST API 或 `client-go` 库时，您必须将 `propagationPolicy` 设置为 `Orphan`。例如：
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
|
||||
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
> -H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the original is deleted, you can create a new ReplicaSet to replace it. As long
|
||||
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
|
||||
However, it will not make any effort to make existing pods match a new, different pod template.
|
||||
To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
|
||||
-->
|
||||
|
||||
一旦删除了原来的 ReplicaSet，就可以创建一个新的来替换它。
|
||||
由于新旧 ReplicaSet 的 `.spec.selector` 是相同的，新的 ReplicaSet 将接管老的 Pod。
|
||||
但是，它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。
|
||||
若想要以可控的方式将 Pod 更新到新的 spec，就要使用 [滚动更新](#rolling-updates)的方式。
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
### Isolating pods from a ReplicaSet
|
||||
|
||||
Pods may be removed from a ReplicaSet's target set by changing their labels. This technique may be used to remove pods
|
||||
from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (
|
||||
assuming that the number of replicas is not also changed).
|
||||
|
||||
-->
|
||||
|
||||
### 将 Pod 从 ReplicaSet 中隔离
|
||||
|
||||
可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。
|
||||
以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。
|
||||
|
||||
<!--
|
||||
### Scaling a ReplicaSet
|
||||
|
||||
A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller
|
||||
ensures that a desired number of pods with a matching label selector are available and operational.
|
||||
-->
|
||||
|
||||
### 缩放 RepliaSet
|
||||
|
||||
通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。
|
||||
|
||||
<!--
|
||||
### ReplicaSet as an Horizontal Pod Autoscaler Target
|
||||
|
||||
A ReplicaSet can also be a target for
|
||||
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). That is,
|
||||
a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
|
||||
the ReplicaSet we created in the previous example.
|
||||
-->
|
||||
|
||||
### ReplicaSet 作为水平的 Pod 自动缩放器目标
|
||||
|
||||
ReplicaSet 也可以作为 [水平的 Pod 缩放器 (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/) 的目标。也就是说，ReplicaSet 可以被 HPA 自动缩放。
|
||||
以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。
|
||||
|
||||
|
||||
{{< codenew file="controllers/hpa-rs.yaml" >}}
|
||||
|
||||
<!--
|
||||
Saving this manifest into `hpa-rs.yaml` and submitting it to a Kubernetes cluster should
|
||||
create the defined HPA that autoscales the target ReplicaSet depending on the CPU usage
|
||||
of the replicated pods.
|
||||
-->
|
||||
|
||||
将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Alternatively, you can use the `kubectl autoscale` command to accomplish the same
|
||||
(and it's easier!)
|
||||
-->
|
||||
|
||||
或者，可以使用 `kubectl autoscale` 命令完成相同的操作。
|
||||
(而且它更简单！)
|
||||
|
||||
```shell
|
||||
kubectl autoscale rs frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
## Alternatives to ReplicaSet
|
||||
|
||||
### Deployment (Recommended)
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying ReplicaSets and their Pods
|
||||
in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
|
||||
because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features. For more information on running a stateless
|
||||
application using a Deployment, please read [Run a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
-->
|
||||
|
||||
## ReplicaSet 的替代方案
|
||||
|
||||
### Deployment （推荐）
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
|
||||
如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
|
||||
有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
|
||||
|
||||
<!--
|
||||
### Bare Pods
|
||||
|
||||
Unlike the case where a user directly created pods, a ReplicaSet replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node (for example, Kubelet or Docker).
|
||||
-->
|
||||
|
||||
### 裸 Pod
|
||||
|
||||
与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。
|
||||
因为这个好处，我们建议您使用 ReplicaSet，即使应用程序只需要一个 Pod。
|
||||
想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod，而不是在单个节点上监视单个进程。
|
||||
ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet 或 Docker）去完成。
|
||||
|
||||
<!--
|
||||
### Job
|
||||
|
||||
Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicaSet for pods that are expected to terminate on their own
|
||||
(that is, batch jobs).
|
||||
-->
|
||||
|
||||
### Job
|
||||
|
||||
使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
|
||||
|
||||
<!--
|
||||
### DaemonSet
|
||||
|
||||
Use a [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) instead of a ReplicaSet for pods that provide a
|
||||
machine-level function, such as machine monitoring or machine logging. These pods have a lifetime that is tied
|
||||
to a machine lifetime: the pod needs to be running on the machine before other pods start, and are
|
||||
safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
|
||||
-->
|
||||
|
||||
### DaemonSet
|
||||
|
||||
对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
|
||||
这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,417 @@
|
||||
---
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
- smarterclayton
|
||||
title: StatefulSets
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
- smarterclayton
|
||||
title: StatefulSets
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
StatefulSet is the workload API object used to manage stateful applications.
|
||||
-->
|
||||
|
||||
StatefulSet 是用来管理有状态应用的工作负载 API 对象。
|
||||
|
||||
{{< note >}}
|
||||
<!--**Note:** StatefulSets are stable (GA) in 1.9.-->
|
||||
**注意：** StatefulSets 是在 1.9 版本中正式发布的。
|
||||
{{< /note >}}
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Using StatefulSets
|
||||
|
||||
StatefulSets are valuable for applications that require one or more of the
|
||||
following.
|
||||
|
||||
* Stable, unique network identifiers.
|
||||
* Stable, persistent storage.
|
||||
* Ordered, graceful deployment and scaling.
|
||||
* Ordered, automated rolling updates.
|
||||
|
||||
In the above, stable is synonymous with persistence across Pod (re)scheduling.
|
||||
If an application doesn't require any stable identifiers or ordered deployment,
|
||||
deletion, or scaling, you should deploy your application with a controller that
|
||||
provides a set of stateless replicas. Controllers such as
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/) or
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
|
||||
-->
|
||||
|
||||
## 使用 StatefulSets
|
||||
|
||||
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
|
||||
|
||||
* 稳定的、唯一的网络标识符。
|
||||
* 稳定的、持久的存储。
|
||||
* 有序的、优雅的部署和缩放。
|
||||
* 有序的、自动的滚动更新。
|
||||
|
||||
在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用一组无状态的副本控制器来部署应用程序，比如 [Deployment](/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态需要。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
|
||||
* StatefulSet was a beta resource prior to 1.9 and not available in any Kubernetes release prior to 1.5.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
|
||||
* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
|
||||
* StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion.
|
||||
-->
|
||||
|
||||
## 限制
|
||||
|
||||
* StatefulSet 在 1.9 版本之前属于 beta 资源，在 1.5 版本之前的任何 Kubernetes 版本中都不可用。
|
||||
* 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。
|
||||
* 删除和／或收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
|
||||
* StatefulSet 当前需要 [无头服务](/docs/concepts/services-networking/service/#headless-services) 来负责Pod 的网络标识。您需要负责创建此服务。
|
||||
* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为0。
|
||||
|
||||
<!--
|
||||
## Components
|
||||
The example below demonstrates the components of a StatefulSet.
|
||||
|
||||
* A Headless Service, named nginx, is used to control the network domain.
|
||||
* The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
|
||||
* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
|
||||
-->
|
||||
|
||||
## 组件
|
||||
下面的示例演示了 StatefulSet 的组件。
|
||||
|
||||
* 名为 nginx 的无头服务用来控制网络域。
|
||||
* 名为 web 的 StatefulSet 有一个Spec，它表明将在单个 Pod 中启动 nginx 容器的3个副本。
|
||||
* volumeClaimTemplates 将通过 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 驱动提供的 PersistentVolume 来提供稳定的存储。
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
name: web
|
||||
clusterIP: None
|
||||
selector:
|
||||
app: nginx
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: web
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx # has to match .spec.template.metadata.labels
|
||||
serviceName: "nginx"
|
||||
replicas: 3 # by default is 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx # has to match .spec.selector.matchLabels
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- name: www
|
||||
mountPath: /usr/share/nginx/html
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "my-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
<!--
|
||||
## Pod Selector
|
||||
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
|
||||
-->
|
||||
|
||||
## Pod 选择器
|
||||
您必须设置 StatefulSet 的 `.spec.selector` 字段来匹配它的`.spec.template.metadata.labels`标签。在 Kubernetes 1.8 版本之前，忽略`.spec.selector` 字段会提供默认设置。在 1.8 和以后的版本中，指定的 Pod 选择器匹配失败将在创建 StatefulSet 期间导致验证错误。
|
||||
|
||||
<!--
|
||||
## Pod Identity
|
||||
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
|
||||
stable network identity, and stable storage. The identity sticks to the Pod,
|
||||
regardless of which node it's (re)scheduled on.
|
||||
-->
|
||||
|
||||
## Pod 的身份
|
||||
|
||||
StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。
|
||||
|
||||
<!--
|
||||
### Ordinal Index
|
||||
|
||||
For a StatefulSet with N replicas, each Pod in the StatefulSet will be
|
||||
assigned an integer ordinal, from 0 up through N-1, that is unique over the Set.
|
||||
-->
|
||||
|
||||
### 序号索引
|
||||
|
||||
对于具有N个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。
|
||||
|
||||
<!--
|
||||
### Stable Network ID
|
||||
|
||||
Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet
|
||||
and the ordinal of the Pod. The pattern for the constructed hostname
|
||||
is `$(statefulset name)-$(ordinal)`. The example above will create three Pods
|
||||
named `web-0,web-1,web-2`.
|
||||
A StatefulSet can use a [Headless Service](/docs/concepts/services-networking/service/#headless-services)
|
||||
to control the domain of its Pods. The domain managed by this Service takes the form:
|
||||
`$(service name).$(namespace).svc.cluster.local`, where "cluster.local" is the
|
||||
cluster domain.
|
||||
As each Pod is created, it gets a matching DNS subdomain, taking the form:
|
||||
`$(podname).$(governing service domain)`, where the governing service is defined
|
||||
by the `serviceName` field on the StatefulSet.
|
||||
-->
|
||||
|
||||
### 稳定的网络 ID
|
||||
|
||||
StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为 `$(statefulset name)-$(ordinal)`。上例将会创建三个名称为 `web-0,web-1,web-2` 的三个 Pod。
|
||||
StatefulSet 可以使用 [无头服务](/docs/concepts/services-networking/service/#headless-services) 控制它的 Pod 的网络域。管理域的这个服务的格式为：
|
||||
`$(service name).$(namespace).svc.cluster.local`, 其中 "cluster.local" 是集群域。
|
||||
一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：`$(podname).$(governing service domain)`，其中管理服务由 StatefulSet 的 `serviceName` 域来定义。
|
||||
|
||||
|
||||
<!--
|
||||
Here are some examples of choices for Cluster Domain, Service name,
|
||||
StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods.
|
||||
-->
|
||||
|
||||
下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例：
|
||||
|
||||
Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname |
|
||||
-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
|
||||
cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
|
||||
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
|
||||
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** Cluster Domain will be set to `cluster.local` unless
|
||||
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
|
||||
-->
|
||||
**注意** 集群域会被设置为 `cluster.local` 除非有[其他配置](/docs/concepts/services-networking/dns-pod-service/#how-it-works)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Stable Storage
|
||||
|
||||
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each
|
||||
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
|
||||
with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
|
||||
is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
|
||||
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
|
||||
PersistentVolume Claims. Note that, the PersistentVolumes associated with the
|
||||
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
|
||||
This must be done manually.
|
||||
-->
|
||||
|
||||
### 稳定的存储
|
||||
|
||||
Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/docs/concepts/storage/persistent-volumes/)。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。当一个 Pod 被安排到节点上时，它的 `volumeMounts` 挂载了与其 PersistentVolumeClaims 相关联的 PersistentVolume。请注意，当 Pod 或者 StatefulSet 被删除时，与PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。
|
||||
|
||||
|
||||
<!--
|
||||
### Pod Name Label
|
||||
|
||||
When the StatefulSet controller creates a Pod, it adds a label, `statefulset.kubernetes.io/pod-name`,
|
||||
that is set to the name of the Pod. This label allows you to attach a Service to a specific Pod in
|
||||
the StatefulSet.
|
||||
-->
|
||||
|
||||
### Pod 名称标签
|
||||
|
||||
当 StatefulSet 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。
|
||||
|
||||
<!--
|
||||
## Deployment and Scaling Guarantees
|
||||
|
||||
* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
|
||||
* When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
|
||||
* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
|
||||
* Before a Pod is terminated, all of its successors must be completely shutdown.
|
||||
-->
|
||||
|
||||
## 部署和伸缩保证
|
||||
|
||||
* 对于包含 N 个 副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为 {0..N-1}。
|
||||
* 当删除 Pod 时，它们是逆序终止的，顺序为 {N-1..0}。
|
||||
* 在将缩放操作应用到 Pod 之前，它前面的所有 Pod 必须是 Running 和 Ready 状态。
|
||||
* 在 Pod 终止之前，所有的继任者必须完全关闭。
|
||||
|
||||
<!--
|
||||
The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
-->
|
||||
|
||||
StatefulSet 不应该声明 `pod.Spec.TerminationGracePeriodSeconds` 为 0。这种做法是不安全的，要强烈阻止。更多的解释请参考 [强制删除 StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)。
|
||||
|
||||
<!--
|
||||
When the nginx example above is created, three Pods will be deployed in the order
|
||||
web-0, web-1, web-2. web-1 will not be deployed before web-0 is
|
||||
[Running and Ready](/docs/user-guide/pod-states/), and web-2 will not be deployed until
|
||||
web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before
|
||||
web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and
|
||||
becomes Running and Ready.
|
||||
-->
|
||||
|
||||
在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。在 web-0 进入[Running 和 Ready](/docs/user-guide/pod-states/)状态前不会部署 web-1。在 web-1 进入Running 和 Ready 状态前不会部署 web-2。如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了 web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和 Ready 状态后，才会部署 web-2。
|
||||
|
||||
<!--
|
||||
If a user were to scale the deployed example by patching the StatefulSet such that
|
||||
`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2
|
||||
is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and
|
||||
is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
|
||||
until web-0 is Running and Ready.
|
||||
-->
|
||||
|
||||
如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。
|
||||
|
||||
<!--
|
||||
### Pod Management Policies
|
||||
In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
|
||||
preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field.
|
||||
|
||||
#### OrderedReady Pod Management
|
||||
|
||||
`OrderedReady` pod management is the default for StatefulSets. It implements the behavior
|
||||
described [above](#deployment-and-scaling-guarantees).
|
||||
|
||||
#### Parallel Pod Management
|
||||
|
||||
`Parallel` pod management tells the StatefulSet controller to launch or
|
||||
terminate all Pods in parallel, and to not wait for Pods to become Running
|
||||
and Ready or completely terminated prior to launching or terminating another
|
||||
Pod.
|
||||
-->
|
||||
|
||||
### Pod 管理策略
|
||||
在 Kubernetes 1.7及以后的版本中，StatefulSet 允许您放松其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
|
||||
|
||||
#### 有序的 Pod 管理
|
||||
|
||||
`有序的` Pod 管理是 StatefulSet 的默认功能。它实现了 [上面](#deployment-and-scaling-guarantees)描述的行为。
|
||||
|
||||
#### 并行的 Pod 管理
|
||||
|
||||
`并行` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。
|
||||
|
||||
<!--
|
||||
## Update Strategies
|
||||
|
||||
In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
|
||||
and disable automated rolling updates for containers, labels, resource request/limits, and
|
||||
annotations for the Pods in a StatefulSet.
|
||||
-->
|
||||
|
||||
## 更新策略
|
||||
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求／限制、以及注解。
|
||||
|
||||
|
||||
<!--
|
||||
### On Delete
|
||||
|
||||
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. When a StatefulSet's
|
||||
`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
|
||||
update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
|
||||
create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
|
||||
-->
|
||||
|
||||
### On Delete
|
||||
|
||||
`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。
|
||||
|
||||
|
||||
<!--
|
||||
### Rolling Updates
|
||||
|
||||
The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
|
||||
StatefulSet. It is the default strategy when `.spec.updateStrategy` is left unspecified. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
|
||||
StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
|
||||
in the same order as Pod termination (from the largest ordinal to the smallest), updating
|
||||
each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
|
||||
updating its predecessor.
|
||||
-->
|
||||
|
||||
### 滚动更新（Rolling Updates）
|
||||
|
||||
`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明`.spec.updateStrategy`时，`RollingUpdate` 是默认配置。
|
||||
当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。
|
||||
它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready状态，然后再更新其前身。
|
||||
|
||||
<!--
|
||||
#### Partitions
|
||||
|
||||
The `RollingUpdate` update strategy can be partitioned, by specifying a
|
||||
`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
|
||||
ordinal that is greater than or equal to the partition will be updated when the StatefulSet's
|
||||
`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not
|
||||
be updated, and, even if they are deleted, they will be recreated at the previous version. If a
|
||||
StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`,
|
||||
updates to its `.spec.template` will not be propagated to its Pods.
|
||||
In most cases you will not need to use a partition, but they are useful if you want to stage an
|
||||
update, roll out a canary, or perform a phased roll out.
|
||||
-->
|
||||
|
||||
#### 分区
|
||||
|
||||
通过声明 `.spec.updateStrategy.rollingUpdate.partition`的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的`.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。
|
||||
在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
|
||||
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
|
||||
-->
|
||||
|
||||
* 示例一： [部署有状态应用](/docs/tutorials/stateful-application/basic-stateful-set/)。
|
||||
* 示例二： [使用 StatefulSet 部署 Cassandra](/docs/tutorials/stateful-application/cassandra/)。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
@@ -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 as well.
|
||||
|
||||
Pods in a Kubernetes cluster can be used in two main ways:
|
||||
-->
|
||||
[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的容器运行时。
|
||||
|
||||
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,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](http://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](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
|
||||
|
||||
<!--
|
||||
Pod is exposed as a primitive in order to facilitate:
|
||||
|
||||
* 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 apiserver 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 创建请求时，系统会执行以下操作：
|
||||
应用于接收到的 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>"`。
|
||||
|
||||
<!--
|
||||
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