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/concepts/services-networking/_index.md
+11
View File
@@ -0,0 +1,11 @@
---
title: "服务、负载均衡和联网"
weight: 80
---
<!--
---
title: "Services, Load Balancing, and Networking"
weight: 80
---
-->
content/zh/docs/concepts/services-networking/ingress.md
+674
View File
@@ -0,0 +1,674 @@
---
reviewers:
- bprashanth
title: Ingress
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!--
## Terminology
Throughout this doc you will see a few terms that are sometimes used interchangeably elsewhere, that might cause confusion. This section attempts to clarify them.
* Node: A single virtual or physical machine in a Kubernetes cluster.
* Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
* Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](https://www.openvswitch.org/).
* Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
-->
## 专用术语
在本文档中，您将看到一些有时在其他地方可互换使用的术语，这些术语可能会引起混淆。 本节试图澄清它们
* 节点：Kubernetes 集群中的单个虚拟或物理机器。
* 集群：互联网防火墙保护下的一组节点，它们是 Kubernetes 管理的主要计算资源。
* 边缘路由器：为集群强制执行防火墙策略的路由器。这可以是由云提供商管理的网关或物理硬件。
* 集群网络：一组逻辑或物理的链接，根据 [Kubernetes 网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。集群网络的例子包括 覆盖网络，例如 [flannel](https://github.com/coreos/flannel#flannel)；或者SDN，例如 [OVS](https://www.openvswitch.org/)。
* 服务：Kubernetes [服务](/docs/concepts/services-networking/service/) 使用标签选择器标识一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
<!--
## What is Ingress?
Typically, services and pods have IPs only routable by the cluster network. All traffic that ends up at an edge router is either dropped or forwarded elsewhere. Conceptually, this might look like:
-->
## Ingress 是什么？
通常，服务 和 Pod 具有仅能在集群网络内路由的 IP 地址。在边缘路由器结束的所有流量都被丢弃或转发到别处。从概念上讲，这可能看起来像：
```none
internet
|
------------
[ Services ]
```
<!--
An Ingress is a collection of rules that allow inbound connections to reach the cluster services.
-->
Ingress 是允许连接到集群 Service 的规则集合。
```
互联网
|
[ Ingress ]
--|-----|--
[ Services ]
```
<!--
It can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, offer name based virtual hosting, and more. Users request ingress by POSTing the Ingress resource to the API server. An [Ingress controller](#ingress-controllers) is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic in an HA manner.
-->
它可以被配置为提供外部可访问的URL、负载均衡流量、终止SSL、提供基于名称的虚拟托管等等。
用户通过向 API 服务器 POST Ingress 资源来请求 Ingress。
[Ingress 控制器](#ingress-controllers) 负责实现 Ingress，它通常使用负载均衡器，不过它也可以配置边缘路由器或其他前端，从而帮助用户以 HA 方式处理流量。
<!--
## Prerequisites
Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
GCE/Google Kubernetes Engine deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) and [here](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class).
Make sure you review the [beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) of this controller. In environments other than GCE/Google Kubernetes Engine, you need to [deploy a controller](https://git.k8s.io/ingress-nginx/README.md) as a pod.
-->
## 环境准备
在开始使用 Ingress 资源之前，有一些事情您应该了解。
Ingress 是 beta 资源，在 1.1 之前的任何 Kubernetes 版本中都不可用。
您需要一个 Ingress 控制器来满足 Ingress，否则简单地创建资源将不起作用。
GCE／Google Kubernetes Engine 是在主节点上部署 Ingress 控制器。
您可以在 Pod 中部署任意数量的自定义 Ingress 控制器。
您必须使用适当的类来注释每个 Ingress，如[这里](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) 和 [这里](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class) 所示。
一定要检查一下这个控制器的 [beta 限制](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)。
在 GCE／Google Kubernetes Engine 之外的环境中，需要将[控制器部署](https://git.k8s.io/ingress-nginx/README.md) 为 Pod。
<!--
## The Ingress Resource
A minimal Ingress might look like:
-->
## Ingress 资源
最小的 Ingress 可能看起来像这样：
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /testpath
backend:
serviceName: test
servicePort: 80
```
<!--
*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
__Lines 1-6__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/) and [ingress configuration rewrite](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
__Lines 7-9__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
-->
*如果尚未配置 [Ingress 控制器](#ingress-controllers)，则向 API 服务器 POST 操作将没有任何效果。*
__1-6 行__: 与其他 Kubernetes 对象配置一样，Ingress 需要 `apiVersion`、`kind`、和 `metadata` 字段。
有关使用配置文件的一般信息，请参见
[部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)、
[配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/)、
[管理资源](/docs/concepts/cluster-administration/manage-deployment/)
和 [ingress 配置重写](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
__7-9 行__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 具有配置负载均衡器或代理服务器所需的所有信息。
最重要的是，它包含与所有传入请求相匹配的规则列表。目前，Ingress 资源仅支持 HTTP 规则。
<!--
__Lines 10-11__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
__Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/). Ingress traffic is typically sent directly to the endpoints matching a backend.
__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [API reference](https://releases.k8s.io/{{< param "githubbranch" >}}/staging/src/k8s.io/api/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
-->
__10-11 行__: 每个 HTTP 规则都包含以下信息：主机（例如：foo.bar.com，在本例中默认为 * ），路径列表（例如：/testpath），每个路径都有一个关联的后端（test:80）。
在负载均衡器将流量路由到后端之前，主机和路径都必须与传入请求的规则匹配。
__12-14 行__: 如[services doc](/docs/concepts/services-net./service/)中所述，后端（endpoint）是 “Service:port” 的组合。
Ingress 流量通常被直接发送到与后端相匹配的端点。
__全局参数__: 为了简单起见，Ingress 示例没有全局参数，有关资源的完整定义请参见 [API引用](https://releases.k8s.io/{{< param "githubbranch" >}}/staging/src/k8s.io/api/extensions/v1beta1/types.go)。
您可以指定全局默认的后端，这样的话，当请求与 spec 中的路径不匹配时，就会被转发到 Ingress 控制器的默认后端。
<!--
## Ingress controllers
In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. Choose the ingress controller implementation that best fits your cluster, or implement a new ingress controller.
-->
## Ingress 控制器
为了使 Ingress 资源正常工作，集群必须有 Ingress 控制器运行。
这不同于其他类型的控制器，它们通常作为 `kube-controller-manager` 二进制文件的一部分运行，并且通常作为集群创建的一部分自动启动。
请选择最适合您的集群的 Ingress 控制器，或者实现一个新的 Ingress 控制器。
<!--
* Kubernetes currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or [commercial](https://konghq.com/api-customer-success/) support and maintenance for the [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/)
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), and it also comes with commercial support by [Containous](https://containo.us/services)
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
* [HAProxy](http://www.haproxy.org/) based ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on this blog post [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)
* [Istio](https://istio.io/) based ingress controller [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)
{{< note >}}
**Note:** Review the documentation for your controller to find its specific support policy.
{{< /note >}}
-->
* Kubernetes 当前支持并维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
* F5 Networks 为 [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest) 提供[支持和维护](https://support.f5.com/csp/article/K86859508)。
* [Kong](https://konghq.com/) 为 [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/) 提供 [社区版](https://discuss.konghq.com/c/kubernetes) 或 [商业版](https://konghq.com/api-customer-success/) 支持和维护。
* [Traefik](https://github.com/containous/traefik) 是个全功能的 Ingress 控制器。
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), 它也伴随着 [Containous](https://containo.us/services) 的商业支持。
* [NGINX, Inc.](https://www.nginx.com/) 为 [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) 提供支持和维护。
* [HAProxy](http://www.haproxy.org/) 是 Ingress 控制器 [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) 的基础， 在这个博客中有提到它 [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)。
* [Istio](https://istio.io/) 是 Ingress 控制器 [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/) 的基础。
{{< note >}}
**注意:** 请检查你的控制器的文档以找到其特定的支持策略。
{{< /note >}}
<!--
## Before you begin
The following document describes a set of cross-platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. We currently support and maintain [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. If you use the F5 BIG-IP Controller, see [Use the BIG-IP Controller as a Kubernetes Ingress Controller](http://clouddocs.f5.com/containers/latest/kubernetes/kctlr-k8s-ingress-ctlr.html).
-->
## 在您开始之前
下面的文档描述了通过Ingress资源公开的一组跨平台特性。
理想情况下，所有 Ingress 控制器都应该满足这个规范，但是我们还没有。
我们现在支持并维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
如果您使用 F5 BIG-IP 控制器，请参考 [使用 BIG-IP 控制器作为 Kubernetes Ingress 控制器](http://clouddocs.f5.com/containers/latest/kubernetes/kctlr-k8s-ingress-ctlr.html)。
<!--
{{< note >}}
**Note:** Make sure you review your controller's specific docs so you understand the caveats.
{{< /note >}}
-->
{{< note >}}
**注意:** 请您一定要查看您的控制器的特定文档，以便您能理解这些警告。
{{< /note >}}
<!--
## Types of Ingress
### Single Service Ingress
There are existing Kubernetes concepts that allow you to expose a single Service
(see [alternatives](#alternatives)), however you can do so through an Ingress
as well, by specifying a *default backend* with no rules.
-->
## Ingress 的类型
### 单服务 Ingress
现有的 Kubernetes 概念允许您暴露单个 Service (查看 [替代方案](#alternatives))，同样您也可以使用 Ingress 来实现，具体方法是指定一个没有规则的 *默认后端（default backend）*。
{{< codenew file="service/networking/ingress.yaml" >}}
<!--
If you create it using `kubectl create -f` you should see:
-->
如果您用 `kubectl create -f`创建它，你应该看到：
```shell
kubectl get ingress test-ingress
```
```shell
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
```
<!--
Where `107.178.254.228` is the IP allocated by the Ingress controller to satisfy
this Ingress.
-->
其中 `107.178.254.228` 是 Ingress 控制器为该 Ingress 分配的 IP 该。
<!--
### Simple fanout
As described previously, Pods within kubernetes have IPs only visible on the
cluster network, so we need something at the edge accepting ingress traffic and
proxying it to the right endpoints. This component is usually a highly available
loadbalancer. An Ingress allows you to keep the number of loadbalancers down
to a minimum. For example, a setup like:
-->
### 简单分列
如前所述，Kubernetes 中 Pod 的 IP 仅在集群网络上可见，所以我们需要在集群网络的边缘接收下行流量并将其代理到正确的端点。
这个组件通常是一个高可用的负载均衡器。Ingress 允许您将负载均衡器的数量降至最低。例如，这样的设置：
```shell
foo.bar.com -> 178.91.123.132 -> / foo s1:80
/ bar s2:80
```
<!--
would require an Ingress such as:
-->
可能需要一个 Ingress 就像：
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: s1
servicePort: 80
- path: /bar
backend:
serviceName: s2
servicePort: 80
```
<!--
When you create the Ingress with `kubectl create -f`:
-->
当您使用 `kubectl create -f` 创建 Ingress 时：
```shell
kubectl describe ingress test
```
```shell
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo s1:80 (10.8.0.90:80)
/bar s2:80 (10.8.0.91:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 22s loadbalancer-controller default/test
```
<!--
The Ingress controller will provision an implementation specific loadbalancer
that satisfies the Ingress, as long as the services (`s1`, `s2`) exist.
When it has done so, you will see the address of the loadbalancer at the
Address field.
-->
Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress，只要 Service (`s1`，`s2`) 存在。
当它这样做了，你会在地址栏看到负载平衡器的地址。
{{< note >}}
<!--**Note:** You need to create a default-http-backend [Service](/docs/concepts/services-networking/service/) if necessary.-->
**注意:** 如果需要，你需要创建一个默认的 HTTP 后端 [Service](/docs/concepts/services-networking/service/)。
{{< /note >}}
<!--
### Name based virtual hosting
Name-based virtual hosts use multiple host names for the same IP address.
-->
### 基于名称的虚拟托管
基于名称的虚拟主机为同一个 IP 地址使用多个主机名。
```none
foo.bar.com --| |-> foo.bar.com s1:80
| 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com s2:80
```
<!--
The following Ingress tells the backing loadbalancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
-->
下面的 Ingress 让后台的负载均衡器基于 [Host header](https://tools.ietf.org/html/rfc7230#section-5.4) 路由请求。
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: s1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80
```
<!--
__Default Backends__: An Ingress with no rules, like the one shown in the previous
section, sends all traffic to a single default backend. You can use the same
technique to tell a loadbalancer where to find your website's 404 page, by
specifying a set of rules *and* a default backend. Traffic is routed to your
default backend if none of the Hosts in your Ingress match the Host in the
request header, and/or none of the paths match the URL of the request.
-->
__默认后端__: 一个没有规则的 Ingress，如前面部分所示，它将所有流量发送到单个默认后端。
通过指定一组规则*和*默认后端，您可以使用相同的技术来告诉负载均衡器在哪里找到网站的 404 页面。
如果 Ingress 中的主机与请求头中的主机不匹配，和/或没有路径与请求的 URL 匹配，则流量被路由到默认后端。
<!--
### TLS
You can secure an Ingress by specifying a [secret](/docs/concepts/configuration/secret)
that contains a TLS private key and certificate. Currently the Ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
configuration section in an Ingress specifies different hosts, they will be
multiplexed on the same port according to the hostname specified through the
SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret
must contain keys named `tls.crt` and `tls.key` that contain the certificate
and private key to use for TLS, e.g.:
-->
### TLS
您可以通过指定包含TLS私钥和证书的 [secret](/docs/concepts/configuration/secret) 来加密 Ingress。
目前，Ingress 只支持单个 TLS 端口，443，并假定 TLS 终止。
如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。
TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的密钥，这些密钥包含用于 TLS 的证书和私钥，例如：
```yaml
apiVersion: v1
data:
tls.crt: base64 encoded cert
tls.key: base64 encoded key
kind: Secret
metadata:
name: testsecret
namespace: default
type: Opaque
```
<!--
Referencing this secret in an Ingress will tell the Ingress controller to
secure the channel from the client to the loadbalancer using TLS:
-->
在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道：
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: no-rules-map
spec:
tls:
- secretName: testsecret
backend:
serviceName: s1
servicePort: 80
```
<!--
Note that there is a gap between TLS features supported by various Ingress
controllers. Please refer to documentation on
[nginx](https://git.k8s.io/ingress-nginx/README.md#https),
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), or any other
platform specific Ingress controller to understand how TLS works in your environment.
-->
注意，各种 Ingress 控制器所支持的 TLS 功能之间存在间隙。请参阅有关文件
[nginx](https://git.k8s.io/ingress-nginx/README.md#https)，
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)，
或任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。
<!--
### Loadbalancing
An Ingress controller is bootstrapped with some load balancing policy settings
that it applies to all Ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
(e.g. persistent sessions, dynamic weights) are not yet exposed through the
Ingress. You can still get these features through the
[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
With time, we plan to distill load balancing patterns that are applicable
cross platform into the Ingress resource.
-->
### 负载均衡
Ingress控制器使用一些适用于所有 Ingress 的负载均衡策略设置进行自举，例如负载平衡算法、后端权重方案等。
更高级的负载平衡概念（例如，持久会话、动态权重）尚未通过Ingress公开。
您仍然可以通过 [Service 负载均衡器](https://github.com/kubernetes/ingress-nginx) 获得这些特性。
随着时间的推移，我们计划将跨平台应用的负载平衡模式提取到 Ingress 资源中。
<!--
It's also worth noting that even though health checks are not exposed directly
through the Ingress, there exist parallel concepts in Kubernetes such as
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
which allow you to achieve the same end result. Please review the controller
specific docs to see how they handle health checks (
[nginx](https://git.k8s.io/ingress-nginx/README.md),
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
-->
值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，但是在 Kubernetes 中存在并行概念，比如 [就绪检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，它允许您实现相同的最终结果。
请检查控制器说明文档，以了解他们是怎样实现健康检查的 (
[nginx](https://git.k8s.io/ingress-nginx/README.md)，
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
<!--
## Updating an Ingress
Say you'd like to add a new Host to an existing Ingress, you can update it by editing the resource:
-->
## 更新 Ingress
假设您想向现有的 Ingress 中添加新主机，可以通过编辑资源来更新它：
```shell
kubectl describe ingress test
```
```shell
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo s1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 35s loadbalancer-controller default/test
```
```shell
kubectl edit ingress test
```
<!--
This should pop up an editor with the existing yaml, modify it to include the new Host:
-->
这应该弹出一个编辑器与现有的 yaml，修改它来增加新的主机：
```yaml
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: s1
servicePort: 80
path: /foo
- host: bar.baz.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80
path: /foo
..
```
<!--
Saving the yaml will update the resource in the API server, which should tell the Ingress controller to reconfigure the loadbalancer.
-->
保存 yaml 将更新 API 服务器中的资源，这应该会告诉 Ingress 控制器来重新配置负载均衡器。
```shell
kubectl describe ingress test
```
```shell
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo s1:80 (10.8.0.90:80)
bar.baz.com
/foo s2:80 (10.8.0.91:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 45s loadbalancer-controller default/test
```
<!--
You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
-->
您可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。
<!--
## Failing across availability zones
Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant Ingress controller for details. Please refer to the federation [doc](/docs/concepts/cluster-administration/federation/) for details on deploying Ingress in a federated cluster.
-->
## 跨可用区失败
用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。
有关在联邦集群中部署 Ingress 的详细信息，请参阅联邦 [文档](/docs/concepts/cluster-administration/federation/)。
<!--
## Future Work
* Various modes of HTTPS/TLS support (e.g.: SNI, re-encryption)
* Requesting an IP or Hostname via claims
* Combining L4 and L7 Ingress
* More Ingress controllers
Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827) for more details on the evolution of the resource, and the [Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the evolution of various Ingress controllers.
-->
## 未来的工作
*各种 HTTPS/TLS 模式的支持（例如：SNI、重加密）
*通过声明请求IP或主机名
*合并 L4 和 L7 Ingress
*更多 Ingress 控制器
请跟踪 [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827)以了解关于资源演化的更多细节，以及 [Ingress repository](https://github.com/kubernetes/ingress/tree/master) 以了解关于各种 Ingress 控制器演进的更多细节。
<!--
## Alternatives
You can expose a Service in multiple ways that don't directly involve the Ingress resource:
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
-->
## 替代方案
不直接使用 Ingress 资源，也有多种方法暴露 Service：
* 使用 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* 使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* 使用 [端口代理](https://git.k8s.io/contrib/for-demos/proxy-to-service)
{{% /capture %}}
{{% capture whatsnext %}}
{{% /capture %}}
content/zh/docs/concepts/services-networking/service.md
+659 -83
View File
@@ -1,47 +1,104 @@
---
approvers:
reviewers:
- bprashanth
title: Service
redirect_from:
- "/docs/user-guide/services/"
- "/docs/user-guide/services/index.html"
title: Services
feature:
title: 服务发现与负载均衡
description: >
无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载平衡。
content_template: templates/concept
weight: 10
---
<!--
---
reviewers:
- bprashanth
title: Services
feature:
title: Service discovery and load balancing
description: >
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives containers their own IP addresses and a single DNS name for a set of containers, and can load-balance across them.
content_template: templates/concept
weight: 10
---
-->
{{% capture overview %}}
<!--
Kubernetes [`Pods`](/docs/concepts/workloads/pods/pod/) are mortal. They are born and when they die, they
are not resurrected. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) in
particular create and destroy `Pods` dynamically (e.g. when scaling out or in). While each `Pod` gets its own IP address, even
those IP addresses cannot be relied upon to be stable over time. This leads to
a problem: if some set of `Pods` (let's call them backends) provides
functionality to other `Pods` (let's call them frontends) inside the Kubernetes
cluster, how do those frontends find out and keep track of which backends are
in that set?
-->
Kubernetes [`Pod`](/docs/user-guide/pods) 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。
通过 [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) 能够动态地创建和销毁 `Pod`（例如，需要进行扩缩容，或者执行 [滚动升级](/docs/user-guide/kubectl/v1.7/#rolling-update)）。
每个 `Pod` 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。
这会导致一个问题：在 Kubernetes 集群中，如果一组 `Pod`（称为 backend）为其它 `Pod` （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 `Pod` 中的哪些 backend 呢？
<!--
Enter `Services`.
-->
关于 `Services`
关于 `Service`
<!--
A Kubernetes `Service` is an abstraction which defines a logical set of `Pods`
and a policy by which to access them - sometimes called a micro-service. The
set of `Pods` targeted by a `Service` is (usually) determined by a [`Label
Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors) (see below for why you might want a
`Service` without a selector).
-->
Kubernetes `Service` 定义了这样一种抽象：逻辑上的一组 `Pod`，一种可以访问它们的策略 —— 通常称为微服务。
这一组 `Pod` 能够被 `Service` 访问到，通常是通过 [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)（查看下面了解，为什么可能需要没有 selector 的 `Service`）实现的。
<!--
As an example, consider an image-processing backend which is running with 3
replicas. Those replicas are fungible - frontends do not care which backend
they use. While the actual `Pods` that compose the backend set may change, the
frontend clients should not need to be aware of that or keep track of the list
of backends themselves. The `Service` abstraction enables this decoupling.
-->
举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。
然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。
`Service` 定义的抽象能够解耦这种关联。
<!--
For Kubernetes-native applications, Kubernetes offers a simple `Endpoints` API
that is updated whenever the set of `Pods` in a `Service` changes. For
non-native applications, Kubernetes offers a virtual-IP-based bridge to Services
which redirects to the backend `Pods`.
-->
对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 `Endpoints` API，只要 `Service` 中的一组 `Pod` 发生变更，应用程序就会被更新。
对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 `Service`，再由 `Service` 重定向到 backend `Pod`。
{{< toc >}}
{{% /capture %}}
{{% capture body %}}
<!--
## Defining a service
A `Service` in Kubernetes is a REST object, similar to a `Pod`. Like all of the
REST objects, a `Service` definition can be POSTed to the apiserver to create a
new instance. For example, suppose you have a set of `Pods` that each expose
port 9376 and carry a label `"app=MyApp"`.
-->
## 定义 Service
一个 `Service` 在 Kubernetes 中是一个 REST 对象，和 `Pod` 类似。
像所有的 REST 对象一样， `Service` 定义可以基于 POST 方式，请求 apiserver 创建新的实例。
例如，假定有一组 `Pod`，它们对外暴露了 9376 端口，同时还被打上 `"app=MyApp"` 标签。
@@ -60,13 +117,29 @@ spec:
targetPort: 9376
```
<!--
This specification will create a new `Service` object named "my-service" which
targets TCP port 9376 on any `Pod` with the `"app=MyApp"` label. This `Service`
will also be assigned an IP address (sometimes called the "cluster IP"), which
is used by the service proxies (see below). The `Service`'s selector will be
evaluated continuously and the results will be POSTed to an `Endpoints` object
also named "my-service".
-->
上述配置将创建一个名称为 “my-service” 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。
这个 `Service` 将被指派一个 IP 地址（通常称为 “Cluster IP”），它会被服务的代理使用（见下面）。
该 `Service` 的 selector 将会持续评估，处理结果将被 POST 到一个名称为 “my-service” 的 `Endpoints` 对象上。
<!--
Note that a `Service` can map an incoming port to any `targetPort`. By default
the `targetPort` will be set to the same value as the `port` field. Perhaps
more interesting is that `targetPort` can be a string, referring to the name of
a port in the backend `Pods`. The actual port number assigned to that name can
be different in each backend `Pod`. This offers a lot of flexibility for
deploying and evolving your `Services`. For example, you can change the port
number that pods expose in the next version of your backend software, without
breaking clients.
-->
需要注意的是， `Service` 能够将一个接收端口映射到任意的 `targetPort`。
默认情况下，`targetPort` 将被设置为与 `port` 字段相同的值。
@@ -75,16 +148,32 @@ spec:
对于部署和设计 `Service` ，这种方式会提供更大的灵活性。
例如，可以在 backend 软件下一个版本中，修改 Pod 暴露的端口，并不会中断客户端的调用。
<!--
Kubernetes `Services` support `TCP`, `UDP` and `SCTP` for protocols. The default
is `TCP`.
-->
Kubernetes `Service` 能够支持 `TCP` 和 `UDP` 协议，默认 `TCP` 协议。
{{< note >}}
自 Kubernetes 1.12 以来，SCTP 的支持是 alpha 功能。
{{< /note >}}
<!--
### Services without selectors
Services generally abstract access to Kubernetes `Pods`, but they can also
abstract other kinds of backends. For example:
* You want to have an external database cluster in production, but in test
you use your own databases.
* You want to point your service to a service in another
[`Namespace`](/docs/concepts/overview/working-with-objects/namespaces/) or on another cluster.
* You are migrating your workload to Kubernetes and some of your backends run
outside of Kubernetes.
In any of these scenarios you can define a service without a selector:
-->
### 没有 selector 的 Service
Servcie 抽象了该如何访问 Kubernetes `Pod`，但也能够抽象其它类型的 backend，例如：
* 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
@@ -105,6 +194,10 @@ spec:
targetPort: 9376
```
<!--
Because this service has no selector, the corresponding `Endpoints` object will not be
created. You can manually map the service to your own specific endpoints:
-->
由于这个 `Service` 没有 selector，就不会创建相关的 `Endpoints` 对象。可以手动将 `Service` 映射到指定的 `Endpoints`：
@@ -120,57 +213,76 @@ subsets:
- port: 9376
```
<!--
{{< note >}}
The endpoint IPs may not be loopback (127.0.0.0/8), link-local
(169.254.0.0/16), or link-local multicast (224.0.0.0/24). They cannot be the
cluster IPs of other Kubernetes services either because the `kube-proxy`
component doesn't support virtual IPs as destination yet.
{{< /note >}}
-->
{{< note >}}
注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）、或者 link-local 多播（224.0.0.0/24）。它们不能是其他 Kubernetes 服务的集群 IP，因为 `kube-proxy` 组件不支持虚拟 IP 作为目的地。
{{< /note >}}
注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）、或者 link-local 多播（224.0.0.0/24）。
<!--
Accessing a `Service` without a selector works the same as if it had a selector.
The traffic will be routed to endpoints defined by the user (`1.2.3.4:9376` in
this example).
-->
访问没有 selector 的 `Service`，与有 selector 的 `Service` 的原理相同。请求将被路由到用户定义的 Endpoint（该示例中为 `1.2.3.4:9376`）。
<!--
An ExternalName service is a special case of service that does not have
selectors and uses DNS names instead. For more information, see the
[ExternalName](#externalname) section later in this document.
-->
ExternalName `Service` 是 `Service` 的特例，它没有 selector，也没有使用 DNS 名称代替。
有关更多信息，请参阅本文档后面的[`ExternalName`](#externalname)。
ExternalName `Service` 是 `Service` 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。
相反地，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。
```yaml
kind: Service
apiVersion: v1
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
```
当查询主机 `my-service.prod.svc.CLUSTER`时，集群的 DNS 服务将返回一个值为 `my.database.example.com` 的 `CNAME` 记录。
访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。
如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 `Service` 的 `type`。
<!--
## Virtual IPs and service proxies
Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
responsible for implementing a form of virtual IP for `Services` of type other
than [`ExternalName`](#externalname).
In Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct, the
proxy was purely in userspace. In Kubernetes v1.1, the `Ingress` API was added
(beta) to represent "layer 7"(HTTP) services, iptables proxy was added too,
and became the default operating mode since Kubernetes v1.2. In Kubernetes v1.8.0-beta.0,
ipvs proxy was added.
-->
## VIP 和 Service 代理
在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 [`ExternalName`](#externalname) 的形式。
在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 `ExternalName` 的形式。
在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。
从 Kubernetes v1.2 起，默认就是 iptables 代理。
在 Kubernetes v1.0 版本，`Services` 是 "L4" (IP 层上的 TCP/UDP) 构造，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 `Ingress` API (beta) "L 7"(HTTP) 服务与 iptables 代理，自 Kubernetes v1.2 以来成为默认的操作模式。
在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理。
在 Kubernetes v1.0 版本，`Service` 是 “4层”（TCP/UDP over IP）概念。
在 Kubernetes v1.1 版本，新增了 `Ingress` API（beta 版），用来表示 “7层”（HTTP）服务。
<!--
### Proxy-mode: userspace
In this mode, kube-proxy watches the Kubernetes master for the addition and
removal of `Service` and `Endpoints` objects. For each `Service` it opens a
port (randomly chosen) on the local node. Any connections to this "proxy port"
will be proxied to one of the `Service`'s backend `Pods` (as reported in
`Endpoints`). Which backend `Pod` to use is decided based on the
`SessionAffinity` of the `Service`. Lastly, it installs iptables rules which
capture traffic to the `Service`'s `clusterIP` (which is virtual) and `Port`
and redirects that traffic to the proxy port which proxies the backend `Pod`.
By default, the choice of backend is round robin.
![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg)
-->
### userspace 代理模式
这种模式，kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
对每个 `Service`，它会在本地 Node 上打开一个端口（随机选择）。
任何连接到“代理端口”的请求，都会被代理到 `Service` 的backend `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。
@@ -190,12 +302,24 @@ spec:
![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg)
<!--
### Proxy-mode: iptables
In this mode, kube-proxy watches the Kubernetes master for the addition and
removal of `Service` and `Endpoints` objects. For each `Service`, it installs
iptables rules which capture traffic to the `Service`'s `clusterIP` (which is
virtual) and `Port` and redirects that traffic to one of the `Service`'s
backend sets. For each `Endpoints` object, it installs iptables rules which
select a backend `Pod`. By default, the choice of backend is random.
Obviously, iptables need not switch back between userspace and kernelspace, it should be
faster and more reliable than the userspace proxy. However, unlike the
userspace proxier, the iptables proxier cannot automatically retry another
`Pod` if the one it initially selects does not respond, so it depends on
having working [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#defining-readiness-probes).
![Services overview diagram for iptables proxy](/images/docs/services-iptables-overview.svg)
-->
### iptables 代理模式
这种模式，kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
对每个 `Service`，它会安装 iptables 规则，从而捕获到达该 `Service` 的 `clusterIP`（虚拟 IP）和端口的请求，进而将请求重定向到 `Service` 的一组 backend 中的某个上面。
对于每个 `Endpoints` 对象，它也会安装 iptables 规则，这个规则会选择一个 backend `Pod`。
@@ -214,7 +338,68 @@ spec:
![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg)
<!--
### Proxy-mode: ipvs
{{< feature-state for_k8s_version="v1.9" state="beta" >}}
In this mode, kube-proxy watches Kubernetes Services and Endpoints,
calls `netlink` interface to create ipvs rules accordingly and syncs ipvs rules with Kubernetes
Services and Endpoints periodically, to make sure ipvs status is
consistent with the expectation. When Service is accessed, traffic will
be redirected to one of the backend Pods.
Similar to iptables, Ipvs is based on netfilter hook function, but uses hash
table as the underlying data structure and works in the kernel space.
That means ipvs redirects traffic much faster, and has much
better performance when syncing proxy rules. Furthermore, ipvs provides more
options for load balancing algorithm, such as:
- `rr`: round-robin
- `lc`: least connection
- `dh`: destination hashing
- `sh`: source hashing
- `sed`: shortest expected delay
- `nq`: never queue
{{< note >}}
ipvs mode assumes IPVS kernel modules are installed on the node
before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
kube-proxy would validate if IPVS modules are installed on the node, if
it's not installed kube-proxy will fall back to iptables proxy mode.
{{< /note >}}
![Services overview diagram for ipvs proxy](/images/docs/services-ipvs-overview.svg)
In any of these proxy model, any traffic bound for the Service’s IP:Port is
proxied to an appropriate backend without the clients knowing anything
about Kubernetes or Services or Pods. Client-IP based session affinity
can be selected by setting `service.spec.sessionAffinity` to "ClientIP"
(the default is "None"), and you can set the max session sticky time by
setting the field `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`
if you have already set `service.spec.sessionAffinity` to "ClientIP"
(the default is “10800”).
-->
<!--
## Multi-Port Services
Many `Services` need to expose more than one port. For this case, Kubernetes
supports multiple port definitions on a `Service` object. When using multiple
ports you must give all of your ports names, so that endpoints can be
disambiguated. For example:
```yaml
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
```
Note that the port names must only contain lowercase alphanumeric characters and `-`, and must begin & end with an alphanumeric character. `123-abc` and `web` are valid, but `123_abc` and `-web` are not valid names.
-->
## 多端口 Service
@@ -242,23 +427,43 @@ spec:
targetPort: 9377
```
<!--
## Choosing your own IP address
You can specify your own cluster IP address as part of a `Service` creation
request. To do this, set the `.spec.clusterIP` field. For example, if you
already have an existing DNS entry that you wish to reuse, or legacy systems
that are configured for a specific IP address and difficult to re-configure.
The IP address that a user chooses must be a valid IP address and within the
`service-cluster-ip-range` CIDR range that is specified by flag to the API
server. If the IP address value is invalid, the apiserver returns a 422 HTTP
status code to indicate that the value is invalid.
-->
## 选择自己的 IP 地址
在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。
比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。
用户选择的 IP 地址必须合法，并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内，这对 API Server 来说是通过一个标识来指定的。
如果 IP 地址不合法，API Server 会返回 HTTP 状态码 422，表示值不合法。
<!--
### Why not use round-robin DNS?
A question that pops up every now and then is why we do all this stuff with
virtual IPs rather than just use standard round-robin DNS. There are a few
reasons:
* There is a long history of DNS libraries not respecting DNS TTLs and
caching the results of name lookups.
* Many apps do DNS lookups once and cache the results.
* Even if apps and libraries did proper re-resolution, the load of every
client re-resolving DNS over and over would be difficult to manage.
We try to discourage users from doing things that hurt themselves. That said,
if enough people ask for this, we may implement it as an alternative.
-->
### 为何不使用 round-robin DNS？
一个不时出现的问题是，为什么我们都使用 VIP 的方式，而不使用标准的 round-robin DNS，有如下几个原因：
* 长久以来，DNS 库都没能认真对待 DNS TTL、缓存域名查询结果
@@ -267,20 +472,42 @@ spec:
我们尽力阻止用户做那些对他们没有好处的事情，如果很多人都来问这个问题，我们可能会选择实现它。
<!--
## Discovering services
Kubernetes supports 2 primary modes of finding a `Service` - environment
variables and DNS.
-->
## 服务发现
Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。
<!--
### Environment variables
When a `Pod` is run on a `Node`, the kubelet adds a set of environment variables
for each active `Service`. It supports both [Docker links
compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
[makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49))
and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
where the Service name is upper-cased and dashes are converted to underscores.
For example, the Service `"redis-master"` which exposes TCP port 6379 and has been
allocated cluster IP address 10.0.0.11 produces the following environment
variables:
```shell
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
```
*This does imply an ordering requirement* - any `Service` that a `Pod` wants to
access must be created before the `Pod` itself, or else the environment
variables will not be populated. DNS does not have this restriction.
-->
### 环境变量
当 `Pod` 运行在 `Node` 上，kubelet 会为每个活跃的 `Service` 添加一组环境变量。
它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量（查看 [makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)）、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量，这里 `Service` 的名称需大写，横线被转换成下划线。
@@ -301,9 +528,29 @@ REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
*这意味着需要有顺序的要求* —— `Pod` 想要访问的任何 `Service` 必须在 `Pod` 自己之前被创建，否则这些环境变量就不会被赋值。DNS 并没有这个限制。
<!--
### DNS
An optional (though strongly recommended) [cluster
add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
DNS server watches the Kubernetes API for new `Services` and creates a set of
DNS records for each. If DNS has been enabled throughout the cluster then all
`Pods` should be able to do name resolution of `Services` automatically.
For example, if you have a `Service` called `"my-service"` in a Kubernetes
`Namespace` called `"my-ns"`, a DNS record for `"my-service.my-ns"` is created. `Pods`
which exist in the `"my-ns"` `Namespace` should be able to find it by simply doing
a name lookup for `"my-service"`. `Pods` which exist in other `Namespaces` must
qualify the name as `"my-service.my-ns"`. The result of these name lookups is the
cluster IP.
Kubernetes also supports DNS SRV (service) records for named ports. If the
`"my-service.my-ns"` `Service` has a port named `"http"` with protocol `TCP`, you
can do a DNS SRV query for `"_http._tcp.my-service.my-ns"` to discover the port
number for `"http"`.
The Kubernetes DNS server is the only way to access services of type
`ExternalName`. More information is available in the [DNS Pods and
Services](/docs/concepts/services-networking/dns-pod-service/).
-->
### DNS
一个可选（尽管强烈推荐）[集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md) 是 DNS 服务器。
DNS 服务器监视着创建新 `Service` 的 Kubernetes API，从而为每一个 `Service` 创建一组 DNS 记录。
@@ -326,7 +573,20 @@ Kubernetes 也支持对端口名称的 DNS SRV（Service）记录。
Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。
更多信息可以查看[DNS Pod 和 Service](/docs/concepts/services-networking/dns-pod-service/)。
<!--
## Headless services
Sometimes you don't need or want load-balancing and a single service IP. In
this case, you can create "headless" services by specifying `"None"` for the
cluster IP (`.spec.clusterIP`).
This option allows developers to reduce coupling to the Kubernetes system by
allowing them freedom to do discovery their own way. Applications can still use
a self-registration pattern and adapters for other discovery systems could easily
be built upon this API.
For such `Services`, a cluster IP is not allocated, kube-proxy does not handle
these services, and there is no load balancing or proxying done by the platform
for them. How DNS is automatically configured depends on whether the service has
selectors defined.
-->
## Headless Service
@@ -345,7 +605,12 @@ Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的
对这类 `Service` 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。
DNS 如何实现自动配置，依赖于 `Service` 是否定义了 selector。
<!--
### With selectors
For headless services that define selectors, the endpoints controller creates
`Endpoints` records in the API, and modifies the DNS configuration to return A
records (addresses) that point directly to the `Pods` backing the `Service`.
-->
### 配置 Selector
@@ -353,7 +618,15 @@ DNS 如何实现自动配置，依赖于 `Service` 是否定义了 selector。
对定义了 selector 的 Headless Service，Endpoint 控制器在 API 中创建了 `Endpoints` 记录，并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 `Service` 的后端 `Pod` 上。
<!--
### Without selectors
For headless services that do not define selectors, the endpoints controller does
not create `Endpoints` records. However, the DNS system looks for and configures
either:
* CNAME records for [`ExternalName`](#externalname)-type services.
* A records for any `Endpoints` that share a name with the service, for all
other types.
-->
### 不配置 Selector
@@ -365,7 +638,29 @@ DNS 如何实现自动配置，依赖于 `Service` 是否定义了 selector。
* `ExternalName` 类型 Service 的 CNAME 记录
* 记录：与 Service 共享一个名称的任何 `Endpoints`，以及所有其它类型
<!--
## Publishing services - service types
For some parts of your application (e.g. frontends) you may want to expose a
Service onto an external (outside of your cluster) IP address.
Kubernetes `ServiceTypes` allow you to specify what kind of service you want.
The default is `ClusterIP`.
`Type` values and their behaviors are:
* `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value
makes the service only reachable from within the cluster. This is the
default `ServiceType`.
* [`NodePort`](#nodeport): Exposes the service on each Node's IP at a static port
(the `NodePort`). A `ClusterIP` service, to which the `NodePort` service will
route, is automatically created. You'll be able to contact the `NodePort` service,
from outside the cluster,
by requesting `<NodeIP>:<NodePort>`.
* [`LoadBalancer`](#loadbalancer): Exposes the service externally using a cloud
provider's load balancer. `NodePort` and `ClusterIP` services, to which the external
load balancer will route, are automatically created.
* [`ExternalName`](#externalname): Maps the service to the contents of the
`externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
with its value. No proxying of any kind is set up. This requires version 1.7 or
higher of `kube-dns`.
-->
## 发布服务 —— 服务类型
@@ -383,7 +678,23 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认
* `ExternalName`：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` 字段的内容（例如， `foo.bar.example.com`）。
没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 `kube-dns` 才支持。
<!--
### Type NodePort {#nodeport}
If you set the `type` field to `NodePort`, the Kubernetes master will
allocate a port from a range specified by `--service-node-port-range` flag (default: 30000-32767), and each
Node will proxy that port (the same port number on every Node) into your `Service`.
That port will be reported in your `Service`'s `.spec.ports[*].nodePort` field.
If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s) (which is supported since Kubernetes v1.10). A comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 1.2.3.4/32) is used to filter addresses local to this node. For example, if you start kube-proxy with flag `--nodeport-addresses=127.0.0.0/8`, kube-proxy will select only the loopback interface for NodePort Services. The `--nodeport-addresses` is defaulted to empty (`[]`), which means select all available interfaces and is in compliance with current NodePort behaviors.
If you want a specific port number, you can specify a value in the `nodePort`
field, and the system will allocate you that port or else the API transaction
will fail (i.e. you need to take care about possible port collisions yourself).
The value you specify must be in the configured range for node ports.
This gives developers the freedom to set up their own load balancers, to
configure environments that are not fully supported by Kubernetes, or
even to just expose one or more nodes' IPs directly.
Note that this Service will be visible as both `<NodeIP>:spec.ports[*].nodePort`
and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
-->
### NodePort 类型
@@ -402,12 +713,51 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认
需要注意的是，Service 将能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。
<!--
### Type LoadBalancer {#loadbalancer}
On cloud providers which support external load balancers, setting the `type`
field to `LoadBalancer` will provision a load balancer for your `Service`.
The actual creation of the load balancer happens asynchronously, and
information about the provisioned balancer will be published in the `Service`'s
`.status.loadBalancer` field. For example:
```yaml
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
loadBalancerIP: 78.11.24.19
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 146.148.47.155
```
Traffic from the external load balancer will be directed at the backend `Pods`,
though exactly how that works depends on the cloud provider. Some cloud providers allow
the `loadBalancerIP` to be specified. In those cases, the load-balancer will be created
with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
an ephemeral IP will be assigned to the loadBalancer. If the `loadBalancerIP` is specified, but the
cloud provider does not support the feature, the field will be ignored.
**Special notes for Azure**: To use user-specified public type `loadBalancerIP`, a static type
public IP address resource needs to be created first, and it should be in the same resource
group of the other automatically created resources of the cluster. For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
{{< note >}}
The support of SCTP in the cloud provider's load balancer is up to the cloud provider's
load balancer implementation. If SCTP is not supported by the cloud provider's load balancer the
Service creation request is accepted but the creation of the load balancer fails.
{{< /note >}}
-->
### LoadBalancer 类型
使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。
负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。
@@ -439,7 +789,59 @@ status:
某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。
如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。
<!--
#### Internal load balancer
In a mixed environment it is sometimes necessary to route traffic from services inside the same VPC.
In a split-horizon DNS environment you would need two services to be able to route both external and internal traffic to your endpoints.
This can be achieved by adding the following annotations to the service based on cloud provider.
{{< tabs name="service_tabs" >}}
{{% tab name="Default" %}}
Select one of the tabs.
{{% /tab %}}
{{% tab name="GCP" %}}
```yaml
[...]
metadata:
name: my-service
annotations:
cloud.google.com/load-balancer-type: "Internal"
[...]
```
Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing).
{{% /tab %}}
{{% tab name="AWS" %}}
```yaml
[...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
[...]
```
{{% /tab %}}
{{% tab name="Azure" %}}
```yaml
[...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
[...]
```
{{% /tab %}}
{{% tab name="OpenStack" %}}
```yaml
[...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
[...]
```
{{% /tab %}}
{{< /tabs >}}
-->
### AWS 内部负载均衡器
在混合云环境中，有时从虚拟私有云（VPC）环境中的服务路由流量是非常有必要的。
@@ -457,7 +859,61 @@ metadata:
在水平分割的 DNS 环境中，需要两个 `Service` 来将外部和内部的流量路由到 Endpoint 上。
<!--
#### SSL support on AWS
For partial SSL support on clusters running on AWS, starting with 1.3 three
annotations can be added to a `LoadBalancer` service:
```yaml
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
```
The first specifies the ARN of the certificate to use. It can be either a
certificate from a third party issuer that was uploaded to IAM or one created
within AWS Certificate Manager.
```yaml
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
```
The second annotation specifies which protocol a pod speaks. For HTTPS and
SSL, the ELB will expect the pod to authenticate itself over the encrypted
connection.
HTTP and HTTPS will select layer 7 proxying: the ELB will terminate
the connection with the user, parse headers and inject the `X-Forwarded-For`
header with the user's IP address (pods will only see the IP address of the
ELB at the other end of its connection) when forwarding requests.
TCP and SSL will select layer 4 proxying: the ELB will forward traffic without
modifying the headers.
In a mixed-use environment where some ports are secured and others are left unencrypted,
the following annotations may be used:
```yaml
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"
```
In the above example, if the service contained three ports, `80`, `443`, and
`8443`, then `443` and `8443` would use the SSL certificate, but `80` would just
be proxied HTTP.
Beginning in 1.9, services can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)
for any HTTPS or SSL listeners. To see which policies are available for use, run
the awscli command:
```bash
aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'
```
Any one of those policies can then be specified using the
"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
annotation, for example:
```yaml
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"
-->
### AWS SSL 支持
对运行在 AWS 上部分支持 SSL 的集群，从 1.3 版本开始，可以为 `LoadBalancer` 类型的 `Service` 增加两个 annotation：
@@ -490,7 +946,31 @@ HTTP 和 HTTPS 将选择7层代理：ELB 将中断与用户的连接，当转发
TCP 和 SSL 将选择4层代理：ELB 将转发流量，并不修改 Header 信息。
<!--
### External IPs
If there are external IPs that route to one or more cluster nodes, Kubernetes services can be exposed on those
`externalIPs`. Traffic that ingresses into the cluster with the external IP (as destination IP), on the service port,
will be routed to one of the service endpoints. `externalIPs` are not managed by Kubernetes and are the responsibility
of the cluster administrator.
In the `ServiceSpec`, `externalIPs` can be specified along with any of the `ServiceTypes`.
In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`"" (`externalIP:port`)
```yaml
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10
```
-->
### 外部 IP
@@ -518,7 +998,20 @@ spec:
- 80.11.12.10
```
<!--
## Shortcomings
Using the userspace proxy for VIPs will work at small to medium scale, but will
not scale to very large clusters with thousands of Services. See [the original
design proposal for portals](http://issue.k8s.io/1107) for more details.
Using the userspace proxy obscures the source-IP of a packet accessing a `Service`.
This makes some kinds of firewalling impossible. The iptables proxier does not
obscure in-cluster source IPs, but it does still impact clients coming through
a load-balancer or node-port.
The `Type` field is designed as nested functionality - each level adds to the
previous. This is not strictly required on all cloud providers (e.g. Google Compute Engine does
not need to allocate a `NodePort` to make `LoadBalancer` work, but AWS does)
but the current API requires it.
-->
## 不足之处
@@ -536,7 +1029,20 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求
`Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`，但是 AWS 需要 ），但当前 API 是强制要求的。
<!--
## Future work
In the future we envision that the proxy policy can become more nuanced than
simple round robin balancing, for example master-elected or sharded. We also
envision that some `Services` will have "real" load balancers, in which case the
VIP will simply transport the packets there.
We intend to improve our support for L7 (HTTP) `Services`.
We intend to have more flexible ingress modes for `Services` which encompass
the current `ClusterIP`, `NodePort`, and `LoadBalancer` modes and more.
## The gory details of virtual IPs
The previous information should be sufficient for many people who just want to
use `Services`. However, there is a lot going on behind the scenes that may be
worth understanding.
-->
## 未来工作
@@ -549,14 +1055,37 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求
我们打算为 `Service` 实现更加灵活的请求进入模式，这些 `Service` 包含当前 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。
<!--
## The gory details of virtual IPs
The previous information should be sufficient for many people who just want to
use `Services`. However, there is a lot going on behind the scenes that may be
worth understanding.
-->
## VIP 的那些骇人听闻的细节
对很多想使用 `Service` 的人来说，前面的信息应该足够了。
然而，有很多内部原理性的内容，还是值去理解的。
<!--
### Avoiding collisions
One of the primary philosophies of Kubernetes is that users should not be
exposed to situations that could cause their actions to fail through no fault
of their own. In this situation, we are looking at network ports - users
should not have to choose a port number if that choice might collide with
another user. That is an isolation failure.
In order to allow users to choose a port number for their `Services`, we must
ensure that no two `Services` can collide. We do that by allocating each
`Service` its own IP address.
To ensure each service receives a unique IP, an internal allocator atomically
updates a global allocation map in etcd prior to creating each service. The map object
must exist in the registry for services to get IPs, otherwise creations will
fail with a message indicating an IP could not be allocated. A background
controller is responsible for creating that map (to migrate from older versions
of Kubernetes that used in memory locking) as well as checking for invalid
assignments due to administrator intervention and cleaning up any IPs
that were allocated but which no service currently uses.
-->
### 避免冲突
@@ -575,7 +1104,18 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致
为了使 `Service` 能够获取到 IP，这个映射表对象必须在注册中心存在，否则创建 `Service` 将会失败，指示一个 IP 不能被分配。
一个后台 Controller 的职责是创建映射表（从 Kubernetes 的旧版本迁移过来，旧版本中是通过在内存中加锁的方式实现），并检查由于管理员干预和清除任意 IP 造成的不合理分配，这些 IP 被分配了但当前没有 `Service` 使用它们。
<!--
### IPs and VIPs
Unlike `Pod` IP addresses, which actually route to a fixed destination,
`Service` IPs are not actually answered by a single host. Instead, we use
`iptables` (packet processing logic in Linux) to define virtual IP addresses
which are transparently redirected as needed. When clients connect to the
VIP, their traffic is automatically transported to an appropriate endpoint.
The environment variables and DNS for `Services` are actually populated in
terms of the `Service`'s VIP and port.
We support three proxy modes - userspace, iptables and ipvs which operate
slightly differently.
-->
### IP 和 VIP
@@ -584,7 +1124,22 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致
当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。
环境变量和 DNS，实际上会根据 `Service` 的 VIP 和端口来进行填充。
<!--
#### Userspace
As an example, consider the image processing application described above.
When the backend `Service` is created, the Kubernetes master assigns a virtual
IP address, for example 10.0.0.1. Assuming the `Service` port is 1234, the
`Service` is observed by all of the `kube-proxy` instances in the cluster.
When a proxy sees a new `Service`, it opens a new random port, establishes an
iptables redirect from the VIP to this new port, and starts accepting
connections on it.
When a client connects to the VIP the iptables rule kicks in, and redirects
the packets to the `Service proxy`'s own port. The `Service proxy` chooses a
backend, and starts proxying traffic from the client to the backend.
This means that `Service` owners can choose any port they want without risk of
collision. Clients can simply connect to an IP and port, without being aware
of which `Pods` they are actually accessing.
-->
#### Userspace
@@ -601,7 +1156,23 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致
这意味着 `Service` 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。
客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些 `Pod`。
<!--
#### Iptables
Again, consider the image processing application described above.
When the backend `Service` is created, the Kubernetes master assigns a virtual
IP address, for example 10.0.0.1. Assuming the `Service` port is 1234, the
`Service` is observed by all of the `kube-proxy` instances in the cluster.
When a proxy sees a new `Service`, it installs a series of iptables rules which
redirect from the VIP to per-`Service` rules. The per-`Service` rules link to
per-`Endpoint` rules which redirect (Destination NAT) to the backends.
When a client connects to the VIP the iptables rule kicks in. A backend is
chosen (either based on session affinity or randomly) and packets are
redirected to the backend. Unlike the userspace proxy, packets are never
copied to userspace, the kube-proxy does not have to be running for the VIP to
work, and the client IP is not altered.
This same basic flow executes when traffic comes in through a node-port or
through a load-balancer, though in those cases the client IP does get altered.
-->
#### Iptables
@@ -617,7 +1188,12 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致
不像 userspace 代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，并且客户端 IP 是不可更改的。
当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，但是在那些案例中客户端 IP 是可以更改的。
<!--
## API Object
Service is a top-level resource in the Kubernetes REST API. More details about the
API object can be found at:
[Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
-->
## API 对象