ZH-trans: merge release1.16-temporary to master (#18217)
* zh-trans:/docs/docs/concepts/workloads/pods/ephemeral-containers.md (#16948) * update zh-trans of define-environment-variable-container.md (#16999) Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> * update chinese docs (#16985) * Fix ordered list (#16988) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md (#16951) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * Remove redundant symbol and fix some ordered list (#17000) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * update-zh-translation/docs/reference/setup-tools/kubeadm/kubeadm-init.md (#16997) * update zh translation kubeadm-reset.md kubeadm-upgrade.md (#16992) * Create kubeadm_join_phase_control-plane-join_all.md (#16987) * Update web-ui-dashboard.md (#16976) * update format problem (#16956) Signed-off-by: PingWang <wang.ping5@zte.com.cn> update Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/docs/concepts/storage/volume-pvc-datasource.md (#17021) * update zh translation /docs/reference/access-authn-authz/webhook.md (#16860) * fix confict update zh translation (#16863) * zh-trans:/docs/concepts/workloads/pods/disruptions.md (#16983) * zh-trans:/docs/concepts/workloads/pods/disruptions.md * Update content/zh/docs/concepts/workloads/pods/disruptions.md Co-Authored-By: Qiming <tengqim@cn.ibm.com> * update zh translation content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md (#17006) * Update RC's link (#16935) Signed-off-by: PingWang <wang.ping5@zte.com.cn> Update Signed-off-by: PingWang <wang.ping5@zte.com.cn> update the style Signed-off-by: PingWang <wang.ping5@zte.com.cn> * Update the links for /zh/docs/setup (#16938) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans:/docs/docs/concepts/services-networking/dual-stack.md (#17024) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm.md (#17036) * update zh tanslation /reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md (#17037) * update zh translation -/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md (#17038) * update zh translation /docs/contribute/participating.md (#17040) * Fix cri-o's links to match English docs (#16936) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * update zh translation content/zh/docs/reference/kubectl/jsonpath.md (#16862) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md (#17049) * update Unkown -> Unknown (#17062) * zh-translation:high-availability.md (#16960) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update Runnning -> Running (#17061) * zh-trans:/docs/docs/concepts/storage/volume-snapshots.md (#17054) * update zh transation /docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md (#17060) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md (#17052) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#17055) * update zh translation update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md (#17048) * update zh-translation:ha-topology.md (#17099) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md (#17093) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md (#17083) * Add Chinese translation for scheduler-perf-tuning (#17087) Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for scheduler-perf-tuning Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> * zh trans content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md (#17121) * update zh trans content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md (#17122) * zh-translation:content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md (#17105) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md (#17091) * update zh trans /docs/setup/learning-environment/minikube.md (#17143) * update zh trans /zh/docs/reference/_index.md (#17146) * update zh trans /docs/tasks/access-application-cluster/port-forward-access-application-cluster.md (#17134) * update zh translation 20191020-update-zh-translation-/docs/contribute/localization.md (#17046) * update zh trans /docs/reference/using-api/client-libraries.md (#17144) * update zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md (#17145) * update zh /docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md (#17131) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md (#17081) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md (#17078) * add zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md (#17076) * update zh trans content/zh/docs/contribute/generate-ref-docs/kubectl.md (#17165) * update zh translation /reference/command-line-tools-reference/kube-proxy.md (#17107) * zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-const… (#16955) * zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-constraints.md * Update pod-topology-spread-constraints.md * zh-trans:/docs/concepts/configuration/scheduling-framework.md (#17088) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md (#17079) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md (#17077) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md (#17075) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md (#17050) * update zh trans /docs/concepts/overview/working-with-objects/namespaces.md (#17205) * update zh trans /docs/concepts/overview/what-is-kubernetes.md (#17203) * pr_release-1.16_crictl (#17201) * update zh docs/tasks/administer-cluster/dns-debugging-resolution.md (#17186) * update zh trans content/zh/docs/concepts/overview/working-with-objects/field-selectors.md (#17191) * translate configure_upgrade_etcd (#17160) * translate kubeadm_upgrade_apply (#17159) * update zh /docs/tasks/job/coarse-parallel-processing-work-queue.md (#17155) * translate docs/setup/release/version-skew-policy.md to Chinese (#17142) * update zh trans content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md (#17124) * zh-trans replace the wrong translation (#17103) zh-trans replace the wrong translation * Merged 1.14~1.16 changes (#17117) * zh-trans:/docs/concepts/configuration/assign-pod-node.md (#17129) * update zh trans /docs/contribute/generate-ref-docs/kubernetes-api.md (#17161) * pr_release-1.16_basic-ss (#17169) * Add zh-trans of assign-cpu-resource.md (#17063) Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> Add zh-trans of assign-cpu-resource.md Signed-off-by: heqg <he.qingguo@zte.com.cn> * update zh trans content/zh/docs/concepts/overview/working-with-objects/common-labels.md (#17193) * update zh translation /docs/contribute/intermediate.md (#17041) * zh-trans:docs/setup/production-environment/turnkey/tencent.md (#17207) * pr_release-1.16_mysql-wordpress-pv (#17202) * pr_release-1.16_reconfig-kubelet (#17200) * zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completio… (#17020) * zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completion.md * Update jobs-run-completion.md * Update jobs-run-completion.md * update zh trans content/zh/docs/concepts/extend-kubernetes/extend-cluster.md (#17212) * update zh trans content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md (#17213) * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md (#17220) kubeadm_join_phase_control-plane-prepare_download-certs.md * add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md and /reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md (#17219) * update zh trans content/zh/docs/concepts/containers/images.md (#17216) * ZH-trans: add _index.md (#17214) * ZH-trans: add _index.md * add _index.md file * add _index.md files * pr_release-1.16_crd-versions (#17198) * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md (#17092) * zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images.md (#17094) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md (#17222) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md (#17221) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md (#17223) * 013 /docs/concepts/services networking/ingress.md (#17185) * x * update zh trans content/zh/docs/concepts/services-networking/ingress.md * zh-trans:/reference/setup-tools/kubeadm/generated/kubeadm_completion.md and kubeadm_config.md (#17097) * add zh trans reference/glossary/pod-lifecycle (#17226) * update zh-translation document (#17096) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh-translation:setup-ha-etcd-with-kubeadm.md (#17098) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md (#17227) * add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md (#17228) * zh-translation:content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md (#17089) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md (#17080) * update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_config_view.md (#17085) * zh-translation:troubleshooting-kubeadm.md (#17069) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans: docs/concepts/scheduling/kube-scheduler.md (#17067) * Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn> * Update kube-scheduler.md * Add Chinese translation for kube-scheduler * Update kube-scheduler.md * Update kube-scheduler.md * Update kube-scheduler.md * translate pods.md and init-containers.md for branch release-1.16 (#17208) * update zh translation /docs/contribute/start.md (#17039) * zh-translation:2017-10-00-Five-Days-Of-Kubernetes-18.md (#17229) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * translate kubeadm-certs.md (#17090) * update the Illegal comment such as : (<！--、<--) (#17266) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md (#17268) * update zh /docs/concepts/architecture/cloud-controller.md (#17263) * update zh /docs/concepts/cluster-administration/logging.md (#17247) * modify the show of zh translation /concepts/overview/what-is-kubernetes.md /reference/setup-tools/kubeadm/generated/kubeadm_init.md /reference/setup-tools/kubeadm/kubeadm-init.md (#17246) * zh-translation:kubeadm_init_phase_control-plane_all.md (#17243) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-translation:kubeadm_join_phase_control-plane-join_etcd.md (#17236) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md (#17230) * add content/zh/docs/reference/glossary/container-runtime.md file fix-up to pass the ci and trans content/zh/docs/reference/glossary/container-runtime.md、content/zh/docs/concepts/overview/components.md (#17211) * zh-translation:mirror-pod.md (#17231) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-translation:kubeadm_init_phase_upload-config.md (#17238) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * update zh /docs/concepts/workloads/pods/pod-overview.md (#17239) * update the format of zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md (#17248) * Create advanced.md (#17256) * Create advanced.md * trans the advanced.md and fix the build bugs * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md (#17269) * zh-translation:kubelet-integration.md (#17272) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * pr_release-1.16_out-of-resource (#17199) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md (#17267) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md (#17271) * pr_release-1.16_ext-admission-ctl (#17196) * update zh translation /docs/contribute/advanced.md (#17042) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md (#17275) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md (#17282) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated… (#17287) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md * Update kubeadm_init_phase_etcd.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17285) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-server.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver.md * Update kubeadm_alpha_kubelet.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md fix-up bad comment kubeadm_alpha_certs_renew.md、kubeadm_alpha_certs_renew_apiserver-etcd-client.md、kubeadm_init_phase_addon_all.md (#17276) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17281) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md * Update kubeadm_init_phase_etcd_local.md * zh trans update-daemon-set.md (#16872) * zh trans update-daemon-set.md * Update update-daemon-set.md * managing-tls-in-a-cluster.md (#16874) * update-api-object-kubectl-patch.md (#16875) * improve the zh trans /kubeadm/generated/kubeadm_init_phase_.* 1 (#17295) * improve the zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_.* (#17294) * modify the zh translation content/zh/docs/reference/setup-tools/kubea… (#17293) * modify the zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_.* * Update kubeadm_alpha.md * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md (#17280) * add zh /docs/reference/glossary/cgroup.md (#17291) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md (#17288) * improve zh trans of command in /kubeadm/generated/kubeadm_init_phase_.* files (#17297) * improve zh command translation /kubeadm/generated/kubeadm_init_.* files (#17298) * update zh trans in /kubeadm/generated/kubeadm_.* files (#17306) * add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-peer.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md (#17308) * Improve previously translated documents (#17327) Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * zh-trans: docs/setup/production-environment/turnkey/aws.md (#17320) * Update zh.toml * update zh trans /generated/kubeadm_join_phase_.* files (#17301) * Update zh.toml * add zh /docs/reference/glossary/pod-disruption-budget.md (#17344) * pr_release-1.16_config-aggregation-layer (#17197) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_controller-manager.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_scheduler.conf.md (#17390) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md (#17381) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md (#17380) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md (#17383) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_certificate-key.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md (#17385) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_admin.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md (#17387) * add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_front-proxy-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md (#17384) * add zh /docs/reference/glossary/limitrange.md (#17324) * add zh trans content/zh/docs/setup/best-practices/cluster-large.md (#17321) * add zh trans content/zh/docs/setup/best-practices/cluster-large.md * Update cluster-large.md * add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/do… (#17403) * add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md * Update kubeadm_init_phase_certs_etcd-server.md * add zh /docs/reference/glossary/cluster-operations.md (#17300) * add zh /docs/reference/glossary/applications.md (#17419) * update zh trans kubelet (#17379) * update zh trans kubelet * update the file according to feedback from reviewer tengqm * update 1000-1757 lines * update the advice zh trans * add zh /docs/reference/glossary/static-pod.md (#17418) * add zh /docs/reference/glossary/preemption.md (#17423) * add zh /docs/reference/glossary/pod-priority.md (#17421) * add zh /docs/reference/glossary/control-plane.md (#17425) * add zh /docs/reference/glossary/cluster-infrastructure.md (#17424) * pr_release-1.16_api-overview (#17444) * pr_release-1.16_daemonset (#17435) * pr_release-1.16_gc (#17445) * pr_release-1.16_qos-class (#17442) * fix QoS Class to QoS 类 (#17464) * pr_release-1.16-abac (#17427) * zh-trans:docs/setup/production-environment/turnkey/alibaba-cloud.md (#17345) * pr_release-1.16_endpoint-slice (#17468) * pr_release-1.16_taint (#17469) * pr_release-1.16_operator-pattern (#17467) * pr_release-1.16_ss (#17433) * pr_release-1.16_admission-controller (#17440) * pr_release-1.16_containerd (#17441) * pr_release-1.16_app-container (#17466) * add zh-trans content/zh/docs/setup/_index.md、content/zh/docs/setup/release/_index.md (#17503) * pr-release-1.16_enabling-endpoint-slices (#17504) * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495) * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md、content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md * add content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md * pr-release-1.16_logging (#17491) * pr-release-1.16_cri (#17486) * add zh-trans:docs/setup/production-environment/turnkey/azure.md (#17482) * pattern translate into 模式 (#17485) * fix zk affinity description in zh trans (#17393) * pr-release-1.16_ephemeral-container (#17487) * pr-release-1.16_data-plane (#17489) * pr-release-1.16_cncf (#17490) * zh-trans add content\zh\docs\tools\install-minikube.md (#16920) * zh-trans add content\zh\docs\tools\install-minikube.md * zh-trans update content\zh\docs\tools\install-minikube.md * zh-trans update content\zh\docs\tools\install-minikube.md * update \docs\tasks\tools\install-minikube.md * update docs\concepts\workloads\controllers\deployment.md * update deployment.md * pr-release-1.16_extensions (#17492) * pr-release-1.16_toleration (#17493) * Revert "update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495)" (#17521) This reverts commit 1134c14e0a39bdc3d1a920ac9797139a6dcccf4b. * motidy extensions in content/zh/docs/reference/glossary/extensions (#17524) * motidy toleration in content/zh/docs/reference/glossary/toleration.md (#17523) * motidy toleration in content/zh/docs/reference/glossary/toleration.md * Update toleration.md * improve zh-trans in content/zh/docs/setup/_index.md (#17526) * add zh-trans /zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md (#17527) * Broken Link (#17546) Issue available at https://kubernetes.io/zh/docs/concepts/containers/runtime-class/ and introduced by original English documentation (see #17543) * Update trans kubeadm_upgrade_plan.md (#17395) * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * Update kubeadm_upgrade_plan.md * update zh-trans of define-command-argument-container.md (#17022) Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update zh-trans of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> Add back the Original English Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update title of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update table title and reference Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> update reference of define-command-argument-container.md Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn> * ZH-trans: fix multiple jump links and update files (#17603) * ZH-trans: fix multiple jump links and update files * Update _index.html * update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md (#17528) * update zh trans /doc/concepts/architecture/nodes.md (#17617) * update zh trans content/zh/docs/concepts/architecture/nodes.md * fix-up content/zh/docs/concepts/architecture/nodes.md * add zh-trans /docs/setup/release/notes.md (#17519) * add zh-trans /docs/setup/release/notes.md update-750 * fix-up 1575 line and udpate 2483 line * update to line 2980 * update to the last line 3160 * add zh-trans:docs/setup/production-environment/turnkey/icp.md (#17568) * zh-trans: /docs/setup/production-environment/container-runtimes.md (#17646) * zh-trs:container-runtimes.md Signed-off-by: yuxiaobo <yuxiaobogo@163.com> * Update container-runtimes.md * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese (#17791) * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Sorry, wrong commit, roll back... * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Create trans kubeadm_upgrade_diff.md (#17392) * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Create _index.md (#17831) * zh-trans zh-trans-/docs/reference/command-line-tools-reference/feature-gates.md (#17658) * Update volume-snapshots.md (#17829) * Update volume-snapshots.md * Update volume-snapshots.md * Update volume-snapshots.md * Create ovirt.md (#17849) * Create ovirt.md * Update ovirt.md * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese (#17761) * Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese * Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese * Sorry, wrong commit, roll back... * Update translation after tengqm's review. * Update cloud-providers.md * Update dual-stack.md (#17836) * Update dual-stack.md * Update dual-stack.md * Update dual-stack.md * Update dual-stack.md * Create validate-dual-stack.md (#17833) * Create validate-dual-stack.md * Update validate-dual-stack.md * translation content/zh/docs/reference/setup-tools/kubeadm/ kubeadm-join-phase、kubeadm-reset-phase (#17881) * zh-trans content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md (#17882) * Chinese translation /docs/tasks/administer-cluster/highly-available-master.md (#17884) * Chinese translation /docs/tasks/administer-cluster/highly-available-master.md * Apply suggestions from code review Co-Authored-By: Qiming <tengqim@cn.ibm.com> * Fix format issue (#17921) * Create topology-manager.md (#17901) * Create topology-manager.md * Update topology-manager.md * add zh-trans:docs/setup/production-environment/windows/user-guide-windows-containers.md (#17876) * Update pod-overhead.md (#17931) * Update scheduler-perf-tuning.md (#17934) * Create dcos.md (#17932) * Create dcos.md * Update dcos.md * Update object-management.md (#17937) * zh-translation content/zh/docs/setup/production-environment/tools/kops.md (#17991) * Create imperative-config.md (#17956) * Create imperative-config.md * Update imperative-config.md * Create self-hosting.md (#17950) * Create resource-bin-packing.md (#17935) * Create nodelocaldns.md (#17938) * Update config.toml(release-1.16) for 1.17 (#18025) * Update config.toml(release-1.16) for 1.17 * Update config.toml * Remove ru language * Update the conflict and merge the two commits * add nginx-deployment.yaml file Co-authored-by: ZhongliangXiong <xiong.zhongliang@zte.com.cn> Co-authored-by: Yixiang Wang <wang.yixiang@zte.com.cn> Co-authored-by: li mengyang <hwdef97@gmail.com> Co-authored-by: PingWang <wang.ping5@zte.com.cn> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: Sophy417 <53026875+Sophy417@users.noreply.github.com> Co-authored-by: zhangx501 <zhang0000xun@gmail.com> Co-authored-by: Qiming <tengqim@cn.ibm.com> Co-authored-by: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com> Co-authored-by: senwang <wang.sen2@zte.com.cn> Co-authored-by: lichuqiang <lichuqiang@huawei.com> Co-authored-by: lpf7551321 <liupengfei20@huawei.com> Co-authored-by: Hongcai Ren <renhongcai@huawei.com> Co-authored-by: jiajie <jiaj12@chinaunicom.cn> Co-authored-by: heqg <56527988+heqg@users.noreply.github.com> Co-authored-by: IreneByron <zhangbingqing7@huawei.com> Co-authored-by: Wang Bing <wangbing.adam@gmail.com> Co-authored-by: Damini Satya <daminisatya@gmail.com> Co-authored-by: liufangwai <liufangwai@huawei.com> Co-authored-by: wangcong <congfairy2536@gmail.com> Co-authored-by: XuefeiWang2 <wangxuefei2@huawei.com> Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com> Co-authored-by: Ziqiu Zhu <zzqshu@126.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com> Co-authored-by: jiazxjason <52809535+jiazxjason@users.noreply.github.com> Co-authored-by: Coffey Gao <coffiney@qq.com> Co-authored-by: Bingshen Wang <bingshen.wbs@alibaba-inc.com>
This commit is contained in:
LiuDui
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
9135bdbe6d
commit
b8b2cc7c74
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "运行应用"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Run Applications"
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
@@ -0,0 +1,334 @@
|
||||
---
|
||||
title: 指定应用程序的中断预算（Disruption Budget）
|
||||
content_template: templates/task
|
||||
weight: 110
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
title: Specifying a Disruption Budget for your Application
|
||||
content_template: templates/task
|
||||
weight: 110
|
||||
--- -->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- This page shows how to limit the number of concurrent disruptions
|
||||
that your application experiences, allowing for higher availability
|
||||
while permitting the cluster administrator to manage the clusters
|
||||
nodes. -->
|
||||
|
||||
本文展示了如何限制应用程序的并发中断数量，在允许集群管理员管理集群节点的同时保证高可用。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!-- * You are the owner of an application running on a Kubernetes cluster that requires
|
||||
high availability. -->
|
||||
* 用户是 Kubernetes 集群中有高可用需求的应用的所有者。
|
||||
|
||||
<!-- * You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/). -->
|
||||
* 用户应了解如何部署 [无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
和/或 [有状态应用](/docs/tasks/run-application/run-replicated-stateful-application/)。
|
||||
|
||||
<!-- * You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/). -->
|
||||
* 用户应当已经阅读过关于 [Pod 中断](/docs/concepts/workloads/pods/disruptions/) 的文档。
|
||||
|
||||
<!-- * You should confirm with your cluster owner or service provider that they respect
|
||||
Pod Disruption Budgets. -->
|
||||
* 用户应当与集群所有者或服务提供者确认其遵从 Pod 中断预算（Pod Disruption Budgets）的规则。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- ## Protecting an Application with a PodDisruptionBudget -->
|
||||
## 用 PodDisruptionBudget 来保护应用
|
||||
|
||||
<!-- 1. Identify what application you want to protect with a PodDisruptionBudget (PDB).
|
||||
1. Think about how your application reacts to disruptions.
|
||||
1. Create a PDB definition as a YAML file.
|
||||
1. Create the PDB object from the YAML file. -->
|
||||
|
||||
1. 确定想要使用 PodDisruptionBudget (PDB) 来保护的应用。
|
||||
1. 考虑应用对中断的反应。
|
||||
1. 以 YAML 文件形式定义 PDB 。
|
||||
1. 通过 YAML 文件创建 PDB 对象。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- ## Identify an Application to Protect -->
|
||||
## 确定要保护的应用
|
||||
|
||||
<!-- The most common use case when you want to protect an application
|
||||
specified by one of the built-in Kubernetes controllers: -->
|
||||
用户想要保护通过内置的 Kubernetes 控制器指定的应用，这是最常见的使用场景：
|
||||
|
||||
- Deployment
|
||||
- ReplicationController
|
||||
- ReplicaSet
|
||||
- StatefulSet
|
||||
|
||||
<!-- In this case, make a note of the controller's `.spec.selector`; the same
|
||||
selector goes into the PDBs `.spec.selector`. -->
|
||||
在这种情况下，在控制器的 `.spec.selector` 字段中做记录，并在 PDB 的 `.spec.selector` 字段中加入同样的选择器。
|
||||
|
||||
<!-- You can also use PDBs with pods which are not controlled by one of the above
|
||||
controllers, or arbitrary groups of pods, but there are some restrictions,
|
||||
described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-selectors). -->
|
||||
用户也可以用 PDB 来保护不受上述控制器控制的 pod，或任意组（arbitrary groups）的 pod， 但是正如 [任意控制器和选择器](#arbitrary-controllers-and-selectors) 中描述的，这里存在一些限制。
|
||||
|
||||
<!-- ## Think about how your application reacts to disruptions -->
|
||||
## 考虑应用对中断的反应
|
||||
|
||||
<!-- Decide how many instances can be down at the same time for a short period
|
||||
due to a voluntary disruption. -->
|
||||
确定在自发中断时，多少实例可以在短时间内同时关闭。
|
||||
|
||||
<!-- - Stateless frontends:
|
||||
- Concern: don't reduce serving capacity by more than 10%.
|
||||
- Solution: use PDB with minAvailable 90% for example.
|
||||
- Single-instance Stateful Application:
|
||||
- Concern: do not terminate this application without talking to me.
|
||||
- Possible Solution 1: Do not use a PDB and tolerate occasional downtime.
|
||||
- Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding
|
||||
(outside of Kubernetes) that the cluster operator needs to consult you before
|
||||
termination. When the cluster operator contacts you, prepare for downtime,
|
||||
and then delete the PDB to indicate readiness for disruption. Recreate afterwards.
|
||||
- Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd:
|
||||
- Concern: Do not reduce number of instances below quorum, otherwise writes fail.
|
||||
- Possible Solution 1: set maxUnavailable to 1 (works with varying scale of application).
|
||||
- Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once).
|
||||
- Restartable Batch Job:
|
||||
- Concern: Job needs to complete in case of voluntary disruption.
|
||||
- Possible solution: Do not create a PDB. The Job controller will create a replacement pod. -->
|
||||
|
||||
- 无状态的前端：
|
||||
- 关注：不能降低服务能力 10% 以上。
|
||||
- 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。
|
||||
- 单实例有状态应用：
|
||||
- 关注：不要在不通知的情况下终止该应用。
|
||||
- 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。
|
||||
- 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。意为（Kubernetes 范畴之外的） 集群操作人员需要在终止应用前与用户协商，协商后准备停机，然后删除 PDB 表示准备中断，后续再重新创建。
|
||||
- 多实例有状态应用， 如 Consul、ZooKeeper 或 etcd：
|
||||
- 关注：不要将实例数量减少至低于仲裁规模（below quorum），否则将写入失败。
|
||||
- 可能的解决方案 1：设置 maxUnavailable 值为 1 (适用于不同规模的应用)。
|
||||
- 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。 (允许每次更多的中断)。
|
||||
- 可重新启动的批处理任务：
|
||||
- 关注： 自发中断的情况下，需要确保任务完成。
|
||||
- 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换的 pod。
|
||||
|
||||
<!-- ### Rounding logic when specifying percentages -->
|
||||
### 指定百分比时的舍入逻辑
|
||||
|
||||
<!-- Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage. -->
|
||||
`minAvailable` 或 `maxUnavailable` 的值可以表示为整数或百分比。
|
||||
|
||||
<!-- - When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
|
||||
Pods must always be available, even during a disruption. -->
|
||||
- 指定整数时，它表示许多Pod。 例如，如果将minAvailable设置为10，那么即使在中断期间，也必须始终有10个Pod可用。
|
||||
<!-- - When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
|
||||
total Pods. For instance, if you set `minUnavailable` to `"50%"`, then only 50% of the Pods can be unavailable during a
|
||||
disruption. -->
|
||||
- 通过将值设置为百分比的字符串表示形式（例如“50％”）来指定百分比时，它表示总 Pod 数的百分比。例如，如果将 "minUnavailable" 设置为“50％”，则只有50％的 Pod 可以中断。
|
||||
|
||||
<!-- When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
|
||||
you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
|
||||
Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. You can examine the
|
||||
[code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
|
||||
that controls this behavior. -->
|
||||
如果将值指定为百分比，则可能无法映射到确切数量的 Pod 。例如，如果您有 7 个 Pod ，并且你将 `minAvailable` 设置为 `"50％"`，这不清楚是 3 个 Pod 或 4 个 Pod 必须可用。
|
||||
Kubernetes 向上取整到最接近的整数，因此在这种情况下，必须有 4 个 Pod 。
|
||||
您可以检查控制此行为的[代码](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)。
|
||||
|
||||
<!-- ## Specifying a PodDisruptionBudget -->
|
||||
## 指定 PodDisruptionBudget
|
||||
|
||||
<!-- A `PodDisruptionBudget` has three fields: -->
|
||||
一个 `PodDisruptionBudget` 有 3 个字段：
|
||||
|
||||
<!-- * A label selector `.spec.selector` to specify the set of
|
||||
pods to which it applies. This field is required.
|
||||
* `.spec.minAvailable` which is a description of the number of pods from that
|
||||
set that must still be available after the eviction, even in the absence
|
||||
of the evicted pod. `minAvailable` can be either an absolute number or a percentage.
|
||||
* `.spec.maxUnavailable` (available in Kubernetes 1.7 and higher) which is a description
|
||||
of the number of pods from that set that can be unavailable after the eviction.
|
||||
It can be either an absolute number or a percentage. -->
|
||||
* 标签选择器 `.spec.selector` ，用于指定其所作用的 pod 集合， 该字段为必须字段。
|
||||
* `.spec.minAvailable` 表示驱逐后仍然保证可用的 pod 数量。即使因此影响到 pod 驱逐（即该条件在和 pod 驱逐发生冲突时优先保证）。
|
||||
`minAvailable` 值可以是绝对值，也可以是百分比。
|
||||
* `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的 pod 的最大数量。
|
||||
其值可以是绝对值或是百分比。
|
||||
|
||||
{{< note >}}
|
||||
<!-- For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
|
||||
object using the `kubectl` command line tool, the `minAvailable` field has a
|
||||
default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified. -->
|
||||
对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget`对象时，如果既未指定 `minAvailable` 也未指定 `maxUnavailable`，
|
||||
则 `minAvailable` 字段有一个默认值1。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- You can specify only one of `maxUnavailable` and `minAvailable` in a single `PodDisruptionBudget`.
|
||||
`maxUnavailable` can only be used to control the eviction of pods
|
||||
that have an associated controller managing them. In the examples below, "desired replicas"
|
||||
is the `scale` of the controller managing the pods being selected by the
|
||||
`PodDisruptionBudget`. -->
|
||||
用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。`maxUnavailable`
|
||||
只能够用于控制存在相应控制器的 pod 的驱逐（即不受控制器控制的 pod 不在 `maxUnavailable` 控制范围内）。在下面的示例中，
|
||||
“所需副本” 指的是相应控制器的 `scale`， 控制器对 `PodDisruptionBudget` 所选择的 pod 进行管理。
|
||||
|
||||
<!-- Example 1: With a `minAvailable` of 5, evictions are allowed as long as they leave behind
|
||||
5 or more healthy pods among those selected by the PodDisruptionBudget's `selector`. -->
|
||||
示例 1：设置 `minAvailable` 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 `selector` 选中的 pod 中 5 个 或 5 个以上处于健康状态。
|
||||
|
||||
<!-- Example 2: With a `minAvailable` of 30%, evictions are allowed as long as at least 30%
|
||||
of the number of desired replicas are healthy. -->
|
||||
示例 2：设置 `minAvailable` 值为 30% 的情况下，驱逐时需保证 pod 所需副本的至少 30% 处于健康状态。
|
||||
|
||||
<!-- Example 3: With a `maxUnavailable` of 5, evictions are allowed as long as there are at most 5
|
||||
unhealthy replicas among the total number of desired replicas. -->
|
||||
示例 3：设置 `maxUnavailable` 值为 5 的情况下，驱逐时需保证所需副本中最多 5 个处于不可用状态。
|
||||
|
||||
Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as no more than 30%
|
||||
of the desired replicas are unhealthy.
|
||||
示例4： 设置 `maxUnavailable` 值为 30% 的情况下，驱逐时需保证所需副本中最多 30% 处于不可用状态。
|
||||
|
||||
<!-- In typical usage, a single budget would be used for a collection of pods managed by
|
||||
a controller—for example, the pods in a single ReplicaSet or StatefulSet. -->
|
||||
在典型用法中，中断预算会被用于一个控制器管理的一组 pod 中——例如：一个 ReplicaSet 或 StatefulSet 中的 pod。
|
||||
|
||||
{{< note >}}
|
||||
<!-- A disruption budget does not truly guarantee that the specified
|
||||
number/percentage of pods will always be up. For example, a node that hosts a
|
||||
pod from the collection may fail when the collection is at the minimum size
|
||||
specified in the budget, thus bringing the number of available pods from the
|
||||
collection below the specified size. The budget can only protect against
|
||||
voluntary evictions, not all causes of unavailability. -->
|
||||
注意：中断预算并不能真正保证指定数量/百分比的 pod 一直处于运行状态。例如： 当 pod 集合的
|
||||
规模处于预算指定的最小值时，承载集合中某个 pod 的节点发生了故障，这样就导致集合中可用 pod 的
|
||||
数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 pod 不可用的诱因。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- A `maxUnavailable` of 0% (or 0) or a `minAvailable` of 100% (or equal to the
|
||||
number of replicas) may block node drains entirely. This is permitted as per the
|
||||
semantics of `PodDisruptionBudget`. -->
|
||||
设置 `maxUnavailable` 值为 0% （或 0 ）或设置 `minAvailable` 值为 100% （或等于副本数） 可能会
|
||||
阻塞节点，导致资源耗尽。按照 `PodDisruptionBudget` 的语义，这是允许的。
|
||||
|
||||
<!-- You can find examples of pod disruption budgets defined below. They match pods with the label
|
||||
`app: zookeeper`. -->
|
||||
用户可以在下面看到 pod 中断预算定义的示例，它们与带有 `app: zookeeper` 标签的 pod 相匹配：
|
||||
|
||||
<!-- Example PDB Using minAvailable: -->
|
||||
使用 minAvailable 的PDB 示例：
|
||||
|
||||
{{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
|
||||
|
||||
<!-- Example PDB Using maxUnavailable (Kubernetes 1.7 or higher): -->
|
||||
使用 maxUnavailable 的 PDB 示例（Kubernetes 1.7 或更高的版本）：
|
||||
|
||||
{{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
|
||||
|
||||
<!-- For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
|
||||
specifications have the exact same meaning. The use of `maxUnavailable` is recommended as it
|
||||
automatically responds to changes in the number of replicas of the corresponding controller. -->
|
||||
例如，如果上述 `zk-pdb` 选择的是一个规格为 3 的 StatefulSet 对应的 pod，那么上面两种规范的含义完全相同。
|
||||
推荐使用 `maxUnavailable` ，因为它自动响应控制器副本数量的变化。
|
||||
|
||||
## Create the PDB object
|
||||
## 创建 PDB 对象
|
||||
|
||||
<!-- You can create the PDB object with a command like `kubectl apply -f mypdb.yaml`. -->
|
||||
用户可以通过类似 `kubectl create -f mypdb.yaml` 的命令来创建 PDB。
|
||||
|
||||
<!-- You cannot update PDB objects. They must be deleted and re-created. -->
|
||||
PDB 对象无法更新，必须删除后重新创建。
|
||||
|
||||
## Check the status of the PDB
|
||||
## 检查 PDB 的状态
|
||||
|
||||
<!-- Use kubectl to check that your PDB is created. -->
|
||||
使用 kubectl 来确认 PDB 被创建。
|
||||
|
||||
<!-- Assuming you don't actually have pods matching `app: zookeeper` in your namespace,
|
||||
then you'll see something like this: -->
|
||||
假设用户的名字空间下没有匹配 `app: zookeeper` 的 pod，用户会看到类似下面的信息：
|
||||
|
||||
```shell
|
||||
kubectl get poddisruptionbudgets
|
||||
```
|
||||
```
|
||||
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
|
||||
zk-pdb 2 0 7s
|
||||
```
|
||||
|
||||
<!-- If there are matching pods (say, 3), then you would see something like this: -->
|
||||
假设有匹配的 pod (比如说 3 个), 那么用户会看到类似下面的信息：
|
||||
|
||||
```shell
|
||||
kubectl get poddisruptionbudgets
|
||||
```
|
||||
```
|
||||
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
|
||||
zk-pdb 2 1 7s
|
||||
```
|
||||
|
||||
<!-- The non-zero value for `ALLOWED-DISRUPTIONS` means that the disruption controller has seen the pods,
|
||||
counted the matching pods, and updated the status of the PDB. -->
|
||||
`ALLOWED-DISRUPTIONS` 值非 0 意味着中断控制器已经感知到相应的 pod， 对匹配的 pod 进行统计，并更新了 PDB 的状态。
|
||||
|
||||
<!-- You can get more information about the status of a PDB with this command: -->
|
||||
用户可以通过以下命令获取更多 PDB 状态相关信息：
|
||||
|
||||
```shell
|
||||
kubectl get poddisruptionbudgets zk-pdb -o yaml
|
||||
```
|
||||
```yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodDisruptionBudget
|
||||
metadata:
|
||||
creationTimestamp: 2017-08-28T02:38:26Z
|
||||
generation: 1
|
||||
name: zk-pdb
|
||||
…
|
||||
status:
|
||||
currentHealthy: 3
|
||||
desiredHealthy: 3
|
||||
disruptedPods: null
|
||||
disruptionsAllowed: 1
|
||||
expectedPods: 3
|
||||
observedGeneration: 1
|
||||
```
|
||||
|
||||
<!-- ## Arbitrary Controllers and Selectors -->
|
||||
## 任意控制器和选择器
|
||||
|
||||
<!-- You can skip this section if you only use PDBs with the built-in
|
||||
application controllers (Deployment, ReplicationController, ReplicaSet, and StatefulSet),
|
||||
with the PDB selector matching the controller's selector. -->
|
||||
如果用户只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet）
|
||||
对应的 PDB，也就是 PDB 的选择器与 控制器的选择器相匹配，那么可以跳过这一节。
|
||||
|
||||
<!-- You can use a PDB with pods controlled by another type of controller, by an
|
||||
"operator", or bare pods, but with these restrictions: -->
|
||||
用户可以使用这样的 PDB：它对应的 pod 可能由其他类型的控制器控制，可能由 "operator" 控制，
|
||||
也可能为“裸的（不受控制器控制）” pod，但该类 PDB 存在以下限制：
|
||||
|
||||
- only `.spec.minAvailable` can be used, not `.spec.maxUnavailable`.
|
||||
- only an integer value can be used with `.spec.minAvailable`, not a percentage.
|
||||
- 只能够使用 `.spec.minAvailable` ，而不能够使用 `.spec.maxUnavailable。`
|
||||
- 只能够使用整数作为 `.spec.minAvailable` 的值，而不能使用百分比。
|
||||
|
||||
<!-- You can use a selector which selects a subset or superset of the pods belonging to a built-in
|
||||
controller. However, when there are multiple PDBs in a namespace, you must be careful not
|
||||
to create PDBs whose selectors overlap. -->
|
||||
用户可以令选择器选择一个内置控制器所控制 pod 的子集或父集。然而，当名字空间下存在多个 PDB 时，
|
||||
用户必须小心，保证 PDB 的选择器之间不重叠。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- erictune
|
||||
- foxish
|
||||
- smarterclayton
|
||||
title: 强制删除 StatefulSet 类型的 Pods
|
||||
content_template: templates/task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- erictune
|
||||
- foxish
|
||||
- smarterclayton
|
||||
title: Force Delete StatefulSet Pods
|
||||
content_template: templates/task
|
||||
weight: 70
|
||||
---
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
This page shows how to delete Pods which are part of a stateful set, and explains the considerations to keep in mind when doing so.
|
||||
--->
|
||||
本文介绍了如何删除 StatefulSet 管理的部分 pods，并且解释了这样操作时需要记住的注意事项。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!--
|
||||
* This is a fairly advanced task and has the potential to violate some of the properties inherent to StatefulSet.
|
||||
* Before proceeding, make yourself familiar with the considerations enumerated below.
|
||||
--->
|
||||
* 这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。
|
||||
* 继续任务之前，请熟悉下面列举的注意事项。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## StatefulSet considerations
|
||||
--->
|
||||
## StatefulSet 注意事项
|
||||
|
||||
<!--
|
||||
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
|
||||
--->
|
||||
在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 pod。StatefulSet 控制器负责创建，扩容和删除 StatefulSet 管理的 pods。它尝试确保从序号 0 到 N-1 指定数量的 pods 处于活动状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 pod。这就是所谓的由 StatefulSet 提供的*最多一个*的语义。
|
||||
|
||||
<!--
|
||||
Manual force deletion should be undertaken with caution, as it has the potential to violate the at most one semantics inherent to StatefulSet. StatefulSets may be used to run distributed and clustered applications which have a need for a stable network identity and stable storage. These applications often have configuration which relies on an ensemble of a fixed number of members with fixed identities. Having multiple members with the same identity can be disastrous and may lead to data loss (e.g. split brain scenario in quorum-based systems).
|
||||
--->
|
||||
应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。这些应用通常配置为具有固定标识固定数量的成员集合。具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (e.g. 基于 quorum 系统中的脑裂场景)。
|
||||
|
||||
<!--
|
||||
## Delete Pods
|
||||
--->
|
||||
## 删除 Pods
|
||||
|
||||
<!--
|
||||
You can perform a graceful pod deletion with the following command:
|
||||
--->
|
||||
您可以使用下面的命令执行优雅地删除 pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pods <pod>
|
||||
```
|
||||
|
||||
<!--
|
||||
For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/user-guide/pods/#termination-of-pods) before the kubelet deletes the name from the apiserver.
|
||||
--->
|
||||
为了使上面的方法能够正常终止，Pod **一定不能**设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的 pods 不要使用。优雅删除是安全的，并且会在 kubelet 从 apiserver 中删除名称之前确保 [优雅地关闭 pod ](/docs/user-guide/pods/#termination-of-pods)。
|
||||
|
||||
<!--
|
||||
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
|
||||
--->
|
||||
Kubernetes (1.5 版本或者更新版本)不会因为一个 Node 无法访问而删除 pods。在无法访问节点上运行的 pods 在[超时](/docs/admin/node/#node-condition)后会进入'Terminating' 或者 'Unknown' 状态。当用户尝试优雅删除无法访问节点上的 pod 时，pods 也可能会进入这些状态。从 apiserver 中删除处于这些状态 pod 的唯一方法如下：
|
||||
|
||||
<!--
|
||||
* The Node object is deleted (either by you, or by the [Node Controller](/docs/admin/node)).<br/>
|
||||
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.<br/>
|
||||
* Force deletion of the Pod by the user.
|
||||
--->
|
||||
* Node 对象被删除(要么您删除, 或者[Node Controller](/docs/admin/node))。<br/>
|
||||
* 无响应节点上的 kubelet 开始响应，杀死 pod 并从 apiserver 中移除该条目。<br/>
|
||||
* 用户强制删除 pod。
|
||||
|
||||
<!--
|
||||
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
|
||||
--->
|
||||
推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如，永久断开网络，断电等)，则删除 Node 对象。如果节点遇到网裂，请尝试解决该问题或者等待其解决。当网裂愈合时，kubelet 将完成 pod 的删除并从 apiserver 中释放其名字。
|
||||
|
||||
<!--
|
||||
Normally, the system completes the deletion once the Pod is no longer running on a Node, or the Node is deleted by an administrator. You may override this by force deleting the Pod.
|
||||
--->
|
||||
通常，pod 一旦不在节点上运行，或者管理员删除了节点，系统就会完成删除。你可以通过强制删除 pod 来覆盖它。
|
||||
|
||||
<!--
|
||||
### Force Deletion
|
||||
--->
|
||||
### 强制删除
|
||||
|
||||
<!--
|
||||
Force deletions **do not** wait for confirmation from the kubelet that the Pod has been terminated. Irrespective of whether a force deletion is successful in killing a Pod, it will immediately free up the name from the apiserver. This would let the StatefulSet controller create a replacement Pod with that same identity; this can lead to the duplication of a still-running Pod, and if said Pod can still communicate with the other members of the StatefulSet, will violate the at most one semantics that StatefulSet is designed to guarantee.
|
||||
--->
|
||||
强制删除**不要**等待来自 kubelet 的确认 pod 已被终止。无论强制删除是否成功杀死了 pod，它都会立即从 apiserver 中释放该名字。这将让 StatefulSet 控制器创建一个具有相同标识的替换 pod；这可能导致正在运行 pod 的重复，并且如果所述 pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 旨在保证的最多一个的语义。
|
||||
|
||||
<!--
|
||||
When you force delete a StatefulSet pod, you are asserting that the Pod in question will never again make contact with other Pods in the StatefulSet and its name can be safely freed up for a replacement to be created.
|
||||
--->
|
||||
当你强制删除 StatefulSet 类型的 pod 时，你要确保有问题的 pod 不会再和 StatefulSet 管理的其他 pods通信，并且可以安全地释放其名字以便创建替换 pod。
|
||||
|
||||
<!--
|
||||
If you want to delete a Pod forcibly using kubectl version >= 1.5, do the following:
|
||||
--->
|
||||
如果要使用 kubectl version >= 1.5 强制删除 pod，请执行下面命令：
|
||||
|
||||
```shell
|
||||
kubectl delete pods <pod> --grace-period=0 --force
|
||||
```
|
||||
|
||||
<!--
|
||||
If you're using any version of kubectl <= 1.4, you should omit the `--force` option and use:
|
||||
--->
|
||||
如果您使用 kubectl <= 1.4 的任何版本，则应省略 `--force` 选项：
|
||||
|
||||
```shell
|
||||
kubectl delete pods <pod> --grace-period=0
|
||||
```
|
||||
<!--
|
||||
If even after these commands the pod is stuck on `Unknown` state, use the following command to remove the pod from the cluster:
|
||||
--->
|
||||
如果在这些命令后 pod 仍处于`Unknown`状态，请使用以下命令从集群中删除 pod:
|
||||
|
||||
```shell
|
||||
kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
Always perform force deletion of StatefulSet Pods carefully and with complete knowledge of the risks involved.
|
||||
--->
|
||||
请始终谨慎地执行强制删除 StatefulSet 类型的 pods，并完全了解所涉及地风险。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
|
||||
--->
|
||||
进一步了解[调试 StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/)。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,695 @@
|
||||
---
|
||||
reviewers:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
- justinsb
|
||||
- directxman12
|
||||
title: Horizontal Pod Autoscaler演练
|
||||
content_template: templates/task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Horizontal Pod Autoscaler automatically scales the number of pods
|
||||
in a replication controller, deployment or replica set based on observed CPU utilization
|
||||
(or, with beta support, on some other, application-provided metrics).
|
||||
-->
|
||||
Horizontal Pod Autoscaler 可以根据CPU利用率自动伸缩 replication controller、deployment 或者 replica set 中的Pod数量
|
||||
（也可以基于其他应用程序提供的度量指标，目前这一功能处于 beta 版本）。
|
||||
|
||||
<!--
|
||||
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
-->
|
||||
本文将引导您了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。
|
||||
更多 Horizontal Pod Autoscaler 的信息请参阅 [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!--
|
||||
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
|
||||
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
|
||||
metrics-server monitoring will be turned-on by default.
|
||||
-->
|
||||
本文示例需要一个1.2或者更高版本的可运行的 Kubernetes 集群以及 kubectl。
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 也需要部署到集群中，
|
||||
它可以通过 resource metrics API 对外提供度量数据，Horizontal Pod Autoscaler 正是根据此 API 来获取度量数据，部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。
|
||||
如果你正在使用GCE，按照 [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。
|
||||
|
||||
<!--
|
||||
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
|
||||
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
|
||||
must be able to communicate with the API server providing the custom metrics API. Finally, to use metrics
|
||||
not related to any Kubernetes object you must have a Kubernetes cluster at version 1.10 or later, and
|
||||
you must be able to communicate with the API server that provides the external metrics API.
|
||||
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
|
||||
-->
|
||||
如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，您的 Kubernetes 集群以及 kubectl 至少需要达到1.6版本。
|
||||
此外，如果要使用自定义度量指标，您的Kubernetes 集群还必须能够与提供这些自定义指标的API服务器通信。
|
||||
最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要达到1.10版本，同样，需要保证集群能够与提供这些外部指标的API服务器通信。
|
||||
更多详细信息，请参阅[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Run & expose php-apache server
|
||||
-->
|
||||
## 第一步：运行 php-apache 服务器并暴露服务
|
||||
|
||||
<!--
|
||||
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
|
||||
The Dockerfile has the following content:
|
||||
-->
|
||||
为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。
|
||||
Dockerfile 内容如下：
|
||||
|
||||
```
|
||||
FROM php:5-apache
|
||||
ADD index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
```
|
||||
<!--
|
||||
It defines an index.php page which performs some CPU intensive computations:
|
||||
-->
|
||||
它定义一个 index.php 页面来执行一些 CPU 密集型计算：
|
||||
|
||||
```
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
$x += sqrt($x);
|
||||
}
|
||||
echo "OK!";
|
||||
?>
|
||||
```
|
||||
<!--
|
||||
First, we will start a deployment running the image and expose it as a service:
|
||||
-->
|
||||
首先，我们先启动一个 deployment 来运行这个镜像并暴露一个服务:
|
||||
|
||||
```shell
|
||||
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
|
||||
```
|
||||
```
|
||||
service/php-apache created
|
||||
deployment.apps/php-apache created
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create Horizontal Pod Autoscaler
|
||||
-->
|
||||
## 创建 Horizontal Pod Autoscaler
|
||||
|
||||
<!--
|
||||
Now that the server is running, we will create the autoscaler using
|
||||
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
|
||||
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
|
||||
controlled by the php-apache deployment we created in the first step of these instructions.
|
||||
Roughly speaking, HPA will increase and decrease the number of replicas
|
||||
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
|
||||
(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
|
||||
See [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
|
||||
-->
|
||||
现在，php-apache服务器已经运行，我们将通过 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 命令创建 Horizontal Pod Autoscaler。
|
||||
以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 deployment，使 Pod 的副本数量在维持在1到10之间。
|
||||
大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment ）以保持所有 Pod 的平均CPU利用率在50%以内
|
||||
（由于每个 Pod 通过 [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)
|
||||
申请了200 milli-cores CPU，所以50%的 CPU 利用率意味着平均 CPU 利用率为100 milli-cores）。
|
||||
相关算法的详情请参阅[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)。
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
```
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
||||
```
|
||||
|
||||
<!--
|
||||
We may check the current status of autoscaler by running:
|
||||
-->
|
||||
我们可以通过以下命令查看 autoscaler 的状态：
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
Please note that the current CPU consumption is 0% as we are not sending any requests to the server
|
||||
(the ``CURRENT`` column shows the average across all the pods controlled by the corresponding deployment).
|
||||
-->
|
||||
请注意在上面的命令输出中，当前的CPU利用率是0%，这是由于我们尚未发送任何请求到服务器
|
||||
（``CURRENT`` 列显示了相应 deployment 所控制的所有 Pod 的平均 CPU 利用率）。
|
||||
|
||||
<!--
|
||||
## Increase load
|
||||
-->
|
||||
## 增加负载
|
||||
|
||||
<!--
|
||||
Now, we will see how the autoscaler reacts to increased load.
|
||||
We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
|
||||
-->
|
||||
现在，我们将看到 autoscaler 如何对增加负载作出反应。
|
||||
我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求（请在另一个终端中运行以下命令）：
|
||||
|
||||
```shell
|
||||
kubectl run -i --tty load-generator --image=busybox /bin/sh
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
|
||||
```
|
||||
|
||||
<!--
|
||||
Within a minute or so, we should see the higher CPU load by executing:
|
||||
-->
|
||||
在几分钟时间内，通过以下命令，我们可以看到CPU负载升高了：
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
```
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
Here, CPU consumption has increased to 305% of the request.
|
||||
As a result, the deployment was resized to 7 replicas:
|
||||
-->
|
||||
这时，由于请求增多，CPU利用率已经升至305%。 可以看到，deployment 的副本数量已经增长到了7：
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7 7 7 7 19m
|
||||
```
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
It may take a few minutes to stabilize the number of replicas. Since the amount
|
||||
of load is not controlled in any way it may happen that the final number of replicas
|
||||
will differ from this example.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
有时最终副本的数量可能需要几分钟才能稳定下来。 由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Stop load
|
||||
-->
|
||||
## 停止负载
|
||||
|
||||
<!--
|
||||
We will finish our example by stopping the user load.
|
||||
|
||||
In the terminal where we created the container with `busybox` image, terminate
|
||||
the load generation by typing `<Ctrl> + C`.
|
||||
|
||||
Then we will verify the result state (after a minute or so):
|
||||
-->
|
||||
我们将通过停止负载来结束我们的示例。
|
||||
|
||||
在我们创建 busybox 容器的终端中，输入`<Ctrl> + C`来终止负载的产生。
|
||||
|
||||
然后我们可以再次查看负载状态（等待几分钟时间）：
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 1 1 1 1 27m
|
||||
```
|
||||
|
||||
<!--
|
||||
Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas back down to 1.
|
||||
-->
|
||||
这时，CPU利用率已经降到0，所以 HPA 将自动缩减副本数量至1。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Autoscaling the replicas may take a few minutes.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
自动伸缩完成副本数量的改变可能需要几分钟的时间。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!--
|
||||
## Autoscaling on multiple metrics and custom metrics
|
||||
-->
|
||||
## 基于多项度量指标和自定义度量指标自动伸缩
|
||||
|
||||
<!--
|
||||
You can introduce additional metrics to use when autoscaling the `php-apache` Deployment
|
||||
by making use of the `autoscaling/v2beta2` API version.
|
||||
-->
|
||||
利用`autoscaling/v2beta2`API版本，您可以在自动伸缩 php-apache 这个 Deployment 时引入其他度量指标。
|
||||
|
||||
<!--
|
||||
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
|
||||
-->
|
||||
首先，获取`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 的YAML文件：
|
||||
|
||||
```shell
|
||||
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
|
||||
-->
|
||||
在编辑器中打开`/tmp/hpa-v2.yaml`：
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 50
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
```
|
||||
|
||||
<!--
|
||||
Notice that the `targetCPUUtilizationPercentage` field has been replaced with an array called `metrics`.
|
||||
The CPU utilization metric is a *resource metric*, since it is represented as a percentage of a resource
|
||||
specified on pod containers. Notice that you can specify other resource metrics besides CPU. By default,
|
||||
the only other supported resource metric is memory. These resources do not change names from cluster
|
||||
to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
|
||||
-->
|
||||
需要注意的是，`targetCPUUtilizationPercentage` 字段已经被名为 `metrics` 的数组所取代。
|
||||
CPU利用率这个度量指标是一个*resource metric*(资源度量指标)，因为它表示容器上指定资源的百分比。
|
||||
除CPU外，您还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。
|
||||
只要`metrics.k8s.io` API存在，这些资源度量指标就是可用的，并且他们不会在不同的Kubernetes集群中改变名称。
|
||||
|
||||
<!--
|
||||
You can also specify resource metrics in terms of direct values, instead of as percentages of the
|
||||
requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
|
||||
setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
|
||||
-->
|
||||
您还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将`target`类型`AverageUtilization`替换成`AverageValue`，同时
|
||||
将`target.averageUtilization`替换成`target.averageValue`并设定相应的值。
|
||||
|
||||
<!--
|
||||
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
|
||||
object metrics. These metrics may have names which are cluster specific, and require a more
|
||||
advanced cluster monitoring setup.
|
||||
-->
|
||||
还有两种其他类型的度量指标，他们被认为是*custom metrics*（自定义度量指标）：
|
||||
即 Pod 度量指标和对象度量指标（pod metrics and object metrics）。
|
||||
这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。
|
||||
|
||||
<!--
|
||||
The first of these alternative metric types is *pod metrics*. These metrics describe pods, and
|
||||
are averaged together across pods and compared with a target value to determine the replica count.
|
||||
They work much like resource metrics, except that they *only* support a `target` type of `AverageValue`.
|
||||
-->
|
||||
第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了Pod，在不同Pod之间进行平均，并通过与一个目标值比对来确定副本的数量。
|
||||
它们的工作方式与资源度量指标非常相像，差别是它们仅支持`target` 类型为`AverageValue`。
|
||||
|
||||
<!--
|
||||
Pod metrics are specified using a metric block like this:
|
||||
-->
|
||||
Pod 度量指标通过如下代码块定义：
|
||||
|
||||
```yaml
|
||||
type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 1k
|
||||
```
|
||||
|
||||
<!--
|
||||
The second alternative metric type is *object metrics*. These metrics describe a different
|
||||
object in the same namespace, instead of describing pods. The metrics are not necessarily
|
||||
fetched from the object; they only describe it. Object metrics support `target` types of
|
||||
both `Value` and `AverageValue`. With `Value`, the target is compared directly to the returned
|
||||
metric from the API. With `AverageValue`, the value returned from the custom metrics API is divided
|
||||
by the number of pods before being compared to the target. The following example is the YAML
|
||||
representation of the `requests-per-second` metric.
|
||||
-->
|
||||
第二种可选的度量指标类型是对象度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间(namespace)中的其他对象。
|
||||
请注意这些度量指标用于描述这些对象，并非从对象中获取。
|
||||
对象度量指标支持的`target`类型包括`Value`和`AverageValue`。如果是`Value`类型，target值将直接与API返回的度量指标比较，
|
||||
而`AverageValue`类型，API返回的度量指标将按照 Pod 数量拆分，然后再与target值比较。
|
||||
下面的 YAML 文件展示了一个表示`requests-per-second`的度量指标。
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
type: Value
|
||||
value: 2k
|
||||
```
|
||||
|
||||
<!--
|
||||
If you provide multiple such metric blocks, the HorizontalPodAutoscaler will consider each metric in turn.
|
||||
The HorizontalPodAutoscaler will calculate proposed replica counts for each metric, and then choose the
|
||||
one with the highest replica count.
|
||||
-->
|
||||
如果您指定了多个上述类型的度量指标，HorizontalPodAutoscaler 将会依次考量各个指标。
|
||||
HorizontalPodAutoscaler 将会计算每一个指标所提议的副本数量，然后最终选择一个最高值。
|
||||
|
||||
<!--
|
||||
For example, if you had your monitoring system collecting metrics about network traffic,
|
||||
you could update the definition above using `kubectl edit` to look like this:
|
||||
-->
|
||||
比如，如果您的监控系统能够提供网络流量数据，您可以通过`kubectl edit`命令将上述 Horizontal Pod Autoscaler 的定义更改为：
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: AverageUtilization
|
||||
averageUtilization: 50
|
||||
- type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
targetAverageValue: 1k
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
kind: Value
|
||||
value: 10k
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
current:
|
||||
value: 10k
|
||||
```
|
||||
|
||||
<!--
|
||||
Then, your HorizontalPodAutoscaler would attempt to ensure that each pod was consuming roughly
|
||||
50% of its requested CPU, serving 1000 packets per second, and that all pods behind the main-route
|
||||
Ingress were serving a total of 10000 requests per second.
|
||||
-->
|
||||
然后，您的 HorizontalPodAutoscaler 将会尝试确保每个Pod的CPU利用率在50%以内，每秒能够服务1000个数据包请求，
|
||||
并确保所有在Ingress后的Pod每秒能够服务的请求总数达到10000个。
|
||||
|
||||
<!--
|
||||
### Autoscaling on more specific metrics
|
||||
-->
|
||||
### 多个度量指标下伸缩
|
||||
|
||||
<!--
|
||||
Many metrics pipelines allow you to describe metrics either by name or by a set of additional
|
||||
descriptors called _labels_. For all non-resource metric types (pod, object, and external,
|
||||
described below), you can specify an additional label selector which is passed to your metric
|
||||
pipeline. For instance, if you collect a metric `http_requests` with the `verb`
|
||||
label, you can specify the following metric block to scale only on GET requests:
|
||||
-->
|
||||
许多度量管道允许您通过名称或附加的_labels_来描述度量指标。对于所有非资源类型度量指标(pod、object和后面将介绍的external)，
|
||||
，可以额外指定一个标签选择器。例如，如果你希望收集包含`verb`标签的`http_requests`度量指标，
|
||||
你可以在 GET 请求中指定需要的度量指标，如下所示：
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: `http_requests`
|
||||
selector: `verb=GET`
|
||||
```
|
||||
|
||||
<!--
|
||||
This selector uses the same syntax as the full Kubernetes label selectors. The monitoring pipeline
|
||||
determines how to collapse multiple series into a single value, if the name and selector
|
||||
match multiple series. The selector is additive, and cannot select metrics
|
||||
that describe objects that are **not** the target object (the target pods in the case of the `Pods`
|
||||
type, and the described object in the case of the `Object` type).
|
||||
-->
|
||||
这个选择器使用与 Kubernetes 标签选择器相同的语法。
|
||||
如果名称和标签选择器匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。
|
||||
选择器是附加的，它不会选择目标以外的对象（类型为`Pods`的目标和类型为`Object`的目标）。
|
||||
|
||||
<!--
|
||||
### Autoscaling on metrics not related to Kubernetes objects
|
||||
-->
|
||||
### 基于Kubernetes以外的度量指标伸缩
|
||||
|
||||
<!--
|
||||
Applications running on Kubernetes may need to autoscale based on metrics that don't have an obvious
|
||||
relationship to any object in the Kubernetes cluster, such as metrics describing a hosted service with
|
||||
no direct correlation to Kubernetes namespaces. In Kubernetes 1.10 and later, you can address this use case
|
||||
with *external metrics*.
|
||||
-->
|
||||
运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动伸缩，
|
||||
例如那些描述不在 Kubernetes 任何 namespaces 服务的度量指标。
|
||||
|
||||
<!--
|
||||
Using external metrics requires knowledge of your monitoring system; the setup is
|
||||
similar to that required when using custom metrics. External metrics allow you to autoscale your cluster
|
||||
based on any metric available in your monitoring system. Just provide a `metric` block with a
|
||||
`name` and `selector`, as above, and use the `External` metric type instead of `Object`.
|
||||
If multiple time series are matched by the `metricSelector`,
|
||||
the sum of their values is used by the HorizontalPodAutoscaler.
|
||||
External metrics support both the `Value` and `AverageValue` target types, which function exactly the same
|
||||
as when you use the `Object` type.
|
||||
-->
|
||||
使用外部的度量指标，需要了解你使用的监控系统，相关的设置与使用自定义试题指标类似。
|
||||
External metrics 可以使用你的监控系统的任何指标来自动伸缩你的集群。你只需要在`metric`块中提供`name` 和 `selector`，同时将类型由`Object`改为`External`。
|
||||
如果`metricSelector`匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
|
||||
External metrics 同时支持`Value`和`AverageValue`类型，这与`Object`类型的度量指标相同。
|
||||
|
||||
<!--
|
||||
For example if your application processes tasks from a hosted queue service, you could add the following
|
||||
section to your HorizontalPodAutoscaler manifest to specify that you need one worker per 30 outstanding tasks.
|
||||
-->
|
||||
例如，如果你的应用程序处理主机上的消息队列，
|
||||
为了让每30个任务有1个worker，你可以将下面的内容添加到 HorizontalPodAutoscaler 的配置中。
|
||||
|
||||
```yaml
|
||||
- type: External
|
||||
external:
|
||||
metric:
|
||||
name: queue_messages_ready
|
||||
selector: "queue=worker_tasks"
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 30
|
||||
```
|
||||
|
||||
<!--
|
||||
When possible, it's preferable to use the custom metric target types instead of external metrics, since it's
|
||||
easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows
|
||||
access to any metric, so cluster administrators should take care when exposing it.
|
||||
-->
|
||||
如果可能，还是推荐 custom metric 而不是 external metrics，因为这便于让系统管理员加固 custom metrics API。
|
||||
而 external metrics API 可以允许访问所有的度量指标，当暴露这些服务时，系统管理员需要仔细考虑这个问题。
|
||||
|
||||
<!--
|
||||
## Appendix: Horizontal Pod Autoscaler Status Conditions
|
||||
-->
|
||||
## 附录：Horizontal Pod Autoscaler状态条件
|
||||
|
||||
<!--
|
||||
When using the `autoscaling/v2beta2` form of the HorizontalPodAutoscaler, you will be able to see
|
||||
*status conditions* set by Kubernetes on the HorizontalPodAutoscaler. These status conditions indicate
|
||||
whether or not the HorizontalPodAutoscaler is able to scale, and whether or not it is currently restricted
|
||||
in any way.
|
||||
-->
|
||||
当使用`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 时，您将可以看到 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（status conditions）。
|
||||
这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行伸缩以及是否受到一定的限制。
|
||||
|
||||
<!--
|
||||
The conditions appear in the `status.conditions` field. To see the conditions affecting a HorizontalPodAutoscaler,
|
||||
we can use `kubectl describe hpa`:
|
||||
-->
|
||||
`status.conditions`字段展示了这些状态条件。
|
||||
可以通过`kubectl describe hpa`命令查看当前影响 HorizontalPodAutoscaler 的各种状态条件信息：
|
||||
|
||||
```shell
|
||||
kubectl describe hpa cm-test
|
||||
```
|
||||
```shell
|
||||
Name: cm-test
|
||||
Namespace: prom
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000
|
||||
Reference: ReplicationController/cm-test
|
||||
Metrics: ( current / target )
|
||||
"http_requests" on pods: 66m / 500m
|
||||
Min replicas: 1
|
||||
Max replicas: 4
|
||||
ReplicationController pods: 1 current / 1 desired
|
||||
Conditions:
|
||||
Type Status Reason Message
|
||||
---- ------ ------ -------
|
||||
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
|
||||
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_requests
|
||||
ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range
|
||||
Events:
|
||||
```
|
||||
|
||||
<!--
|
||||
For this HorizontalPodAutoscaler, we can see several conditions in a healthy state. The first,
|
||||
`AbleToScale`, indicates whether or not the HPA is able to fetch and update scales, as well as
|
||||
whether or not any backoff-related conditions would prevent scaling. The second, `ScalingActive`,
|
||||
indicates whether or not the HPA is enabled (i.e. the replica count of the target is not zero) and
|
||||
is able to calculate desired scales. When it is `False`, it generally indicates problems with
|
||||
fetching metrics. Finally, the last condition, `ScalingLimited`, indicates that the desired scale
|
||||
was capped by the maximum or minimum of the HorizontalPodAutoscaler. This is an indication that
|
||||
you may wish to raise or lower the minimum or maximum replica count constraints on your
|
||||
HorizontalPodAutoscaler.
|
||||
-->
|
||||
对于上面展示的这个 HorizontalPodAutoscaler，我们可以看出有若干状态条件处于健康状态。
|
||||
首先，`AbleToScale` 表明 HPA 是否可以获取和更新伸缩信息，以及是否存在阻止伸缩的各种回退条件。
|
||||
其次，`ScalingActive` 表明HPA是否被启用（即目标的副本数量不为零） 以及是否能够完成伸缩计算。
|
||||
当这一状态为 `False` 时，通常表明获取度量指标存在问题。
|
||||
最后一个条件 `ScalingLimitted` 表明所需伸缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小伸缩值）。
|
||||
这通常表明您可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。
|
||||
|
||||
<!--
|
||||
## Appendix: Quantities
|
||||
-->
|
||||
## 附录：Quantities
|
||||
|
||||
<!--
|
||||
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
|
||||
a special whole-number notation known in Kubernetes as a *quantity*. For example,
|
||||
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
|
||||
will return whole numbers without a suffix when possible, and will generally return
|
||||
quantities in milli-units otherwise. This means you might see your metric value fluctuate
|
||||
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
|
||||
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
|
||||
-->
|
||||
HorizontalPodAutoscaler 和 metrics api 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （）殊整数表示。
|
||||
例如，数量`10500m`用十进制表示为`10.5`。
|
||||
如果可能的话，metrics api 将返回没有后缀的整数，否则返回以千分单位的数量。
|
||||
这意味着您可能会看到您的度量指标在`1`和`1500m`之间波动，或者在十进制记数法中的`1`和`1.5`。
|
||||
更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity)
|
||||
|
||||
<!--
|
||||
## Appendix: Other possible scenarios
|
||||
-->
|
||||
## 附录：其他可能的情况
|
||||
|
||||
<!--
|
||||
### Creating the autoscaler declaratively
|
||||
-->
|
||||
### 使用YAML文件创建 autoscaler
|
||||
|
||||
<!--
|
||||
Instead of using `kubectl autoscale` command to create a HorizontalPodAutoscaler imperatively we
|
||||
can use the following file to create it declaratively:
|
||||
-->
|
||||
除了使用 `kubectl autoscale` 命令，也可以文件创建 HorizontalPodAutoscaler ：
|
||||
|
||||
{{< codenew file="application/hpa/php-apache.yaml" >}}
|
||||
|
||||
<!--
|
||||
We will create the autoscaler by executing the following command:
|
||||
-->
|
||||
使用如下命令创建 autoscaler：
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
|
||||
```
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache created
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,559 @@
|
||||
---
|
||||
reviewers:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
- directxman12
|
||||
title: Pod 水平自动伸缩
|
||||
feature:
|
||||
title: 水平伸缩
|
||||
description: >
|
||||
使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行伸缩。
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
The Horizontal Pod Autoscaler automatically scales the number of pods
|
||||
in a replication controller, deployment or replica set based on observed CPU utilization (or, with
|
||||
[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
|
||||
support, on some other application-provided metrics). Note that Horizontal
|
||||
Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets.
|
||||
-->
|
||||
Pod 水平自动伸缩（Horizontal Pod Autoscaler）特性，
|
||||
可以基于CPU利用率自动伸缩 replication controller、deployment和 replica set 中的 pod 数量，（除了 CPU 利用率）也可以
|
||||
基于其他应程序提供的度量指标[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)。
|
||||
pod 自动缩放不适用于无法缩放的对象，比如 DaemonSets。
|
||||
|
||||
<!--
|
||||
The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
|
||||
The resource determines the behavior of the controller.
|
||||
The controller periodically adjusts the number of replicas in a replication controller or deployment
|
||||
to match the observed average CPU utilization to the target specified by user.
|
||||
-->
|
||||
Pod 水平自动伸缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
|
||||
控制器会周期性的获取平均 CPU 利用率，并与目标值相比较后来调整 replication controller 或 deployment 中的副本数量。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## How does the Horizontal Pod Autoscaler work?
|
||||
-->
|
||||
## Pod 水平自动伸缩工作机制
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
The Horizontal Pod Autoscaler is implemented as a control loop, with a period controlled
|
||||
by the controller manager's `--horizontal-pod-autoscaler-sync-period` flag (with a default
|
||||
value of 15 seconds).
|
||||
-->
|
||||
Pod 水平自动伸缩的实现是一个控制循环，由 controller manager 的 `--horizontal-pod-autoscaler-sync-period` 参数
|
||||
指定周期（默认值为15秒）。
|
||||
|
||||
<!--
|
||||
During each period, the controller manager queries the resource utilization against the
|
||||
metrics specified in each HorizontalPodAutoscaler definition. The controller manager
|
||||
obtains the metrics from either the resource metrics API (for per-pod resource metrics),
|
||||
or the custom metrics API (for all other metrics).
|
||||
-->
|
||||
每个周期内，controller manager 根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
|
||||
controller manager 可以从 resource metrics API（每个pod 资源指标）和 custom metrics API（其他指标）获取指标。
|
||||
|
||||
<!--
|
||||
* For per-pod resource metrics (like CPU), the controller fetches the metrics
|
||||
from the resource metrics API for each pod targeted by the HorizontalPodAutoscaler.
|
||||
Then, if a target utilization value is set, the controller calculates the utilization
|
||||
value as a percentage of the equivalent resource request on the containers in
|
||||
each pod. If a target raw value is set, the raw metric values are used directly.
|
||||
The controller then takes the mean of the utilization or the raw value (depending on the type
|
||||
of target specified) across all targeted pods, and produces a ratio used to scale
|
||||
the number of desired replicas.
|
||||
-->
|
||||
* 对于每个 pod 的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定
|
||||
的 pod 的指标，然后，如果设置了目标使用率，控制器获取每个 pod 中的容器资源使用情况，并计算资源使用率。
|
||||
如果使用原始值，将直接使用原始数据（不再计算百分比）。
|
||||
然后，控制器根据平均的资源使用率或原始值计算出缩放的比例，进而计算出目标副本数。
|
||||
|
||||
<!--
|
||||
Please note that if some of the pod's containers do not have the relevant resource request set,
|
||||
CPU utilization for the pod will not be defined and the autoscaler will
|
||||
not take any action for that metric. See the [algorithm
|
||||
details](#algorithm-details) section below for more information about
|
||||
how the autoscaling algorithm works.
|
||||
-->
|
||||
需要注意的是，如果 pod 某些容器不支持资源采集，那么控制器将不会使用该 pod 的 CPU 使用率。
|
||||
下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。
|
||||
|
||||
<!--
|
||||
* For per-pod custom metrics, the controller functions similarly to per-pod resource metrics,
|
||||
except that it works with raw values, not utilization values.
|
||||
-->
|
||||
* 如果 pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。
|
||||
|
||||
<!--
|
||||
* For object metrics and external metrics, a single metric is fetched, which describes
|
||||
the object in question. This metric is compared to the target
|
||||
value, to produce a ratio as above. In the `autoscaling/v2beta2` API
|
||||
version, this value can optionally be divided by the number of pods before the
|
||||
comparison is made.
|
||||
-->
|
||||
* 如果pod 使用对象指标和外部指标（每个指标描述一个对象信息）。
|
||||
这个指标将直接跟据目标设定值相比较，并生成一个上面提到的缩放比例。在 `autoscaling/v2beta2` 版本API中，
|
||||
这个指标也可以根据 pod 数量平分后再计算。
|
||||
|
||||
<!--
|
||||
The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
|
||||
`custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by
|
||||
metrics-server, which needs to be launched separately. See
|
||||
[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
|
||||
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
|
||||
-->
|
||||
通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`和`external.metrics.k8s.io`）
|
||||
中获取指标数据。
|
||||
`metrics.k8s.io` API 通常由 metrics-server（需要额外启动）提供。
|
||||
可以从[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。
|
||||
另外，控制器也可以直接从 Heapster 获取指标。
|
||||
|
||||
{{< note >}}
|
||||
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
|
||||
<!--
|
||||
Fetching metrics from Heapster is deprecated as of Kubernetes 1.11.
|
||||
-->
|
||||
自 Kubernetes 1.11起，从 Heapster 获取指标特性已废弃。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
See [Support for metrics APIs](#support-for-metrics-apis) for more details.
|
||||
-->
|
||||
关于指标 API 更多信息，请参考[Support for metrics APIs](#support-for-metrics-apis)。
|
||||
|
||||
<!--
|
||||
The autoscaler accesses corresponding scalable controllers (such as replication controllers, deployments, and replica sets)
|
||||
by using the scale sub-resource. Scale is an interface that allows you to dynamically set the number of replicas and examine
|
||||
each of their current states. More details on scale sub-resource can be found
|
||||
[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
|
||||
-->
|
||||
自动缩放控制器使用 scale sub-resource 访问相应可支持缩放的控制器（如replication controllers、deployments 和 replica sets）。
|
||||
`scale` 是一个可以动态设定副本数量和检查当前状态的接口。
|
||||
更多关于 scale sub-resource 的信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
|
||||
|
||||
<!--
|
||||
### Algorithm Details
|
||||
-->
|
||||
### 算法细节
|
||||
|
||||
<!--
|
||||
From the most basic perspective, the Horizontal Pod Autoscaler controller
|
||||
operates on the ratio between desired metric value and current metric
|
||||
value:
|
||||
-->
|
||||
从最基本的角度来看，pod 水平自动缩放控制器跟据当前指标和期望指标来计算缩放比例。
|
||||
|
||||
<!--
|
||||
```
|
||||
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
|
||||
```
|
||||
-->
|
||||
```
|
||||
期望副本数 = ceil[当前副本数 * ( 当前指标 / 期望指标 )]
|
||||
```
|
||||
|
||||
<!--
|
||||
For example, if the current metric value is `200m`, and the desired value
|
||||
is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 ==
|
||||
2.0` If the current value is instead `50m`, we'll halve the number of
|
||||
replicas, since `50.0 / 100.0 == 0.5`. We'll skip scaling if the ratio is
|
||||
sufficiently close to 1.0 (within a globally-configurable tolerance, from
|
||||
the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
|
||||
-->
|
||||
例如，当前指标为`200m`，目标设定值为`100m`,那么由于`200.0 / 100.0 == 2.0`，
|
||||
副本数量将会翻倍。
|
||||
如果当前指标为`50m`，副本数量将会减半，因为`50.0 / 100.0 == 0.5`。
|
||||
如果计算出的缩放比例接近1.0（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为0.1），
|
||||
将会放弃本次缩放。
|
||||
|
||||
<!--
|
||||
When a `targetAverageValue` or `targetAverageUtilization` is specified,
|
||||
the `currentMetricValue` is computed by taking the average of the given
|
||||
metric across all Pods in the HorizontalPodAutoscaler's scale target.
|
||||
Before checking the tolerance and deciding on the final values, we take
|
||||
pod readiness and missing metrics into consideration, however.
|
||||
-->
|
||||
如果 HorizontalPodAutoscaler 指定的是`targetAverageValue` 或 `targetAverageUtilization`，
|
||||
那么将会把指定pod的平均指标做为`currentMetricValue`。
|
||||
然而，在检查容忍度和决定最终缩放值前，我们仍然会把那些无法获取指标的pod统计进去。
|
||||
|
||||
<!--
|
||||
All Pods with a deletion timestamp set (i.e. Pods in the process of being
|
||||
shut down) and all failed Pods are discarded.
|
||||
-->
|
||||
所有被标记了删除时间戳(Pod正在关闭过程中)的 pod 和 失败的 pod 都会被忽略。
|
||||
|
||||
<!--
|
||||
If a particular Pod is missing metrics, it is set aside for later; Pods
|
||||
with missing metrics will be used to adjust the final scaling amount.
|
||||
-->
|
||||
如果某个 pod 缺失指标信息，它将会被搁置，只在最终确定缩值时再考虑。
|
||||
|
||||
<!--
|
||||
When scaling on CPU, if any pod has yet to become ready (i.e. it's still
|
||||
initializing) *or* the most recent metric point for the pod was before it
|
||||
became ready, that pod is set aside as well.
|
||||
-->
|
||||
当使用 CPU 指标来缩放时，任何还未就绪（例如还在初始化）状态的 pod *或* 最近的指标为就绪状态前的 pod，
|
||||
也会被搁置
|
||||
|
||||
<!--
|
||||
Due to technical constraints, the HorizontalPodAutoscaler controller
|
||||
cannot exactly determine the first time a pod becomes ready when
|
||||
determining whether to set aside certain CPU metrics. Instead, it
|
||||
considers a Pod "not yet ready" if it's unready and transitioned to
|
||||
unready within a short, configurable window of time since it started.
|
||||
This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` flag, and its default is 30
|
||||
seconds. Once a pod has become ready, it considers any transition to
|
||||
ready to be the first if it occurred within a longer, configurable time
|
||||
since it started. This value is configured with the `--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its
|
||||
default is 5 minutes.
|
||||
-->
|
||||
由于受技术限制，pod 水平缩放控制器无法准确的知道 pod 什么时候就绪，
|
||||
也就无法决定是否暂时搁置该 pod。
|
||||
`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为30s），用于设置 pod 准备时间，
|
||||
在此时间内的 pod 统统被认为未就绪。
|
||||
`--horizontal-pod-autoscaler-cpu-initialization-period`参数（默认为5分钟），用于设置 pod 的初始化时间，
|
||||
在此时间内的 pod，CPU 资源指标将不会被采纳。
|
||||
|
||||
<!--
|
||||
The `currentMetricValue / desiredMetricValue` base scale ratio is then
|
||||
calculated using the remaining pods not set aside or discarded from above.
|
||||
-->
|
||||
在排除掉被搁置的 pod 后，缩放比例就会跟据`currentMetricValue / desiredMetricValue`计算出来。
|
||||
|
||||
<!--
|
||||
If there were any missing metrics, we recompute the average more
|
||||
conservatively, assuming those pods were consuming 100% of the desired
|
||||
value in case of a scale down, and 0% in case of a scale up. This dampens
|
||||
the magnitude of any potential scale.
|
||||
-->
|
||||
如果有任何 pod 的指标缺失，我们会更保守地重新计算平均值，
|
||||
在需要缩小时假设这些 pod 消耗了目标值的 100%，
|
||||
在需要放大时假设这些 pod 消耗了0%目标值。
|
||||
这可以在一定程度上抑制伸缩的幅度。
|
||||
|
||||
<!--
|
||||
Furthermore, if any not-yet-ready pods were present, and we would have
|
||||
scaled up without factoring in missing metrics or not-yet-ready pods, we
|
||||
conservatively assume the not-yet-ready pods are consuming 0% of the
|
||||
desired metric, further dampening the magnitude of a scale up.
|
||||
-->
|
||||
此外，如果存在任何尚未就绪的pod，我们可以在不考虑遗漏指标或尚未就绪的pods的情况下进行伸缩，
|
||||
我们保守地假设尚未就绪的pods消耗了试题指标的0%，从而进一步降低了伸缩的幅度。
|
||||
|
||||
<!--
|
||||
After factoring in the not-yet-ready pods and missing metrics, we
|
||||
recalculate the usage ratio. If the new ratio reverses the scale
|
||||
direction, or is within the tolerance, we skip scaling. Otherwise, we use
|
||||
the new ratio to scale.
|
||||
-->
|
||||
在缩放方向（缩小或放大）确定后，我们会把未就绪的 pod 和缺少指标的 pod 考虑进来再次计算使用率。
|
||||
如果新的比率与缩放方向相反，或者在容忍范围内，则跳过缩放。
|
||||
否则，我们使用新的缩放比例。
|
||||
|
||||
<!--
|
||||
Note that the *original* value for the average utilization is reported
|
||||
back via the HorizontalPodAutoscaler status, without factoring in the
|
||||
not-yet-ready pods or missing metrics, even when the new usage ratio is
|
||||
used.
|
||||
-->
|
||||
注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（
|
||||
即使使用了新的使用率，也不考虑未就绪 pod 和 缺少指标的 pod)。
|
||||
|
||||
<!--
|
||||
If multiple metrics are specified in a HorizontalPodAutoscaler, this
|
||||
calculation is done for each metric, and then the largest of the desired
|
||||
replica counts is chosen. If any of those metrics cannot be converted
|
||||
into a desired replica count (e.g. due to an error fetching the metrics
|
||||
from the metrics APIs), scaling is skipped.
|
||||
-->
|
||||
如果创建 HorizontalPodAutoscaler 时指定了多个指标，
|
||||
那么会按照每个指标分别计算缩放副本数，取最大的进行缩放。
|
||||
如果任何一个指标无法顺利的计算出缩放副本数（比如，通过 API 获取指标时出错），
|
||||
那么本次缩放会被跳过。
|
||||
|
||||
<!--
|
||||
Finally, just before HPA scales the target, the scale recommendation is recorded. The
|
||||
controller considers all recommendations within a configurable window choosing the
|
||||
highest recommendation from within that window.
|
||||
This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
|
||||
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
|
||||
fluctuating metric values.
|
||||
-->
|
||||
最后，在 HPA 控制器执行缩放操作之前，会记录缩放建议信息（scale recommendation）。
|
||||
控制器会在操作时间窗口中考虑所有的建议信息，并从中选择得分最高的建议。
|
||||
这个值可通过 kube-controller-manager 服务的启动参数 `--horizontal-pod-autoscaler-downscale-stabilization` 进行配置，
|
||||
默认值为 5min。
|
||||
这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。
|
||||
|
||||
<!--
|
||||
## API Object
|
||||
-->
|
||||
## API 对象
|
||||
|
||||
<!--
|
||||
The Horizontal Pod Autoscaler is an API resource in the Kubernetes `autoscaling` API group.
|
||||
The current stable version, which only includes support for CPU autoscaling,
|
||||
can be found in the `autoscaling/v1` API version.
|
||||
-->
|
||||
HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。
|
||||
在当前稳定版本（`autoscaling/v1`）中只支持基于CPU指标的缩放。
|
||||
|
||||
<!--
|
||||
The beta version, which includes support for scaling on memory and custom metrics,
|
||||
can be found in `autoscaling/v2beta2`. The new fields introduced in `autoscaling/v2beta2`
|
||||
are preserved as annotations when working with `autoscaling/v1`.
|
||||
-->
|
||||
在 beta 版本（`autoscaling/v2beta2`），引入了基于内存和自定义指标的缩放。
|
||||
在`autoscaling/v2beta2`版本中新引入的字段在`autoscaling/v1`版本中基于 annotation 实现。
|
||||
|
||||
<!--
|
||||
More details about the API object can be found at
|
||||
[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
-->
|
||||
更多有关 API 对象的信息，请查阅[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。
|
||||
|
||||
<!--
|
||||
## Support for Horizontal Pod Autoscaler in kubectl
|
||||
-->
|
||||
## 使用 kubectl 操作 Horizontal Pod Autoscaler
|
||||
|
||||
<!--
|
||||
Horizontal Pod Autoscaler, like every API resource, is supported in a standard way by `kubectl`.
|
||||
We can create a new autoscaler using `kubectl create` command.
|
||||
We can list autoscalers by `kubectl get hpa` and get detailed description by `kubectl describe hpa`.
|
||||
Finally, we can delete an autoscaler using `kubectl delete hpa`.
|
||||
-->
|
||||
与其他 API 资源类似，`kubectl` 也标准支持 Pod 自动伸缩。
|
||||
我们可以通过 `kubectl create` 命令创建一个自动伸缩对象，
|
||||
通过 `kubectl get hpa` 命令来获取所有自动伸缩对象，
|
||||
通过 `kubectl describe hpa` 命令来查看自动伸缩对象的详细信息。
|
||||
最后，可以使用 `kubectl delete hpa` 命令删除对象。
|
||||
|
||||
<!--
|
||||
In addition, there is a special `kubectl autoscale` command for easy creation of a Horizontal Pod Autoscaler.
|
||||
For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
|
||||
will create an autoscaler for replication set *foo*, with target CPU utilization set to `80%`
|
||||
and the number of replicas between 2 and 5.
|
||||
The detailed documentation of `kubectl autoscale` can be found [here](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
-->
|
||||
此外，还有个简便的命令 `kubectl autoscale` 来创建自动伸缩对象。
|
||||
例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名
|
||||
为 *foo* 的 replication set 创建一个自动伸缩对象，
|
||||
对象目标CPU使用率为 `80%`，副本数量配置为 2 到 5 之间。
|
||||
|
||||
<!--
|
||||
## Autoscaling during rolling update
|
||||
-->
|
||||
|
||||
## 滚动升级时缩放
|
||||
|
||||
<!--
|
||||
Currently in Kubernetes, it is possible to perform a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)
|
||||
by managing replication controllers directly,
|
||||
or by using the deployment object, which manages the underlying replica sets for you.
|
||||
Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
|
||||
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
|
||||
-->
|
||||
目前在 Kubernetes 中，可以针对 replication controllers 或 deployment 执行
|
||||
滚动升级[rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)，他们会为你管理底层副本数。
|
||||
Pod 水平缩放只支持后一种：Horizontal Pod Autoscaler 会被绑定到 deployment 对象中，Horizontal Pod Autoscaler 设置副本数量时，
|
||||
deployment 会设置底层副本数。
|
||||
|
||||
<!--
|
||||
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
|
||||
i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update (e.g. using `kubectl rolling-update`).
|
||||
The reason this doesn't work is that when rolling update creates a new replication controller,
|
||||
the Horizontal Pod Autoscaler will not be bound to the new replication controller.
|
||||
-->
|
||||
当使用 replication controllers 执行滚动升级时， Horizontal Pod Autoscaler 不能工作，
|
||||
也就是说你不能将 Horizontal Pod Autoscaler 绑定到某个 replication controller
|
||||
再执行滚动升级（例如使用 `kubectl rolling-update` 命令）。
|
||||
Horizontal Pod Autoscaler 不能工作的原因是，Horizontal Pod Autoscaler 无法绑定到滚动升级时创建的新副本。
|
||||
|
||||
<!--
|
||||
## Support for cooldown/delay
|
||||
-->
|
||||
## 冷却/延迟
|
||||
|
||||
<!--
|
||||
When managing the scale of a group of replicas using the Horizontal Pod Autoscaler,
|
||||
it is possible that the number of replicas keeps fluctuating frequently due to the
|
||||
dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*.
|
||||
-->
|
||||
当使用 Horizontal Pod Autoscaler 管理一组副本缩放时，
|
||||
有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为 *抖动*。
|
||||
|
||||
<!--
|
||||
Starting from v1.6, a cluster operator can mitigate this problem by tuning
|
||||
the global HPA settings exposed as flags for the `kube-controller-manager` component:
|
||||
-->
|
||||
从 v1.6 版本起，集群操作员可以开启某些 `kube-controller-manager` 全局的参数来缓和这个问题。
|
||||
|
||||
<!--
|
||||
Starting from v1.12, a new algorithmic update removes the need for the
|
||||
upscale delay.
|
||||
-->
|
||||
从 v1.12 开始，算法调整后，就不用这么做了。
|
||||
|
||||
<!--
|
||||
- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
|
||||
duration that specifies how long the autoscaler has to wait before another
|
||||
downscale operation can be performed after the current one has completed.
|
||||
The default value is 5 minutes (`5m0s`).
|
||||
-->
|
||||
- `--horizontal-pod-autoscaler-downscale-stabilization`: 这个 `kube-controller-manager` 的参数表示缩容冷却时间。
|
||||
即自从上次缩容执行结束后，多久可以再次执行缩容，默认时间是5分钟(`5m0s`)。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
When tuning these parameter values, a cluster operator should be aware of the possible
|
||||
consequences. If the delay (cooldown) value is set too long, there could be complaints
|
||||
that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if
|
||||
the delay value is set too short, the scale of the replicas set may keep thrashing as
|
||||
usual.
|
||||
-->
|
||||
当启用这个参数时，集群操作员需要明白其可能的影响。
|
||||
如果延迟（冷却）时间设置的太长，那么 Horizontal Pod Autoscaler 可能会不能很好的改变负载。
|
||||
如果延迟（冷却）时间设备的太短，那么副本数量有可能跟以前一样抖动。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Support for multiple metrics
|
||||
-->
|
||||
## 多指标支持
|
||||
|
||||
<!--
|
||||
Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API
|
||||
version to specify multiple metrics for the Horizontal Pod Autoscaler to scale on. Then, the Horizontal Pod
|
||||
Autoscaler controller will evaluate each metric, and propose a new scale based on that metric. The largest of the
|
||||
proposed scales will be used as the new scale.
|
||||
-->
|
||||
在 Kubernetes 1.6 支持了基于多个指标进行缩放。
|
||||
你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。
|
||||
Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个缩放建议。
|
||||
幅度最大的缩放建议会被采纳。
|
||||
|
||||
<!--
|
||||
## Support for custom metrics
|
||||
-->
|
||||
## 自定义指标支持
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
|
||||
Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API. While the old method for collecting
|
||||
custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
|
||||
annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
|
||||
-->
|
||||
在 Kubernetes 1.2 增加的 alpha 的缩放支持基于特定的 annotation。
|
||||
自从 Kubernetes 1.6 起，由于缩放 API 的引入，这些 annotation 就不再支持了。
|
||||
虽然收集自定义指标的旧方法仍然可用，但是 Horizontal Pod Autoscaler 调度器将不会再使用这些指标，
|
||||
同时，Horizontal Pod Autoscaler 也不再使用之前的用于指定用户自定义指标的 annotation 了。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler.
|
||||
You can add custom metrics for the Horizontal Pod Autoscaler to use in the `autoscaling/v2beta2` API.
|
||||
Kubernetes then queries the new custom metrics API to fetch the values of the appropriate custom metrics.
|
||||
-->
|
||||
自 Kubernetes 1.6 起，Horizontal Pod Autoscaler 支持使用自定义指标。
|
||||
你可以使用 `autoscaling/v2beta2` API 为 Horizontal Pod Autoscaler 指定用户自定义指标。
|
||||
Kubernetes 会通过用户自定义指标 API 来获取相应的指标。
|
||||
|
||||
<!--
|
||||
See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
|
||||
-->
|
||||
关于指标 API 的要求，请查阅 [Support for metrics APIs](#support-for-metrics-apis)。
|
||||
|
||||
<!--
|
||||
## Support for metrics APIs
|
||||
-->
|
||||
## 指标 API
|
||||
|
||||
<!--
|
||||
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
|
||||
APIs, cluster administrators must ensure that:
|
||||
-->
|
||||
默认情况下，HorizontalPodAutoscaler 控制器会从一系列的 API 中请求指标数据。
|
||||
集群管理员需要确保下述条件，以保证这些 API 可以访问：
|
||||
|
||||
<!--
|
||||
* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled.
|
||||
-->
|
||||
* [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 已开启
|
||||
|
||||
<!--
|
||||
* The corresponding APIs are registered:
|
||||
|
||||
* For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-incubator/metrics-server).
|
||||
It can be launched as a cluster addon.
|
||||
|
||||
* For custom metrics, this is the `custom.metrics.k8s.io` API. It's provided by "adapter" API servers provided by metrics solution vendors.
|
||||
Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
|
||||
If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) to get started.
|
||||
|
||||
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
|
||||
-->
|
||||
|
||||
* 相应的 API 已注册：
|
||||
|
||||
* 资源指标会使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
|
||||
它可以做为集群组件启动。
|
||||
* 用户指标会使用 `custom.metrics.k8s.io` API。
|
||||
它由其他厂商的“适配器”API 服务器提供。
|
||||
确认你的指标管道，或者查看 [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
|
||||
* 外部指标会使用 `external.metrics.k8s.io` API。可能由上面的用户指标适配器提供。
|
||||
|
||||
<!--
|
||||
* The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset. Setting this to false switches to Heapster-based autoscaling, which is deprecated.
|
||||
-->
|
||||
* `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。
|
||||
如果设置为 false，则会切换到基于 Heapster 的自动缩放，这个特性已经被弃用了。
|
||||
|
||||
<!--
|
||||
For more information on these different metrics paths and how they differ please see the relevant design proposals for
|
||||
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
|
||||
-->
|
||||
更多关于指标来源以及其区别，请参阅相关的设计文档，
|
||||
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)和
|
||||
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。
|
||||
|
||||
<!--
|
||||
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
|
||||
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
|
||||
-->
|
||||
如何使用它们的示例，请参考
|
||||
[the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
|
||||
和 [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
|
||||
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
-->
|
||||
* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
|
||||
* kubectl 自动缩放命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* 使用示例：[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,33 +1,89 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: 基于Replication Controller执行滚动升级
|
||||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: Perform Rolling Update Using a Replication Controller
|
||||
content_template: templates/concept
|
||||
weight: 80
|
||||
---
|
||||
-->
|
||||
|
||||
## 概述
|
||||
|
||||
**注**: 创建副本应用的首选方法是使用[Deployment](/docs/api-reference/{{< param "version" >}}/#deployment-v1beta1-apps)，Deployment使用[ReplicaSet](/docs/api-reference/{{< param "version" >}}/#replicaset-v1beta1-extensions)来进行副本控制。
|
||||
更多信息, 查看[使用Deployment运行一个无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
**Note**: The preferred way to create a replicated application is to use a
|
||||
[Deployment](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps),
|
||||
which in turn uses a
|
||||
[ReplicaSet](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicaset-v1-apps).
|
||||
For more information, see
|
||||
[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
为了在更新服务的同时不中断业务， `kubectl` 支持['滚动更新'](/docs/user-guide/kubectl/v1.6/#rolling-update)，它一次更新一个pod，而不是同时停止整个服务。 有关更多信息，请参阅 [滚动更新设计文档](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) 和 [滚动更新示例](/docs/tasks/run-application/rolling-update-replication-controller/)。
|
||||
|
||||
<!--
|
||||
To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) for more information.
|
||||
-->
|
||||
|
||||
请注意， `kubectl rolling-update` 仅支持Replication Controllers。 但是，如果使用Replication Controllers部署应用，请考虑将其切换到[Deployments](/docs/concepts/workloads/controllers/deployment/). Deployment是一种被推荐使用的更高级别的控制器，它可以对应用进行声明性的自动滚动更新。 如果您仍然希望保留您的Replication Controllers并使用 `kubectl rolling-update`进行滚动更新， 请继续往下阅读：
|
||||
|
||||
<!--
|
||||
Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
|
||||
consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
|
||||
of applications declaratively, and therefore is recommended. If you still want to keep your Replication Controllers and use `kubectl rolling-update`, keep reading:
|
||||
-->
|
||||
|
||||
滚动更新可以对replication controller所管理的Pod的配置进行变更，变更可以通过一个新的配置文件来进行，或者，如果只更新镜像，则可以直接指定新的容器镜像。
|
||||
|
||||
<!--
|
||||
A rolling update applies changes to the configuration of pods being managed by
|
||||
a replication controller. The changes can be passed as a new replication
|
||||
controller configuration file; or, if only updating the image, a new container
|
||||
image can be specified directly.
|
||||
-->
|
||||
|
||||
滚动更新的工作流程：
|
||||
|
||||
<!--
|
||||
A rolling update works by:
|
||||
-->
|
||||
|
||||
1. 通过新的配置创建一个replication controller
|
||||
2. 在新的控制器上增加副本数，在旧的上面减少副本数，直到副本数达到期望值
|
||||
3. 删除之前的replication controller
|
||||
|
||||
<!--
|
||||
1. Creating a new replication controller with the updated configuration.
|
||||
2. Increasing/decreasing the replica count on the new and old controllers until
|
||||
the correct number of replicas is reached.
|
||||
3. Deleting the original replication controller.
|
||||
-->
|
||||
|
||||
使用`kubectl rolling-update`命令来进行滚动更新：
|
||||
|
||||
$ kubectl rolling-update NAME \
|
||||
([NEW_NAME] --image=IMAGE | -f FILE)
|
||||
|
||||
<!--
|
||||
Rolling updates are initiated with the `kubectl rolling-update` command:
|
||||
|
||||
$ kubectl rolling-update NAME \
|
||||
([NEW_NAME] --image=IMAGE | -f FILE)
|
||||
-->
|
||||
|
||||
## 通过配置文件更新
|
||||
|
||||
通过配置文件来进行滚动更新，需要在`kubectl rolling-update`命令后面带上新的配置文件：
|
||||
@@ -42,7 +98,27 @@ title: 基于Replication Controller执行滚动升级
|
||||
|
||||
* `metadata.namespace`字段必须相同
|
||||
|
||||
Replication Controllers的配置文件详细介绍见[创建Replication Controllers](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
|
||||
Replication Controllers的配置文件详细介绍见[创建Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
|
||||
|
||||
<!--
|
||||
## Passing a configuration file
|
||||
|
||||
To initiate a rolling update using a configuration file, pass the new file to
|
||||
`kubectl rolling-update`:
|
||||
|
||||
$ kubectl rolling-update NAME -f FILE
|
||||
|
||||
The configuration file must:
|
||||
|
||||
* Specify a different `metadata.name` value.
|
||||
|
||||
* Overwrite at least one common label in its `spec.selector` field.
|
||||
|
||||
* Use the same `metadata.namespace`.
|
||||
|
||||
Replication controller configuration files are described in
|
||||
[Creating Replication Controllers](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
|
||||
-->
|
||||
|
||||
### 示例
|
||||
|
||||
@@ -52,6 +128,16 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll
|
||||
// 将frontend-v2.json数据传到标准输入来更新frontend-v1的pods
|
||||
$ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
|
||||
// Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
|
||||
$ kubectl rolling-update frontend-v1 -f frontend-v2.json
|
||||
|
||||
// Update pods of frontend-v1 using JSON data passed into stdin.
|
||||
$ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
|
||||
-->
|
||||
|
||||
## 更新容器镜像
|
||||
|
||||
仅更新容器镜像的话，可通过如下命令，该命令可以指定一个新的控制器名称（可选），通过`--image`参数来指定新的镜像名称和标签。
|
||||
@@ -65,6 +151,29 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll
|
||||
如果`IMAGE:TAG` 和当前值相同，更新就会失败。 因此，我们建议使用版本号来作为标签，而不是使用 `:latest`。从一个 `image:latest`镜像升级到一个新的 `image:latest` 镜像将会失败，即使这两个镜像不是相同的。
|
||||
所以，我们不建议使用 `:latest` 来作为标签，详细信息见[最佳配置实践](/docs/concepts/configuration/overview/#container-images) 。
|
||||
|
||||
<!--
|
||||
## Updating the container image
|
||||
|
||||
To update only the container image, pass a new image name and tag with the
|
||||
`--image` flag and (optionally) a new controller name:
|
||||
|
||||
$ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
|
||||
|
||||
The `--image` flag is only supported for single-container pods. Specifying
|
||||
`--image` with multi-container pods returns an error.
|
||||
|
||||
If no `NEW_NAME` is specified, a new replication controller is created with
|
||||
a temporary name. Once the rollout is complete, the old controller is deleted,
|
||||
and the new controller is updated to use the original name.
|
||||
|
||||
The update will fail if `IMAGE:TAG` is identical to the
|
||||
current value. For this reason, we recommend the use of versioned tags as
|
||||
opposed to values such as `:latest`. Doing a rolling update from `image:latest`
|
||||
to a new `image:latest` will fail, even if the image at that tag has changed.
|
||||
Moreover, the use of `:latest` is not recommended, see
|
||||
[Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
|
||||
-->
|
||||
|
||||
### 示例
|
||||
|
||||
// 更新frontend-v1的pod到frontend-v2
|
||||
@@ -73,6 +182,16 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll
|
||||
// 更新frontend的pods，不更改replication controller的名称
|
||||
$ kubectl rolling-update frontend --image=image:v2
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
|
||||
// Update the pods of frontend-v1 to frontend-v2
|
||||
$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
|
||||
|
||||
// Update the pods of frontend, keeping the replication controller name
|
||||
$ kubectl rolling-update frontend --image=image:v2
|
||||
-->
|
||||
|
||||
## 必选和可选字段
|
||||
|
||||
必选字段：
|
||||
@@ -99,6 +218,47 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll
|
||||
|
||||
有关`kubectl rolling-update`命令的更多信息见[`kubectl`参考](/docs/user-guide/kubectl/v1.6/#rolling-update).
|
||||
|
||||
<!--
|
||||
## Required and optional fields
|
||||
|
||||
Required fields are:
|
||||
|
||||
* `NAME`: The name of the replication controller to update.
|
||||
|
||||
as well as either:
|
||||
|
||||
* `-f FILE`: A replication controller configuration file, in either JSON or
|
||||
YAML format. The configuration file must specify a new top-level `id` value
|
||||
and include at least one of the existing `spec.selector` key:value pairs.
|
||||
See the
|
||||
[Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/#replication-controller-configuration-file)
|
||||
page for details.
|
||||
<br>
|
||||
<br>
|
||||
or:
|
||||
<br>
|
||||
<br>
|
||||
* `--image IMAGE:TAG`: The name and tag of the image to update to. Must be
|
||||
different than the current image:tag currently specified.
|
||||
|
||||
Optional fields are:
|
||||
|
||||
* `NEW_NAME`: Only used in conjunction with `--image` (not with `-f FILE`). The
|
||||
name to assign to the new replication controller.
|
||||
* `--poll-interval DURATION`: The time between polling the controller status
|
||||
after update. Valid units are `ns` (nanoseconds), `us` or `µs` (microseconds),
|
||||
`ms` (milliseconds), `s` (seconds), `m` (minutes), or `h` (hours). Units can
|
||||
be combined (e.g. `1m30s`). The default is `3s`.
|
||||
* `--timeout DURATION`: The maximum time to wait for the controller to update a
|
||||
pod before exiting. Default is `5m0s`. Valid units are as described for
|
||||
`--poll-interval` above.
|
||||
* `--update-period DURATION`: The time to wait between updating pods. Default
|
||||
is `1m0s`. Valid units are as described for `--poll-interval` above.
|
||||
|
||||
Additional information about the `kubectl rolling-update` command is available
|
||||
from the [`kubectl` reference](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update).
|
||||
-->
|
||||
|
||||
## 实践
|
||||
|
||||
现在你运行了一个1.7.9版本的nginx应用：
|
||||
@@ -214,6 +374,123 @@ Scaling my-nginx-v4 up to 5
|
||||
Update succeeded. Deleting old controller: my-nginx
|
||||
replicationcontroller "my-nginx-v4" rolling updated
|
||||
```
|
||||
<!--
|
||||
## Walkthrough
|
||||
|
||||
Let's say you were running version 1.7.9 of nginx:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 5
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
|
||||
Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
|
||||
```
|
||||
|
||||
In another window, you can see that `kubectl` added a `deployment` label to the pods, whose value is a hash of the configuration, to distinguish the new pods from the old:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l app=nginx -L deployment
|
||||
NAME READY STATUS RESTARTS AGE DEPLOYMENT
|
||||
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z 1/1 Running 0 1m ccba8fbd8cc8160970f63f9a2696fc46
|
||||
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh 1/1 Running 0 35s ccba8fbd8cc8160970f63f9a2696fc46
|
||||
my-nginx-divi2 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
|
||||
my-nginx-o0ef1 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
|
||||
my-nginx-q6all 1/1 Running 0 8m 2d1d7a8f682934a254002b56404b813e
|
||||
```
|
||||
|
||||
`kubectl rolling-update` reports progress as it progresses:
|
||||
|
||||
```
|
||||
Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
|
||||
Scaling my-nginx down to 2
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
|
||||
Scaling my-nginx down to 1
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
|
||||
Scaling my-nginx down to 0
|
||||
Update succeeded. Deleting old controller: my-nginx
|
||||
Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
|
||||
replicationcontroller "my-nginx" rolling updated
|
||||
```
|
||||
|
||||
If you encounter a problem, you can stop the rolling update midway and revert to the previous version using `--rollback`:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx --rollback
|
||||
Setting "my-nginx" replicas to 1
|
||||
Continuing update with existing controller my-nginx.
|
||||
Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
|
||||
Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
|
||||
replicationcontroller "my-nginx" rolling updated
|
||||
```
|
||||
|
||||
This is one example where the immutability of containers is a huge asset.
|
||||
|
||||
If you need to update more than just the image (e.g., command arguments, environment variables), you can create a new replication controller, with a new name and distinguishing label value, such as:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: my-nginx-v4
|
||||
spec:
|
||||
replicas: 5
|
||||
selector:
|
||||
app: nginx
|
||||
deployment: v4
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
deployment: v4
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.9.2
|
||||
args: ["nginx", "-T"]
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
and roll it out:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
|
||||
Created my-nginx-v4
|
||||
Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
|
||||
Scaling my-nginx-v4 up to 1
|
||||
Scaling my-nginx down to 3
|
||||
Scaling my-nginx-v4 up to 2
|
||||
Scaling my-nginx down to 2
|
||||
Scaling my-nginx-v4 up to 3
|
||||
Scaling my-nginx down to 1
|
||||
Scaling my-nginx-v4 up to 4
|
||||
Scaling my-nginx down to 0
|
||||
Scaling my-nginx-v4 up to 5
|
||||
Update succeeded. Deleting old controller: my-nginx
|
||||
replicationcontroller "my-nginx-v4" rolling updated
|
||||
```
|
||||
-->
|
||||
|
||||
## 故障分析
|
||||
|
||||
@@ -222,3 +499,16 @@ replicationcontroller "my-nginx-v4" rolling updated
|
||||
如果更新失败，可以尝试使用同样的命令来继续更新过程。
|
||||
|
||||
在尝试更新之前如果需要回滚到之前的状态，可在之前的命令后面添加`--rollback=true`参数，这将回退所有的更改。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
If the `timeout` duration is reached during a rolling update, the operation will
|
||||
fail with some pods belonging to the new replication controller, and some to the
|
||||
original controller.
|
||||
|
||||
To continue the update from where it failed, retry using the same command.
|
||||
|
||||
To roll back to the original state before the attempted update, append the
|
||||
`--rollback=true` flag to the original command. This will revert all changes.
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,656 @@
|
||||
---
|
||||
title: 运行一个有状态的应用程序
|
||||
content_template: templates/tutorial
|
||||
weight: 30
|
||||
---
|
||||
<!-- ---
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
- smarterclayton
|
||||
title: Run a Replicated Stateful Application
|
||||
content_template: templates/tutorial
|
||||
weight: 30
|
||||
--- -->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- This page shows how to run a replicated stateful application using a
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller.
|
||||
The example is a MySQL single-master topology with multiple slaves running
|
||||
asynchronous replication. -->
|
||||
该页面显示如何使用[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) 控制器去运行一个有状态的应用程序。此例是一主多从的 MySQL 集群。
|
||||
|
||||
<!-- Note that **this is not a production configuration**.
|
||||
In particular, MySQL settings remain on insecure defaults to keep the focus
|
||||
on general patterns for running stateful applications in Kubernetes. -->
|
||||
请注意 **这不是生产配置**。
|
||||
重点是， MySQL 设置保留在不安全的默认值上，使重点放在 Kubernetes 中运行有状态应用程序的常规模式。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!-- * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
* This tutorial assumes you are familiar with
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
|
||||
[Services](/docs/concepts/services-networking/service/), and
|
||||
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
* Some familiarity with MySQL helps, but this tutorial aims to present
|
||||
general patterns that should be useful for other systems. -->
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
* 本教程假定您熟悉
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
与 [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
以及其他核心概念，例如[Pods](/docs/concepts/workloads/pods/pod/),
|
||||
[Services](/docs/concepts/services-networking/service/), 与
|
||||
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
* 熟悉 MySQL 会有所帮助，但是本教程旨在介绍对其他系统应该有用的常规模式。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
<!-- * Deploy a replicated MySQL topology with a StatefulSet controller.
|
||||
* Send MySQL client traffic.
|
||||
* Observe resistance to downtime.
|
||||
* Scale the StatefulSet up and down. -->
|
||||
* 使用 StatefulSet 控制器部署复制的 MySQL 拓扑。
|
||||
* 发送 MySQL 客户端流量。
|
||||
* 观察对宕机的抵抗力。
|
||||
* 缩放 StatefulSet 的大小。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
<!-- ## Deploy MySQL -->
|
||||
## 部署 MySQL
|
||||
|
||||
<!-- The example MySQL deployment consists of a ConfigMap, two Services,
|
||||
and a StatefulSet. -->
|
||||
部署 MySQL 示例，包含一个 ConfigMap，两个 Services，与一个 StatefulSet。
|
||||
|
||||
### ConfigMap
|
||||
|
||||
<!-- Create the ConfigMap from the following YAML configuration file: -->
|
||||
从以下的 YAML 配置文件创建 ConfigMap ：
|
||||
|
||||
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
|
||||
```
|
||||
|
||||
<!-- This ConfigMap provides `my.cnf` overrides that let you independently control
|
||||
configuration on the MySQL master and slaves.
|
||||
In this case, you want the master to be able to serve replication logs to slaves
|
||||
and you want slaves to reject any writes that don't come via replication. -->
|
||||
这个 ConfigMap 提供 `my.cnf` 覆盖，使您可以独立控制 MySQL 主服务器和从服务器的配置。
|
||||
在这种情况下，您希望主服务器能够将复制日志提供给从服务器，并且希望从服务器拒绝任何不是通过复制进行的写操作。
|
||||
|
||||
<!-- There's nothing special about the ConfigMap itself that causes different
|
||||
portions to apply to different Pods.
|
||||
Each Pod decides which portion to look at as it's initializing,
|
||||
based on information provided by the StatefulSet controller. -->
|
||||
ConfigMap 本身没有什么特别之处，它可以使不同部分应用于不同的 Pod。
|
||||
每个 Pod 都会决定在初始化时要看基于 StatefulSet 控制器提供的信息。
|
||||
|
||||
<!-- ### Services -->
|
||||
### Services
|
||||
|
||||
<!-- Create the Services from the following YAML configuration file: -->
|
||||
从以下 YAML 配置文件创建服务：
|
||||
|
||||
{{< codenew file="application/mysql/mysql-services.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
||||
```
|
||||
|
||||
<!-- The Headless Service provides a home for the DNS entries that the StatefulSet
|
||||
controller creates for each Pod that's part of the set.
|
||||
Because the Headless Service is named `mysql`, the Pods are accessible by
|
||||
resolving `<pod-name>.mysql` from within any other Pod in the same Kubernetes
|
||||
cluster and namespace. -->
|
||||
Headless Service 给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。因为 Headless Service 名为 `mysql`，所以可以通过在同一 Kubernetes 集群和 namespace 中的任何其他 Pod 内解析 `<pod-name>.mysql` 来访问 Pod。
|
||||
|
||||
<!-- The Client Service, called `mysql-read`, is a normal Service with its own
|
||||
cluster IP that distributes connections across all MySQL Pods that report
|
||||
being Ready. The set of potential endpoints includes the MySQL master and all
|
||||
slaves. -->
|
||||
客户端 Service 称为 `mysql-read`，是一种常规 Service，具有其自己的群集 IP，该群集 IP 在报告为就绪的所有MySQL Pod 中分配连接。可能端点的集合包括 MySQL 主节点和所有从节点。
|
||||
|
||||
<!-- Note that only read queries can use the load-balanced Client Service.
|
||||
Because there is only one MySQL master, clients should connect directly to the
|
||||
MySQL master Pod (through its DNS entry within the Headless Service) to execute
|
||||
writes. -->
|
||||
请注意，只有读取查询才能使用负载平衡的客户端 Service。因为只有一个 MySQL 主服务器，所以客户端应直接连接到 MySQL 主服务器 Pod (通过其在 Headless Service 中的 DNS 条目)以执行写入操作。
|
||||
|
||||
### StatefulSet
|
||||
|
||||
<!-- Finally, create the StatefulSet from the following YAML configuration file: -->
|
||||
最后，从以下 YAML 配置文件创建 StatefulSet：
|
||||
|
||||
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
|
||||
```
|
||||
|
||||
<!-- You can watch the startup progress by running: -->
|
||||
您可以通过运行以下命令查看启动进度：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql --watch
|
||||
```
|
||||
|
||||
<!-- After a while, you should see all 3 Pods become Running: -->
|
||||
一段时间后，您应该看到所有3个 Pod 都开始运行：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-0 2/2 Running 0 2m
|
||||
mysql-1 2/2 Running 0 1m
|
||||
mysql-2 2/2 Running 0 1m
|
||||
```
|
||||
|
||||
<!-- Press **Ctrl+C** to cancel the watch.
|
||||
If you don't see any progress, make sure you have a dynamic PersistentVolume
|
||||
provisioner enabled as mentioned in the [prerequisites](#before-you-begin). -->
|
||||
输入**Ctrl+C**取消观察。
|
||||
如果您看不到任何进度，确保已启用[前提条件](#before-you-begin)中提到的动态 PersistentVolume 预配器。
|
||||
|
||||
|
||||
<!-- This manifest uses a variety of techniques for managing stateful Pods as part of
|
||||
a StatefulSet. The next section highlights some of these techniques to explain
|
||||
what happens as the StatefulSet creates Pods. -->
|
||||
该清单使用多种技术来管理作为 StatefulSet 一部分的有状态 Pod。下一节重点介绍其中一些技巧，以解释 StatefulSet 创建 Pod 时发生的状况。
|
||||
|
||||
<!-- ## Understanding stateful Pod initialization -->
|
||||
## 了解有状态的 Pod 初始化
|
||||
|
||||
<!-- The StatefulSet controller starts Pods one at a time, in order by their
|
||||
ordinal index.
|
||||
It waits until each Pod reports being Ready before starting the next one. -->
|
||||
StatefulSet 控制器一次按顺序启动 Pod 序数索引。它一直等到每个 Pod 报告就绪为止，然后再开始下一个 Pod。
|
||||
|
||||
<!-- In addition, the controller assigns each Pod a unique, stable name of the form
|
||||
`<statefulset-name>-<ordinal-index>`, which results in Pods named `mysql-0`,
|
||||
`mysql-1`, and `mysql-2`. -->
|
||||
此外，控制器为每个 Pod 分配一个唯一，稳定的表单名称 `<statefulset-name>-<ordinal-index>` 其结果是 Pods 名为 mysql-0，mysql-1 和 mysql-2。
|
||||
|
||||
<!-- The Pod template in the above StatefulSet manifest takes advantage of these
|
||||
properties to perform orderly startup of MySQL replication. -->
|
||||
上述 StatefulSet 清单中的 Pod 模板利用这些属性来执行 MySQL 复制的有序启动。
|
||||
|
||||
<!-- ### Generating configuration -->
|
||||
### 生成配置
|
||||
|
||||
<!-- Before starting any of the containers in the Pod spec, the Pod first runs any
|
||||
[Init Containers](/docs/concepts/workloads/pods/init-containers/)
|
||||
in the order defined. -->
|
||||
在启动 Pod 规范中的任何容器之前， Pod 首先运行任何[初始容器](/docs/concepts/workloads/pods/init-containers/)按照定义的顺序。
|
||||
|
||||
<!-- The first Init Container, named `init-mysql`, generates special MySQL config
|
||||
files based on the ordinal index. -->
|
||||
第一个名为 `init-mysql` 的初始化容器，根据序号索引生成特殊的 MySQL 配置文件。
|
||||
|
||||
<!-- The script determines its own ordinal index by extracting it from the end of
|
||||
the Pod name, which is returned by the `hostname` command.
|
||||
Then it saves the ordinal (with a numeric offset to avoid reserved values)
|
||||
into a file called `server-id.cnf` in the MySQL `conf.d` directory.
|
||||
This translates the unique, stable identity provided by the StatefulSet
|
||||
controller into the domain of MySQL server IDs, which require the same
|
||||
properties. -->
|
||||
该脚本通过从 Pod 名称的末尾提取索引来确定自己的序号索引，该名称由 `hostname` 命令返回。
|
||||
然后将序数(带有数字偏移量以避免保留值)保存到 MySQL conf.d 目录中的文件 server-id.cnf 中。
|
||||
这将转换 StatefulSet 提供的唯一，稳定的身份控制器进入需要相同属性的 MySQL 服务器 ID 的范围。
|
||||
|
||||
<!-- The script in the `init-mysql` container also applies either `master.cnf` or
|
||||
`slave.cnf` from the ConfigMap by copying the contents into `conf.d`.
|
||||
Because the example topology consists of a single MySQL master and any number of
|
||||
slaves, the script simply assigns ordinal `0` to be the master, and everyone
|
||||
else to be slaves. -->
|
||||
通过将内容复制到 conf.d 中，init-mysql 容器中的脚本也可以应用 ConfigMap 中的 master.cnf 或 slave.cnf。由于示例拓扑由单个 MySQL 主节点和任意数量的从节点组成，因此脚本仅将序数 `0` 指定为主节点，而将其他所有人指定为从节点。与 StatefulSet 控制器的[部署顺序保证](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/),这样可以确保 MySQL 主服务器在创建从服务器之前已准备就绪，以便它们可以开始复制。
|
||||
|
||||
<!-- ### Cloning existing data -->
|
||||
### 克隆现有数据
|
||||
|
||||
<!-- In general, when a new Pod joins the set as a slave, it must assume the MySQL
|
||||
master might already have data on it. It also must assume that the replication
|
||||
logs might not go all the way back to the beginning of time. -->
|
||||
通常，当新的 Pod 作为从节点加入集合时，必须假定 MySQL 主节点可能已经有数据。还必须假设复制日志可能不会一直追溯到时间的开始。
|
||||
<!-- These conservative assumptions are the key to allow a running StatefulSet
|
||||
to scale up and down over time, rather than being fixed at its initial size. -->
|
||||
这些保守假设的关键是允许正在运行的 StatefulSet 随时间扩大和缩小而不是固定在其初始大小。
|
||||
|
||||
<!-- The second Init Container, named `clone-mysql`, performs a clone operation on
|
||||
a slave Pod the first time it starts up on an empty PersistentVolume.
|
||||
That means it copies all existing data from another running Pod,
|
||||
so its local state is consistent enough to begin replicating from the master. -->
|
||||
第二个名为 `clone-mysql` 的初始化容器，第一次在从属 Pod 上以空 PersistentVolume 启动时，会对从属 Pod 执行克隆操作。这意味着它将从另一个运行的 Pod 复制所有现有数据，因此其本地状态足够一致，可以开始主从服务器复制。
|
||||
|
||||
<!-- MySQL itself does not provide a mechanism to do this, so the example uses a
|
||||
popular open-source tool called Percona XtraBackup.
|
||||
During the clone, the source MySQL server might suffer reduced performance.
|
||||
To minimize impact on the MySQL master, the script instructs each Pod to clone
|
||||
from the Pod whose ordinal index is one lower.
|
||||
This works because the StatefulSet controller always ensures Pod `N` is
|
||||
Ready before starting Pod `N+1`. -->
|
||||
MySQL 本身不提供执行此操作的机制，因此该示例使用了一种流行的开源工具 Percona XtraBackup。
|
||||
在克隆期间，源 MySQL 服务器可能会降低性能。
|
||||
为了最大程度地减少对 MySQL 主机的影响，该脚本指示每个 Pod 从序号较低的 Pod 中克隆。
|
||||
可以这样做的原因是 StatefulSet 控制器始终确保在启动 Pod N + 1 之前 Pod N 已准备就绪。
|
||||
|
||||
<!-- ### Starting replication -->
|
||||
### 开始复制
|
||||
|
||||
<!-- After the Init Containers complete successfully, the regular containers run.
|
||||
The MySQL Pods consist of a `mysql` container that runs the actual `mysqld`
|
||||
server, and an `xtrabackup` container that acts as a
|
||||
[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). -->
|
||||
初始化容器成功完成后，常规容器将运行。
|
||||
MySQL Pods 由运行实际 `mysqld` 服务器的 `mysql` 容器和充当[辅助工具](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)的 xtrabackup 容器组成。
|
||||
|
||||
<!-- The `xtrabackup` sidecar looks at the cloned data files and determines if
|
||||
it's necessary to initialize MySQL replication on the slave.
|
||||
If so, it waits for `mysqld` to be ready and then executes the
|
||||
`CHANGE MASTER TO` and `START SLAVE` commands with replication parameters
|
||||
extracted from the XtraBackup clone files. -->
|
||||
`xtrabackup` 辅助工具查看克隆的数据文件，并确定是否有必要在从属服务器上初始化 MySQL 复制。
|
||||
如果是这样，它将等待 `mysqld` 准备就绪，然后执行带有从 XtraBackup 克隆文件中提取的复制参数 `CHANGE MASTER TO` 和 `START SLAVE` 命令。
|
||||
|
||||
<!-- Once a slave begins replication, it remembers its MySQL master and
|
||||
reconnects automatically if the server restarts or the connection dies.
|
||||
Also, because slaves look for the master at its stable DNS name
|
||||
(`mysql-0.mysql`), they automatically find the master even if it gets a new
|
||||
Pod IP due to being rescheduled. -->
|
||||
一旦从服务器开始复制后，它会记住其 MySQL 主服务器。并且如果服务器重新启动或连接中断，则会自动重新连接。
|
||||
另外，因为从服务器会以其稳定的 DNS 名称查找主服务器(`mysql-0.mysql`)，即使由于重新安排而获得新的 Pod IP，他们也会自动找到主服务器。
|
||||
|
||||
<!-- Lastly, after starting replication, the `xtrabackup` container listens for
|
||||
connections from other Pods requesting a data clone.
|
||||
This server remains up indefinitely in case the StatefulSet scales up, or in
|
||||
case the next Pod loses its PersistentVolumeClaim and needs to redo the clone. -->
|
||||
最后，开始复制后，`xtrabackup` 容器监听来自其他 Pod 的连接数据克隆请求。
|
||||
如果 StatefulSet 扩大规模，或者下一个 Pod 失去其 PersistentVolumeClaim 并需要重新克隆，则此服务器将无限期保持运行。
|
||||
|
||||
<!-- ## Sending client traffic -->
|
||||
## 发送客户端流量
|
||||
|
||||
<!-- You can send test queries to the MySQL master (hostname `mysql-0.mysql`)
|
||||
by running a temporary container with the `mysql:5.7` image and running the
|
||||
`mysql` client binary. -->
|
||||
您可以通过运行带有 `mysql:5.7` 镜像的临时容器并运行 `mysql` 客户端二进制文件，将测试查询发送到 MySQL 主服务器(主机名 `mysql-0.mysql` )。
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
|
||||
mysql -h mysql-0.mysql <<EOF
|
||||
CREATE DATABASE test;
|
||||
CREATE TABLE test.messages (message VARCHAR(250));
|
||||
INSERT INTO test.messages VALUES ('hello');
|
||||
EOF
|
||||
```
|
||||
|
||||
<!-- Use the hostname `mysql-read` to send test queries to any server that reports
|
||||
being Ready: -->
|
||||
使用主机名 `mysql-read` 将测试查询发送到任何报告为就绪的服务器：
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
mysql -h mysql-read -e "SELECT * FROM test.messages"
|
||||
```
|
||||
|
||||
<!-- You should get output like this: -->
|
||||
您应该获得如下输出：
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
|
||||
+---------+
|
||||
| message |
|
||||
+---------+
|
||||
| hello |
|
||||
+---------+
|
||||
pod "mysql-client" deleted
|
||||
```
|
||||
|
||||
<!-- To demonstrate that the `mysql-read` Service distributes connections across
|
||||
servers, you can run `SELECT @@server_id` in a loop: -->
|
||||
为了演示 `mysql-read` 服务在服务器之间分配连接，您可以在循环中运行 `SELECT @@server_id`：
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"
|
||||
```
|
||||
|
||||
<!-- You should see the reported `@@server_id` change randomly, because a different
|
||||
endpoint might be selected upon each connection attempt: -->
|
||||
您应该看到报告的 `@@server_id` 发生随机变化，因为每次尝试连接时都可能选择了不同的端点：
|
||||
|
||||
```
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 100 | 2006-01-02 15:04:05 |
|
||||
+-------------+---------------------+
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 102 | 2006-01-02 15:04:06 |
|
||||
+-------------+---------------------+
|
||||
+-------------+---------------------+
|
||||
| @@server_id | NOW() |
|
||||
+-------------+---------------------+
|
||||
| 101 | 2006-01-02 15:04:07 |
|
||||
+-------------+---------------------+
|
||||
```
|
||||
|
||||
<!-- You can press **Ctrl+C** when you want to stop the loop, but it's useful to keep
|
||||
it running in another window so you can see the effects of the following steps. -->
|
||||
要停止循环时可以按 **Ctrl+C** ，但是让它在另一个窗口中运行非常有用，这样您就可以看到以下步骤的效果。
|
||||
|
||||
<!-- ## Simulating Pod and Node downtime -->
|
||||
## 模拟 Pod 和 Node 的宕机时间
|
||||
|
||||
<!-- To demonstrate the increased availability of reading from the pool of slaves
|
||||
instead of a single server, keep the `SELECT @@server_id` loop from above
|
||||
running while you force a Pod out of the Ready state. -->
|
||||
为了证明从从节点缓存而不是单个服务器读取数据的可用性提高，请在使 Pod 退出 Ready 状态时，保持 `SELECT @@server_id` 循环从上面运行。
|
||||
|
||||
<!-- ### Break the Readiness Probe -->
|
||||
### 退出 Readiness Probe
|
||||
|
||||
<!-- The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
|
||||
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
|
||||
to make sure the server is up and able to execute queries. -->
|
||||
`mysql` 容器的[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)运行命令 `mysql -h 127.0.0.1 -e 'SELECT 1'`，以确保服务器已启动并能够执行查询。
|
||||
|
||||
<!-- One way to force this readiness probe to fail is to break that command: -->
|
||||
迫使 readiness probe 失败的一种方法就是执行该命令：
|
||||
|
||||
```shell
|
||||
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off
|
||||
```
|
||||
|
||||
<!-- This reaches into the actual container's filesystem for Pod `mysql-2` and
|
||||
renames the `mysql` command so the readiness probe can't find it.
|
||||
After a few seconds, the Pod should report one of its containers as not Ready,
|
||||
which you can check by running: -->
|
||||
这进入 Pod `mysql-2` 的实际容器文件系统，并重命名 `mysql` 命令，以便 readiness probe 无法找到它。
|
||||
几秒钟后， Pod 会将其中一个容器报告为未就绪，您可以通过运行以下命令进行检查：
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2
|
||||
```
|
||||
|
||||
<!-- Look for `1/2` in the `READY` column: -->
|
||||
在 `就绪` 列中查找 ` 1/2` ：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-2 1/2 Running 0 3m
|
||||
```
|
||||
|
||||
<!-- At this point, you should see your `SELECT @@server_id` loop continue to run,
|
||||
although it never reports `102` anymore.
|
||||
Recall that the `init-mysql` script defined `server-id` as `100 + $ordinal`,
|
||||
so server ID `102` corresponds to Pod `mysql-2`. -->
|
||||
此时，您应该会看到 `SELECT @@server_id` 循环继续运行，尽管它不再报告 `102` 。
|
||||
回想一下，`init-mysql` 脚本将 `server-id` 定义为 `100 + $ordinal` ，因此服务器 ID `102` 对应于 Pod `mysql-2`。
|
||||
|
||||
<!-- Now repair the Pod and it should reappear in the loop output
|
||||
after a few seconds: -->
|
||||
现在修复 Pod，几秒钟后它应该重新出现在循环输出中：
|
||||
|
||||
```shell
|
||||
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql
|
||||
```
|
||||
|
||||
<!-- ### Delete Pods -->
|
||||
### 删除 Pods
|
||||
|
||||
<!-- The StatefulSet also recreates Pods if they're deleted, similar to what a
|
||||
ReplicaSet does for stateless Pods. -->
|
||||
如果删除了 Pod，则 StatefulSet 还会重新创建 Pod，类似于 ReplicaSet 对无状态 Pod 所做的操作。
|
||||
|
||||
```shell
|
||||
kubectl delete pod mysql-2
|
||||
```
|
||||
|
||||
<!-- The StatefulSet controller notices that no `mysql-2` Pod exists anymore,
|
||||
and creates a new one with the same name and linked to the same
|
||||
PersistentVolumeClaim.
|
||||
You should see server ID `102` disappear from the loop output for a while
|
||||
and then return on its own. -->
|
||||
StatefulSet 控制器注意到不再存在 `mysql-2` Pod，并创建了一个具有相同名称并链接到相同 PersistentVolumeClaim 的新 Pod。
|
||||
您应该看到服务器 ID `102` 从循环输出中消失了一段时间，然后自行返回。
|
||||
|
||||
<!-- ### Drain a Node -->
|
||||
### 排除 Node
|
||||
|
||||
<!-- If your Kubernetes cluster has multiple Nodes, you can simulate Node downtime
|
||||
(such as when Nodes are upgraded) by issuing a
|
||||
[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain). -->
|
||||
如果您的 Kubernetes 集群具有多个节点，则可以通过发出以下命令[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)来模拟节点停机时间(例如升级节点时)。
|
||||
|
||||
<!-- First determine which Node one of the MySQL Pods is on: -->
|
||||
首先确定 MySQL Pods 之一在哪个节点上：
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2 -o wide
|
||||
```
|
||||
|
||||
<!-- The Node name should show up in the last column: -->
|
||||
节点名称应显示在最后一列中：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-node-9l2t
|
||||
```
|
||||
|
||||
<!-- Then drain the Node by running the following command, which cordons it so
|
||||
no new Pods may schedule there, and then evicts any existing Pods.
|
||||
Replace `<node-name>` with the name of the Node you found in the last step. -->
|
||||
然后通过运行以下命令耗尽节点，该命令将其封锁，以使新的 Pod 不能在那里调度，然后驱逐任何现有的 Pod。
|
||||
将 `<node-name>` 替换为在上一步中找到的 Node 的名称。
|
||||
|
||||
|
||||
<!-- This might impact other applications on the Node, so it's best to
|
||||
**only do this in a test cluster**. -->
|
||||
这可能会影响节点上的其他应用程序，因此最好
|
||||
**仅在测试集群中执行此操作**。
|
||||
|
||||
```shell
|
||||
kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
|
||||
```
|
||||
|
||||
<!-- Now you can watch as the Pod reschedules on a different Node: -->
|
||||
现在，您可以观察 Pod 在其他节点上的重新安排：
|
||||
|
||||
```shell
|
||||
kubectl get pod mysql-2 -o wide --watch
|
||||
```
|
||||
|
||||
<!-- It should look something like this: -->
|
||||
它看起来应该像这样：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
mysql-2 2/2 Terminating 0 15m 10.244.1.56 kubernetes-node-9l2t
|
||||
[...]
|
||||
mysql-2 0/2 Pending 0 0s <none> kubernetes-node-fjlm
|
||||
mysql-2 0/2 Init:0/2 0 0s <none> kubernetes-node-fjlm
|
||||
mysql-2 0/2 Init:1/2 0 20s 10.244.5.32 kubernetes-node-fjlm
|
||||
mysql-2 0/2 PodInitializing 0 21s 10.244.5.32 kubernetes-node-fjlm
|
||||
mysql-2 1/2 Running 0 22s 10.244.5.32 kubernetes-node-fjlm
|
||||
mysql-2 2/2 Running 0 30s 10.244.5.32 kubernetes-node-fjlm
|
||||
```
|
||||
|
||||
<!-- And again, you should see server ID `102` disappear from the
|
||||
`SELECT @@server_id` loop output for a while and then return. -->
|
||||
再次，您应该看到服务器 ID `102` 从 `SELECT @@server_id` 循环输出一段时间，然后返回。
|
||||
|
||||
<!-- Now uncordon the Node to return it to a normal state: -->
|
||||
现在 uncordon 节点,使其恢复为正常模式:
|
||||
|
||||
```shell
|
||||
kubectl uncordon <node-name>
|
||||
```
|
||||
|
||||
<!-- ## Scaling the number of slaves -->
|
||||
## 扩展从节点数量
|
||||
|
||||
<!-- With MySQL replication, you can scale your read query capacity by adding slaves.
|
||||
With StatefulSet, you can do this with a single command: -->
|
||||
使用 MySQL 复制，您可以通过添加从节点来扩展读取查询的能力。
|
||||
使用 StatefulSet，您可以使用单个命令执行此操作：
|
||||
|
||||
```shell
|
||||
kubectl scale statefulset mysql --replicas=5
|
||||
```
|
||||
|
||||
<!-- Watch the new Pods come up by running: -->
|
||||
查看新的 Pod 的运行情况：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql --watch
|
||||
```
|
||||
|
||||
<!-- Once they're up, you should see server IDs `103` and `104` start appearing in
|
||||
the `SELECT @@server_id` loop output.
|
||||
|
||||
You can also verify that these new servers have the data you added before they
|
||||
existed: -->
|
||||
一旦 Pod 启动，您应该看到服务器 IDs `103` 和 `104` 开始出现在 `SELECT @@server_id` 循环输出中。
|
||||
|
||||
您还可以验证这些新服务器在存在之前已添加了数据：
|
||||
|
||||
```shell
|
||||
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
|
||||
mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
|
||||
```
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
|
||||
+---------+
|
||||
| message |
|
||||
+---------+
|
||||
| hello |
|
||||
+---------+
|
||||
pod "mysql-client" deleted
|
||||
```
|
||||
|
||||
<!-- Scaling back down is also seamless: -->
|
||||
向下缩放也是不停顿的：
|
||||
|
||||
```shell
|
||||
kubectl scale statefulset mysql --replicas=3
|
||||
```
|
||||
|
||||
<!-- Note, however, that while scaling up creates new PersistentVolumeClaims
|
||||
automatically, scaling down does not automatically delete these PVCs.
|
||||
This gives you the choice to keep those initialized PVCs around to make
|
||||
scaling back up quicker, or to extract data before deleting them. -->
|
||||
但是请注意，按比例放大会自动创建新的 PersistentVolumeClaims，而按比例缩小不会自动删除这些 PVC。
|
||||
这使您可以选择保留那些初始化的 PVC，以更快地进行缩放，或者在删除它们之前提取数据。
|
||||
|
||||
<!-- You can see this by running: -->
|
||||
您可以通过运行以下命令查看此信息：
|
||||
|
||||
```shell
|
||||
kubectl get pvc -l app=mysql
|
||||
```
|
||||
|
||||
<!-- Which shows that all 5 PVCs still exist, despite having scaled the
|
||||
StatefulSet down to 3: -->
|
||||
这表明，尽管将 StatefulSet 缩小为3，所有5个 PVC 仍然存在：
|
||||
|
||||
```
|
||||
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
|
||||
data-mysql-0 Bound pvc-8acbf5dc-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-1 Bound pvc-8ad39820-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-2 Bound pvc-8ad69a6d-b103-11e6-93fa-42010a800002 10Gi RWO 20m
|
||||
data-mysql-3 Bound pvc-50043c45-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
|
||||
data-mysql-4 Bound pvc-500a9957-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
|
||||
```
|
||||
|
||||
<!-- If you don't intend to reuse the extra PVCs, you can delete them: -->
|
||||
如果您不打算重复使用多余的 PVC，则可以删除它们：
|
||||
|
||||
```shell
|
||||
kubectl delete pvc data-mysql-3
|
||||
kubectl delete pvc data-mysql-4
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture cleanup %}}
|
||||
|
||||
<!-- 1. Cancel the `SELECT @@server_id` loop by pressing **Ctrl+C** in its terminal,
|
||||
or running the following from another terminal: -->
|
||||
1. 通过在终端上按 **Ctrl+C** 取消 `SELECT @@server_id` 循环，或从另一个终端运行以下命令：
|
||||
|
||||
```shell
|
||||
kubectl delete pod mysql-client-loop --now
|
||||
```
|
||||
|
||||
<!-- 1. Delete the StatefulSet. This also begins terminating the Pods. -->
|
||||
1. 删除 StatefulSet。这也开始终止 Pod。
|
||||
|
||||
```shell
|
||||
kubectl delete statefulset mysql
|
||||
```
|
||||
|
||||
<!-- 1. Verify that the Pods disappear.
|
||||
They might take some time to finish terminating. -->
|
||||
1. 验证 Pod 消失。
|
||||
他们可能需要一些时间才能完成终止。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=mysql
|
||||
```
|
||||
|
||||
<!-- You'll know the Pods have terminated when the above returns: -->
|
||||
当以上内容返回时，您将知道 Pod 已终止：
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
<!-- 1. Delete the ConfigMap, Services, and PersistentVolumeClaims. -->
|
||||
1. 删除 ConfigMap，Services 和 PersistentVolumeClaims。
|
||||
|
||||
```shell
|
||||
kubectl delete configmap,service,pvc -l app=mysql
|
||||
```
|
||||
|
||||
<!-- 1. If you manually provisioned PersistentVolumes, you also need to manually
|
||||
delete them, as well as release the underlying resources.
|
||||
If you used a dynamic provisioner, it automatically deletes the
|
||||
PersistentVolumes when it sees that you deleted the PersistentVolumeClaims.
|
||||
Some dynamic provisioners (such as those for EBS and PD) also release the
|
||||
underlying resources upon deleting the PersistentVolumes. -->
|
||||
1. 如果您手动设置 PersistentVolume，则还需要手动删除它们，并释放基础资源。
|
||||
如果您使用了动态预配器，当得知您删除 PersistentVolumeClaims 时，它将自动删除 PersistentVolumes。
|
||||
一些动态预配器(例如用于 EBS 和 PD 的预配器)也会在删除 PersistentVolumes 时释放基础资源。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!-- * Look in the [Helm Charts repository](https://github.com/kubernetes/charts)
|
||||
for other stateful application examples. -->
|
||||
* 在[Helm Charts 存储库](https://github.com/kubernetes/charts)中查找其他有状态的应用程序示例。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ content_template: templates/tutorial
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文介绍在Kubernetes中使用PersistentVolume和Deployment如何运行一个单实例有状态应用. 该应用是MySQL.
|
||||
本文介绍在 Kubernetes 中使用 PersistentVolume 和 Deployment 如何运行一个单实例有状态应用. 该应用是 MySQL.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -31,12 +31,7 @@ content_template: templates/tutorial
|
||||
|
||||
## 部署MySQL
|
||||
|
||||
通过创建Kubernetes Deployment并使用PersistentVolumeClaim将其连接到现已存在的PersistentVolume上来运行一个有状态的应用. 例如, 下面这个YAML文件描述了一个运行MySQL
|
||||
并引用PersistentVolumeClaim的Deployment. 该文件定义了一个volume其挂载目录为/var/lib/mysql, 然后创建一个内存为20G的卷的PersistentVolumeClaim. 此申领可以通过任
|
||||
何符合需求的卷来满足, 在本例中满足上面创建的卷.
|
||||
|
||||
|
||||
注意: 在配置的yaml文件中定义密码的做法是不安全的. 具体安全解决方案请参考
|
||||
注意: 在配置的 yaml 文件中定义密码的做法是不安全的. 具体安全解决方案请参考
|
||||
[Kubernetes Secrets](/docs/concepts/configuration/secret/).
|
||||
|
||||
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
|
||||
@@ -50,9 +45,9 @@ content_template: templates/tutorial
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
|
||||
|
||||
1. 展示Deployment相关信息:
|
||||
1. 展示 Deployment 相关信息:
|
||||
|
||||
kubectl describe deployment mysql
|
||||
kubectl describe deployment mysql
|
||||
|
||||
Name: mysql
|
||||
Namespace: default
|
||||
@@ -78,77 +73,57 @@ content_template: templates/tutorial
|
||||
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
|
||||
ClaimName: mysql-pv-claim
|
||||
ReadOnly: false
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available False MinimumReplicasUnavailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: mysql-63082529 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available False MinimumReplicasUnavailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: mysql-63082529 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
|
||||
|
||||
|
||||
1. 列举出Deployment创建的pods:
|
||||
1. 列举出 Deployment 创建的 pods:
|
||||
|
||||
kubectl get pods -l app=mysql
|
||||
kubectl get pods -l app=mysql
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-63082529-2z3ki 1/1 Running 0 3m
|
||||
|
||||
1. 查看 PersistentVolumeClaim:
|
||||
|
||||
1. 查看持久卷:
|
||||
|
||||
kubectl describe pv mysql-pv
|
||||
|
||||
Name: mysql-pv
|
||||
Labels: <none>
|
||||
Status: Bound
|
||||
Claim: default/mysql-pv-claim
|
||||
Reclaim Policy: Retain
|
||||
Access Modes: RWO
|
||||
Capacity: 20Gi
|
||||
Message:
|
||||
Source:
|
||||
Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
|
||||
PDName: mysql-disk
|
||||
FSType: ext4
|
||||
Partition: 0
|
||||
ReadOnly: false
|
||||
No events.
|
||||
|
||||
|
||||
1. 查看PersistentVolumeClaim:
|
||||
|
||||
kubectl describe pvc mysql-pv-claim
|
||||
kubectl describe pvc mysql-pv-claim
|
||||
|
||||
Name: mysql-pv-claim
|
||||
Namespace: default
|
||||
StorageClass:
|
||||
Status: Bound
|
||||
Volume: mysql-pv
|
||||
Volume: mysql-pv-volume
|
||||
Labels: <none>
|
||||
Annotations: pv.kubernetes.io/bind-completed=yes
|
||||
pv.kubernetes.io/bound-by-controller=yes
|
||||
Capacity: 20Gi
|
||||
Access Modes: RWO
|
||||
No events.
|
||||
Events: <none>
|
||||
|
||||
## 访问 MySQL 实例
|
||||
|
||||
|
||||
## 访问MySQL实例
|
||||
前面 YAML 文件中创建了一个允许集群内其他 pods 访问数据库的服务. 该服务中选项
|
||||
`clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址. 当在一个服务下只有一个 pod
|
||||
并且不打算增加 pods 的数量这是最好的.
|
||||
|
||||
|
||||
前面YAML文件中创建了一个允许集群内其他pods访问数据库的服务. 该服务中选项
|
||||
`clusterIP: None` 让服务DNS名称直接解析为Pod的IP地址. 当在一个服务下只有一个pod
|
||||
并且不打算增加pods的数量这是最好的.
|
||||
|
||||
|
||||
运行MySQL客户端以连接到服务器:
|
||||
运行 MySQL 客户端以连接到服务器:
|
||||
|
||||
```
|
||||
kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -p <password>
|
||||
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
|
||||
```
|
||||
|
||||
此命令在集群内创建一个新的Pod并运行MySQL客户端,并通过服务将其连接到服务器.如果连接成功,你就知道有状态的MySQL database正处于运行状态.
|
||||
此命令在集群内创建一个新的 Pod 并运行 MySQL 客户端,并通过 Service 将其连接到服务器.如果连接成功,你就知道有状态的 MySQL 数据库正处于运行状态.
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
|
||||
@@ -160,16 +135,16 @@ mysql>
|
||||
## 更新
|
||||
|
||||
|
||||
Deployment中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新. 以下是
|
||||
Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新. 以下是
|
||||
特定于有状态应用的一些注意事项:
|
||||
|
||||
* 不要弹性伸缩. 弹性伸缩仅适用于单实例应用. 下层的PersistentVolume仅只能挂载一个pod. 对于集群级有状态应用, 请参考StatefulSet文档
|
||||
* 不要弹性伸缩. 弹性伸缩仅适用于单实例应用. 下层的 PersistentVolume 仅只能挂载一个 pod. 对于集群级有状态应用, 请参考 StatefulSet 文档
|
||||
[StatefulSet documentation](/docs/concepts/workloads/controllers/statefulset/).
|
||||
* 在Deployment的YAML文件中使用 `strategy:` `type: Recreate` . 该选项指示Kubernetes不使用滚动升级. 滚动升级将无法工作, 由于一次不能运行多个pod. 在更新配置文件
|
||||
创建一个新的pod前 `Recreate`策略将先停止第一个pod.
|
||||
* 在 Deployment 的 YAML 文件中使用 `strategy:` `type: Recreate` . 该选项指示 Kubernetes 不使用滚动升级. 滚动升级将无法工作, 由于一次不能运行多个 pod. 在更新配置文件
|
||||
创建一个新的 pod 前 `Recreate` 策略将先停止第一个 pod.
|
||||
|
||||
|
||||
## 删除deployment
|
||||
## 删除 Deployment
|
||||
|
||||
|
||||
通过名称删除部署的对象:
|
||||
@@ -177,27 +152,24 @@ Deployment中镜像或其他部分同往常一样可以通过 `kubectl apply`
|
||||
```
|
||||
kubectl delete deployment,svc mysql
|
||||
kubectl delete pvc mysql-pv-claim
|
||||
kubectl delete pv mysql-pv
|
||||
kubectl delete pv mysql-pv-volume
|
||||
```
|
||||
|
||||
如果使用Compute Engine磁盘，也可以使用如下命令:
|
||||
|
||||
```
|
||||
gcloud compute disks delete mysql-disk
|
||||
```
|
||||
如果通过手动的方式分配 PersistentVolume, 那么也需要手动的删除它，以及释放下层资源.
|
||||
如果是用过动态分配 PersistentVolume 的方式，在删除 PersistentVolumeClaim 后 PersistentVolume 将被自动的删除. 一些存储服务(比如 EBS 和 PD)也会在 PersistentVolume 被删除时自动回收下层资源.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 了解更多Deployment对象请参考 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
|
||||
* 了解更多 Deployment 对象请参考 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
* 了解更多Deployment应用请参考 [Deploying applications](/docs/user-guide/deploying-applications/)
|
||||
* 了解更多 Deployment 应用请参考 [Deploying applications](/docs/user-guide/deploying-applications/)
|
||||
|
||||
* kubectl run文档请参考[kubectl run documentation](/docs/user-guide/kubectl/v1.6/#run)
|
||||
* kubectl run 文档请参考[kubectl run documentation](/docs/reference/generated/kubectl/kubectl-commands/#run)
|
||||
|
||||
* 卷和持久卷请参考[Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
* 卷和持久卷请参考 [Volumes](/docs/concepts/storage/volumes/) 和 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,527 @@
|
||||
---
|
||||
title: 使用 kubectl patch 更新 API 对象
|
||||
description: 使用 kubectl patch 更新 Kubernetes API 对象。做一个策略性的合并 patch 或 JSON 合并 patch。
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Update API Objects in Place Using kubectl patch
|
||||
description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This task shows how to use `kubectl patch` to update an API object in place. The exercises
|
||||
in this task demonstrate a strategic merge patch and a JSON merge patch.
|
||||
-->
|
||||
|
||||
这个任务展示了如何使用 `kubectl patch` 就地更新 API 对象。这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Use a strategic merge patch to update a Deployment
|
||||
-->
|
||||
|
||||
## 使用策略合并 patch 更新 Deployment
|
||||
|
||||
<!--
|
||||
Here's the configuration file for a Deployment that has two replicas. Each replica
|
||||
is a Pod that has one container:
|
||||
-->
|
||||
|
||||
下面是具有两个副本的 Deployment 的配置文件。每个副本是一个 Pod，有一个容器：
|
||||
|
||||
{{< codenew file="application/deployment-patch.yaml" >}}
|
||||
|
||||
<!--
|
||||
Create the Deployment:
|
||||
-->
|
||||
|
||||
创建 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/deployment-patch.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Pods associated with your Deployment:
|
||||
-->
|
||||
查看与 Deployment 相关的 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Deployment has two Pods. The `1/1` indicates that
|
||||
each Pod has one container:
|
||||
-->
|
||||
输出显示 Deployment 有两个 Pod。`1/1` 表示每个 Pod 有一个容器:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-28633765-670qr 1/1 Running 0 23s
|
||||
patch-demo-28633765-j5qs3 1/1 Running 0 23s
|
||||
```
|
||||
|
||||
<!--
|
||||
Make a note of the names of the running Pods. Later, you will see that these Pods
|
||||
get terminated and replaced by new ones.
|
||||
-->
|
||||
把运行的 Pod 的名字记下来。稍后，您将看到这些 Pod 被终止并被新的 Pod 替换。
|
||||
|
||||
<!--
|
||||
At this point, each Pod has one Container that runs the nginx image. Now suppose
|
||||
you want each Pod to have two containers: one that runs nginx and one that runs redis.
|
||||
-->
|
||||
此时，每个 Pod 都有一个运行 nginx 镜像的容器。现在假设您希望每个 Pod 有两个容器：一个运行 nginx，另一个运行 redis。
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file-containers.yaml` that has this content:
|
||||
-->
|
||||
创建一个名为 `patch-file-containers.yaml` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: patch-demo-ctr-2
|
||||
image: redis
|
||||
```
|
||||
|
||||
<!--
|
||||
Patch your Deployment:
|
||||
-->
|
||||
修补您的 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
|
||||
```
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看修补后的 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the PodSpec in the Deployment has two Containers:
|
||||
-->
|
||||
输出显示 Deployment 中的 PodSpec 有两个容器:
|
||||
|
||||
```shell
|
||||
containers:
|
||||
- image: redis
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr-2
|
||||
...
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Pods associated with your patched Deployment:
|
||||
-->
|
||||
查看与 patch Deployment 相关的 Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the running Pods have different names from the Pods that
|
||||
were running previously. The Deployment terminated the old Pods and created two
|
||||
new Pods that comply with the updated Deployment spec. The `2/2` indicates that
|
||||
each Pod has two Containers:
|
||||
-->
|
||||
输出显示正在运行的 Pod 与以前运行的 Pod 有不同的名称。Deployment 终止了旧的 Pod，并创建了两个
|
||||
符合更新的部署规范的新 Pod。`2/2` 表示每个 Pod 有两个容器:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-1081991389-2wrn5 2/2 Running 0 1m
|
||||
patch-demo-1081991389-jmg7b 2/2 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
Take a closer look at one of the patch-demo Pods:
|
||||
-->
|
||||
仔细查看其中一个 patch-demo Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod <your-pod-name> --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Pod has two Containers: one running nginx and one running redis:
|
||||
-->
|
||||
输出显示 Pod 有两个容器:一个运行 nginx，一个运行 redis:
|
||||
|
||||
```
|
||||
containers:
|
||||
- image: redis
|
||||
...
|
||||
- image: nginx
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
### Notes on the strategic merge patch
|
||||
-->
|
||||
|
||||
### 策略性合并类的 patch
|
||||
|
||||
<!--
|
||||
The patch you did in the preceding exercise is called a *strategic merge patch*.
|
||||
Notice that the patch did not replace the `containers` list. Instead it added a new
|
||||
Container to the list. In other words, the list in the patch was merged with the
|
||||
existing list. This is not always what happens when you use a strategic merge patch on a list.
|
||||
In some cases, the list is replaced, not merged.
|
||||
-->
|
||||
您在前面的练习中所做的 patch 称为`策略性合并 patch`。
|
||||
请注意，patch 没有替换`容器`列表。相反，它向列表中添加了一个新容器。换句话说，
|
||||
patch 中的列表与现有列表合并。当您在列表中使用策略性合并 patch 时，并不总是这样。
|
||||
在某些情况下，列表是替换的，而不是合并的。
|
||||
|
||||
<!--
|
||||
With a strategic merge patch, a list is either replaced or merged depending on its
|
||||
patch strategy. The patch strategy is specified by the value of the `patchStrategy` key
|
||||
in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
|
||||
struct has a `patchStrategy` of `merge`:
|
||||
-->
|
||||
对于策略性合并 patch，列表可以根据其 patch 策略进行替换或合并。patch 策略由 Kubernetes 源代码中字段标记中的 `patchStrategy` 键的值指定。
|
||||
例如，`PodSpec` 结构体的 `Containers` 字段有 `merge` 的 `patchStrategy`：
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
|
||||
```
|
||||
|
||||
<!--
|
||||
You can also see the patch strategy in the
|
||||
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
|
||||
-->
|
||||
|
||||
您还可以在 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)
|
||||
规范中看到 patch 策略：
|
||||
|
||||
```json
|
||||
"io.k8s.api.core.v1.PodSpec": {
|
||||
...
|
||||
"containers": {
|
||||
"description": "List of containers belonging to the pod. ...
|
||||
},
|
||||
"x-kubernetes-patch-merge-key": "name",
|
||||
"x-kubernetes-patch-strategy": "merge"
|
||||
},
|
||||
```
|
||||
|
||||
<!--
|
||||
And you can see the patch strategy in the
|
||||
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
-->
|
||||
您可以在 [Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
中看到 patch 策略
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file-tolerations.yaml` that has this content:
|
||||
-->
|
||||
创建一个名为 `patch-file-tolerations.yaml` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
<!--
|
||||
Patch your Deployment:
|
||||
-->
|
||||
patch Deployment：
|
||||
|
||||
|
||||
{{< tabs name="kubectl_patch_example" >}}
|
||||
{{{< tab name="Bash" codelang="bash" >}}
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
|
||||
{{< /tab >}}
|
||||
{{< tab name="PowerShell" codelang="posh" >}}
|
||||
kubectl patch deployment patch-demo --patch $(cat patch-file-containers.yaml)
|
||||
{{< /tab >}}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看 patch Deployment：
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the PodSpec in the Deployment has only one Toleration:
|
||||
-->
|
||||
输出结果显示部署中的 PodSpec 只有一个默认：
|
||||
|
||||
```shell
|
||||
|
||||
containers:
|
||||
- image: redis
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr-2
|
||||
...
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: patch-demo-ctr
|
||||
...
|
||||
```
|
||||
```shell
|
||||
|
||||
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: disktype
|
||||
value: ssd
|
||||
```
|
||||
|
||||
<!--
|
||||
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because
|
||||
the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
|
||||
strategic merge patch uses the default patch strategy, which is `replace`.
|
||||
-->
|
||||
请注意，PodSpec 中的 `tolerations` 列表被替换，而不是合并。这是因为 PodSpec 的 tolerance 字段的字段标签中没有
|
||||
`patchStrategy` 键。所以策略合并 patch 使用默认的 patch 策略，也就是 `replace`。
|
||||
|
||||
```go
|
||||
type PodSpec struct {
|
||||
...
|
||||
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
|
||||
```
|
||||
|
||||
<!--
|
||||
## Use a JSON merge patch to update a Deployment
|
||||
-->
|
||||
## 使用 JSON 合并 patch 更新部署
|
||||
|
||||
<!--
|
||||
A strategic merge patch is different from a
|
||||
[JSON merge patch](https://tools.ietf.org/html/rfc7386).
|
||||
With a JSON merge patch, if you
|
||||
want to update a list, you have to specify the entire new list. And the new list completely
|
||||
replaces the existing list.
|
||||
-->
|
||||
策略性合并 patch 不同于 [JSON 合并 patch](https://tools.ietf.org/html/rfc7386)。
|
||||
使用 JSON 合并 patch，如果您想更新列表，您必须指定整个新列表。新的列表完全取代了现有的列表。
|
||||
|
||||
<!--
|
||||
The `kubectl patch` command has a `type` parameter that you can set to one of these values:
|
||||
-->
|
||||
`kubectl patch` 命令有一个 `type` 参数，您可以将其设置为以下值之一:
|
||||
|
||||
<table>
|
||||
<tr><th>Parameter value</th><th>Merge type</th></tr>
|
||||
<tr><td>json</td><td><a href="https://tools.ietf.org/html/rfc6902">JSON Patch, RFC 6902</a></td></tr>
|
||||
<tr><td>merge</td><td><a href="https://tools.ietf.org/html/rfc7386">JSON Merge Patch, RFC 7386</a></td></tr>
|
||||
<tr><td>strategic</td><td>Strategic merge patch</td></tr>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
For a comparison of JSON patch and JSON merge patch, see
|
||||
[JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/).
|
||||
-->
|
||||
有关 JSON patch 和 JSON 合并 patch 的比较，查看[ JSON patch 和 JSON 合并 patch](http://erosb.github.io/post/json-patch-vs-merge-patch/)。
|
||||
|
||||
<!--
|
||||
The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
|
||||
did a strategic merge patch.
|
||||
-->
|
||||
`type` 参数的默认值是 `strategic`。在前面的练习中，我们做了一个策略性的合并 patch。
|
||||
|
||||
<!--
|
||||
Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml`
|
||||
that has this content:
|
||||
-->
|
||||
下一步，在相同的部署上执行 JSON 合并 patch。创建一个名为 `patch-file-2` 的文件。内容如下:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: patch-demo-ctr-3
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
```
|
||||
|
||||
<!--
|
||||
In your patch command, set `type` to `merge`:
|
||||
-->
|
||||
在 patch 命令中，将 `type` 设置为 `merge`：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)"
|
||||
```
|
||||
|
||||
<!--
|
||||
View the patched Deployment:
|
||||
-->
|
||||
查看 patch 部署：
|
||||
|
||||
```shell
|
||||
kubectl get deployment patch-demo --output yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The `containers` list that you specified in the patch has only one Container.
|
||||
The output shows that your list of one Container replaced the existing `containers` list.
|
||||
-->
|
||||
patch 中指定的`容器`列表只有一个容器。
|
||||
输出显示您的一个容器列表替换了现有的`容器`列表。
|
||||
|
||||
```shell
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google-samples/node-hello:1.0
|
||||
...
|
||||
name: patch-demo-ctr-3
|
||||
```
|
||||
|
||||
<!--
|
||||
List the running Pods:
|
||||
-->
|
||||
列表中运行的 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
In the output, you can see that the existing Pods were terminated, and new Pods
|
||||
were created. The `1/1` indicates that each new Pod is running only one Container.
|
||||
-->
|
||||
在输出中，您可以看到已经终止了现有的 Pod，并创建了新的 Pod。`1/1` 表示每个新 Pod只运行一个容器。
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
patch-demo-1307768864-69308 1/1 Running 0 1m
|
||||
patch-demo-1307768864-c86dc 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Alternate forms of the kubectl patch command
|
||||
-->
|
||||
|
||||
## kubectl patch 命令的其他形式
|
||||
|
||||
<!--
|
||||
The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
|
||||
directly on the command line.
|
||||
-->
|
||||
`kubectl patch` 命令使用 YAML 或 JSON。它可以将 patch 作为文件，也可以直接在命令行中使用。
|
||||
|
||||
<!--
|
||||
Create a file named `patch-file.json` that has this content:
|
||||
-->
|
||||
创建一个文件名称是 `patch-file.json` 内容如下：
|
||||
|
||||
```json
|
||||
{
|
||||
"spec": {
|
||||
"template": {
|
||||
"spec": {
|
||||
"containers": [
|
||||
{
|
||||
"name": "patch-demo-ctr-2",
|
||||
"image": "redis"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The following commands are equivalent:
|
||||
-->
|
||||
以下命令是相同的：
|
||||
|
||||
```shell
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
|
||||
kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis'
|
||||
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file.json)"
|
||||
kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
## Summary
|
||||
-->
|
||||
|
||||
## 总结
|
||||
|
||||
<!--
|
||||
In this exercise, you used `kubectl patch` to change the live configuration
|
||||
of a Deployment object. You did not change the configuration file that you originally used to
|
||||
create the Deployment object. Other commands for updating API objects include
|
||||
[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate),
|
||||
[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit),
|
||||
[kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace),
|
||||
[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale),
|
||||
and
|
||||
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply).
|
||||
-->
|
||||
在本练习中，您使用 `kubectl patch` 更改部署对象的实时配置。您没有更改最初用于创建部署对象的配置文件。
|
||||
用于更新 API 对象的其他命令包括
|
||||
[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)，
|
||||
[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
|
||||
[kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace)，
|
||||
[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)，
|
||||
和
|
||||
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)
|
||||
* [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
|
||||
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/imperative-config/)
|
||||
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/declarative-config/)
|
||||
-->
|
||||
|
||||
* [Kubernetes 对象管理器](/docs/concepts/overview/object-management-kubectl/overview/)
|
||||
* [使用命令管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-command/)
|
||||
* [使用配置文件强制管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-config/)
|
||||
* [使用配置文件对 Kubernetes 对象进行声明式管理](/docs/concepts/overview/object-management-kubectl/declarative-config/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user