whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

zh-trans: merge zh content from release-1.16-temporary into release-1.16 (#18216)

Browse Source 
* Update http-proxy-access-api.md (#16932)

* Update coredns.md (#16930)

* zh-trans:/docs/docs/concepts/workloads/pods/ephemeral-containers.md (#16948)

* update zh-trans of define-environment-variable-container.md (#16999)

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

* update chinese docs (#16985)

* Fix ordered list (#16988)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* zh-trans:/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md (#16951)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* Remove redundant symbol and fix some ordered list (#17000)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* update-zh-translation/docs/reference/setup-tools/kubeadm/kubeadm-init.md (#16997)

* update zh translation kubeadm-reset.md kubeadm-upgrade.md (#16992)

* Create kubeadm_join_phase_control-plane-join_all.md (#16987)

* Update web-ui-dashboard.md (#16976)

* update format problem (#16956)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* zh-trans:/docs/docs/concepts/storage/volume-pvc-datasource.md (#17021)

* update zh translation /docs/reference/access-authn-authz/webhook.md (#16860)

* fix confict update zh translation (#16863)

* zh-trans:/docs/concepts/workloads/pods/disruptions.md (#16983)

* zh-trans:/docs/concepts/workloads/pods/disruptions.md

* Update content/zh/docs/concepts/workloads/pods/disruptions.md

Co-Authored-By: Qiming <tengqim@cn.ibm.com>

* update zh translation content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md (#17006)

* Update RC's link (#16935)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

Update

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

update the style

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* Update the links for /zh/docs/setup (#16938)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* zh-trans:/docs/docs/concepts/services-networking/dual-stack.md (#17024)

* update zh translation /reference/setup-tools/kubeadm/generated/kubeadm.md (#17036)

* update zh tanslation /reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md (#17037)

* update zh translation -/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md (#17038)

* update zh translation /docs/contribute/participating.md (#17040)

* Fix cri-o's links to match English docs (#16936)

Signed-off-by: PingWang <wang.ping5@zte.com.cn>

* update zh translation content/zh/docs/reference/kubectl/jsonpath.md (#16862)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md (#17049)

* update Unkown ->  Unknown (#17062)

* zh-translation:high-availability.md (#16960)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* update Runnning -> Running (#17061)

* zh-trans:/docs/docs/concepts/storage/volume-snapshots.md (#17054)

* update zh transation /docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md (#17060)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md (#17052)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#17055)

* update zh translation update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md (#17048)

* update zh-translation:ha-topology.md (#17099)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md (#17093)

* update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md (#17083)

* Add Chinese translation for scheduler-perf-tuning (#17087)

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for scheduler-perf-tuning

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for scheduler-perf-tuning

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for scheduler-perf-tuning

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

* zh trans content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md (#17121)

* update zh trans content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md (#17122)

* zh-translation:content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md (#17105)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* update-zh-translation-/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md (#17091)

* update zh trans /docs/setup/learning-environment/minikube.md (#17143)

* update zh trans /zh/docs/reference/_index.md (#17146)

* update zh trans /docs/tasks/access-application-cluster/port-forward-access-application-cluster.md (#17134)

* update zh translation 20191020-update-zh-translation-/docs/contribute/localization.md (#17046)

* update zh trans /docs/reference/using-api/client-libraries.md (#17144)

* update zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md (#17145)

* update zh /docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md (#17131)

* update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md (#17081)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md (#17078)

* add zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md (#17076)

* update zh trans content/zh/docs/contribute/generate-ref-docs/kubectl.md (#17165)

* update zh translation /reference/command-line-tools-reference/kube-proxy.md (#17107)

* zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-const… (#16955)

* zh-trans:/docs/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

* Update pod-topology-spread-constraints.md

* zh-trans:/docs/concepts/configuration/scheduling-framework.md (#17088)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md (#17079)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md (#17077)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md (#17075)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md (#17050)

* update zh trans /docs/concepts/overview/working-with-objects/namespaces.md (#17205)

* update zh trans /docs/concepts/overview/what-is-kubernetes.md (#17203)

* pr_release-1.16_crictl (#17201)

* update zh docs/tasks/administer-cluster/dns-debugging-resolution.md (#17186)

* update zh trans content/zh/docs/concepts/overview/working-with-objects/field-selectors.md (#17191)

* translate configure_upgrade_etcd (#17160)

* translate kubeadm_upgrade_apply (#17159)

* update zh /docs/tasks/job/coarse-parallel-processing-work-queue.md (#17155)

* translate docs/setup/release/version-skew-policy.md to Chinese (#17142)

* update zh trans content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md (#17124)

* zh-trans replace the wrong translation (#17103)

zh-trans replace the wrong translation

* Merged 1.14~1.16 changes (#17117)

* zh-trans:/docs/concepts/configuration/assign-pod-node.md (#17129)

* update zh trans /docs/contribute/generate-ref-docs/kubernetes-api.md (#17161)

* pr_release-1.16_basic-ss (#17169)

* Add zh-trans of assign-cpu-resource.md (#17063)

Signed-off-by: heqg <he.qingguo@zte.com.cn>

Add zh-trans of assign-cpu-resource.md

Signed-off-by: heqg <he.qingguo@zte.com.cn>

Add zh-trans of assign-cpu-resource.md

Signed-off-by: heqg <he.qingguo@zte.com.cn>

Add zh-trans of assign-cpu-resource.md

Signed-off-by: heqg <he.qingguo@zte.com.cn>

Add zh-trans of assign-cpu-resource.md

Signed-off-by: heqg <he.qingguo@zte.com.cn>

* update zh trans content/zh/docs/concepts/overview/working-with-objects/common-labels.md (#17193)

* update zh translation /docs/contribute/intermediate.md (#17041)

* zh-trans:docs/setup/production-environment/turnkey/tencent.md (#17207)

* pr_release-1.16_mysql-wordpress-pv (#17202)

* pr_release-1.16_reconfig-kubelet (#17200)

* zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completio… (#17020)

* zh-trans:/docs/docs/concepts/workloads/controllers/jobs-run-completion.md

* Update jobs-run-completion.md

* Update jobs-run-completion.md

* update zh trans content/zh/docs/concepts/extend-kubernetes/extend-cluster.md (#17212)

* update zh trans content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md (#17213)

* add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md (#17220)

kubeadm_join_phase_control-plane-prepare_download-certs.md

* add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md and /reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md (#17219)

* update zh trans content/zh/docs/concepts/containers/images.md (#17216)

* ZH-trans: add _index.md (#17214)

* ZH-trans: add _index.md

* add _index.md file

* add _index.md files

* pr_release-1.16_crd-versions (#17198)

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md (#17092)

* zh-trans /reference/setup-tools/kubeadm/generated/kubeadm_config_images.md (#17094)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md   and   content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md (#17222)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md  content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md (#17221)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md (#17223)

* 013 /docs/concepts/services networking/ingress.md (#17185)

* x

* update zh trans content/zh/docs/concepts/services-networking/ingress.md

* zh-trans:/reference/setup-tools/kubeadm/generated/kubeadm_completion.md and kubeadm_config.md (#17097)

* add zh trans reference/glossary/pod-lifecycle (#17226)

* update zh-translation document (#17096)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* update zh-translation:setup-ha-etcd-with-kubeadm.md (#17098)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md (#17227)

* add zh trans /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md and /docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md (#17228)

* zh-translation:content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md (#17089)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* update zh translation /docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md (#17080)

* update zh translation /reference/setup-tools/kubeadm/generated/kubeadm_config_view.md (#17085)

* zh-translation:troubleshooting-kubeadm.md (#17069)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* zh-trans: docs/concepts/scheduling/kube-scheduler.md (#17067)

* Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

Add Chinese translation for kube-scheduler

Signed-off-by: GeorgeSen <wang.sen2@zte.com.cn>

* Update kube-scheduler.md

* Add Chinese translation for kube-scheduler

* Update kube-scheduler.md

* Update kube-scheduler.md

* Update kube-scheduler.md

* translate pods.md  and init-containers.md for branch release-1.16 (#17208)

* update zh translation /docs/contribute/start.md (#17039)

* zh-translation:2017-10-00-Five-Days-Of-Kubernetes-18.md (#17229)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* translate kubeadm-certs.md (#17090)

* update the Illegal comment such as : (<！--、<--) (#17266)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md (#17268)

* update zh /docs/concepts/architecture/cloud-controller.md (#17263)

* update zh /docs/concepts/cluster-administration/logging.md (#17247)

* modify the show of zh translation /concepts/overview/what-is-kubernetes.md /reference/setup-tools/kubeadm/generated/kubeadm_init.md  /reference/setup-tools/kubeadm/kubeadm-init.md (#17246)

* zh-translation:kubeadm_init_phase_control-plane_all.md (#17243)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* zh-translation:kubeadm_join_phase_control-plane-join_etcd.md (#17236)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md (#17230)

* add content/zh/docs/reference/glossary/container-runtime.md file fix-up to pass the ci and trans content/zh/docs/reference/glossary/container-runtime.md、content/zh/docs/concepts/overview/components.md (#17211)

* zh-translation:mirror-pod.md (#17231)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* zh-translation:kubeadm_init_phase_upload-config.md (#17238)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* update zh /docs/concepts/workloads/pods/pod-overview.md (#17239)

* update the format of zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md   content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md  content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md  content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md  content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md  content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md  content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md (#17248)

* Create advanced.md (#17256)

* Create advanced.md

* trans the advanced.md and fix the build bugs

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md (#17269)

* zh-translation:kubelet-integration.md (#17272)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* pr_release-1.16_out-of-resource (#17199)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md (#17267)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md (#17271)

* pr_release-1.16_ext-admission-ctl (#17196)

* update zh translation /docs/contribute/advanced.md (#17042)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md (#17275)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md (#17282)

* add zh trans  content/zh/docs/reference/setup-tools/kubeadm/generated… (#17287)

* add zh trans  content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md

* Update kubeadm_init_phase_etcd.md

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17285)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-server.md content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md update zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver.md

* Update kubeadm_alpha_kubelet.md

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md fix-up bad comment kubeadm_alpha_certs_renew.md、kubeadm_alpha_certs_renew_apiserver-etcd-client.md、kubeadm_init_phase_addon_all.md (#17276)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/… (#17281)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md

* Update kubeadm_init_phase_etcd_local.md

* zh trans update-daemon-set.md (#16872)

* zh trans update-daemon-set.md

* Update update-daemon-set.md

* managing-tls-in-a-cluster.md (#16874)

* update-api-object-kubectl-patch.md (#16875)

* improve the zh trans /kubeadm/generated/kubeadm_init_phase_.* 1 (#17295)

* improve the zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_.* (#17294)

* modify the zh translation content/zh/docs/reference/setup-tools/kubea… (#17293)

* modify the zh translation content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_.*

* Update kubeadm_alpha.md

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md and content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md (#17280)

* add zh /docs/reference/glossary/cgroup.md (#17291)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md (#17288)

* improve zh trans of command in /kubeadm/generated/kubeadm_init_phase_.* files (#17297)

* improve zh command translation /kubeadm/generated/kubeadm_init_.* files (#17298)

* update zh trans in /kubeadm/generated/kubeadm_.* files (#17306)

* add zh trans /reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_etcd-peer.md、/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md (#17308)

* Improve previously translated documents (#17327)

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* zh-trans: docs/setup/production-environment/turnkey/aws.md (#17320)

* Update zh.toml

* update zh trans /generated/kubeadm_join_phase_.* files (#17301)

* Update zh.toml

* add zh /docs/reference/glossary/pod-disruption-budget.md (#17344)

* pr_release-1.16_config-aggregation-layer (#17197)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_controller-manager.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_scheduler.conf.md (#17390)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md (#17381)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md (#17380)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md (#17383)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_certificate-key.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md (#17385)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_admin.conf.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md (#17387)

* add zh trans content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_renew_front-proxy-client.md、content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md (#17384)

* add zh /docs/reference/glossary/limitrange.md (#17324)

* add zh trans content/zh/docs/setup/best-practices/cluster-large.md (#17321)

* add zh trans content/zh/docs/setup/best-practices/cluster-large.md

* Update cluster-large.md

* add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/do… (#17403)

* add zh trans /docs/reference/setup-tools/kubeadm/kubeadm-alpha.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md、/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md

* Update kubeadm_init_phase_certs_etcd-server.md

* add zh /docs/reference/glossary/cluster-operations.md (#17300)

* add zh /docs/reference/glossary/applications.md (#17419)

* update zh trans kubelet (#17379)

* update zh trans kubelet

* update the file according to feedback from reviewer tengqm

* update 1000-1757 lines

* update the advice zh trans

* add zh /docs/reference/glossary/static-pod.md (#17418)

* add zh /docs/reference/glossary/preemption.md (#17423)

* add zh /docs/reference/glossary/pod-priority.md (#17421)

* add zh /docs/reference/glossary/control-plane.md (#17425)

* add zh /docs/reference/glossary/cluster-infrastructure.md (#17424)

* pr_release-1.16_api-overview (#17444)

* pr_release-1.16_daemonset (#17435)

* pr_release-1.16_gc (#17445)

* pr_release-1.16_qos-class (#17442)

* fix QoS Class to QoS 类 (#17464)

* pr_release-1.16-abac (#17427)

* zh-trans:docs/setup/production-environment/turnkey/alibaba-cloud.md (#17345)

* pr_release-1.16_endpoint-slice (#17468)

* pr_release-1.16_taint (#17469)

* pr_release-1.16_operator-pattern (#17467)

* pr_release-1.16_ss (#17433)

* pr_release-1.16_admission-controller (#17440)

* pr_release-1.16_containerd (#17441)

* pr_release-1.16_app-container (#17466)

* add zh-trans content/zh/docs/setup/_index.md、content/zh/docs/setup/release/_index.md (#17503)

* pr-release-1.16_enabling-endpoint-slices (#17504)

* update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495)

* update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md、content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md

* add content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md

* pr-release-1.16_logging (#17491)

* pr-release-1.16_cri (#17486)

* add zh-trans:docs/setup/production-environment/turnkey/azure.md (#17482)

* pattern translate into 模式 (#17485)

* fix zk affinity description in zh trans (#17393)

* pr-release-1.16_ephemeral-container (#17487)

* pr-release-1.16_data-plane (#17489)

* pr-release-1.16_cncf (#17490)

* zh-trans add content\zh\docs\tools\install-minikube.md (#16920)

* zh-trans add content\zh\docs\tools\install-minikube.md

* zh-trans update content\zh\docs\tools\install-minikube.md

* zh-trans update content\zh\docs\tools\install-minikube.md

* update \docs\tasks\tools\install-minikube.md

* update docs\concepts\workloads\controllers\deployment.md

* update deployment.md

* pr-release-1.16_extensions (#17492)

* pr-release-1.16_toleration (#17493)

* Revert "update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm… (#17495)" (#17521)

This reverts commit 1134c14e0a39bdc3d1a920ac9797139a6dcccf4b.

* motidy extensions in content/zh/docs/reference/glossary/extensions (#17524)

* motidy toleration in content/zh/docs/reference/glossary/toleration.md (#17523)

* motidy toleration in content/zh/docs/reference/glossary/toleration.md

* Update toleration.md

* improve zh-trans in content/zh/docs/setup/_index.md (#17526)

* add zh-trans /zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md (#17527)

* Broken Link (#17546)

Issue available at https://kubernetes.io/zh/docs/concepts/containers/runtime-class/
and introduced by original English documentation (see #17543)

* Update trans kubeadm_upgrade_plan.md (#17395)

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* update zh-trans of define-command-argument-container.md (#17022)

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

update zh-trans of define-command-argument-container.md

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

Add back the Original English

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

update title of define-command-argument-container.md

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

update table title and reference

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

update reference of define-command-argument-container.md

Signed-off-by: Yixiang2019 <wang.yixiang@zte.com.cn>

* ZH-trans: fix multiple jump links and update files (#17603)

* ZH-trans: fix multiple jump links and update files

* Update _index.html

* update zh trans content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md (#17528)

* update zh trans /doc/concepts/architecture/nodes.md (#17617)

* update zh trans content/zh/docs/concepts/architecture/nodes.md

* fix-up content/zh/docs/concepts/architecture/nodes.md

* add zh-trans /docs/setup/release/notes.md (#17519)

* add zh-trans /docs/setup/release/notes.md

update-750

*  fix-up 1575 line and udpate 2483 line

* update to line 2980

* update to the last line 3160

* add zh-trans:docs/setup/production-environment/turnkey/icp.md (#17568)

* zh-trans: /docs/setup/production-environment/container-runtimes.md (#17646)

* zh-trs:container-runtimes.md

Signed-off-by: yuxiaobo <yuxiaobogo@163.com>

* Update container-runtimes.md

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese (#17791)

* Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese

* Sorry, wrong commit, roll back...

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese

* Create trans kubeadm_upgrade_diff.md (#17392)

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Create _index.md (#17831)

* zh-trans zh-trans-/docs/reference/command-line-tools-reference/feature-gates.md (#17658)

* Update volume-snapshots.md (#17829)

* Update volume-snapshots.md

* Update volume-snapshots.md

* Update volume-snapshots.md

* Create ovirt.md (#17849)

* Create ovirt.md

* Update ovirt.md

* Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese (#17761)

* Translate /docs/concepts/cluster-administration/cloud-providers.md into Chinese

* Translate /docs/concepts/workloads/controllers/ttlafterfinished.md into Chinese

* Sorry, wrong commit, roll back...

* Update translation after tengqm's review.

* Update cloud-providers.md

* Update dual-stack.md (#17836)

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

* Create validate-dual-stack.md (#17833)

* Create validate-dual-stack.md

* Update validate-dual-stack.md

* translation content/zh/docs/reference/setup-tools/kubeadm/ kubeadm-join-phase、kubeadm-reset-phase (#17881)

* zh-trans content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md (#17882)

* Chinese translation /docs/tasks/administer-cluster/highly-available-master.md (#17884)

* Chinese translation /docs/tasks/administer-cluster/highly-available-master.md

* Apply suggestions from code review

Co-Authored-By: Qiming <tengqim@cn.ibm.com>

* Fix format issue (#17921)

* Create topology-manager.md (#17901)

* Create topology-manager.md

* Update topology-manager.md

* add zh-trans:docs/setup/production-environment/windows/user-guide-windows-containers.md (#17876)

* Update pod-overhead.md (#17931)

* Update scheduler-perf-tuning.md (#17934)

* Create dcos.md (#17932)

* Create dcos.md

* Update dcos.md

* Update object-management.md (#17937)

* zh-translation content/zh/docs/setup/production-environment/tools/kops.md (#17991)

* Create imperative-config.md (#17956)

* Create imperative-config.md

* Update imperative-config.md

* Create self-hosting.md (#17950)

* Create resource-bin-packing.md (#17935)

* Create nodelocaldns.md (#17938)

* Update config.toml(release-1.16) for 1.17 (#18025)

* Update config.toml(release-1.16) for 1.17

* Update config.toml

* Remove ru language

* fix shotcode mismatch

Co-authored-by: zhangx501 <zhang0000xun@gmail.com>
Co-authored-by: ZhongliangXiong <xiong.zhongliang@zte.com.cn>
Co-authored-by: Yixiang Wang <wang.yixiang@zte.com.cn>
Co-authored-by: li mengyang <hwdef97@gmail.com>
Co-authored-by: PingWang <wang.ping5@zte.com.cn>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: Sophy417 <53026875+Sophy417@users.noreply.github.com>
Co-authored-by: Qiming <tengqim@cn.ibm.com>
Co-authored-by: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com>
Co-authored-by: senwang <wang.sen2@zte.com.cn>
Co-authored-by: lichuqiang <lichuqiang@huawei.com>
Co-authored-by: lpf7551321 <liupengfei20@huawei.com>
Co-authored-by: Hongcai Ren <renhongcai@huawei.com>
Co-authored-by: jiajie <jiaj12@chinaunicom.cn>
Co-authored-by: heqg <56527988+heqg@users.noreply.github.com>
Co-authored-by: IreneByron <zhangbingqing7@huawei.com>
Co-authored-by: LiuDui <1693291525@qq.com>
Co-authored-by: Wang Bing <wangbing.adam@gmail.com>
Co-authored-by: Damini Satya <daminisatya@gmail.com>
Co-authored-by: liufangwai <liufangwai@huawei.com>
Co-authored-by: wangcong <congfairy2536@gmail.com>
Co-authored-by: XuefeiWang2 <wangxuefei2@huawei.com>
Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Co-authored-by: Ziqiu Zhu <zzqshu@126.com>
Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com>
Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-authored-by: jiazxjason <52809535+jiazxjason@users.noreply.github.com>
Co-authored-by: Coffey Gao <coffiney@qq.com>
Co-authored-by: Bingshen Wang <bingshen.wbs@alibaba-inc.com>
This commit is contained in:
SataQiu
2019-12-25 08:53:29 +08:00
committed by Kubernetes Prow Robot
parent 6be3e1414d
commit 0f2bd2871b
932 changed files with 113356 additions and 8088 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/setup/production-environment/_index.md
+9
View File
@@ -0,0 +1,9 @@
---
title: 生产环境
weight: 30
---
<!--
title: Production environment
weight: 30
-->
content/zh/docs/setup/production-environment/container-runtimes.md
+583
View File
@@ -0,0 +1,583 @@
---
reviewers:
- vincepri
- bart0sh
title: 容器运行时
content_template: templates/concept
weight: 10
---
<!--
---
reviewers:
- vincepri
- bart0sh
title: Container runtimes
content_template: templates/concept
weight: 10
---
-->
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
<!--
To run containers in Pods, Kubernetes uses a container runtime. Here are
the installation instructions for various runtimes.
-->
Kubernetes 使用容器运行时来实现在 pod 中运行容器。
这是各种运行时的安装说明。
{{% /capture %}}
{{% capture body %}}
{{< caution >}}
<!--
A flaw was found in the way runc handled system file descriptors when running containers.
A malicious container could use this flaw to overwrite contents of the runc binary and
consequently run arbitrary commands on the container host system.
Please refer to this link for more information about this issue
[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
-->
我们发现 runc 在运行容器，处理系统文件描述符时存在一个漏洞。
恶意容器可以利用此漏洞覆盖 runc 二进制文件的内容，并以此在主机系统的容器上运行任意的命令。
请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
{{< /caution >}}
<!--
### Applicability
-->
### 适用性
{{< note >}}
<!--
This document is written for users installing CRI onto Linux. For other operating
systems, look for documentation specific to your platform
-->
本文档是为在 Linux 上安装 CRI 的用户编写的。
对于其他操作系统，请查找特定于您平台的文档。
{{< /note >}}
<!--
You should execute all the commands in this guide as `root`. For example, prefix commands
with `sudo `, or become `root` and run the commands as that user.
-->
您应该以 `root` 身份执行本指南中的所有命令。
例如，使用 `sudo` 前缀命令，或者成为 `root` 并以该用户身份运行命令。
<!--
### Cgroup drivers
-->
### Cgroup 驱动程序
<!--
When systemd is chosen as the init system for a Linux distribution, the init process generates
and consumes a root control group (`cgroup`) and acts as a cgroup manager. Systemd has a tight
integration with cgroups and will allocate cgroups per process. It's possible to configure your
container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside systemd means
that there will then be two different cgroup managers.
-->
当某个 Linux 系统发行版使用 systemd 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 （`cgroup`），并充当 cgroup 管理器。
systemd 与 cgroup 集成紧密，并将为每个进程分配 cgroup。
您也可以配置容器运行时和 kubelet 使用 `cgroupfs`。
连同 systemd 一起使用 `cgroupfs` 意味着将有两个不同的 cgroup 管理器。
<!--
Control groups are used to constrain resources that are allocated to processes.
A single cgroup manager will simplify the view of what resources are being allocated
and will by default have a more consistent view of the available and in-use resources. When we have
two managers we end up with two views of those resources. We have seen cases in the field
where nodes that are configured to use `cgroupfs` for the kubelet and Docker, and `systemd`
for the rest of the processes running on the node becomes unstable under resource pressure.
-->
控制组用来约束分配给进程的资源。
单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用中的资源具有更一致的视图。
当有两个管理器时，最终将对这些资源产生两种视图。
在此领域我们已经看到案例，某些节点配置让 kubelet 和 docker 使用 `cgroupfs`，而节点上运行的其余进程则使用 systemd；这类节点在资源压力下会变得不稳定。
<!--
Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
stabilized the system. Please note the `native.cgroupdriver=systemd` option in the Docker setup below.
-->
更改设置，令容器运行时和 kubelet 使用 `systemd` 作为 cgroup 驱动，以此使系统更为稳定。
请注意在 docker 下设置 `native.cgroupdriver=systemd` 选项。
{{< caution >}}
<!--
Changing the cgroup driver of a Node that has joined a cluster is highly unrecommended.
If the kubelet has created Pods using the semantics of one cgroup driver, changing the container
runtime to another cgroup driver can cause errors when trying to re-create the PodSandbox
for such existing Pods. Restarting the kubelet may not solve such errors. The recommendation
is to drain the Node from its workloads, remove it from the cluster and re-join it.
-->
强烈建议不要更改已加入集群的节点的 cgroup 驱动。
如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，尝试更改运行时以使用别的 cgroup 驱动，为现有 Pods 重新创建 PodSandbox 时会产生错误。
重启 kubelet 也可能无法解决此类问题。
推荐将工作负载逐出节点，之后将节点从集群中删除并重新加入。
{{< /caution >}}
<!--
## Docker
On each of your machines, install Docker.
Version 18.06.2 is recommended, but 1.11, 1.12, 1.13, 17.03 and 18.09 are known to work as well.
Keep track of the latest verified Docker version in the Kubernetes release notes.
Use the following commands to install Docker on your system:
-->
## Docker
在您的每台机器上安装 Docker。
推荐安装 18.06.2 版本，但是 1.11、1.12、1.13、17.03 和 18.09 版本也是可以的。
请跟踪 Kubernetes 发行说明中经过验证的 Docker 最新版本变化。
使用以下命令在您的系统上安装 Docker：
{{< tabs name="tab-cri-docker-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
<!--
# Install Docker CE
## Set up the repository:
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
### Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-->
# 安装 Docker CE
## 设置仓库
### 安装软件包以允许 apt 通过 HTTPS 使用存储库
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
### 新增 Docker 的 官方 GPG 秘钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
<!--
### Add Docker apt repository.
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
## Install Docker CE.
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
# Setup daemon.
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
mkdir -p /etc/systemd/system/docker.service.d
-->
### 添加 Docker apt 仓库
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
## 安装 Docker CE
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
# 设置 daemon
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
mkdir -p /etc/systemd/system/docker.service.d
<!--
# Restart docker.
systemctl daemon-reload
systemctl restart docker
-->
# 重启 docker.
systemctl daemon-reload
systemctl restart docker
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
<!--
# Install Docker CE
## Set up the repository
### Install required packages.
yum install yum-utils device-mapper-persistent-data lvm2
### Add Docker repository.
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
## Install Docker CE.
yum update && yum install docker-ce-18.06.2.ce
## Create /etc/docker directory.
mkdir /etc/docker
# Setup daemon.
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
EOF
mkdir -p /etc/systemd/system/docker.service.d
-->
# 安装 Docker CE
## 设置仓库
### 安装所需包
yum install yum-utils device-mapper-persistent-data lvm2
### 新增 Docker 仓库。
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
## 安装 Docker CE.
yum update && yum install docker-ce-18.06.2.ce
## 创建 /etc/docker 目录。
mkdir /etc/docker
# 设置 daemon。
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
EOF
mkdir -p /etc/systemd/system/docker.service.d
<!--
# Restart Docker
systemctl daemon-reload
systemctl restart docker
-->
# 重启 Docker
systemctl daemon-reload
systemctl restart docker
{{< /tab >}}
{{< /tabs >}}
<!--
Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
for more information.
-->
请参阅[官方 Docker 安装指南](https://docs.docker.com/engine/installation/)
来获取更多的信息。
<!--
## CRI-O
This section contains the necessary steps to install `CRI-O` as CRI runtime.
Use the following commands to install CRI-O on your system:
### Prerequisites
```shell
modprobe overlay
modprobe br_netfilter
# Setup required sysctl params, these persist across reboots.
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl --system
```
-->
## CRI-O
本节包含安装 `CRI-O` 作为 CRI 运行时的必要步骤。
使用以下命令在系统中安装 CRI-O：
### 准备环境
```shell
modprobe overlay
modprobe br_netfilter
# 设置必需的sysctl参数，这些参数在重新启动后仍然存在。
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
<!--
# Install prerequisites
apt-get update
apt-get install software-properties-common
add-apt-repository ppa:projectatomic/ppa
apt-get update
# Install CRI-O
apt-get install cri-o-1.15
-->
# 安装必备软件
apt-get update
apt-get install software-properties-common
add-apt-repository ppa:projectatomic/ppa
apt-get update
# 安装 CRI-O
apt-get install cri-o-1.15
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
<!--
# Install prerequisites
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
# Install CRI-O
yum install --nogpgcheck cri-o
-->
# 安装必备软件
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
# 安装 CRI-O
yum install --nogpgcheck cri-o
{{< /tab >}}
{{< /tabs >}}
<!--
### Start CRI-O
```
systemctl start crio
```
Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
for more information.
-->
### 启动 CRI-O
```
systemctl start crio
```
请参阅[CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started)
来获取更多的信息。
<!--
## Containerd
This section contains the necessary steps to use `containerd` as CRI runtime.
Use the following commands to install Containerd on your system:
### Prerequisites
```shell
cat > /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF
modprobe overlay
modprobe br_netfilter
# Setup required sysctl params, these persist across reboots.
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl --system
```
-->
## containerd
本节包含使用 `containerd` 作为 CRI 运行时的必要步骤。
使用以下命令在系统上安装容器：
### 准备环境
```shell
cat > /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF
modprobe overlay
modprobe br_netfilter
# 设置必需的sysctl参数，这些参数在重新启动后仍然存在。
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl --system
```
<!--
### Install containerd
-->
### 安装 containerd
{{< tabs name="tab-cri-containerd-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
<!--
# Install containerd
## Set up the repository
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
### Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
### Add Docker apt repository.
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
## Install containerd
apt-get update && apt-get install -y containerd.io
# Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
-->
# 安装 containerd
## 设置仓库
### 安装软件包以允许 apt 通过 HTTPS 使用存储库
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
### 安装 Docker 的官方 GPG 密钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
### 新增 Docker apt 仓库。
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
## 安装 containerd
apt-get update && apt-get install -y containerd.io
# 配置 containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
<!--
# Restart containerd
systemctl restart containerd
-->
# 重启 containerd
systemctl restart containerd
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
<!--
# Install containerd
## Set up the repository
### Install required packages
yum install yum-utils device-mapper-persistent-data lvm2
### Add docker repository
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
## Install containerd
yum update && yum install containerd.io
# Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
-->
# 安装 containerd
## 设置仓库
### 安装所需包
yum install yum-utils device-mapper-persistent-data lvm2
### 新增 Docker 仓库
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
## 安装 containerd
yum update && yum install containerd.io
# 配置 containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
<!--
# Restart containerd
systemctl restart containerd
-->
# 重启 containerd
systemctl restart containerd
{{< /tab >}}
{{< /tabs >}}
<!--
### systemd
To use the `systemd` cgroup driver, set `plugins.cri.systemd_cgroup = true` in `/etc/containerd/config.toml`.
When using kubeadm, manually configure the
[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
## Other CRI runtimes: frakti
Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information.
-->
### systemd
使用 `systemd` cgroup 驱动，在 `/etc/containerd/config.toml` 中设置 `plugins.cri.systemd_cgroup = true`。
当使用 kubeadm 时，请手动配置
[kubelet 的 cgroup 驱动](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
## 其他的 CRI 运行时：frakti
请参阅 [Frakti 快速开始指南](https://github.com/kubernetes/frakti#quickstart) 来获取更多的信息。
{{% /capture %}}
content/zh/docs/setup/production-environment/on-premises-vm/_index.md
+10
View File
@@ -0,0 +1,10 @@
---
title: 本地 VMs
weight: 40
---
<!--
---
title: On-Premises VMs
weight: 40
---
-->
content/zh/docs/setup/production-environment/on-premises-vm/dcos.md
+48
View File
@@ -0,0 +1,48 @@
---
reviewers:
- smugcloud
title: DC/OS 上的 Kubernetes
content_template: templates/concept
---
<!--
---
reviewers:
- smugcloud
title: Kubernetes on DC/OS
content_template: templates/concept
---
-->
{{% capture overview %}}
<!--
Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://mesosphere.com/product/), offering:
-->
Mesosphere 提供了一个简单的选项来将 Kubernetes 设置到[DC/OS](https://mesosphere.com/product/)上，它提供：
<!--
* Pure upstream Kubernetes
* Single-click cluster provisioning
* Highly available and secure by default
* Kubernetes running alongside fast-data platforms (e.g. Akka, Cassandra, Kafka, Spark)
-->
* 纯上游 Kubernetes
* 集群一键部署
* 默认情况下高度可用且安全
* 与快速数据平台 (例如 Akka、Cassandra、Kafka、Spark) 一起运行的 Kubernetes
{{% /capture %}}
{{% capture body %}}
<!--
## Official Mesosphere Guide
-->
## Mesosphere 官方指南
<!--
The canonical source of getting started on DC/OS is located in the [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart).
-->
DC/OS 入门的正式来源位于[quickstart 仓库](https://github.com/mesosphere/dcos-kubernetes-quickstart)中。
{{% /capture %}}
content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md
+135
View File
@@ -0,0 +1,135 @@
---
title: oVirt
content_template: templates/concept
---
<!--
---
reviewers:
- caesarxuchao
- erictune
title: oVirt
content_template: templates/concept
---
-->
{{% capture overview %}}
<!--
oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
-->
oVirt 是一个虚拟数据中心管理器，可以对多个主机上的多个虚拟机进行强大的管理。
使用 KVM 和 libvirt ，可以将 oVirt 安装在 Fedora、CentOS 或者 Red Hat Enterprise Linux 主机上，以部署和管理您的虚拟数据中心。
{{% /capture %}}
{{% capture body %}}
<!--
## oVirt Cloud Provider Deployment
-->
## oVirt 云驱动的部署
<!--
The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
-->
oVirt 云驱动可以轻松发现新 VM 实例并自动将其添加为 Kubernetes 集群的节点。
目前，包括 Kubernetes 在内，尚无社区支持或预加载的 VM 镜像，但可以在 VM 中 [导入] 或 [安装] Project Atomic（或 Fedora）来 [生成模版]。
包括 Kubernetes 的任何其他 Linux 发行版也可能可行。
<!--
It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
-->
必须在寄宿系统中 [安装 ovirt-guest-agent]，才能将 VM 的 IP 地址和主机名报给 ovirt-engine 并最终报告给 Kubernetes。
<!--
Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
-->
一旦 Kubernetes 模版可用，就可以开始创建可由云驱动发现的 VM。
<!--
[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
-->
[导入]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
[安装]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
[生成模版]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
[安装 ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
<!--
## Using the oVirt Cloud Provider
-->
## 使用 oVirt 云驱动
<!--
The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
-->
oVirt 云驱动需要访问 oVirt REST-API 来收集正确的信息，所需的凭据应在 `ovirt-cloud.conf` 文件中设定：
```none
[connection]
uri = https://localhost:8443/ovirt-engine/api
username = admin@internal
password = admin
```
<!--
In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to Kubernetes:
-->
在同一文件中，可以指定（使用 `filters` 节区）搜索查询，用于辨识要报告给 Kubernetes 的 VM：
```none
[filters]
# Search query used to find nodes
vms = tag=kubernetes
```
<!--
In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to Kubernetes.
-->
在上面的示例中，所有带有 `kubernetes` 标签的虚拟机都将作为节点报告给 Kubernetes。
<!--
The `ovirt-cloud.conf` file then must be specified in kube-controller-manager:
-->
然后必须向 kube-controller-manager 提供 `ovirt-cloud.conf` 文件：
```shell
kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ...
```
<!--
## oVirt Cloud Provider Screencast
-->
## oVirt 云驱动截屏视频
<!--
This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your Kubernetes cluster.
-->
这段简短的截屏视频演示了如何使用 oVirt 云提供商将 VM 动态添加到 Kubernetes 集群。
<!--
[![Screencast](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
-->
[![截屏视频](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
<!--
## Support Level
-->
## 支持级别
<!--
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
-->
IaaS 提供商 | 配置管理 | OS | 联网 | 文件 | 遵从性 | 支持级别
----------------- | ------- | ------ | ---- | ------------------------------------------------- |------| ---------------
oVirt | | | | [文件](/docs/setup/production-environment/on-premises-vm/ovirt/) | | 社区 ([@simon3z](https://github.com/simon3z))
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/_index.md
+9
View File
@@ -0,0 +1,9 @@
---
title: 使用部署工具安装 Kubernetes
weight: 30
---
<!--
title: Installing Kubernetes with deployment tools
weight: 30
-->
content/zh/docs/setup/production-environment/tools/kops.md
+351
View File
@@ -0,0 +1,351 @@
---
title: 使用 Kops 安装 Kubernetes
content_template: templates/concept
weight: 20
---
<!--
---
title: Installing Kubernetes with kops
content_template: templates/concept
weight: 20
---
-->
{{% capture overview %}}
<!--
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
-->
本篇快速入门介绍了如何在 AWS 上轻松安装 Kubernetes 集群。
本篇使用了一个名为 [`kops`](https://github.com/kubernetes/kops) 的工具。
<!--
kops is an opinionated provisioning system:
-->
kops 是一个自用的供应系统：
<!--
* Fully automated installation
* Uses DNS to identify clusters
* Self-healing: everything runs in Auto-Scaling Groups
* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
* Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
-->
* 全自动安装流程
* 使用 DNS 识别集群
* 自我修复：一切都在自动扩展组中运行
* 支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS） - 参考 [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
* 支持高可用 - 参考 [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
* 可以直接提供或者生成 terraform 清单 - 参考 [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
<!--
If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
a building block. kops builds on the kubeadm work.
-->
如果您有不同的观点，您可能更喜欢使用 [kubeadm](/docs/admin/kubeadm/) 作为构建工具来构建自己的集群。kops 建立在 kubeadm 工作的基础上。
{{% /capture %}}
{{% capture body %}}
<!--
## Creating a cluster
-->
## 创建集群
<!--
### (1/5) Install kops
-->
### (1/5) 安装 kops
<!--
#### Requirements
-->
#### 前提条件
<!--
You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
-->
您必须安装 [kubectl](/docs/tasks/tools/install-kubectl/) 才能使 kops 工作。
<!--
#### Installation
-->
#### 安装
<!--
Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
-->
从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops（从源代码构建也很容易）：
<!--
On macOS:
# you can also install using Homebrew
-->
在 macOS 上：
```shell
curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
chmod +x kops-darwin-amd64
mv kops-darwin-amd64 /usr/local/bin/kops
# 您也可以使用 Homebrew 安装 kops
brew update && brew install kops
```
<!--
On Linux:
-->
在 Linux 上：
```shell
wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
chmod +x kops-linux-amd64
mv kops-linux-amd64 /usr/local/bin/kops
```
<!--
### (2/5) Create a route53 domain for your cluster
-->
### (2/5) 为您的集群创建一个 route53 域名
<!--
kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
from clients.
-->
kops 在集群内部都使用 DNS 进行发现操作，因此您可以从客户端访问 kubernetes API 服务器。
<!--
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
and you can reach them without relying on remembering an IP address.
-->
kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这样一来，您就不会再使集群混乱，
可以与同事明确共享集群，并且无需依赖记住 IP 地址即可访问群集。
<!--
You can, and probably should, use subdomains to divide your clusters. As our example we will use
`useast1.dev.example.com`. The API server endpoint will then be `api.useast1.dev.example.com`.
-->
您应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
然后，API 服务器端点域名将为 `api.useast1.dev.example.com`。
<!--
A Route53 hosted zone can serve subdomains. Your hosted zone could be `useast1.dev.example.com`,
but also `dev.example.com` or even `example.com`. kops works with any of these, so typically
you choose for organization reasons (e.g. you are allowed to create records under `dev.example.com`,
but not under `example.com`).
-->
Route53 托管区域可以服务子域名。您的托管区域可能是 `useast1.dev.example.com`，还有 `dev.example.com` 甚至 `example.com`。
kops 可以与以上任何一种配合使用，因此通常您出于组织原因选择不同的托管区域。
例如，允许您在 `dev.example.com` 下创建记录，但不能在 `example.com` 下创建记录。
<!--
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
-->
假设您使用 `dev.example.com` 作为托管区域。您可以使用[正常流程](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 或者使用诸如 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 之类的命令来创建该托管区域。
<!--
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
you would create NS records in `example.com` for `dev`. If it is a root domain name you would configure the NS
records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
-->
然后，您必须在父域名中设置您的 DNS 记录，以便该域名中的记录可以被解析。在这里，您将在 `example.com` 中为 `dev` 创建 DNS 记录。
如果它是根域名，则可以在域名注册机构配置 DNS 记录。例如，您需要在购买 `example.com` 的地方配置 `example.com`。
<!--
This step is easy to mess up (it is the #1 cause of problems!) You can double-check that
your cluster is configured correctly if you have the dig tool by running:
-->
这一步很容易搞砸（这是问题的第一大原因！）
如果您安装了 dig 工具，则可以通过运行以下步骤再次检查集群是否配置正确：
<!--
`dig NS dev.example.com`
-->
`dig DNS dev.example.com`
<!--
You should see the 4 NS records that Route53 assigned your hosted zone.
-->
您应该看到 Route53 分配了您的托管区域的 4 条 DNS 记录。
<!--
### (3/5) Create an S3 bucket to store your clusters state
-->
### (3/5) 创建一个 S3 存储桶来存储集群状态
<!--
kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters
that you have created, along with their configuration, the keys they are using etc. This information is stored
in an S3 bucket. S3 permissions are used to control access to the bucket.
-->
kops 使您即使在安装后也可以管理集群。为此，它必须跟踪已创建的集群及其配置、所使用的密钥等。
此信息存储在 S3 存储桶中。S3 权限用于控制对存储桶的访问。
<!--
Multiple clusters can use the same S3 bucket, and you can share an S3 bucket between your colleagues that
administer the same clusters - this is much easier than passing around kubecfg files. But anyone with access
to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
the operations team.
-->
多个集群可以使用同一 S3 存储桶，并且您可以在管理同一集群的同事之间共享一个 S3 存储桶 - 这比传递 kubecfg 文件容易得多。
但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，因此您不想在运营团队之外共享它。
<!--
So typically you have one S3 bucket for each ops team (and often the name will correspond
to the name of the hosted zone above!)
-->
因此，通常每个运维团队都有一个 S3 存储桶（而且名称通常对应于上面托管区域的名称！）
<!--
In our example, we chose `dev.example.com` as our hosted zone, so let's pick `clusters.dev.example.com` as
the S3 bucket name.
-->
在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此让我们选择 `clusters.dev.example.com` 作为 S3 存储桶名称。
<!--
* Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
-->
* 导出 `AWS_PROFILE` 文件（如果您需要选择一个配置文件用来使 AWS CLI 正常工作）
<!--
* Create the S3 bucket using `aws s3 mb s3://clusters.dev.example.com`
-->
* 使用 `aws s3 mb s3://clusters.dev.example.com` 创建 S3 存储桶
<!--
* You can `export KOPS_STATE_STORE=s3://clusters.dev.example.com` and then kops will use this location by default.
We suggest putting this in your bash profile or similar.
-->
* 您可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，然后 kops 将默认使用此位置。
我们建议将其放入您的 bash profile 文件或类似文件中。
<!--
### (4/5) Build your cluster configuration
-->
### (4/5) 建立您的集群配置
<!--
Run "kops create cluster" to create your cluster configuration:
-->
运行 "kops create cluster" 以创建您的集群配置：
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
<!--
kops will create the configuration for your cluster. Note that it _only_ creates the configuration, it does
not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`. This
give you an opportunity to review the configuration or change it.
-->
kops 将为您的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 - 您将在下一步中使用 `kops update cluster` 进行配置。
这使您有机会查看配置或进行更改。
<!--
It prints commands you can use to explore further:
-->
它打印出可用于进一步探索的命令：
<!--
* List your clusters with: `kops get cluster`
* Edit this cluster with: `kops edit cluster useast1.dev.example.com`
* Edit your node instance group: `kops edit ig --name=useast1.dev.example.com nodes`
* Edit your master instance group: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
-->
* 使用以下命令列出集群：`kops get cluster`
* 使用以下命令编辑该集群：`kops edit cluster useast1.dev.example.com`
* 使用以下命令编辑您的节点实例组：`kops edit ig --name = useast1.dev.example.com nodes`
* 使用以下命令编辑您的主实例组：`kops edit ig --name = useast1.dev.example.com master-us-east-1c`
<!--
If this is your first time using kops, do spend a few minutes to try those out! An instance group is a
set of instances, which will be registered as kubernetes nodes. On AWS this is implemented via auto-scaling-groups.
You can have several instance groups, for example if you wanted nodes that are a mix of spot and on-demand instances, or
GPU and non-GPU instances.
-->
如果这是您第一次使用 kops，请花几分钟尝试一下！ 实例组是一组实例，将被注册为 kubernetes 节点。
在 AWS 上，这是通过 auto-scaling-groups 实现的。您可以有多个实例组，例如，如果您想要的是混合实例和按需实例的节点，或者
GPU 和非 GPU 实例。
<!--
### (5/5) Create the cluster in AWS
-->
### (5/5) 在 AWS 中创建集群
<!--
Run "kops update cluster" to create your cluster in AWS:
-->
运行 "kops update cluster" 以在 AWS 中创建集群：
`kops update cluster useast1.dev.example.com --yes`
<!--
That takes a few seconds to run, but then your cluster will likely take a few minutes to actually be ready.
`kops update cluster` will be the tool you'll use whenever you change the configuration of your cluster; it
applies the changes you have made to the configuration to your cluster - reconfiguring AWS or kubernetes as needed.
-->
这需要几秒钟的时间才能运行，但实际上集群可能需要几分钟才能准备就绪。每当更改集群配置时，都会使用 `kops update cluster` 工具。
它将对配置进行的更改应用于您的集群 - 根据需要重新配置 AWS 或者 kubernetes。
<!--
For example, after you `kops edit ig nodes`, then `kops update cluster --yes` to apply your configuration, and
sometimes you will also have to `kops rolling-update cluster` to roll out the configuration immediately.
-->
例如，在您运行 `kops edit ig nodes` 之后，然后运行 `kops update cluster --yes` 应用您的配置，有时您还必须运行 `kops rolling-update cluster` 立即回滚更新配置。
<!--
Without `--yes`, `kops update cluster` will show you a preview of what it is going to do. This is handy
for production clusters!
-->
如果没有 `--yes` 参数，`kops update cluster` 操作将向您显示其操作的预览效果。这对于生产集群很方便！
<!--
### Explore other add-ons
-->
### 探索其他附加组件
<!--
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp; control of your Kubernetes cluster.
-->
请参阅[附加组件列表](/docs/concepts/cluster-administration/addons/)探索其他附加组件，包括用于 Kubernetes 集群的日志记录、监视、网络策略、可视化和控制的工具。
<!--
## Cleanup
-->
## 清理
<!--
* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
-->
* 删除集群：`kops delete cluster useast1.dev.example.com --yes`
<!--
## Feedback
-->
## 反馈
<!--
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
-->
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
-->
* 了解有关 Kubernetes 的 [concepts](/docs/concepts/) 和 [`kubectl`](/docs/user-guide/kubectl-overview/) 的更多信息。
* 了解 `kops` [高级用法](https://github.com/kubernetes/kops)。
* 请参阅 `kops` [文档](https://github.com/kubernetes/kops) 获取教程、最佳做法和高级配置选项。
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/_index.md
+9
View File
@@ -0,0 +1,9 @@
---
title: "使用 kubeadm 引导集群"
weight: 10
---
<!--
title: "Bootstrapping clusters with kubeadm"
weight: 10
-->
content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+138
View File
@@ -0,0 +1,138 @@
---
title: 使用 kubeadm 定制控制平面配置
content_template: templates/concept
weight: 40
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Customizing control plane configuration with kubeadm
content_template: templates/concept
weight: 40
---
-->
{{% capture overview %}}
{{< feature-state for_k8s_version="1.12" state="stable" >}}
<!--
The kubeadm `ClusterConfiguration` object exposes the field `extraArgs` that can override the default flags passed to control plane
components such as the APIServer, ControllerManager and Scheduler. The components are defined using the following fields:
-->
kubeadm `ClusterConfiguration` 对象公开了 `extraArgs` 字段，它可以覆盖传递给控制平面组件（如 APIServer、ControllerManager 和 Scheduler）的默认参数。各组件配置使用如下字段定义：
- `apiServer`
- `controllerManager`
- `scheduler`
<!--
The `extraArgs` field consist of `key: value` pairs. To override a flag for a control plane component:
-->
`extraArgs` 字段由 `key: value` 对组成。
要覆盖控制平面组件的参数:
<!--
1. Add the appropriate field to your configuration.
2. Add the flags to override to the field.
3. Run `kubeadm init` with `--config <YOUR CONFIG YAML>`.
-->
1. 将适当的字段添加到配置中。
2. 向字段添加要覆盖的参数值。
3. 用 `--config <YOUR CONFIG YAML>` 运行 `kubeadm init`。
<!--
For more details on each field in the configuration you can navigate to our
[API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration).
-->
有关配置中的每个字段的详细信息，您可以导航到我们的 [API 参考页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration)。
{{< note >}}
<!--
You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults` and saving the output to a file of your choice.
-->
您可以通过运行 `kubeadm config print init-defaults` 并将输出保存到您选择的文件中，以默认值形式生成 `ClusterConfiguration` 对象。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!--
## APIServer flags
-->
## APIServer 参数
<!--
For details, see the [reference documentation for kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/).
-->
有关详细信息，请参阅 [kube-apiserver 参考文档](/docs/reference/command-line-tools-reference/kube-apiserver/)。
<!--
Example usage:
-->
使用示例：
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
extraArgs:
advertise-address: 192.168.0.103
anonymous-auth: "false"
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
```
<!--
## ControllerManager flags
-->
## ControllerManager 参数
<!--
For details, see the [reference documentation for kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
-->
有关详细信息，请参阅 [kube-controller-manager 参考文档](/docs/reference/command-line-tools-reference/kube-controller-manager/)。
<!--
Example usage:
-->
使用示例：
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
bind-address: 0.0.0.0
deployment-controller-sync-period: "50"
```
<!--
## Scheduler flags
-->
## Scheduler 参数
<!--
For details, see the [reference documentation for kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
-->
有关详细信息，请参阅 [kube-scheduler 参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/)。
<!--
Example usage:
-->
使用示例：
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
extraArgs:
address: 0.0.0.0
config: /home/johndoe/schedconfig.yaml
kubeconfig: /home/johndoe/kubeconfig.yaml
```
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+140
View File
@@ -0,0 +1,140 @@
---
reviewers:
- sig-cluster-lifecycle
title: 高可用拓扑选项
content_template: templates/concept
weight: 50
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Options for Highly Available topology
content_template: templates/concept
weight: 50
---
-->
{{% capture overview %}}
<!--
This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
-->
本页面介绍了配置高可用（HA） Kubernetes 集群拓扑的两个选项。
<!--
You can set up an HA cluster:
-->
您可以设置 HA 集群：
<!--
- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes- With external etcd nodes, where etcd runs on separate nodes from the control plane
-->
- 使用堆叠（stacked）控制平面节点，其中 etcd 节点与控制平面节点共存
- 使用外部 etcd 节点，其中 etcd 在与控制平面不同的节点上运行
<!--
You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
-->
在设置 HA 集群之前，您应该仔细考虑每种拓扑的优缺点。
{{% /capture %}}
{{% capture body %}}
<!--
## Stacked etcd topology
-->
## 堆叠（Stacked） etcd 拓扑
<!--
A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributeddata storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by kubeadm that run control plane components.
-->
堆叠（Stacked） HA 集群是一种这样的[拓扑](https://en.wikipedia.org/wiki/Network_topology)，其中 etcd 分布式数据存储集群堆叠在 kubeadm 管理的控制平面节点上，作为控制平面的一个组件运行。
<!--
Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
-->
每个控制平面节点运行 `kube-apiserver`，`kube-scheduler` 和 `kube-controller-manager` 实例。
<!--
The `kube-apiserver` is exposed to worker nodes using a load balancer.
-->
`kube-apiserver` 使用负载均衡器暴露给工作节点。
<!--
Each control plane node creates a local etcd member and this etcd member communicates only with
the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
and `kube-scheduler` instances.
-->
每个控制平面节点创建一个本地 etcd 成员（member），这个 etcd 成员只与该节点的 `kube-apiserver` 通信。这同样适用于本地 `kube-controller-manager` 和 `kube-scheduler` 实例。
<!--
This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster with external etcd nodes, and simpler to manage for replication.
-->
这种拓扑将控制平面和 etcd 成员耦合在同一节点上。相对使用外部 etcd 集群，设置起来更简单，而且更易于副本管理。
<!--
However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a controlplane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.
-->
然而，堆叠集群存在耦合失败的风险。如果一个节点发生故障，则 etcd 成员和控制平面实例都将丢失，并且冗余会受到影响。您可以通过添加更多控制平面节点来降低此风险。
<!--
You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
-->
因此，您应该为 HA 集群运行至少三个堆叠的控制平面节点。
<!--
This is the default topology in kubeadm. A local etcd member is created automatically
on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
-->
这是 kubeadm 中的默认拓扑。当使用 `kubeadm init` 和 `kubeadm join --control-plane` 时，在控制平面节点上会自动创建本地 etcd 成员。
<!--
![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
-->
！[堆叠的 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
<!--
## External etcd topology
-->
## 外部 etcd 拓扑
<!--
An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.
-->
具有外部 etcd 的 HA 集群是一种这样的[拓扑](https://en.wikipedia.org/wiki/Network_topology)，其中 etcd 分布式数据存储集群在独立于控制平面节点的其他节点上运行。
<!--
Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node.
-->
就像堆叠的 etcd 拓扑一样，外部 etcd 拓扑中的每个控制平面节点都运行 `kube-apiserver`，`kube-scheduler` 和 `kube-controller-manager` 实例。同样， `kube-apiserver` 使用负载均衡器暴露给工作节点。但是，etcd 成员在不同的主机上运行，​​每个 etcd 主机与每个控制平面节点的 `kube-apiserver` 通信。
<!--
This topology decouples the control plane and etcd member. It therefore provides an HA setup wherelosing a control plane instance or an etcd member has less impact and does not affectthe cluster redundancy as much as the stacked HA topology.
-->
这种拓扑结构解耦了控制平面和 etcd 成员。因此，它提供了一种 HA 设置，其中失去控制平面实例或者 etcd 成员的影响较小，并且不会像堆叠的 HA 拓扑那样影响集群冗余。
<!--
However, this topology requires twice the number of hosts as the stacked HA topology.
-->
但是，此拓扑需要两倍于堆叠 HA 拓扑的主机数量。
<!--
A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.
-->
具有此拓扑的 HA 集群至少需要三个用于控制平面节点的主机和三个用于 etcd 节点的主机。
<!--
![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
-->
！[外部 etcd 拓扑](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
{{% /capture %}}
{{% capture whatsnext %}}
<!--
- [Set up a highly available cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
-->
- [使用 kubeadm 设置高可用集群](/docs/setup/production-environment/tools/kubeadm/high-availability/)
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/high-availability.md
+727
View File
@@ -0,0 +1,727 @@
---
reviewers:
- sig-cluster-lifecycle
title: 利用 kubeadm 创建高可用集群
content_template: templates/task
weight: 60
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Creating Highly Available clusters with kubeadm
content_template: templates/task
weight: 60
---
-->
{{% capture overview %}}
<!--
This page explains two different approaches to setting up a highly available Kubernetes
cluster using kubeadm:
- With stacked control plane nodes. This approach requires less infrastructure. The etcd members
and control plane nodes are co-located.
- With an external etcd cluster. This approach requires more infrastructure. The
control plane nodes and etcd members are separated.
-->
本文讲述了使用 kubeadm 设置一个高可用的 Kubernetes 集群的两种不同方式：
- 使用堆控制平面节点。这种方法所需基础设施较少。etcd 成员和控制平面节点位于同一位置。
- 使用外部集群。这种方法所需基础设施较多。控制平面的节点和 etcd 成员是分开的。
<!--
Before proceeding, you should carefully consider which approach best meets the needs of your applications
and environment. [This comparison topic](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each.
If you encounter issues with setting up the HA cluster, please provide us with feedback
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
-->
在下一步之前，您应该仔细考虑哪种方法更好的满足您的应用程序和环境的需求。 [这是对比文档](/docs/setup/production-environment/tools/kubeadm/ha-topology/) 讲述了每种方法的优缺点。
如果您在安装 HA 集群时遇到问题，请在 kubeadm [问题跟踪](https://github.com/kubernetes/kubeadm/issues/new)里向我们提供反馈。
您也可以阅读 [升级文件](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15)。
{{< caution >}}
<!--
This page does not address running your cluster on a cloud provider. In a cloud
environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
-->
这篇文档没有讲述在云提供商上运行集群的问题。在云环境中，此处记录的方法不适用于类型为 LoadBalancer 的服务对象，或者具有动态的 PersistentVolumes。
{{< /caution >}}
{{% /capture %}}
{{% capture prerequisites %}}
<!--
For both methods you need this infrastructure:
- Three machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for
the masters
- Three machines that meet [kubeadm's minimum
requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
- Full network connectivity between all machines in the cluster (public or
private network)
- sudo privileges on all machines
- SSH access from one device to all nodes in the system
- `kubeadm` and `kubelet` installed on all machines. `kubectl` is optional.
-->
对于这两种方法，您都需要以下基础设施：
- 配置三台机器[kubeadm 的最低要求](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)给主节点
- 配置三台机器 [kubeadm 的最低要求](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给工作节点
- 在集群中，所有计算机之间的完全网络连接（公网或私网）
- 所有机器上的 sudo 权限
- 每台设备对系统中所有节点的 SSH 访问
- 在所有机器上安装 `kubeadm` 和 `kubelet`，`kubectl` 是可选的。
<!--
For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-->
仅对于外部 etcd 集群来说，您还需要：
- 给 etcd 成员使用的另外三台机器
{{% /capture %}}
{{% capture steps %}}
<!-- ## First steps for both methods -->
## 这两种方法的第一步
<!-- ### Create load balancer for kube-apiserver -->
### 为 kube-apiserver 创建负载均衡器
<!--
There are many configurations for load balancers. The following example is only one
option. Your cluster requirements may need a different configuration.
-->
{{< note >}}
**注意**：使用负载均衡器需要许多配置。您的集群搭建可能需要不同的配置。下面的例子只是其中的一方面配置。
{{< /note >}}
<!--
1. Create a kube-apiserver load balancer with a name that resolves to DNS.
- In a cloud environment you should place your control plane nodes behind a TCP
forwarding load balancer. This load balancer distributes traffic to all
healthy control plane nodes in its target list. The health check for
an apiserver is a TCP check on the port the kube-apiserver listens on
(default value `:6443`).
- It is not recommended to use an IP address directly in a cloud environment.
- The load balancer must be able to communicate with all control plane nodes
on the apiserver port. It must also allow incoming traffic on its
listening port.
- [HAProxy](http://www.haproxy.org/) can be used as a load balancer.
- Make sure the address of the load balancer always matches
the address of kubeadm's `ControlPlaneEndpoint`.
-->
1. 创建一个名为 kube-apiserver 的负载均衡器解析 DNS。
- 在云环境中，应该将控制平面节点放置在 TCP 后面转发负载平衡。 该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。健康检查 apiserver 是在 kube-apiserver 监听端口(默认值 `:6443`)上的一个 TCP 检查。
- 不建议在云环境中直接使用 IP 地址。
- 负载均衡器必须能够在 apiserver 端口上与所有控制平面节点通信。它还必须允许其监听端口的传入流量。
- [HA代理](http://www.haproxy.org/)可以被用来做一个负载均衡器。
- 确保负载均衡器的地址始终匹配 kubeadm 的 `ControlPlaneEndpoint` 地址。
<!--
1. Add the first control plane nodes to the load balancer and test the
connection:
```sh
nc -v LOAD_BALANCER_IP PORT
```
- A connection refused error is expected because the apiserver is not yet
running. A timeout, however, means the load balancer cannot communicate
with the control plane node. If a timeout occurs, reconfigure the load
balancer to communicate with the control plane node.
1. Add the remaining control plane nodes to the load balancer target group.
-->
1. 添加第一个控制平面节点到负载均衡器并测试连接：
```sh
nc -v LOAD_BALANCER_IP PORT
```
- 由于 apiserver 尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。
如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。
1. 将其余控制平面节点添加到负载均衡器目标组。
<!-- ## Stacked control plane and etcd nodes -->
## 使用堆控制平面和 etcd 节点
<!-- ### Steps for the first control plane node -->
### 控制平面节点的第一步
<!--
1. Initialize the control plane:
```sh
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
```
- You can use the `--kubernetes-version` flag to set the Kubernetes version to use.
It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
- The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer.
- The `--upload-certs` flag is used to upload the certificates that should be shared
across all the control-plane instances to the cluster. If instead, you prefer to copy certs across
control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual
certificate distribution](#manual-certs) section bellow.
-->
1. 初始化控制平面：
```sh
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
```
- 您可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
- 这个 `--control-plane-endpoint` 标志应该被设置成负载均衡器的地址或 DNS 和端口。
- 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化
工具复制证书，请删除此标志并参考如下部分[证书分配手册](#manual-certs)。
{{< note >}}
<!--
The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
-->
**注意**：标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，因此如果您要使用[kubeadm 配置](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)，您必须在相应的配置文件（位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
{{< /note >}}
{{< note >}}
<!--
Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
-->
**注意**：一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考 [CNI 网络文档](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者您可以使用 kubeadm 配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
{{< note >}}
<!--
After the command completes you should see something like so:
```sh
...
You can now join any number of control-plane node by running the following command on each as a root:
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
```
- Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
- When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
are encrypted and uploaded in the `kubeadm-certs` Secret.
- To re-upload the certificates and generate a new decryption key, use the following command on a control plane
node that is already joined to the cluster:
```sh
sudo kubeadm init phase upload-certs --upload-certs
```
- You can also specify a custom `--certificate-key` during `init` that can later be used by `join`.
To generate such a key you can use the following command:
```sh
kubeadm alpha certs certificate-key
```
-->
命令完成后，您应该会看到类似以下内容：
```sh
...
现在，您可以通过在根目录上运行以下命令来加入任意数量的控制平面节点：
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
请注意，证书密钥可以访问集群内敏感数据，请保密！
为了安全起见，将在两个小时内删除上传的证书； 如有必要，您可以使用 kubeadm 初始化上传证书阶段，之后重新加载证书。
然后，您可以通过在根目录上运行以下命令来加入任意数量的工作节点：
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
```
- 将此输出复制到文本文件。 稍后您将需要它来将控制平面节点和辅助节点加入集群。
- 当 `--upload-certs` 与 `kubeadm init` 一起使用时，主控制平面的证书被加密并上传到 `kubeadm-certs` 密钥中。
- 要重新上传证书并生成新的解密密钥，请在已加入集群节点的控制平面上使用以下命令：
```sh
sudo kubeadm init phase upload-certs --upload-certs
```
- 您还可以在 `init` 期间指定自定义的 `--certificate-key`，以后可以由 `join` 使用。
要生成这样的密钥，可以使用以下命令：
```sh
kubeadm alpha certs certificate-key
```
{{< note >}}
<!--
The `kubeadm-certs` Secret and decryption key expire after two hours.
-->
**注意**： `kubeadm-certs` 密钥和解密密钥会在两个小时后失效。
{{< /note >}}
{{< caution >}}
<!--
As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
-->
正如命令输出中所述，证书密钥可访问群集敏感数据，并将其保密！
{{< /caution >}}
<!--
1. Apply the CNI plugin of your choice:
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
In this example we are using Weave Net:
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
1. Type the following and watch the pods of the control plane components get started:
```sh
kubectl get pod -n kube-system -w
```
-->
1. 应用您选择的 CNI 插件：
[请遵循以下指示](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) 安装 CNI 提供程序。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod CIDR 相对应。
在此示例中，我们使用 Weave Net：
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
1. 输入以下内容，并查看 pods 的控制平面组件启动：
```sh
kubectl get pod -n kube-system -w
```
<!--
### Steps for the rest of the control plane nodes
-->
### 其余控制平面节点的步骤
{{< note >}}
<!--
Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel.
Prior to this version, you must join new control plane nodes sequentially, only after
the first node has finished initializing.
-->
**注意**：从 kubeadm 1.15 版本开始，您可以并行加入多个控制平面节点。
在此版本之前，您必须在第一个节点初始化后才能依序的增加新的控制平面节点。
{{< /note >}}
<!--
For each additional control plane node you should:
1. Execute the join command that was previously given to you by the `kubeadm init` output on the first node.
It should look something like this:
```sh
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
```
- The `--control-plane` flag tells `kubeadm join` to create a new control plane.
- The `--certificate-key ...` will cause the control plane certificates to be downloaded
from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.
-->
对于每个其他控制平面节点，您应该：
1. 执行先前由第一个节点上的 `kubeadm init` 输出提供给您的 join 命令。
它看起来应该像这样：
```sh
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
```
- 这个 `--control-plane` 命令通知 `kubeadm join` 创建一个新的控制平面。
- `--certificate-key ...` 将导致从集群中的 `kubeadm-certs` 秘钥下载控制平面证书并使用给定的密钥进行解密。
<!--
## External etcd nodes
Setting up a cluster with external etcd nodes is similar to the procedure used for stacked etcd
with the exception that you should setup etcd first, and you should pass the etcd information
in the kubeadm config file.
-->
## 外部 etcd 节点
使用外部 etcd 节点设置集群类似于用于堆叠 etcd 的过程，
不同之处在于您应该首先设置 etcd，并在 kubeadm 配置文件中传递 etcd 信息。
<!--
### Set up the etcd cluster
1. Follow [these instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster.
1. Setup SSH as described [here](#manual-certs).
1. Copy the following files from any etcd node in the cluster to the first control plane node:
```sh
export CONTROL_PLANE="ubuntu@10.0.0.7"
scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
```
- Replace the value of `CONTROL_PLANE` with the `user@host` of the first control plane machine.
-->
### 设置 ectd 集群
1. 按照 [这些指示](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 去设置 etcd 集群。
1. 设置 SSH 在 [这](#manual-certs)描述。
1. 将以下文件从集群中的任何 etcd 节点复制到第一个控制平面节点：
```sh
export CONTROL_PLANE="ubuntu@10.0.0.7"
scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
```
- 用第一台控制平面机的 `user@host` 替换 `CONTROL_PLANE` 的值。
<!--
### Set up the first control plane node
1. Create a file called `kubeadm-config.yaml` with the following contents:
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
-->
### 设置第一个控制平面节点
1. 用以下内容创建一个名为 `kubeadm-config.yaml` 的文件：
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
{{< note >}}
<!--
The difference between stacked etcd and external etcd here is that the external etcd setup requires
a configuration file with the etcd endpoints under the `external` object for `etcd`.
In the case of the stacked etcd topology this is managed automatically.
-->
这里堆 etcd 和外部 etcd 之前的区别在于设置外部 etcd 需要一个 `etcd` 的 `external` 对象下带有 etcd 端点的配置文件。
如果是堆 etcd 技术，是自动管理的。
{{< /note >}}
<!--
- Replace the following variables in the config template with the appropriate values for your cluster:
- `LOAD_BALANCER_DNS`
- `LOAD_BALANCER_PORT`
- `ETCD_0_IP`
- `ETCD_1_IP`
- `ETCD_2_IP`
The following steps are similar to the stacked etcd setup:
1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node.
1. Write the output join commands that are returned to a text file for later use.
1. Apply the CNI plugin of your choice. The given example is for Weave Net:
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
-->
- 在您的集群中，将配置模板中的以下变量替换为适当值：
- `LOAD_BALANCER_DNS`
- `LOAD_BALANCER_PORT`
- `ETCD_0_IP`
- `ETCD_1_IP`
- `ETCD_2_IP`
以下的步骤与设置堆集群是相似的：
1. 在节点上运行 `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` 命令。
1. 编写输出联接命令，这些命令将返回到文本文件以供以后使用。
1. 应用您选择的 CNI 插件。 给定以下示例适用于 Weave Net：
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
<!--
### Steps for the rest of the control plane nodes
The steps are the same as for the stacked etcd setup:
- Make sure the first control plane node is fully initialized.
- Join each control plane node with the join command you saved to a text file. It's recommended
to join the control plane nodes one at a time.
- Don't forget that the decryption key from `--certificate-key` expires after two hours, by default.
-->
### 其他控制平面节点的步骤
步骤与设置堆 etcd 相同：
- 确保第一个控制平面节点已完全初始化。
- 使用保存到文本文件的连接命令将每个控制平面节点连接在一起。建议一次加入一个控制平面节点。
- 不要忘记默认情况下，`--certificate-key` 中的解密秘钥会在两个小时后过期。
<!-- ## Common tasks after bootstrapping control plane -->
## 列举控制平面之后的常见任务
<!-- ### Install workers -->
### 安装工作节点
<!--
Worker nodes can be joined to the cluster with the command you stored previously
as the output from the `kubeadm init` command:
```sh
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
```
-->
您可以使用之前存储的命令将工作节点加入集群中
作为 `kubeadm init` 命令的输出：
```sh
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
```
<!--
## Manual certificate distribution {#manual-certs}
If you choose to not use `kubeadm init` with the `--upload-certs` flag this means that
you are going to have to manually copy the certificates from the primary control plane node to the
joining control plane nodes.
There are many ways to do this. In the following example we are using `ssh` and `scp`:
SSH is required if you want to control all nodes from a single machine.
-->
## 手动证书分发 {#manual-certs}
如果您选择不将 `kubeadm init` 与 `--upload-certs` 命令一起使用，
则意味着您将必须手动将证书从主控制平面节点复制到
将要加入的控制平面节点上。
有许多方法可以实现这种操作。在下面的例子中我们使用 `ssh` 和 `scp`：
如果要在单独的一台计算机控制所有节点，则需要 SSH。
<!--
1. Enable ssh-agent on your main device that has access to all other nodes in
the system:
```
eval $(ssh-agent)
```
1. Add your SSH identity to the session:
```
ssh-add ~/.ssh/path_to_private_key
```
1. SSH between nodes to check that the connection is working correctly.
- When you SSH to any node, make sure to add the `-A` flag:
```
ssh -A 10.0.0.7
```
- When using sudo on any node, make sure to preserve the environment so SSH
forwarding works:
```
sudo -E -s
```
-->
1. 在您的主设备上启动 ssh-agent，要求该设备能访问系统中的所有其他节点：
```
eval $(ssh-agent)
```
1. 将 SSH 身份添加到会话中：
```
ssh-add ~/.ssh/path_to_private_key
```
1. 检查节点间的 SSH 以确保连接是正常运行的
- SSH 到任何节点时，请确保添加 `-A` 标志：
```
ssh -A 10.0.0.7
```
- 当在任何节点上使用 sudo 时，请确保环境完善，以便使用 SSH
转发任务：
```
sudo -E -s
```
<!--
1. After configuring SSH on all the nodes you should run the following script on the first control plane node after
running `kubeadm init`. This script will copy the certificates from the first control plane node to the other
control plane nodes:
In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
other control plane nodes.
```sh
USER=ubuntu # customizable
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
done
```
-->
1. 在所有节点上配置 SSH 之后，您应该在运行过 `kubeadm init` 命令的第一个控制平面节点上运行以下脚本。
该脚本会将证书从第一个控制平面节点复制到另一个控制平面节点：
在以下示例中，用其他控制平面节点的 IP 地址替换 `CONTROL_PLANE_IPS`。
```sh
USER=ubuntu # 可自己设置
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
done
```
{{< caution >}}
<!--
Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates
with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake,
the creation of additional nodes could fail due to a lack of required SANs.
-->
只需要复制上面列表中的证书。kubeadm 将负责生成其余证书以及加入控制平面实例所需的 SAN。
如果您错误地复制了所有证书，由于缺少所需的 SAN，创建其他节点可能会失败。
{{< /caution >}}
<!--
1. Then on each joining control plane node you have to run the following script before running `kubeadm join`.
This script will move the previously copied certificates from the home directory to `/etc/kubernetes/pki`:
```sh
USER=ubuntu # customizable
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
```
-->
1. 然后，在每个连接控制平面节点上，您必须先运行以下脚本，然后再运行 `kubeadm join`。
该脚本会将先前复制的证书从主目录移动到 `/etc/kubernetes/pki`：
```sh
USER=ubuntu # 可自己设置
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
```
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+381
View File
@@ -0,0 +1,381 @@
---
reviewers:
- sig-cluster-lifecycle
title: 使用 kubeadm 配置集群中的每个 kubelet
content_template: templates/concept
weight: 80
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Configuring each kubelet in your cluster using kubeadm
content_template: templates/concept
weight: 80
---
-->
{{% capture overview %}}
{{< feature-state for_k8s_version="1.11" state="stable" >}}
<!--
The lifecycle of the kubeadm CLI tool is decoupled from the
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
initialized or upgraded, where as the kubelet is always running in the background.
Since the kubelet is a daemon, it needs to be maintained by some kind of a init
system or service manager. When the kubelet is installed using DEBs or RPMs,
systemd is configured to manage the kubelet. You can use a different service
manager instead, but you need to configure it manually.
Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while
other configuration aspects need to be set on a per-kubelet basis, to accommodate the different
characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration
of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
kubelet configurations centrally](#configure-kubelets-using-kubeadm).
-->
kubeadm CLI 工具的生命周期与 [kubelet](/docs/reference/command-line-tools-reference/kubelet)解耦，它是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
当 Kubernetes 初始化或升级时，kubeadm CLI 工具由用户执行，而 kubelet 始终在后台运行。
由于kubelet是守护程序，因此需要通过某种初始化系统或服务管理器进行维护。
当使用 DEB 或 RPM 安装 kubelet 时，配置系统去管理 kubelet。
您可以改用其他服务管理器，但需要手动地配置。
集群中涉及的所有 kubelet 的一些配置细节都必须相同，而其他配置方面则需要基于每个 kubelet 进行设置，以适应给定机器的不同特性，例如操作系统、存储和网络。
您可以手动地管理 kubelet 的配置，但是 [kubeadm 现在提供一种 `KubeletConfiguration` API 类型，用于集中管理 kubelet 的配置](#configure-kubelets-using-kubeadm)。
{{% /capture %}}
{{% capture body %}}
<!--
## Kubelet configuration patterns
The following sections describe patterns to kubelet configuration that are simplified by
using kubeadm, rather than managing the kubelet configuration for each Node manually.
-->
## Kubelet 配置模式
以下各节讲述了通过使用 kubeadm 简化 kubelet 配置模式，而不是在每个节点上手动地管理 kubelet 配置。
<!--
### Propagating cluster-level configuration to each kubelet
You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join`
commands. Interesting examples include using a different CRI runtime or setting the default subnet
used by services.
If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass
the `--service-cidr` parameter to kubeadm:
```bash
kubeadm init --service-cidr 10.96.0.0/12
```
Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used
by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
that can configure most parameters in the kubelet and push out this configuration to each running
kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as
a list of values to a camelCased key, illustrated by the following example:
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10
```
-->
### 将集群级配置传播到每个 kubelet 中
您可以通过使用 `kubeadm init` 和 `kubeadm join` 命令为 kubelet 提供默认值。
有趣的示例包括使用其他 CRI 运行时或通过服务器设置不同的默认子网。
如果您想使用子网 `10.96.0.0/12` 作为默认的服务，您可以给 kubeadm 传递 `--service-cidr` 参数：
```bash
kubeadm init --service-cidr 10.96.0.0/12
```
现在，可以从该子网分配服务的虚拟 IP。
您还需要通过 kubelet 使用 `--cluster-dns` 标志设置 DNS 地址。
在集群中的每个管理器和节点上的 kubelet 的设置需要相同。
kubelet 提供了一个版本化的结构化 API 对象，该对象可以配置 kubelet 中的大多数参数，并将此配置推送到集群中正在运行的每个 kubelet 上。
此对象被称为 **kubelet 的配置组件**。
该配置组件允许用户指定标志，例如用骆峰值代表集群的 DNS IP 地址，如下所示：
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10
```
有关组件配置的更多详细信息，亲参阅 [本节](#configure-kubelets-using-kubeadm)。
<!--
### Providing instance-specific configuration details
Some hosts require specific kubelet configurations, due to differences in hardware, operating system,
networking, or other host-specific parameters. The following list provides a few examples.
- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
configuration flag, may differ among operating systems, or depending on whether you are using
`systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
is configured incorrectly.
- The Node API object `.metadata.name` is set to the machine's hostname by default,
unless you are using a cloud provider. You can use the `--hostname-override` flag to override the
default behavior if you need to specify a Node name different from the machine's hostname.
- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime,
but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure
the health of the kubelet.
- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet.
For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you
are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI
endpoint using the `--container-runtime-path-endpoint=<path>`.
You can specify these flags by configuring an individual kubelet's configuration in your service manager,
such as systemd.
-->
### 提供指定实例的详细配置信息
由于硬件、操作系统、网络或者其他主机特定参数的差异。某些主机需要特定的 kubelet 配置。
以下列表提供了一些示例。
- 由 kubelet 配置标志 `--resolv-confkubelet` 指定的 DNS 解析文件的路径在操作系统之间可能有所不同，
它取决于您是否使用 `systemd-resolved`。
如果此路径错误，则在其 kubelet 配置错误的节点上 DNS 解析也将失败。
- 除非您使用云提供商，否则默认情况下，Node API 对象 `.metadata.name` 被设置为计算机的主机名。
如果您需要指定一个节点的名称与机器的主机名不同，您可以是使用 `--hostname-override` 标志覆盖默认操作。
- 当前，kubelet 无法自动检测 CRI 运行时使用的 cgroup 驱动程序，
但是值 `--cgroup-driver` 必须与 CRI 运行时使用的 cgroup 驱动程序匹配，以确保 kubelet 的健康运行状况。
- 根据您集群使用的 CRI 运行时，您可能需要为 kubelet 指定不同的标志。
例如，当使用 Docker 时，你要需要指定标志如 `--network-plugin=cni`，但是如果您使用的是外部运行时，
则需要指定 `--container-runtime=remote` 并使用 `--container-runtime-path-endpoint=<path>` 指定 CRI端点。
您可以在服务管理器（例如系统）中通过对单个的 kubelet 配置来指定这些标志。
<!--
## Configure kubelets using kubeadm
It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
see all the default values for this structure.
Also have a look at the [API reference for the
kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
for more information on the individual fields.
-->
## 使用 kubeadm 配置 kubelet
如果自定义的 `KubeletConfiguration` API 对象使用像 `kubeadm ... --config some-config-file.yaml` 这样的配置文件进行传递，则可以配置 kubeadm 启动的 kubelet。
通过调用 `kubeadm config print init-defaults --component-configs KubeletConfiguration` 您可以看到此结构中的所有默认值。
也可以阅读 [kubelet 配置组件的 API 参考](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)来获取有关各个字段的更多信息。
<!--
### Workflow when using `kubeadm init`
When you call `kubeadm init`, the kubelet configuration is marshalled to disk
at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap
is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are
initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the
baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
points to the client certificates that allow the kubelet to communicate with the API server. This
addresses the need to
[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
To address the second pattern of
[providing instance-specific configuration details](#providing-instance-specific-configuration-details),
kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of
flags to pass to the kubelet when it starts. The flags are presented in the file like this:
```bash
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
```
In addition to the flags used when starting the kubelet, the file also contains dynamic
parameters such as the cgroup driver and whether to use a different CRI runtime socket
(`--cri-socket`).
After marshalling these two files to disk, kubeadm attempts to run the following two
commands, if you are using systemd:
```bash
systemctl daemon-reload && systemctl restart kubelet
```
If the reload and restart are successful, the normal `kubeadm init` workflow continues.
-->
### 当使用 `kubeadm init`时的工作流程
当调用 `kubeadm init` 时，kubelet 配置被编组到磁盘上的 `/var/lib/kubelet/config.yaml` 中，
并且上传到集群中的 ConfigMap。
ConfigMap 名为 `kubelet-config-1.X`，其中 `.X` 是您正在初始化的 kubernetes 版本的次版本。
在集群中所有 kubelet 的基准集群范围内配置，将 kubelet 配置文件写入 `/etc/kubernetes/kubelet.conf` 中。
此配置文件指向允许 kubelet 与 API 服务器通信的客户端证书。
这解决了 [将集群级配置传播到每个 kubelet](#propagating-cluster-level-configuration-to-each-kubelet)的需求。
该文档 [提供特定实例的配置详细信息](#providing-instance-specific-configuration-details) 是第二种解决模式，
kubeadm 将环境文件写入 `/var/lib/kubelet/kubeadm-flags.env`，其中包含了一个标志列表，
当 kubelet 启动时，该标志列表会传递给 kubelet 标志在文件中的显示方式如下：
```bash
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
```
除了启动 kubelet 时使用该标志外，该文件还包含动态参数，例如 cgroup 驱动程序以及是否使用其他 CRI 运行时 socket（`--cri-socket`）。
将这两个文件编组到磁盘后，如果使用 systemd，则 kubeadm 尝试运行以下两个命令：
```bash
systemctl daemon-reload && systemctl restart kubelet
```
如果重新加载和重新启动成功，则正常的 `kubeadm init` 工作流程将继续。
<!--
### Workflow when using `kubeadm join`
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
a TLS bootstrap, which fetches the credential needed to download the
`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
environment file is generated in exactly the same way as `kubeadm init`.
Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:
```bash
systemctl daemon-reload && systemctl restart kubelet
```
After the kubelet loads the new configuration, kubeadm writes the
`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap
Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique
credential, which is stored in `/etc/kubernetes/kubelet.conf`. When this file is written, the kubelet
has finished performing the TLS Bootstrap.
-->
### 当使用 `kubeadm join`时的工作流程
当运行 `kubeadm join` 时，kubeadm 使用 Bootstrap Token 证书执行 TLS 引导，该引导会获取一份证书，该证书需要下载 `kubelet-config-1.X` ConfigMap 并把它写入 `/var/lib/kubelet/config.yaml` 中。
动态环境文件的生成方式恰好与 `kubeadm init` 相同。
接下来，kubeadm 运行以下两个命令将新配置加载到 kubelet 中：
```bash
systemctl daemon-reload && systemctl restart kubelet
```
在 kubelet 加载新配置后，kubeadm 将写入 `/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig 文件中，
该文件包含 CA 证书和引导程序令牌。
kubelet 使用这些证书执行 TLS 引导程序并获取唯一的凭据，该凭据被存储在 `/etc/kubernetes/kubelet.conf` 中。
当此文件被写入后，kubelet 就完成了执行 TLS 引导程序。
<!--
## The kubelet drop-in file for systemd
kubeadm ships with configuration for how systemd should run the kubelet.
Note that the kubeadm CLI command never touches this drop-in file.
This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) is written to
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service))):
```none
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort.
# Preferably, the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
```
This file specifies the default locations for all of the files managed by kubeadm for the kubelet.
- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`,
but it is only used if `/etc/kubernetes/kubelet.conf` does not exist.
- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`.
- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`.
- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`.
- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from
`/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
is last in the flag chain and has the highest priority in the event of conflicting settings.
-->
## 系统中的 kubelet 插件
kubeadm 中附带了有关系统如何运行 kubelet 的配置。
请注意 kubeadm CLI 命令不会触及此插件。
通过 `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) 或者 [RPM 包](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) 安装的配置文件已被写入 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 并由系统使用。
它加强了基础设施 [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service)))：
```none
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# 这是 "kubeadm init" 和 "kubeadm join" 运行时生成的文件，动态地填充 KUBELET_KUBEADM_ARGS 变量
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# 这是一个文件，用户在不得已下可以将其用作替代 kubelet args。
# 用户最好使用 .NodeRegistration.KubeletExtraArgs 对象在配置文件中替代。
# KUBELET_EXTRA_ARGS 应该从此文件中获取。
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
```
该文件为 kubelet 指定由 kubeadm 管理的所有文件的默认位置。
- 用于 TLS 引导程序的 KubeConfig 文件为 `/etc/kubernetes/bootstrap-kubelet.conf`，
但仅当 `/etc/kubernetes/kubelet.conf` 不存在时才能使用。
- 具有唯一 kubelet 标识的 KubeConfig 文件为 `/etc/kubernetes/kubelet.conf`。
- 包含 kubelet 的组件配置的文件为 `/var/lib/kubelet/config.yaml`。
- 包含的动态环境的文件 `KUBELET_KUBEADM_ARGS` 是来源于 `/var/lib/kubelet/kubeadm-flags.env`。
- 包含用户指定标志替代的文件 `KUBELET_EXTRA_ARGS` 是来源于
`/etc/default/kubelet`（对于 DEB），或者 `/etc/sysconfig/kubelet`（对于 RPM）。
`KUBELET_EXTRA_ARGS` 在标志链中排在最后，并且在设置冲突时具有最高优先级。
<!--
## Kubernetes binaries and package contents
The DEB and RPM packages shipped with the Kubernetes releases are:
| Package name | Description |
|--------------|-------------|
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
-->
## Kubernetes 二进制文件和软件包内容
Kubernetes 版本对应的 DEB 和 RPM 软件包是：
| Package name | Description |
|--------------|-------------|
| `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 插件](#the-kubelet-drop-in-file-for-systemd)。 |
| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件。 |
| `kubectl` | 安装 `/usr/bin/kubectl` 二进制问价。 |
| `kubernetes-cni` | 将官方的 CNI 二进制文件安装到 `/opt/cni/bin` 目录中 |
| `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-incubator/cri-tools)中安装 `/usr/bin/crictl` 二进制文件。 |
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+134
View File
@@ -0,0 +1,134 @@
---
reviewers:
- sig-cluster-lifecycle
title: 配置您的 kubernetes 集群以自托管控制平台
content_template: templates/concept
weight: 100
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Configuring your kubernetes cluster to self-host the control plane
content_template: templates/concept
weight: 100
---
-->
{{% capture overview %}}
<!--
### Self-hosting the Kubernetes control plane {#self-hosting}
-->
### 自托管 Kubernetes 控制平台 {#self-hosting}
<!--
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
configured in the kubelet via static files.
-->
kubeadm 允许您实验性地创建 _self-hosted_ Kubernetes 控制平面。
这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 的身份运行，而不是通过静态文件将 [static pods](/docs/tasks/administer-cluster/static-pod/) 在 kubelet 中配置。
<!--
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-->
要创建自托管集群，请参见 [kubeadm alpha 自托管枢纽](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) 命令。
{{% /capture %}}
{{% capture body %}}
<!--
#### Caveats
-->
#### 警告
{{< caution >}}
<!--
This feature pivots your cluster into an unsupported state, rendering kubeadm unable
to manage you cluster any longer. This includes `kubeadm upgrade`.
-->
此功能将您的集群设置为不受支持的状态，从而使 kubeadm 无法再管理您的集群。
这包括 `kubeadm 升级` 。
{{< /caution >}}
<!--
1. Self-hosting in 1.8 and later has some important limitations. In particular, a
self-hosted cluster _cannot recover from a reboot of the control-plane node_
without manual intervention.
-->
1. 1.8及更高版本中的自托管功能有一些重要限制。
特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
<!--
1. By default, self-hosted control plane Pods rely on credentials loaded from
[`hostPath`](/docs/concepts/storage/volumes/#hostpath)
volumes. Except for initial creation, these credentials are not managed by
kubeadm.
-->
1. 默认情况下，自托管的控制平面 Pod 依赖于从 [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
除初始创建外，这些凭据不由 kubeadm 管理。
<!--
1. The self-hosted portion of the control plane does not include etcd,
which still runs as a static Pod.
-->
1. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
<!--
#### Process
-->
#### 处理
<!--
The self-hosting bootstrap process is documented in the [kubeadm design
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
-->
自托管引导过程记录在 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
<!--
In summary, `kubeadm alpha selfhosting` works as follows:
-->
总而言之，`kubeadm alpha 自托管` 的工作原理如下：
<!--
1. Waits for this bootstrap static control plane to be running and
healthy. This is identical to the `kubeadm init` process without self-hosting.
-->
1. 等待此引导静态控制平面运行且良好。
这与没有自我托管的 `kubeadm init` 过程相同。
<!--
1. Uses the static control plane Pod manifests to construct a set of
DaemonSet manifests that will run the self-hosted control plane.
It also modifies these manifests where necessary, for example adding new volumes
for secrets.
-->
1. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
它还会在必要时修改这些清单，例如添加新的秘密卷。
<!--
1. Creates DaemonSets in the `kube-system` namespace and waits for the
resulting Pods to be running.
-->
1. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
<!--
1. Once self-hosted Pods are operational, their associated static Pods are deleted
and kubeadm moves on to install the next component. This triggers kubelet to
stop those static Pods.
-->
1. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
这将触发 kubelet 停止那些静态 Pod 。
<!--
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
-->
1. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+407
View File
@@ -0,0 +1,407 @@
---
title: 使用 kubeadm 创建一个高可用 etcd 集群
content_template: templates/task
weight: 60
---
<!--
---
reviewers:
- sig-cluster-lifecycle
title: Set up a High Availability etcd cluster with kubeadm
content_template: templates/task
weight: 60
---
-->
{{% capture overview %}}
<!--
Kubeadm defaults to running a single member etcd cluster in a static pod managed
by the kubelet on the control plane node. This is not a high availability setup
as the etcd cluster contains only one member and cannot sustain any members
becoming unavailable. This task walks through the process of creating a high
availability etcd cluster of three members that can be used as an external etcd
when using kubeadm to set up a kubernetes cluster.
-->
默认情况下，kubeadm 运行单成员的 etcd 集群，该集群由控制面节点上的 kubelet 以静态 Pod 的方式进行管理。由于 etcd 集群只包含一个成员且不能在任一成员不可用时保持运行，所以这不是一种高可用设置。本任务，将告诉您如何在使用 kubeadm 创建一个 kubernetes 集群时创建一个外部 etcd：有三个成员的高可用 etcd 集群。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
* Three hosts that can talk to each other over ports 2379 and 2380. This document assumes these default ports. However, they are configurable through the kubeadm config file.
-->
* 三个可以通过 2379 和 2380 端口相互通信的主机。本文档使用这些作为默认端口。不过，它们可以通过 kubeadm 的配置文件进行自定义。
<!--
* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
-->
* 每个主机必须 [安装有 docker、kubelet 和 kubeadm][工具箱]。
<!--
* Some infrastructure to copy files between hosts. For example `ssh` and `scp` can satisfy this requirement.
-->
* 一些可以用来在主机间复制文件的基础设施。例如 `ssh` 和 `scp` 就可以满足需求。
<!--
[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
-->
[工具箱]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
{{% /capture %}}
{{% capture steps %}}
<!--
## Setting up the cluster
-->
## 建立集群
<!--
The general approach is to generate all certs on one node and only distribute the *necessary* files to the other nodes.
-->
一般来说，是在一个节点上生成所有证书并且只分发这些*必要*的文件到其它节点上。
{{< note >}}
<!--
kubeadm contains all the necessary crytographic machinery to generate the certificates described below; no other cryptographic tooling is required for this example.
-->
kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这个例子中，不需要其他加密工具。
{{< /note >}}
<!--
1. Configure the kubelet to be a service manager for etcd.
Since etcd was created first, you must override the service priority by creating a new unit file
that has higher precedence than the kubeadm-provided kubelet unit file.
-->
1. 将 kubelet 配置为 etcd 的服务管理器。
由于 etcd 是首先创建的，因此您必须通过创建具有更高优先级的新文件来覆盖 kubeadm 提供的 kubelet 单元文件。
```sh
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
# Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
Restart=always
EOF
systemctl daemon-reload
systemctl restart kubelet
```
<!--
1.Create configuration files for kubeadm.
Generate one kubeadm configuration file for each host that will have an etcd
member running on it using the following script.
-->
1. 为 kubeadm 创建配置文件。
使用以下脚本为每个将要运行 etcd 成员的主机生成一个 kubeadm 配置文件。
<!--
```sh
# Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=10.0.0.8
# Create temp directories to store files that will end up on other hosts.
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
NAMES=("infra0" "infra1" "infra2")
for i in "${!ETCDHOSTS[@]}"; do
HOST=${ETCDHOSTS[$i]}
NAME=${NAMES[$i]}
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
apiVersion: "kubeadm.k8s.io/v1beta2"
kind: ClusterConfiguration
etcd:
local:
serverCertSANs:
- "${HOST}"
peerCertSANs:
- "${HOST}"
extraArgs:
initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
initial-cluster-state: new
name: ${NAME}
listen-peer-urls: https://${HOST}:2380
listen-client-urls: https://${HOST}:2379
advertise-client-urls: https://${HOST}:2379
initial-advertise-peer-urls: https://${HOST}:2380
EOF
done
```
-->
```sh
# 使用 IP 或可解析的主机名替换 HOST0、HOST1 和 HOST2
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=10.0.0.8
# 创建临时目录来存储将被分发到其它主机上的文件
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
NAMES=("infra0" "infra1" "infra2")
for i in "${!ETCDHOSTS[@]}"; do
HOST=${ETCDHOSTS[$i]}
NAME=${NAMES[$i]}
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
apiVersion: "kubeadm.k8s.io/v1beta2"
kind: ClusterConfiguration
etcd:
local:
serverCertSANs:
- "${HOST}"
peerCertSANs:
- "${HOST}"
extraArgs:
initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
initial-cluster-state: new
name: ${NAME}
listen-peer-urls: https://${HOST}:2380
listen-client-urls: https://${HOST}:2379
advertise-client-urls: https://${HOST}:2379
initial-advertise-peer-urls: https://${HOST}:2380
EOF
done
```
<!--
1.Generate the certificate authority
If you already have a CA then the only action that is copying the CA's `crt` and
`key` file to `/etc/kubernetes/pki/etcd/ca.crt` and
`/etc/kubernetes/pki/etcd/ca.key`. After those files have been copied,
proceed to the next step, "Create certificates for each member".
-->
1. 生成证书颁发机构
如果您已经拥有 CA，那么唯一的操作是复制 CA 的 `crt` 和 `key` 文件到 `etc/kubernetes/pki/etcd/ca.crt` 和 `/etc/kubernetes/pki/etcd/ca.key`。复制完这些文件后继续下一步，“为每个成员创建证书”。
<!--
If you do not already have a CA then run this command on `$HOST0` (where you generated the configuration files for kubeadm).
-->
如果您还没有 CA，则在 `$HOST0`（您为 kubeadm 生成配置文件的位置）上运行此命令。
```
kubeadm alpha phase certs etcd-ca
```
<!--
This creates two files
-->
创建了如下两个文件
- `/etc/kubernetes/pki/etcd/ca.crt`
- `/etc/kubernetes/pki/etcd/ca.key`
<!--
1. Create certificates for each member
-->
1. 为每个成员创建证书
<!--
```sh
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
# cleanup non-reusable certificates
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
# No need to move the certs because they are for HOST0
# clean up certs that should not be copied off this host
find /tmp/${HOST2} -name ca.key -type f -delete
find /tmp/${HOST1} -name ca.key -type f -delete
```
-->
```sh
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
# 清理不可重复使用的证书
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
# 不需要移动 certs 因为它们是给 HOST0 使用的
# 清理不应从此主机复制的证书
find /tmp/${HOST2} -name ca.key -type f -delete
find /tmp/${HOST1} -name ca.key -type f -delete
```
<!--
1.Copy certificates and kubeadm configs
The certificates have been generated and now they must be moved to their
respective hosts.
-->
1. 复制证书和 kubeadm 配置
证书已生成，现在必须将它们移动到对应的主机。
```sh
USER=ubuntu
HOST=${HOST1}
scp -r /tmp/${HOST}/* ${USER}@${HOST}:
ssh ${USER}@${HOST}
USER@HOST $ sudo -Es
root@HOST $ chown -R root:root pki
root@HOST $ mv pki /etc/kubernetes/
```
<!--
1.Ensure all expected files exist
The complete list of required files on `$HOST0` is:
-->
1. 确保已经所有预期的文件都存在
`$HOST0` 所需文件的完整列表如下：
```
/tmp/${HOST0}
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── ca.key
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
<!--
On `$HOST1`:
-->
在 `$HOST1`:
```
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
<!--
On `$HOST2`
-->
在 `$HOST2`
```
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
<!--
1.Create the static pod manifests
Now that the certificates and configs are in place it's time to create the
manifests. On each host run the `kubeadm` command to generate a static manifest
for etcd.
-->
1. 创建静态 Pod 清单
既然证书和配置已经就绪，是时候去创建清单了。在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。
```sh
root@HOST0 $ kubeadm alpha phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
root@HOST1 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
root@HOST2 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
```
<!--
1.Optional: Check the cluster health
-->
1. 可选：检查群集运行状况
```sh
docker run --rm -it \
--net host \
-v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:v3.2.18 etcdctl \
--cert-file /etc/kubernetes/pki/etcd/peer.crt \
--key-file /etc/kubernetes/pki/etcd/peer.key \
--ca-file /etc/kubernetes/pki/etcd/ca.crt \
--endpoints https://${HOST0}:2379 cluster-health
...
cluster is healthy
```
{{% /capture %}}
{{% capture whatsnext %}}
<!--
Once your have a working 3 member etcd cluster, you can continue setting up a
highly available control plane using the [external etcd method with
kubeadm](/docs/setup/independent/high-availability/).
-->
一旦拥有了一个正常工作的 3 成员的 etcd 集群，你就可以基于[使用 kubeadm 的外部 etcd 方法](/docs/setup/independent/high-availability/)，继续部署一个高可用的控制平面。
{{% /capture %}}
content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+650
View File
@@ -0,0 +1,650 @@
---
title: 对 kubeadm 进行故障排查
content_template: templates/concept
weight: 20
---
<!--
---
title: Troubleshooting kubeadm
content_template: templates/concept
weight: 20
---
-->
{{% capture overview %}}
<!--
As with any program, you might run into an error installing or running kubeadm.
This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
If your problem is not listed below, please follow the following steps:
- If you think your problem is a bug with kubeadm:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-->
与任何程序一样，您可能会在安装或者运行 kubeadm 时遇到错误。
本文列举了一些常见的故障场景，并提供可帮助您理解和解决这些问题的步骤。
如果您的问题未在下面列出，请执行以下步骤：
- 如果您认为问题是 kubeadm 的错误：
- 转到 [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) 并搜索存在的问题。
- 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。
- 如果您对 kubeadm 的工作方式有疑问，可以在 [Slack](http://slack.k8s.io/) 上的 #kubeadm 频道提问，
或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。
请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助您。
{{% /capture %}}
{{% capture body %}}
<!--
## `ebtables` or some similar executable not found during installation
If you see the following warnings while running `kubeadm init`
```sh
[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path
```
Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands:
- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
- For CentOS/Fedora users, run `yum install ebtables ethtool`.
-->
## 在安装过程中没有找到 `ebtables` 或者其他类似的可执行文件
如果在运行 `kubeadm init` 命令时，遇到以下的警告
```sh
[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path
```
那么或许在您的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
您可以使用以下命令安装它们：
- 对于 Ubuntu/Debian 用户，运行 `apt install ebtables ethtool` 命令。
- 对于 CentOS/Fedora 用户，运行 `yum install ebtables ethtool` 命令。
<!--
## kubeadm blocks waiting for control plane during installation
If you notice that `kubeadm init` hangs after printing out the following line:
```sh
[apiclient] Created API client, waiting for the control plane to become ready
```
-->
## 在安装过程中，kubeadm 一直等待控制平面就绪
如果您注意到 `kubeadm init` 在打印以下行后挂起：
```sh
[apiclient] Created API client, waiting for the control plane to become ready
```
<!--
This may be caused by a number of problems. The most common are:
- network connection problems. Check that your machine has full network connectivity before continuing.
- the default cgroup driver configuration for the kubelet differs from that used by Docker.
Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following:
```shell
error: failed to run Kubelet: failed to create kubelet:
misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
```
There are two common ways to fix the cgroup driver problem:
1. Install Docker again following instructions
[here](/docs/setup/production-environment/container-runtimes/#docker).
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
[Configure cgroup driver used by kubelet on Master Node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
-->
这可能是由许多问题引起的。最常见的是：
- 网络连接问题。在继续之前，请检查您的计算机是否具有全部联通的网络连接。
- kubelet 的默认 cgroup 驱动程序配置不同于 Docker 使用的配置。
检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果您看见以下内容：
```shell
error: failed to run Kubelet: failed to create kubelet:
misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
```
有两种常见方法可解决 cgroup 驱动程序问题：
1. 按照 [此处](/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，您可以参考
[在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。您可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
<!--
## kubeadm blocks when removing managed containers
The following could happen if Docker halts and does not remove any Kubernetes-managed containers:
```bash
sudo kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)
```
A possible solution is to restart the Docker service and then re-run `kubeadm reset`:
```bash
sudo systemctl restart docker.service
sudo kubeadm reset
```
Inspecting the logs for docker may also be useful:
```sh
journalctl -ul docker
```
-->
## 当删除托管容器时 kubeadm 阻塞
如果 Docker 停止并且不删除 Kubernetes 所管理的所有容器，可能发生以下情况：
```bash
sudo kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)
```
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 `kubeadm reset`：
```bash
sudo systemctl restart docker.service
sudo kubeadm reset
```
检查 docker 的日志也可能有用：
```sh
journalctl -ul docker
```
<!--
## Pods in `RunContainerError`, `CrashLoopBackOff` or `Error` state
Right after `kubeadm init` there should not be any pods in these states.
- If there are pods in one of these states _right after_ `kubeadm init`, please open an
issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
until you have deployed the network solution.
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
it's very likely that the Pod Network solution that you installed is somehow broken.
You might have to grant it more RBAC privileges or use a newer version. Please file
an issue in the Pod Network providers' issue tracker and get the issue triaged there.
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.
-->
## Pods 处于 `RunContainerError`、`CrashLoopBackOff` 或者 `Error` 状态
在 `kubeadm init` 命令运行后，系统中不应该有 pods 处于这类状态。
- 在 `kubeadm init` 命令执行完后，如果有 pods 处于这些状态之一，请在 kubeadm
仓库提起一个 issue。`coredns` (或者 `kube-dns`) 应该处于 `Pending` 状态，
直到您部署了网络解决方案为止。
- 如果在部署完网络解决方案之后，有 Pods 处于 `RunContainerError`、`CrashLoopBackOff`
或 `Error` 状态之一，并且`coredns` （或者 `kube-dns`）仍处于 `Pending` 状态，
那很可能是您安装的网络解决方案由于某种原因无法工作。您或许需要授予它更多的
RBAC 特权或使用较新的版本。请在 Pod Network 提供商的问题跟踪器中提交问题，
然后在此处分类问题。
- 如果您安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
删除 `MountFlags=slave` 选项。
您可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
MountFlags 可能会干扰 Kubernetes 挂载的卷， 并使 Pods 处于 `CrashLoopBackOff` 状态。
当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。
<!--
## `coredns` (or `kube-dns`) is stuck in the `Pending` state
This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
of choice. You have to install a Pod Network
before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
-->
## `coredns` （或 `kube-dns`）停滞在 `Pending` 状态
这一行为是 **预期之中** 的，因为系统就是这么设计的。
kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/docs/concepts/cluster-administration/addons/)。
您必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。
<!--
## `HostPort` services do not work
The `HostPort` and `HostIP` functionality is available depending on your Pod Network
provider. Please contact the author of the Pod Network solution to find out whether
`HostPort` and `HostIP` functionality are available.
Calico, Canal, and Flannel CNI providers are verified to support HostPort.
For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
-->
## `HostPort` 服务无法工作
此 `HostPort` 和 `HostIP` 功能是否可用取决于您的 Pod 网络配置。请联系 Pod 解决方案的作者，
以确认 `HostPort` 和 `HostIP` 功能是否可用。
已验证 Calico、Canal 和 Flannel CNI 驱动程序支持 HostPort。
有关更多信息，请参考 [CNI portmap 文档](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
如果您的网络提供商不支持 portmap CNI 插件，您或许需要使用 [NodePort 服务的功能](/docs/concepts/services-networking/service/#nodeport) 或者使用 `HostNetwork=true`。
<!--
## Pods are not accessible via their Service IP
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
which allows pods to access themselves via their Service IP. This is an issue related to
[CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
add-on provider to get the latest status of their support for hairpin mode.
- If you are using VirtualBox (directly or via Vagrant), you will need to
ensure that `hostname -i` returns a routable IP address. By default the first
interface is connected to a non-routable host-only network. A work around
is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
for an example.
-->
## 无法通过其服务 IP 访问 Pod
- 许多网络附加组件尚未启用 [hairpin 模式](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
- 如果您正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，您需要
确保 `hostname -i` 返回一个可路由的 IP 地址。默认情况下，第一个接口连接不能路由的仅主机网络。
解决方法是修改 `/etc/hosts`，请参考示例 [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)。
<!--
## TLS certificate errors
The following error indicates a possible certificate mismatch.
```none
# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
```
- Verify that the `$HOME/.kube/config` file contains a valid certificate, and
regenerate a certificate if necessary. The certificates in a kubeconfig file
are base64 encoded. The `base64 -d` command can be used to decode the certificate
and `openssl x509 -text -noout` can be used for viewing the certificate information.
- Unset the `KUBECONFIG` environment variable using:
```sh
unset KUBECONFIG
```
Or set it to the default `KUBECONFIG` location:
```sh
export KUBECONFIG=/etc/kubernetes/admin.conf
```
- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
```sh
mv $HOME/.kube $HOME/.kube.bak
mkdir $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
-->
## TLS 证书错误
以下错误指出证书可能不匹配。
```none
# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
```
- 验证 `$HOME/.kube/config` 文件是否包含有效证书，并
在必要时重新生成证书。在 kubeconfig 文件中的证书是 base64 编码的。
该 `base64 -d` 命令可以用来解码证书，`openssl x509 -text -noout` 命令
可以用于查看证书信息。
- 使用如下方法取消设置 `KUBECONFIG` 环境变量的值：
```sh
unset KUBECONFIG
```
或者将其设置为默认的 `KUBECONFIG` 位置：
```sh
export KUBECONFIG=/etc/kubernetes/admin.conf
```
- 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员" ：
```sh
mv $HOME/.kube $HOME/.kube.bak
mkdir $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
<!--
## Default NIC When using flannel as the pod network in Vagrant
The following error might indicate that something was wrong in the pod network:
```sh
Error from server (NotFound): the server could not find the requested resource
```
- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel.
Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
-->
## 在 Vagrant 中使用 flannel 作为 pod 网络时的默认 NIC
以下错误可能表明 Pod 网络中出现问题：
```sh
Error from server (NotFound): the server could not find the requested resource
```
- 如果你正在 Vagrant 中使用 flannel 作为 pod 网络，则必须指定 flannel 的默认接口名称。
Vagrant 通常为所有 VM 分配两个接口。第一个为所有主机分配了 IP 地址 `10.0.2.15`，用于获得 NATed 的外部流量。
这可能会导致 flannel 出现问题，它默认为主机上的第一个接口。这导致所有主机认为它们具有
相同的公共 IP 地址。为防止这种情况，传递 `--iface eth1` 标志给 flannel 以便选择第二个接口。
<!--
## Non-public IP used for containers
In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster:
```sh
Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
```
- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider.
- Digital Ocean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one.
Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to Digital Ocean allows to query for the anchor IP from the droplet:
```sh
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
```
The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
Then restart `kubelet`:
```sh
systemctl daemon-reload
systemctl restart kubelet
```
-->
## 容器使用的非公共 IP
在某些情况下 `kubectl logs` 和 `kubectl run` 命令或许会返回以下错误，即便除此之外集群一切功能正常：
```sh
Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
```
- 这或许是由于 Kubernetes 使用的 IP 无法与看似相同的子网上的其他 IP 进行通信的缘故，
可能是由机器提供商的政策所导致的。
- Digital Ocean 既分配一个共有 IP 给 `eth0`，也分配一个私有 IP 在内部用作其浮动 IP 功能的锚点，
然而 `kubelet` 将选择后者作为节点的 `InternalIP` 而不是公共 IP
使用 `ip addr show` 命令代替 `ifconfig` 命令去检查这种情况，因为 `ifconfig` 命令
不会显示有问题的别名 IP 地址。或者指定的 Digital Ocean 的 API 端口允许从 droplet 中
查询 anchor IP：
```sh
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
```
解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 Digital Ocean 时，可以是公网IP（分配给 `eth0`的），
或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。
这个 [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
然后重启 `kubelet`：
```sh
systemctl daemon-reload
systemctl restart kubelet
```
<!--
## `coredns` pods have `CrashLoopBackOff` or `Error` state
If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
where the `coredns` pods are not starting. To solve that you can try one of the following options:
- Upgrade to a [newer version of Docker](/docs/setup/production-environment/container-runtimes/#docker).
- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
```bash
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
```
Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
-->
## `coredns` pods 有 `CrashLoopBackOff` 或者 `Error` 状态
如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，您或许会遇到 `coredns` pods 无法启动的情况。
要解决此问题，您可以尝试以下选项之一：
- 升级到 [Docker 的较新版本](/docs/setup/production-environment/container-runtimes/#docker)。
- [禁用 SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
- 修改 `coredns` 部署以设置 `allowPrivilegeEscalation` 为 `true`：
```bash
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
```
CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部署的 CoreDNS Pod 检测
到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。
{{< warning >}}
<!--
Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
the security of your cluster.
-->
**警告**：禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
{{< /warning >}}
<!--
## etcd pods restart continually
If you encounter the following error:
```
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
```
this issue appears if you run CentOS 7 with Docker 1.13.1.84.
This version of Docker can prevent the kubelet from executing into the etcd container.
To work around the issue, choose one of these options:
- Roll back to an earlier version of Docker, such as 1.13.1-75
```
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
```
- Install one of the more recent recommended versions, such as 18.06:
```bash
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce-18.06.1.ce-3.el7.x86_64
```
-->
## etcd pods 持续重启
如果您遇到以下错误：
```
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
```
如果您使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
此版本的 Docker 会阻止 kubelet 在 etcd 容器中执行。
为解决此问题，请选择以下选项之一：
- 回滚到早期版本的 Docker，例如 1.13.1-75
```
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
```
- 安装较新的推荐版本之一，例如 18.06:
```bash
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce-18.06.1.ce-3.el7.x86_64
```
<!--
## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
the values (`mapStringString`).
If you decide to pass an argument that supports multiple, comma-separated values such as
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
`flag: malformed pair, expect string=string`. This happens because the list of arguments for
`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
as a key that is missing a value.
Alternatively, you can try separating the `key=value` pairs like so:
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
-->
## 无法将以逗号分隔的值列表传递给 `--component-extra-args` 标志内的参数
`kubeadm init` 标志例如 `--component-extra-args` 允许您将自定义参数传递给像 kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
如果您决定传递一个支持多个逗号分隔值（例如 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，将出现 `flag: malformed pair, expect string=string` 错误。
发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
一种解决方法是尝试分离 `key=value` 对，像这样：
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
但这将导致键 `enable-admission-plugins` 仅有值 `NamespaceExists`。
已知的解决方法是使用 kubeadm [配置文件](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
<!--
## kube-proxy scheduled before node is initialized by cloud-controller-manager
In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
to pick up the node's IP address properly and has knock-on effects to the proxy function managing
load balancers.
The following error can be seen in kube-proxy Pods:
```
server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
```
A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
conditions abate:
```
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
```
The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
-->
## 在节点被云控制管理器初始化之前，kube-proxy 就被调度了
在云环境场景中，可能出现在云控制管理器完成节点地址初始化之前，kube-proxy 就被调度到新节点了。
这会导致 kube-proxy 无法正确获取节点的 IP 地址，并对管理负载平衡器的代理功能产生连锁反应。
在 kube-proxy Pod 中可以看到以下错误：
```
server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
```
一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
```
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
```
此问题的跟踪 [在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
<!--
## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.*
By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice,
the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint.
There are at least two workarounds:
1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
2. Remove the taint after kubeadm init exits:
```bash
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
```
-->
## NodeRegistration.Taints 字段在编组 kubeadm 配置时丢失
*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
默认情况下，kubeadm 将 `role.kubernetes.io/master:NoSchedule` 污点应用于控制平面节点。
如果您希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
如果省略该字段，则 kubeadm 将应用默认污点。
至少有两种解决方法：
1. 使用 `role.kubernetes.io/master:PreferNoSchedule` 污点代替空切片。
除非其他节点具有容量，[否则将在主节点上调度 Pods](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
2. 在 kubeadm init 退出后删除污点：
```bash
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
```
{{% /capture %}}
content/zh/docs/setup/production-environment/turnkey/_index.md
+9
View File
@@ -0,0 +1,9 @@
---
title: Turnkey 云解决方案
weight: 30
---
<!--
title: Turnkey Cloud Solutions
weight: 30
-->
content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md
+44
View File
@@ -0,0 +1,44 @@
---
reviewers:
- colemickens
- brendandburns
title: 在阿里云上运行 Kubernetes
---
<!--
---
reviewers:
- colemickens
- brendandburns
title: Running Kubernetes on Alibaba Cloud
---
-->
<!--
## Alibaba Cloud Container Service
The [Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service) lets you run and manage Docker applications on a cluster of Alibaba Cloud ECS instances. It supports the popular open source container orchestrators: Docker Swarm and Kubernetes.
To simplify cluster deployment and management, use [Kubernetes Support for Alibaba Cloud Container Service](https://www.alibabacloud.com/product/kubernetes). You can get started quickly by following the [Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm), and there are some [tutorials for Kubernetes Support on Alibaba Cloud](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1) in Chinese.
To use custom binaries or open source Kubernetes, follow the instructions below.
-->
## 阿里云容器服务
[阿里云容器服务](https://www.alibabacloud.com/product/container-service)使您可以在阿里云 ECS 实例集群上运行和管理 Docker 应用程序。它支持流行的开源容器编排引擎：Docker Swarm 和 Kubernetes。
为了简化集群的部署和管理，请使用 [容器服务 Kubernetes 版](https://www.alibabacloud.com/product/kubernetes)。您可以按照 [Kubernetes 演练](https://www.alibabacloud.com/help/doc-detail/86737.htm)快速入门，其中有一些使用中文书写的[容器服务 Kubernetes 版教程](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)。
要使用自定义二进制文件或开源版本的 Kubernetes，请按照以下说明进行操作。
<!--
## Custom Deployments
The source code for [Kubernetes with Alibaba Cloud provider implementation](https://github.com/AliyunContainerService/kubernetes) is open source and available on GitHub.
For more information, see "[Quick deployment of Kubernetes - VPC environment on Alibaba Cloud](https://www.alibabacloud.com/forum/read-830)" in English and [Chinese](https://yq.aliyun.com/articles/66474).
-->
## 自定义部署
[阿里云 Kubernetes Cloud Provider 实现](https://github.com/AliyunContainerService/kubernetes) 的源代码是开源的，可在 GitHub 上获得。
有关更多信息，请参阅中文版本[快速部署 Kubernetes - 阿里云上的VPC环境](https://yq.aliyun.com/articles/66474)和[英文版本](https://www.alibabacloud.com/forum/read-830)。
content/zh/docs/setup/production-environment/turnkey/aws.md
+177
View File
@@ -0,0 +1,177 @@
---
reviewers:
- justinsb
- clove
title: 在 AWS EC2 上运行 Kubernetes
content_template: templates/task
---
<!--
---
reviewers:
- justinsb
- clove
title: Running Kubernetes on AWS EC2
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page describes how to install a Kubernetes cluster on AWS.
-->
本页面介绍了如何在 AWS 上安装 Kubernetes 集群。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
-->
在 AWS 上创建 Kubernetes 集群，您将需要 AWS 的 Access Key ID 和 Secret Access Key。
<!--
### Supported Production Grade Tools
-->
### 支持的生产级别工具
<!--
* [conjure-up](/docs/getting-started-guides/ubuntu/) is an open-source installer for Kubernetes that creates Kubernetes clusters with native AWS integrations on Ubuntu.
-->
* [conjure-up](/docs/getting-started-guides/ubuntu/) 是 Kubernetes 的开源安装程序，可在 Ubuntu 上创建与原生 AWS 集成的 Kubernetes 集群。
<!--
* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
-->
* [Kubernetes Operations](https://github.com/kubernetes/kops) - 生产级 K8s 的安装、升级和管理。支持在 AWS 运行 Debian、Ubuntu、CentOS 和 RHEL。
<!--
* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS.
-->
* [CoreOS Tectonic](https://coreos.com/tectonic/) 包括开源的 [Tectonic 安装程序](https://github.com/coreos/tectonic-installer)，它用于在 AWS 上创建带有 Container Linux 节点的 Kubernetes 集群。
<!--
* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
-->
* 起源于 CoreOS，Kubernetes Incubator 维护的 [CLI 工具， kube-aws ](https://github.com/kubernetes-incubator/kube-aws)，该工具使用 [Container Linux](https://coreos.com/why/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。
<!--
* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
-->
* [KubeOne](https://github.com/kubermatic/kubeone) 是一个开源集群生命周期管理工具，它可用于创建，升级和管理高可用 Kubernetes 集群。
{{% /capture %}}
{{% capture steps %}}
<!--
## Getting started with your cluster
-->
## 集群入门
<!--
### Command line administration tool: kubectl
-->
### 命令行管理工具：kubectl
<!--
The cluster startup script will leave you with a `kubernetes` directory on your workstation.
Alternately, you can download the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases).
Next, add the appropriate binary folder to your `PATH` to access kubectl:
-->
集群启动脚本将在您的工作站上为您提供一个 `kubernetes` 目录。
或者，您可以从[此页面](https://github.com/kubernetes/kubernetes/releases)下载最新的 Kubernetes 版本。
接下来，将适当的二进制文件夹添加到您的 `PATH` 以访问 kubectl：
```shell
# macOS
export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
# Linux
export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
```
<!--
An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
-->
此工具的最新文档页面位于此处：[kubectl 手册](/docs/user-guide/kubectl/)
默认情况下，`kubectl` 将使用在集群启动期间生成的 `kubeconfig` 文件对 API 进行身份验证。
有关更多信息，请阅读 [kubeconfig 文件](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
<!--
### Examples
See [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)
-->
### 示例
请参阅[一个简单的 nginx 示例](/docs/tasks/run-application/run-stateless-application-deployment/)试用您的新集群。
“Guestbook” 应用程序是另一个入门 Kubernetes 的流行示例：[guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)。
有关更完整的应用程序，请查看[示例目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)。
<!--
## Scaling the cluster
Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
-->
## 集群伸缩
不支持通过 `kubectl` 添加和删除节点。您仍然可以通过调整在安装过程中创建的 [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html) 中的 “Desired” 和 “Max” 属性来手动伸缩节点数量。
<!--
## Tearing down the cluster
Make sure the environment variables you used to provision your cluster are still exported, then call the following script inside the
`kubernetes` directory:
-->
## 集群拆除
确保您用于配置集群的环境变量已被导出，然后在运行如下在 Kubernetes 目录的脚本：
```shell
cluster/kube-down.sh
```
<!--
## Support Level
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
-->
## 支持等级
IaaS 提供商 | 配置管理 | 操作系统 | 网络 | 文档 | 符合率 | 支持等级
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
<!--
## Further reading
Please see the [Kubernetes docs](/docs/) for more details on administering
and using a Kubernetes cluster.
-->
## 进一步阅读
请参阅 [Kubernetes 文档](/docs/)了解有关管理和使用 Kubernetes 集群的更多详细信息。
{{% /capture %}}
content/zh/docs/setup/production-environment/turnkey/azure.md
+76
View File
@@ -0,0 +1,76 @@
---
reviewers:
- colemickens
- brendandburns
title: 在 Azure 上运行 Kubernetes
---
<!--
---
reviewers:
- colemickens
- brendandburns
title: Running Kubernetes on Azure
---
-->
<!--
## Azure Kubernetes Service (AKS)
The [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) offers simple
deployments for Kubernetes clusters.
For an example of deploying a Kubernetes cluster onto Azure via the Azure Kubernetes Service:
**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/zh-cn/azure/aks/intro-kubernetes)**
-->
## Azure Kubernetes 服务 (AKS)
[Azure Kubernetes 服务](https://azure.microsoft.com/zh-cn/services/kubernetes-service/)提供了简单的
Kubernetes 集群部署方式。
有关通过 Azure Kubernetes 服务将 Kubernetes 集群部署到 Azure 的示例：
**[微软 Azure Kubernetes 服务](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
<!--
## Custom Deployments: AKS-Engine
The core of the Azure Kubernetes Service is **open source** and available on GitHub for the community
to use and contribute to: **[AKS-Engine](https://github.com/Azure/aks-engine)**. The legacy [ACS-Engine](https://github.com/Azure/acs-engine) codebase has been deprecated in favor of AKS-engine.
AKS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Kubernetes
Service officially supports. These customizations include deploying into existing virtual networks, utilizing multiple
agent pools, and more. Some community contributions to AKS-Engine may even become features of the Azure Kubernetes Service.
The input to AKS-Engine is an apimodel JSON file describing the Kubernetes cluster. It is similar to the Azure Resource Manager (ARM) template syntax used to deploy a cluster directly with the Azure Kubernetes Service. The resulting output is an ARM template that can be checked into source control and used to deploy Kubernetes clusters to Azure.
You can get started by following the **[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**.
-->
## 定制部署：AKS 引擎
Azure Kubernetes 服务的核心是**开源**，并且可以在 GitHub 上让社区使用和参与贡献：**[AKS 引擎](https://github.com/Azure/aks-engine)**。旧版 [ACS 引擎](https://github.com/Azure/acs-engine) 代码库已被弃用，以支持AKS-engine。
如果您需要在 Azure Kubernetes 服务正式支持的范围之外对部署进行自定义，则 AKS 引擎是一个不错的选择。这些自定义包括部署到现有虚拟网络中，利用多个代理程序池等。一些社区对 AKS 引擎的贡献甚至可能成为 Azure Kubernetes 服务的特性。
AKS 引擎的输入是一个描述 Kubernetes 集群的 apimodel JSON 文件。它和用于直接通过 Azure Kubernetes 服务部署集群的 Azure 资源管理器（ARM）模板语法相似。产生的输出是一个 ARM 模板，可以将其签入源代码管理，并使用它将 Kubernetes 集群部署到 Azure。
您可以按照 **[AKS 引擎 Kubernetes 教程](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**开始使用。
<!--
## CoreOS Tectonic for Azure
The CoreOS Tectonic Installer for Azure is **open source** and available on GitHub for the community to use and contribute to: **[Tectonic Installer](https://github.com/coreos/tectonic-installer)**.
Tectonic Installer is a good choice when you need to make cluster customizations as it is built on [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure Resource Manager (ARM) provider. This enables users to customize or integrate using familiar Terraform tooling.
You can get started using the [Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html).
-->
## 适用于 Azure 的 CoreOS Tectonic
适用于 Azure 的 CoreOS Tectonic Installer 是**开源的**，它可以让社区在 GitHub 上使用和参与贡献：**[Tectonic Installer](https://github.com/coreos/tectonic-installer)**。
当您需要进行自定义集群时，Tectonic Installer是一个不错的选择，因为它是基于 [Hashicorp 的 Terraform](https://www.terraform.io/docs/providers/azurerm/)，Azure资源管理器（ARM）提供程序构建的。这使用户可以使用熟悉的 Terraform 工具进行自定义或集成。
您可以开始使用 [在 Azure 上安装 Tectonic 指南](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html)。
content/zh/docs/setup/production-environment/turnkey/icp.md
+162
View File
@@ -0,0 +1,162 @@
---
reviewers:
- bradtopol
title: 使用 IBM Cloud Private 在多个云上运行 Kubernetes
---
<!--
---
reviewers:
- bradtopol
title: Running Kubernetes on Multiple Clouds with IBM Cloud Private
---
-->
<!--
IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform.
-->
IBM® Cloud Private 是一个 一站式云解决方案并且是一个本地的一站式云解决方案。 IBM Cloud Private 提供纯上游 Kubernetes，以及运行实际企业工作负载所需的典型管理组件。这些工作负载包括健康管理、日志管理、审计跟踪以及用于跟踪平台上工作负载使用情况的计量。
<!--
IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started).
-->
IBM Cloud Private 提供了社区版和全支持的企业版。可从 [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/) 免费获得社区版本。企业版支持高可用性拓扑，并包括 IBM 对 Kubernetes 和 IBM Cloud Private 管理平台的商业支持。如果您想尝试 IBM Cloud Private，您可以使用托管试用版、教程或自我指导演示。您也可以尝试免费的社区版。有关详细信息，请参阅 [IBM Cloud Private 入门](https://www.ibm.com/cloud/private/get-started)。
<!--
For more information, explore the following resources:
* [IBM Cloud Private](https://www.ibm.com/cloud/private)
* [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
* [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
-->
有关更多信息，请浏览以下资源：
* [IBM Cloud Private](https://www.ibm.com/cloud/private)
* [IBM Cloud Private 参考架构](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
* [IBM Cloud Private 文档](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
<!--
## IBM Cloud Private and Terraform
The following modules are available where you can deploy IBM Cloud Private by using Terraform:
* AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
* Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
* IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
* OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
* Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
* VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
-->
## IBM Cloud Private 和 Terraform
您可以利用一下模块使用 Terraform 部署 IBM Cloud Private：
* AWS：[将 IBM Cloud Private 部署到 AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
* Azure：[将 IBM Cloud Private 部署到 Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
* IBM Cloud：[将 IBM Cloud Private 集群部署到 IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
* OpenStack：[将IBM Cloud Private 部署到 OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
* Terraform 模块：[在任何支持的基础架构供应商上部署 IBM Cloud Private](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
* VMware：[将 IBM Cloud Private 部署到 VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
<!--
## IBM Cloud Private on AWS
-->
## AWS 上的 IBM Cloud Private
<!--
You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
-->
您可以使用 AWS CloudFormation 或 Terraform 在 Amazon Web Services（AWS）上部署 IBM Cloud Private 集群。
<!--
IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
-->
IBM Cloud Private 快速入门可以自动将 IBM Cloud Private 部署到 AWS Cloud 上的新虚拟私有云（VPC）中。常规部署大约需要60分钟，而高可用性（HA）部署大约需要75分钟。快速入门包括 AWS CloudFormation 模板和部署指南。
<!--
This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
-->
这个快速入门适用于希望探索应用程序现代化并希望通过使用 IBM Cloud Private 和 IBM 工具加速实现其数字化转换目标的用户。快速入门可帮助用户在 AWS 上快速部署高可用性（HA）、生产级的 IBM Cloud Private 参考架构。有关所有详细信息和部署指南，请参阅 [IBM Cloud Private 在 AWS 上的快速入门 ](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/)。
<!--
IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
-->
IBM Cloud Private 也可以通过使用 Terraform 在 AWS 云平台上运行。要在 AWS EC2 环境中部署 IBM Cloud Private，请参阅[在 AWS 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md)。
<!--
## IBM Cloud Private on Azure
You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html).
-->
## Azure 上的 IBM Cloud Private
您可以启用 Microsoft Azure 作为 IBM Cloud Private 部署的云提供者，并利用 Azure 公共云上的所有 IBM Cloud Private 功能。有关更多信息，请参阅 [Azure 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html)。
<!--
## IBM Cloud Private with Red Hat OpenShift
-->
## 带有 Red Hat OpenShift 的 IBM Cloud Private
<!--
You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
-->
您可以将在 IBM Cloud Private 上运行的 IBM 认证的软件容器部署到 Red Hat OpenShift 上。
<!--
Integration capabilities:
* Supports Linux® 64-bit platform in offline-only installation mode
* Single-master configuration
* Integrated IBM Cloud Private cluster management console and catalog
* Integrated core platform services, such as monitoring, metering, and logging
* IBM Cloud Private uses the OpenShift image registry
-->
整合能力：
* 在仅脱机安装模式下支持 Linux®64 位平台
* 单主控节点配置
* 集成的 IBM Cloud Private 集群管理控制台和目录
* 集成的核心平台服务，例如监控、计量和日志
* IBM Cloud Private 使用 OpenShift 镜像仓库
<!--
For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html).
-->
有关更多信息，请参阅 [OpenShift 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html)。
<!--
## IBM Cloud Private on VirtualBox
To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox).
-->
## VirtualBox 上的 IBM Cloud Private
要将 IBM Cloud Private 安装到 VirtualBox 环境，请参阅[在 VirtualBox 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox)。
<!--
## IBM Cloud Private on VMware
-->
## VMware 上的 IBM Cloud Private
<!--
You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects:
-->
您可以使用 Ubuntu 或 RHEL 镜像在 VMware 上安装 IBM Cloud Private。有关详细信息，请参见以下项目：
<!--
* [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
* [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
-->
* [使用 Ubuntu 安装IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
* [使用 Red Hat Enterprise 安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
<!--
The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.
-->
IBM Cloud Private Hosted 服务会自动在您的 VMware vCenter Server 实例上部署 IBM Cloud Private Hosted。此服务将微服务和容器的功能带到 IBM Cloud上的VMware 环境中。使用此服务，您可以将同样熟悉的 VMware 和 IBM Cloud Private 操作模型和工具从本地扩展到 IBM Cloud。
<!--
For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted).
-->
有关更多信息，请参阅 [IBM Cloud Private Hosted 服务](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted)。
content/zh/docs/setup/production-environment/turnkey/tencent.md
+44
View File
@@ -0,0 +1,44 @@
---
title: 在腾讯云容器服务上运行 Kubernetes
---
<!--
---
title: Running Kubernetes on Tencent Kubernetes Engine
---
-->
<!--
## Tencent Kubernetes Engine
[Tencent Cloud Tencent Kubernetes Engine (TKE)](https://intl.cloud.tencent.com/product/tke) provides native Kubernetes container management services. You can deploy and manage a Kubernetes cluster with TKE in just a few steps. For detailed directions, see [Deploy Tencent Kubernetes Engine](https://intl.cloud.tencent.com/document/product/457/11741).
TKE is a [Certified Kubernetes product](https://www.cncf.io/certification/software-conformance/).It is fully compatible with the native Kubernetes API.
-->
## 腾讯云容器服务
[腾讯云容器服务（TKE）](https://intl.cloud.tencent.com/product/tke)提供本地 Kubernetes 容器管理服务。您只需几个步骤即可使用 TKE 部署和管理 Kubernetes 集群。有关详细说明，请参阅[部署腾讯云容器服务](https://intl.cloud.tencent.com/document/product/457/11741)。
TKE 是[认证的 Kubernetes 产品](https://www.cncf.io/certification/software-conformance/)。它与原生 Kubernetes API 完全兼容。
<!--
## Custom Deployment
The core of Tencent Kubernetes Engine is open source and available [on GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/).
When using TKE to create a Kubernetes cluster, you can choose managed mode or independent deployment mode. In addition, you can customize the deployment as needed; for example, you can choose an existing Cloud Virtual Machine instance for cluster creation or enable Kube-proxy in IPVS mode.
-->
## 定制部署
腾讯 Kubernetes Engine 的核心是开源的，并且可以在 [GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/) 上使用。
使用 TKE 创建 Kubernetes 集群时，可以选择托管模式或独立部署模式。另外，您可以根据需要自定义部署。例如，您可以选择现有的 Cloud Virtual Machine 实例来创建集群，也可以在 IPVS 模式下启用 Kube-proxy。
<!--
## What's Next
To learn more, see the [TKE documentation](https://intl.cloud.tencent.com/document/product/457).
-->
## 下一步
要了解更多信息，请参阅 [TKE 文档](https://intl.cloud.tencent.com/document/product/457)。
content/zh/docs/setup/production-environment/windows/_index.md
+9
View File
@@ -0,0 +1,9 @@
---
title: "Windows Kubernetes"
weight: 50
---
<!--
title: "Windows in Kubernetes"
weight: 50
-->
content/zh/docs/setup/production-environment/windows/kubecluster.ps1-install.gif
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.9 MiB

content/zh/docs/setup/production-environment/windows/kubecluster.ps1-join.gif
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.5 MiB

content/zh/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 MiB

content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md
+244
View File
@@ -0,0 +1,244 @@
---
reviewers:
- michmike
- patricklang
title: Kubernetes 中调度 Windows 容器的指南
content_template: templates/concept
weight: 75
---
<!--
---
reviewers:
- michmike
- patricklang
title: Guide for scheduling Windows containers in Kubernetes
content_template: templates/concept
weight: 75
---
-->
{{% capture overview %}}
<!--
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
-->
Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
{{% /capture %}}
{{% capture body %}}
<!--
## Objectives
* Configure an example deployment to run Windows containers on the Windows node
* (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA)
-->
## 目标
* 配置一个示例 deployment 以在 Windows 节点上运行 Windows 容器
* （可选）使用组托管服务帐户（GMSA）为您的 Pod 配置 Active Directory 身份
<!--
## Before you begin
* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](../user-guide-windows-nodes)
* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided simply to jumpstart your experience with Windows containers.
-->
## 在你开始之前
* 创建一个 Kubernetes 集群，其中包括一个[运行 Windows Server 的主节点和工作节点](../user-guide-windows-nodes)
* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 上创建和部署服务和工作负载的行为几乎相同。与集群接口的 [Kubectl 命令](/docs/reference/kubectl/overview/)相同。提供以下部分中的示例只是为了快速启动 Windows 容器的使用体验。
<!--
## Getting Started: Deploying a Windows container
To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
-->
## 入门：部署 Windows 容器
要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。下面的示例 YAML 文件创建了一个简单的 Web 服务器应用程序。创建一个名为 `win-webserver.yaml` 的服务规约，其内容如下：
```yaml
apiVersion: v1
kind: Service
metadata:
name: win-webserver
labels:
app: win-webserver
spec:
ports:
# the port that this service should serve on
- port: 80
targetPort: 80
selector:
app: win-webserver
type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: win-webserver
name: win-webserver
spec:
replicas: 2
selector:
matchLabels:
app: win-webserver
template:
metadata:
labels:
app: win-webserver
name: win-webserver
spec:
containers:
- name: windowswebserver
image: mcr.microsoft.com/windows/servercore:ltsc2019
command:
- powershell.exe
- -command
- "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
nodeSelector:
beta.kubernetes.io/os: windows
```
{{< note >}}
<!--
Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
-->
端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。
{{< /note >}}
<!--
1. Check that all nodes are healthy:
```bash
kubectl get nodes
```
1. Deploy the service and watch for pod updates:
```bash
kubectl apply -f win-webserver.yaml
kubectl get pods -o wide -w
```
When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C.
1. Check that the deployment succeeded. To verify:
* Two containers per pod on the Windows node, use `docker ps`
* Two pods listed from the Linux master, use `kubectl get pods`
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
* Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
-->
1. 检查所有节点是否健康：
```bash
kubectl get nodes
```
1. 部署服务并观察 pod 更新：
```bash
kubectl apply -f win-webserver.yaml
kubectl get pods -o wide -w
```
正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
1. 检查部署是否成功。验证：
* Windows 节点上每个 Pod 有两个容器，使用 `docker ps`
* Linux 主机列出两个 Pod，使用 `kubectl get pods`
* 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应
* Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 pod 之间（以及跨主机，如果您有多个 Windows 节点）进行 ping 操作
* 服务到 Pod 的通信，从 Linux 主服务器和各个 Pod 中 `curl` 虚拟服务 IP（在 `kubectl get services` 下可见）
* 服务发现，使用 Kubernetes `curl` 服务名称[默认 DNS 后缀](/docs/concepts/services-networking/dns-pod-service/#services)
* 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort
* 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
{{< note >}}
<!--
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
-->
由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。
{{< /note >}}
<!--
## Using configurable Container usernames
Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
-->
## 使用可配置的容器用户名
从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名来运行其入口点和进程。此能力的实现方式和 Linux 容器有些不同。在[此处](/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。
<!--
## Managing Workload Identity with Group Managed Service Accounts
Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
-->
## 使用组托管服务帐户管理工作负载身份
从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。在[此处](/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
<!--
## Taints and Tolerations
-->
## 污点和容忍度
<!--
Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
-->
目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，因而需要结合使用污点和节点选择算符。这可能仅给 Windows 用户造成不便。推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
<!--
### Ensuring OS-specific workloads land on the appropriate container host
-->
### 确保特定操作系统的工作负载落在适当的容器主机上
<!--
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
-->
用户可以使用污点和容忍度确保 Windows 容器可以调度在适当的主机上。目前所有 Kubernetes 节点都具有以下默认标签：
* beta.kubernetes.io/os = [windows|linux]
* beta.kubernetes.io/arch = [amd64|arm64|...]
<!--
If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
-->
如果 Pod 规范未指定诸如 `"beta.kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod 可能会被调度到任何主机（Windows 或 Linux）上。这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。最佳实践是使用 nodeSelector。
<!--
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
-->
但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。
<!--
For example: `--register-with-taints='os=Win1809:NoSchedule'`
-->
例如：`--register-with-taints='os=Win1809:NoSchedule'`
<!--
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
-->
向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows，也需要合适的匹配的容忍度设置。
```yaml
nodeSelector:
"beta.kubernetes.io/os": windows
tolerations:
- key: "os"
operator: "Equal"
value: "Win1809"
effect: "NoSchedule"
```
{{% /capture %}}