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

Merge release 1.12 into release 1.13 (#14171)

Browse Source 
* ZH-trans: Update coarse-parallel-processing-work-queue.md (#11862)

* ZH-trans: Update coarse-parallel-processing-work-queue.md

* Update coarse-parallel-processing-work-queue.md

* zh-trans: add /docs/concepts/architecture/cloud-controller.md (#11799)

* docs/concepts/architecture/cloud-controller.md

* docs/concepts/architecture/cloud-controller.md

* docs/concepts/architecture/cloud-controller.md

* fix

* fix

* fix

* zh-trans: /docs/contribute/style/kubernetes-components.md (#11838)

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

zh-trans: /docs/contribute/generate-ref-docs/kubernetes-components.md; update

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

* Update weave-network-policy.md (#11858)

* ZH-trans: add Update define-environment-variable-container.md (#11859)

* Update define-environment-variable-container.md

* Update define-environment-variable-container.md

* Update define-environment-variable-container.md

* Update define-environment-variable-container.md

* Update define-environment-variable-container.md

* Update fine-parallel-processing-work-queue.md (#11863)

* Update fine-parallel-processing-work-queue.md

* Update fine-parallel-processing-work-queue.md

* Update setup-extension-api-server.md (#11864)

* zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md (#11798)

* zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md

zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md

* Update kubeadm-join.md

* Create kubeadm_join.md

* zh-trans: update docs/concepts/containers/images.md (#11877)

* zh-trans: update docs/concepts/containers/images.md

* zh-trans: update docs/concepts/containers/images.md

* Update kubeadm_alpha_phase_controlplane.md (#11878)

* 更新第 115 行翻译

* zh_trans: kubeadm_token_generate.md (#11884)

* zh_trans: kubeadm_token_generate.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md

* Better translation  

Better translation
 

* zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md (#11886)

zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md

* zh-trans:add content/zh/docs/reference/issues-security (#11890)

* zh-trans: add content/zh/docs/tutorials/online-training/overview.md (#11892)

* zh_trans: kubeadm_token_delete.md (#11883)

* zh_trans: kubeadm_token_delete.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md

* fix tpye error

fix tpye error

*  Better translation  

Better translation

* zh_trans: independent/create-cluster-kubeadm.md (#11882)

* zh_trans: independent/create-cluster-kubeadm.md

zh_trans: docs/setup/independent/create-cluster-kubeadm.md

* fix word style error

* fix type error

* better zhtran

better zhtran

* fix "Create" -> "create"

fix "Create" -> "create"

* zh-trans: add docs⁩/concept⁨s/storage/storage-classes.md (#11788)

* ZH-trans: fixing formatting errors (#11661)

* ZH-trans: fixing formatting errors

* Update ZH-trans: fixing formatting errors

storage-classes zh part 1

* storage-classes zh trans

* fix typo

update trans for provisioner & fix typo

* fix typo

* 根据校对更新翻译

* zh_trans: kubeadm-token.md (#11898)

zh_trans: /docs/reference/setup-tools/kubeadm/kubeadm-token.md

* zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md (#11900)

* zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md

zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md

* Update quality-service-pod.md

* zh_trans: kubeadm_alpha_phase_bootstrap-token_node.md (#11897)

zh_trans: Path：/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md

* zh-trans: add /docs/concepts/storage/volumes.md (#11767)

* zh-trans: add /docs/concepts/storage/volumes.md

zh-trans: add /docs/concepts/storage/volumes.md

* Update volumes.md

* Update volumes.md

* self-review

* Update volumes.md

* fix docs format error (#11934)

fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/

* Update cloud-controller.md (#11922)

* zh-trans: /docs/reference/glossary/approver.md (#11924)

zh-trans: /docs/reference/glossary/approver.md

* zh-trans: add docs/setup/on-premises-vm/dcos.md (#11891)

* zh-trans: add docs/setup/on-premises-vm/dcos.md

* Update content/zh/docs/setup/on-premises-vm/dcos.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: /docs/tasks/configure-pod-container/configure-persistent-vo… (#11915)

* zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

* Update configure-persistent-volume-storage.md

* zh_trans: kubeadm_alpha.md (#11902)

* zh_trans: kubeadm_alpha.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md

* Better translation

Better translation

* zh-trans: /docs/reference/glossary/downstream.md (#11931)

* zh-trans: /docs/reference/glossary/downstream.md

zh-trans: /docs/reference/glossary/downstream.md

* Update downstream.md

* Update downstream.md

* ZH-trans: Update install-kubeadm.md (#11955)

* fix typo of install-kubeadm.md

fix typo of install-kubeadm.md

* Update install-kubeadm.md

* zh-trans: add kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md (#11952)

* zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md

zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md

* Update kubeadm_alpha_phase_certs_renew_all.md

* renew 的翻译更新为续期

* zh-trans:kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md (#11953)

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md

/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md

* Update kubeadm_alpha_phase_certs_renew_etcd-peer.md

* zh-trans: /docs/contribute/generate-ref-docs/kubectl.md (#11941)

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

* fix docs format error (#11936)

fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/

* Update pull request (#11921)

* Update pull request (#11960)

* ZH-trans: add kubefed-options.md (#11956)

* Update ZH-trans: add kubefed-options.md

* Update kubefed-options.md

* ZH-trans: add generated/... (#11880)

* Update pull request

* Update kubeadm_alpha_phase_certs_renew.md

* Update pull request (#11881)

* ZH-trans: add generated/... (#11879)

* Update pull request

* Resolving file conflicts

* zh-trans: add zh/ docs/tasks/configure-pod-container/configure-servic… (#11889)

* zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md

zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md

* Update configure-service-account.md

* Update configure-service-account.md

* zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md (#11875)

* zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md

* zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md

* zh-trans:update kubelet-garbage-collection.md

* zh_trans: kubeadm_alpha_phase_kubeconfig_user.md (#11901)

* zh_trans: kubeadm_alpha_phase_kubeconfig_user.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md

* Better translation

* zh-trans:add docs/reference/using-api/client-libraries.md (#11958)

* zh-trans:add docs/reference/using-api/client-libraries.md

* Update content/zh/docs/reference/using-api/client-libraries.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: add pull-image-private-registry.md (#11912)

* zh-trans: add pull-image-private-registry.md

zh-trans: add pull-image-private-registry.md

* Update pull-image-private-registry.md

* Update pull-image-private-registry.md

* ZH-trans: add kubeadm_alpha_phase_kubelet_config_annotate-cri.md (#11972)

* Create kubeadm_alpha_phase_kubelet_config_annotate-cri.md

* Update kubeadm_alpha_phase_kubelet_config_annotate-cri.md

* ZH-trans: add kubeadm_alpha_phase_kubelet_config.md (#11974)

* Create kubeadm_alpha_phase_kubelet_config.md

* Update kubeadm_alpha_phase_kubelet_config.md

* fix Typo "##" -> "## " (#12011)

* fix Typo "##" -> "## "

fix Typo "##" -> "## "

* update basic-stateful-set.md

* fix web style error (#12010)

fix web style error

* Create kubeadm_alpha_phase_selfhosting.md (#12006)

* Create kubeadm_alpha_phase_controlplane_apiserver.md (#12005)

* zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitor… (#11995)

* zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md

zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md

* Update resource-usage-monitoring.md

* Update resource-usage-monitoring.md

* zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md (#11990)

zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md

* zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md (#11989)

zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md

* Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md (#11969)

* Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md

* Update kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md

* zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md (#11962)

* zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md

zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md

* Update debug-init-containers.md

* zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md (#11930)

* zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md

zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md

* Update horizontal-pod-autoscaler.md

* zh-trans: add /docs/tasks/configure-pod-container/configure-projected… (#11911)

* zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md

zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md

* Update configure-projected-volume-storage.md

* Update configure-projected-volume-storage.md

* zh-trans: /docs/tasks/configure-pod-container/extended-resource.md (#11918)

* zh-trans: /docs/tasks/configure-pod-container/extended-resource.md

zh-trans: /docs/tasks/configure-pod-container/extended-resource.md

* Update extended-resource.md

* Update extended-resource.md

* zh-trans: add translate-compose-kubernetes.md (#11910)

* zh-trans: add translate-compose-kubernetes.md

zh-trans: add translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* Update translate-compose-kubernetes.md

* zh-trans: zh/docs/reference/glossary/flexvolume.md (#11925)

* zh-trans: zh/docs/reference/glossary/flexvolume.md

zh-trans: zh/docs/reference/glossary/flexvolume.md

* Update flexvolume.md

* zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md (#11947)

* zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_create.md

* better translation  

better translation  

* zh-trans:add docs/setup/turnkey/alibaba-cloud.md (#11959)

* zh_trans: kubeadm_completion.md (#11895)

* zh_trans: kubeadm_completion.md

zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md

* Better translation  

Better translation

* Update kubeadm_completion.md

* better translation

better translation

* zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md (#11961)

* zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md

zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md

* Update crictl.md

* ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-ca.md (#11968)

* ZH-trans: add kubeadm_alpha_phase_controlplane_all.md (#11970)

* Create kubeadm_alpha_phase_controlplane_all.md

* Update kubeadm_alpha_phase_controlplane_all.md

* Update kubeadm_alpha_phase_controlplane_all.md

* Update kubeadm_alpha_phase_controlplane_all.md

* ZH-trans: add kubeadm_alpha_phase_upload-config.md (#11971)

* Create kubeadm_alpha_phase_upload-config.md

* Update kubeadm_alpha_phase_upload-config.md

* Update kubeadm_alpha_phase_upload-config.md

* ZH-trans: Fixed some incorrect translations (#11973)

* zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-… (#11977)

* zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md

zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md

* Update determine-reason-pod-failure.md

* zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md (#11988)

* zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md

zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md

* Update local-debugging.md

* zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md (#11996)

zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md

* zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-cont… (#11998)

* zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md

zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md

* Update get-shell-running-container.md

* zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md (#12001)

zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md

* ZH-trans: ad kubeadm_alpha_phase_kubelet_config_write-to-disk.md (#12004)

* Create kubeadm_alpha_phase_kubelet_config_write-to-disk.md

* Update kubeadm_alpha_phase_kubelet_config_write-to-disk.md

* Remove old-generated kubefed docs (generated on 25-march-2018) (#12093)

* Update _index.md (#12061)

* Update kubeadm_reset.md (#12047)

* ZH-trasn: add kubeadm_alpha_phase_kubeconfig_controller-manager.md (#12032)

* Create kubeadm_alpha_phase_kubeconfig_controller-manager.md

* Update kubeadm_alpha_phase_kubeconfig_controller-manager.md

* ZH-trans: add kubeadm_alpha_phase_preflight_node.md (#12035)

* Create kubeadm_alpha_phase_preflight_node.md

* Update kubeadm_alpha_phase_preflight_node.md

* Update kubeadm_alpha_phase_preflight_node.md

* ZH-trans: add kubeadm_alpha_phase_controlplane_scheduler.md (#12031)

* Create kubeadm_alpha_phase_controlplane_scheduler.md

* Update kubeadm_alpha_phase_controlplane_scheduler.md

* ZH-trans: add kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md (#12039)

* Create kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md

* Update kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md

* ZH-trans: add kubeadm_alpha_phase_kubelet_write-env-file.md (#12034)

* Create kubeadm_alpha_phase_kubelet_write-env-file.md

* Update kubeadm_alpha_phase_kubelet_write-env-file.md

* ZH-trans: add kubeadm_upgrade_node_experimental-control-plane.md (#12036)

* Create kubeadm_upgrade_node_experimental-control-plane.md

* Update kubeadm_upgrade_node_experimental-control-plane.md

* Create kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md (#12038)

* Create kubeadm_alpha_phase_etcd.md (#12040)

* ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-server.md (#12041)

* Create kubeadm_alpha_phase_certs_renew_etcd-server.md

* Update kubeadm_alpha_phase_certs_renew_etcd-server.md

* Update advanced.md (#12044)

* ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md (#12042)

* Create kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md

* Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md

* Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md

* Update kubeadm_version.md (#12046)

* Update _index.md (#12063)

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md (#12085)

zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md

* ZH-trans: add kubeadm_alpha_phase_certs_etcd-peer.md (#12037)

* Create kubeadm_alpha_phase_certs_etcd-peer.md

* Update kubeadm_alpha_phase_certs_etcd-peer.md

* Update kubeadm_alpha_phase_certs_etcd-peer.md

* ZH-trans: add kubeadm_alpha_phase_kubelet_config_download.md (#12033)

* Create kubeadm_alpha_phase_kubelet_config_download.md

* Update kubeadm_alpha_phase_kubelet_config_download.md

* zh-trans: add docs/tasks/access-application-cluster/_index.md (#12048)

* zh-trans: update cpu-constraint-namespace.md and cpu-default-namespace.md (#12106)

* ZH-trans: update kubeadm_alpha_phase_upload-config.md (#12110)

* zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md (#12022)

* zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md

zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md

* Update kubefed_unjoin.md

* Update kubefed_unjoin.md

* Update kubefed_unjoin.md

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12114)

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md

zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md

* Update kubeadm_alpha_phase_certs_apiserver.md

* Update kubeadm_alpha_phase_certs_apiserver.md

* zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md (#12088)

* zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md

zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md

* Update docker-cli-to-kubectl.md

* zh-trans: /docs/reference/kubectl/conventions.md (#12089)

* zh-trans: /docs/reference/kubectl/conventions.md

zh-trans: /docs/reference/kubectl/conventions.md

* Update conventions.md

* zh-trans organize-cluster-access-kubeconfig.md (#12094)

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md (#12086)

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md

zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md

* Update kubefed.md

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md (#12029)

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md

zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md

* Update kubefed_join.md

* Update kubefed_join.md

* zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md (#12020)

* zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md

zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md

* Update kubefed_init.md

* Update kubefed_init.md

* Update kubefed_init.md

* zh-trans: add docs/setup/independent/control-plane-flags.md (#12043)

* zh-trans: add docs/setup/independent/control-plane-flags.md

* update content/zh/docs/setup/independent/control-plane-flags.md

* zh-trans:/docs/tasks/tools/install-kubectl.md (#11992)

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* .

* .

* configure-aggregation-layer.md

* .

* .

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* zh-trans: add /docs/concepts/cluster-administration/manage-deployment.md (#11899)

* add /docs/concepts/cluster-administration/manage-deployment.md

* 更新部分翻译，去除多余的反引号

* 更新部分翻译

* zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md (#12045)

* zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md

* update docs/tasks/service-catalog/install-service-catalog-using-sc.md

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md (#12087)

* zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md

zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md

* Update kubefed_options.md

* Update kubefed_options.md

* zh-trans: Fix some blog links issue (#12115)

* zh-trans: Fix some blog links issue

* Revert the space change

* update Set Kubelet parameters via a config file (#12150)

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md (#12185)

zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12184)

* zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md

zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md

* Update kubeadm_alpha_phase_etcd_local.md

* zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md (#12130)

zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md

* zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md (#12131)

zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md

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

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

* zh-trans:/docs/concepts/overview/object-management-kubectl/imperative… (#12151)

* zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md

zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md

* Update imperative-config.md

* ZH-trans: added a blog post Chinese translation: 2018-05-01-developing-on-kubernetes.md (#12009)

* added a blog post chinese translation

* Update 2018-05-01-developing-on-kubernetes.md

apply some suggested changes per review comments

* Update 2018-05-01-developing-on-kubernetes.md

cont to review and improve the wording, up to squash

* more update and rewording

* ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md (#12209)

* ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md

* Update kubeadm_alpha_phase_kubelet_config_enable-dynamic.md

* ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md (#12210)

* ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md

* Update kubeadm_alpha_phase_certs_renew_apiserver.md

* Update kubeadm_alpha_phase_certs_renew_apiserver.md

* ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-client.md (#12212)

* fix docs style (#12225)

* fix docs style

fix docs style

* fix docs style

fix docs style

* ZH-trans: add rbac.md (#12263)

* ZH-trans: add rbac.md

* Update rbac.md

* ZH-trans: add persistent-volume-claim.md (#12264)

* ZH-trans: add persistent-volume-claim.md

* Update persistent-volume-claim.md

* Update persistent-volume-claim.md

* Update docker-cli-to-kubectl.md (#12288)

* ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md (#12285)

* ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md

* Update kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md

* ZH-trans: add coredns.md (#12282)

* ZH-trans: add coredns.md

* Update coredns.md

* ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md (#12286)

* ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md

* Update kubeadm_alpha_phase_certs_etcd-healthcheck-client.md

* ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md (#12284)

* ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md

* Update kubeadm_alpha_phase_kubeconfig_kubelet.md

* ZH-trans: add service-account.md (#12261)

* ZH-trans: add service-account.md

* Update service-account.md

* ZH-trans: add security-context.md (#12262)

* ZH-trans: add security-context.md

* Update security-context.md

* Update security-context.md

* Update security-context.md

* fix typo "_必须_" -> "必须" (#12300)

fix typo "_必须_" -> "必须"

* fix docs style error (#12307)

fix docs style error

* Create explore-interactive.html (#12311)

* fix docs style error (#12314)

fix docs style error

* ZH-trans: add kube-controller-manager.md (#12260)

* ZH-trans: add kube-controller-manager.md

* Update kube-controller-manager.md

* Update kube-controller-manager.md

* Update kube-controller-manager.md

* zh-trans: /docs/contribute/localization.md (#12295)

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

zh-trans: /docs/contribute/localization.md; update

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

zh-trans: /docs/contribute/localization.md; update2

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

* ZH-trans: update tools.md (#12320)

ZH-trans: update tools.md

* ZH-trans: fix "kubead -config" -> "kubeadm-config" (#12319)

* ZH-trans: update kubeadm_config.md

* fix style error

* correct "availability” trans for chinese (#12394)

* ZH-trans:/docs/tasks/debug-application-cluster/debug-service.md (#12275)

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* .

* .

* configure-aggregation-layer.md

* .

* .

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* .

* .

* Translate some remnant partials for localization (#12240)

* zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md (#12415)

* zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md

zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md

* Update limit-storage-consumption.md

* Update limit-storage-consumption.md

* update link to SSH tunneling (#12615)

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

* zh-trans: update content/zh/docs/setup/certificates.md (#12620)

* ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md (#12619)

* ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md

* Update kubeadm_alpha_phase_certs_apiserver-kubelet-client.md

* zh-trans: node-conformance.md (#12356)

* zh-trans: node-conformance.md

zh-trans: node-conformance.md

* better translation

better translation

* zh-trans: translate docs/getting-started-guides/ubuntu/operational-co… (#12353)

* zh-trans: translate docs/getting-started-guides/ubuntu/operational-considerations.md

* Adopt PR suggestions

* add period sign

* zh-trans: krib.md (#12363)

* zh-trans: krib.md

zh-trans: krib.md

* Update krib.md

* Update krib.md

* Update krib.md

* Update krib.md

* zh-trans: /docs/tasks/administer-federation/events.md (#12411)

* zh-trans: /docs/tasks/administer-federation/events.md

zh-trans: /docs/tasks/administer-federation/events.md

* Update events.md

* Update events.md

* zh-trans: /docs/setup/turnkey/azure.md (#12412)

zh-trans: /docs/setup/turnkey/azure.md

* zh-trans:/docs/tasks/administer-federation/hpa.md & /docs/tasks/administer-cluster/extended-resource-node.md (#12432)

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* .

* .

* configure-aggregation-layer.md

* .

* .

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* Add arm64, ppc64le and s390x platforms for calico (#12666)

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

add only

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

* zh-trans: developing-cloud-controller-manager.md (#12413)

* zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md

zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md

* Update developing-cloud-controller-manager.md

* fix typo: delete useless "**"

* Update developing-cloud-controller-manager.md

* ZH-trans: add 2018-05-01-developing-on-kubernetes.md (#12814)

* ZH-trans: update encrypt-data.md (#12939)

* ZH-trans: update encrypt-data.md

* Update encrypt-data.md

* ZH-trans: add example-task-template.md (#12940)

* ZH-trans: add example-task-template.md

* Update example-task-template.md

* Added Instana to tools (#12978)

Instana is already available in the english version of the text, therefore I added it here too. Hope my skills were enough to make the text still correct :-)

* ZH-trans: add expose-interactive.html (#12965)

* ZH-trans: add expose-interactive.html

* Update content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html

Co-Authored-By: xichengliudui <1693291525@qq.com>

* ZH-trans: add cloudstack.md (#12967)

* Create cloudstack.md

* Update cloudstack.md

* Update cloudstack.md

* Update cloudstack.md

* ZH-trans: add container-lifecycle-hooks.md (#12941)

* ZH-trans: add container-lifecycle-hooks.md

* Update container-lifecycle-hooks.md

* translate content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md to chinese (#12904)

* ZH-trans: add expose-external-ip-address.md (#12955)

* ZH-trans: add expose-external-ip-address.md

* Update expose-external-ip-address.md

* Update expose-external-ip-address.md

* Update expose-external-ip-address.md

* Update expose-external-ip-address.md

* Update expose-external-ip-address.md

* ZH-trans: add dns-horizontal-autoscaling.md (#12948)

* ZH-trans: add dns-horizontal-autoscaling.md

* Update dns-horizontal-autoscaling.md

* Update dns-horizontal-autoscaling.md

* zh-trans: update content/zh/docs/concepts/_index.md (#13182)

* zh-trans: update content/zh/docs/reference/access-authn-authz/node.md (#13181)

* Update dns-horizontal-autoscaling.md (#13119)

* Update dns-horizontal-autoscaling.md

* Update dns-horizontal-autoscaling.md

* Update dns-horizontal-autoscaling.md

* ZH-trans: add 2018-10-03-kubedirector.md (#13048)

* ZH-trans: add 2018-10-03-kubedirector.md

* Update 2018-10-03-kubedirector.md

* Update 2018-10-03-kubedirector.md

* ZH-trans: add guestbook.md (#12953)

* ZH-trans: add guestbook.md

* Update guestbook.md

* Update guestbook.md

* Update guestbook.md

* Update guestbook.md

* ZH-trans: add set-up-placement-policies-federation.md (#12947)

* ZH-trans: add set-up-placement-policies-federation.md

* update pull request

* Update set-up-placement-policies-federation.md

* Update set-up-placement-policies-federation.md

* Update set-up-placement-policies-federation.md

* Update set-up-placement-policies-federation.md

* ZH-trans: add service-accounts-admin.md (#13047)

* ZH-trans: add service-accounts-admin.md

* Update service-accounts-admin.md

* Update service-accounts-admin.md

* ZH-trans: add update-api-object-kubectl-patch.md (#12943)

* ZH-trans: add update-api-object-kubectl-patch.md

* Update update-api-object-kubectl-patch.md

* Update update-api-object-kubectl-patch.md

* Update update-api-object-kubectl-patch.md

* Update update-api-object-kubectl-patch.md

* ZH-trans: add parallel-processing-expansion.md (#12944)

* ZH-trans: add parallel-processing-expansion.md

* Update parallel-processing-expansion.md

* Update parallel-processing-expansion.md

* zh-trans: add 2018-12-05-new-contributor-shanghai.md (#12778)

* add zh 2017-03-00-Five-Days-Of-Kubernetes-1-6.md

add zh 2018-12-05-new-contributor-shanghai.md

* Delete 2017-03-00-Five-Days-Of-Kubernetes-1-6.md

* zh-trans: /docs/contribute/style/write-new-topic.md (#12572)

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

zh-trans: /docs/contribute/style/write-new-topic.md; update

Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn>

* zh-trans: update content/zh/docs/setup/salt.md (#13202)

* zh-trans: add docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#13198)

* ZH-trans: add kubeadm_upgrade_diff.md (#13170)

* ZH-trans: add kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* zh-trans: update docs/reference/access-authn-authz/authorization.md (#13180)

* zh-trans: update docs/reference/setup-tools/kubeadm/kubeadm-config.md (#13179)

* zh-trans: add docs/concepts/storage/dynamic-provisioning.md (#13171)

* ZH-trans: add 2015-05-00-Kubernetes-On-Openstack.md (#13149)

* ZH-trans: add Kubernetes开源项目产品经理

* Update 2015-05-00-Kubernetes-On-Openstack.md

* ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md (#13131)

* ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md

* Update 2015-03-00-Welcome-To-Kubernetes-Blog.md

* ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md (#13123)

* ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md

* Update 2015-06-00-Slides-Cluster-Management-With.md

* Create 2015-03-00-Kubernetes-Gathering-Videos.md (#13124)

* ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md (#13129)

* ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md

* Update 2015-03-00-Weekly-Kubernetes-Community-Hangout.md

* ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md (#13130)

* ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md

* Update 2015-04-00-Kubernetes-Release-0150.md

* ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md (#13132)

* ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md

* Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md

* Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md

* Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md

* ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md (#13147)

* ZH-trans: add 2015-05-00-Weekly-Kubernetes-Community-Hangout.md (#13148)

* ZH-trans: add flannel_multi_node_cluster.md (#13195)

* ZH-trans: add flannel_multi_node_cluster.md

* Update flannel_multi_node_cluster.md

* Update flannel_multi_node_cluster.md

* zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md (#13200)

* zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md

* Update kubelet-authentication-authorization.md

* zh-trans: /docs/tasks/administer-cluster/out-of-resource.md (#12879)

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* configure-aggregation-layer.md

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* .

* .

* configure-aggregation-layer.md

* .

* .

* Update configure-aggregation-layer.md

* .

* .

* .

* .

* .

* .

* zh-trans: update docs/setup/node-conformance.md (#13201)

* zh-trans: update docs/setup/node-conformance.md

* zh-trans: update docs/setup/on-premises-vm/dcos.md

* zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md (#13227)

* zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md

* Update content/zh/blog/_posts/2018-10-15-steering-election-results.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Add @xichengliudui to sig-docs-zh-owners (release-1.12) (#13167)

* Add @xichengliudui to sig-docs-zh-owners

* Update OWNERS_ALIASES

* ZH-trans: add coreos.md (#13193)

* ZH-trans: coreos.md

* Update coreos.md

* Update coreos.md

* Update coreos.md

* Update coreos.md

* Update coreos.md

* Update coreos.md

* add SataQiu as a sig-docs-zh-owner (#13271)

* Fix relative links issue in zh content (#13312)

* `http://kubernetes.io/docs/` -> `/docs/`

* `https://kubernetes.io/docs/` -> `/docs/`

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

* zh-trans: add docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md

* Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update kubeadm-upgrade.md

* ZH-trans: add kubeadm-upgrade-ha-1-12.md (#13306)

* ZH-trans: add kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update kubeadm-upgrade-ha-1-12.md

* Update config.toml (#13408)

* zh-trans: add content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md (#13221)

* zh-trans: add content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md (#13236)

* zh-trans: add content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md (#13274)

* zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md (#13268)

* zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md

* Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md

* ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13427)

* ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md

* Update 2017-10-00-Five-Days-Of-Kubernetes-18.md

* zh-trans: add content/zh/docs/tasks/administer-federation/daemonset.md (#13239)

* message

* more message

* remove data.json

* ZH-trans: add aws.md (#13276)

* ZH-trans: add aws.md

* Update aws.md

* Update aws.md

* ZH-trans: add cluster-interactive.html (#13479)

* ZH-trans: add cluster-interactive.html

* Update cluster-interactive.html

* ZH-trans: add update-intro.html (#13480)

* Create update-intro.html

* Update update-intro.html

* Update update-intro.html

* Update update-intro.html

* Update update-intro.html

* Update update-intro.html

* ZH-trans: add README.md (#13235)

* ZH-trans: add vendoring

* Update README.md

* zh: docs/cocepts/cluster-administration/logging.md (#13541)

* zh: docs/cocepts/cluster-administration/logging.md

* Update logging.md

* zh-trans: update docker-cli-to-kubectl.md (#13591)

* Update docker-cli-to-kubectl.md

* Update docker-cli-to-kubectl.md

* zh-trans: update advanced.md (#13592)

* ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md (#13424)

* ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md

* Update 2017-11-00-Autoscaling-In-Kubernetes.md

* ZH-trans: add fedora_manual_config.md (#13439)

* ZH-trans: add fedora_manual_config.md

* Update fedora_manual_config.md

* zh-trans: content/zh/docs/concepts/overview/working-with-objects/labe… (#12277)

* zh-trans: content/zh/docs/concepts/overview/working-with-objects/labels.md

* update trans

* update trans

*  zh: docs/contribute/start.md trans (#13632)

* zh：docs/contribute/start.md trans

* Update start.md

* Update start.md

* Update start.md

* Update start.md

* Update content/zh/docs/contribute/start.md

Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com>

* Update content/zh/docs/contribute/start.md

Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com>

* Update content/zh/docs/contribute/start.md

Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com>

* zh-trans: update docs/reference/setup-tools/kubefed (#13729)

* Update 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13472)

* zh-trans: add configure-multiple-schedulers.md (#13492)

* zh-trans: add configure-multiple-schedulers.md

* Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update configure-multiple-schedulers.md

* Update configure-multiple-schedulers.md

* Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update configure-multiple-schedulers.md

* zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md (#13551)

* zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md

* Update share-process-namespace.md

* zh-trans: update docs/admin/accessing-the-api.md (#13744)

* zh-trans: add content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md (#13303)

* ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md (#13241)

* ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md

* Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md

* Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md

* ZH-trans: add  2016-07-00-Citrix-Netscaler-And-Kubernetes.md (#13242)

* ZH-trans: add  2016-07-00-Citrix-Netscaler-And-Kubernetes.md

* Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md

* Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md

* zh-trans: update docs/admin/bootstrap-tokens.md (#13770)

* zh-trans: update content/zh/docs/admin/cluster-large.md (#13771)

* zh-trans: update content/zh/docs/admin/kube-apiserver.md (#13774)

* zh-trans: update content/zh/docs/admin/kube-apiserver.md

* Update kube-apiserver.md

* Update content/zh/docs/admin/kube-apiserver.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: update content/zh/docs/admin/multiple-zones.md (#13775)

* zh-trans: update content/zh/docs/admin/multiple-zones.md

* Update multiple-zones.md

* zh-trans: update node-conformance.md and ovs-networking.md (#13776)

* zh-trans: update high-availability/_index.md and authorization/webhook.md (#13780)

* zh-trans: update content/zh/docs/admin/authorization/_index.md (#13779)

* zh-trans: update content/zh/docs/admin/authorization/_index.md

* Update _index.md

* Update content/zh/docs/admin/authorization/_index.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/admin/authorization/_index.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update content/zh/docs/admin/authorization/_index.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: update content/zh/docs/admin/authorization/abac.md (#13777)

* zh-trans: update content/zh/docs/admin/authorization/abac.md

* Update content/zh/docs/admin/authorization/abac.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* Update abac.md

* zh-trans: update content/zh/docs/admin/service-accounts-admin.md (#13778)

* zh-trans: update content/zh/docs/admin/service-accounts-admin.md

* Update content/zh/docs/admin/service-accounts-admin.md

Co-Authored-By: SataQiu <1527062125@qq.com>

* zh-trans: update content/zh/docs/concepts/architecture (#13797)

* ZH-trans: add cluster.md (#13500)

* ZH-trans: add cluster.md

* Update cluster.md

* Update cluster.md

* Update cluster.md

* zh-trans: update docs/concepts/cluster-administration (#13825)

* Exclude content-en changes in the PR

* Exclude content/ko changes in the PR

* Exclude OWNERS_ALIASES change in the PR

* rm kubeadm/generated/README.md to fix the build

* Remove generated sass assets
This commit is contained in:
chenrui
2019-06-17 12:28:11 -04:00
committed by Kubernetes Prow Robot
parent d437c2e5e5
commit 577b431931
717 changed files with 76342 additions and 1681 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/getting-started-guides/_index.md
Executable
+11
View File
@@ -0,0 +1,11 @@
---
title: "独立解决方案"
weight: 50
---
<!--
---
title: "Independent Solutions"
weight: 50
---
-->
content/zh/docs/getting-started-guides/alternatives.md
+22
View File
@@ -0,0 +1,22 @@
---
title: 弃用的替代品
---
<!--
---
reviewers:
- pwittrock
title: Deprecated Alternatives
---
-->
# *停止。这些指南已被[Minikube](../minikube/)所取代，这里列出它们只是为了保持完整性。*
<!--
# *Stop. These guides are superseded by [Minikube](../minikube/). They are only listed here for completeness.*
-->
* [使用 Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md)
* *更高级的：* [直接使用 Kubernetes 原始二进制程序（仅限 Linux 系统）](https://git.k8s.io/community/contributors/devel/running-locally.md)
<!--
* [Using Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md)
* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://git.k8s.io/community/contributors/devel/running-locally.md)
-->
content/zh/docs/getting-started-guides/fedora/fedora_manual_config.md
+345
View File
@@ -0,0 +1,345 @@
---
reviewers:
- aveshagarwal
- eparis
- thockin
title: Fedora (单节点)
---
<!--
---
reviewers:
- aveshagarwal
- eparis
- thockin
title: Fedora (Single Node)
---
-->
{{< toc >}}
<!--
## Prerequisites
-->
## 前提条件
<!--
1. You need 2 or more machines with Fedora installed. These can be either bare metal machines or virtual machines.
## Instructions
This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc...
This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/concepts/cluster-administration/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious.
The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: `/etc/kubernetes`. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker.
-->
1. 您需要两台或更多机器安装 Fedora。这些机器可以是裸机，也可以是虚拟机。
## 说明
这是 Fedora 的入门指南。配置手工打造，因而需要了解所有底层软件包/服务/端口等等。
本指南只能使一个节点（以前的 minion）工作。多个节点需要在 Kubernetes 之外完成功能性网络配置。尽管额外的 Kubernetes 配置需求是显而易见的。
Kubernetes 包提供了一些服务：kube-apiserver、kube-scheduler、kube-control -manager、kubelet、kube-proxy。这些服务由 systemd 管理，配置位于中心位置：`/etc/kubernetes`。
我们将打破主机之间的服务。第一个主机，fed-master，将是 Kubernetes 主节点。该主节点将运行 kube-apiserver、kube-control-manager 和 kube-scheduler。
此外，主服务器还将运行 *etcd* (如果 *etcd* 运行在不同的主机上就不需要了，但是本指南假设 *etcd* 和 Kubernetes 主服务器在同一主机上运行)。剩下的主机，fed-node 将是节点并运行 kubelet、proxy 和 docker。
<!--
**System Information:**
Hosts:
```conf
fed-master = 192.168.121.9
fed-node = 192.168.121.65
```
-->
**系统信息：**
主机:
```conf
fed-master = 192.168.121.9
fed-node = 192.168.121.65
```
<!--
**Prepare the hosts:**
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond.
* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the `enable=0` to `enable=1` for extras.
-->
**准备主机：**
* 在所有主机（fed-{master，node}）上安装 Kubernetes 。这同时也会安装 docker。接着在 fed-master 上安装 etcd。本指南已经通过 Kubernetes-0.18 及更高版本的测试。
* 在使用 RHEL 7.2 的 AWS EC2 上运行时，您需要通过编辑 `/etc/yum.repos.d/redhat-rhui.repo` 和更改 `enable=0to` 为 `enable=1` 来为 yum 启用 “extras” 仓库。
```shell
dnf -y install kubernetes
```
<!--
* Install etcd
-->
* 安装 etcd
```shell
dnf -y install etcd
```
<!--
* Add master and node to `/etc/hosts` on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping.
-->
* 将主机和节点添加到所有机器上的 `/etc/hosts` (如果主机名已经在 DNS 中，则不需要)。通过使用 ping 等实用程序，确保 fed-master 和 fed-node 之间的通信工作正常。
```shell
echo "192.168.121.9 fed-master
192.168.121.65 fed-node" >> /etc/hosts
```
<!--
* Edit `/etc/kubernetes/config` (which should be the same on all hosts) to set
the name of the master server:
```shell
# Comma separated list of nodes in the etcd cluster
KUBE_MASTER="--master=http://fed-master:8080"
```
-->
* 编辑 `/etc/kubernetes/config` （在所有主机上应该是相同的）来设置主服务器的名称:
```shell
# 逗号分隔的 etcd 群集中的节点列表
KUBE_MASTER="--master=http://fed-master:8080"
```
<!--
* Disable the firewall on both the master and node, as Docker does not play well with other firewall rule managers. Please note that iptables.service does not exist on the default Fedora Server install.
-->
* 禁用主节点和子节点上的防火墙，因为 Docker 与其他防火墙规则管理器不兼容。请注意，默认的 Fedora Server 安装中不存在 iptables.service。
```shell
systemctl mask firewalld.service
systemctl stop firewalld.service
systemctl disable iptables.service
systemctl stop iptables.service
```
<!--
**Configure the Kubernetes services on the master.**
* Edit `/etc/kubernetes/apiserver` to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything.
-->
**在主服务器上配置 Kubernetes 服务。**
* 编辑 `/etc/kubernetes/apiserver`，包含以下内容。`service-cluster-ip-range` 的 IP 地址必须是未使用的地址块，同时也不能在其他任何地方使用。它们不需要路由或分配给任何东西。
<!--
```shell
# The address on the local server to listen to.
KUBE_API_ADDRESS="--address=0.0.0.0"
# Comma separated list of nodes in the etcd cluster
KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"
# Address range to use for services
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
# Add your own!
KUBE_API_ARGS=""
```
-->
```shell
# 本地服务器上所要监听的地址。
KUBE_API_ADDRESS="--address=0.0.0.0"
# 逗号在 ETCD 集群分离节点列表
KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"
# 地址范围内使用的服务
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
# 添加你自己的!
KUBE_API_ARGS=""
```
<!--
* Edit `/etc/etcd/etcd.conf` to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused".
-->
* 编辑 `/etc/etcd/etcd.conf` 让 etcd 监听所有可用的 IP 地址，而不仅仅是 127.0.0.1。如果没有这样做，您可能会看到一个错误，例如 "connection refused"。
```shell
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
```
<!--
* Start the appropriate services on master:
-->
* 在主节点上启动适当的服务:
```shell
for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do
systemctl restart $SERVICES
systemctl enable $SERVICES
systemctl status $SERVICES
done
```
<!--
**Configure the Kubernetes services on the node.**
***We need to configure the kubelet on the node.***
* Edit `/etc/kubernetes/kubelet` to appear as such:
-->
**在节点上配置 Kubernetes 服务**
***我们需要在节点上配置 kubelet。***
* 编辑 `/etc/kubernetes/kubelet`，加入以下内容：
<!--
```shell
###
# Kubernetes kubelet (node) config
# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
KUBELET_ADDRESS="--address=0.0.0.0"
# You may leave this blank to use the actual hostname
KUBELET_HOSTNAME="--hostname-override=fed-node"
# location of the api-server
KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml"
```
-->
```shell
###
# Kubernetes kubelet（节点）的配置
# info 服务器要服务的地址(设置为 0.0.0.0 或 "" 用于所有接口)
KUBELET_ADDRESS="--address=0.0.0.0"
# 可以留空，使用实际主机名
KUBELET_HOSTNAME="--hostname-override=fed-node"
# api-server 的位置
KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml"
```
<!--
* Edit `/etc/kubernetes/master-kubeconfig.yaml` to contain the following information:
-->
* 编辑 `/etc/kubernetes/master-kubeconfig.yaml` 文件，添加以下信息：
```yaml
kind: Config
clusters:
- name: local
cluster:
server: http://fed-master:8080
users:
- name: kubelet
contexts:
- context:
cluster: local
user: kubelet
name: kubelet-context
current-context: kubelet-context
```
<!--
* Start the appropriate services on the node (fed-node).
-->
* 在节点（fed-node）上启动适当的服务。
```shell
for SERVICES in kube-proxy kubelet docker; do
systemctl restart $SERVICES
systemctl enable $SERVICES
systemctl status $SERVICES
done
```
<!--
* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_.
-->
* 检查以确保集群在 fed-master 上可以看到 fed-node，并且它的状态更改为 _Ready_。
```shell
kubectl get nodes
NAME STATUS AGE VERSION
fed-node Ready 4h
```
<!--
* Deletion of nodes:
To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information):
-->
* 删除节点：
要从 Kubernetes 集群中删除 _fed-node_，应该在 fed-master 上运行以下命令（这只是演示用）：
```shell
kubectl delete -f ./node.json
```
<!--
*You should be finished!*
**The cluster should be running! Launch a test pod.**
## Support Level
-->
*到此为止！*
**集群应该正在运行！创建测试 pod。**
## 支持级别
<!--
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
-->
IaaS 供应商 | 配置管理 | 操作系统| 网络 | 文档 | 合规 | 支持级别
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Bare-metal | custom | Fedora | _none_ | [文档](/docs/getting-started-guides/fedora/fedora_manual_config) | | 项目
有关所有解决方案的支持级别信息，请参见[解决方案表](/docs/getting-started-guides/#table-of-solutions)。
content/zh/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
+332
View File
@@ -0,0 +1,332 @@
---
reviewers:
- dchen1107
- erictune
- thockin
title: Fedora （多节点）
---
<!--
---
reviewers:
- dchen1107
- erictune
- thockin
title: Fedora (Multi Node)
---
-->
{{< toc >}}
<!--
This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. Flannel on each node configures an overlay network that docker uses. Flannel runs on each node to setup a unique class-C container network.
-->
本文档描述了如何在多个主机上部署 Kubernetes 来建立一个多节点集群和 flannel 网络。遵循 fedora 入门指南设置 1 个主节点 （fed-master）
和 2 个或更多节点。确保所有节点具有不同的名称（fed-node1、fed-node2 等等）和标签（fed-node1-label、fed-node2-label 等等），以避免
任何冲突。还要确保 Kubernetes 主节点主机正在运行 etcd、kube-controller-manager、kube-scheduler 和 kube-apiserver 服务，节点正在
运行 docker、kube-proxy 和 kubelet 服务。现在在 Kubernetes 节点上安装 flannel。每个节点上的 flannel 配置 docker 使用的 overlay 网络。
Flannel 在每个节点上运行，以设置一个唯一的 class-C 容器网络。
<!--
## Prerequisites
-->
## 前提条件
<!--
You need 2 or more machines with Fedora installed.
-->
安装 Fedora 您需要两台或更多机器。
<!--
## Master Setup
-->
## 主节点设置
<!--
**Perform following commands on the Kubernetes master**
* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are:
-->
**在 Kubernetes 主节点上执行以下命令**
* 在您当前的目录上的 fed-master 中通过创建一个 `flannel-config.json` 来配置 flannel。Flannel 在其他 overlay 网络后端选项中提供 udp 和 vxlan 。在本指南中，我们选择基于内核的 vxlan 后端。json 的内容为：
```json
{
"Network": "18.16.0.0/16",
"SubnetLen": 24,
"Backend": {
"Type": "vxlan",
"VNI": 1
}
}
```
{{< note >}}
<!--
Choose an IP range that is *NOT* part of the public IP address range.
-->
选择一个不在公共 IP 地址范围内的 IP 范围。
{{< /note >}}
<!--
Add the configuration to the etcd server on fed-master.
-->
将配置添加到 fed-master 上的 etcd 服务器。
```shell
etcdctl set /coreos.com/network/config < flannel-config.json
```
<!--
* Verify that the key exists in the etcd server on fed-master.
-->
* 验证 fed-master 上的 etcd 服务器中是否存在该密钥。
```shell
etcdctl get /coreos.com/network/config
```
<!--
## Node Setup
-->
## 节点设置
<!--
**Perform following commands on all Kubernetes nodes**
-->
**在所有 Kubernetes 节点上执行以下命令**
<!--
Install the flannel package
-->
安装 flannel 包
```shell
# dnf -y install flannel
```
<!--
Edit the flannel configuration file /etc/sysconfig/flanneld as follows:
-->
编辑 flannel 配置文件 /etc/sysconfig/flanneld，如下所示：
<!--
# Flanneld configuration options
# etcd url location. Point this to the server where etcd runs
# etcd config key. This is the configuration key that flannel queries
# For address range assignment
# Any additional options that you want to pass
-->
```shell
# Flanneld 配置选项
# etcd url 位置，将此指向 etcd 运行的服务器
FLANNEL_ETCD="http://fed-master:2379"
# etcd 配置的键。这是 flannel 查询的配置键
# 用于地址范围分配
FLANNEL_ETCD_KEY="/coreos.com/network"
# 您想要传递的任何附加选项
FLANNEL_OPTIONS=""
```
{{< note >}}
<!--
By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line.
-->
默认情况下，flannel 使用默认路由的接口。如果您有多个接口并且想要使用默认路由以外的接口，则可以将 "-iface=" 添加到 FLANNEL_OPTIONS。有关其他选项，请在命令行上运行 `flanneld --help`。
{{< /note >}}
<!--
Enable the flannel service.
-->
启用 flannel 服务。
```shell
systemctl enable flanneld
```
<!--
If docker is not running, then starting flannel service is enough and skip the next step.
-->
如果 docker 没有运行，那么启动 flannel 服务就足够了，跳过下一步。
```shell
systemctl start flanneld
```
<!--
If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`).
-->
如果 docker 已经运行，则停止 docker，删除 docker bridge（docker0），启动 flanneld 并重新启动 docker，如下所示。另一种方法是重启系统（systemctl reboot）。
```shell
systemctl stop docker
ip link delete docker0
systemctl start flanneld
systemctl start docker
```
<!--
## Test the cluster and flannel configuration
-->
## 测试集群和 flannel 配置
<!--
Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this:
-->
现在检查节点上的接口。请注意，现在有一个 flannel.1 接口，docker0 和 flannel.1 接口的 ip 地址在同一个网络中。您会注意到 docker0 在上面配置的 IP 范围之外的每个 Kubernetes 节点上分配了一个子网（18.16.29.0/24，如下所示）。 正常运行的输出应如下所示：
```shell
# ip -4 a|grep inet
inet 127.0.0.1/8 scope host lo
inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0
inet 18.16.29.0/16 scope global flannel.1
inet 18.16.29.1/24 scope global docker0
```
<!--
From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output.
-->
从集群中的任何节点，通过 curl 向 etcd 服务器发出查询来检查集群成员(仅显示部分输出 `grep -E "\{|\}|key|value`)。如果您设置了 1 个主节点和 3 个节点集群，您应该会看到每个节点都有一个块，显示分配给它们的子网。您可以通过输出中列出的 MAC 地址（VtepMAC）和 IP 地址(公共 IP) 将这些子网关联到每个节点。
```shell
curl -s http://fed-master:2379/v2/keys/coreos.com/network/subnets | python -mjson.tool
```
```json
{
"node": {
"key": "/coreos.com/network/subnets",
{
"key": "/coreos.com/network/subnets/18.16.29.0-24",
"value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}"
},
{
"key": "/coreos.com/network/subnets/18.16.83.0-24",
"value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}"
},
{
"key": "/coreos.com/network/subnets/18.16.90.0-24",
"value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}"
}
}
}
```
<!--
From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel.
-->
从所有节点，查看 `/run/flannel/subnet.env` 文件。这个文件是由 flannel 自动生成的。
```shell
# cat /run/flannel/subnet.env
FLANNEL_SUBNET=18.16.29.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
```
<!--
At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly.
-->
此时，我们在 Kubernetes 主节点上运行了 etcd，在 Kubernetes 节点上运行了 flannel / docker。接下来的步骤是测试跨主机容器通信，这将确认 docker 和 flannel 配置正确。
<!--
Issue the following commands on any 2 nodes:
-->
在任意两个节点上发出以下命令:
```shell
# docker run -it fedora:latest bash
bash-4.3#
```
<!--
This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error.
-->
您将会进入容器中。安装 iproute 和 iputils 包来安装 ip 和 ping 实用程序。由于一个[错误](https://bugzilla.redhat.com/show_bug.cgi?id=1142311)，需要修改 ping 二进制文件的功能来处理"操作不允许"错误。
```shell
bash-4.3# dnf -y install iproute iputils
bash-4.3# setcap cap_net_raw-ep /usr/bin/ping
```
<!--
Now note the IP address on the first node:
-->
现在记下第一个节点上的 IP 地址：
```shell
bash-4.3# ip -4 a l eth0 | grep inet
inet 18.16.29.4/24 scope global eth0
```
<!--
And also note the IP address on the other node:
-->
还要注意另一个节点上的 IP 地址：
```shell
bash-4.3# ip a l eth0 | grep inet
inet 18.16.90.4/24 scope global eth0
```
<!--
Now ping from the first node to the other node:
-->
现在从第一个节点 ping 到另一个节点：
```shell
bash-4.3# ping 18.16.90.4
PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data.
64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms
64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms
```
<!--
Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel.
-->
现在，Kubernetes 多节点集群通过 flannel 设置 overlay 网络。
<!--
## Support Level
-->
## 支持级别
<!--
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
-->
IaaS 供应商 | 配置 管理 | 系统 | 网络 | 文档 | 标准 | 支持级别
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
content/zh/docs/getting-started-guides/ubuntu/_index.md
+140
View File
@@ -0,0 +1,140 @@
---
title: Ubuntu 上运行 Kubernetes
content_template: templates/concept
---
<!-- ---
title: Kubernetes on Ubuntu
content_template: templates/concept
--- -->
{{% capture overview %}}
<!-- There are multiple ways to run a Kubernetes cluster with Ubuntu. These pages explain how to deploy Kubernetes on Ubuntu on multiple public and private clouds, as well as bare metal. -->
使用 Ubuntu 运行 Kubernetes 集群有多种方法。 这些页面阐释了如何在多种公共云、私有云和裸机的 Ubuntu 上部署 Kubernetes。
{{% /capture %}}
{{% capture body %}}
<!-- ## Official Ubuntu Guides
- [The Canonical Distribution of Kubernetes](https://www.ubuntu.com/cloud/kubernetes)
The latest version of Kubernetes with upstream binaries. Supports AWS, GCE, Azure, Joyent, OpenStack, VMware, Bare Metal and localhost deployments.
-->
## 官方 Ubuntu 指南
- [Kubernetes 的 Canonical 发行版](https://www.ubuntu.com/cloud/kubernetes)
最新版 Kubernetes 上游二进制文件。 支持 AWS、GCE、Azure、Joyent、OpenStack、VMware、裸机和 localhost 部署。
<!-- ### Quick Start
[conjure-up](http://conjure-up.io/) provides the quickest way to deploy Kubernetes on Ubuntu for multiple clouds and bare metal. It provides a user-friendly UI that prompts you for cloud credentials and configuration options
Available for Ubuntu 16.04 and newer: -->
### 快速入门
[conjure-up](http://conjure-up.io/) 提供了在多种云和裸机的 Ubuntu 上部署 Kubernetes 的最快方法。它提供了用户友好的界面，提示您提供云凭据和配置选项
适用于 Ubuntu 16.04 及更高版本:
<!--
```
sudo snap install conjure-up --classic
# re-login may be required at that point if you just installed snap utility
conjure-up kubernetes
```
-->
```
sudo snap install conjure-up --classic
# 如果您刚刚安装了 snap 工具，可能需要重新登录。
conjure-up kubernetes
```
<!-- As well as Homebrew for macOS: -->
以及用于 macOS 的 Homebrew：
```
brew install conjure-up
conjure-up kubernetes
```
<!-- ### Operational Guides
These are more in-depth guides for users choosing to run Kubernetes in production:
- [Installation](/docs/getting-started-guides/ubuntu/installation/)
- [Validation](/docs/getting-started-guides/ubuntu/validation/)
- [Backups](/docs/getting-started-guides/ubuntu/backups/)
- [Upgrades](/docs/getting-started-guides/ubuntu/upgrades/)
- [Scaling](/docs/getting-started-guides/ubuntu/scaling/)
- [Logging](/docs/getting-started-guides/ubuntu/logging/)
- [Monitoring](/docs/getting-started-guides/ubuntu/monitoring/)
- [Networking](/docs/getting-started-guides/ubuntu/networking/)
- [Security](/docs/getting-started-guides/ubuntu/security/)
- [Storage](/docs/getting-started-guides/ubuntu/storage/)
- [Troubleshooting](/docs/getting-started-guides/ubuntu/troubleshooting/)
- [Decommissioning](/docs/getting-started-guides/ubuntu/decommissioning/)
- [Operational Considerations](/docs/getting-started-guides/ubuntu/operational-considerations/)
- [Glossary](/docs/getting-started-guides/ubuntu/glossary/) -->
### 操作指南
这些是用户在生产中运行 Kubernetes 的更深入的指南：
- [安装](/docs/getting-started-guides/ubuntu/installation/)
- [验证](/docs/getting-started-guides/ubuntu/validation/)
- [备份](/docs/getting-started-guides/ubuntu/backups/)
- [升级](/docs/getting-started-guides/ubuntu/upgrades/)
- [缩放](/docs/getting-started-guides/ubuntu/scaling/)
- [日志](/docs/getting-started-guides/ubuntu/logging/)
- [监控](/docs/getting-started-guides/ubuntu/monitoring/)
- [网络](/docs/getting-started-guides/ubuntu/networking/)
- [安全](/docs/getting-started-guides/ubuntu/security/)
- [存储](/docs/getting-started-guides/ubuntu/storage/)
- [故障排除](/docs/getting-started-guides/ubuntu/troubleshooting/)
- [退役](/docs/getting-started-guides/ubuntu/decommissioning/)
- [操作因素](/docs/getting-started-guides/ubuntu/operational-considerations/)
- [词汇表](/docs/getting-started-guides/ubuntu/glossary/)
<!-- ## Third-party Product Integrations
- [Rancher](/docs/getting-started-guides/ubuntu/rancher/)
## Developer Guides
- [Localhost using LXD](/docs/getting-started-guides/ubuntu/local/) -->
## 第三方产品集成
- [Rancher](/docs/getting-started-guides/ubuntu/rancher/)
## 开发者指南
- [Localhost 使用 LXD](/docs/getting-started-guides/ubuntu/local/)
<!-- ## Where to find us
We're normally following the following Slack channels:
- [kubernetes-users](https://kubernetes.slack.com/messages/kubernetes-users/)
- [kubernetes-novice](https://kubernetes.slack.com/messages/kubernetes-novice/)
- [sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
- [sig-cluster-ops](https://kubernetes.slack.com/messages/sig-cluster-ops/)
- [sig-onprem](https://kubernetes.slack.com/messages/sig-onprem/)
and we monitor the Kubernetes mailing lists. -->
## 如何找到我们
我们通常关注以下 Slack 频道：
- [kubernetes-users](https://kubernetes.slack.com/messages/kubernetes-users/)
- [kubernetes-novice](https://kubernetes.slack.com/messages/kubernetes-novice/)
- [sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
- [sig-cluster-ops](https://kubernetes.slack.com/messages/sig-cluster-ops/)
- [sig-onprem](https://kubernetes.slack.com/messages/sig-onprem/)
而且我们会查看 Kubernetes 邮件列表。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/backups.md
+189
View File
@@ -0,0 +1,189 @@
---
title: 备份
content_template: templates/task
---
{{% capture overview %}}
<!-- The state of a Kubernetes cluster is kept in the etcd datastore.
This page shows how to backup and restore the etcd shipped with
the Canonical Distribution of Kubernetes. Backing up application specific data,
normally stored in a persistent volume, is outside the scope of this
document. -->
Kubernetes 集群的状态信息保存在 etcd 数据库中。
本文将要展示如何对 Canonical 发行版的 Kubernetes 中所带有的 etcd 进行备份和恢复。
至于如何对通常保存在持久卷上的应用数据进行备份，超出了本文的讨论范围。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设您有一个 Juju 部署的集群。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Snapshot etcd data -->
## 快照 etcd 中的数据
<!-- The `snapshot` action of the etcd charm allows the operator to snapshot
a running cluster's data for use in cloning,
backing up, or migrating to a new cluster.
juju run-action etcd/0 snapshot
This will create a snapshot in `/home/ubuntu/etcd-snapshots` by default. -->
etcd charm 的 `snapshot` 操作能够让操作员给正在运行的集群数据建立快照，快照数据可用于复制、备份或者迁移到一个新的集群中。
juju run-action etcd/0 snapshot
这条命令会在 `/home/ubuntu/etcd-snapshots` 默认路径下建立一个快照。
<!-- ## Restore etcd data -->
## 恢复 etcd 数据
<!-- The etcd charm is capable of restoring its data from a cluster-data snapshot
via the `restore` action.
This comes with caveats and a very specific path to restore a cluster:
The cluster must be in a state of only having a single member. So it's best to
deploy a new cluster using the etcd charm, without adding any additional units. -->
etcd charm 能够通过 `restore` 操作从一个集群数据快照中恢复集群数据。
这里有些注意事项，而且是恢复集群的唯一办法：集群当前只能有一个成员。
所以最好是使用 etcd charm 来部署一个新的集群，而不必添加任何新的单元。
```
juju deploy etcd new-etcd
```
<!-- The above code snippet will deploy a single unit of etcd, as 'new-etcd' -->
上面的命令将会部署一个单独的 etcd 单元，'new-etcd'。
```
juju run-action etcd/0 restore target=/mnt/etcd-backups
```
<!-- Once the restore action has completed, evaluate the cluster health. If the unit
is healthy, you may resume scaling the application to meet your needs.
- **param** target: destination directory to save the existing data.
- **param** skip-backup: Don't backup any existing data. -->
当恢复操作完成后，评估一下集群的健康状态。如果集群运行良好，就可以按照您的需求来扩展应用程序规模。
- **参数** target: 保存现有数据的目的路径。
- **参数** skip-backup: 不要备份任何现有的数据。
<!-- ## Migrating an etcd cluster
Using the above snapshot and restore operations, migrating etcd is a fairly easy task. -->
## 迁移 etcd 集群
通过使用上述的 `snapshot` 和 `restore` 操作，就能很容易地迁移 etcd 集群。
<!-- **Step 1:** Snapshot your existing cluster. This is encapsulated in the `snapshot` action. -->
**第一步：** 给现有的集群建立快照。这个已经封装在 `snapshot` 操作中。
```
juju run-action etcd/0 snapshot
```
<!-- Results: -->
结果：
```
Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580c
```
<!-- **Step 2:** Check the status of the action so you can grab the snapshot and verify
the sum. The `copy.cmd` result output is a copy/paste command for you to download
the exact snapshot that you just created. -->
**第二步：** 检查操作状态，以便您能抓取快照并且验证校验和。
您可以直接使用 `copy.cmd` 中的结果来下载您刚刚创建的快照数据，`copy.cmd` 中的结果可以直接复制/粘贴使用。
<!-- Download the snapshot archive from the unit that created the snapshot and verify the sha256 sum -->
从节点上下载刚刚创建的快照数据并且验证 sha256sum 校验和
```
juju show-action-output b46d5d6f-5625-4320-8cda-b611c6ae580c
```
<!-- Results: -->
结果：
```
results:
copy:
cmd: juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
.
snapshot:
path: /home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
sha256: 1dea04627812397c51ee87e313433f3102f617a9cab1d1b79698323f6459953d
size: 68K
status: completed
```
<!-- Copy the snapshot to the local disk and then check the sha256sum. -->
将数据快照拷到本地，然后检查 sha256sum。
```
juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz .
sha256sum etcd-snapshot-2016-11-09-02.41.47.tar.gz
```
<!-- **Step 3:** Deploy the new cluster leader, and attach the snapshot: -->
**第三步：** 部署新的集群 leader 节点，并加载快照数据：
```
juju deploy etcd new-etcd --resource snapshot=./etcd-snapshot-2016-11-09-02.41.47.tar.gz
```
<!-- **Step 4:** Reinitialize the master with the data from the resource we just attached in step 3. -->
**第四步：** 使用在第三步中的快照数据来重新初始化 master：
```
juju run-action new-etcd/0 restore
```
{{% /capture %}}
{{% capture discussion %}}
<!-- ## Known Limitations -->
## 已知的局限
<!-- #### Loss of PKI warning -->
#### 丢失 PKI 警告
<!-- If you destroy the leader - identified with the `*` text next to the unit number in status:
all TLS pki will be lost. No PKI migration occurs outside
of the units requesting and registering the certificates. -->
如果销毁了 leader - 在状态栏通过 `*` 来标识，那么所有的 TLS pki 警告都将会丢失。
在请求和注册证书的单元之外，将不会有 PKI 迁移发生。
{{< caution >}}
<!-- **Caution:** Mismanaging this configuration will result in locking yourself
out of the cluster, and can potentially break existing deployments in very
strange ways relating to x509 validation of certificates, which affects both
servers and clients. -->
**警告：** 如果误管理这项配置，将会导致您无法从外部访问集群，
并且很可能会破坏现有的部署，出现 x509 证书验证相关的异常问题，这些都会对服务器和客户端造成影响。
{{< /caution >}}
<!-- #### Restoring from snapshot on a scaled cluster -->
#### 在一个已经扩展的集群上进行快照数据恢复
<!-- Restoring from a snapshot on a scaled cluster will result in a broken cluster.
Etcd performs clustering during unit turn-up, and state is stored in Etcd itself.
During the snapshot restore phase, a new cluster ID is initialized, and peers
are dropped from the snapshot state to enable snapshot restoration. Please
follow the migration instructions above in the restore action description. -->
在一个已经扩展的集群上进行快照数据恢复，将会导致集群损坏。
etcd 在节点启动时开始集群管理，并且将状态保存在 etcd 中。
在快照数据的恢复阶段，会初始化一个新的集群 ID，并且丢弃其它 peer 节点以保证快照数据的恢复。
请严格遵照上述集群迁移中的恢复操作来进行操作。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/decommissioning.md
+103
View File
@@ -0,0 +1,103 @@
---
title: 销毁
content_template: templates/task
---
<!-- ---
title: Decommissioning
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This page shows you how to properly decommission a cluster. -->
本页将展示如何销毁一个集群。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本页假设有一个使用 Juju 部署的、正在运行的集群。
{{< warning >}}
<!-- By the time you've reached this step you should have backed up your workloads and pertinent data; this section is for the complete destruction of a cluster. -->
当您到达这一步时，您应该已经对集群的相关内容进行了备份；这部分将彻底销毁一个集群。
{{< /warning >}}
{{% /capture %}}
{{% capture steps %}}
<!-- ## Destroy the Juju model -->
## 破坏 Juju 模型
<!-- It is recommended to deploy individual Kubernetes clusters in their own models, so that there is a clean separation between environments. To remove a cluster first find out which model it's in with `juju list-models`. The controller reserves an `admin` model for itself. If you have chosen to not name your model it might show up as `default`. -->
建议使用各自的模型来相应地部署 Kubernetes 集群，
以便各个环境之间能够界限分明。
如果想要删除一个集群，首先需要通过 `juju list-models` 命令找到其对应的模型。
控制器为其自身预留了 `admin` 这个模型。
如果没有命名模型，则模型名可能会显示为 `default`。
```
$ juju list-models
Controller: aws-us-east-2
Model Cloud/Region Status Machines Cores Access Last connection
controller aws/us-east-2 available 1 2 admin just now
my-kubernetes-cluster* aws/us-east-2 available 12 22 admin 2 minutes ago
```
<!-- You can then destroy the model, which will in turn destroy the cluster inside of it: -->
销毁模型，模型内的集群也随之被销毁：
juju destroy-model my-kubernetes-cluster
```
$ juju destroy-model my-kubernetes-cluster
WARNING! This command will destroy the "my-kubernetes-cluster" model.
This includes all machines, applications, data and other resources.
Continue [y/N]? y
Destroying model
Waiting on model to be removed, 12 machine(s), 10 application(s)...
Waiting on model to be removed, 12 machine(s), 9 application(s)...
Waiting on model to be removed, 12 machine(s), 8 application(s)...
Waiting on model to be removed, 12 machine(s), 7 application(s)...
Waiting on model to be removed, 12 machine(s)...
Waiting on model to be removed...
$
```
<!-- This will destroy and decommission all nodes. You can confirm all nodes are destroyed by running `juju status`. -->
这将会彻底破坏并销毁所有节点。
运行 `juju status` 命令可以确认所有节点是否已经被销毁。
<!-- If you're using a public cloud this will terminate the instances. If you're on bare metal using MAAS this will release the nodes, optionally wipe the disk, power off the machines, and return them to available pool of machines to deploy from. -->
如果使用的是公有云，命令将会终止所有的实例。
如果使用的是 MAAS 裸机，命令将会释放所有的节点，（可能）清空磁盘，关闭机器，
然后将节点资源返回到可用的机器池中。
<!-- ## Cleaning up the Controller -->
## 清理控制器
<!-- If you're not using the controller for anything else, you will also need to remove the controller instance: -->
如果控制器没有其它的用途，还需要删除控制器实例：
```
$ juju list-controllers
Use --refresh flag with this command to see the latest information.
Controller Model User Access Cloud/Region Models Machines HA Version
aws-us-east-2* - admin superuser aws/us-east-2 2 1 none 2.0.1
$ juju destroy-controller aws-us-east-2
WARNING! This command will destroy the "aws-us-east-2" controller.
This includes all machines, applications, data and other resources.
Continue? (y/N):y
Destroying controller
Waiting for hosted model resources to be reclaimed
All hosted models reclaimed, cleaning up controller machines
$
```
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/glossary.md
+50
View File
@@ -0,0 +1,50 @@
---
title: 词汇与术语
content_template: templates/concept
---
<!--
---
title: Glossary and Terminology
content_template: templates/concept
---
-->
<!--
{{% capture overview %}}
This page explains some of the terminology used in deploying Kubernetes with Juju.
{{% /capture %}}
{{% capture body %}}
-->
{{％capture overview％}}
本页介绍了用 Juju 部署 Kubernetes 时使用的一些术语。
{{％/ capture％}}
{{％capture body％}}
<!--
**controller** - The management node of a cloud environment. Typically you have one controller per cloud region, or more in HA environments. The controller is responsible for managing all subsequent models in a given environment. It contains the Juju API server and its underlying database.
**model** - A collection of charms and their relationships that define a deployment. This includes machines and units. A controller can host multiple models. It is recommended to separate Kubernetes clusters into individual models for management and isolation reasons.
**charm** - The definition of a service, including its metadata, dependencies with other services, required packages, and application management logic. It contains all the operational knowledge of deploying a Kubernetes cluster. Included charm examples are `kubernetes-core`, `easyrsa`, `flannel`, and `etcd`.
**unit** - A given instance of a service. These may or may not use up a whole machine, and may be colocated on the same machine. So for example you might have a `kubernetes-worker`, and `etcd`, and `easyrsa` units running on a single machine, but they are three distinct units of different services.
**machine** - A physical node, these can either be bare metal nodes, or virtual machines provided by a cloud.
{{% /capture %}}
-->
**controller** - 云环境的管理节点。通常，每个域(Region)都有一个 controller，在高可用环境中有更多 controller。每个 controller 负责管理给定环境中的所有后续 model。Controller 中包含 Juju API 服务器及其底层数据库。
**model** - 定义 Deployments 的一系列 charms 及其关系的集合。model 之中包括 machine 和更小的 unit。每个 controller 可以托管多个 model。出于管理和隔离的原因，建议将 Kubernetes 集群分成独立的 model。
**charm** - 每个 charm 对应一个 Service 的定义，包括其元数据、与其他服务间的依赖关系、所需的包和应用管理逻辑。
其中包含部署 Kubernetes 集群的所有操作知识。内置的 charms 例子有 `kubernetes-core`、`easyrsa`、`flannel` 和 `etcd` 等。
**unit** - 对应某 Service 的给定实例。每个 unit 可能会也可能不会耗尽某指定机器上的所有资源。多个 unit 可能部署在同一台机器上。例如，您可能在一台机器上运行 `kubernetes-worker` 和 `etcd` 以及 `easyrsa` unit，但它们是基于不同服务的三个独立的 unit。
**machine** - 物理节点，可以是裸机节点，也可以是云提供商提供的虚拟机。
{{％/ capture％}}
content/zh/docs/getting-started-guides/ubuntu/installation.md
+542
View File
@@ -0,0 +1,542 @@
---
reviewers:
- caesarxuchao
- erictune
title: 用 Juju 搭建 Kubernetes
content_template: templates/task
---
<!-- ---
reviewers:
- caesarxuchao
- erictune
title: Setting up Kubernetes with Juju
content_template: templates/task
--- -->
<!-- {{% capture overview %}}
Ubuntu 16.04 introduced the [Canonical Distribution of Kubernetes](https://www.ubuntu.com/cloud/kubernetes), a pure upstream distribution of Kubernetes designed for production usage. This page shows you how to deploy a cluster.
{{% /capture %}} -->
{% capture overview %}
Ubuntu 16.04 已公开 [Kubernetes 的 Canonical 发行版 ](https://www.ubuntu.com/cloud/kubernetes), 一套为生产环境设计的 Kubernetes 上游版本。本文将为您演示如何部署集群。
{% endcapture %}
<!-- {{% capture prerequisites %}}
- A working [Juju client](https://jujucharms.com/docs/2.3/reference-install); this does not have to be a Linux machine, it can also be Windows or OSX.
- A [supported cloud](#cloud-compatibility).
- Bare Metal deployments are supported via [MAAS](http://maas.io). Refer to the [MAAS documentation](http://maas.io/docs/) for configuration instructions.
- OpenStack deployments are currently only tested on Icehouse and newer.
- One of the following:
- Network access to the following domains
- *.jujucharms.com
- gcr.io
- github.com
- Access to an Ubuntu mirror (public or private)
- Offline deployment prepared with [these](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Running-CDK-in-a-restricted-environment) instructions.
{{% /capture %}} -->
{{% capture prerequisites %}}
- 一个可用的 [Juju 客户端](https://jujucharms.com/docs/2.3/reference-install)；不一定要是 Linux 机器，也可以是 Windows 或 OSX。
- 一个[受支持的云](#cloud-compatibility)。
- 裸机部署可以通过 [MAAS](http://maas.io) 实现。 配置指南参见 [MAAS 文档](http://maas.io/docs/)。
- OpenStack 部署目前只在 Icehouse 及更新版本上测试通过。
- 下面任一一种选项：
- 可以网络访问以下站点
- *.jujucharms.com
- gcr.io
- github.com
- 访问 Ubuntu 镜像源（公共的或私有的）
- 通过[这些](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Running-CDK-in-a-restricted-environment)步骤准备好离线部署。
{{% /capture %}}
<!-- {{% capture steps %}}
## Deployment overview
Out of the box the deployment comes with the following components on 9 machines:
- Kubernetes (automated deployment, operations, and scaling)
- Four node Kubernetes cluster with one master and three worker nodes.
- TLS used for communication between units for security.
- Flannel Software Defined Network (SDN) plugin
- A load balancer for HA kubernetes-master (Experimental)
- Optional Ingress Controller (on worker)
- Optional Dashboard addon (on master) including Heapster for cluster monitoring
- EasyRSA
- Performs the role of a certificate authority serving self signed certificates
to the requesting units of the cluster.
- ETCD (distributed key value store)
- Three unit cluster for reliability. -->
{{% capture steps %}}
## 部署概述
开箱即用的部署由以下组件构成，部署在 9 台机器上：
- Kubernetes （自动化部署，运营及伸缩）
- 具有一个主节点和三个工作节点的四节点 Kubernetes 集群。
- 使用 TLS 实现组件间的安全通信。
- Flannel 软件定义网络 (SDN) 插件
- 一个负载均衡器以实现 kubernetes-master 的高可用 (实验阶段)
- 可选的 Ingress 控制器（在工作节点上）
- 可选的 Dashboard 插件（在主节点上），包含实现集群监控的 Heapster 插件
- EasyRSA
- 扮演证书授权机构的角色，向集群中的组件提供自签名证书
- ETCD （分布式键值存储）
- 三节点的集群达到高可靠性。
<!-- The Juju Kubernetes work is curated by the Big Software team at [Canonical Ltd](https://www.canonical.com/),
let us know how we are doing. If you find any problems please open an
[issue on our tracker](https://github.com/juju-solutions/bundle-canonical-kubernetes)
so we can find them. -->
Juju Kubernetes 工作由 Canonical Ltd（https://www.canonical.com/） 的 Big Software 团队整理，欢迎对我们的工作给出反馈意见。
如果发现任何问题，请提交相应的 [Issue 到跟踪系统](https://github.com/juju-solutions/bundle-canonical-kubernetes)，以便我们解决。
<!-- ## Support Level
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Amazon Web Services (AWS) | Juju | Ubuntu | flannel, calico* | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
OpenStack | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Microsoft Azure | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Google Compute Engine (GCE) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Joyent | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Rackspace | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
VMware vSphere | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Bare Metal (MAAS) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) -->
## 支持级别
IaaS 提供商 | 配置管理 | 系统 | 网络 | 文档 | 符合 | 支持级别
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Amazon Web Services (AWS) | Juju | Ubuntu | flannel, calico* | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
OpenStack | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Microsoft Azure | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Google Compute Engine (GCE) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Joyent | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Rackspace | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
VMWare vSphere | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
Bare Metal (MAAS) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core)
<!-- For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
## Installation options
You can launch a cluster in one of two ways: [conjure-up](#conjure-up) or [juju deploy](#juju-deploy). Conjure-up is just a convenience wrapper over juju and simplifies the installation. As such, it is the preferred method of install.
Deployment of the cluster is [supported on a wide variety of public clouds](#cloud-compatibility), private OpenStack clouds, or raw bare metal clusters. Bare metal deployments are supported via [MAAS](http://maas.io/).
## Conjure-up
To install Kubernetes with conjure-up, you need only to run the following commands and then follow the prompts:
```
sudo snap install conjure-up --classic
conjure-up kubernetes
```
## Juju deploy
### Configure Juju to use your cloud provider
After deciding which cloud to deploy to, follow the [cloud setup page](https://jujucharms.com/docs/devel/getting-started) to configure deploying to that cloud.
Load your [cloud credentials](https://jujucharms.com/docs/2.3/credentials) for each
cloud provider you would like to use. -->
有关所有解决方案的支持级别信息，请参见[解决方案表](/docs/getting-started-guides/#table-of-solutions)。
## 安装选项
可以通过下面任一一种方式启动集群：[conjure-up](#conjure-up) or [juju 部署](#juju-deploy)。Conjure-up 只是一个对 juju 的简易封装，简化了安装的过程。正因为如此，这也是推荐的安装方法。
可以在 [众多不同的公有云](#cloud-compatibility)，私有 OpenStack 云，或者是原始的裸机集群上部署集群软件。通过 [MAAS](http://maas.io) 实现裸机部署。
## Conjure-up
通过 conjure-up 来安装 Kubernetes, 只需要运行下面的命令，然后根据提示做选择：
```
sudo snap install conjure-up --classic
conjure-up kubernetes
```
## Juju 部署
### 配置 Juju 使用您的云提供商
确定所要部署的云之后，按照[云安装界面](https://jujucharms.com/docs/devel/getting-started)来配置、部署到该云。
加载[云凭证](https://jujucharms.com/docs/2.3/credentials)来选择、使用相应的云。
<!-- In this example
```
juju add-credential aws
credential name: my_credentials
select auth-type [userpass, oauth, etc]: userpass
enter username: jorge
enter password: *******
```
You can also just auto load credentials for popular clouds with the `juju autoload-credentials` command, which will auto import your credentials from the default files and environment variables for each cloud. -->
在本例中
```
juju add-credential aws
credential name: my_credentials
select auth-type [userpass, oauth, etc]: userpass
enter username: jorge
enter password: *******
```
也可以通过 `juju autoload-credentials` 命令自动加载常用的云凭证，该命令将自动从每个云的默认文件和环境变量中导入凭据信息。
<!-- Next we need to bootstrap a controller to manage the cluster. You need to define the cloud you want to bootstrap on, the region, and then any name for your controller node:
```
juju update-clouds # This command ensures all the latest regions are up to date on your client
juju bootstrap aws/us-east-2
```
or, another example, this time on Azure:
```
juju bootstrap azure/westus2
``` -->
接下来，我们需要启动一个控制器来管理集群。您需要确定所要启动的云，地区以及控制器节点的名字：
```
juju update-clouds # 这个命令可以确保客户端上所有最新的区域是最新的
juju bootstrap aws/us-east-2
```
或者，另外一个例子，这次是在 Azure 上：
```
juju bootstrap azure/westus2
```
<!-- If you receive this error, it is likely that the default Azure VM size (Standard D1 v2 [1 vcpu, 3.5 GB memory]) is not available in the Azure location: -->
如果您看到下面的错误信息，很可能默认的 Azure VM (Standard D1 v2 [1 vcpu, 3.5 GB memory]) 并不在当前的 Azure 地区。
```
ERROR failed to bootstrap model: instance provisioning failed (Failed)
```
<!-- You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.3/controllers) for more information.
Note that each controller can host multiple Kubernetes clusters in a given cloud or region. -->
您需要为部署到的每个云或区域分配一个控制器节点。更多信息参见[控制器文档](https://jujucharms.com/docs/2.3/controllers)。
请注意，每个控制器可以在给定的云或区域中管理多个 Kubernetes 集群。
<!-- ### Launch a Kubernetes cluster
The following command will deploy the initial 9-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to:
```
juju deploy canonical-kubernetes
```
After this command executes the cloud will then launch instances and begin the deployment process. -->
## 启动 Kubernetes 集群
以下命令将部署 9-节点的初始集群。执行速度取决于您所要部署到的云的性能：
```
juju deploy canonical-kubernetes
```
执行完此命令后，云将启动实例并开始部署过程。
<!-- ## Monitor deployment
The `juju status` command provides information about each unit in the cluster. Use the `watch -c juju status --color` command to get a real-time view of the cluster as it deploys. When all the states are green and "Idle", the cluster is ready to be used:
juju status
Output: -->
## 监控部署
`juju status` 命令提供集群中每个单元的信息。`watch -c juju status --color` 命令可以获取集群部署的实时状态。
当所有的状态是绿色并且“空闲”时，表示集群处于待用状态：
juju status
输出结果:
```
Model Controller Cloud/Region Version SLA
conjure-canonical-kubern-f48 conjure-up-aws-650 aws/us-east-2 2.3.2 unsupported
App Version Status Scale Charm Store Rev OS Notes
easyrsa 3.0.1 active 1 easyrsa jujucharms 27 ubuntu
etcd 2.3.8 active 3 etcd jujucharms 63 ubuntu
flannel 0.9.1 active 4 flannel jujucharms 40 ubuntu
kubeapi-load-balancer 1.10.3 active 1 kubeapi-load-balancer jujucharms 43 ubuntu exposed
kubernetes-master 1.9.3 active 1 kubernetes-master jujucharms 13 ubuntu
kubernetes-worker 1.9.3 active 3 kubernetes-worker jujucharms 81 ubuntu exposed
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 3 18.219.190.99 Certificate Authority connected.
etcd/0 active idle 5 18.219.56.23 2379/tcp Healthy with 3 known peers
etcd/1* active idle 0 18.219.212.151 2379/tcp Healthy with 3 known peers
etcd/2 active idle 6 13.59.240.210 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 1 18.222.61.65 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 4 18.219.105.220 6443/tcp Kubernetes master running.
flannel/3 active idle 18.219.105.220 Flannel subnet 10.1.78.1/24
kubernetes-worker/0 active idle 2 18.219.221.98 80/tcp,443/tcp Kubernetes worker running.
flannel/1 active idle 18.219.221.98 Flannel subnet 10.1.38.1/24
kubernetes-worker/1* active idle 7 18.219.249.103 80/tcp,443/tcp Kubernetes worker running.
flannel/2 active idle 18.219.249.103 Flannel subnet 10.1.68.1/24
kubernetes-worker/2 active idle 8 52.15.89.16 80/tcp,443/tcp Kubernetes worker running.
flannel/0* active idle 52.15.89.16 Flannel subnet 10.1.73.1/24
Machine State DNS Inst id Series AZ Message
0 started 18.219.212.151 i-065eab4eabc691b25 xenial us-east-2a running
1 started 18.222.61.65 i-0b332955f028d6281 xenial us-east-2b running
2 started 18.219.221.98 i-0879ef1ed95b569bc xenial us-east-2a running
3 started 18.219.190.99 i-08a7b364fc008fc85 xenial us-east-2c running
4 started 18.219.105.220 i-0f92d3420b01085af xenial us-east-2a running
5 started 18.219.56.23 i-0271f6448cebae352 xenial us-east-2c running
6 started 13.59.240.210 i-0789ef5837e0669b3 xenial us-east-2b running
7 started 18.219.249.103 i-02f110b0ab042f7ac xenial us-east-2b running
8 started 52.15.89.16 i-086852bf1bee63d4e xenial us-east-2c running
Relation provider Requirer Interface Type Message
easyrsa:client etcd:certificates tls-certificates regular
easyrsa:client kubeapi-load-balancer:certificates tls-certificates regular
easyrsa:client kubernetes-master:certificates tls-certificates regular
easyrsa:client kubernetes-worker:certificates tls-certificates regular
etcd:cluster etcd:cluster etcd peer
etcd:db flannel:etcd etcd regular
etcd:db kubernetes-master:etcd etcd regular
kubeapi-load-balancer:loadbalancer kubernetes-master:loadbalancer public-address regular
kubeapi-load-balancer:website kubernetes-worker:kube-api-endpoint http regular
kubernetes-master:cni flannel:cni kubernetes-cni subordinate
kubernetes-master:kube-api-endpoint kubeapi-load-balancer:apiserver http regular
kubernetes-master:kube-control kubernetes-worker:kube-control kube-control regular
kubernetes-worker:cni flannel:cni kubernetes-cni subordinate
```
<!-- ## Interacting with the cluster
After the cluster is deployed you may assume control over the cluster from any kubernetes-master, or kubernetes-worker node.
If you didn't use conjure-up, you will first need to download the credentials and client application to your local workstation:
Create the kubectl config directory.
```
mkdir -p ~/.kube
```
Copy the kubeconfig file to the default location.
```
juju scp kubernetes-master/0:/home/ubuntu/config ~/.kube/config
``` -->
## 与集群的交互
部署完集群后，您可以在任意一个 kubernetes-master 或 kubernetes-worker 节点取得集群的控制权。
如果您没有使用 conjure-up，那么您需要先将凭据和客户端程序下载到本地工作站上：
创建 kubectl 配置信息目录。
```
mkdir -p ~/.kube
```
将 kubeconfig 文件复制到默认位置。
```
juju scp kubernetes-master/0:config ~/.kube/config
```
<!-- The next step is to install the kubectl client on your local machine. The recommended way to do this on Ubuntu is using the kubectl snap ([/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu](/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu)).
The following command should be run on the machine you wish to use to control the kubernetes cluster:
```
sudo snap install kubectl --classic
```
This will install and deploy the kubectl binary. You may need to restart your terminal as your $PATH may have been updated. -->
下一步是在本地机器上安装 kubectl 客户端。在 Ubuntu 上推荐的安装方式是使用 kubectl snap ([/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu](/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu))。
可以运行下面的命令便可以控制 kubernetes 集群了：
```
sudo snap install kubectl --classic
```
这条命令会安装和部署 kubectl 程序。安装完成后，您可能需要重启命令窗口（因为 $PATH 已经被更新）。
<!-- Query the cluster:
kubectl cluster-info
Output:
```
Kubernetes master is running at https://52.15.104.227:443
Heapster is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/kube-dns/proxy
Grafana is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
InfluxDB is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```
Congratulations, you've now set up a Kubernetes cluster! -->
查询集群：
kubectl cluster-info
输出结果：
```
Kubernetes master is running at https://52.15.104.227:443
Heapster is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/kube-dns/proxy
Grafana is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
InfluxDB is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```
<!-- ## Scale up cluster
Want larger Kubernetes nodes? It is easy to request different sizes of cloud
resources from Juju by using **constraints**. You can increase the amount of
CPU or memory (RAM) in any of the systems requested by Juju. This allows you
to fine tune the Kubernetes cluster to fit your workload. Use flags on the
bootstrap command or as a separate `juju constraints` command. Look to the
[Juju documentation for machine](https://jujucharms.com/docs/2.3/charms-constraints)
details. -->
## 为集群垂直扩容
需要更大的 Kubernetes 节点？通过使用 Juju 的**约束**，您可以轻松地请求到不同大小的云资源。
通过 Juju 请求创建的任意系统，您都可以为它们增加 CPU 和内存（RAM）。
这使您可以对 Kubernetes 集群进行调优以适应工作负载。
藉由 bootstrap 命令的参数或使用独立的 `juju constraints` 命令都可以做到这点。详情参见[和机器相关的 Juju 文档](https://jujucharms.com/docs/2.3/charms-constraints)
<!-- ## Scale out cluster
Need more workers? We just add more units:
```shell
juju add-unit kubernetes-worker
```
Or multiple units at one time:
```shell
juju add-unit -n3 kubernetes-worker
```
You can also ask for specific instance types or other machine-specific constraints. See the [constraints documentation](https://jujucharms.com/docs/stable/reference-constraints) for more information. Here are some examples, note that generic constraints such as `cores` and `mem` are more portable between clouds. In this case we'll ask for a specific instance type from AWS:
```shell
juju set-constraints kubernetes-worker instance-type=c4.large
juju add-unit kubernetes-worker
```
You can also scale the etcd charm for more fault tolerant key/value storage:
```shell
juju add-unit -n3 etcd
```
It is strongly recommended to run an odd number of units for quorum. -->
## 为集群集群水平扩容
需要更多的工作节点？只需添加一些 unit：
```shell
juju add-unit kubernetes-worker
```
或者一次添加多个：
```shell
juju add-unit -n3 kubernetes-worker
```
您也可以为特定实例类型或者特定机器的设置约束。更多信息请参见[约束文档](https://jujucharms.com/docs/stable/reference-constraints)。
接下来举一些例子。请注意，诸如 `cores` 和 `mem` 这样的通用约束在各云之间的可移植性是比较高的。
在本例中，我们从 AWS 申请一个特定的实例类型：
```shell
juju set-constraints kubernetes-worker instance-type=c4.large
juju add-unit kubernetes-worker
```
为提升键值存储的容错能力，您也可以扩展 etcd charm：
```shell
juju add-unit -n3 etcd
```
强烈建议运行奇数个 unit 以支持法定人数票选。
<!-- ## Tear down cluster
If you used conjure-up to create your cluster, you can tear it down with `conjure-down`. If you used juju directly, you can tear it down by destroying the Juju model or the controller. Use the `juju switch` command to get the current controller name:
```shell
juju switch
juju destroy-controller $controllername --destroy-all-models
```
This will shutdown and terminate all running instances on that cloud.
{{% /capture %}}
{{% capture discussion %}} -->
## 销毁集群
如果您是使用 conjure-up 创建的集群，通过 `conjure-down` 便可以完成销毁过程。
如果是直接使用的 juju，你可以通过销毁 juju 模型或控制器来销毁集群。
使用 `juju switch` 命令获取当前控制器的名字：
```shell
juju switch
juju destroy-controller $controllername --destroy-all-models
```
这将关闭并终止该云上所有正在运行的实例。
{{% /capture %}}
{{% capture discussion %}}
<!-- ## More Info
The Ubuntu Kubernetes deployment uses open-source operations, or operations as code, known as charms. These charms are assembled from layers which keeps the code smaller and more focused on the operations of just Kubernetes and its components.
The Kubernetes layer and bundles can be found in the `kubernetes`
project on github.com:
- [Bundle location](https://git.k8s.io/kubernetes/cluster/juju/bundles)
- [Kubernetes charm layer location](https://git.k8s.io/kubernetes/cluster/juju/layers)
- [Canonical Kubernetes home](https://jujucharms.com/kubernetes)
- [Main issue tracker](https://github.com/juju-solutions/bundle-canonical-kubernetes)
Feature requests, bug reports, pull requests and feedback are appreciated.
{{% /capture %}} -->
{{% capture discussion %}}
## 更多信息
Ubuntu Kubernetes 的部署通过名为 charms 的开源运维工具实现，这类工具也称作运维即代码（Operations as Code）。
这些 charms 以层的方式组装，从而使代码更小，更专注于 Kubernetes 及其组件的操作。
Kubernetes 的层和 Bundle 可以在 github.com 的 `kubernetes` 项目中找到：
- [Bundle 的地址](https://git.k8s.io/kubernetes/cluster/juju/bundles)
- [Kubernetes charm 层的地址](https://git.k8s.io/kubernetes/cluster/juju/layers)
- [Canonical Kubernetes 主页](https://jujucharms.com/kubernetes)
- [主要的 issue tracker](https://github.com/juju-solutions/bundle-canonical-kubernetes)
欢迎提供功能需求，错误报告，pull request和反馈意见。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/local.md
+118
View File
@@ -0,0 +1,118 @@
---
title: 通过 LXD 实现 Kubernetes 本地开发
content_template: templates/task
---
<!-- ---
title: Local Kubernetes development with LXD
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- Running Kubernetes locally has obvious development advantages, such as lower cost and faster iteration than constantly deploying and tearing down clusters on a public cloud. Ideally, a Kubernetes developer can spawn all necessary nodes inside local containers and test new configurations as they are committed. This page will show you how to deploy a cluster to LXD containers on a local machine. -->
在本地运行 Kubernetes 比在公有云上部署和移除集群具有明显的开发优势，如更低的成本和更快的迭代。
理想情况下，Kubernetes 开发人员可以在本地容器内产生所有必需的节点，并在提交新配置时测试它们。
本文将展示如何将集群部署到本地机器的 LXD 容器上。
{{% /capture %}}
<!-- The purpose of using [LXD](https://linuxcontainers.org/lxd/) on a local machine is to emulate the same deployment that a user would use in a cloud or bare metal. Each node is treated as a machine, with the same characteristics as production. Each node is a separate container, which runs Docker containers and `kubectl` inside (see [Cluster Intro](/docs/tutorials/kubernetes-basics/cluster-intro/) for more info). -->
在本地机器上使用 [LXD](https://linuxcontainers.org/lxd/) 的目的是为了模拟用户在云或裸机中部署的环境。每个节点都被视为一台机器，具有与生产环境相同的特性。 每个节点都是一个单独的容器，它在里面运行 Docker 容器和 `kubectl`（更多信息请参阅 [集群简介](/docs/tutorials/kubernetes-basics/cluster-intro/)）。
{{% capture prerequisites %}}
<!-- Install [conjure-up](http://conjure-up.io/), a tool for deploying big software.
Add the current user to the `lxd` user group. -->
安装 [conjure-up](http://conjure-up.io/)，这是一个用来部署大型软件的工具。
将当前用户添加到 `lxd` 用户组中。
```
sudo snap install conjure-up --classic
sudo usermod -a -G lxd $(whoami)
```
<!-- Note: If conjure-up asks you to "Setup an ipv6 subnet" with LXD, answer NO. ipv6 with Juju/LXD is currently unsupported.
{{% /capture %}} -->
注意：如果 conjure-up 要求您在 LXD 上 "配置一个 ipv6 子网"，请选择 NO。目前还不支持在 Juju/LXD 上使用 ipv6。
{% endcapture %}
{{% capture steps %}}
<!-- ## Deploying Kubernetes -->
## 部署 Kubernetes
<!-- Start the deployment with: -->
通过以下命令启动部署：
conjure-up kubernetes
<!-- For this walkthrough we are going to create a new controller - select the `localhost` Cloud type:
![Select Cloud](/images/docs/ubuntu/00-select-cloud.png) -->
对于本教程，我们将会创建一个新的控制器 - 选择 `localhost` 云类型：
![选择云类型](/images/docs/ubuntu/00-select-cloud.png)
<!-- Deploy the applications:
![Deploy Applications](/images/docs/ubuntu/01-deploy.png) -->
部署应用：
![部署应用](/images/docs/ubuntu/01-deploy.png)
<!-- Wait for Juju bootstrap to finish:
![Bootstrap](/images/docs/ubuntu/02-bootstrap.png) -->
等待 Juju 引导结束：
![引导](/images/docs/ubuntu/02-bootstrap.png)
<!-- Wait for our Applications to be fully deployed:
![Waiting](/images/docs/ubuntu/03-waiting.png) -->
等待应用被完全部署：
![等待](/images/docs/ubuntu/03-waiting.png)
<!-- Run the final post-processing steps to automatically configure your Kubernetes environment:
![Postprocessing](/images/docs/ubuntu/04-postprocessing.png) -->
执行最终的后处理步骤，来自动配置 Kubernetes 环境：
![后处理](/images/docs/ubuntu/04-postprocessing.png)
<!-- Review the final summary screen:
![Final Summary](/images/docs/ubuntu/05-final-summary.png) -->
查看最终的摘要信息：
![最终的摘要](/images/docs/ubuntu/05-final-summary.png)
<!-- ## Accessing the Cluster
You can access your Kubernetes cluster by running the following: -->
## 访问集群
您可以通过运行以下命令来访问 Kubernetes 集群：
kubectl --kubeconfig=~/.kube/config
<!-- Or if you've already run this once it'll create a new config file as shown in the summary screen. -->
或者如果您已经运行过一次，它将创建一个新的配置文件，如摘要信息所示。
kubectl --kubeconfig=~/.kube/config.conjure-up
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/logging.md
+79
View File
@@ -0,0 +1,79 @@
---
title: 日志
content_template: templates/task
---
<!-- ---
title: Logging
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This page will explain how logging works within a Juju deployed cluster. -->
本文将说明日志在 Juju 部署的集群中是如何工作的。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设你已经有一个可用的 Juju 部署的集群。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Agent Logging -->
## 代理日志
<!-- The `juju debug-log` will show all of the consolidated logs of all the Juju agents running on each node of the cluster. This can be useful for finding out why a specific node hasn't deployed or is in an error state. These agent logs are located in `/var/lib/juju/agents` on every node. -->
`juju debug-log` 命令可以显示集群中每一个节点上运行的 Juju 代理所汇总的日志结果。
它可以帮助确定为何某个节点没有被部署或者是处于错误的状态。这些代理日志被存放在每个节点的 `/var/lib/juju/agents` 路径下。
<!-- See the [Juju documentation](https://jujucharms.com/docs/stable/troubleshooting-logs) for more information. -->
更多信息参见[Juju 文档](https://jujucharms.com/docs/stable/troubleshooting-logs)
<!-- ## Managing log verbosity -->
## 管理日志级别
<!-- Log verbosity in Juju is set at the model level. You can adjust it at any time: -->
Juju 中默认的日志级别是 model 级别。不过，你可以随时调整它：
```
juju add-model k8s-development --config logging-config='<root>=DEBUG;unit=DEBUG'
```
<!-- and later on your k8s-production model -->
然后在你的生态环境下的 k8s 模型进行配置
```
juju model-config -m k8s-production logging-config='<root>=ERROR;unit=ERROR'
```
<!-- In addition, the jujud daemon is started in debug mode by default on all controllers. To remove that behavior edit ```/var/lib/juju/init/jujud-machine-0/exec-start.sh``` on the controller node and comment the ```--debug``` section. -->
另外，所有控制器上的 jujud 守护进程默认使用 debug 级别。如果想要移除这种行为，编辑控制器节点上的 ```/var/lib/juju/init/jujud-machine-0/exec-start.sh``` 文件并注释掉 ```--debug``` 选项。
<!-- It then contains: -->
修改之后，如下所示：
```
#!/usr/bin/env bash
# Set up logging.
touch '/var/log/juju/machine-0.log'
chown syslog:syslog '/var/log/juju/machine-0.log'
chmod 0600 '/var/log/juju/machine-0.log'
exec >> '/var/log/juju/machine-0.log'
exec 2>&1
# Run the script.
'/var/lib/juju/tools/machine-0/jujud' machine --data-dir '/var/lib/juju' --machine-id 0 # --debug
```
<!-- Then restart the service with: -->
然后运行下面的命令，重启服务：
```
sudo systemctl restart jujud-machine-0.service
```
<!-- See the [official documentation](https://jujucharms.com/docs/stable/models-config) for more information about logging and other model settings in Juju. -->
Juju 中更多和日志与其它模型设置相关的信息请参考[官方文档](https://jujucharms.com/docs/stable/models-config)。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/monitoring.md
+234
View File
@@ -0,0 +1,234 @@
---
title: 监控
content_template: templates/task
---
<!--
---
title: Monitoring
content_template: templates/task
---
-->
{{% capture overview %}}
<!-- This page shows how to connect various logging solutions to a Juju deployed cluster. -->
本文将介绍如何将不同的日志解决方案连到已经用 Juju 部署好的 Kubernetes 集群上。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设你有一个用 Juju 部署好了的 Kubernetes 集群。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Connecting Datadog -->
## 连接 Datadog
<!-- Datadog is a SaaS offering which includes support for a range of integrations,
including Kubernetes and ETCD. While the solution is SAAS/Commercial,
they include a Free tier which is supported with the following method.
To deploy a full Kubernetes stack with Datadog out of the box, do: -->
Datadog 是一个 SaaS 方案，包含了对很多不同类型的应用集成的支持，例如，Kubernetes 和 etcd。
在提供商业版本的同时，也支持通过如下方式免费使用。
部署一个带有现成的 Databox 的 Kubernetes 集群：
```
juju deploy canonical-kubernetes-datadog
```
<!-- ### Installation of Datadog -->
### 安装 Datadog
<!-- To start, deploy the latest version Datadog from the Charm Store: -->
首先, 从 Juju 的 Charm Store 下载部署最新版本的 Datadog :
```
juju deploy datadog
```
<!-- Configure Datadog with your api-key, found in the [Datadog dashboard]().
Replace `XXXX` with your API key. -->
使用在 [Datadog dashboard]() 上的 api-key 来配置 Datadog。
将 `XXXX` 配置为你的 API 密钥。
```
juju configure datadog api-key=XXXX
```
<!-- Finally, attach `datadog` to all applications you wish to monitor.
For example, kubernetes-master, kubernetes-worker, and etcd: -->
最后, 将 `datadog` 绑定到需要监控的所有应用上。例如：kubernetes-master, kubernetes-worker, and etcd:
```
juju add-relation datadog kubernetes-worker
juju add-relation datadog kubernetes-master
juju add-relation datadog etcd
```
<!-- ## Connecting Elastic stack -->
## 连接 Elastic 栈
<!-- The Elastic stack, formally "ELK" stack, refers to Elastic Search and the suite of tools to
facilitate log aggregation, monitoring, and dashboarding.
To deploy a full Kubernetes stack with elastic out of the box, do: -->
Elastic 栈，正规地说是 "ELK" 栈, 指的是 ElasticSearch 和日志收集，监控，dashboard 的套件.
部署带有现成的 elastic 栈的 Kubernetes 集群命令如下：
```
juju deploy canonical-kubernetes-elastic
```
<!-- ### New install of ElasticSearch -->
### 初装 ElasticSearch
<!-- To start, deploy the latest version of ElasticSearch, Kibana, Filebeat, and Topbeat from the Charm Store: -->
首先, 从 Juju 的 Charm store 下载、部署最新版本的 ElasticSearch, Kibana, Filebeat 和 Topbeat：
<!-- This can be done in one command as: -->
命令行如下：
```
juju deploy beats-core
```
<!-- However, if you wish to customize the deployment, or proceed manually, the following commands can be issued: -->
此外，如果你要定制部署，或手工安装，可使用以下命令：
```
juju deploy elasticsearch
juju deploy kibana
juju deploy filebeat
juju deploy topbeat
juju add-relation elasticsearch kibana
juju add-relation elasticsearch topbeat
juju add-relation elasticsearch filebeat
```
<!-- Finally, connect filebeat and topbeat to all applications you wish to monitor.
For example, kubernetes-master and kubernetes-worker: -->
最后将 filebeat 和 topbeat 连接到所要监控的应用上。
例如：kubernetes-master 和 kubernetes-worker：
```
juju add-relation kubernetes-master topbeat
juju add-relation kubernetes-master filebeat
juju add-relation kubernetes-worker topbeat
juju add-relation kubernetes-worker filebeat
```
<!-- ### Existing ElasticSearch cluster -->
### 已装 ElasticSearch 集群
<!-- In the event an ElasticSearch cluster already exists,
the following can be used to connect and leverage it instead of creating a
new, separate, cluster.
First deploy the two beats, filebeat and topbeat -->
如果已有一个 ElasticSearch 集群已经存在的情况下，
你可以使用下面的方式来连接和使用它而不是重新创建一个单独的新集群。
首先部署 filebeat 和 topbeat 两个组件：
```
juju deploy filebeat
juju deploy topbeat
```
<!-- Configure both filebeat and topbeat to connect to your ElasticSearch cluster,
replacing `255.255.255.255` with the IP address in your setup. -->
按照如下方式可配置 filebeat 和 topbeat 对接 ElasticSearch 集群，
将 `255.255.255.255` 替换成自己配置的IP。
```
juju configure filebeat elasticsearch=255.255.255.255
juju configure topbeat elasticsearch=255.255.255.255
```
<!-- Follow the above instructions on connect topbeat and filebeat to the applications you wish to monitor. -->
使用上面的命令，将 topbeat 和 filebeat 连接到需要监控的应用上。
<!-- ## Connecting Nagios -->
## 连接 Nagios
<!-- Nagios utilizes the Nagios Remote Plugin Executor protocol (NRPE protocol)
as an agent on each node to derive machine level details of the health and applications. -->
Nagios 在每个节点上，使用 Nagions 远程执行插件协议 (NRPE 协议)作为代理
来收集节点里和健康、应用相关的详细信息。
<!-- ### New install of Nagios -->
### 初装 Nagios
<!-- To start, deploy the latest version of the Nagios and NRPE charms from the store: -->
首先, 从 Juju 的 Charm store 部署最新版本的 Nagois 和 NRPE:
```
juju deploy nagios
juju deploy nrpe
```
<!-- Connect Nagios to NRPE -->
将 Nagois 连接到 NRPE 上
```
juju add-relation nagios nrpe
```
<!-- Finally, add NRPE to all applications deployed that you wish to monitor,
for example `kubernetes-master`, `kubernetes-worker`, `etcd`, `easyrsa`, and `kubeapi-load-balancer`. -->
最后，将 NRPE 添加到所有需要部署的应用，
例如，`kubernetes-master`, `kubernetes-worker`, `etcd`, `easyrsa`, 和 `kubeapi-load-balancer`。
```
juju add-relation nrpe kubernetes-master
juju add-relation nrpe kubernetes-worker
juju add-relation nrpe etcd
juju add-relation nrpe easyrsa
juju add-relation nrpe kubeapi-load-balancer
```
<!-- ### Existing install of Nagios -->
### 已装 Nagios
<!-- If you already have an existing Nagios installation,
the `nrpe-external-master` charm can be used instead.
This will allow you to supply configuration options that map your existing
external Nagios installation to NRPE.
Replace `255.255.255.255` with the IP address of the nagios instance. -->
如果已经装有 Nagios，可以换用 `nrpe-external-master` charm 。
这样可以提供配置选项将现有的、外部 Nagios 安装映射到 NRPE上。
将 `255.255.255.255` 替换为 nagois 实例的 IP 地址。
```
juju deploy nrpe-external-master
juju configure nrpe-external-master nagios_master=255.255.255.255
```
<!-- Once configured, connect nrpe-external-master as outlined above. -->
配置完后，如上所示，连到 nrpe-external-master。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/networking.md
+92
View File
@@ -0,0 +1,92 @@
---
title: 网络
content_template: templates/task
---
<!-- ---
title: Networking
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- Kubernetes supports the [Container Network Interface (CNI)](https://github.com/containernetworking/cni).
This is a network plugin architecture that allows you to use whatever
Kubernetes-friendly SDN you want. Currently this means support for Flannel and Canal. -->
Kubernetes 支持[容器网络接口](https://github.com/containernetworking/cni)。
这个网络插件架构允许你使用任何你喜欢的、对 Kubernetes 友好的 SDN。
目前支持的插件是 Flannel 和 Canal。
<!-- This page shows how the various network portions of a cluster work and how to configure them. -->
本页将展示集群中各个网络部分是如何工作，并且对它们进行相应的配置。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本页假设你有一个已经通过 Juju 部署、正在运行的集群。
{{< note >}}
<!-- Note that if you deploy a cluster via conjure-up or the CDK bundles, manually deploying CNI plugins is unnecessary. -->
注意，如果你是通过 `conjure-up` 或者 CDK 软件包部署的集群，将不需要再手动部署 CNI 插件。
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
<!-- The CNI charms are [subordinates](https://jujucharms.com/docs/stable/authors-subordinate-applications).
These charms will require a principal charm that implements the `kubernetes-cni` interface in order to properly deploy. -->
CNI charms 在[子路径](https://jujucharms.com/docs/stable/authors-subordinate-applications)下。
这些 charms 需要主 charm 实现 `kubernetes-cni` 接口，才能正常部署。
## Flannel
```
juju deploy flannel
juju add-relation flannel kubernetes-master
juju add-relation flannel kubernetes-worker
juju add-relation flannel etcd
```
## Canal
```
juju deploy canal
juju add-relation canal kubernetes-master
juju add-relation canal kubernetes-worker
juju add-relation canal etcd
```
<!-- ### Configuration -->
### 配置
<!-- **iface** The interface to configure the flannel or canal SDN binding. If this value is
empty string or undefined the code will attempt to find the default network
adapter similar to the following command: -->
**iface** 接口是用来配置 flannel 或 canal 的 SDN 绑定。
如果属性为空字符串或未定义，程序将通过下面的命令行试图找出默认的网络适配器：
```bash
$ route | grep default | head -n 1 | awk {'print $8'}
```
<!-- **cidr** The network range to configure the flannel or canal SDN to declare when
establishing networking setup with etcd. Ensure this network range is not active
on layers 2/3 you're deploying to, as it will cause collisions and odd behavior
if care is not taken when selecting a good CIDR range to assign to flannel. It's
also good practice to ensure you allot yourself a large enough IP range to support
how large your cluster will potentially scale. Class A IP ranges with /24 are
a good option. -->
**cidr** 在用 etcd 进行网络设置时，用于配置 flannel 或 canal SDN 所要使用的网络地址范围。
请确保这个网络地址范围在所要部署的 L2/L3 上不是在用状态，
因为如果没有选择一个好的 CIDR 范围来分配给 flannel，就会出现冲突或异常行为。
同时也要保证 IP 地址范围足够大以支持未来可能会发生的集群扩容。
A 类 IP 地址 `/24` 是一个不错的选择。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/operational-considerations.md
+262
View File
@@ -0,0 +1,262 @@
---
title: 运维注意事项
content_template: templates/task
---
<!--
---
title: Operational Considerations
content_template: templates/task
---
-->
{{% capture overview %}}
<!-- This page gives recommendations and hints for people managing long lived clusters -->
本文为管理维护长期运行的集群的工程师提供一些建议和提示。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you understand the basics of Juju and Kubernetes. -->
本文假定您对 Juju 和 Kubernetes 已经有了基本的了解。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Managing Juju -->
## 管理 Juju
<!-- ### Sizing your controller node -->
### 确定控制节点规模
<!-- The Juju Controller: -->
Juju 控制器：
<!-- * requires about 2 to 2.5GB RAM to operate.
* uses a MongoDB database as a storage backend for the configuration and state of the cluster. This database can grow significantly, and can also be the biggest consumer of CPU cycles on the instance
* aggregates and stores the log data of all services and units. Therefore, significant storage is needed for long lived models. If your intention is to keep the cluster running, make sure to provision at least 64GB for the logs. -->
* 运行需要大概 2 到 2.5 GB 的 RAM。
* 用 MongoDB 数据库作为集群配置和状态的存储后端。这个数据库可能增长很快，也可能是实例中 CPU 周期的最大消费者。
* 汇总和存储所有服务和单位的日志数据。因此，长期运行的模型需要大量的存储。如果您的目的是保持集群运行，请确保为日志配置至少 64 GB 的存储空间。
<!-- To bootstrap a controller with constraints run the following command: -->
指定参数创建一个控制器（命令行如下）：
```
juju bootstrap --constraints "mem=8GB cpu-cores=4 root-disk=128G"
```
<!-- Juju will select the cheapest instance type matching your constraints on your target cloud.
You can also use the ```instance-type``` constraint in conjunction with ```root-disk``` for strict control.
For more information about the constraints available, refer to the [official documentation](https://jujucharms.com/docs/stable/reference-constraints) -->
Juju 将会选择与目标云上的约束匹配的最便宜的实例类型。
还可以通过将 ```instance-type``` 与 ```root-disk``` 两个约束结合使用来进行严格控制。
对于可用的约束信息，请参阅 [官方文档](https://jujucharms.com/docs/stable/reference-constraints)
<!-- Additional information about logging can be found in the [logging section](/docs/getting-started-guides/ubuntu/logging) -->
关于日志记录的更多信息，请参阅 [日志章节](/docs/getting-started-guides/ubuntu/logging)
<!-- ### SSHing into the Controller Node -->
### SSH 到控制节点上
<!-- By default, Juju will create a pair of SSH keys that it will use to automate the connection to units. They are stored on the client node in ```~/.local/share/juju/ssh/``` -->
默认情况下，Juju 将创建一对 SSH 密钥，用于自动化单元之间的连接。
这对密钥保存在客户端节点的 ```~/.local/share/juju/ssh/``` 路径下。
<!-- After deployment, Juju Controller is a "silent unit" that acts as a proxy between the client and the deployed applications. Nevertheless it can be useful to SSH into it. -->
部署完后，Juju 控制器是一个 "无声单元"，
其充当客户端和已部署应用程序之间的代理。
尽管如此，SSH 到控制器上还是很有用的。
<!-- First you need to understand your environment, especially if you run several Juju models and controllers. Run -->
首先，你需要了解你的运行环境，特别是如果你运行了几个 Juju 模型和控制器。
运行下面的命令行：
```
juju list-models --all
$ juju models --all
Controller: k8s
Model Cloud/Region Status Machines Cores Access Last connection
admin/controller lxd/localhost available 1 - admin just now
admin/default lxd/localhost available 0 - admin 2017-01-23
admin/whale* lxd/localhost available 6 - admin 3 minutes ago
```
<!-- The first line ```Controller: k8s``` refers to how you bootstrapped. -->
第一行的 ```Controller: k8s``` 表明是如何引导创建的控制器。
<!-- Then you will see 2, 3 or more models listed below. -->
接着可以看见下面列了 2 个，3 个或更多的类型。
<!-- * admin/controller is the default model that hosts all controller units of juju
* admin/default is created by default as the primary model to host the user application, such as the Kubernetes cluster
* admin/whale is an additional model created if you use conjure-up as an overlay on top of Juju. -->
* admin/controller 是托管 juju 所有控制器单元的默认模型
* admin/default 默认情况下，作为托管用户应用程序的主要模型，例如 Kubernetes 集群
* admin/whale 是一个额外的模型，如在 Juju 之上，叠加使用 conjure-up 的话
<!-- Now to ssh into a controller node, you first ask Juju to switch context, then ssh as you would with a normal unit: -->
现在开始 ssh 到控制节点上，首先是让 Juju 切换上下文，然后是像一般单元那样 ssh 到控制节点上：
```
juju switch controller
```
<!-- At this stage, you can query the controller model as well: -->
在这个阶段，也可以查询控制器模型：
```
juju status
Model Controller Cloud/Region Version
controller k8s lxd/localhost 2.0.2
App Version Status Scale Charm Store Rev OS Notes
Unit Workload Agent Machine Public address Ports Message
Machine State DNS Inst id Series AZ
0 started 10.191.22.15 juju-2a5ed8-0 xenial
```
<!-- Note that if you had bootstrapped in HA mode, you would see several machines listed. -->
请注意，如果是在 HA 模式下进行的引导，
会在列表中看到几台机器。
<!-- Now ssh-ing into the controller follows the same semantic as classic Juju commands: -->
现在 ssh 到控制器节点上，遵循和经典 Juju 命令相同的语义：
```
$ juju ssh 0
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.8.0-34-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
0 packages can be updated.
0 updates are security updates.
Last login: Tue Jan 24 16:38:13 2017 from 10.191.22.1
ubuntu@juju-2a5ed8-0:~$
```
<!-- When you are done and want to come back to your initial model, exit the controller and -->
在结束完操作，想要返回到最初的模型，退出控制器即可。
<!-- Then if you need to switch back to your cluster and ssh into the units, run -->
如果，还想要切换回集群，ssh 到其他单元上，运行下面的命令行进行切换：
```
juju switch default
```
<!-- ## Managing your Kubernetes cluster -->
## 管理 Kubernetes 集群
<!-- ### Running privileged containers -->
### 运行特权容器
<!-- By default, juju-deployed clusters only allow running privileged containers on nodes with GPUs.
If you need privileged containers on other nodes,
you have to enable the ```allow-privileged``` config on both kubernetes-master and kubernetes-worker: -->
默认情况下，juju 部署的集群不支持在带有 GPU 的节点上运行特权容器。
如果需要在其它节点上运行特权容器，只能是在 kubernetes-master 和 kubernetes-worker 节点上
使能 ```allow-privileged``` 参数：
```
juju config kubernetes-master allow-privileged=true
juju config kubernetes-worker allow-privileged=true
```
<!-- ### Private registry -->
### 私有仓库
<!-- With the registry action, you can easily create a private docker registry that
uses TLS authentication.
However, note that a registry deployed with that action
is not HA;
it uses storage tied to the kubernetes node where the pod is running.
Consequently, if the registry pod is migrated from one node to another, you will
need to re-publish the images. -->
通过 registry 操作，您可以很容易地创建一个使用 TLS 身份验证的私有 docker 仓库。
但是请注意，通过这些功能部署的仓库不是高可用性的；
它使用的存储绑定到运行 pod 的 kubernetes 节点上。
因此，如果仓库所在的 pod 从一个节点迁移到另一个节点上，
那么你需要重新发布镜像。
<!-- #### Example usage -->
#### 使用示例
<!-- Create the relevant authentication files. Let's say you want user ```userA```
to authenticate with the password ```passwordA```. Then you'll do: -->
创建相关的身份验证文件。
例如用户为 ```userA``` 密码为 ```passwordA``` 用来进行身份验证，
命令行如下：
```
echo "userA:passwordA" > htpasswd-plain
htpasswd -c -b -B htpasswd userA passwordA
```
<!-- (the `htpasswd` program comes with the ```apache2-utils``` package) -->
（`htpasswd` 程序通过 ```apache2-utils``` 包获得）
<!-- Assuming that your registry will be reachable at ```myregistry.company.com```,
you already have your TLS key in the ```registry.key``` file, and your TLS
certificate (with ```myregistry.company.com``` as Common Name) in the ```registry.crt``` file, you would then run: -->
假设您的仓库可以通过 ```myregistry.company.com``` 访问，
您已经在 ```registry.key``` 文件中拥有了您的 TLS 密钥，
并且您的 TLS 身份验证（以 ```myregistry.company.com``` 作为 Common Name）在
```registry.crt``` 文件中，那么您可以运行：
```
juju run-action kubernetes-worker/0 registry domain=myregistry.company.com htpasswd="$(base64 -w0 htpasswd)" htpasswd-plain="$(base64 -w0 htpasswd-plain)" tlscert="$(base64 -w0 registry.crt)" tlskey="$(base64 -w0 registry.key)" ingress=true
```
<!-- If you then decide that you want to delete the registry, just run: -->
如果决定删除镜像仓库，命令行如下：
```
juju run-action kubernetes-worker/0 registry delete=true ingress=true
```
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/rancher.md
+543
View File
@@ -0,0 +1,543 @@
---
title: Rancher 与 Ubuntu Kubernetes 集成
cn-approvers:
- chentao1596
---
<!-- ---
title: Rancher Integration with Ubuntu Kubernetes
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This repository explains how to deploy Rancher 2.0alpha on Canonical Kubernetes. -->
本文将介绍如何在 Canonical Kubernetes 集群上部署 Rancher 2.0 alpha。
<!-- These steps are currently in alpha/testing phase and will most likely change. -->
这些步骤目前处于 alpha/testing 阶段，未来很可能会发生变化。
<!-- The original documentation for this integration can be found at [https://github.com/CalvinHartwell/canonical-kubernetes-rancher/](https://github.com/CalvinHartwell/canonical-kubernetes-rancher/). -->
有关此集成的原始文档可以在 [https://github.com/CalvinHartwell/canonical-kubernetes-rancher/](https://github.com/CalvinHartwell/canonical-kubernetes-rancher/) 上找到。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- To use this guide, you must have a working kubernetes cluster that was deployed using Canonical's juju. -->
本文假设你有一个已经通过 Juju 部署、正在运行的集群。
<!-- The full instructions for deploying Kubernetes with juju can be found at [/docs/getting-started-guides/ubuntu/installation/](/docs/getting-started-guides/ubuntu/installation/). -->
有关使用 juju 部署 Kubernetes 集群的完整指导，请参考 [/docs/getting-started-guides/ubuntu/installation/](/docs/getting-started-guides/ubuntu/installation/)。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Deploying Rancher -->
## 部署 Rancher
<!-- To deploy Rancher, we just need to run the Rancher container workload on-top of Kubernetes.
Rancher provides their containers through dockerhub ([https://hub.docker.com/r/rancher/server/tags/](https://hub.docker.com/r/rancher/server/tags/)) and can be downloaded freely from the internet. -->
想要部署 Rancher，我们只需要在 Kubernetes 集群上运行 Rancher 容器工作负载即可。
Rancher 通过 dockerhub（[https://hub.docker.com/r/rancher/server/tags/](https://hub.docker.com/r/rancher/server/tags/)）
提供他们的容器镜像的免费下载。
<!-- If you're running your own registry or have an offline deployment,
the container should be downloaded and pushed to a private registry before proceeding. -->
如果您正在使用自己的镜像仓库，或进行离线部署，
那么，在开始部署之前，请先下载好这些容器镜像，将其推入私有镜像仓库中。
<!-- ### Deploying Rancher with a nodeport -->
### 使用 nodeport 部署 Rancher
<!-- First create a yaml file which defines how to deploy Rancher on kubernetes.
Save the file as cdk-rancher-nodeport.yaml: -->
首先创建一个 yaml 文件，该文件定义了如何在 kubernetes 上部署 Rancher。
将该文件保存为 cdk-rancher-nodeport.yaml：
```
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
---
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: rancher
name: rancher
spec:
replicas: 1
selector:
matchLabels:
app: rancher
ima: pod
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: rancher
ima: pod
spec:
containers:
- image: rancher/server:preview
imagePullPolicy: Always
name: rancher
ports:
- containerPort: 80
- containerPort: 443
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
timeoutSeconds: 30
resources: {}
restartPolicy: Always
serviceAccountName: ""
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: rancher
labels:
app: rancher
spec:
ports:
- port: 443
protocol: TCP
targetPort: 443
selector:
app: rancher
---
apiVersion: v1
kind: Service
metadata:
name: rancher-nodeport
spec:
type: NodePort
selector:
app: rancher
ports:
- name: rancher-api
protocol: TCP
nodePort: 30443
port: 443
targetPort: 443
```
<!-- Once kubectl is running and working, run the following command to deploy Rancher: -->
kubectl 开始正常运行后，执行下面的命令开始部署 Rancher：
```
kubectl apply -f cdk-rancher-nodeport.yaml
```
<!-- Now we need to open this nodeport so we can access it.
For that, we can use juju. We need to run the open-port command for each of the worker nodes in our cluster.
Inside the cdk-rancher-nodeport.yaml file, the nodeport has been set to 30443.
Below shows how to open the port on each of the worker nodes: -->
现在我们需要打开这个 nodeport，以供访问。
为此，我们可以使用 juju。我们需要在集群中的每个工作节点上运行 open-port 命令。
在 cdk-rancher-nodeport.yaml 文件中，nodeport 已设置为 30443。
下面的命令行展示如何在每个工作节点上打开端口：
<!-- ```
# repeat this for each kubernetes worker in the cluster.
juju run --unit kubernetes-worker/0 "open-port 30443"
juju run --unit kubernetes-worker/1 "open-port 30443"
juju run --unit kubernetes-worker/2 "open-port 30443"
``` -->
```
# 在集群的每个工作节点上运行下面的命令行
juju run --unit kubernetes-worker/0 "open-port 30443"
juju run --unit kubernetes-worker/1 "open-port 30443"
juju run --unit kubernetes-worker/2 "open-port 30443"
```
<!-- Rancher can now be accessed on this port through a worker IP or DNS entries if you have created them.
It is generally recommended that you create a DNS entry for each of the worker nodes in your cluster.
For example, if you have three worker nodes and you own the domain example.com,
you could create three A records, one for each worker in the cluster. -->
现在便可以通过工作节点的 IP 或 DNS 记录（如果已经创建）在此端口上访问 Rancher。
通常建议您为集群中的每个工作节点创建一条 DNS 记录。
例如，如果有三个工作节点并且域名是 example.com，则可以创建三条 A 记录，集群中的每个工作节点各一条。
<!-- As creating DNS entries is outside of the scope of this document,
we will use the freely available xip.io service which can return A records for an IP address
which is part of the domain name.
For example, if you have the domain rancher.35.178.130.245.xip.io,
the xip.io service will automatically return the IP address 35.178.130.245 as an
A record which is useful for testing purposes.
For your deployment, the IP address 35.178.130.245 should be replaced with one of your worker IP address,
which can be found using Juju or AWS: -->
由于创建 DNS 记录超出了本文关注的范围，
我们将使用免费服务 xip.io 来获得和 IP 地址相对应的 A 记录，IP 地址将是域名的一部分。
例如，如果有域名 rancher.35.178.130.245.xip.io，
则 xip.io 服务会自动将 IP 地址 35.178.130.245 作为 A 记录返回，这对测试相当有用。
至于您的部署，IP 地址 35.178.130.245 应该替换为集群工作节点的 IP 地址，这个 IP 地址可以通过 Juju 或 AWS 得到：
<!-- ```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... output omitted.
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# Note the IP addresses for the kubernetes-workers in the example above. You should pick one of the public addresses.
``` -->
```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... 输出省略。
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# 注意上面输出中 kubernetes-worker 的 IP 地址，可以选一个用作设置。
```
<!-- Try opening up Rancher in your browser using the nodeport and the domain name or ip address: -->
尝试使用 nodeport 搭配域名或 IP 地址在浏览器中打开 Rancher：
<!-- ```
# replace the IP address with one of your Kubernetes worker, find this from juju status command.
wget https://35.178.130.245.xip.io:30443 --no-check-certificate
# this should also work
wget https://35.178.130.245:30443 --no-check-certificate
``` -->
```
# 将 IP 地址替换为某个 Kubernetes 工作节点的公共地址，通过 juju status 命令进行查找。
wget https://35.178.130.245.xip.io:30443 --no-check-certificate
# 这条命令也应该能工作
wget https://35.178.130.245:30443 --no-check-certificate
```
<!-- If you need to make any changes to the kubernetes configuration file,
edit the yaml file and then just use apply again: -->
如果需要对 kubernetes 配置文件进行任何更改，编辑 yaml 文件，再重新 apply 即可：
```
kubectl apply -f cdk-rancher-nodeport.yaml
```
<!-- ### Deploying Rancher with an ingress rule -->
### 使用 ingress 规则部署 Rancher
<!-- It is also possible to deploy Rancher using an ingress rule.
This has the added benefit of not requiring additional ports to be opened up on
the Kubernetes cluster. First create a yaml file to describe the
deployment called cdk-rancher-ingress.yaml which should contain the following: -->
也可以使用 ingress 规则来部署 Rancher。
这还有另外一个好处，就是不需要在 Kubernetes 集群上打开额外的端口。
首先创建一个名为 cdk-rancher-ingress.yaml 的文件，内容如下：
```
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
---
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: rancher
name: rancher
spec:
replicas: 1
selector:
matchLabels:
app: rancher
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: rancher
spec:
containers:
- image: rancher/server:preview
imagePullPolicy: Always
name: rancher
ports:
- containerPort: 443
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
timeoutSeconds: 30
resources: {}
restartPolicy: Always
serviceAccountName: ""
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: rancher
labels:
app: rancher
spec:
ports:
- port: 443
targetPort: 443
protocol: TCP
selector:
app: rancher
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: rancher
annotations:
kubernetes.io/tls-acme: "true"
ingress.kubernetes.io/secure-backends: "true"
spec:
tls:
- hosts:
- rancher.34.244.118.135.xip.io
rules:
- host: rancher.34.244.118.135.xip.io
http:
paths:
- path: /
backend:
serviceName: rancher
servicePort: 443
```
<!-- It is generally recommended that you create a DNS entry for each of the worker nodes in your cluster.
For example, if you have three worker nodes and you own the domain example.com,
you could create three A records, one for each worker in the cluster. -->
通常建议您为集群中的每个工作节点创建一条 DNS 记录。
例如，如果有三个工作节点并且域名是 example.com，则可以创建三条 A 记录，集群中的每个工作节点各一条。
<!-- As creating DNS entries is outside of the scope of this tutorial, we will use the freely available xip.io service which can return A records for an IP address which is part of the domain name. For example, if you have the domain rancher.35.178.130.245.xip.io, the xip.io service will automatically return the IP address 35.178.130.245 as an A record which is useful for testing purposes. -->
由于创建 DNS 记录超出了本文关注的范围，
我们将使用免费服务 xip.io 来获得和 IP 地址相对应的 A 记录，IP 地址将是域名的一部分。
例如，如果有域名 rancher.35.178.130.245.xip.io，
则 xip.io 服务会自动将 IP 地址 35.178.130.245 作为 A 记录返回，这对测试相当有用。
<!-- For your deployment, the IP address 35.178.130.245 should be replaced with one of your worker IP address, which can be found using Juju or AWS: -->
至于您的部署，IP 地址 35.178.130.245 应该替换为集群工作节点的 IP 地址，这个 IP 地址可以通过 Juju 或 AWS 得到：
<!-- ```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... output omitted.
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# Note the IP addresses for the kubernetes-workers in the example above. You should pick one of the public addresses.
``` -->
```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... 输出省略。
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# 注意上面输出中 kubernetes-worker 的 IP 地址，可以选一个用作设置。
```
<!-- Looking at the output from the juju status above, the Public Address (35.178.130.245) can be used to create a xip.io DNS entry (rancher.35.178.130.245.xip.io) which should be placed into the cdk-rancher-ingress.yaml file. You could also create your own DNS entry as long as it resolves to each of the worker nodes or one of them it will work fine: -->
查看上面 juju status 的命令输出，可以拿公共地址（35.178.130.245）来创建 xip.io DNS记录（rancher.35.178.130.245.xip.io），记录可以加到 cdk-rancher-ingress.yaml 文件中。
你也同样可以创建自己的 DNS 记录，只要能解析到集群上的工作节点即可:
<!-- ```
# The xip.io domain should appear in two places in the file, change both entries.
cat cdk-rancher-ingress.yaml | grep xip.io
- host: rancher.35.178.130.245.xip.io
``` -->
```
# xip.io 在文件中会出现两次，请都替换修改。
cat cdk-rancher-ingress.yaml | grep xip.io
- host: rancher.35.178.130.245.xip.io
```
<!-- Once you've edited the ingress rule to reflect your DNS entries, run the kubectl apply -f cdk-rancher-ingress.yaml to deploy Kubernetes: -->
修改完 ingress 规则之后，可以运行 `kubectl apply -f cdk-rancher-ingress.yaml` 命令来更新 Kubernetes 集群：
```
kubectl apply -f cdk-rancher-ingress.yaml
```
<!-- Rancher can now be accessed on the regular 443 through a worker IP or DNS entries if you have created them.
Try opening it up in your browser: -->
现在可以通过工作节点 IP 或者 DNS 记录（如果已创建）在常规的 443 上访问 Rancher。
尝试在浏览器中打开它：
<!-- ```
# replace the IP address with one of your Kubernetes worker, find this from juju status command.
wget https://35.178.130.245.xip.io:443 --no-check-certificate
``` -->
```
# 将 IP 地址替换为某个 Kubernetes 工作节点的公共地址，通过 juju status 命令进行查找。
wget https://35.178.130.245.xip.io:443 --no-check-certificate
```
<!-- If you need to make any changes to the kubernetes configuration file,
edit the yaml file and then just use apply again: -->
如果需要对 kubernetes 配置文件进行任何更改，请编辑 yaml 文件，再 apply：
```
kubectl apply -f cdk-rancher-ingress.yaml
```
<!-- ### Removing Rancher -->
### 删除 Rancher
<!-- You can remove Rancher from your cluster using kubectl.
Deleting constructs in Kubernetes is as simple as creating them: -->
您可以使用 kubectl 从集群中删除 Rancher。
在 Kubernetes 中删除对象与创建它们的过程一样简单：
<!-- ```
# If you used the nodeport example change the yaml filename if you used the ingress example.
kubectl delete -f cdk-rancher-nodeport.yaml
``` -->
```
# 使用 nodeport 示例（如果使用 ingress 示例，请修改文件名）
kubectl delete -f cdk-rancher-nodeport.yaml
```
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/scaling.md
+147
View File
@@ -0,0 +1,147 @@
---
title: 扩缩
content_template: templates/task
---
<!-- ---
title: Scaling
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This page shows how to horizontally scale master and worker nodes on a cluster. -->
本文将讨论如何在集群中扩缩主节点和工作节点。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设您已经有一个用 Juju 部署、正在运行的集群。
<!-- Any of the applications can be scaled out post-deployment.
The charms update the status messages with progress, so it is recommended to run. -->
任何应用都可以在部署之后进行横向扩容。
charms 将会不停地更新进度状态信息，建议运行如下命令。
```
watch -c juju status --color
```
{{% /capture %}}
{{% capture steps %}}
<!-- ## Kubernetes masters -->
## Kubernetes 主节点
<!-- The provided Kubernetes master nodes act as a control plane for the cluster.
The deployment has been designed so that these nodes can be scaled independently
of worker nodes to allow for more operational flexibility.
To scale a master node up, simply execute: -->
Kubernetes 主节点充当了集群中控制平面的角色。
在设计上，这些主节点可以独立于工作节点进行扩缩容，从而带来运维上的灵活性。
想要添加一个主节点，只需要执行以下命令：
juju add-unit kubernetes-master
<!-- This will add another master node to the control plane.
See the [building high-availability clusters](/docs/admin/high-availability)
section of the documentation for more information. -->
这将会在控制平面中添加一个新的主节点。
参见[构建高可用集群](/docs/admin/high-availability)文档，获取更多信息。
<!-- ## Kubernetes workers -->
## Kubernetes 工作节点
<!-- The kubernetes-worker nodes are the load-bearing units of a Kubernetes cluster. -->
kubernetes-worker 节点是 Kubernetes 集群中承担负载的部分。
<!-- By default pods are automatically spread throughout the kubernetes-worker units
that you have deployed. -->
默认情况下，pod 会自动均匀部署在 kubernetes-worker 节点上。
<!-- To add more kubernetes-worker units to the cluster: -->
如果想要在集群中添加更多的 kubernetes-worker 节点，运行如下命令：
```
juju add-unit kubernetes-worker
```
<!-- or specify machine constraints to create larger nodes: -->
或者修改机器限制，来创建更大的节点：
```
juju set-constraints kubernetes-worker "cpu-cores=8 mem=32G"
juju add-unit kubernetes-worker
```
<!-- Refer to the
[machine constraints documentation](https://jujucharms.com/docs/stable/charms-constraints)
for other machine constraints that might be useful for the kubernetes-worker units. -->
参见[机器限制文档](https://jujucharms.com/docs/stable/charms-constraints)，
了解其它机器约束，这些约束可能对 kubernetes-worker unit 有帮助。
## etcd
<!-- Etcd is used as a key-value store for the Kubernetes cluster.
The bundle defaults to one instance in this cluster. -->
Etcd 在 Kubernetes 集群中用作键值存储。
集群默认使用一个存储实例。
<!-- For quorum reasons it is recommended to keep an odd number of etcd nodes.
3, 5, 7, and 9 nodes are the recommended amount of nodes,
depending on your cluster size. The CoreOS etcd documentation has a chart for the
[optimal cluster size](https://coreos.com/etcd/docs/latest/admin_guide.html#optimal-cluster-size)
to determine fault tolerance. -->
由于仲裁机制的关系，推荐保有奇数个 etcd 节点。
根据集群的大小，推荐使用3、5、7 或 9 个节点。
CoreOS etcd 文档有一个关于[最佳集群大小](https://coreos.com/etcd/docs/latest/admin_guide.html#optimal-cluster-size)的图表，
可以参考确定最佳的容错设计。
<!-- To add an etcd unit: -->
添加 etcd 单元:
```
juju add-unit etcd
```
<!-- Shrinking of an etcd cluster after growth is not recommended. -->
不建议在扩容 etcd 集群之后对其缩容。
<!-- ## Juju controller -->
## Juju 控制器
<!-- A single node is responsible for coordinating with all the Juju agents
on each machine that manage Kubernetes; it is called the controller node.
For production deployments it is recommended to enable HA of the controller node: -->
一个负责协调每台机器上 Juju 代理（这些代理管理 Kubernetes 集群）的节点被称为控制器节点。
对于生产环境下的部署，建议启用控制器节点的高可用性：
juju enable-ha
<!-- Enabling HA results in 3 controller nodes, this should be sufficient for most use cases.
5 and 7 controller nodes are also supported for extra large deployments. -->
启用 HA 将会创建 3 个控制器节点，对于大多数情况而言应该是足够的。
而对于超大型的部署，也同时支持 5 或 7 个控制器节点。
<!-- Refer to the [Juju HA controller documentation](https://jujucharms.com/docs/2.2/controllers-ha) for more information. -->
参见 [Juju HA 控制器文档](https://jujucharms.com/docs/2.2/controllers-ha) 获取更多信息.
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/storage.md
+138
View File
@@ -0,0 +1,138 @@
---
title: 存储
content_template: templates/task
---
<!-- ---
title: Storage
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This page explains how to install and configure persistent storage on a cluster. -->
本文解释了如何在集群中安装和配置持久化存储。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设您已经有一个用 Juju 部署、正在运行的集群。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Ceph Persistent Volumes -->
## Ceph 持久卷
<!-- The Canonical Distribution of Kubernetes allows you to connect with durable
storage devices such as [Ceph](http://ceph.com). When paired with the
[Juju Storage](https://jujucharms.com/docs/2.0/charms-storage) feature you
can add durable storage easily and across clouds. -->
Canonical 的 Kubernetes 发行版允许添加持久化存储设备，例如 [Ceph](http://ceph.com)。
配合 [Juju Storage](https://jujucharms.com/docs/2.0/charms-storage)功能，
可以跨云平台，添加持久化存储。
<!-- Deploy a minimum of three ceph-mon and three ceph-osd units. -->
部署一个至少有三个 ceph-mon 和三个 ceph-osd 单元的存储池。
```
juju deploy cs:ceph-mon -n 3
juju deploy cs:ceph-osd -n 3
```
<!-- Relate the units together: -->
关联这些单元：
```
juju add-relation ceph-mon ceph-osd
```
<!-- List the storage pools available to Juju for your cloud: -->
列出云上 Juju 可用的存储池：
juju storage-pools
<!-- Output: -->
输出：
```
Name Provider Attrs
ebs ebs
ebs-ssd ebs volume-type=ssd
loop loop
rootfs rootfs
tmpfs tmpfs
```
{{< note >}}
<!-- This listing is for the Amazon Web Services public cloud.
Different clouds may have different pool names. -->
注意列表使用的是 AWS，不同的云有不同的存储池名称。
{{< /note >}}
<!-- Add a storage pool to the ceph-osd charm by NAME,SIZE,COUNT: -->
以 “名字,大小,数量”的格式往 ceph-osd charm 中添加存储池：
```
juju add-storage ceph-osd/0 osd-devices=ebs,10G,1
juju add-storage ceph-osd/1 osd-devices=ebs,10G,1
juju add-storage ceph-osd/2 osd-devices=ebs,10G,1
```
<!-- Next relate the storage cluster with the Kubernetes cluster: -->
接下来将 Kubernetes 和存储集群相关联：
```
juju add-relation kubernetes-master ceph-mon
```
<!-- We are now ready to enlist
[Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
in Kubernetes which our workloads can consume via Persistent Volume (PV) claims. -->
现在我们可以在 Kubernetes 中列举可用的[持久卷](/docs/concepts/storage/persistent-volumes/)，
集群中的负载可以通过 PVC 申领来使用这些持久卷。
```
juju run-action kubernetes-master/0 create-rbd-pv name=test size=50
```
<!-- This example created a "test" Rados Block Device (rbd) in the size of 50 MB.
Use watch on your Kubernetes cluster like the following, you should see the PV
become enlisted and be marked as available: -->
本例中创建了 50 MB 大小的 “test” Rados 块设备 (rbd)。
在 Kubernetes 集群上使用如下所示的 watch 命令，可以看到 PV 加入列表，并被标记可用的过程：
watch kubectl get pv
<!-- Output: -->
输出:
```
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
test 50M RWO Available 10s
```
<!-- To consume these Persistent Volumes, your pods will need an associated
Persistent Volume Claim with them, and is outside the scope of this README.
See the [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
documentation for more information. -->
要使用这些持久卷，pods 需要关联一个持久卷申领，这超出了本文档的讨论范围。
参见[持久卷](/docs/concepts/storage/persistent-volumes/)获取更多信息。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/troubleshooting.md
+272
View File
@@ -0,0 +1,272 @@
---
title: 故障排除
---
<!-- ---
title: Troubleshooting
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This document with highlighting how to troubleshoot the deployment of a Kubernetes cluster,
it will not cover debugging of workloads inside Kubernetes. -->
本文重点讨论如何解决 Kubernetes 集群部署过程中的问题，
而不会关心如何调试 Kubernetes 集群内的工作负载。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working Juju deployed cluster. -->
本文假设您已经有一个用 Juju 部署、正在工作的集群。
{{% /capture %}}
{{% capture steps %}}
<!-- ## Understanding Cluster Status -->
## 了解集群状态
<!-- Using `juju status` can give you some insight as to what's happening in a cluster: -->
使用 `juju status` 命令可以了解一些集群内的情况：
```
Model Controller Cloud/Region Version
kubes work-multi aws/us-east-2 2.0.2.1
App Version Status Scale Charm Store Rev OS Notes
easyrsa 3.0.1 active 1 easyrsa jujucharms 3 ubuntu
etcd 2.2.5 active 1 etcd jujucharms 17 ubuntu
flannel 0.6.1 active 2 flannel jujucharms 6 ubuntu
kubernetes-master 1.4.5 active 1 kubernetes-master jujucharms 8 ubuntu exposed
kubernetes-worker 1.4.5 active 1 kubernetes-worker jujucharms 11 ubuntu exposed
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0/lxd/0 10.0.0.55 Certificate Authority connected.
etcd/0* active idle 0 52.15.47.228 2379/tcp Healthy with 1 known peers.
kubernetes-master/0* active idle 0 52.15.47.228 6443/tcp Kubernetes master services ready.
flannel/1 active idle 52.15.47.228 Flannel subnet 10.1.75.1/24
kubernetes-worker/0* active idle 1 52.15.177.233 80/tcp,443/tcp Kubernetes worker running.
flannel/0* active idle 52.15.177.233 Flannel subnet 10.1.63.1/24
Machine State DNS Inst id Series AZ
0 started 52.15.47.228 i-0bb211a18be691473 xenial us-east-2a
0/lxd/0 started 10.0.0.55 juju-153b74-0-lxd-0 xenial
1 started 52.15.177.233 i-0502d7de733be31bb xenial us-east-2b
```
<!-- In this example we can glean some information. The `Workload` column will show the status of a given service.
The `Message` section will show you the health of a given service in the cluster.
During deployment and maintenance these workload statuses will update to
reflect what a given node is doing. For example the workload my say `maintenance`
while message will describe this maintenance as `Installing docker`. -->
在这个例子中，我们可以获取一些信息。 `Workload` 列将显示给定服务的状态。
`Message` 部分将显示集群中给定服务的健康状况。 在部署和维护期间，
这些工作负载状态将进行更新以反映给定节点正在执行的操作。例如，
Workload 可能显示为 `maintenance`，而 Message 则会相应显示为 `Installing docker`。
<!-- During normal operation the Workload should read `active`,
the Agent column (which reflects what the Juju agent is doing) should read `idle`,
and the messages will either say `Ready` or another descriptive term.
`juju status --color` will also return all green results when a cluster's deployment is healthy. -->
正常情况下，Workload 列应该为 `active`，Agent 列（用于反映 Juju 代理正在做什么）应该为 `idle`，
而 Message 要么是 `Ready` 或者其它描述性的术语。
如果集群运行健康，`juju status --color` 返回的结果输出都将是绿色的。
<!-- Status can become unwieldy for large clusters, it is then recommended to
check status on individual services, for example to check the status on the workers only: -->
对于大型集群而言，状态信息可能会太多，因此建议检查各个服务的状态，例如仅检查工作节点的状态：
juju status kubernetes-worker
<!-- or just on the etcd cluster: -->
或者只检查 etcd 集群的状态：
juju status etcd
Errors will have an obvious message, and will return a red result when used with
`juju status --color`. Nodes that come up in this manner should be investigated.
错误都会有明显的错误信息，使用 `juju status --color` 的返回结果也将是红色的。
如果节点状态出现这种情况，需要相应地检查了解。
<!-- ## SSHing to units -->
## SSH 到各个单元上
<!-- You can ssh to individual units easily with the following convention,
`juju ssh <servicename>/<unit#>`: -->
按照 `juju ssh <服务名>/<单元#>` 的命令格式可以轻松地连接到各个单元上：
juju ssh kubernetes-worker/3
<!-- Will automatically ssh you to the 3rd worker unit. -->
将会 ssh 到第 3 个工作单元上。
juju ssh easyrsa/0
<!-- This will automatically ssh you to the easyrsa unit. -->
将会 ssh 到第 0 个 easyrsa 单元上。
<!-- ## Collecting debug information -->
## 收集调试信息
<!-- Sometimes it is useful to collect all the information from a cluster
to share with a developer to identify problems. This is best accomplished with [CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent). -->
有时候，从集群上收集所有的信息，并与开发人员共享，将有助于发现问题。
这最好是通过 [CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent) 来完成。
<!-- Download and execute the collect.py script from [CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent) on a box that has a Juju client configured with the current controller and model pointing at the CDK deployment of interest. -->
在带有 Juju 客户端，而客户端配有指向相应的 CDK 部署的控制器的节点上，
下载并执行[CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent)中的 collect.py 文件。
<!-- Running the script will generate a tarball of system information and includes basic information such as systemctl status, Juju logs, charm unit data, etc. Additional application-specific information may be included as well. -->
运行该脚本会生成一个 tar 包，包含系统信息以及诸如 systemctl 状态，Juju 日志，charm 单元数据等基本信息。
额外和应用相关的信息可能也会包含其中。
<!-- ## Common Problems -->
## 常见问题
<!-- ### Load Balancer interfering with Helm -->
### 负载均衡器对 Helm 的影响
<!-- This section assumes you have a working deployment of Kubernetes via Juju
using a Load Balancer for the API, and that you are using Helm to deploy charts. -->
本节假定有一个用 Juju 部署的正在运行的 Kubernetes 集群，使用负载均衡器来代理 API，同时也用 Helm 来进行 chart 部署。
<!-- To deploy Helm you will have run: -->
Helm 初始化：
```
helm init
$HELM_HOME has been configured at /home/ubuntu/.helm
Tiller (the helm server side component) has been installed into your Kubernetes Cluster.
Happy Helming!
```
<!-- Then when using helm you may see one of the following errors: -->
随后使用 helm 时，可能会出现以下错误：
<!-- * Helm doesn't get the version from the Tiller server -->
* Helm 不能从 Tiller 服务器获取版本号
```
helm version
Client: &version.Version{SemVer:"v2.1.3", GitCommit:"5cbc48fb305ca4bf68c26eb8d2a7eb363227e973", GitTreeState:"clean"}
Error: cannot connect to Tiller
```
<!-- * Helm cannot install your chart -->
* Helm 不能安装 chart
```
helm install <chart> --debug
Error: forwarding ports: error upgrading connection: Upgrade request required
```
<!-- This is caused by the API load balancer not forwarding ports in the context of the helm client-server relationship.
To deploy using helm, you will need to follow these steps: -->
这是因为 API 负载均衡器在 helm 客户端-服务端关系的上下文中不进行端口转发造成的。
要使用 helm 进行部署，需要执行以下步骤：
<!-- 1. Expose the Kubernetes Master service -->
1. 暴露 Kubernetes Master 服务
```
juju expose kubernetes-master
```
<!-- 1. Identify the public IP address of one of your masters -->
1. 确定其中一个主节点的公开 IP 地址
```
juju status kubernetes-master
Model Controller Cloud/Region Version
production k8s-admin aws/us-east-1 2.0.0
App Version Status Scale Charm Store Rev OS Notes
flannel 0.6.1 active 1 flannel jujucharms 7 ubuntu
kubernetes-master 1.5.1 active 1 kubernetes-master jujucharms 10 ubuntu exposed
Unit Workload Agent Machine Public address Ports Message
kubernetes-master/0* active idle 5 54.210.100.102 6443/tcp Kubernetes master running.
flannel/0 active idle 54.210.100.102 Flannel subnet 10.1.50.1/24
Machine State DNS Inst id Series AZ
5 started 54.210.100.102 i-002b7150639eb183b xenial us-east-1a
Relation Provides Consumes Type
certificates easyrsa kubernetes-master regular
etcd etcd flannel regular
etcd etcd kubernetes-master regular
cni flannel kubernetes-master regular
loadbalancer kubeapi-load-balancer kubernetes-master regular
cni kubernetes-master flannel subordinate
cluster-dns kubernetes-master kubernetes-worker regular
cni kubernetes-worker flannel subordinate
```
<!-- In this context the public IP address is 54.210.100.102.
If you want to access this data programmatically you can use the JSON output: -->
本例中，公开 IP 地址为 54.210.100.102。
如果想编程访问得到这个值，可以使用 JSON 输出：
```
juju show-status kubernetes-master --format json | jq --raw-output '.applications."kubernetes-master".units | keys[]'
54.210.100.102
```
<!-- 1. Update the kubeconfig file -->
1. 更新 kubeconfig 文件
<!-- Identify the kubeconfig file or section used for this cluster, and edit the server configuration.
By default, it will look like ```https://54.213.123.123:443```. Replace it with the Kubernetes Master endpoint ```https://54.210.100.102:6443``` and save.
Note that the default port used by CDK for the Kubernetes Master API is 6443 while the port exposed by the load balancer is 443. -->
确定集群所使用的 kubeconfig 文件或配置部分，然后修改服务器配置。
默认情况下，这个配置类似于 ```https://54.213.123.123:443```。将其替换为 Kubernetes Master 端点地址
```https://54.210.100.102:6443``` 并保存。
注意，Kubernetes Master API 的 CDK 默认使用的端口为 6443，而负载均衡器暴露的端口是 443。
<!-- 1. Start helm again! -->
1. 继续使用 helm！
```
helm install <chart> --debug
Created tunnel using local port: '36749'
SERVER: "localhost:36749"
CHART PATH: /home/ubuntu/.helm/<chart>
NAME: <chart>
...
...
```
<!-- ## Logging and monitoring -->
## 日志和监控
<!-- By default there is no log aggregation of the Kubernetes nodes, each node logs locally.
Please read over the [logging](/docs/getting-started-guides/ubuntu/logging/) page for more information. -->
默认情况下， Kubernetes 没有节点的日志聚合，每个节点都是本地保存日志。
请参阅[日志](/docs/getting-started-guides/ubuntu/logging/)文档，获取更多信息。
{{% /capture %}}
content/zh/docs/getting-started-guides/ubuntu/upgrades.md
+273
View File
@@ -0,0 +1,273 @@
---
title: 升级
content_template: templates/task
---
<!-- ---
title: Upgrades
content_template: templates/task
--- -->
{{% capture overview %}}
<!-- This page will outline how to manage and execute a Kubernetes upgrade. -->
本页将展示如何进行 Kubernetes 集群升级。
{{% /capture %}}
{{% capture prerequisites %}}
<!-- This page assumes you have a working deployed cluster. -->
本页假定你有一个 juju 部署的集群。
{{< warning >}}
<!-- You should always back up all your data before attempting an upgrade.
Don't forget to include the workload inside your cluster!
Refer to the [backup documentation](/docs/getting-started-guides/ubuntu/backups). -->
在进行升级之前，你应当备份所有的数据。
不要忘记对集群内的工作负载进行数据备份！
参见[备份文档](/docs/getting-started-guides/ubuntu/backups)。
{{< /warning >}}
{{% /capture %}}
{{% capture steps %}}
<!-- ## Patch kubernetes upgrades for example 1.9.0 -> 1.9.1 -->
## 对集群进行补丁版本升级，例如，1.9.0 -> 1.9.1
<!-- Clusters are transparently upgraded to the latest Kubernetes patch release.
To be clear, a cluster deployed using the 1.9/stable channel
will transparently receive unattended upgrades for the 1.9.X Kubernetes
releases.
The upgrade causes no disruption to the operation of the cluster and requires
no intervention from a cluster administrator.
Each patch release is evaluated by the
Canonical Kubernetes Distribution team.
Once a patch release passes internal testing and is deemed safe for upgrade,
it is packaged in snap format and pushed to the stable channel. -->
集群透明地升级到最新的 Kubernetes 补丁版本。
需要澄清的是，用 1.9/stable 通道部署的集群将会透明地、自动更新到 Kubernetes 1.9.X 最新版。
升级的过程对集群的运行没有影响，也不需要集群维护人员的干预。
每一个补丁版本都由 Canonical Kubernetes 发布小组审核评估。
一旦补丁版本通过了内部测试，认为可以安全用于集群升级，
将会被打包成 snap 格式，发布到稳定版通道上。
<!-- ## Upgrading a minor Kubernetes release for example 1.8.1 -> 1.9.0 -->
## 对集群进行次版本升级，例如，1.8.1 -> 1.9.0
<!-- The Kubernetes charms follow the Kubernetes releases. Please consult
your support plan on the upgrade frequency. Important operational considerations
and changes in behaviour will always be documented in the release notes. -->
Kubernetes charms 遵循的是 Kubernetes 发行版本。
请咨询了解 support 计划在升级频率方面的相关信息。
重要的运维考虑以及行为上的改变都会记录在发布通知里。
<!-- ### Upgrade etcd -->
### 升级 etcd
<!-- Backing up etcd requires an export and snapshot, refer to the
[backup documentation](/docs/getting-started-guides/ubuntu/backups) to create a snapshot.
After the snapshot, upgrade the etcd service with: -->
备份 etcd 需要导出和快照操作，参见[备份文档](/docs/getting-started-guides/ubuntu/backups)了解如何创建快照。
在做完快照后，用下面的命令升级 etcd 服务：
juju upgrade-charm etcd
<!-- This will handle upgrades between minor versions of etcd.
Instructions on how to upgrade from 2.x to 3.x can be found
[here](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade)
in the juju-solutions wiki. -->
命令将会负责 etcd 的次版本升级。
在 [juju 解决方案的 wiki](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade) 里
可以了解如何将 etcd 从 2.x 升级到 3.x。
<!-- ### Upgrade kubeapi-load-balancer -->
### 升级 kubeapi-load-balancer
<!-- The Kubernetes Charms are generally all updated and released at the same time. A core part of a cluster on Ubuntu is the kubeapi-load-balancer component. Incorrect or missing changes there can have an effect on API availability and access controls. To ensure API service continuity for the master and workers when they are updated, this upgrade needs to precede them. -->
Kubernetes Charms 通常是同时更新、发布。
Ubuntu 集群的核心部分是 kubeapi-load-balancer 组件。
错误或遗失修改可能会导致 API 可用性和访问控制方面的问题。
为了保证 API 服务在集群升级期间还能为主节点和工作节点服务，也需要对它们进行升级。
<!-- To upgrade the charm run: -->
升级命令：
juju upgrade-charm kubeapi-load-balancer
<!-- ### Upgrade Kubernetes -->
### 升级 Kubernetes
<!-- The Kubernetes Charms use snap channels to drive payloads.
The channels are defined by `X.Y/channel` where `X.Y` is the `major.minor` release
of Kubernetes (for example 1.9) and `channel` is one of the four following channels: -->
Kubernetes Charms 使用 snap 通道来驱动负荷。
这些通道定义的格式为 `X.Y/channel`，其中，`X.Y` 是 Kubernetes `主.次` 发行版（例如，1.9）
而 `channel` 的取值范围如下：
<!-- | Channel name | Description |
| ------------------- | ------------ |
| stable | The latest stable released patch version of Kubernetes |
| candidate | Release candidate releases of Kubernetes |
| beta | Latest alpha or beta of Kubernetes for that minor release |
| edge | Nightly builds of that minor release of Kubernetes | -->
| 通道名 | 描述 |
| ------------------- | ------------ |
| stable | Kubernetes 的最新稳定发行版 |
| candidate | Kubernetes 的发行候选版 |
| beta | Kubernetes 次发行版的最新 alpha 或 beta 版 |
| edge | Kubernetes 次发行版的每日构建版 |
<!-- If a release isn't available, the next highest channel is used.
For example, 1.9/beta will load `/candidate` or `/stable` depending on availability of release.
Development versions of Kubernetes are available in the edge channel for each minor release.
There is no guarantee that edge snaps will work with the current charms. -->
如果发行版还不可用，就会使用下一个最高通道的版本。
例如，1.9/beta 会根据发行版的可用性加载 `/candidate` 或 `/stable` 版本。
Kubernetes 的开发版本会根据每个次版本，发布到 edge 通道上。
但不会保证 edge snap 能够和当前的 charms 一起工作。
<!-- ### Master Upgrades -->
### 主节点升级
<!-- First you need to upgrade the masters: -->
首先需要对主节点进行升级：
juju upgrade-charm kubernetes-master
{{< note >}}
<!-- Always upgrade the masters before the workers. -->
永远在工作节点升级之前，升级主节点。
{{< /note >}}
<!-- Once the latest charm is deployed, the channel for Kubernetes can be selected by issuing the following: -->
在部署完最新的 charm 之后，可以通过下面的命令行来选择通道：
juju config kubernetes-master channel=1.x/stable
<!-- Where `x` is the minor version of Kubernetes. For example, `1.9/stable`. See above for Channel definitions.
Once you've configured kubernetes-master with the appropriate channel, run the upgrade action on each master: -->
其中，`x` 是 Kubernetes 的次版本号。例如，`1.9/stable`。
参阅前面对通道的定义。
将 kubernetes-master 配置到合适的通道上后，
再在每个主节点上运行下面的升级命令：
juju run-action kubernetes-master/0 upgrade
juju run-action kubernetes-master/1 upgrade
...
<!-- ### Worker Upgrades -->
### 工作节点升级
<!-- Two methods of upgrading workers are supported.
[Blue/Green Deployment](http://martinfowler.com/bliki/BlueGreenDeployment.html)
and upgrade-in-place. Both methods are provided for operational flexibility and both
are supported and tested. Blue/Green will require more hardware up front than in-place,
but is a safer upgrade route. -->
现有所支持的升级工作节点的方法有两种，[蓝/绿部署](http://martinfowler.com/bliki/BlueGreenDeployment.html)
和就地升级。提供两种方法可以带来运维上的灵活性，而这两种方法也都被支持和测试。
相比于就地升级，蓝/绿部署需要更多的硬件资源，但也更为安全可靠。
<!-- #### Blue/green worker upgrade -->
#### 蓝/绿工作节点升级
<!-- Given a deployment where the workers are named kubernetes-alpha. -->
假定一个部署里面所有的工作节点都叫 kubernetes-alpha。
<!-- Deploy new workers: -->
部署新的工作节点：
juju deploy kubernetes-alpha
<!-- Pause the old workers so your workload migrates: -->
暂停旧的工作节点，然后迁移工作负载：
juju run-action kubernetes-alpha/# pause
<!-- Verify old workloads have migrated with: -->
验证所迁移的工作负载：
kubectl get pod -o wide
<!-- Tear down old workers with: -->
销毁就有的工作节点：
juju remove-application kubernetes-alpha
<!-- #### In place worker upgrade -->
#### 就地工作节点升级
juju upgrade-charm kubernetes-worker
juju config kubernetes-worker channel=1.x/stable
<!-- Where `x` is the minor version of Kubernetes. For example, `1.9/stable`.
See above for Channel definitions. Once you've configured kubernetes-worker with the appropriate channel,
run the upgrade action on each worker: -->
其中，`x` 是 Kubernetes 的次版本号。例如，`1.9/stable`。
参阅前面对通道的定义。将 kubernetes-worker 配置到合适的通道上后，
再在每个工作节点上运行下面的升级命令：
juju run-action kubernetes-worker/0 upgrade
juju run-action kubernetes-worker/1 upgrade
...
<!-- ### Verify upgrade -->
### 验证升级
<!-- `kubectl version` should return the newer version. -->
`kubectl version` 将会返回新的版本号。
<!-- It is recommended to rerun a [cluster validation](/docs/getting-started-guides/ubuntu/validation)
to ensure that the cluster upgrade has successfully completed. -->
建议重新运行[集群验证](/docs/getting-started-guides/ubuntu/validation)确认集群升级成功完成。
<!-- ### Upgrade Flannel -->
### 升级 Flannel
<!-- Upgrading flannel can be done at any time, it is independent of Kubernetes upgrades.
Be advised that networking is interrupted during the upgrade. You can initiate a flannel upgrade with: -->
可以在任何时候升级 flannel，它的升级可以和 Kubernetes 升级分开进行。
需要注意的是，在升级过程中，网络会受到影响。
可以通过下面的命令行发起升级：
juju upgrade-charm flannel
<!-- ### Upgrade easyrsa -->
### 升级 easyrsa
<!-- Upgrading easyrsa can be done at any time, it is independent of Kubernetes upgrades.
Upgrading easyrsa should result in zero downtime as it is not a running service: -->
可以在任何时候升级 easyrsa，它的升级可以和 Kubernetes 升级分开进行。
升级 easyrsa 会有停机时间，因为不是运行服务：
juju upgrade-charm easyrsa
{{% /capture %}}
content/zh/docs/getting-started-guides/windows/OVN_OVS_Windows_Installer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

content/zh/docs/getting-started-guides/windows/UpstreamRouting.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 87 KiB

content/zh/docs/getting-started-guides/windows/_index.md
+892
View File
@@ -0,0 +1,892 @@
---
title: 在 Kubernetes 中使用 Windows Server 容器
toc_hide: true
---
<!--
title: Using Windows Server Containers in Kubernetes
-->
{{< note >}}
**Note:** 这些说明最近基于 Windows Server 平台增强和 Kubernetes v1.9 版本进行了更新
{{< /note >}}
<!--
**Note:** These instructions were recently updated based on Windows Server platform enhancements and the Kubernetes v1.9 release
-->
Kubernetes 1.5 版本基于 Windows Server 2016 操作系统引入了对 Windows Server 容器
的 Alpha 支持。随着 Windows Server 版本 1709 的发布和使用 Kubernetes v1.9，用户可以使用许多不同的
网络拓扑和 CNI 插件在本地或私有/公共云中部署 Kubernetes 集群。Kubernetes 上的 Windows Server 容器的一些
关键功能改进包括：
<!--
Kubernetes version 1.5 introduced Alpha support for Windows Server
Containers based on the Windows Server 2016 operating system. With the
release of Windows Server version 1709 and using Kubernetes v1.9 users
are able to deploy a Kubernetes cluster either on-premises or in a
private/public cloud using a number of different network topologies
and CNI plugins. Some key feature improvements for Windows Server
Containers on Kubernetes include:
-->
- 改进了对 pod 的支持!具有多个 Windows Server 容器(共享内核)的共享网络命名空间(隔离专区)
<!--
- Improved support for pods! Shared network namespace (compartment) with multiple Windows Server containers (shared kernel)
-->
- 通过每个 pod 使用单个网络端点降低网络复杂性
<!--
- Reduced network complexity by using a single network endpoint per pod
-->
- 使用虚拟过滤平台 (VFP)Hyper-v 交换机扩展(类似于 Linux iptables) 的基于内核的负载均衡
<!--
- Kernel-Based load-balancing using the Virtual Filtering Platform (VFP) Hyper-v Switch Extension (analogous to Linux iptables)
-->
- 容器运行时接口(CRI) pod 和 节点级统计
<!--
- Container Runtime Interface (CRI) pod and node level statistics
-->
- 支持 kubeadm 命令将 Windows Server 节点添加到 Kubernetes 环境中
<!--
- Support for kubeadm commands to add Windows Server nodes to a Kubernetes environment
-->
Kubernetes 控制平面(API服务器，调度程序，控制器管理器等)继续在 Linux 上运行，而 kubelet 和 kube-proxy 可以在 Windows Server 2016 或更高版本上运行
<!--
The Kubernetes control plane (API Server, Scheduler, Controller Manager, etc) continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server 2016 or later
-->
{{< note >}}
**Note:** Kubernetes 上的 Windows Server 容器是 Kubernetes v1.9 中的一个 Beta 特性
{{< /note >}}
<!--
**Note:** Windows Server Containers on Kubernetes is a Beta feature in Kubernetes v1.9
-->
## 获取 Windows 二进制文件
<!--
## Get Windows Binaries
-->
我们建议使用可以在 [https://github.com/kubernetes/kubernetes/releases/latest](https://github.com/kubernetes/kubernetes/releases/latest) 上找到的发布的二进制文件。在更新日志下您可以找到 Windows-amd64 的节点二进制文件链接，其中包括 kubeadm，kubectl，kubelet 和 kube-proxy。
<!--
We recommend using the release binaries that can be found at [https://github.com/kubernetes/kubernetes/releases/latest](https://github.com/kubernetes/kubernetes/releases/latest). Under the CHANGELOG you can find the Node Binaries link for Windows-amd64, which will include kubeadm, kubectl, kubelet and kube-proxy.
-->
如果您希望自己构建代码，请参阅[此处](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/compiling-kubernetes-binaries)的详细构建说明。
<!--
If you wish to build the code yourself, please refer to detailed build instructions [here](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/compiling-kubernetes-binaries).
-->
## 环境准备
<!--
## Prerequisites
-->
在 Kubernetes 1.9 或更高版本中，使用以下内容支持 Kubernetes 的 Windows Server 容器：
<!--
In Kubernetes version 1.9 or later, Windows Server Containers for Kubernetes are supported using the following:
-->
1. Kubernetes 控制平面在现有的 Linux 基础架构(1.9版本或更高版本)上运行。
<!--
1. Kubernetes control plane running on existing Linux infrastructure (version 1.9 or later).
-->
2. Linux 的节点上的 Kubenet 网络插件设置。
<!--
2. Kubenet network plugin setup on the Linux nodes.
-->
3. Windows Server 2016 RTM 或更高版本，Windows Server 版本 1709 或更高版本是首选; 它解锁了共享网络命名空间等关键功能。
<!--
3. Windows Server 2016 RTM or later. Windows Server version 1709 or later is preferred; it unlocks key capabilities like shared network namespace.
-->
4. 适用于 Windows Server 节点的 Docker 版本 17.06.1-ee-2 或更高版本(Linux 节点和 Kubernetes 控制平面可以运行任何 Kubernetes 支持的 Docker 版本)。
<!--
4. Docker Version 17.06.1-ee-2 or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version).
-->
## 网络
<!--
## Networking
-->
Windows 上有几种支持 Kubernetes v1.9 的网络配置，包括使用第三方网络插件的第三层路由和覆盖拓扑。
<!--
There are several supported network configurations with Kubernetes v1.9 on Windows, including both Layer-3 routed and overlay topologies using third-party network plugins.
-->
1. [上游 L3 路由](#upstream-l3-routing-topology) - 在上游 ToR 中配置的 IP 路由
<!--
1. [Upstream L3 Routing](#upstream-l3-routing-topology) - IP routes configured in upstream ToR
-->
2. [主机网关](#host-gateway-topology) - 在每台主机上配置的 IP 路由
<!--
2. [Host-Gateway](#host-gateway-topology) - IP routes configured on each host
-->
3. [使用覆盖式 Open vSwitch(OVS) 和开放虚拟网络(OVN)](#using-ovn-with-ovs) - 覆盖网络(支持STT和Geneve隧道类型)
<!--
3. [Open vSwitch (OVS) & Open Virtual Network (OVN) with Overlay](#using-ovn-with-ovs) - overlay networks (supports STT and Geneve tunneling types)
-->
4. [未来 - 评审中] 覆盖 - 使用 Flannel 的 VXLAN 或者 IP-in-IP 封装
<!--
4. [Future - In Review] Overlay - VXLAN or IP-in-IP encapsulation using Flannel
-->
5. [未来] 使用 BGP(Calico) 的第三层路由
<!--
5. [Future] Layer-3 Routing with BGP (Calico)
-->
选择要部署的网络配置和拓扑取决于物理网络拓扑和用户配置路由的能力，封装的性能问题以及与第三方网络插件集成的要求。
<!--
The selection of which network configuration and topology to deploy depends on the physical network topology and a user's ability to configure routes, performance concerns with encapsulation, and requirement to integrate with third-party network plugins.
-->
### 未来的 CNI 插件
另外两个 CNI 插件 [win-l2bridge(主机网关)和 win-overlay(vxlan)] 正在进行 PR 审核。这两个 CNI 插件准备好后，既可以直接使用，也可以与 Flannel 一起使用。
<!--
### Future CNI Plugins
An additional two CNI plugins [win-l2bridge (host-gateway) and win-overlay (vxlan)] are in [PR review](https://github.com/containernetworking/plugins/pull/85). These two CNI plugins, when ready, can either be used directly or with Flannel.
-->
### Linux
Linux 上已经使用桥接接口支持上述网络方法，桥接接口基本上创建了节点本地的专用网络。与 Windows 端类似，必须创建到所有其他 pod CIDR 的路由才能通过"公共" NIC 发送数据包。
<!--
### Linux
The above networking approaches are already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC.
-->
### Windows
Windows 支持 CNI 网络模型，并使用插件与 Windows 主机网络服务(HNS)连接以配置主机网络和策略。在撰写本文时，Microsoft 唯一公开提供的 CNI 插件是从私人存储库构建的，可在此处获得[wincni.exe](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/cni/wincni.exe)。它使用由管理员在每个节点上使用 HNS PowerShell 命令通过 Windows 主机网络服务(HNS)创建的 l2bridge 网络，如下面的 [Windows 主机设置](#windows-host-setup)部分所述。未来CNI插件的源代码将公开发布
<!--
### Windows
Windows supports the CNI network model and uses plugins to interface with the Windows Host Networking Service (HNS) to configure host networking and policy. At the time of this writing, the only publicly available CNI plugin from Microsoft is built from a private repo and available here [wincni.exe](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/cni/wincni.exe). It uses an l2bridge network created through the Windows Host Networking Service (HNS) by an administrator using HNS PowerShell commands on each node as documented in the [Windows Host Setup](#windows-host-setup) section below. Source code for the future CNI plugins will be made available publicly.
-->
#### 上游 L3 路由拓扑
在这种拓扑结构中，通过在机架 (ToR)交换机/路由器的上游顶部配置静态 IP 路由，使用L3路由实现网络连接。每个群集节点都通过主机 IP 连接到管理网络。此外，每个节点使用本地'l2bridge'网络，并分配了一个 pod CIDR。给定工作节点上的所有 pod 将连接到 pod CIDR 子网('l2bridge'网络)。为了在不同节点上运行的 pod 之间实现网络通信，上游路由器配置了静态路由 pod CIDR 前缀 => 主机 IP。
<!--
#### Upstream L3 Routing Topology
In this topology, networking is achieved using L3 routing with static IP routes configured in an upstream Top of Rack (ToR) switch/router. Each cluster node is connected to the management network with a host IP. Additionally, each node uses a local 'l2bridge' network with a pod CIDR assigned. All pods on a given worker node will be connected to the pod CIDR subnet ('l2bridge' network). In order to enable network communication between pods running on different nodes, the upstream router has static routes configured with pod CIDR prefix => Host IP.
-->
以下示例图说明了使用上游 L3 路由设置的 Kubernetes 的 Windows Server 网络设置：
<!--
The following example diagram illustrates the Windows Server networking setup for Kubernetes using Upstream L3 Routing Setup:
-->
![K8s 集群使用 ToR 的 L3 路由](UpstreamRouting.png)
<!--
![K8s Cluster using L3 Routing with ToR](UpstreamRouting.png)
-->
#### 主机网关拓扑
这种拓扑与上游 L3 路由拓扑相似，惟一的区别是静态 IP 路由是直接在每个集群节点上配置的，而不是在上游 ToR 中配置的。每个节点使用本地的 'l2bridge' 网络，并像以前一样分配 pod CIDR，并为分配给远程集群节点的所有其他 pod CIDR 子网提供路由表条目。
<!--
#### Host-Gateway Topology
This topology is similar to the Upstream L3 Routing topology with the only difference being that static IP routes are configured directly on each cluster node and not in the upstream ToR. Each node uses a local 'l2bridge' network with a pod CIDR assigned as before and has routing table entries for all other pod CIDR subnets assigned to the remote cluster nodes.
-->
#### OVN 和 OVS 一起使用
下图概述了组件之间的体系结构和交互：
<!--
#### Using OVN with OVS
The following diagram gives a general overview of the architecture and interaction between components:
-->
![覆盖式使用 OVN 控制器和 OVS 开关扩展](ovn_kubernetes.png)
<!--
![Overlay using OVN controller and OVS Switch Extension](ovn_kubernetes.png)
-->
(上图来自 [https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram](https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram))
<!--
(The above image is from [https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram](https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram))
-->
由于它的体系结构，OVN 有一个中央组件，它将您的网络意图存储在数据库中。其他组件如 kube-apiserver、kube-controller-manager、kube-scheduler 等也可以部署在该中心节点上。
<!--
Due to its architecture, OVN has a central component which stores your networking intent in a database. Other components i.e. kube-apiserver, kube-controller-manager, kube-scheduler etc. can be deployed on that central node as well.
-->
## 在 Kubernetes 上设置 Windows Server 容器
要在 Kubernetes 上运行 Windows Server 容器，您需要为 Windows 设置主机和 Kubernetes 节点组件。根据您的网络拓扑，可能需要为不同节点上的 pod 通信设置路由。
<!--
## Setting up Windows Server Containers on Kubernetes
To run Windows Server Containers on Kubernetes, you'll need to set up both your host machines and the Kubernetes node components for Windows. Depending on your network topology, routes may need to be set up for pod communication on different nodes.
-->
### 主机设置
<!--
### Host Setup
-->
#### 1. 上游 L3 路由拓扑和 2. 主机网关拓扑
<!--
#### For 1. Upstream L3 Routing Topology and 2. Host-Gateway Topology
-->
##### Linux 主机设置
<!--
##### Linux Host Setup
-->
1. Linux 主机应该根据它们各自的发行版文档和您将使用的 Kubernetes 版本的要求进行设置。
<!--
1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using.
-->
2. 使用步骤[此处](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/creating-a-linux-master.md)配置Linux主节点
<!--
2. Configure Linux Master node using steps [here](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/creating-a-linux-master.md)
-->
3. [可选]安装CNI网络插件。
<!--
3. [Optional] CNI network plugin installed.
-->
##### Windows 主机设置
<!--
##### Windows Host Setup
-->
1. 运行所需 Windows Server 和 Docker 版本的 Windows Server 容器主机。请按照此帮助主题概述的安装说明进行操作：https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server。
<!--
1. Windows Server container host running the required Windows Server and Docker versions. Follow the setup instructions outlined by this help topic: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server.
-->
2. 2. [获取 Windows 二进制文件](#get-windows-binaries) kubelet.exe, kube-proxy.exe, and kubectl.exe 使用说明
<!--
2. [Get Windows Binaries](#get-windows-binaries) kubelet.exe, kube-proxy.exe, and kubectl.exe using instructions
-->
3. 使用 X.509 密钥从 Linux 主节点复制节点规范文件(kube config)
<!--
3. Copy Node spec file (kube config) from Linux master node with X.509 keys
-->
4. 创建 HNS 网络，确保正确的 CNI 网络配置，并使用此脚本 [start-kubelet.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubelet.ps1) 启动 kubelet.exe
<!--
4. Create the HNS Network, ensure the correct CNI network config, and start kubelet.exe using this script [start-kubelet.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubelet.ps1)
-->
5. 使用此脚本启动 [start-kubeproxy.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubeproxy.ps1) 启动 kube-proxy
<!--
Start kube-proxy using this script [start-kubeproxy.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubeproxy.ps1)
-->
6. [仅限 #2 主机网关模式]使用此脚本 [AddRoutes.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/AddRoutes.ps1) 在Windows主机上添加静态路由
<!--
6. [Only required for #2 Host-Gateway mode] Add static routes on Windows host using this script [AddRoutes.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/AddRoutes.ps1)
-->
更详细的说明可以在[这里](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows.md)找到。
<!--
More detailed instructions can be found [here](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows.md).
-->
**Windows CNI 配置示例**
<!--
**Windows CNI Config Example**
-->
Windows CNI 插件基于 wincni.exe 的，配置文件，是基于上面显示的 ToR 示例图，指定了应用于 Windows node-1 的配置。特别有趣的是 Windows node-1 pod CIDR(10.10.187.64/26) 和 cbr0(10.10.187.66)的关联网关。异常列表指定服务 CIDR(11.0.0.0/8)，集群 CIDR(10.10.0.0/16) 和管理(或主机) CIDR（10.127.132.128/25）。
<!--
Today, Windows CNI plugin is based on wincni.exe code with the following example, configuration file. This is based on the ToR example diagram shown above, specifying the configuration to apply to Windows node-1. Of special interest is Windows node-1 pod CIDR (10.10.187.64/26) and the associated gateway of cbr0 (10.10.187.66). The exception list is specifying the Service CIDR (11.0.0.0/8), Cluster CIDR (10.10.0.0/16), and Management (or Host) CIDR (10.127.132.128/25).
-->
注意：此文件假设用户以前使用 <Verb>-HNSNetworkcmdlet 在每个 Windows 节点上创建了'l2bridge' 主机网络，如上面链接的 start-kubelet.ps1 和 start-kubeproxy.ps1 脚本中所示
<!--
Note: this file assumes that a user previous created 'l2bridge' host networks on each Windows node using `<Verb>-HNSNetwork` cmdlets as shown in the `start-kubelet.ps1` and `start-kubeproxy.ps1` scripts linked above
-->
```json
{
"cniVersion": "0.2.0",
"name": "l2bridge",
"type": "wincni.exe",
"master": "Ethernet",
"ipam": {
"environment": "azure",
"subnet": "10.10.187.64/26",
"routes": [{
"GW": "10.10.187.66"
}]
},
"dns": {
"Nameservers": [
"11.0.0.10"
]
},
"AdditionalArgs": [{
"Name": "EndpointPolicy",
"Value": {
"Type": "OutBoundNAT",
"ExceptionList": [
"11.0.0.0/8",
"10.10.0.0/16",
"10.127.132.128/25"
]
}
},
{
"Name": "EndpointPolicy",
"Value": {
"Type": "ROUTE",
"DestinationPrefix": "11.0.0.0/8",
"NeedEncap": true
}
},
{
"Name": "EndpointPolicy",
"Value": {
"Type": "ROUTE",
"DestinationPrefix": "10.127.132.213/32",
"NeedEncap": true
}
}
]
}
```
#### 3.使用覆盖方式打开 vSwitch(OVS) 和开放虚拟网络(OVN)
<!--
#### For 3. Open vSwitch (OVS) & Open Virtual Network (OVN) with Overlay
-->
{{< note >}}
**Note:** 通过 Ansible 剧本的全自动设置是[可用的](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)。
{{< /note >}}
<!--
**Note:** Fully automated setup via Ansible playbooks is [available](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib).
-->
对于手动设置，请继续以下步骤。
<!--
For manual setup, continue the following steps.
-->
##### Linux 主机设置
<!--
##### Linux Host Setup
-->
设置中心节点和所需组件超出了本文档的范围。您可以阅读[这些说明](https://github.com/openvswitch/ovn-kubernetes#k8s-master-node-initialization)。
<!--
Setting up the central node and the components needed is out of scope of this document. You can read [these instructions](https://github.com/openvswitch/ovn-kubernetes#k8s-master-node-initialization) for that.
-->
添加 Linux minion 也超出了范围，你可以在这里阅读：[Linux minion](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations)。
<!--
Adding a Linux minion is also out of scope and you can read it here: [Linux minion](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations).
-->
##### windows 主机设置
<!--
##### Windows Host Setup
-->
添加 Windows minion 需要您安装 OVS 和 OVN 二进制文件。运行所需 Windows Server 和 Docker 版本的 Windows Server 容器主机。请按照[此帮助主题](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server)概述的设置说明进行操作。从 Windows Server 2016 RTM 开始支持此类部署。
<!--
Adding a Windows minion requires you to install OVS and OVN binaries. Windows Server container host running the required Windows Server and Docker versions. Follow the setup instructions outlined by [this help topic](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server). This type of deployment is supported starting with Windows Server 2016 RTM.
-->
编译 OVS 并生成安装程序不在本文中讨论。请访问[此链接](http://docs.openvswitch.org/en/latest/intro/install/windows/#open-vswitch-on-windows)。对于预构建的认证安装程序，请访问[此链接](https://cloudbase.it/openvswitch/#download)并下载最新版本
<!--
Compiling OVS and generating the installer will not be treated in this document. For a step by step instruction please visit [this link](http://docs.openvswitch.org/en/latest/intro/install/windows/#open-vswitch-on-windows).
For a prebuilt certified installer please visit [this link](https://cloudbase.it/openvswitch/#download) and download the latest version of it.
-->
以下指南使用预构建的认证安装程序。
<!--
The following guide uses the prebuilt certified installer.
-->
安装 OVS 既可以通过 GUI 对话框完成，也可以在无人看管的情况下完成。将 Windows 主机添加到您的设置需要您拥有`OVN主机`和默认安装特性。下面是需要安装的对话框图像：
<!--
Installing OVS can be done either via the GUI dialogs or unattended. Adding a Windows host to your setup requires you to have `OVN Host` together with the default installation features. Below is the dialog image on what needs to be installed:
-->
![Windows 安装 OVN OVS](OVN_OVS_Windows_Installer.png)
<!--
![OVN OVS Windows Installer](OVN_OVS_Windows_Installer.png)
-->
对于无人看管情况下的安装，请使用以下命令：
<!--
For an unattended installation please use the following command:
-->
```
cmd /c 'msiexec /i openvswitch.msi ADDLOCAL="OpenvSwitchCLI,OpenvSwitchDriver,OVNHost" /qn'
```
安装程序设置新的环境变量。请使用命令打开一个新的 shell 或注销/登录，以确保刷新了环境变量。
<!--
The installer propagates new environment variables. Please open a new command shell or logoff/logon to ensure the environment variables are refreshed.
-->
对于叠加，Windows 上的 OVS 需要透明的 docker 网络才能正常运行。请使用以下命令创建一个透明的 docker 网络，OVS 将使用该网络。powershell：
<!--
For overlay, OVS on Windows requires a transparent docker network to function properly. Please use the following to create a transparent docker network which will be used by OVS. From powershell:
-->
```
docker network create -d transparent --gateway $GATEWAY_IP --subnet $SUBNET `
-o com.docker.network.windowsshim.interface="$INTERFACE_ALIAS" external
```
$SUBNET 是用于产生 pods 的 minion 子网(将由 kubernetes 使用的子网)，$GATEWAY_IP 是 $SUBNET 的第一个 IP，$INTERFACE_ALIAS 是用于创建覆盖隧道的接口(必须与 OVN 主机的 rests 连接)。
例：
<!--
Where $SUBNET is the minion subnet which will be used to spawn pods on (the one which will be used by kubernetes), $GATEWAY_IP is the first IP of the $SUBNET and $INTERFACE_ALIAS is the interface used for creating the overlay tunnels (must have connectivity with the rests of the OVN hosts).
Example:
-->
```
docker network create -d transparent --gateway 10.0.1.1 --subnet 10.0.1.0/24 `
-o com.docker.network.windowsshim.interface="Ethernet0" external
```
创建 docker 网络后，请从 powershell 运行下面的命令。(创建OVS桥接器，在桥接器下添加接口，并启用OVS转发交换机扩展名)
<!--
After creating the docker network please run the next commands from powershell. (creates an OVS bridge, adds the interface under the bridge and enables the OVS forwarding switch extension)
-->
```
$a = Get-NetAdapter | where Name -Match HNSTransparent
Rename-NetAdapter $a[0].Name -NewName HNSTransparent
Stop-Service ovs-vswitchd -force; Disable-VMSwitchExtension "Cloudbase Open vSwitch Extension";
ovs-vsctl --no-wait del-br br-ex
ovs-vsctl --no-wait --may-exist add-br br-ex
ovs-vsctl --no-wait add-port br-ex HNSTransparent -- set interface HNSTransparent type=internal
ovs-vsctl --no-wait add-port br-ex $INTERFACE_ALIAS
Enable-VMSwitchExtension "Cloudbase Open vSwitch Extension"; sleep 2; Restart-Service ovs-vswitchd
```
除此之外，Windows主机的设置与Linux主机相同。从[这里](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations)开始执行以下步骤。
<!--
Besides of the above, setting up a Windows host is the same as the Linux host. Follow the steps from [here](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations).
-->
**Windows CNI 设置**
<!--
**Windows CNI Setup**
-->
现在，Windows OVN&OVS CNI 插件是基于 ovn_cni.exe 可以从[此处](https://cloudbase.it/downloads/ovn_cni.exe)下载。CNI 配置文件示例如下:
<!--
Today, Windows OVN&OVS CNI plugin is based on ovn_cni.exe which can be downloaded from [here](https://cloudbase.it/downloads/ovn_cni.exe). A sample of CNI config file is the following:
-->
```
{
"name": "net",
"type": "ovn_cni.exe",
"bridge": "br-int",
"isGateway": "true",
"ipMasq": "false",
"ipam": {
"type": "host-local",
"subnet": "$SUBNET"
}
}
```
$SUBNET 是上一个 ```docker network create``` 命令中使用的子网。
<!--
Where $SUBNET is the subnet that was used in the previous ```docker network create``` command.
-->
有关谷歌云平台(GCP)，即谷歌计算引擎(GCE)的完整指南，请访问[这里](https://github.com/apprenda/kubernetes-ovn-heterogeneous-cluster#heterogeneous-kubernetes-cluster-on-top-of-ovn)。
<!--
For a complete guide on Google Cloud Platform (GCP), namely Google Compute Engine (GCE) visit [this](https://github.com/apprenda/kubernetes-ovn-heterogeneous-cluster#heterogeneous-kubernetes-cluster-on-top-of-ovn).
-->
有关亚马逊网络服务(AWS)，请访问[这里](https://github.com/justeat/kubernetes-windows-aws-ovs#kubernetes-on-windows-in-aws-using-ovn)。
<!--
For a complete guide on Amazon Web Services (AWS) visit [this](https://github.com/justeat/kubernetes-windows-aws-ovs#kubernetes-on-windows-in-aws-using-ovn).
-->
## 启动群集
要启动集群，您需要启动基于 Linux 的 Kubernetes 控制平面和基于 Windows Server 的 Kubernetes 节点组件(kubelet 和 kube-proxy)。对于 OVS 和 OVN，仅需要 kubelet。
<!--
## Starting the Cluster
To start your cluster, you'll need to start both the Linux-based Kubernetes control plane, and the Windows Server-based Kubernetes node components (kubelet and kube-proxy). For the OVS & OVN only the kubelet is required.
-->
## 启动基于 Linux-based 的控制平面
使用您喜欢的方法在 Linux 上启动 Kubernetes 集群。请注意，集群 CIDR 可能需要更新。
<!--
## Starting the Linux-based Control Plane
Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated.
-->
## 支持kubeadm加入
<!--
## Support for kubeadm join
-->
如果您的群集是由[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)，创建的
使用上面列出的方法之一正确地设置网络(网络是在 kubeadm 之外设置的)，您可以使用 kubeadm 向集群添加 Windows 节点。在较高的级别上，首先必须使用 kubeadm(Linux) 初始化主节点，然后设置基于 CNI 的网络(在 kubeadm 之外)，最后开始将 Windows 或 Linux 工作节点连接到集群。如需其他文件和参考资料，请访问上文的 kubeadm 链接。
<!--
If your cluster has been created by [kubeadm](/docs/setup/independent/create-cluster-kubeadm/),
and your networking is setup correctly using one of the methods listed above (networking is setup outside of kubeadm), you can use kubeadm to add a Windows node to your cluster. At a high level, you first have to initialize the master with kubeadm (Linux), then set up the CNI based networking (outside of kubeadm), and finally start joining Windows or Linux worker nodes to the cluster. For additional documentation and reference material, visit the kubeadm link above.
-->
kubeadm 二进制文件可以在 [Kubernetes 版本](https://github.com/kubernetes/kubernetes/release)的节点二进制文件归档中找到。添加 Windows 节点与添加 Linux 节点没有任何不同：
<!--
The kubeadm binary can be found at [Kubernetes Releases](https://github.com/kubernetes/kubernetes/releases), inside the node binaries archive. Adding a Windows node is not any different than adding a Linux node:
-->
`kubeadm.exe join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>`
有关更多详细信息请参阅[加入您的节点](/docs/setup/independent/create-cluster-kubeadm/#joining-your-nodes)。
<!--
See [joining-your-nodes](/docs/setup/independent/create-cluster-kubeadm/#joining-your-nodes) for more details.
-->
## 支持的功能
<!--
## Supported Features
-->
下面列出的示例假设在 Windows Server 1709 上运行 Windows 节点。如果您正在运行 Windows Server 2016，示例将需要更新镜像以指定 `image: microsoft/windowsservercore:ltsc2016`。这是因为在使用进程隔离时，需要容器镜像匹配主机操作系统版本。不指定标记将隐式地使用 `:latest` 标记，这可能导致令人惊讶的行为。有关 Windows Service Core 镜像标记的更多信息，请与[https://hub.docker.com/r/microsoft/windowsservercore/](https://hub.docker.com/r/microsoft/windowsservercore/)联系。
<!--
The examples listed below assume running Windows nodes on Windows Server 1709. If you are running Windows Server 2016, the examples will need the image updated to specify `image: microsoft/windowsservercore:ltsc2016`. This is due to the requirement for container images to match the host operating system version when using process isolation. Not specifying a tag will implicitly use the `:latest` tag which can lead to surprising behaviors. Please consult with [https://hub.docker.com/r/microsoft/windowsservercore/](https://hub.docker.com/r/microsoft/windowsservercore/) for additional information on Windows Server Core image tagging.
-->
### 在 Windows 上调度 Pod
由于您的群集同时具有 Linux 和 Windows 节点，因此必须明确设置 nodeSelector 约束以便能够将 pod 安排到 Windows 节点。必须将 nodeSelector 的标签 beta.kubernetes.io/os 设置为值 windows; 请参阅以下示例：
<!--
### Scheduling Pods on Windows
Because your cluster has both Linux and Windows nodes, you must explicitly set the `nodeSelector` constraint to be able to schedule pods to Windows nodes. You must set nodeSelector with the label `beta.kubernetes.io/os` to the value `windows`; see the following example:
-->
{{< codenew file="windows/simple-pod.yaml" >}}
{{< note >}}
**Note:** 本例假设您在 Windows Server 1709 上运行，因此使用镜像标记来支持它。如果使用不同的版本，则需要更新标记。例如，如果在 Windows Server 2016 上，更新为使用 `"image": "microsoft/iis"`，默认为该操作系统版本。
{{< /note >}}
<!--
**Note:** This example assumes you are running on Windows Server 1709, so uses the image tag to support that. If you are on a different version, you will need to update the tag. For example, if on Windows Server 2016, update to use `"image": "microsoft/iis"` which will default to that OS version.
-->
### Secrets 和 ConfigMaps
secret和configmap可以在Windows Service 容器中使用，但是必须作为环境变量使用。有关更多细节，请参见下面的限制部分。
<!--
### Secrets and ConfigMaps
Secrets and ConfigMaps can be utilized in Windows Server Containers, but must be used as environment variables. See limitations section below for additional details.
-->
**例子：**
<!--
**Examples:**
-->
Windows pod 与 secrets 映射到环境变量
<!--
Windows pod with secrets mapped to environment variables
-->
{{< codenew file="windows/secret-pod.yaml" >}}
具有 configMap 值的 Windows Pod 映射到环境变量
<!--
Windows Pod with configMap values mapped to environment variables
-->
{{< codenew file="windows/configmap-pod.yaml" >}}
### 卷
一些受支持的卷挂载可以是本地卷，emptyDir 卷和主机路径卷。需要记住的一点是，路径必须转义，或者使用前斜杠，例如：`mountPath: "C:\\etc\\foo"` or `mountPath: "C:/etc/foo"`。
<!--
### Volumes
Some supported Volume Mounts are local, emptyDir, hostPath. One thing to remember is that paths must either be escaped, or use forward slashes, for example `mountPath: "C:\\etc\\foo"` or `mountPath: "C:/etc/foo"`.
-->
对于受支持的卷类型，支持持久卷的声明。
<!--
Persistent Volume Claims are supported for supported volume types.
-->
**例子：**
<!--
**Examples:**
-->
带有主机路径卷的 Windows pod
<!--
Windows pod with a hostPath volume
-->
{{< codenew file="windows/hostpath-volume-pod.yaml" >}}
具有多个 emptyDir 卷的 Windows pod
<!--
Windows pod with multiple emptyDir volumes
-->
{{< codenew file="windows/emptydir-pod.yaml" >}}
### 守护线程集
<!--
### DaemonSets
-->
支持守护线程集
<!--
DaemonSets are supported
-->
{{< codenew file="windows/daemonset.yaml" >}}
### 指标
<!--
### Metrics
-->
Windows Stats 使用混合模型：pod 和容器级别的统计数据来自 CRI(通过 dockershim)，而节点级别的统计数据来自“winstats”包，该包使用特定于 Windows 的 perf 计数器导出 cadvisor 之类的数据结构。
<!--
Windows Stats use a hybrid model: pod and container level stats come from CRI (via dockershim), while node level stats come from the "winstats" package that exports cadvisor like data structures using windows specific perf counters from the node.
-->
### 容器资源
<!--
### Container Resources
-->
现在可以为 v1.10 中的 windows 容器设置容器资源(CPU和内存)。
<!--
Container resources (CPU and memory) could be set now for windows containers in v1.10.
-->
{{< codenew file="windows/deploy-resource.yaml" >}}
### Hyper-V 容器
<!--
### Hyper-V Containers
-->
Hyper-V 容器在 v1.10 中作为实验支持。要创建 Hyper-V 容器，kubelet 应该从特性 gates `HyperVContainer=true` 开始，Pod 应该包含注释 `experimental.windows.kubernetes.io/isolation-type=hyperv`。
<!--
Hyper-V containers are supported as experimental in v1.10. To create a Hyper-V container, kubelet should be started with feature gates `HyperVContainer=true` and Pod should include annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`.
-->
{{< codenew file="windows/deploy-hyperv.yaml" >}}
### Kubelet 和 kube-proxy 现在可以作为 Windows 服务运行
<!--
### Kubelet and kube-proxy can now run as Windows services
-->
从 kubernetes v1.11 开始，kubelet 和 kube-proxy 可以作为 Windows 服务运行。
<!--
Starting with kubernetes v1.11, kubelet and kube-proxy can run as Windows services.
-->
这意味着您现在可以通过 `sc` 命令将它们注册为 Windows 服务。有关如何使用 `sc` 创建 Windows 服务的更多细节，请参阅[此处](https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe)。
<!--
This means that you can now register them as Windows services via `sc` command. More details about how to create Windows services with `sc` can be found [here](https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe).
-->
**例子：**
<!--
**Examples:**
-->
创建服务
<!--
To create the service:
-->
```
PS > sc.exe create <component_name> binPath= "<path_to_binary> --service <other_args>"
CMD > sc create <component_name> binPath= "<path_to_binary> --service <other_args>"
```
请注意，如果参数包含空格，则必须对其进行转义。例：
<!--
Please note that if the arguments contain spaces, it must be escaped. Example:
-->
```
PS > sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <other_args>"
CMD > sc create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <other_args>"
```
启动服务：
<!--
To start the service:
-->
```
PS > Start-Service kubelet; Start-Service kube-proxy
CMD > net start kubelet && net start kube-proxy
```
停止服务
<!--
To stop the service:
-->
```
PS > Stop-Service kubelet (-Force); Stop-Service kube-proxy (-Force)
CMD > net stop kubelet && net stop kube-proxy
```
查询服务
<!--
To query the service:
-->
```
PS > Get-Service kubelet; Get-Service kube-proxy;
CMD > sc.exe queryex kubelet && sc qc kubelet && sc.exe queryex kube-proxy && sc.exe qc kube-proxy
```
## Windows Server 容器与 v1.9 的已知限制
<!--
## Known Limitations for Windows Server Containers with v1.9
-->
在未来的Kubernetes版本中，社区将解决其中一些限制：
<!--
Some of these limitations will be addressed by the community in future releases of Kubernetes:
-->
- 共享网络名称空间(隔间)与多个 Windows Server 容器(共享内核)每个 pod 只支持在 Windows Server 1709 或更高
<!--
- Shared network namespace (compartment) with multiple Windows Server containers (shared kernel) per pod is only supported on Windows Server 1709 or later
-->
- 不支持使用 secret 和 configmap 作为卷装载
<!--
- Using Secrets and ConfigMaps as volume mounts is not supported
-->
- Windows不支持挂载传播
<!--
- Mount propagation is not supported on Windows
-->
- 不支持有状态应用程序的状态集功能
<!--
- The StatefulSet functionality for stateful applications is not supported
-->
- Windows Server 容器 pod 的相同 pod 自动缩放尚未经过验证，pod 端之间无法工作。
<!--
- Horizontal Pod Autoscaling for Windows Server Container pods has not been verified to work end-to-end
-->
- 不支持Hyper-V隔离容器。
<!--
- Hyper-V isolated containers are not supported.
-->
- Windows 容器操作系统必须与主机操作系统匹配。如果它不这样做，pod 就会陷入崩溃循环。
<!--
- Windows container OS must match the Host OS. If it does not, the pod will get stuck in a crash loop.
-->
- 在 L3 或主机 GW 的网络模型下，由于 Windows 问题，Windows 节点无法访问
<!--
- Under the networking models of L3 or Host GW, Kubernetes Services are inaccessible to Windows nodes due to a Windows issue. This is not an issue if using OVN/OVS for networking.
-->
- Windows kubelet.exe 在 VMware Fusion 下运行 Windows Server 时，可能无法启动[issue 57110](https://github.com/kubernetes/kubernetes/pull/57124)
<!--
- Windows kubelet.exe may fail to start when running on Windows Server under VMware Fusion [issue 57110](https://github.com/kubernetes/kubernetes/pull/57124)
-->
- Flannel 和 Weavenet 尚未得到支持
<!--
- Flannel and Weavenet are not yet supported
-->
- 一些 .Net 核心应用程序希望环境变量的名称中带有冒号 (`:`)。Kubernetes 目前不允许这样做。根据[此处](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment)所述，用双下划线 (`__`) 替换冒号 (':')
<!--
- Some .Net Core applications expect environment variables with a colon (`:`) in the name. Kubernetes currently does not allow this. Replace colon (`:`) with double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
-->
- 由于 cgroups 在 windows 上不受支持，kubelet.exe 应该以以下附加参数开始 `--cgroups-per-qos=false --enforce-node-allocatable=""` [issue 61716](https://github.com/kubernetes/kubernetes/issues/61716)
<!--
- As cgroups are not supported on windows, kubelet.exe should be started with the following additional arguments `--cgroups-per-qos=false --enforce-node-allocatable=""` [issue 61716](https://github.com/kubernetes/kubernetes/issues/61716)
-->
## 后续步骤和资源
<!--
## Next steps and resources
-->
- 对Windows版本的支持从v1.9开始测试，欢迎您提供反馈。有关参与的信息，请访问[SIG-Windows](https://github.com/kubernetes/community/blob/master/sig-windows/README.md)
- 故障排除和常见问题：[链接](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/common-problems)
<!--
- Support for Windows is in Beta as of v1.9 and your feedback is welcome. For information on getting involved, please head to [SIG-Windows](https://github.com/kubernetes/community/blob/master/sig-windows/README.md)
- Troubleshooting and Common Problems: [Link](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/common-problems)
-->
content/zh/docs/getting-started-guides/windows/ovn_kubernetes.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 104 KiB

content/zh/docs/getting-started-guides/windows/sample-l2bridge-wincni-config.json
+49
View File
@@ -0,0 +1,49 @@
{
"cniVersion": "0.2.0",
"name": "l2bridge",
"type": "wincni.exe",
"master": "Ethernet",
"ipam": {
"environment": "azure",
"subnet": "10.10.187.64/26",
"routes": [
{
"GW": "10.10.187.66"
}
]
},
"dns": {
"Nameservers": [
"11.0.0.10"
]
},
"AdditionalArgs": [
{
"Name": "EndpointPolicy",
"Value": {
"Type": "OutBoundNAT",
"ExceptionList": [
"11.0.0.0/8",
"10.10.0.0/16",
"10.127.132.128/25"
]
}
},
{
"Name": "EndpointPolicy",
"Value": {
"Type": "ROUTE",
"DestinationPrefix": "11.0.0.0/8",
"NeedEncap": true
}
},
{
"Name": "EndpointPolicy",
"Value": {
"Type": "ROUTE",
"DestinationPrefix": "10.127.132.213/32",
"NeedEncap": true
}
}
]
}
content/zh/docs/getting-started-guides/windows/windows-setup.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB