Merge release 1.12 into release 1.13 (#14171)
* ZH-trans: Update coarse-parallel-processing-work-queue.md (#11862) * ZH-trans: Update coarse-parallel-processing-work-queue.md * Update coarse-parallel-processing-work-queue.md * zh-trans: add /docs/concepts/architecture/cloud-controller.md (#11799) * docs/concepts/architecture/cloud-controller.md * docs/concepts/architecture/cloud-controller.md * docs/concepts/architecture/cloud-controller.md * fix * fix * fix * zh-trans: /docs/contribute/style/kubernetes-components.md (#11838) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/generate-ref-docs/kubernetes-components.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * Update weave-network-policy.md (#11858) * ZH-trans: add Update define-environment-variable-container.md (#11859) * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update define-environment-variable-container.md * Update fine-parallel-processing-work-queue.md (#11863) * Update fine-parallel-processing-work-queue.md * Update fine-parallel-processing-work-queue.md * Update setup-extension-api-server.md (#11864) * zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md (#11798) * zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md zh-trans: add / docs/reference/setup-tools/kubeadm/kubeadm-join.md * Update kubeadm-join.md * Create kubeadm_join.md * zh-trans: update docs/concepts/containers/images.md (#11877) * zh-trans: update docs/concepts/containers/images.md * zh-trans: update docs/concepts/containers/images.md * Update kubeadm_alpha_phase_controlplane.md (#11878) * 更新第 115 行翻译 * zh_trans: kubeadm_token_generate.md (#11884) * zh_trans: kubeadm_token_generate.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md * Better translation Better translation * zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md (#11886) zh-trans: add /docs/tasks/configure-pod-container/configure-pod-initialization.md * zh-trans:add content/zh/docs/reference/issues-security (#11890) * zh-trans: add content/zh/docs/tutorials/online-training/overview.md (#11892) * zh_trans: kubeadm_token_delete.md (#11883) * zh_trans: kubeadm_token_delete.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md * fix tpye error fix tpye error * Better translation Better translation * zh_trans: independent/create-cluster-kubeadm.md (#11882) * zh_trans: independent/create-cluster-kubeadm.md zh_trans: docs/setup/independent/create-cluster-kubeadm.md * fix word style error * fix type error * better zhtran better zhtran * fix "Create" -> "create" fix "Create" -> "create" * zh-trans: add docs/concepts/storage/storage-classes.md (#11788) * ZH-trans: fixing formatting errors (#11661) * ZH-trans: fixing formatting errors * Update ZH-trans: fixing formatting errors storage-classes zh part 1 * storage-classes zh trans * fix typo update trans for provisioner & fix typo * fix typo * 根据校对更新翻译 * zh_trans: kubeadm-token.md (#11898) zh_trans: /docs/reference/setup-tools/kubeadm/kubeadm-token.md * zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md (#11900) * zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md zh-trans: add /docs/tasks/configure-pod-container/quality-service-pod.md * Update quality-service-pod.md * zh_trans: kubeadm_alpha_phase_bootstrap-token_node.md (#11897) zh_trans: Path：/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md * zh-trans: add /docs/concepts/storage/volumes.md (#11767) * zh-trans: add /docs/concepts/storage/volumes.md zh-trans: add /docs/concepts/storage/volumes.md * Update volumes.md * Update volumes.md * self-review * Update volumes.md * fix docs format error (#11934) fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/ * Update cloud-controller.md (#11922) * zh-trans: /docs/reference/glossary/approver.md (#11924) zh-trans: /docs/reference/glossary/approver.md * zh-trans: add docs/setup/on-premises-vm/dcos.md (#11891) * zh-trans: add docs/setup/on-premises-vm/dcos.md * Update content/zh/docs/setup/on-premises-vm/dcos.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: /docs/tasks/configure-pod-container/configure-persistent-vo… (#11915) * zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md zh-trans: /docs/tasks/configure-pod-container/configure-persistent-volume-storage.md * Update configure-persistent-volume-storage.md * zh_trans: kubeadm_alpha.md (#11902) * zh_trans: kubeadm_alpha.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md * Better translation Better translation * zh-trans: /docs/reference/glossary/downstream.md (#11931) * zh-trans: /docs/reference/glossary/downstream.md zh-trans: /docs/reference/glossary/downstream.md * Update downstream.md * Update downstream.md * ZH-trans: Update install-kubeadm.md (#11955) * fix typo of install-kubeadm.md fix typo of install-kubeadm.md * Update install-kubeadm.md * zh-trans: add kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md (#11952) * zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md zh-trans: add /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md * Update kubeadm_alpha_phase_certs_renew_all.md * renew 的翻译更新为续期 * zh-trans:kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md (#11953) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md * Update kubeadm_alpha_phase_certs_renew_etcd-peer.md * zh-trans: /docs/contribute/generate-ref-docs/kubectl.md (#11941) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * fix docs format error (#11936) fix docs format error of https://v1-12.docs.kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/ * Update pull request (#11921) * Update pull request (#11960) * ZH-trans: add kubefed-options.md (#11956) * Update ZH-trans: add kubefed-options.md * Update kubefed-options.md * ZH-trans: add generated/... (#11880) * Update pull request * Update kubeadm_alpha_phase_certs_renew.md * Update pull request (#11881) * ZH-trans: add generated/... (#11879) * Update pull request * Resolving file conflicts * zh-trans: add zh/ docs/tasks/configure-pod-container/configure-servic… (#11889) * zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md zh-trans: add zh/ docs/tasks/configure-pod-container/configure-service-account.md * Update configure-service-account.md * Update configure-service-account.md * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md (#11875) * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md * zh-trans: update docs/concepts/cluster-administration/kubelet-garbage-collection.md * zh-trans:update kubelet-garbage-collection.md * zh_trans: kubeadm_alpha_phase_kubeconfig_user.md (#11901) * zh_trans: kubeadm_alpha_phase_kubeconfig_user.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md * Better translation * zh-trans:add docs/reference/using-api/client-libraries.md (#11958) * zh-trans:add docs/reference/using-api/client-libraries.md * Update content/zh/docs/reference/using-api/client-libraries.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: add pull-image-private-registry.md (#11912) * zh-trans: add pull-image-private-registry.md zh-trans: add pull-image-private-registry.md * Update pull-image-private-registry.md * Update pull-image-private-registry.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config_annotate-cri.md (#11972) * Create kubeadm_alpha_phase_kubelet_config_annotate-cri.md * Update kubeadm_alpha_phase_kubelet_config_annotate-cri.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config.md (#11974) * Create kubeadm_alpha_phase_kubelet_config.md * Update kubeadm_alpha_phase_kubelet_config.md * fix Typo "##" -> "## " (#12011) * fix Typo "##" -> "## " fix Typo "##" -> "## " * update basic-stateful-set.md * fix web style error (#12010) fix web style error * Create kubeadm_alpha_phase_selfhosting.md (#12006) * Create kubeadm_alpha_phase_controlplane_apiserver.md (#12005) * zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitor… (#11995) * zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md zh-trans:/docs/tasks/debug-application-cluster/resource-usage-monitoring.md * Update resource-usage-monitoring.md * Update resource-usage-monitoring.md * zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md (#11990) zh-trans:/docs/tasks/debug-application-cluster/core-metrics-pipeline.md * zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md (#11989) zh-trans:/docs/tasks/debug-application-cluster/troubleshooting.md * Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md (#11969) * Create kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md * Update kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md * zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md (#11962) * zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md zh-trans: /docs/tasks/debug-application-cluster/debug-init-containers.md * Update debug-init-containers.md * zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md (#11930) * zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md zh-trans: docs/reference/glossary/horizontal-pod-autoscaler.md * Update horizontal-pod-autoscaler.md * zh-trans: add /docs/tasks/configure-pod-container/configure-projected… (#11911) * zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md zh-trans: add /docs/tasks/configure-pod-container/configure-projected-volume-storage.md * Update configure-projected-volume-storage.md * Update configure-projected-volume-storage.md * zh-trans: /docs/tasks/configure-pod-container/extended-resource.md (#11918) * zh-trans: /docs/tasks/configure-pod-container/extended-resource.md zh-trans: /docs/tasks/configure-pod-container/extended-resource.md * Update extended-resource.md * Update extended-resource.md * zh-trans: add translate-compose-kubernetes.md (#11910) * zh-trans: add translate-compose-kubernetes.md zh-trans: add translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * Update translate-compose-kubernetes.md * zh-trans: zh/docs/reference/glossary/flexvolume.md (#11925) * zh-trans: zh/docs/reference/glossary/flexvolume.md zh-trans: zh/docs/reference/glossary/flexvolume.md * Update flexvolume.md * zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md (#11947) * zh_trans: kubeadm_alpha_phase_bootstrap-token_create.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_create.md * better translation better translation * zh-trans:add docs/setup/turnkey/alibaba-cloud.md (#11959) * zh_trans: kubeadm_completion.md (#11895) * zh_trans: kubeadm_completion.md zh_trans: /docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md * Better translation Better translation * Update kubeadm_completion.md * better translation better translation * zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md (#11961) * zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md zh-trans: add /zh/ docs/tasks/debug-application-cluster/crictl.md * Update crictl.md * ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-ca.md (#11968) * ZH-trans: add kubeadm_alpha_phase_controlplane_all.md (#11970) * Create kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * Update kubeadm_alpha_phase_controlplane_all.md * ZH-trans: add kubeadm_alpha_phase_upload-config.md (#11971) * Create kubeadm_alpha_phase_upload-config.md * Update kubeadm_alpha_phase_upload-config.md * Update kubeadm_alpha_phase_upload-config.md * ZH-trans: Fixed some incorrect translations (#11973) * zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-… (#11977) * zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md zh-trans: /docs/tasks/debug-application-cluster/determine-reason-pod-failure.md * Update determine-reason-pod-failure.md * zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md (#11988) * zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md zh-trans: /docs/tasks/debug-application-cluster/local-debugging.md * Update local-debugging.md * zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md (#11996) zh-trans:/docs/tasks/debug-application-cluster/events-stackdriver.md * zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-cont… (#11998) * zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md zh-trans:/docs/tasks/debug-application-cluster/get-shell-running-container.md * Update get-shell-running-container.md * zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md (#12001) zh-trans:/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md * ZH-trans: ad kubeadm_alpha_phase_kubelet_config_write-to-disk.md (#12004) * Create kubeadm_alpha_phase_kubelet_config_write-to-disk.md * Update kubeadm_alpha_phase_kubelet_config_write-to-disk.md * Remove old-generated kubefed docs (generated on 25-march-2018) (#12093) * Update _index.md (#12061) * Update kubeadm_reset.md (#12047) * ZH-trasn: add kubeadm_alpha_phase_kubeconfig_controller-manager.md (#12032) * Create kubeadm_alpha_phase_kubeconfig_controller-manager.md * Update kubeadm_alpha_phase_kubeconfig_controller-manager.md * ZH-trans: add kubeadm_alpha_phase_preflight_node.md (#12035) * Create kubeadm_alpha_phase_preflight_node.md * Update kubeadm_alpha_phase_preflight_node.md * Update kubeadm_alpha_phase_preflight_node.md * ZH-trans: add kubeadm_alpha_phase_controlplane_scheduler.md (#12031) * Create kubeadm_alpha_phase_controlplane_scheduler.md * Update kubeadm_alpha_phase_controlplane_scheduler.md * ZH-trans: add kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md (#12039) * Create kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md * Update kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md * ZH-trans: add kubeadm_alpha_phase_kubelet_write-env-file.md (#12034) * Create kubeadm_alpha_phase_kubelet_write-env-file.md * Update kubeadm_alpha_phase_kubelet_write-env-file.md * ZH-trans: add kubeadm_upgrade_node_experimental-control-plane.md (#12036) * Create kubeadm_upgrade_node_experimental-control-plane.md * Update kubeadm_upgrade_node_experimental-control-plane.md * Create kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md (#12038) * Create kubeadm_alpha_phase_etcd.md (#12040) * ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-server.md (#12041) * Create kubeadm_alpha_phase_certs_renew_etcd-server.md * Update kubeadm_alpha_phase_certs_renew_etcd-server.md * Update advanced.md (#12044) * ZH-trans: add kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md (#12042) * Create kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md * Update kubeadm_version.md (#12046) * Update _index.md (#12063) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md (#12085) zh-trans:/docs/reference/setup-tools/kubefed/kubefed_version.md * ZH-trans: add kubeadm_alpha_phase_certs_etcd-peer.md (#12037) * Create kubeadm_alpha_phase_certs_etcd-peer.md * Update kubeadm_alpha_phase_certs_etcd-peer.md * Update kubeadm_alpha_phase_certs_etcd-peer.md * ZH-trans: add kubeadm_alpha_phase_kubelet_config_download.md (#12033) * Create kubeadm_alpha_phase_kubelet_config_download.md * Update kubeadm_alpha_phase_kubelet_config_download.md * zh-trans: add docs/tasks/access-application-cluster/_index.md (#12048) * zh-trans: update cpu-constraint-namespace.md and cpu-default-namespace.md (#12106) * ZH-trans: update kubeadm_alpha_phase_upload-config.md (#12110) * zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md (#12022) * zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md zh-tran: /docs/reference/setup-tools/kubefed/kubefed_unjoin.md * Update kubefed_unjoin.md * Update kubefed_unjoin.md * Update kubefed_unjoin.md * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12114) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md * Update kubeadm_alpha_phase_certs_apiserver.md * Update kubeadm_alpha_phase_certs_apiserver.md * zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md (#12088) * zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md zh-trans:/docs/reference/kubectl/docker-cli-to-kubectl.md * Update docker-cli-to-kubectl.md * zh-trans: /docs/reference/kubectl/conventions.md (#12089) * zh-trans: /docs/reference/kubectl/conventions.md zh-trans: /docs/reference/kubectl/conventions.md * Update conventions.md * zh-trans organize-cluster-access-kubeconfig.md (#12094) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md (#12086) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed.md * Update kubefed.md * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md (#12029) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed_join.md * Update kubefed_join.md * Update kubefed_join.md * zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md (#12020) * zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md zh-trans: /docs/reference/setup-tools/kubefed/kubefed_init.md * Update kubefed_init.md * Update kubefed_init.md * Update kubefed_init.md * zh-trans: add docs/setup/independent/control-plane-flags.md (#12043) * zh-trans: add docs/setup/independent/control-plane-flags.md * update content/zh/docs/setup/independent/control-plane-flags.md * zh-trans:/docs/tasks/tools/install-kubectl.md (#11992) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * zh-trans: add /docs/concepts/cluster-administration/manage-deployment.md (#11899) * add /docs/concepts/cluster-administration/manage-deployment.md * 更新部分翻译，去除多余的反引号 * 更新部分翻译 * zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md (#12045) * zh-trans: add docs/tasks/service-catalog/install-service-catalog-using-sc.md * update docs/tasks/service-catalog/install-service-catalog-using-sc.md * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md (#12087) * zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md zh-trans:/docs/reference/setup-tools/kubefed/kubefed_options.md * Update kubefed_options.md * Update kubefed_options.md * zh-trans: Fix some blog links issue (#12115) * zh-trans: Fix some blog links issue * Revert the space change * update Set Kubelet parameters via a config file (#12150) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md (#12185) zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_… (#12184) * zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md zh-trans:/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md * Update kubeadm_alpha_phase_etcd_local.md * zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md (#12130) zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md * zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md (#12131) zh-trans: kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md * zh-trans: /docs/contribute/generate-ref-docs/kubernetes-api.md (#12141) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * zh-trans:/docs/concepts/overview/object-management-kubectl/imperative… (#12151) * zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md zh-trans:/docs/concepts/overview/object-management-kubectl/imperative-config.md * Update imperative-config.md * ZH-trans: added a blog post Chinese translation: 2018-05-01-developing-on-kubernetes.md (#12009) * added a blog post chinese translation * Update 2018-05-01-developing-on-kubernetes.md apply some suggested changes per review comments * Update 2018-05-01-developing-on-kubernetes.md cont to review and improve the wording, up to squash * more update and rewording * ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md (#12209) * ZH-trans: add kubeadm_alpha_phase_kubelet_config_enable-dynamic.md * Update kubeadm_alpha_phase_kubelet_config_enable-dynamic.md * ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md (#12210) * ZH-trans: add kubeadm_alpha_phase_certs_renew_apiserver.md * Update kubeadm_alpha_phase_certs_renew_apiserver.md * Update kubeadm_alpha_phase_certs_renew_apiserver.md * ZH-trans: add kubeadm_alpha_phase_certs_front-proxy-client.md (#12212) * fix docs style (#12225) * fix docs style fix docs style * fix docs style fix docs style * ZH-trans: add rbac.md (#12263) * ZH-trans: add rbac.md * Update rbac.md * ZH-trans: add persistent-volume-claim.md (#12264) * ZH-trans: add persistent-volume-claim.md * Update persistent-volume-claim.md * Update persistent-volume-claim.md * Update docker-cli-to-kubectl.md (#12288) * ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md (#12285) * ZH-trans: add kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md * Update kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md * ZH-trans: add coredns.md (#12282) * ZH-trans: add coredns.md * Update coredns.md * ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md (#12286) * ZH-trans: add kubeadm_alpha_phase_certs_etcd-healthcheck-client.md * Update kubeadm_alpha_phase_certs_etcd-healthcheck-client.md * ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md (#12284) * ZH-trans: add kubeadm_alpha_phase_kubeconfig_kubelet.md * Update kubeadm_alpha_phase_kubeconfig_kubelet.md * ZH-trans: add service-account.md (#12261) * ZH-trans: add service-account.md * Update service-account.md * ZH-trans: add security-context.md (#12262) * ZH-trans: add security-context.md * Update security-context.md * Update security-context.md * Update security-context.md * fix typo "_必须_" -> "必须" (#12300) fix typo "_必须_" -> "必须" * fix docs style error (#12307) fix docs style error * Create explore-interactive.html (#12311) * fix docs style error (#12314) fix docs style error * ZH-trans: add kube-controller-manager.md (#12260) * ZH-trans: add kube-controller-manager.md * Update kube-controller-manager.md * Update kube-controller-manager.md * Update kube-controller-manager.md * zh-trans: /docs/contribute/localization.md (#12295) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/localization.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/localization.md; update2 Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * ZH-trans: update tools.md (#12320) ZH-trans: update tools.md * ZH-trans: fix "kubead -config" -> "kubeadm-config" (#12319) * ZH-trans: update kubeadm_config.md * fix style error * correct "availability” trans for chinese (#12394) * ZH-trans:/docs/tasks/debug-application-cluster/debug-service.md (#12275) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * Translate some remnant partials for localization (#12240) * zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md (#12415) * zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md zh-trans: /docs/tasks/administer-cluster/limit-storage-consumption.md * Update limit-storage-consumption.md * Update limit-storage-consumption.md * update link to SSH tunneling (#12615) Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans: update content/zh/docs/setup/certificates.md (#12620) * ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md (#12619) * ZH-trans: add kubeadm_alpha_phase_certs_apiserver-kubelet-client.md * Update kubeadm_alpha_phase_certs_apiserver-kubelet-client.md * zh-trans: node-conformance.md (#12356) * zh-trans: node-conformance.md zh-trans: node-conformance.md * better translation better translation * zh-trans: translate docs/getting-started-guides/ubuntu/operational-co… (#12353) * zh-trans: translate docs/getting-started-guides/ubuntu/operational-considerations.md * Adopt PR suggestions * add period sign * zh-trans: krib.md (#12363) * zh-trans: krib.md zh-trans: krib.md * Update krib.md * Update krib.md * Update krib.md * Update krib.md * zh-trans: /docs/tasks/administer-federation/events.md (#12411) * zh-trans: /docs/tasks/administer-federation/events.md zh-trans: /docs/tasks/administer-federation/events.md * Update events.md * Update events.md * zh-trans: /docs/setup/turnkey/azure.md (#12412) zh-trans: /docs/setup/turnkey/azure.md * zh-trans:/docs/tasks/administer-federation/hpa.md & /docs/tasks/administer-cluster/extended-resource-node.md (#12432) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * Add arm64, ppc64le and s390x platforms for calico (#12666) Signed-off-by: PingWang <wang.ping5@zte.com.cn> add only Signed-off-by: PingWang <wang.ping5@zte.com.cn> * zh-trans: developing-cloud-controller-manager.md (#12413) * zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md zh-trans: /docs/tasks/administer-cluster/developing-cloud-controller-manager.md * Update developing-cloud-controller-manager.md * fix typo: delete useless "**" * Update developing-cloud-controller-manager.md * ZH-trans: add 2018-05-01-developing-on-kubernetes.md (#12814) * ZH-trans: update encrypt-data.md (#12939) * ZH-trans: update encrypt-data.md * Update encrypt-data.md * ZH-trans: add example-task-template.md (#12940) * ZH-trans: add example-task-template.md * Update example-task-template.md * Added Instana to tools (#12978) Instana is already available in the english version of the text, therefore I added it here too. Hope my skills were enough to make the text still correct :-) * ZH-trans: add expose-interactive.html (#12965) * ZH-trans: add expose-interactive.html * Update content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html Co-Authored-By: xichengliudui <1693291525@qq.com> * ZH-trans: add cloudstack.md (#12967) * Create cloudstack.md * Update cloudstack.md * Update cloudstack.md * Update cloudstack.md * ZH-trans: add container-lifecycle-hooks.md (#12941) * ZH-trans: add container-lifecycle-hooks.md * Update container-lifecycle-hooks.md * translate content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md to chinese (#12904) * ZH-trans: add expose-external-ip-address.md (#12955) * ZH-trans: add expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * Update expose-external-ip-address.md * ZH-trans: add dns-horizontal-autoscaling.md (#12948) * ZH-trans: add dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * zh-trans: update content/zh/docs/concepts/_index.md (#13182) * zh-trans: update content/zh/docs/reference/access-authn-authz/node.md (#13181) * Update dns-horizontal-autoscaling.md (#13119) * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * Update dns-horizontal-autoscaling.md * ZH-trans: add 2018-10-03-kubedirector.md (#13048) * ZH-trans: add 2018-10-03-kubedirector.md * Update 2018-10-03-kubedirector.md * Update 2018-10-03-kubedirector.md * ZH-trans: add guestbook.md (#12953) * ZH-trans: add guestbook.md * Update guestbook.md * Update guestbook.md * Update guestbook.md * Update guestbook.md * ZH-trans: add set-up-placement-policies-federation.md (#12947) * ZH-trans: add set-up-placement-policies-federation.md * update pull request * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * Update set-up-placement-policies-federation.md * ZH-trans: add service-accounts-admin.md (#13047) * ZH-trans: add service-accounts-admin.md * Update service-accounts-admin.md * Update service-accounts-admin.md * ZH-trans: add update-api-object-kubectl-patch.md (#12943) * ZH-trans: add update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * Update update-api-object-kubectl-patch.md * ZH-trans: add parallel-processing-expansion.md (#12944) * ZH-trans: add parallel-processing-expansion.md * Update parallel-processing-expansion.md * Update parallel-processing-expansion.md * zh-trans: add 2018-12-05-new-contributor-shanghai.md (#12778) * add zh 2017-03-00-Five-Days-Of-Kubernetes-1-6.md add zh 2018-12-05-new-contributor-shanghai.md * Delete 2017-03-00-Five-Days-Of-Kubernetes-1-6.md * zh-trans: /docs/contribute/style/write-new-topic.md (#12572) Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/style/write-new-topic.md; update Signed-off-by: liyuan198251 <li.yuan4@zte.com.cn> * zh-trans: update content/zh/docs/setup/salt.md (#13202) * zh-trans: add docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md (#13198) * ZH-trans: add kubeadm_upgrade_diff.md (#13170) * ZH-trans: add kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * Update kubeadm_upgrade_diff.md * zh-trans: update docs/reference/access-authn-authz/authorization.md (#13180) * zh-trans: update docs/reference/setup-tools/kubeadm/kubeadm-config.md (#13179) * zh-trans: add docs/concepts/storage/dynamic-provisioning.md (#13171) * ZH-trans: add 2015-05-00-Kubernetes-On-Openstack.md (#13149) * ZH-trans: add Kubernetes开源项目产品经理 * Update 2015-05-00-Kubernetes-On-Openstack.md * ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md (#13131) * ZH-trans: add 2015-03-00-Welcome-To-Kubernetes-Blog.md * Update 2015-03-00-Welcome-To-Kubernetes-Blog.md * ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md (#13123) * ZH-trans: add 2015-06-00-Slides-Cluster-Management-With.md * Update 2015-06-00-Slides-Cluster-Management-With.md * Create 2015-03-00-Kubernetes-Gathering-Videos.md (#13124) * ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md (#13129) * ZH-trans: add 2015-03-00-Weekly-Kubernetes-Community-Hangout.md * Update 2015-03-00-Weekly-Kubernetes-Community-Hangout.md * ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md (#13130) * ZH-trans: add 2015-04-00-Kubernetes-Release-0150.md * Update 2015-04-00-Kubernetes-Release-0150.md * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md (#13132) * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * Update 2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md * ZH-trans: add 2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md (#13147) * ZH-trans: add 2015-05-00-Weekly-Kubernetes-Community-Hangout.md (#13148) * ZH-trans: add flannel_multi_node_cluster.md (#13195) * ZH-trans: add flannel_multi_node_cluster.md * Update flannel_multi_node_cluster.md * Update flannel_multi_node_cluster.md * zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md (#13200) * zh-trans: add docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md * Update kubelet-authentication-authorization.md * zh-trans: /docs/tasks/administer-cluster/out-of-resource.md (#12879) * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * . * . * zh-trans: update docs/setup/node-conformance.md (#13201) * zh-trans: update docs/setup/node-conformance.md * zh-trans: update docs/setup/on-premises-vm/dcos.md * zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md (#13227) * zh-trans: add content/zh/blog/_posts/2018-10-15-steering-election-results.md * Update content/zh/blog/_posts/2018-10-15-steering-election-results.md Co-Authored-By: SataQiu <1527062125@qq.com> * Add @xichengliudui to sig-docs-zh-owners (release-1.12) (#13167) * Add @xichengliudui to sig-docs-zh-owners * Update OWNERS_ALIASES * ZH-trans: add coreos.md (#13193) * ZH-trans: coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * Update coreos.md * add SataQiu as a sig-docs-zh-owner (#13271) * Fix relative links issue in zh content (#13312) * `http://kubernetes.io/docs/` -> `/docs/` * `https://kubernetes.io/docs/` -> `/docs/` * zh-trans: add docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md (#13194) * zh-trans: add docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md * Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update kubeadm-upgrade.md * ZH-trans: add kubeadm-upgrade-ha-1-12.md (#13306) * ZH-trans: add kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update kubeadm-upgrade-ha-1-12.md * Update config.toml (#13408) * zh-trans: add content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md (#13221) * zh-trans: add content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md (#13236) * zh-trans: add content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md (#13274) * zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md (#13268) * zh-trans: add content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md * ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13427) * ZH-trans: add 2017-10-00-Five-Days-Of-Kubernetes-18.md * Update 2017-10-00-Five-Days-Of-Kubernetes-18.md * zh-trans: add content/zh/docs/tasks/administer-federation/daemonset.md (#13239) * message * more message * remove data.json * ZH-trans: add aws.md (#13276) * ZH-trans: add aws.md * Update aws.md * Update aws.md * ZH-trans: add cluster-interactive.html (#13479) * ZH-trans: add cluster-interactive.html * Update cluster-interactive.html * ZH-trans: add update-intro.html (#13480) * Create update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * Update update-intro.html * ZH-trans: add README.md (#13235) * ZH-trans: add vendoring * Update README.md * zh: docs/cocepts/cluster-administration/logging.md (#13541) * zh: docs/cocepts/cluster-administration/logging.md * Update logging.md * zh-trans: update docker-cli-to-kubectl.md (#13591) * Update docker-cli-to-kubectl.md * Update docker-cli-to-kubectl.md * zh-trans: update advanced.md (#13592) * ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md (#13424) * ZH-trans: add 2017-11-00-Autoscaling-In-Kubernetes.md * Update 2017-11-00-Autoscaling-In-Kubernetes.md * ZH-trans: add fedora_manual_config.md (#13439) * ZH-trans: add fedora_manual_config.md * Update fedora_manual_config.md * zh-trans: content/zh/docs/concepts/overview/working-with-objects/labe… (#12277) * zh-trans: content/zh/docs/concepts/overview/working-with-objects/labels.md * update trans * update trans * zh: docs/contribute/start.md trans (#13632) * zh：docs/contribute/start.md trans * Update start.md * Update start.md * Update start.md * Update start.md * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * Update content/zh/docs/contribute/start.md Co-Authored-By: zhangqx2010 <zhangqx2010@users.noreply.github.com> * zh-trans: update docs/reference/setup-tools/kubefed (#13729) * Update 2017-10-00-Five-Days-Of-Kubernetes-18.md (#13472) * zh-trans: add configure-multiple-schedulers.md (#13492) * zh-trans: add configure-multiple-schedulers.md * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update configure-multiple-schedulers.md * Update configure-multiple-schedulers.md * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update configure-multiple-schedulers.md * zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md (#13551) * zh-trans: add docs/tasks/configure-pod-container/share-process-namespace.md * Update share-process-namespace.md * zh-trans: update docs/admin/accessing-the-api.md (#13744) * zh-trans: add content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md (#13303) * ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md (#13241) * ZH-trans: add 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * Update 2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md * ZH-trans: add 2016-07-00-Citrix-Netscaler-And-Kubernetes.md (#13242) * ZH-trans: add 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * Update 2016-07-00-Citrix-Netscaler-And-Kubernetes.md * zh-trans: update docs/admin/bootstrap-tokens.md (#13770) * zh-trans: update content/zh/docs/admin/cluster-large.md (#13771) * zh-trans: update content/zh/docs/admin/kube-apiserver.md (#13774) * zh-trans: update content/zh/docs/admin/kube-apiserver.md * Update kube-apiserver.md * Update content/zh/docs/admin/kube-apiserver.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/admin/multiple-zones.md (#13775) * zh-trans: update content/zh/docs/admin/multiple-zones.md * Update multiple-zones.md * zh-trans: update node-conformance.md and ovs-networking.md (#13776) * zh-trans: update high-availability/_index.md and authorization/webhook.md (#13780) * zh-trans: update content/zh/docs/admin/authorization/_index.md (#13779) * zh-trans: update content/zh/docs/admin/authorization/_index.md * Update _index.md * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update content/zh/docs/admin/authorization/_index.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/admin/authorization/abac.md (#13777) * zh-trans: update content/zh/docs/admin/authorization/abac.md * Update content/zh/docs/admin/authorization/abac.md Co-Authored-By: SataQiu <1527062125@qq.com> * Update abac.md * zh-trans: update content/zh/docs/admin/service-accounts-admin.md (#13778) * zh-trans: update content/zh/docs/admin/service-accounts-admin.md * Update content/zh/docs/admin/service-accounts-admin.md Co-Authored-By: SataQiu <1527062125@qq.com> * zh-trans: update content/zh/docs/concepts/architecture (#13797) * ZH-trans: add cluster.md (#13500) * ZH-trans: add cluster.md * Update cluster.md * Update cluster.md * Update cluster.md * zh-trans: update docs/concepts/cluster-administration (#13825) * Exclude content-en changes in the PR * Exclude content/ko changes in the PR * Exclude OWNERS_ALIASES change in the PR * rm kubeadm/generated/README.md to fix the build * Remove generated sass assets
This commit is contained in:
chenrui
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
d437c2e5e5
commit
577b431931
Binary file not shown.
|
After Width: | Height: | Size: 1.9 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.0 KiB |
@@ -0,0 +1,3 @@
|
||||
---
|
||||
headless: true
|
||||
---
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "生产级别的容器编排系统"
|
||||
abstract: "自动化的容器部署、扩展和管理"
|
||||
cid: "home"
|
||||
cid: home
|
||||
---
|
||||
|
||||
<section id="oceanNodes">
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
|
||||
title: " Kubernetes 采集视频 "
|
||||
date: 2015-03-23
|
||||
slug: kubernetes-gathering-videos
|
||||
url: /blog/2015/03/Kubernetes-Gathering-Videos
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
|
||||
title: " Kubernetes Gathering Videos "
|
||||
date: 2015-03-23
|
||||
slug: kubernetes-gathering-videos
|
||||
url: /blog/2015/03/Kubernetes-Gathering-Videos
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
If you missed the Kubernetes Gathering in SF last month, fear not! Here are the videos from the evening presentations organized into a playlist on YouTube
|
||||
|
||||
[](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe)
|
||||
-->
|
||||
|
||||
如果你错过了上个月在旧金山举行的 Kubernetes 大会，不要害怕!以下是在 YouTube 上组织成播放列表的晚间演示文稿中的视频。
|
||||
|
||||
[](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe)
|
||||
@@ -0,0 +1,186 @@
|
||||
---
|
||||
title: " Kubernetes 社区每周聚会笔记 - 2015年3月27日 "
|
||||
date: 2015-03-28
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Weekly Kubernetes Community Hangout Notes - March 27 2015 "
|
||||
date: 2015-03-28
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
|
||||
-->
|
||||
每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
|
||||
|
||||
<!--
|
||||
Agenda:
|
||||
-->
|
||||
日程安排：
|
||||
|
||||
<!--
|
||||
|
||||
\- Andy - demo remote execution and port forwarding
|
||||
|
||||
\- Quinton - Cluster federation - Postponed
|
||||
|
||||
\- Clayton - UI code sharing and collaboration around Kubernetes
|
||||
|
||||
-->
|
||||
|
||||
\- Andy - 演示远程执行和端口转发
|
||||
|
||||
\- Quinton - 联邦集群 - 延迟
|
||||
|
||||
\- Clayton - 围绕 Kubernetes 的 UI 代码共享和协作
|
||||
|
||||
<!--
|
||||
Notes from meeting:
|
||||
-->
|
||||
从会议指出：
|
||||
|
||||
<!--
|
||||
|
||||
1\. Andy from RedHat:
|
||||
|
||||
-->
|
||||
|
||||
1\. Andy 从 RedHat：
|
||||
|
||||
<!--
|
||||
|
||||
* Demo remote execution
|
||||
|
||||
-->
|
||||
|
||||
* 演示远程执行
|
||||
|
||||
<!--
|
||||
|
||||
* kubectl exec -p $POD -- $CMD
|
||||
|
||||
* Makes a connection to the master as proxy, figures out which node the pod is on, proxies connection to kubelet, which does the interesting bit. via nsenter.
|
||||
|
||||
* Multiplexed streaming over HTTP using SPDY
|
||||
|
||||
* Also interactive mode:
|
||||
|
||||
* Assumes first container. Can use -c $CONTAINER to pick a particular one.
|
||||
|
||||
* If have gdb pre-installed in container, then can interactively attach it to running process
|
||||
|
||||
* backtrace, symbol tbles, print, etc. Most things you can do with gdb.
|
||||
|
||||
* Can also with careful flag crafting run rsync over this or set up sshd inside container.
|
||||
|
||||
* Some feedback via chat:
|
||||
|
||||
-->
|
||||
|
||||
* kubectl exec -p $POD -- $CMD
|
||||
|
||||
* 作为代理与主机建立连接，找出 pod 所在的节点，代理与 kubelet 的连接，这一点很有趣。通过 nsenter。
|
||||
|
||||
* 使用 SPDY 通过 HTTP 进行多路复用流式传输
|
||||
|
||||
* 还有互动模式：
|
||||
|
||||
* 假设第一个容器，可以使用 -c $CONTAINER 一个特定的。
|
||||
|
||||
* 如果在容器中预先安装了 gdb，则可以交互地将其附加到正在运行的进程中
|
||||
|
||||
* backtrace、symbol tbles、print 等。 使用gdb可以做的大多数事情。
|
||||
|
||||
* 也可以用精心制作的参数在上面运行 rsync 或者在容器内设置 sshd。
|
||||
|
||||
* 一些聊天反馈：
|
||||
|
||||
<!--
|
||||
|
||||
* Andy also demoed port forwarding
|
||||
* nsenter vs. docker exec
|
||||
|
||||
-->
|
||||
|
||||
* Andy 还演示了端口转发
|
||||
* nnsenter 与 docker exec
|
||||
|
||||
<!--
|
||||
|
||||
* want to inject a binary under control of the host, similar to pre-start hooks
|
||||
|
||||
* socat, nsenter, whatever the pre-start hook needs
|
||||
|
||||
-->
|
||||
|
||||
* 想要在主机的控制下注入二进制文件，类似于预启动钩子
|
||||
|
||||
* socat、nsenter，任何预启动钩子需要的
|
||||
|
||||
<!--
|
||||
|
||||
* would be nice to blog post on this
|
||||
* version of nginx in wheezy is too old to support needed master-proxy functionality
|
||||
|
||||
-->
|
||||
|
||||
* 如果能在博客上发表这方面的文章就太好了
|
||||
* wheezy 中的 nginx 版本太旧，无法支持所需的主代理功能
|
||||
|
||||
<!--
|
||||
|
||||
2\. Clayton: where are we wrt a community organization for e.g. kubernetes UI components?
|
||||
|
||||
* google-containers-ui IRC channel, mailing list.
|
||||
* Tim: google-containers prefix is historical, should just do "kubernetes-ui"
|
||||
* also want to put design resources in, and bower expects its own repo.
|
||||
* General agreement
|
||||
|
||||
-->
|
||||
|
||||
2\. Clayton: 我们的社区组织在哪里，例如 kubernetes UI 组件？
|
||||
|
||||
* google-containers-ui IRC 频道，邮件列表。
|
||||
* Tim: google-containers 前缀是历史的，应该只做 "kubernetes-ui"
|
||||
* 也希望将设计资源投入使用，并且 bower 期望自己的仓库。
|
||||
* 通用协议
|
||||
|
||||
<!--
|
||||
|
||||
3\. Brian Grant:
|
||||
|
||||
* Testing v1beta3, getting that ready to go in.
|
||||
* Paul working on changes to commandline stuff.
|
||||
* Early to mid next week, try to enable v1beta3 by default?
|
||||
* For any other changes, file issue and CC thockin.
|
||||
|
||||
-->
|
||||
|
||||
3\. Brian Grant:
|
||||
|
||||
* 测试 v1beta3，准备进入。
|
||||
* Paul 力于改变命令行的内容。
|
||||
* 下周初至中旬，尝试默认启用v1beta3 ?
|
||||
* 对于任何其他更改，请发出文件并抄送 thockin。
|
||||
|
||||
<!--
|
||||
|
||||
4\. General consensus that 30 minutes is better than 60
|
||||
|
||||
-->
|
||||
|
||||
4\. 一般认为30分钟比60分钟好
|
||||
|
||||
<!--
|
||||
|
||||
* Shouldn't artificially try to extend just to fill time.
|
||||
|
||||
-->
|
||||
|
||||
* 不应该为了填满时间而人为地延长。
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: 欢迎来到 Kubernetes 博客!
|
||||
date: 2015-03-20
|
||||
slug: welcome-to-kubernetes-blog
|
||||
url: /blog/2015/03/Welcome-To-Kubernetes-Blog
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Welcome to the Kubernetes Blog!
|
||||
date: 2015-03-20
|
||||
slug: welcome-to-kubernetes-blog
|
||||
url: /blog/2015/03/Welcome-To-Kubernetes-Blog
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Welcome to the new Kubernetes Blog. Follow this blog to learn about the Kubernetes Open Source project. We plan to post release notes, how-to articles, events, and maybe even some off topic fun here from time to time.
|
||||
-->
|
||||
欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划不时发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。
|
||||
|
||||
<!--
|
||||
If you are using Kubernetes or contributing to the project and would like to do a guest post, [please let me know](mailto:kitm@google.com).
|
||||
-->
|
||||
如果您正在使用 Kubernetes 或为该项目做出贡献并想要发帖子，[请告诉我](mailto:kitm@google.com)。
|
||||
|
||||
<!--
|
||||
To start things off, here's a roundup of recent Kubernetes posts from other sites:
|
||||
-->
|
||||
首先，以下是 Kubernetes 最近在其他网站上发布的文章摘要：
|
||||
|
||||
<!--
|
||||
- [Scaling MySQL in the cloud with Vitess and Kubernetes](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html)
|
||||
- [Container Clusters on VMs](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
|
||||
- [Everything you wanted to know about Kubernetes but were afraid to ask](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html)
|
||||
- [What makes a container cluster?](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html)
|
||||
- [Integrating OpenStack and Kubernetes with Murano](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/)
|
||||
- [An introduction to containers, Kubernetes, and the trajectory of modern cloud computing](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html)
|
||||
- [What is Kubernetes and how to use it?](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/)
|
||||
- [OpenShift V3, Docker and Kubernetes Strategy](https://blog.openshift.com/v3-docker-kubernetes-interview/)
|
||||
- [An Introduction to Kubernetes](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes)
|
||||
-->
|
||||
|
||||
- [使用 Vitess 和 Kubernetes 在云中扩展 MySQL](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html)
|
||||
- [虚拟机上的容器群集](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
|
||||
- [想知道的关于 kubernetes 的一切，却又不敢问](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html)
|
||||
- [什么构成容器集群？](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html)
|
||||
- [将 OpenStack 和 Kubernetes 与 Murano 集成](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/)
|
||||
- [容器介绍，Kubernetes 以及现代云计算的发展轨迹](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html)
|
||||
- [什么是 Kubernetes 以及如何使用它？](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/)
|
||||
- [OpenShift V3，Docker 和 Kubernetes 策略](https://blog.openshift.com/v3-docker-kubernetes-interview/)
|
||||
- [Kubernetes 简介](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes)
|
||||
|
||||
<!--
|
||||
Happy cloud computing!
|
||||
-->
|
||||
快乐的云计算！
|
||||
|
||||
<!--
|
||||
- Kit Merker - Product Manager, Google Cloud Platform
|
||||
-->
|
||||
- Kit Merker - Google 云平台产品经理
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
title: " Kubernetes Release: 0.15.0 "
|
||||
date: 2015-04-16
|
||||
slug: kubernetes-release-0150
|
||||
url: /blog/2015/04/Kubernetes-Release-0150
|
||||
---
|
||||
|
||||
<!--
|
||||
Release Notes:
|
||||
-->
|
||||
|
||||
Release 说明：
|
||||
|
||||
<!--
|
||||
|
||||
* Enables v1beta3 API and sets it to the default API version ([#6098][1])
|
||||
* Added multi-port Services ([#6182][2])
|
||||
* New Getting Started Guides
|
||||
* Multi-node local startup guide ([#6505][3])
|
||||
* Mesos on Google Cloud Platform ([#5442][4])
|
||||
* Ansible Setup instructions ([#6237][5])
|
||||
* Added a controller framework ([#5270][6], [#5473][7])
|
||||
* The Kubelet now listens on a secure HTTPS port ([#6380][8])
|
||||
* Made kubectl errors more user-friendly ([#6338][9])
|
||||
* The apiserver now supports client cert authentication ([#6190][10])
|
||||
* The apiserver now limits the number of concurrent requests it processes ([#6207][11])
|
||||
* Added rate limiting to pod deleting ([#6355][12])
|
||||
* Implement Balanced Resource Allocation algorithm as a PriorityFunction in scheduler package ([#6150][13])
|
||||
* Enabled log collection from master ([#6396][14])
|
||||
* Added an api endpoint to pull logs from Pods ([#6497][15])
|
||||
* Added latency metrics to scheduler ([#6368][16])
|
||||
* Added latency metrics to REST client ([#6409][17])
|
||||
|
||||
-->
|
||||
|
||||
* 启用 1beta3 API 并将其设置为默认 API 版本 ([#6098][1])
|
||||
* 增加了多端口服务([#6182][2])
|
||||
* 新入门指南
|
||||
* 多节点本地启动指南 ([#6505][3])
|
||||
* Google 云平台上的 Mesos ([#5442][4])
|
||||
* Ansible 安装说明 ([#6237][5])
|
||||
* 添加了一个控制器框架 ([#5270][6], [#5473][7])
|
||||
* Kubelet 现在监听一个安全的 HTTPS 端口 ([#6380][8])
|
||||
* 使 kubectl 错误更加友好 ([#6338][9])
|
||||
* apiserver 现在支持客户端 cert 身份验证 ([#6190][10])
|
||||
* apiserver 现在限制了它处理的并发请求的数量 ([#6207][11])
|
||||
* 添加速度限制删除 pod ([#6355][12])
|
||||
* 将平衡资源分配算法作为优先级函数实现在调度程序包中 ([#6150][13])
|
||||
* 从主服务器启用日志收集功能 ([#6396][14])
|
||||
* 添加了一个 api 端口来从 Pod 中提取日志 ([#6497][15])
|
||||
* 为调度程序添加了延迟指标 ([#6368][16])
|
||||
* 为 REST 客户端添加了延迟指标 ([#6409][17])
|
||||
|
||||
<!--
|
||||
|
||||
* etcd now runs in a pod on the master ([#6221][18])
|
||||
* nginx now runs in a container on the master ([#6334][19])
|
||||
* Began creating Docker images for master components ([#6326][20])
|
||||
* Updated GCE provider to work with gcloud 0.9.54 ([#6270][21])
|
||||
* Updated AWS provider to fix Region vs Zone semantics ([#6011][22])
|
||||
* Record event when image GC fails ([#6091][23])
|
||||
* Add a QPS limiter to the kubernetes client ([#6203][24])
|
||||
* Decrease the time it takes to run make release ([#6196][25])
|
||||
* New volume support
|
||||
* Added iscsi volume plugin ([#5506][26])
|
||||
* Added glusterfs volume plugin ([#6174][27])
|
||||
* AWS EBS volume support ([#5138][28])
|
||||
* Updated to heapster version to v0.10.0 ([#6331][29])
|
||||
* Updated to etcd 2.0.9 ([#6544][30])
|
||||
* Updated to Kibana to v1.2 ([#6426][31])
|
||||
* Bug Fixes
|
||||
* Kube-proxy now updates iptables rules if a service's public IPs change ([#6123][32])
|
||||
* Retry kube-addons creation if the initial creation fails ([#6200][33])
|
||||
* Make kube-proxy more resiliant to running out of file descriptors ([#6727][34])
|
||||
|
||||
-->
|
||||
|
||||
* etcd 现在在 master 上的一个 pod 中运行 ([#6221][18])
|
||||
* nginx 现在在 master上的容器中运行 ([#6334][19])
|
||||
* 开始为主组件构建 Docker 镜像 ([#6326][20])
|
||||
* 更新了 GCE 程序以使用 gcloud 0.9.54 ([#6270][21])
|
||||
* 更新了 AWS 程序来修复区域与区域语义 ([#6011][22])
|
||||
* 记录镜像 GC 失败时的事件 ([#6091][23])
|
||||
* 为 kubernetes 客户端添加 QPS 限制器 ([#6203][24])
|
||||
* 减少运行 make release 所需的时间 ([#6196][25])
|
||||
* 新卷的支持
|
||||
* 添加 iscsi 卷插件 ([#5506][26])
|
||||
* 添加 glusterfs 卷插件 ([#6174][27])
|
||||
* AWS EBS 卷支持 ([#5138][28])
|
||||
* 更新到 heapster 版本到 v0.10.0 ([#6331][29])
|
||||
* 更新到 etcd 2.0.9 ([#6544][30])
|
||||
* 更新到 Kibana 到 v1.2 ([#6426][31])
|
||||
* 漏洞修复
|
||||
* 如果服务的公共 IP 发生变化，Kube-proxy现在会更新iptables规则 ([#6123][32])
|
||||
* 如果初始创建失败，则重试 kube-addons 创建 ([#6200][33])
|
||||
* 使 kube-proxy 对耗尽文件描述符更具弹性 ([#6727][34])
|
||||
|
||||
<!--
|
||||
To download, please visit https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0
|
||||
-->
|
||||
要下载，请访问 https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0
|
||||
|
||||
<!--
|
||||
[1]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6098 "Enabling v1beta3 api version by default in master"
|
||||
[2]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6182 "Implement multi-port Services"
|
||||
[3]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6505 "Docker multi-node"
|
||||
[4]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5442 "Getting started guide for Mesos on Google Cloud Platform"
|
||||
[5]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6237 "example ansible setup repo"
|
||||
[6]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5270 "Controller framework"
|
||||
[7]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5473 "Add DeltaFIFO (a controller framework piece)"
|
||||
[8]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6380 "Configure the kubelet to use HTTPS (take 2)"
|
||||
[9]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6338 "Return a typed error for config validation, and make errors simple"
|
||||
[10]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6190 "Add client cert authentication"
|
||||
[11]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6207 "Add a limit to the number of in-flight requests that a server processes."
|
||||
[12]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6355 "Added rate limiting to pod deleting"
|
||||
[13]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6150 "Implement Balanced Resource Allocation (BRA) algorithm as a PriorityFunction in scheduler package."
|
||||
[14]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6396 "Enable log collection from master."
|
||||
[15]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6497 "Pod log subresource"
|
||||
[16]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6368 "Add basic latency metrics to scheduler."
|
||||
[17]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6409 "Add latency metrics to REST client"
|
||||
[18]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6221 "Run etcd 2.0.5 in a pod"
|
||||
[19]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6334 "Add an nginx docker image for use on the master."
|
||||
[20]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6326 "Create Docker images for master components "
|
||||
[21]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6270 "Updates for gcloud 0.9.54"
|
||||
-->
|
||||
[1]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6098 "在 master 中默认启用 v1beta3 api 版本"
|
||||
[2]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6182 "实现多端口服务"
|
||||
[3]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6505 "Docker 多节点"
|
||||
[4]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5442 "谷歌云平台上 Mesos 入门指南"
|
||||
[5]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6237 "示例 ansible 设置仓库"
|
||||
[6]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5270 "控制器框架"
|
||||
[7]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5473 "添加 DeltaFIFO（控制器框架块）"
|
||||
[8]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6380 "将 kubelet 配置为使用 HTTPS (获得 2)"
|
||||
[9]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6338 "返回用于配置验证的类型化错误，并简化错误"
|
||||
[10]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6190 "添加客户端证书认证"
|
||||
[11]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6207 "为服务器处理的正在运行的请求数量添加一个限制。"
|
||||
[12]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6355 "添加速度限制删除 pod"
|
||||
[13]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6150 "将均衡资源分配算法作为优先级函数实现在调度程序包中。"
|
||||
[14]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6396 "启用主服务器收集日志。"
|
||||
[15]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6497 "pod 子日志资源"
|
||||
[16]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6368 "将基本延迟指标添加到调度程序。"
|
||||
[17]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6409 "向 REST 客户端添加延迟指标"
|
||||
[18]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6221 "在 pod 中运行 etcd 2.0.5"
|
||||
[19]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6334 "添加一个 nginx docker 镜像用于主程序。"
|
||||
[20]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6326 "为主组件创建 Docker 镜像"
|
||||
[21]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6270 "gcloud 0.9.54 的更新"
|
||||
|
||||
<!--
|
||||
[22]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6011 "Fix AWS region vs zone"
|
||||
[23]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6091 "Record event when image GC fails."
|
||||
[24]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6203 "Add a QPS limiter to the kubernetes client."
|
||||
[25]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6196 "Parallelize architectures in both the building and packaging phases of `make release`"
|
||||
[26]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5506 "add iscsi volume plugin"
|
||||
[27]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6174 "implement glusterfs volume plugin"
|
||||
[28]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5138 "AWS EBS volume support"
|
||||
[29]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6331 "Update heapster version to v0.10.0"
|
||||
[30]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6544 "Build etcd image (version 2.0.9), and upgrade kubernetes cluster to the new version"
|
||||
[31]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6426 "Update Kibana to v1.2 which paramaterizes location of Elasticsearch"
|
||||
[32]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6123 "Fix bug in kube-proxy of not updating iptables rules if a service's public IPs change"
|
||||
[33]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6200 "Retry kube-addons creation if kube-addons creation fails."
|
||||
[34]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6727 "pkg/proxy: panic if run out of fd"
|
||||
-->
|
||||
[22]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6011 "修复 AWS 区域 与 zone"
|
||||
[23]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6091 "记录镜像 GC 失败时的事件。"
|
||||
[24]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6203 "向 kubernetes 客户端添加 QPS 限制器。"
|
||||
[25]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6196 "在 `make release` 的构建和打包阶段并行化架构"
|
||||
[26]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5506 "添加 iscsi 卷插件"
|
||||
[27]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6174 "实现 glusterfs 卷插件"
|
||||
[28]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5138 "AWS EBS 卷支持"
|
||||
[29]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6331 "将 heapster 版本更新到 v0.10.0"
|
||||
[30]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6544 "构建 etcd 镜像(版本 2.0.9)，并将 kubernetes 集群升级到新版本"
|
||||
[31]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6426 "更新 Kibana 到 v1.2，它对 Elasticsearch 的位置进行了参数化"
|
||||
[32]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6123 "修复了 kube-proxy 中的一个错误，如果一个服务的公共 ip 发生变化，它不会更新 iptables 规则"
|
||||
[33]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6200 "如果 kube-addons 创建失败，请重试 kube-addons 创建。"
|
||||
[34]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6727 "pkg/proxy: fd 用完后引起恐慌"
|
||||
|
||||
@@ -0,0 +1,287 @@
|
||||
---
|
||||
title: " Kubernetes 社区每周聚会笔记- 2015年4月17日 "
|
||||
date: 2015-04-17
|
||||
slug: weekly-kubernetes-community-hangout_17
|
||||
url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Weekly Kubernetes Community Hangout Notes - April 17 2015 "
|
||||
date: 2015-04-17
|
||||
slug: weekly-kubernetes-community-hangout_17
|
||||
url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
|
||||
-->
|
||||
每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
|
||||
|
||||
<!--
|
||||
Agenda
|
||||
|
||||
* Mesos Integration
|
||||
* High Availability (HA)
|
||||
* Adding performance and profiling details to e2e to track regressions
|
||||
* Versioned clients
|
||||
|
||||
-->
|
||||
议程
|
||||
|
||||
* Mesos 集成
|
||||
* 高可用性（HA）
|
||||
* 向 e2e 添加性能和分析详细信息以跟踪回归
|
||||
* 客户端版本化
|
||||
|
||||
<!--
|
||||
Notes
|
||||
-->
|
||||
笔记
|
||||
|
||||
<!--
|
||||
|
||||
* Mesos integration
|
||||
|
||||
* Mesos integration proposal:
|
||||
|
||||
* No blockers to integration.
|
||||
|
||||
* Documentation needs to be updated.
|
||||
|
||||
-->
|
||||
|
||||
* Mesos 集成
|
||||
|
||||
* Mesos 集成提案：
|
||||
|
||||
* 没有阻塞集成的因素。
|
||||
|
||||
* 文档需要更新。
|
||||
|
||||
<!--
|
||||
|
||||
* HA
|
||||
|
||||
* Proposal should land today.
|
||||
|
||||
* Etcd cluster.
|
||||
|
||||
* Load-balance apiserver.
|
||||
|
||||
* Cold standby for controller manager and other master components.
|
||||
|
||||
-->
|
||||
|
||||
* HA
|
||||
|
||||
* 提案今天应该会提交。
|
||||
|
||||
* Etcd 集群。
|
||||
|
||||
* apiserver 负载均衡。
|
||||
|
||||
* 控制器管理器和其他主组件的冷备用。
|
||||
|
||||
<!--
|
||||
|
||||
* Adding performance and profiling details to e2e to track regression
|
||||
|
||||
* Want red light for performance regression
|
||||
|
||||
* Need a public DB to post the data
|
||||
|
||||
* See
|
||||
|
||||
* Justin working on multi-platform e2e dashboard
|
||||
|
||||
-->
|
||||
|
||||
* 向 e2e 添加性能和分析详细信息以跟踪回归
|
||||
|
||||
* 希望红色为性能回归
|
||||
|
||||
* 需要公共数据库才能发布数据
|
||||
|
||||
* 查看
|
||||
|
||||
* Justin 致力于多平台 e2e 仪表盘
|
||||
|
||||
<!--
|
||||
|
||||
* Versioned clients
|
||||
|
||||
*
|
||||
|
||||
*
|
||||
|
||||
* Client library currently uses internal API objects.
|
||||
|
||||
* Nobody reported that frequent changes to types.go have been painful, but we are worried about it.
|
||||
|
||||
* Structured types are useful in the client. Versioned structs would be ok.
|
||||
|
||||
* If start with json/yaml (kubectl), shouldn’t convert to structured types. Use swagger.
|
||||
|
||||
-->
|
||||
|
||||
* 客户端版本化
|
||||
|
||||
*
|
||||
|
||||
*
|
||||
|
||||
* 客户端库当前使用内部 API 对象。
|
||||
|
||||
* 尽管没有人反映频繁修改 `types.go` 有多痛苦，但我们很为此担心。
|
||||
|
||||
* 结构化类型在客户端中很有用。版本化的结构就可以了。
|
||||
|
||||
* 如果从 json/yaml (kubectl) 开始，则不应转换为结构化类型。使用 swagger。
|
||||
|
||||
<!--
|
||||
|
||||
* Security context
|
||||
|
||||
*
|
||||
|
||||
* Administrators can restrict who can run privileged containers or require specific unix uids
|
||||
|
||||
* Kubelet will be able to get pull credentials from apiserver
|
||||
|
||||
* Policy proposal coming in the next week or so
|
||||
-->
|
||||
|
||||
* Security context
|
||||
|
||||
*
|
||||
|
||||
* 管理员可以限制谁可以运行特权容器或需要特定的 unix uid
|
||||
|
||||
* kubelet 将能够从 apiserver 获取证书
|
||||
|
||||
* 政策提案将于下周左右出台
|
||||
|
||||
<!--
|
||||
|
||||
* Discussing upstreaming of users, etc. into Kubernetes, at least as optional
|
||||
* 1.0 Roadmap
|
||||
|
||||
* Focus is performance, stability, cluster upgrades
|
||||
|
||||
* TJ has been making some edits to [roadmap.md][4] but hasn’t sent out a PR yet
|
||||
* Kubernetes UI
|
||||
|
||||
* Dependencies broken out into third-party
|
||||
|
||||
* @lavalamp is reviewer
|
||||
|
||||
-->
|
||||
|
||||
* 讨论用户的上游，等等进入Kubernetes，至少是可选的
|
||||
* 1.0 路线图
|
||||
|
||||
* 重点是性能，稳定性，集群升级
|
||||
|
||||
* TJ 一直在对[roadmap.md][4]进行一些编辑，但尚未发布PR
|
||||
* Kubernetes UI
|
||||
|
||||
* 依赖关系分解为第三方
|
||||
|
||||
* @lavalamp 是评论家
|
||||
|
||||
|
||||
[1]: http://kubernetes.io/images/nav_logo.svg
|
||||
[2]: http://kubernetes.io/docs/
|
||||
[3]: https://kubernetes.io/blog/
|
||||
[4]: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/roadmap.md
|
||||
[5]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17 "permanent link"
|
||||
[6]: https://resources.blogblog.com/img/icon18_edit_allbkg.gif
|
||||
[7]: https://www.blogger.com/post-edit.g?blogID=112706738355446097&postID=630924463010638300&from=pencil "Edit Post"
|
||||
[8]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=email "Email This"
|
||||
[9]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=blog "BlogThis!"
|
||||
[10]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=twitter "Share to Twitter"
|
||||
[11]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=facebook "Share to Facebook"
|
||||
[12]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=pinterest "Share to Pinterest"
|
||||
[13]: https://kubernetes.io/blog/search/label/community%20meetings
|
||||
[14]: https://kubernetes.io/blog/search/label/containers
|
||||
[15]: https://kubernetes.io/blog/search/label/docker
|
||||
[16]: https://kubernetes.io/blog/search/label/k8s
|
||||
[17]: https://kubernetes.io/blog/search/label/kubernetes
|
||||
[18]: https://kubernetes.io/blog/search/label/open%20source
|
||||
[19]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos "Newer Post"
|
||||
[20]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3 "Older Post"
|
||||
[21]: https://kubernetes.io/blog/feeds/630924463010638300/comments/default
|
||||
[22]: https://img2.blogblog.com/img/widgets/arrow_dropdown.gif
|
||||
[23]: https://img1.blogblog.com/img/icon_feed12.png
|
||||
[24]: https://img1.blogblog.com/img/widgets/subscribe-netvibes.png
|
||||
[25]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault
|
||||
[26]: https://img1.blogblog.com/img/widgets/subscribe-yahoo.png
|
||||
[27]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault
|
||||
[28]: https://kubernetes.io/blog/feeds/posts/default
|
||||
[29]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault
|
||||
[30]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault
|
||||
[31]: https://resources.blogblog.com/img/icon18_wrench_allbkg.png
|
||||
[32]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Subscribe&widgetId=Subscribe1&action=editWidget§ionId=sidebar-right-1 "Edit"
|
||||
[33]: https://twitter.com/kubernetesio
|
||||
[34]: https://github.com/kubernetes/kubernetes
|
||||
[35]: http://slack.k8s.io/
|
||||
[36]: http://stackoverflow.com/questions/tagged/kubernetes
|
||||
[37]: http://get.k8s.io/
|
||||
[38]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML2&action=editWidget§ionId=sidebar-right-1 "Edit"
|
||||
[39]: javascript:void(0)
|
||||
[40]: https://kubernetes.io/blog/2018/
|
||||
[41]: https://kubernetes.io/blog/2018/01/
|
||||
[42]: https://kubernetes.io/blog/2017/
|
||||
[43]: https://kubernetes.io/blog/2017/12/
|
||||
[44]: https://kubernetes.io/blog/2017/11/
|
||||
[45]: https://kubernetes.io/blog/2017/10/
|
||||
[46]: https://kubernetes.io/blog/2017/09/
|
||||
[47]: https://kubernetes.io/blog/2017/08/
|
||||
[48]: https://kubernetes.io/blog/2017/07/
|
||||
[49]: https://kubernetes.io/blog/2017/06/
|
||||
[50]: https://kubernetes.io/blog/2017/05/
|
||||
[51]: https://kubernetes.io/blog/2017/04/
|
||||
[52]: https://kubernetes.io/blog/2017/03/
|
||||
[53]: https://kubernetes.io/blog/2017/02/
|
||||
[54]: https://kubernetes.io/blog/2017/01/
|
||||
[55]: https://kubernetes.io/blog/2016/
|
||||
[56]: https://kubernetes.io/blog/2016/12/
|
||||
[57]: https://kubernetes.io/blog/2016/11/
|
||||
[58]: https://kubernetes.io/blog/2016/10/
|
||||
[59]: https://kubernetes.io/blog/2016/09/
|
||||
[60]: https://kubernetes.io/blog/2016/08/
|
||||
[61]: https://kubernetes.io/blog/2016/07/
|
||||
[62]: https://kubernetes.io/blog/2016/06/
|
||||
[63]: https://kubernetes.io/blog/2016/05/
|
||||
[64]: https://kubernetes.io/blog/2016/04/
|
||||
[65]: https://kubernetes.io/blog/2016/03/
|
||||
[66]: https://kubernetes.io/blog/2016/02/
|
||||
[67]: https://kubernetes.io/blog/2016/01/
|
||||
[68]: https://kubernetes.io/blog/2015/
|
||||
[69]: https://kubernetes.io/blog/2015/12/
|
||||
[70]: https://kubernetes.io/blog/2015/11/
|
||||
[71]: https://kubernetes.io/blog/2015/10/
|
||||
[72]: https://kubernetes.io/blog/2015/09/
|
||||
[73]: https://kubernetes.io/blog/2015/08/
|
||||
[74]: https://kubernetes.io/blog/2015/07/
|
||||
[75]: https://kubernetes.io/blog/2015/06/
|
||||
[76]: https://kubernetes.io/blog/2015/05/
|
||||
[77]: https://kubernetes.io/blog/2015/04/
|
||||
[78]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_29
|
||||
[79]: https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes
|
||||
[80]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos
|
||||
[81]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17
|
||||
[82]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3
|
||||
[83]: https://kubernetes.io/blog/2015/04/kubernetes-release-0150
|
||||
[84]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_11
|
||||
[85]: https://kubernetes.io/blog/2015/04/faster-than-speeding-latte
|
||||
[86]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout
|
||||
[87]: https://kubernetes.io/blog/2015/03/
|
||||
[88]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=BlogArchive&widgetId=BlogArchive1&action=editWidget§ionId=sidebar-right-1 "Edit"
|
||||
[89]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML1&action=editWidget§ionId=sidebar-right-1 "Edit"
|
||||
[90]: https://www.blogger.com
|
||||
[91]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Attribution&widgetId=Attribution1&action=editWidget§ionId=footer-3 "Edit"
|
||||
|
||||
[*[3:27 PM]: 2015-04-17T15:27:00-07:00
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
title: " Kubernetes 社区每周聚会笔记- 2015年4月24日 "
|
||||
date: 2015-04-30
|
||||
slug: weekly-kubernetes-community-hangout_29
|
||||
url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Weekly Kubernetes Community Hangout Notes - April 24 2015 "
|
||||
date: 2015-04-30
|
||||
slug: weekly-kubernetes-community-hangout_29
|
||||
url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
|
||||
---
|
||||
|
||||
-->
|
||||
|
||||
<!--
|
||||
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
|
||||
-->
|
||||
每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
|
||||
|
||||
<!--
|
||||
Agenda:
|
||||
|
||||
* Flocker and Kubernetes integration demo
|
||||
|
||||
-->
|
||||
日程安排：
|
||||
|
||||
* Flocker 和 Kubernetes 集成演示
|
||||
|
||||
<!--
|
||||
Notes:
|
||||
|
||||
* flocker and kubernetes integration demo
|
||||
* * Flocker Q/A
|
||||
|
||||
* Does the file still exists on node1 after migration?
|
||||
|
||||
* Brendan: Any plan this to make it a volume? So we don't need powerstrip?
|
||||
|
||||
* Luke: Need to figure out interest to decide if we want to make it a first-class persistent disk provider in kube.
|
||||
|
||||
* Brendan: Removing need for powerstrip would make it simple to use. Totally go for it.
|
||||
|
||||
* Tim: Should take no more than 45 minutes to add it to kubernetes:)
|
||||
|
||||
-->
|
||||
笔记：
|
||||
|
||||
* flocker 和 kubernetes 集成演示
|
||||
* * Flocker Q/A
|
||||
|
||||
* 迁移后文件是否仍存在于node1上？
|
||||
|
||||
* Brendan: 有没有计划把它做成一本书？我们不需要 powerstrip？
|
||||
|
||||
* Luke: 需要找出感兴趣的来决定我们是否想让它成为 kube 中的一个一流的持久性磁盘提供商。
|
||||
|
||||
* Brendan: 删除对 powerstrip 的需求会使其易于使用。完全去做。
|
||||
|
||||
* Tim: 将它添加到 kubernetes 应该不超过45分钟:)
|
||||
|
||||
<!--
|
||||
|
||||
* Derek: Contrast this with persistent volumes and claims?
|
||||
|
||||
* Luke: Not much difference, except for the novel ZFS based backend. Makes workloads really portable.
|
||||
|
||||
* Tim: very different than network-based volumes. Its interesting that it is the only offering that allows upgrading media.
|
||||
|
||||
* Brendan: claims, how does it look for replicated claims? eg Cassandra wants to have replicated data underneath. It would be efficient to scale up and down. Create storage on the fly based on load dynamically. Its step beyond taking snapshots - programmatically creating replicas with preallocation.
|
||||
|
||||
* Tim: helps with auto-provisioning.
|
||||
|
||||
-->
|
||||
|
||||
* Derek: 持久卷和请求相比呢?
|
||||
|
||||
* Luke: 除了基于 ZFS 的新后端之外，差别不大。使工作负载真正可移植。
|
||||
|
||||
* Tim: 与基于网络的卷非常不同。有趣的是，它是唯一允许升级媒体的产品。
|
||||
|
||||
* Brendan: 请求，它如何查找重复请求？Cassandra 希望在底层复制数据。向上和向下扩缩是有效的。根据负载动态地创建存储。它的步骤不仅仅是快照——通过编程使用预分配创建副本。
|
||||
|
||||
* Tim: 帮助自动配置。
|
||||
|
||||
<!--
|
||||
|
||||
* Brian: Does flocker requires any other component?
|
||||
|
||||
* Kai: Flocker control service co-located with the master. (dia on blog post). Powerstrip + Powerstrip Flocker. Very interested in mpersisting state in etcd. It keeps metadata about each volume.
|
||||
|
||||
* Brendan: In future, flocker can be a plugin and we'll take care of persistence. Post v1.0.
|
||||
|
||||
* Brian: Interested in adding generic plugin for services like flocker.
|
||||
|
||||
* Luke: Zfs can become really valuable when scaling to lot of containers on a single node.
|
||||
|
||||
-->
|
||||
|
||||
* Brian: flocker 是否需要其他组件？
|
||||
|
||||
* Kai: Flocker 控制服务与主服务器位于同一位置。(dia 在博客上)。Powerstrip + Powerstrip Flocker。对在 etcd 中持久化状态非常有趣。它保存关于每个卷的元数据。
|
||||
|
||||
* Brendan: 在未来，flocker 可以是一个插件，我们将负责持久性。发布 v1.0。
|
||||
|
||||
* Brian: 有兴趣为 flocker 等服务添加通用插件。
|
||||
|
||||
* Luke: 当扩展到单个节点上的许多容器时，Zfs 会变得非常有价值。
|
||||
|
||||
<!--
|
||||
|
||||
* Alex: Can flocker service can be run as a pod?
|
||||
|
||||
* Kai: Yes, only requirement is the flocker control service should be able to talk to zfs agent. zfs agent needs to be installed on the host and zfs binaries need to be accessible.
|
||||
|
||||
* Brendan: In theory, all zfs bits can be put it into a container with devices.
|
||||
|
||||
* Luke: Yes, still working through cross-container mounting issue.
|
||||
|
||||
* Tim: pmorie is working through it to make kubelet work in a container. Possible re-use.
|
||||
|
||||
* Kai: Cinder support is coming. Few days away.
|
||||
* Bob: What's the process of pushing kube to GKE? Need more visibility for confidence.
|
||||
|
||||
-->
|
||||
|
||||
* Alex: flocker 服务可以作为 pod 运行吗？
|
||||
|
||||
* Kai: 是的，唯一的要求是 flocker 控制服务应该能够与 zfs 代理对话。需要在主机上安装 zfs 代理，并且需要访问 zfs 二进制文件。
|
||||
|
||||
* Brendan: 从理论上讲，所有 zfs 位都可以与设备一起放入容器中。
|
||||
|
||||
* Luke: 是的，仍然在处理跨容器安装问题。
|
||||
|
||||
* Tim: pmorie 正在通过它使 kubelet 在容器中工作。可能重复使用。
|
||||
|
||||
* Kai: Cinder 支持即将到来。几天之后。
|
||||
* Bob: 向 GKE 推送 kube 的过程是怎样的？需要更多的可见度。
|
||||
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: " OpenStack 上的 Kubernetes "
|
||||
date: 2015-05-19
|
||||
slug: kubernetes-on-openstack
|
||||
url: /blog/2015/05/Kubernetes-On-Openstack
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Kubernetes on OpenStack "
|
||||
date: 2015-05-19
|
||||
slug: kubernetes-on-openstack
|
||||
url: /blog/2015/05/Kubernetes-On-Openstack
|
||||
---
|
||||
-->
|
||||
|
||||
[](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s1600/Untitled%2Bdrawing.jpg)
|
||||
|
||||
|
||||
<!--
|
||||
Today, the [OpenStack foundation](https://www.openstack.org/foundation/) made it even easier for you deploy and manage clusters of Docker containers on OpenStack clouds by including Kubernetes in its [Community App Catalog](http://apps.openstack.org/). At a keynote today at the OpenStack Summit in Vancouver, Mark Collier, COO of the OpenStack Foundation, and Craig Peters, [Mirantis](https://www.mirantis.com/) product line manager, demonstrated the Community App Catalog workflow by launching a Kubernetes cluster in a matter of seconds by leveraging the compute, storage, networking and identity systems already present in an OpenStack cloud.
|
||||
-->
|
||||
今天，[OpenStack 基金会](https://www.openstack.org/foundation/)通过在其[社区应用程序目录](http://apps.openstack.org/)中包含 Kubernetes，使您更容易在 OpenStack 云上部署和管理 Docker 容器集群。
|
||||
今天在温哥华 OpenStack 峰会上的主题演讲中，OpenStack 基金会的首席运营官：Mark Collier 和 [Mirantis](https://www.mirantis.com/) 产品线经理 Craig Peters 通过利用 OpenStack 云中已经存在的计算、存储、网络和标识系统，在几秒钟内启动了 Kubernetes 集群，展示了社区应用程序目录的工作流。
|
||||
|
||||
<!--
|
||||
The entries in the catalog include not just the ability to [start a Kubernetes cluster](http://apps.openstack.org/#tab=murano-apps&asset=Kubernetes%20Cluster), but also a range of applications deployed in Docker containers managed by Kubernetes. These applications include:
|
||||
-->
|
||||
目录中的条目不仅包括[启动 Kubernetes 集群](http://apps.openstack.org/#tab=murano-apps&asset=Kubernetes%20Cluster)的功能，还包括部署在 Kubernetes 管理的 Docker 容器中的一系列应用程序。这些应用包括：
|
||||
|
||||
<!--
|
||||
|
||||
-
|
||||
Apache web server
|
||||
-
|
||||
Nginx web server
|
||||
-
|
||||
Crate - The Distributed Database for Docker
|
||||
-
|
||||
GlassFish - Java EE 7 Application Server
|
||||
-
|
||||
Tomcat - An open-source web server and servlet container
|
||||
-
|
||||
InfluxDB - An open-source, distributed, time series database
|
||||
-
|
||||
Grafana - Metrics dashboard for InfluxDB
|
||||
-
|
||||
Jenkins - An extensible open source continuous integration server
|
||||
-
|
||||
MariaDB database
|
||||
-
|
||||
MySql database
|
||||
-
|
||||
Redis - Key-value cache and store
|
||||
-
|
||||
PostgreSQL database
|
||||
-
|
||||
MongoDB NoSQL database
|
||||
-
|
||||
Zend Server - The Complete PHP Application Platform
|
||||
|
||||
-->
|
||||
|
||||
|
||||
-
|
||||
Apache web 服务器
|
||||
-
|
||||
Nginx web 服务器
|
||||
-
|
||||
Crate - Docker的分布式数据库
|
||||
-
|
||||
GlassFish - Java EE 7 应用服务器
|
||||
-
|
||||
Tomcat - 一个开源的 web 服务器和 servlet 容器
|
||||
-
|
||||
InfluxDB - 一个开源的、分布式的、时间序列数据库
|
||||
-
|
||||
Grafana - InfluxDB 的度量仪表板
|
||||
-
|
||||
Jenkins - 一个可扩展的开放源码持续集成服务器
|
||||
-
|
||||
MariaDB 数据库
|
||||
-
|
||||
MySql 数据库
|
||||
-
|
||||
Redis - 键-值缓存和存储
|
||||
-
|
||||
PostgreSQL 数据库
|
||||
-
|
||||
MongoDB NoSQL 数据库
|
||||
-
|
||||
Zend 服务器 - 完整的 PHP 应用程序平台
|
||||
|
||||
<!--
|
||||
This list will grow, and is curated [here](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
|
||||
-->
|
||||
此列表将会增长，并在[此处](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes)进行策划。您可以检查（并参与）YAML 文件，该文件告诉 Murano 如何根据[此处](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)定义来安装和启动 ...apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)安装和启动 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
[The Kubernetes open source project](https://github.com/GoogleCloudPlatform/kubernetes) has continued to see fantastic community adoption and increasing momentum, with over 11,000 commits and 7,648 stars on GitHub. With supporters ranging from Red Hat and Intel to CoreOS and Box.net, it has come to represent a range of customer interests ranging from enterprise IT to cutting edge startups. We encourage you to give it a try, give us your feedback, and get involved in our growing community.
|
||||
-->
|
||||
[Kubernetes 开源项目](https://github.com/GoogleCloudPlatform/kubernetes)继续受到社区的欢迎，并且势头越来越好，GitHub 上有超过 11000 个提交和 7648 颗星。从 Red Hat 和 Intel 到 CoreOS 和 Box.net，它已经代表了从企业 IT 到前沿创业企业的一系列客户。我们鼓励您尝试一下，给我们您的反馈，并参与到我们不断增长的社区中来。
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
- Martin Buhr, Product Manager, Kubernetes Open Source Project
|
||||
|
||||
-->
|
||||
|
||||
- Martin Buhr, Kubernetes 开源项目产品经理
|
||||
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 "
|
||||
date: 2015-05-11
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Weekly Kubernetes Community Hangout Notes - May 1 2015 "
|
||||
date: 2015-05-11
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
|
||||
-->
|
||||
每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。
|
||||
|
||||
<!--
|
||||
|
||||
* Simple rolling update - Brendan
|
||||
|
||||
* Rolling update = nice example of why RCs and Pods are good.
|
||||
|
||||
* ...pause… (Brendan needs demo recovery tips from Kelsey)
|
||||
|
||||
* Rolling update has recovery: Cancel update and restart, update continues from where it stopped.
|
||||
|
||||
* New controller gets name of old controller, so appearance is pure update.
|
||||
|
||||
* Can also name versions in update (won't do rename at the end).
|
||||
|
||||
-->
|
||||
|
||||
* 简单的滚动更新 - Brendan
|
||||
|
||||
* 滚动更新 = RCs和Pods很好的例子。
|
||||
|
||||
* ...pause… (Brendan 需要 Kelsey 的演示恢复技巧)
|
||||
|
||||
* 滚动更新具有恢复功能:取消更新并重新启动，更新从停止的地方继续。
|
||||
|
||||
* 新控制器获取旧控制器的名称，因此外观是纯粹的更新。
|
||||
|
||||
* 还可以在 update 中命名版本(最后不会重命名)。
|
||||
|
||||
<!--
|
||||
|
||||
* Rocket demo - CoreOS folks
|
||||
|
||||
* 2 major differences between rocket & docker: Rocket is daemonless & pod-centric.
|
||||
|
||||
* Rocket has AppContainer format as native, but also supports docker image format.
|
||||
|
||||
* Can run AppContainer and docker containers in same pod.
|
||||
|
||||
* Changes are close to merged.
|
||||
|
||||
-->
|
||||
|
||||
* Rocket 演示 - CoreOS 的伙计们
|
||||
|
||||
* Rocket 和 docker 之间的主要区别: Rocket 是无守护进程和以 pod 为中心。。
|
||||
|
||||
* Rocket 具有原生的 AppContainer 格式，但也支持 docker 镜像格式。
|
||||
|
||||
* 可以在同一个 pod 中运行 AppContainer 和 docker 容器。
|
||||
|
||||
* 变更接近于合并。
|
||||
|
||||
<!--
|
||||
|
||||
* demo service accounts and secrets being added to pods - Jordan
|
||||
|
||||
* Problem: It's hard to get a token to talk to the API.
|
||||
|
||||
* New API object: "ServiceAccount"
|
||||
|
||||
* ServiceAccount is namespaced, controller makes sure that at least 1 default service account exists in a namespace.
|
||||
|
||||
* Typed secret "ServiceAccountToken", controller makes sure there is at least 1 default token.
|
||||
|
||||
* DEMO
|
||||
|
||||
* * Can create new service account with ServiceAccountToken. Controller will create token for it.
|
||||
|
||||
* Can create a pod with service account, pods will have service account secret mounted at /var/run/secrets/kubernetes.io/…
|
||||
|
||||
-->
|
||||
|
||||
* 演示 service accounts 和 secrets 被添加到 pod - Jordan
|
||||
|
||||
* 问题：很难获得与API通信的令牌。
|
||||
|
||||
* 新的API对象："ServiceAccount"
|
||||
|
||||
* ServiceAccount 是命名空间，控制器确保命名空间中至少存在一个个默认 service account。
|
||||
|
||||
* 键入 "ServiceAccountToken"，控制器确保至少有一个默认令牌。
|
||||
|
||||
* 演示
|
||||
|
||||
* * 可以使用 ServiceAccountToken 创建新的 service account。控制器将为它创建令牌。
|
||||
|
||||
* 可以创建一个带有 service account 的 pod, pod 将在 /var/run/secrets/kubernets.io/…
|
||||
|
||||
<!--
|
||||
|
||||
* Kubelet running in a container - Paul
|
||||
|
||||
* Kubelet successfully ran pod w/ mounted secret.
|
||||
|
||||
-->
|
||||
|
||||
* Kubelet 在容器中运行 - Paul
|
||||
|
||||
* Kubelet 成功地运行了带有 secret 的 pod。
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "幻灯片：Kubernetes 集群管理，爱丁堡大学演讲"
|
||||
date: 2015-06-26
|
||||
slug: slides-cluster-management-with
|
||||
url: /blog/2015/06/Slides-Cluster-Management-With
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Slides: Cluster Management with Kubernetes, talk given at the University of Edinburgh "
|
||||
date: 2015-06-26
|
||||
slug: slides-cluster-management-with
|
||||
url: /blog/2015/06/Slides-Cluster-Management-With
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
On Friday 5 June 2015 I gave a talk called [Cluster Management with Kubernetes](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000) to a general audience at the University of Edinburgh. The talk includes an example of a music store system with a Kibana front end UI and an Elasticsearch based back end which helps to make concrete concepts like pods, replication controllers and services.
|
||||
|
||||
[Cluster Management with Kubernetes](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000).
|
||||
-->
|
||||
|
||||
2015年6月5日星期五，我在爱丁堡大学给普通听众做了一个演讲，题目是[使用 Kubernetes 进行集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。这次演讲包括一个带有 Kibana 前端 UI 的音乐存储系统的例子，以及一个基于 Elasticsearch 的后端，该后端有助于生成具体的概念，如 pods、复制控制器和服务。
|
||||
|
||||
[Kubernetes 集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: " KubeCon EU 2016：伦敦 Kubernetes 社区 "
|
||||
date: 2016-02-24
|
||||
slug: kubecon-eu-2016-kubernetes-community-in
|
||||
url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " KubeCon EU 2016: Kubernetes Community in London "
|
||||
date: 2016-02-24
|
||||
slug: kubecon-eu-2016-kubernetes-community-in
|
||||
url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
KubeCon EU 2016 is the inaugural [European Kubernetes](http://kubernetes.io/) community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for[Kubernetes](http://kubernetes.io/) enthusiasts, production users and the surrounding ecosystem.
|
||||
-->
|
||||
KubeCon EU 2016 是首届[欧洲 Kubernetes](http://kubernetes.io/) 社区会议，紧随 2015 年 11 月召开的北美会议。KubeCon 致力于为 [Kubernetes](http://kubernetes.io/) 爱好者、产品用户和周围的生态系统提供教育和社区参与。
|
||||
|
||||
<!--
|
||||
Come join us in London and hang out with hundreds from the Kubernetes community and experience a wide variety of deep technical expert talks and use cases.
|
||||
-->
|
||||
快来加入我们在伦敦，与 Kubernetes 社区的数百人一起出去，体验各种深入的技术专家讲座和用例。
|
||||
|
||||
<!--
|
||||
Don’t miss these great speaker sessions at the conference:
|
||||
-->
|
||||
不要错过这些优质的演讲：
|
||||
|
||||
<!--
|
||||
* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google -* [http://sched.co/6Bl3](http://sched.co/6Bl3)
|
||||
|
||||
* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS -* [http://sched.co/6BY7](http://sched.co/6BY7)
|
||||
|
||||
* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google -* [http://sched.co/6BUP](http://sched.co/6BUP)
|
||||
* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation -* http://sched.co/6BYC
|
||||
* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google -* [http://sched.co/6BZa](http://sched.co/6BZa)
|
||||
|
||||
* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times -* [http://sched.co/67f2](http://sched.co/67f2)
|
||||
* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX -* http://sched.co/6Bc9
|
||||
* And many more http://kubeconeurope2016.sched.org/
|
||||
-->
|
||||
|
||||
* “Kubernetes 硬件黑客：通过旋钮、推杆和滑块探索 Kubernetes API” 演讲者 Ian Lewis 和 Brian Dorsey，谷歌开发布道师* [http://sched.co/6Bl3](http://sched.co/6Bl3)
|
||||
|
||||
* “rktnetes: 容器运行时和 Kubernetes 的新功能” 演讲者 Jonathan Boulle, CoreOS 的主程 -* [http://sched.co/6BY7](http://sched.co/6BY7)
|
||||
|
||||
* “Kubernetes 文档：贡献、修复问题、收集奖金” 作者：John Mulhausen，首席技术作家，谷歌 -* [http://sched.co/6BUP](http://sched.co/6BUP)
|
||||
* “[OpenStack 在 Kubernetes 的世界中扮演什么角色？](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者：Thierry carez, OpenStack 基金会工程总监 -* http://sched.co/6BYC
|
||||
* “容器调度的实用指南” 作者：Mandy Waite，开发者倡导者，谷歌 -* [http://sched.co/6BZa](http://sched.co/6BZa)
|
||||
|
||||
* “[《纽约时报》编辑部正在制作 Kubernetes](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis，《纽约时报》网站开发人员 -* [http://sched.co/67f2](http://sched.co/67f2)
|
||||
* “[使用 NGINX 为 Kubernetes 创建一个高级负载均衡解决方案](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者：Andrew Hutchings, NGINX 技术产品经理 -* http://sched.co/6Bc9
|
||||
* 还有更多 http://kubeconeurope2016.sched.org/
|
||||
|
||||
<!--
|
||||
Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016).
|
||||
-->
|
||||
[在这里](https://ti.to/kubecon/kubecon-eu-2016)获取您的 KubeCon EU 门票。
|
||||
|
||||
<!--
|
||||
Venue Location: CodeNode * 10 South Pl, London, United Kingdom
|
||||
Accommodations: [hotels](https://skillsmatter.com/contact-us#hotels)
|
||||
Website: [kubecon.io](https://www.kubecon.io/)
|
||||
Twitter: [@KubeConio](https://twitter.com/kubeconio) #KubeCon
|
||||
Google is a proud Diamond sponsor of KubeCon EU 2016. Come to London next month, March 10th & 11th, and visit booth #13 to learn all about Kubernetes, Google Container Engine (GKE) and Google Cloud Platform!
|
||||
-->
|
||||
会场地址：CodeNode * 英国伦敦南广场 10 号
|
||||
酒店住宿：[酒店](https://skillsmatter.com/contact-us)
|
||||
网站：[kubecon.io] (https://www.kubecon.io/)
|
||||
推特：[@KubeConio] (https://twitter.com/kubeconio)
|
||||
谷歌是 KubeCon EU 2016 的钻石赞助商。下个月 3 月 10 - 11 号来伦敦，参观 13 号展位，了解 Kubernetes，Google Container Engine（GKE），Google Cloud Platform 的所有信息!
|
||||
|
||||
<!--
|
||||
_KubeCon is organized by KubeAcademy, LLC, a community-driven group of developers focused on the education of developers and the promotion of Kubernetes._
|
||||
|
||||
-* Sarah Novotny, Kubernetes Community Manager, Google
|
||||
-->
|
||||
|
||||
_KubeCon 是由 KubeAcademy、LLC 组织的，这是一个由社区驱动的开发者团体，专注于开发人员的教育和 kubernet.com 的推广
|
||||
-* Sarah Novotny, 谷歌的 Kubernetes 社区经理
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
|
||||
date: 2016-04-18
|
||||
slug: kubernetes-network-policy-apis
|
||||
url: /blog/2016/04/Kubernetes-Network-Policy-APIs
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
|
||||
date: 2016-04-18
|
||||
@@ -5,13 +12,6 @@ slug: kubernetes-network-policy-apis
|
||||
url: /blog/2016/04/Kubernetes-Network-Policy-APIs
|
||||
--- -->
|
||||
|
||||
---
|
||||
title: "SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
|
||||
date: 2016-04-18
|
||||
slug: kubernetes-network-policy-apis
|
||||
url: /blog/2016/04/Kubernetes-Network-Policy-APIs
|
||||
---
|
||||
|
||||
<!-- _Editor’s note: This week we’re featuring [Kubernetes Special Interest Groups](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)); Today’s post is by the Network-SIG team describing network policy APIs coming in 1.3 - policies for security, isolation and multi-tenancy._ -->
|
||||
|
||||
编者按：这一周，我们的封面主题是 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs))；今天的文章由网络兴趣小组撰写，来谈谈 1.3 版本中即将出现的网络策略 API - 针对安全，隔离和多租户的策略。
|
||||
|
||||
@@ -1,10 +1,3 @@
|
||||
<!-- ---
|
||||
title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
|
||||
date: 2016-04-15
|
||||
slug: kubernetes-on-aws_15
|
||||
url: /blog/2016/04/Kubernetes-On-Aws_15
|
||||
--- -->
|
||||
|
||||
---
|
||||
title: " 如何在AWS上部署安全，可审计，可复现的k8s集群 "
|
||||
date: 2016-04-15
|
||||
@@ -12,6 +5,13 @@ slug: kubernetes-on-aws_15
|
||||
url: /blog/2016/04/Kubernetes-On-Aws_15
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
|
||||
date: 2016-04-15
|
||||
slug: kubernetes-on-aws_15
|
||||
url: /blog/2016/04/Kubernetes-On-Aws_15
|
||||
--- -->
|
||||
|
||||
<!-- _Today’s guest post is written by Colin Hom, infrastructure engineer at [CoreOS](https://coreos.com/), the company delivering Google’s Infrastructure for Everyone Else (#GIFEE) and running the world's containers securely on CoreOS Linux, Tectonic and Quay._
|
||||
|
||||
_Join us at [CoreOS Fest Berlin](https://coreos.com/fest/), the Open Source Distributed Systems Conference, and learn more about CoreOS and Kubernetes._ -->
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: " Citrix + Kubernetes = 全垒打 "
|
||||
date: 2016-07-14
|
||||
slug: citrix-netscaler-and-kubernetes
|
||||
url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Citrix + Kubernetes = A Home Run "
|
||||
date: 2016-07-14
|
||||
slug: citrix-netscaler-and-kubernetes
|
||||
url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
_Editor’s note: today’s guest post is by Mikko Disini, a Director of Product Management at Citrix Systems, sharing their collaboration experience on a Kubernetes integration. _
|
||||
-->
|
||||
编者按：今天的客座文章来自 Citrix Systems 的产品管理总监 Mikko Disini，他分享了他们在 Kubernetes 集成上的合作经验。 _
|
||||
|
||||
<!--
|
||||
Technical collaboration is like sports. If you work together as a team, you can go down the homestretch and pull through for a win. That’s our experience with the Google Cloud Platform team.
|
||||
-->
|
||||
技术合作就像体育运动。如果你能像一个团队一样合作，你就能在最后关头取得胜利。这就是我们对谷歌云平台团队的经验。
|
||||
|
||||
<!--
|
||||
Recently, we approached Google Cloud Platform (GCP) to collaborate on behalf of Citrix customers and the broader enterprise market looking to migrate workloads. This migration required including the [NetScaler Docker load balancer](https://www.citrix.com/blogs/2016/06/20/the-best-docker-load-balancer-at-dockercon-in-seattle-this-week/), CPX, into Kubernetes nodes and resolving any issues with getting traffic into the CPX proxies.
|
||||
-->
|
||||
最近，我们与 Google 云平台（GCP）联系，代表 Citrix 客户以及更广泛的企业市场，希望就工作负载的迁移进行协作。此迁移需要将 [NetScaler Docker 负载均衡器]https://www.citrix.com/blogs/2016/06/20/the-best-docker-load-balancer-at-dockercon-in-seattle-this-week/) CPX 包含到 Kubernetes 节点中，并解决将流量引入 CPX 代理的任何问题。
|
||||
|
||||
<!--
|
||||
**Why NetScaler and Kubernetes?**
|
||||
-->
|
||||
|
||||
**为什么是 NetScaler 和 Kubernetes**
|
||||
|
||||
<!--
|
||||
1. Citrix customers want the same Layer 4 to Layer 7 capabilities from NetScaler that they have on-prem as they move to the cloud as they begin deploying their container and microservices architecture with Kubernetes
|
||||
2. Kubernetes provides a proven infrastructure for running containers and VMs with automated workload delivery
|
||||
3. NetScaler CPX provides Layer 4 to Layer 7 services and highly efficient telemetry data to a logging and analytics platform, [NetScaler Management and Analytics System](https://www.citrix.com/blogs/2016/05/24/introducing-the-next-generation-netscaler-management-and-analytics-system/)
|
||||
-->
|
||||
|
||||
1. Citrix 的客户希望他们开始使用 Kubernetes 部署他们的容器和微服务体系结构时，能够像当初迁移到云计算时一样，享有 NetScaler 所提供的第 4 层到第 7 层能力
|
||||
2. Kubernetes 提供了一套经过验证的基础设施，可用来运行容器和虚拟机，并自动交付工作负载；
|
||||
3. NetScaler CPX 提供第 4 层到第 7 层的服务，并为日志和分析平台 [NetScaler 管理和分析系统](https://www.citrix.com/blogs/2016/05/24/introducing-the-next-generation-netscaler-management-and-analytics-system/) 提供高效的度量数据。
|
||||
|
||||
<!--
|
||||
I wish all our experiences working together with a technical partner were as good as working with GCP. We had a list of issues to enable our use cases and were able to collaborate swiftly on a solution. To resolve these, GCP team offered in depth technical assistance, working with Citrix such that NetScaler CPX can spin up and take over as a client-side proxy running on each host.
|
||||
-->
|
||||
我希望我们所有与技术合作伙伴一起工作的经验都能像与 GCP 一起工作一样好。我们有一个列表，包含支持我们的用例所需要解决的问题。我们能够快速协作形成解决方案。为了解决这些问题，GCP 团队提供了深入的技术支持，与 Citrix 合作，从而使得 NetScaler CPX 能够在每台主机上作为客户端代理启动运行。
|
||||
|
||||
<!--
|
||||
Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!
|
||||
-->
|
||||
接下来，需要在 GCP 入口负载均衡器的数据路径中插入 NetScaler CPX，使 NetScaler CPX 能够将流量分散到前端 web 服务器。NetScaler 团队进行了修改，以便 NetScaler CPX 监听 API 服务器事件，并配置自己来创建 VIP、IP 表规则和服务器规则，以便跨前端应用程序接收流量和负载均衡。谷歌云平台团队提供反馈和帮助，验证为克服技术障碍所做的修改。完成了!
|
||||
|
||||
<!--
|
||||
NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.
|
||||
-->
|
||||
NetScaler CPX 用例在 [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernets-1.3 - bridge -cloud-native-and-enterprise-workload) 中提供支持。Citrix 的客户和更广泛的企业市场将有机会基于 Kubernetes 享用 NetScaler 服务，从而降低将工作负载转移到云平台的阻力。
|
||||
|
||||
<!--
|
||||
You can learn more about NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).
|
||||
-->
|
||||
您可以在[此处](https://www.citrix.com/networking/microservices.html)了解有关 NetScaler CPX 的更多信息。
|
||||
|
||||
<!--
|
||||
_ -- Mikko Disini, Director of Product Management - NetScaler, Citrix Systems_
|
||||
-->
|
||||
_ -- Mikko Disini，Citrix Systems NetScaler 产品管理总监
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: " Kubernetes 1.8 的五天 "
|
||||
date: 2017-10-24
|
||||
slug: five-days-of-kubernetes-18
|
||||
url: /blog/2017/10/Five-Days-Of-Kubernetes-18
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Five Days of Kubernetes 1.8 "
|
||||
date: 2017-10-24
|
||||
slug: five-days-of-kubernetes-18
|
||||
url: /blog/2017/10/Five-Days-Of-Kubernetes-18
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Kubernetes 1.8 is live, made possible by hundreds of contributors pushing thousands of commits in this latest releases.
|
||||
-->
|
||||
Kubernetes 1.8 是现场直播，数百名贡献者在这个最新版本中推出了成千上万的提交。
|
||||
|
||||
<!--
|
||||
The community has tallied more than 66,000 commits in the main repo and continues rapid growth outside of the main repo, which signals growing maturity and stability for the project. The community has logged more than 120,000 commits across all repos and 17,839 commits across all repos for v1.7.0 to v1.8.0 alone.
|
||||
-->
|
||||
社区已经有超过 66,000 个提交在主仓库，并在主仓库之外继续快速增长，这标志着该项目日益成熟和稳定。仅 v1.7.0 到 v1.8.0，社区就记录了所有仓库的超过 120,000 次提交和 17839 次提交。
|
||||
|
||||
<!--
|
||||
With the help of our growing community of 1,400 plus contributors, we issued more than 3,000 PRs and pushed more than 5,000 commits to deliver Kubernetes 1.8 with significant security and workload support updates. This all points to increased stability, a result of our project-wide focus on maturing [process](https://github.com/kubernetes/sig-release), formalizing [architecture](https://github.com/kubernetes/community/tree/master/sig-architecture), and strengthening Kubernetes’ [governance model](https://github.com/kubernetes/community/tree/master/community/elections/2017).
|
||||
-->
|
||||
在拥有 1400 多名贡献者，并且不断发展壮大的社区的帮助下，我们合并了 3000 多个 PR，并发布了 5000 多个提交，最后的 Kubernetes 1.8 在安全和工作负载方面添加了很多的更新。
|
||||
这一切都表明稳定性的提高，这是我们整个项目关注成熟[流程](https://github.com/kubernetes/sig-release)、形式化[架构](https://github.com/kubernetes/community/tree/master/sig-architecture)和加强 Kubernetes 的[治理模型](https://github.com/kubernetes/community/tree/master/community/elections/2017)的结果。
|
||||
|
||||
<!--
|
||||
While many improvements have been contributed, we highlight key features in this series of in-depth posts listed below. [Follow along](https://twitter.com/kubernetesio) and see what’s new and improved with storage, security and more.
|
||||
-->
|
||||
虽然有很多改进，但我们在下面列出的这一系列深度文章中突出了一些关键特性。[跟随](https://twitter.com/kubernetesio)并了解存储，安全等方面的新功能和改进功能。
|
||||
|
||||
<!--
|
||||
**Day 1:** [5 Days of Kubernetes 1.8](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)
|
||||
**Day 2:** [kubeadm v1.8 Introduces Easy Upgrades for Kubernetes Clusters](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)
|
||||
**Day 3:** [Kubernetes v1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
|
||||
**Day 4:** [Using RBAC, Generally Available in Kubernetes v1.8](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)
|
||||
**Day 5:** [Enforcing Network Policies in Kubernetes](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)
|
||||
-->
|
||||
|
||||
**第一天：** [Kubernetes 1.8 的五天](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)
|
||||
**第二天：** [kubeadm v1.8 为 Kubernetes 集群引入了简单的升级](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)
|
||||
**第三天：** [Kubernetes v1.8 回顾：提升一个 Kubernetes 需要一个 Village](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
|
||||
**第四天：** [使用 RBAC，一般在 Kubernetes v1.8 中提供](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)
|
||||
**第五天：** [在 Kubernetes 执行网络策略](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)
|
||||
|
||||
<!--
|
||||
**Connect**
|
||||
-->
|
||||
|
||||
**链接**
|
||||
|
||||
<!--
|
||||
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
|
||||
- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
|
||||
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
|
||||
- Connect with the community on [Slack](http://slack.k8s.io/)
|
||||
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
|
||||
-->
|
||||
|
||||
- 在 [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) 上发布问题（或回答问题）
|
||||
- 加入 [K8sPort](http://k8sport.org/) 布道师的社区门户网站
|
||||
- 在 Twitter [@Kubernetesio](https://twitter.com/kubernetesio) 关注我们以获取最新更新
|
||||
- 与 [Slack](http://slack.k8s.io/) 上的社区联系
|
||||
- 参与 [GitHub](https://github.com/kubernetes/kubernetes) 上的 Kubernetes 项目
|
||||
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: " Kubernetes 中自动缩放 "
|
||||
date: 2017-11-17
|
||||
slug: autoscaling-in-kubernetes
|
||||
url: /blog/2017/11/Autoscaling-In-Kubernetes
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: " Autoscaling in Kubernetes "
|
||||
date: 2017-11-17
|
||||
slug: autoscaling-in-kubernetes
|
||||
url: /blog/2017/11/Autoscaling-In-Kubernetes
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Kubernetes allows developers to automatically adjust cluster sizes and the number of pod replicas based on current traffic and load. These adjustments reduce the amount of unused nodes, saving money and resources. In this talk, Marcin Wielgus of Google walks you through the current state of pod and node autoscaling in Kubernetes: .how it works, and how to use it, including best practices for deployments in production applications.
|
||||
-->
|
||||
Kubernetes 允许开发人员根据当前的流量和负载自动调整集群大小和 pod 副本的数量。这些调整减少了未使用节点的数量，节省了资金和资源。
|
||||
在这次演讲中，谷歌的 Marcin Wielgus 将带领您了解 Kubernetes 中 pod 和 node 自动调焦的当前状态：它是如何工作的，以及如何使用它，包括在生产应用程序中部署的最佳实践。
|
||||
|
||||
<!--
|
||||
Enjoyed this talk? Join us for more exciting sessions on scaling and automating your Kubernetes clusters at KubeCon in Austin on December 6-8. [Register Now](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)
|
||||
-->
|
||||
喜欢这个演讲吗？ 12 月 6 日至 8 日，在 Austin 参加 KubeCon 关于扩展和自动化您的 Kubernetes 集群的更令人兴奋的会议。[现在注册](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)。
|
||||
|
||||
<!--
|
||||
Be sure to check out [Automating and Testing Production Ready Kubernetes Clusters in the Public Cloud](http://sched.co/CU64) by Ron Lipke, Senior Developer, Platform as a Service, Gannet/USA Today Network.
|
||||
-->
|
||||
一定要查看由 Ron Lipke， Gannet/USA Today Network, 平台即服务高级开发人员，在[公共云中自动化和测试产品就绪的 Kubernetes 集群](http://sched.co/CU64)。
|
||||
|
||||
@@ -0,0 +1,728 @@
|
||||
---
|
||||
title: 在 Kubernetes 上开发
|
||||
date: 2018-05-01
|
||||
slug: developing-on-kubernetes
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Developing on Kubernetes
|
||||
date: 2018-05-01
|
||||
slug: developing-on-kubernetes
|
||||
---
|
||||
-->
|
||||
|
||||
<!--**Authors**:-->
|
||||
**作者**： [Michael Hausenblas](https://twitter.com/mhausenblas) (Red Hat), [Ilya Dmitrichenko](https://twitter.com/errordeveloper) (Weaveworks)
|
||||
|
||||
<!--
|
||||
How do you develop a Kubernetes app? That is, how do you write and test an app that is supposed to run on Kubernetes? This article focuses on the challenges, tools and methods you might want to be aware of to successfully write Kubernetes apps alone or in a team setting.
|
||||
-->
|
||||
|
||||
您将如何开发一个 Kubernates 应用？也就是说，您如何编写并测试一个要在 Kubernates 上运行的应用程序？本文将重点介绍在独自开发或者团队协作中，您可能希望了解到的为了成功编写 Kubernetes 应用程序而需面临的挑战，工具和方法。
|
||||
|
||||
<!--
|
||||
We’re assuming you are a developer, you have a favorite programming language, editor/IDE, and a testing framework available. The overarching goal is to introduce minimal changes to your current workflow when developing the app for Kubernetes. For example, if you’re a Node.js developer and are used to a hot-reload setup—that is, on save in your editor the running app gets automagically updated—then dealing with containers and container images, with container registries, Kubernetes deployments, triggers, and more can not only be overwhelming but really take all the fun out if it.
|
||||
-->
|
||||
|
||||
我们假定您是一位开发人员，有您钟爱的编程语言，编辑器/IDE（集成开发环境），以及可用的测试框架。在针对 Kubernates 开发应用时，最重要的目标是减少对当前工作流程的影响，改变越少越好，尽量做到最小。举个例子，如果您是 Node.js 开发人员，习惯于那种热重载的环境 - 也就是说您在编辑器里一做保存，正在运行的程序就会自动更新 - 那么跟容器、容器镜像或者镜像仓库打交道，又或是跟 Kubernetes 部署、triggers 以及更多头疼东西打交道，不仅会让人难以招架也真的会让开发过程完全失去乐趣。
|
||||
|
||||
<!--
|
||||
In the following, we’ll first discuss the overall development setup, then review tools of the trade, and last but not least do a hands-on walkthrough of three exemplary tools that allow for iterative, local app development against Kubernetes.
|
||||
-->
|
||||
|
||||
在下文中，我们将首先讨论 Kubernetes 总体开发环境，然后回顾常用工具，最后进行三个示例性工具的实践演练。这些工具允许针对 Kubernetes 进行本地应用程序的开发和迭代。
|
||||
|
||||
<!--
|
||||
## Where to run your cluster?
|
||||
-->
|
||||
|
||||
## 您的集群运行在哪里？
|
||||
|
||||
<!--
|
||||
As a developer you want to think about where the Kubernetes cluster you’re developing against runs as well as where the development environment sits. Conceptually there are four development modes:
|
||||
-->
|
||||
|
||||
作为开发人员，您既需要考虑所针对开发的 Kubernetes 集群运行在哪里，也需要思考开发环境如何配置。概念上，有四种开发模式：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
A number of tools support pure offline development including Minikube, Docker for Mac/Windows, Minishift, and the ones we discuss in detail below. Sometimes, for example, in a microservices setup where certain microservices already run in the cluster, a proxied setup (forwarding traffic into and from the cluster) is preferable and Telepresence is an example tool in this category. The live mode essentially means you’re building and/or deploying against a remote cluster and, finally, the pure online mode means both your development environment and the cluster are remote, as this is the case with, for example, [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) or [Cloud 9](https://github.com/errordeveloper/k9c). Let’s now have a closer look at the basics of offline development: running Kubernetes locally.
|
||||
-->
|
||||
|
||||
许多工具支持纯 offline 开发，包括 Minikube、Docker（Mac 版/Windows 版）、Minishift 以及下文中我们将详细讨论的几种。有时，比如说在一个微服务系统中，已经有若干微服务在运行，proxied 模式（通过转发把数据流传进传出集群）就非常合适，Telepresence 就是此类工具的一个实例。live 模式，本质上是您基于一个远程集群进行构建和部署。最后，纯 online 模式意味着您的开发环境和运行集群都是远程的，典型的例子是 [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) 或者 [Cloud 9](https://github.com/errordeveloper/k9c)。现在让我们仔细看看离线开发的基础：在本地运行 Kubernetes。
|
||||
|
||||
<!--
|
||||
[Minikube](/docs/getting-started-guides/minikube/) is a popular choice for those who prefer to run Kubernetes in a local VM. More recently Docker for [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) and [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) started shipping Kubernetes as an experimental package (in the “edge” channel). Some reasons why you may want to prefer using Minikube over the Docker desktop option are:
|
||||
-->
|
||||
|
||||
[Minikube](/docs/getting-started-guides/minikube/) 在更加喜欢于本地 VM 上运行 Kubernetes 的开发人员中，非常受欢迎。不久前，Docker 的 [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) 版和 [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) 版，都试验性地开始自带 Kubernetes（需要下载 “edge” 安装包）。在两者之间，以下原因也许会促使您选择 Minikube 而不是 Docker 桌面版：
|
||||
|
||||
<!--
|
||||
* You already have Minikube installed and running
|
||||
* You prefer to wait until Docker ships a stable package
|
||||
* You’re a Linux desktop user
|
||||
* You are a Windows user who doesn’t have Windows 10 Pro with Hyper-V
|
||||
-->
|
||||
|
||||
* 您已经安装了 Minikube 并且它运行良好
|
||||
* 您想等到 Docker 出稳定版本
|
||||
* 您是 Linux 桌面用户
|
||||
* 您是 Windows 用户，但是没有配有 Hyper-V 的 Windows 10 Pro
|
||||
|
||||
<!--
|
||||
Running a local cluster allows folks to work offline and that you don’t have to pay for using cloud resources. Cloud provider costs are often rather affordable and free tiers exists, however some folks prefer to avoid having to approve those costs with their manager as well as potentially incur unexpected costs, for example, when leaving cluster running over the weekend.
|
||||
-->
|
||||
|
||||
运行一个本地集群，开发人员可以离线工作，不用支付云服务。云服务收费一般不会太高，并且免费的等级也有，但是一些开发人员不喜欢为了使用云服务而必须得到经理的批准，也不愿意支付意想不到的费用，比如说忘了下线而集群在周末也在运转。
|
||||
|
||||
<!--
|
||||
Some developers prefer to use a remote Kubernetes cluster, and this is usually to allow for larger compute and storage capacity and also enable collaborative workflows more easily. This means it’s easier for you to pull in a colleague to help with debugging or share access to an app in the team. Additionally, for some developers it can be critical to mirror production environment as closely as possible, especially when it comes down to external cloud services, say, proprietary databases, object stores, message queues, external load balancer, or mail delivery systems.
|
||||
-->
|
||||
|
||||
有些开发人员却更喜欢远程的 Kubernetes 集群，这样他们通常可以获得更大的计算能力和存储容量，也简化了协同工作流程。您可以更容易的拉上一个同事来帮您调试，或者在团队内共享一个应用的使用。再者，对某些开发人员来说，尽可能的让开发环境类似生产环境至关重要，尤其是您依赖外部厂商的云服务时，如：专有数据库、云对象存储、消息队列、外商的负载均衡器或者邮件投递系统。
|
||||
|
||||
<!--
|
||||
In summary, there are good reasons for you to develop against a local cluster as well as a remote one. It very much depends on in which phase you are: from early prototyping and/or developing alone to integrating a set of more stable microservices.
|
||||
-->
|
||||
|
||||
总之，无论您选择本地或者远程集群，理由都足够多。这很大程度上取决于您所处的阶段：从早期的原型设计/单人开发到后期面对一批稳定微服务的集成。
|
||||
|
||||
<!--
|
||||
Now that you have a basic idea of the options around the runtime environment, let’s move on to how to iteratively develop and deploy your app.
|
||||
-->
|
||||
|
||||
既然您已经了解到运行环境的基本选项，那么我们就接着讨论如何迭代式的开发并部署您的应用。
|
||||
|
||||
<!--
|
||||
## The tools of the trade
|
||||
-->
|
||||
|
||||
## 常用工具
|
||||
|
||||
<!--
|
||||
We are now going to review tooling allowing you to develop apps on Kubernetes with the focus on having minimal impact on your existing workflow. We strive to provide an unbiased description including implications of using each of the tools in general terms.
|
||||
-->
|
||||
|
||||
我们现在回顾既可以允许您可以在 Kubernetes 上开发应用程序又尽可能最小地改变您现有的工作流程的一些工具。我们致力于提供一份不偏不倚的描述，也会提及使用某个工具将会意味着什么。
|
||||
|
||||
<!--
|
||||
Note that this is a tricky area since even for established technologies such as, for example, JSON vs YAML vs XML or REST vs gRPC vs SOAP a lot depends on your background, your preferences and organizational settings. It’s even harder to compare tooling in the Kubernetes ecosystem as things evolve very rapidly and new tools are announced almost on a weekly basis; during the preparation of this post alone, for example, [Gitkube](https://gitkube.sh/) and [Watchpod](https://github.com/MinikubeAddon/watchpod) came out. To cover these new tools as well as related, existing tooling such as [Weave Flux](https://github.com/weaveworks/flux) and OpenShift’s [S2I](https://docs.openshift.com/container-platform/3.9/creating_images/s2i.html) we are planning a follow-up blog post to the one you’re reading.
|
||||
-->
|
||||
|
||||
请注意这很棘手，因为即使在成熟定型的技术中做选择，比如说在 JSON、YAML、XML、REST、gRPC 或者 SOAP 之间做选择，很大程度也取决于您的背景、喜好以及公司环境。在 Kubernetes 生态系统内比较各种工具就更加困难，因为技术发展太快，几乎每周都有新工具面市；举个例子，仅在准备这篇博客的期间，[Gitkube](https://gitkube.sh/) 和 [Watchpod](https://github.com/MinikubeAddon/watchpod) 相继出品。为了进一步覆盖到这些新的，以及一些相关的已推出的工具，例如 [Weave Flux](https://github.com/weaveworks/flux) 和 OpenShift 的 [S2I](https://docs.openshift.com/container-platform/3.9/creating_images/s2i.html)，我们计划再写一篇跟进的博客。
|
||||
|
||||
### Draft
|
||||
|
||||
|
||||
<!--
|
||||
[Draft](https://github.com/Azure/draft) aims to help you get started deploying any app to Kubernetes. It is capable of applying heuristics as to what programming language your app is written in and generates a Dockerfile along with a Helm chart. It then runs the build for you and deploys resulting image to the target cluster via the Helm chart. It also allows user to setup port forwarding to localhost very easily.
|
||||
-->
|
||||
|
||||
[Draft](https://github.com/Azure/draft) 旨在帮助您将任何应用程序部署到 Kubernetes。它能够检测到您的应用所使用的编程语言，并且生成一份 Dockerfile 和 Helm 图表。然后它替您启动构建并且依照 Helm 图表把所生产的镜像部署到目标集群。它也可以让您很容易地设置到 localhost 的端口映射。
|
||||
|
||||
<!--
|
||||
Implications:
|
||||
-->
|
||||
|
||||
这意味着：
|
||||
|
||||
<!--
|
||||
* User can customise the chart and Dockerfile templates however they like, or even create a [custom pack](https://github.com/Azure/draft/blob/master/docs/reference/dep-003.md) (with Dockerfile, the chart and more) for future use
|
||||
-->
|
||||
* 用户可以任意地自定义 Helm 图表和 Dockerfile 模版，或者甚至创建一个 [custom pack](https://github.com/Azure/draft/blob/master/docs/reference/dep-003.md)（使用 Dockerfile、Helm 图表以及其他）以备后用
|
||||
|
||||
<!--
|
||||
* It’s not very simple to guess how just any app is supposed to be built, in some cases user may need to tweak Dockerfile and the Helm chart that Draft generates
|
||||
-->
|
||||
* 要想理解一个应用应该怎么构建并不容易，在某些情况下，用户也许需要修改 Draft 生成的 Dockerfile 和 Heml 图表
|
||||
|
||||
<!--
|
||||
* With [Draft version 0.12.0](https://github.com/Azure/draft/releases/tag/v0.12.0) or older, every time user wants to test a change, they need to wait for Draft to copy the code to the cluster, then run the build, push the image and release updated chart; this can timely, but it results in an image being for every single change made by the user (whether it was committed to git or not)
|
||||
-->
|
||||
* 如果使用 [Draft version 0.12.0](https://github.com/Azure/draft/releases/tag/v0.12.0)<sup>1</sup> 或者更老版本，每一次用户想要测试一个改动，他们需要等 Draft 把代码拷贝到集群，运行构建，推送镜像并且发布更新后的图表；这些步骤可能进行得很快，但是每一次用户的改动都会产生一个镜像（无论是否提交到 git ）
|
||||
|
||||
<!--
|
||||
* As of Draft version 0.12.0, builds are executed locally
|
||||
* User doesn’t have an option to choose something other than Helm for deployment
|
||||
* It can watch local changes and trigger deployments, but this feature is not enabled by default
|
||||
-->
|
||||
* 在 Draft 0.12.0版本，构建是本地进行的
|
||||
* 用户不能选择 Helm 以外的工具进行部署
|
||||
* 它可以监控本地的改动并且触发部署，但是这个功能默认是关闭的
|
||||
|
||||
<!--
|
||||
* It allows developer to use either local or remote Kubernetes cluster
|
||||
* Deploying to production is up to the user, Draft authors recommend their other project – Brigade
|
||||
* Can be used instead of Skaffold, and along the side of Squash
|
||||
-->
|
||||
* 它允许开发人员使用本地或者远程的 Kubernates 集群
|
||||
* 如何部署到生产环境取决于用户， Draft 的作者推荐了他们的另一个项目 - Brigade
|
||||
* 可以代替 Skaffold， 并且可以和 Squash 一起使用
|
||||
|
||||
<!--
|
||||
More info:
|
||||
-->
|
||||
|
||||
更多信息：
|
||||
|
||||
* [Draft: Kubernetes container development made easy](https://kubernetes.io/blog/2017/05/draft-kubernetes-container-development)
|
||||
* [Getting Started Guide](https://github.com/Azure/draft/blob/master/docs/getting-started.md)
|
||||
|
||||
【1】：此处疑为 0.11.0，因为 0.12.0 已经支持本地构建，见下一条
|
||||
|
||||
### Skaffold
|
||||
|
||||
<!--
|
||||
[Skaffold](https://github.com/GoogleCloudPlatform/skaffold) is a tool that aims to provide portability for CI integrations with different build system, image registry and deployment tools. It is different from Draft, yet somewhat comparable. It has a basic capability for generating manifests, but it’s not a prominent feature. Skaffold is extendible and lets user pick tools for use in each of the steps in building and deploying their app.
|
||||
-->
|
||||
|
||||
[Skaffold](https://github.com/GoogleCloudPlatform/skaffold) 让 CI 集成具有可移植性的，它允许用户采用不同的构建系统，镜像仓库和部署工具。它不同于 Draft，同时也具有一定的可比性。它具有生成系统清单的基本能力，但那不是一个重要功能。Skaffold 易于扩展，允许用户在构建和部署应用的每一步选取相应的工具。
|
||||
|
||||
<!--
|
||||
Implications:
|
||||
-->
|
||||
|
||||
这意味着：
|
||||
|
||||
<!--
|
||||
* Modular by design
|
||||
* Works independently of CI vendor, user doesn’t need Docker or Kubernetes plugin
|
||||
* Works without CI as such, i.e. from the developer’s laptop
|
||||
* It can watch local changes and trigger deployments
|
||||
-->
|
||||
* 模块化设计
|
||||
* 不依赖于 CI，用户不需要 Docker 或者 Kubernetes 插件
|
||||
* 没有 CI 也可以工作，也就是说，可以在开发人员的电脑上工作
|
||||
* 它可以监控本地的改动并且触发部署
|
||||
|
||||
<!--
|
||||
* It allows developer to use either local or remote Kubernetes cluster
|
||||
* It can be used to deploy to production, user can configure how exactly they prefer to do it and provide different kind of pipeline for each target environment
|
||||
* Can be used instead of Draft, and along the side with most other tools
|
||||
-->
|
||||
* 它允许开发人员使用本地或者远程的 Kubernetes 集群
|
||||
* 它可以用于部署生产环境，用户可以精确配置，也可以为每一套目标环境提供不同的生产线
|
||||
* 可以代替 Draft，并且和其他工具一起使用
|
||||
|
||||
<!--
|
||||
More info:
|
||||
-->
|
||||
|
||||
更多信息：
|
||||
|
||||
* [Introducing Skaffold: Easy and repeatable Kubernetes development](https://cloudplatform.googleblog.com/2018/03/introducing-Skaffold-Easy-and-repeatable-Kubernetes-development.html)
|
||||
* [Getting Started Guide](https://github.com/GoogleCloudPlatform/skaffold#getting-started-with-local-tooling)
|
||||
|
||||
### Squash
|
||||
|
||||
<!--
|
||||
[Squash](https://github.com/solo-io/squash) consists of a debug server that is fully integrated with Kubernetes, and a IDE plugin. It allows you to insert breakpoints and do all the fun stuff you are used to doing when debugging an application using an IDE. It bridges IDE debugging experience with your Kubernetes cluster by allowing you to attach the debugger to a pod running in your Kubernetes cluster.
|
||||
-->
|
||||
[Squash](https://github.com/solo-io/squash) 包含一个与 Kubernetes 全面集成的调试服务器，以及一个 IDE 插件。它允许您插入断点和所有的调试操作，就像您所习惯的使用 IDE 调试一个程序一般。它允许您将调试器应用到 Kubernetes 集群中运行的 pod 上，从而让您可以使用 IDE 调试 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
Implications:
|
||||
-->
|
||||
|
||||
这意味着：
|
||||
|
||||
<!--
|
||||
* Can be used independently of other tools you chose
|
||||
* Requires a privileged DaemonSet
|
||||
* Integrates with popular IDEs
|
||||
* Supports Go, Python, Node.js, Java and gdb
|
||||
-->
|
||||
* 不依赖您选择的其它工具
|
||||
* 需要一组特权 DaemonSet
|
||||
* 可以和流行 IDE 集成
|
||||
* 支持 Go、Python、Node.js、Java 和 gdb
|
||||
|
||||
<!--
|
||||
* User must ensure application binaries inside the container image are compiled with debug symbols
|
||||
* Can be used in combination with any other tools described here
|
||||
* It can be used with either local or remote Kubernetes cluster
|
||||
-->
|
||||
* 用户必须确保容器中的应用程序使编译时使用了调试符号
|
||||
* 可与此处描述的任何其他工具结合使用
|
||||
* 它可以与本地或远程 Kubernetes 集群一起使用
|
||||
|
||||
<!--
|
||||
More info:
|
||||
-->
|
||||
|
||||
更多信息：
|
||||
|
||||
* [Squash: A Debugger for Kubernetes Apps](https://www.youtube.com/watch?v=5TrV3qzXlgI)
|
||||
* [Getting Started Guide](https://github.com/solo-io/squash/blob/master/docs/getting-started.md)
|
||||
|
||||
### Telepresence
|
||||
|
||||
<!--
|
||||
[Telepresence](https://www.telepresence.io/) connects containers running on developer’s workstation with a remote Kubernetes cluster using a two-way proxy and emulates in-cluster environment as well as provides access to config maps and secrets. It aims to improve iteration time for container app development by eliminating the need for deploying app to the cluster and leverages local container to abstract network and filesystem interface in order to make it appear as if the app was running in the cluster.
|
||||
-->
|
||||
[Telepresence](https://www.telepresence.io/) 使用双向代理将开发人员工作站上运行的容器与远程 Kubernetes 集群连接起来，并模拟集群内环境以及提供对配置映射和机密的访问。它消除了将应用部署到集群的需要，并利用本地容器抽象出网络和文件系统接口，以使其看起来应用好像就在集群中运行，从而改进容器应用程序开发的迭代时间。
|
||||
|
||||
<!--
|
||||
Implications:
|
||||
-->
|
||||
|
||||
这意味着：
|
||||
|
||||
<!--
|
||||
* It can be used independently of other tools you chose
|
||||
* Using together with Squash is possible, although Squash would have to be used for pods in the cluster, while conventional/local debugger would need to be used for debugging local container that’s connected to the cluster via Telepresence
|
||||
* Telepresence imposes some network latency
|
||||
-->
|
||||
* 它不依赖于其它您选取的工具
|
||||
* 可以同 Squash 一起使用，但是 Squash 必须用于调试集群中的 pods，而传统/本地调试器需要用于调试通过 Telepresence 连接到集群的本地容器
|
||||
* Telepresence 会产生一些网络延迟
|
||||
|
||||
<!--
|
||||
* It provides connectivity via a side-car process - sshuttle, which is based on SSH
|
||||
* More intrusive dependency injection mode with LD_PRELOAD/DYLD_INSERT_LIBRARIES is also available
|
||||
* It is most commonly used with a remote Kubernetes cluster, but can be used with a local one also
|
||||
-->
|
||||
* 它通过辅助进程提供连接 - sshuttle，基于SSH的一个工具
|
||||
* 还提供了使用 LD_PRELOAD/DYLD_INSERT_LIBRARIES 的更具侵入性的依赖注入模式
|
||||
* 它最常用于远程 Kubernetes 集群，但也可以与本地集群一起使用
|
||||
|
||||
<!--
|
||||
More info:
|
||||
-->
|
||||
|
||||
更多信息：
|
||||
|
||||
* [Telepresence: fast, realistic local development for Kubernetes microservices](https://www.telepresence.io/)
|
||||
* [Getting Started Guide](https://www.telepresence.io/tutorials/docker)
|
||||
* [How It Works](https://www.telepresence.io/discussion/how-it-works)
|
||||
|
||||
### Ksync
|
||||
|
||||
<!--
|
||||
[Ksync](https://github.com/vapor-ware/ksync) synchronizes application code (and configuration) between your local machine and the container running in Kubernetes, akin to what [oc rsync](https://docs.openshift.com/container-platform/3.9/dev_guide/copy_files_to_container.html) does in OpenShift. It aims to improve iteration time for app development by eliminating build and deployment steps.
|
||||
-->
|
||||
|
||||
|
||||
[Ksync](https://github.com/vapor-ware/ksync) 在本地计算机和运行在 Kubernetes 中的容器之间同步应用程序代码（和配置），类似于 [oc rsync](https://docs.openshift.com/container-platform/3.9/dev_guide/copy_files_to_container.html) 在 OpenShift 中的角色。它旨在通过消除构建和部署步骤来缩短应用程序开发的迭代时间。
|
||||
|
||||
|
||||
<!--
|
||||
Implications:
|
||||
-->
|
||||
|
||||
这意味着：
|
||||
|
||||
<!--
|
||||
* It bypasses container image build and revision control
|
||||
* Compiled language users have to run builds inside the pod (TBC)
|
||||
* Two-way sync – remote files are copied to local directory
|
||||
* Container is restarted each time remote filesystem is updated
|
||||
* No security features – development only
|
||||
-->
|
||||
* 它绕过容器图像构建和修订控制
|
||||
* 使用编译语言的用户必须在 pod（TBC）内运行构建
|
||||
* 双向同步 - 远程文件会复制到本地目录
|
||||
* 每次更新远程文件系统时都会重启容器
|
||||
* 无安全功能 - 仅限开发
|
||||
|
||||
<!--
|
||||
* Utilizes [Syncthing](https://github.com/syncthing/syncthing), a Go library for peer-to-peer sync
|
||||
* Requires a privileged DaemonSet running in the cluster
|
||||
* Node has to use Docker with overlayfs2 – no other CRI implementations are supported at the time of writing
|
||||
-->
|
||||
* 使用 [Syncthing](https://github.com/syncthing/syncthing)，一个用于点对点同步的 Go 语言库
|
||||
* 需要一个在集群中运行的特权 DaemonSet
|
||||
* Node 必须使用带有 overlayfs2 的 Docker - 在写作本文时，尚不支持其他 CRI 实现
|
||||
|
||||
<!--
|
||||
More info:
|
||||
-->
|
||||
|
||||
更多信息：
|
||||
|
||||
* [Getting Started Guide](https://github.com/vapor-ware/ksync#getting-started)
|
||||
* [How It Works](https://github.com/vapor-ware/ksync/blob/master/docs/architecture.md)
|
||||
* [Katacoda scenario to try out ksync in your browser](https://www.katacoda.com/vaporio/scenarios/ksync)
|
||||
* [Syncthing Specification](https://docs.syncthing.net/specs/)
|
||||
|
||||
<!--
|
||||
## Hands-on walkthroughs
|
||||
-->
|
||||
|
||||
## 实践演练
|
||||
|
||||
|
||||
<!--
|
||||
The app we will be using for the hands-on walkthroughs of the tools in the following is a simple [stock market simulator](https://github.com/kubernauts/dok-example-us), consisting of two microservices:
|
||||
-->
|
||||
|
||||
我们接下来用于练习使用工具的应用是一个简单的[股市模拟器](https://github.com/kubernauts/dok-example-us)，包含两个微服务：
|
||||
|
||||
<!--
|
||||
* The `stock-gen` microservice is written in Go and generates stock data randomly and exposes it via HTTP endpoint `/stockdata`.
|
||||
* A second microservice, `stock-con` is a Node.js app that consumes the stream of stock data from `stock-gen` and provides an aggregation in form of a moving average via the HTTP endpoint `/average/$SYMBOL` as well as a health-check endpoint at `/healthz`.
|
||||
-->
|
||||
|
||||
* `stock-gen`（股市数据生成器）微服务是用 Go 编写的，随机生成股票数据并通过 HTTP 端点 `/ stockdata` 公开
|
||||
* 第二个微服务，`stock-con`（股市数据消费者）是一个 Node.js 应用程序，它使用来自 `stock-gen` 的股票数据流，并通过 HTTP 端点 `/average/$SYMBOL` 提供股价移动平均线，也提供一个健康检查端点 `/healthz`。
|
||||
|
||||
<!--
|
||||
Overall, the default setup of the app looks as follows:
|
||||
-->
|
||||
|
||||
总体上，此应用的默认配置如下图所示：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
In the following we’ll do a hands-on walkthrough for a representative selection of tools discussed above: ksync, Minikube with local build, as well as Skaffold. For each of the tools we do the following:
|
||||
-->
|
||||
|
||||
在下文中，我们将选取以上讨论的代表性工具进行实践演练：ksync，具有本地构建的 Minikube 以及 Skaffold。对于每个工具，我们执行以下操作：
|
||||
|
||||
<!--
|
||||
* Set up the respective tool incl. preparations for the deployment and local consumption of the `stock-con` microservice.
|
||||
* Perform a code update, that is, change the source code of the `/healthz` endpoint in the `stock-con` microservice and observe the updates.
|
||||
-->
|
||||
|
||||
* 设置相应的工具，包括部署准备和 `stock-con` 微服务数据的本地读取
|
||||
* 执行代码更新，即更改 `stock-con` 微服务的 `/healthz` 端点的源代码并观察网页刷新
|
||||
|
||||
<!--
|
||||
Note that for the target Kubernetes cluster we’ve been using Minikube locally, but you can also a remote cluster for ksync and Skaffold if you want to follow along.
|
||||
-->
|
||||
|
||||
请注意，我们一直使用 Minikube 的本地 Kubernetes 集群，但是您也可以使用 ksync 和 Skaffold 的远程集群跟随练习。
|
||||
|
||||
<!--
|
||||
### Walkthrough: ksync
|
||||
-->
|
||||
|
||||
### 实践演练：ksync
|
||||
|
||||
<!--
|
||||
As a preparation, install [ksync](https://vapor-ware.github.io/ksync/#installation) and then carry out the following steps to prepare the development setup:
|
||||
-->
|
||||
|
||||
作为准备，安装 [ksync](https://vapor-ware.github.io/ksync/#installation)，然后执行以下步骤配置开发环境：
|
||||
|
||||
```
|
||||
$ mkdir -p $(pwd)/ksync
|
||||
$ kubectl create namespace dok
|
||||
$ ksync init -n dok
|
||||
```
|
||||
<!--
|
||||
With the basic setup completed we're ready to tell ksync’s local client to watch a certain Kubernetes namespace and then we create a spec to define what we want to sync (the directory `$(pwd)/ksync` locally with `/app` in the container). Note that target pod is specified via the selector parameter:
|
||||
-->
|
||||
|
||||
|
||||
完成基本设置后，我们可以告诉 ksync 的本地客户端监控 Kubernetes 的某个命名空间，然后我们创建一个规范来定义我们想要同步的文件夹（本地的 `$(pwd)/ksync` 和容器中的 `/ app` ）。请注意，目标 pod 是用 selector 参数指定：
|
||||
|
||||
```
|
||||
$ ksync watch -n dok
|
||||
$ ksync create -n dok --selector=app=stock-con $(pwd)/ksync /app
|
||||
$ ksync get -n dok
|
||||
```
|
||||
|
||||
<!--
|
||||
Now we deploy the stock generator and the stock consumer microservice:
|
||||
-->
|
||||
|
||||
现在我们部署股价数据生成器和股价数据消费者微服务：
|
||||
|
||||
```
|
||||
$ kubectl -n=dok apply \
|
||||
-f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-gen/app.yaml
|
||||
$ kubectl -n=dok apply \
|
||||
-f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-con/app.yaml
|
||||
```
|
||||
<!--
|
||||
Once both deployments are created and the pods are running, we forward the `stock-con` service for local consumption (in a separate terminal session):
|
||||
-->
|
||||
|
||||
|
||||
一旦两个部署建好并且 pod 开始运行，我们转发 `stock-con` 服务以供本地读取（另开一个终端窗口）：
|
||||
|
||||
```
|
||||
$ kubectl get -n dok po --selector=app=stock-con \
|
||||
-o=custom-columns=:metadata.name --no-headers | \
|
||||
xargs -IPOD kubectl -n dok port-forward POD 9898:9898
|
||||
```
|
||||
<!--
|
||||
With that we should be able to consume the `stock-con` service from our local machine; we do this by regularly checking the response of the `healthz` endpoint like so (in a separate terminal session):
|
||||
-->
|
||||
|
||||
|
||||
这样，通过定期查询 `healthz` 端点，我们就应该能够从本地机器上读取 `stock-con` 服务，查询命令如下（在一个单独的终端窗口）：
|
||||
|
||||
```
|
||||
$ watch curl localhost:9898/healthz
|
||||
```
|
||||
<!--
|
||||
Now change the code in the `ksync/stock-con`directory, for example update the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response and observe how the pod gets updated and the response of the `curl localhost:9898/healthz` command changes. Overall you should have something like the following in the end:
|
||||
-->
|
||||
|
||||
|
||||
现在，改动 `ksync/stock-con` 目录中的代码，例如改动 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中新添一个字段并观察 pod 如何更新以及 `curl localhost：9898/healthz` 命令的输出发生何种变化。总的来说，您最后应该看到类似的内容：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Walkthrough: Minikube with local build
|
||||
-->
|
||||
|
||||
### 实践演练：带本地构建的 Minikube
|
||||
|
||||
<!--
|
||||
For the following you will need to have Minikube up and running and we will leverage the Minikube-internal Docker daemon for building images, locally. As a preparation, do the following
|
||||
-->
|
||||
|
||||
|
||||
对于以下内容，您需要启动并运行 Minikube，我们将利用 Minikube 自带的 Docker daemon 在本地构建镜像。作为准备，请执行以下操作
|
||||
|
||||
```
|
||||
$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us
|
||||
$ eval $(minikube docker-env)
|
||||
$ kubectl create namespace dok
|
||||
```
|
||||
|
||||
<!--
|
||||
Now we deploy the stock generator and the stock consumer microservice:
|
||||
-->
|
||||
|
||||
现在我们部署股价数据生成器和股价数据消费者微服务：
|
||||
|
||||
|
||||
```
|
||||
$ kubectl -n=dok apply -f stock-gen/app.yaml
|
||||
$ kubectl -n=dok apply -f stock-con/app.yaml
|
||||
```
|
||||
<!--
|
||||
Once both deployments are created and the pods are running, we forward the `stock-con` service for local consumption (in a separate terminal session):
|
||||
-->
|
||||
|
||||
|
||||
一旦两个部署建好并且 pod 开始运行，我们转发 `stock-con` 服务以供本地读取（另开一个终端窗口）：
|
||||
|
||||
```
|
||||
$ kubectl get -n dok po --selector=app=stock-con \
|
||||
-o=custom-columns=:metadata.name --no-headers | \
|
||||
xargs -IPOD kubectl -n dok port-forward POD 9898:9898 &
|
||||
$ watch curl localhost:9898/healthz
|
||||
```
|
||||
<!--
|
||||
Now change the code in the `stock-con`directory, for example, update the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response. Once you’re done with your code update, the last step is to build a new container image and kick off a new deployment like shown below:
|
||||
-->
|
||||
|
||||
现在，改一下 `ksync/stock-con` 目录中的代码，例如修改 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中添加一个字段。在您更新完代码后，最后一步是构建新的容器镜像并启动新部署，如下所示：
|
||||
|
||||
|
||||
```
|
||||
$ docker build -t stock-con:dev -f Dockerfile .
|
||||
$ kubectl -n dok set image deployment/stock-con *=stock-con:dev
|
||||
```
|
||||
<!--
|
||||
Overall you should have something like the following in the end:
|
||||
-->
|
||||
|
||||
总的来说，您最后应该看到类似的内容：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Walkthrough: Skaffold
|
||||
-->
|
||||
|
||||
### 实践演练：Skaffold
|
||||
|
||||
<!--
|
||||
To perform this walkthrough you first need to install [Skaffold](https://github.com/GoogleContainerTools/skaffold#installation). Once that is done, you can do the following steps to prepare the development setup:
|
||||
-->
|
||||
|
||||
要进行此演练，首先需要安装 [Skaffold](https://github.com/GoogleContainerTools/skaffold#installation)。完成后，您可以执行以下步骤来配置开发环境：
|
||||
|
||||
```
|
||||
$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us
|
||||
$ kubectl create namespace dok
|
||||
```
|
||||
<!--
|
||||
Now we deploy the stock generator (but not the stock consumer microservice, that is done via Skaffold):
|
||||
-->
|
||||
|
||||
现在我们部署股价数据生成器（但是暂不部署股价数据消费者，此服务将使用 Skaffold 完成）：
|
||||
|
||||
```
|
||||
$ kubectl -n=dok apply -f stock-gen/app.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Note that initially we experienced an authentication error when doing `skaffold dev` and needed to apply a fix as described in [Issue 322](https://github.com/GoogleContainerTools/skaffold/issues/322). Essentially it means changing the content of `~/.docker/config.json` to:
|
||||
-->
|
||||
|
||||
|
||||
请注意，最初我们在执行 `skaffold dev` 时发生身份验证错误，为避免此错误需要安装[问题322](https://github.com/GoogleContainerTools/skaffold/issues/322) 中所述的修复。本质上，需要将 `〜/.docker/config.json` 的内容改为：
|
||||
|
||||
|
||||
```
|
||||
{
|
||||
"auths": {}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
Next, we had to patch `stock-con/app.yaml` slightly to make it work with Skaffold:
|
||||
-->
|
||||
|
||||
接下来，我们需要略微改动 `stock-con/app.yaml`，这样 Skaffold 才能正常使用此文件：
|
||||
|
||||
<!--
|
||||
Add a `namespace` field to both the `stock-con` deployment and the service with the value of `dok`.
|
||||
Change the `image` field of the container spec to `quay.io/mhausenblas/stock-con` since Skaffold manages the container image tag on the fly.
|
||||
-->
|
||||
|
||||
在 `stock-con` 部署和服务中添加一个 `namespace` 字段，其值为 `dok`
|
||||
|
||||
将容器规范的 `image` 字段更改为 `quay.io/mhausenblas/stock-con`，因为 Skaffold 可以即时管理容器镜像标签。
|
||||
|
||||
<!--
|
||||
The resulting `app.yaml` file stock-con looks as follows:
|
||||
-->
|
||||
最终的 stock-con 的 `app.yaml` 文件看起来如下：
|
||||
|
||||
|
||||
```
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: stock-con
|
||||
name: stock-con
|
||||
namespace: dok
|
||||
spec:
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: stock-con
|
||||
spec:
|
||||
containers:
|
||||
- name: stock-con
|
||||
image: quay.io/mhausenblas/stock-con
|
||||
env:
|
||||
- name: DOK_STOCKGEN_HOSTNAME
|
||||
value: stock-gen
|
||||
- name: DOK_STOCKGEN_PORT
|
||||
value: "9999"
|
||||
ports:
|
||||
- containerPort: 9898
|
||||
protocol: TCP
|
||||
livenessProbe:
|
||||
initialDelaySeconds: 2
|
||||
periodSeconds: 5
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 9898
|
||||
readinessProbe:
|
||||
initialDelaySeconds: 2
|
||||
periodSeconds: 5
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 9898
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: stock-con
|
||||
name: stock-con
|
||||
namespace: dok
|
||||
spec:
|
||||
type: ClusterIP
|
||||
ports:
|
||||
- name: http
|
||||
port: 80
|
||||
protocol: TCP
|
||||
targetPort: 9898
|
||||
selector:
|
||||
app: stock-con
|
||||
```
|
||||
<!--
|
||||
The final step before we can start development is to configure Skaffold. So, create a file `skaffold.yaml` in the `stock-con/` directory with the following content:
|
||||
-->
|
||||
|
||||
我们能够开始开发之前的最后一步是配置 Skaffold。因此，在 `stock-con/` 目录中创建文件 `skaffold.yaml`，其中包含以下内容：
|
||||
|
||||
```
|
||||
apiVersion: skaffold/v1alpha2
|
||||
kind: Config
|
||||
build:
|
||||
artifacts:
|
||||
- imageName: quay.io/mhausenblas/stock-con
|
||||
workspace: .
|
||||
docker: {}
|
||||
local: {}
|
||||
deploy:
|
||||
kubectl:
|
||||
manifests:
|
||||
- app.yaml
|
||||
```
|
||||
<!--
|
||||
Now we’re ready to kick off the development. For that execute the following in the `stock-con/` directory:
|
||||
-->
|
||||
|
||||
现在我们准备好开始开发了。为此，在 `stock-con/` 目录中执行以下命令：
|
||||
|
||||
```
|
||||
$ skaffold dev
|
||||
```
|
||||
<!--
|
||||
Above command triggers a build of the `stock-con` image and then a deployment. Once the pod of the `stock-con` deployment is running, we again forward the `stock-con` service for local consumption (in a separate terminal session) and check the response of the `healthz` endpoint:
|
||||
-->
|
||||
|
||||
|
||||
上面的命令将触发 `stock-con` 图像的构建和部署。一旦 `stock-con` 部署的 pod 开始运行，我们再次转发 `stock-con` 服务以供本地读取（在单独的终端窗口中）并检查 `healthz` 端点的响应：
|
||||
|
||||
```bash
|
||||
$ kubectl get -n dok po --selector=app=stock-con \
|
||||
-o=custom-columns=:metadata.name --no-headers | \
|
||||
xargs -IPOD kubectl -n dok port-forward POD 9898:9898 &
|
||||
$ watch curl localhost:9898/healthz
|
||||
```
|
||||
<!--
|
||||
If you now change the code in the `stock-con`directory, for example, by updating the [`/healthz` endpoint code in `service.js`](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52) by adding a field to the JSON response, you should see Skaffold noticing the change and create a new image as well as deploy it. The resulting screen would look something like this:
|
||||
-->
|
||||
|
||||
现在，如果您修改一下 `stock-con` 目录中的代码，例如 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52)，在其 JSON 形式的响应中添加一个字段，您应该看到 Skaffold 可以检测到代码改动并创建新图像以及部署它。您的屏幕看起来应该类似这样：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
By now you should have a feeling how different tools enable you to develop apps on Kubernetes and if you’re interested to learn more about tools and or methods, check out the following resources:
|
||||
-->
|
||||
|
||||
至此，您应该对不同的工具如何帮您在 Kubernetes 上开发应用程序有了一定的概念，如果您有兴趣了解有关工具和/或方法的更多信息，请查看以下资源：
|
||||
|
||||
* Blog post by Shahidh K Muhammed on [Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold](https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs-ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948) (03/2018)
|
||||
* Blog post by Gergely Nemeth on [Using Kubernetes for Local Development](https://nemethgergely.com/using-kubernetes-for-local-development/index.html), with a focus on Skaffold (03/2018)
|
||||
* Blog post by Richard Li on [Locally developing Kubernetes services (without waiting for a deploy)](https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99), with a focus on Telepresence
|
||||
* Blog post by Abhishek Tiwari on [Local Development Environment for Kubernetes using Minikube](https://abhishek-tiwari.com/local-development-environment-for-kubernetes-using-minikube/) (09/2017)
|
||||
* Blog post by Aymen El Amri on [Using Kubernetes for Local Development — Minikube](https://medium.com/devopslinks/using-kubernetes-minikube-for-local-development-c37c6e56e3db) (08/2017)
|
||||
* Blog post by Alexis Richardson on [GitOps - Operations by Pull Request](https://www.weave.works/blog/gitops-operations-by-pull-request) (08/2017)
|
||||
* Slide deck [GitOps: Drive operations through git](https://docs.google.com/presentation/d/1d3PigRVt_m5rO89Ob2XZ16bW8lRSkHHH5k816-oMzZo/), with a focus on Gitkube by Tirumarai Selvan (03/2018)
|
||||
* Slide deck [Developing apps on Kubernetes](https://speakerdeck.com/mhausenblas/developing-apps-on-kubernetes), a talk Michael Hausenblas gave at a CNCF Paris meetup (04/2018)
|
||||
* YouTube videos:
|
||||
* [TGI Kubernetes 029: Developing Apps with Ksync](https://www.youtube.com/watch?v=QW85Y0Ug3KY )
|
||||
* [TGI Kubernetes 030: Exploring Skaffold](https://www.youtube.com/watch?v=McwwWhCXMxc)
|
||||
* [TGI Kubernetes 031: Connecting with Telepresence](https://www.youtube.com/watch?v=zezeBAJ_3w8)
|
||||
* [TGI Kubernetes 033: Developing with Draft](https://www.youtube.com/watch?v=8B1D7cTMPgA)
|
||||
* Raw responses to the [Kubernetes Application Survey](https://docs.google.com/spreadsheets/d/12ilRCly2eHKPuicv1P_BD6z__PXAqpiaR-tDYe2eudE/edit) 2018 by SIG Apps
|
||||
|
||||
<!--
|
||||
With that we wrap up this post on how to go about developing apps on Kubernetes, we hope you learned something and if you have feedback and/or want to point out a tool that you found useful, please let us know via Twitter: [Ilya](https://twitter.com/errordeveloper) and [Michael](https://twitter.com/mhausenblas).
|
||||
-->
|
||||
|
||||
有了这些，我们这篇关于如何在 Kubernetes 上开发应用程序的博客就可以收尾了，希望您有所收获，如果您有反馈和/或想要指出您认为有用的工具，请通过 Twitter 告诉我们：[Ilya](https://twitter.com/errordeveloper) 和 [Michael](https://twitter.com/mhausenblas)
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: 'Kubernetes 1 11：向 discuss kubernetes 问好'
|
||||
layout: blog
|
||||
date: 2018-05-30
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: ' Kubernetes 1 11：say-hello-to-discuss-kubernetes '
|
||||
cn-approvers:
|
||||
- congfairy
|
||||
layout: blog
|
||||
date: 2018-05-30
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
|
||||
Author: Jorge Castro (Heptio)
|
||||
|
||||
-->
|
||||
|
||||
作者: Jorge Castro (Heptio)
|
||||
|
||||
<!--
|
||||
|
||||
Communication is key when it comes to engaging a community of over 35,000 people in a global and remote environment. Keeping track of everything in the Kubernetes community can be an overwhelming task. On one hand we have our official resources, like Stack Overflow, GitHub, and the mailing lists, and on the other we have more ephemeral resources like Slack, where you can hop in, chat with someone, and then go on your merry way.
|
||||
|
||||
-->
|
||||
|
||||
就一个超过 35,000 人的全球性社区而言，参与其中时沟通是非常关键的。 跟踪 Kubernetes 社区中的所有内容可能是一项艰巨的任务。 一方面，我们有官方资源，如 Stack Overflow，GitHub 和邮件列表，另一方面，我们有更多瞬时性的资源，如 Slack，你可以加入进去、与某人聊天然后各走各路。
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
Slack is great for casual and timely conversations and keeping up with other community members, but communication can't be easily referenced in the future. Plus it can be hard to raise your hand in a room filled with 35,000 participants and find a voice. Mailing lists are useful when trying to reach a specific group of people with a particular ask and want to keep track of responses on the thread, but can be daunting with a large amount of people. Stack Overflow and GitHub are ideal for collaborating on projects or questions that involve code and need to be searchable in the future, but certain topics like "What's your favorite CI/CD tool" or "Kubectl tips and tricks" are offtopic there.
|
||||
|
||||
While our current assortment of communication channels are valuable in their own rights, we found that there was still a gap between email and real time chat. Across the rest of the web, many other open source projects like Docker, Mozilla, Swift, Ghost, and Chef have had success building communities on top of Discourse, an open source discussion platform. So what if we could use this tool to bring our discussions together under a modern roof, with an open API, and perhaps not let so much of our information fade into the ether? There's only one way to find out: Welcome to discuss.kubernetes.io
|
||||
|
||||
-->
|
||||
|
||||
Slack 非常适合随意和及时的对话，并与其他社区成员保持联系，但未来很难轻易引用通信。此外，在35,000名参与者中提问并得到回答很难。邮件列表在有问题尝试联系特定人群并且想要跟踪大家的回应时非常有用，但是对于大量人员来说可能是麻烦的。 Stack Overflow 和 GitHub 非常适合在涉及代码的项目或问题上进行协作，并且如果在将来要进行搜索也很有用，但某些主题如“你最喜欢的 CI/CD 工具是什么”或“[Kubectl提示和技巧](http://discuss.kubernetes.io/t/kubectl-tips-and-tricks/192)“在那里是没有意义的。
|
||||
|
||||
虽然我们目前的各种沟通渠道对他们自己来说都很有价值，但我们发现电子邮件和实时聊天之间仍然存在差距。在网络的其他部分，许多其他开源项目，如 Docker、Mozilla、Swift、Ghost 和 Chef，已经成功地在[Discourse](http://www.discourse.org/features)之上构建社区，一个开放的讨论平台。那么，如果我们可以使用这个工具将我们的讨论结合在一个平台下，使用开放的API，或许也不会让我们的大部分信息消失在网络中呢？只有一种方法可以找到：欢迎来到[discuss.kubernetes.io](http://discuss.kubernetes.io)
|
||||
|
||||
<!--
|
||||
|
||||
Right off the bat we have categories that users can browse. Checking and posting in these categories allow users to participate in things they might be interested in without having to commit to subscribing to a list. Granular notification controls allow the users to subscribe to just the category or tag they want, and allow for responding to topics via email.
|
||||
|
||||
Ecosystem partners and developers now have a place where they can [announce projects](https://discuss.kubernetes.io/c/announcements) that they're working on to users without wondering if it would be offtopic on an official list. We can make this place be not just about core Kubernetes, but about the hundreds of wonderful tools our community is building.
|
||||
|
||||
|
||||
This new community forum gives people a place to go where they can discuss Kubernetes, and a sounding board for developers to make announcements of things happening around Kubernetes, all while being searchable and easily accessible to a wider audience.
|
||||
|
||||
Hop in and take a look. We're just getting started, so you might want to begin by [introducing yourself](https://discuss.kubernetes.io/t/introduce-yourself-here/56) and then browsing around. Apps are also available for [Android](https://play.google.com/store/apps/details?id=com.discourse&hl=en_US&rdid=com.discourse&pli=1)and [iOS](https://itunes.apple.com/us/app/discourse-app/id1173672076?mt=8).
|
||||
|
||||
|
||||
-->
|
||||
|
||||
马上，我们有用户可以浏览的类别。检查和发布这些类别允许用户参与他们可能感兴趣的事情，而无需订阅列表。精细的通知控件允许用户只订阅他们想要的类别或标签，并允许通过电子邮件回复主题。
|
||||
|
||||
生态系统合作伙伴和开发人员现在有一个地方可以[宣布项目](http://discuss.kubernetes.io/c/announcements)，他们正在为用户工作，而不会想知道它是否会在官方列表中脱离主题。我们可以让这个地方不仅仅是关于核心 Kubernetes，而是关于我们社区正在建设的数百个精彩工具。
|
||||
|
||||
这个新的社区论坛为人们提供了一个可以讨论 Kubernetes 的地方，也是开发人员在 Kubernetes 周围发布事件的声音板，同时可以搜索并且更容易被更广泛的用户访问。
|
||||
|
||||
进来看看。我们刚刚开始，所以，您可能希望从[自我介绍](http://discuss.kubernetes.io/t/introduce-yourself-here/56)开始，到处浏览。也有 [Android](http://play.google.com/store/apps/details?id=com.discourse&hl=en_US&rdid=com.discourse&pli=1) 和 [iOS](http://itunes.apple.com/us/app/discourse-app/id1173672076?mt=8) 应用下载。
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Kubernetes 这四年
|
||||
approvers:
|
||||
cn-approvers:
|
||||
- congfairy
|
||||
layout: blog
|
||||
date: 2018-06-06
|
||||
---
|
||||
<!--
|
||||
**Author**: Joe Beda (CTO and Founder, Heptio)
|
||||
On June 6, 2014 I checked in the [first commit](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) of what would become the public repository for Kubernetes. Many would assume that is where the story starts. It is the beginning of history, right? But that really doesn’t tell the whole story.
|
||||
-->
|
||||
|
||||
**作者**：Joe Beda( Heptio 首席技术官兼创始人)
|
||||
2014 年 6 月 6 日，我检查了 Kubernetes 公共代码库的[第一次 commit](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) 。许多人会认为这是故事开始的地方。这难道不是一切开始的地方吗？但这的确不能把整个过程说清楚。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
The cast leading up to that commit was large and the success for Kubernetes since then is owed to an ever larger cast.
|
||||
Kubernetes was built on ideas that had been proven out at Google over the previous ten years with Borg. And Borg, itself, owed its existence to even earlier efforts at Google and beyond.
|
||||
Concretely, Kubernetes started as some prototypes from Brendan Burns combined with ongoing work from me and Craig McLuckie to better align the internal Google experience with the Google Cloud experience. Brendan, Craig, and I really wanted people to use this, so we made the case to build out this prototype as an open source project that would bring the best ideas from Borg out into the open.
|
||||
After we got the nod, it was time to actually build the system. We took Brendan’s prototype (in Java), rewrote it in Go, and built just enough to get the core ideas across. By this time the team had grown to include Ville Aikas, Tim Hockin, Brian Grant, Dawn Chen and Daniel Smith. Once we had something working, someone had to sign up to clean things up to get it ready for public launch. That ended up being me. Not knowing the significance at the time, I created a new repo, moved things over, and checked it in. So while I have the first public commit to the repo, there was work underway well before that.
|
||||
The version of Kubernetes at that point was really just a shadow of what it was to become. The core concepts were there but it was very raw. For example, Pods were called Tasks. That was changed a day before we went public. All of this led up to the public announcement of Kubernetes on June 10th, 2014 in a keynote from Eric Brewer at the first DockerCon. You can watch that video here:
|
||||
-->
|
||||
|
||||
第一次 commit 涉及的人员众多，自那以后 Kubernetes 的成功归功于更大的开发者阵容。
|
||||
Kubernetes 建立在过去十年曾经在 Google 的 Borg 集群管理系统中验证过的思路之上。而 Borg 本身也是 Google 和其他公司早期努力的结果。
|
||||
具体而言，Kubernetes 最初是从 Brendan Burns 的一些原型开始，结合我和 Craig McLuckie 正在进行的工作，以更好地将 Google 内部实践与 Google Cloud 的经验相结合。 Brendan，Craig 和我真的希望人们使用它，所以我们建议将这个原型构建为一个开源项目，将 Borg 的最佳创意带给大家。
|
||||
在我们所有人同意后，就开始着手构建这个系统了。我们采用了 Brendan 的原型（Java 语言），用 Go 语言重写了它，并且以上述核心思想去构建该系统。到这个时候，团队已经成长为包括 Ville Aikas，Tim Hockin，Brian Grant，Dawn Chen 和 Daniel Smith。一旦我们有了一些工作需求，有人必须承担一些脱敏的工作，以便为公开发布做好准备。这个角色最终由我承担。当时，我不知道这件事情的重要性，我创建了一个新的仓库，把代码搬过来，然后进行了检查。所以在我第一次提交 public commit 之前，就有工作已经启动了。
|
||||
那时 Kubernetes 的版本只是现在版本的简单雏形。核心概念已经有了，但非常原始。例如，Pods 被称为 Tasks，这在我们推广前一天就被替换。2014年6月10日 Eric Brewe 在第一届 DockerCon 上的演讲中正式发布了 Kubernetes 。您可以在此处观看该视频：
|
||||
|
||||
|
||||
<center><iframe width="560" height="315" src="https://www.youtube.com/embed/YrxnVKZeqK8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></center>
|
||||
|
||||
<!--
|
||||
But, however raw, that modest start was enough to pique the interest of a community that started strong and has only gotten stronger. Over the past four years Kubernetes has exceeded the expectations of all of us that were there early on. We owe the Kubernetes community a huge debt. The success the project has seen is based not just on code and technology but also the way that an amazing group of people have come together to create something special. The best expression of this is the [set of Kubernetes values](https://github.com/kubernetes/steering/blob/master/values.md) that Sarah Novotny helped curate.
|
||||
Here is to another 4 years and beyond! 🎉🎉🎉
|
||||
-->
|
||||
|
||||
但是，无论多么原始，这小小的一步足以激起一个开始强大而且变得更强大的社区的兴趣。在过去的四年里，Kubernetes 已经超出了我们所有人的期望。我们对 Kubernetes 社区的所有人员表示感谢。该项目所取得的成功不仅基于代码和技术，还基于一群出色的人聚集在一起所做的有意义的事情。Sarah Novotny 策划的一套 [Kubernetes 价值观](https://github.com/kubernetes/steering/blob/master/values.md)是以上最好的表现形式。
|
||||
让我们一起期待下一个4年！🎉🎉🎉
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
title: 'Kubernetes 内的动态 Ingress'
|
||||
layout: blog
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Dynamic Ingress in Kubernetes
|
||||
date: 2018-06-07
|
||||
Author: Richard Li (Datawire)
|
||||
-->
|
||||
|
||||
作者: Richard Li (Datawire)
|
||||
|
||||
<!--
|
||||
Kubernetes makes it easy to deploy applications that consist of many microservices, but one of the key challenges with this type of architecture is dynamically routing ingress traffic to each of these services. One approach is Ambassador, a Kubernetes-native open source API Gateway built on the Envoy Proxy. Ambassador is designed for dynamic environment where services may come and go frequently.
|
||||
Ambassador is configured using Kubernetes annotations. Annotations are used to configure specific mappings from a given Kubernetes service to a particular URL. A mapping can include a number of annotations for configuring a route. Examples include rate limiting, protocol, cross-origin request sharing, traffic shadowing, and routing rules.
|
||||
-->
|
||||
|
||||
Kubernetes 可以轻松部署由许多微服务组成的应用程序，但这种架构的关键挑战之一是动态地将流量路由到这些服务中的每一个。
|
||||
一种方法是使用 [Ambassador](https://www.getambassador.io)，
|
||||
一个基于 [Envoy Proxy](https://www.envoyproxy.io) 构建的 Kubernetes 原生开源 API 网关。
|
||||
Ambassador 专为动态环境而设计，这类环境中的服务可能被频繁添加或删除。
|
||||
|
||||
Ambassador 使用 Kubernetes 注解进行配置。
|
||||
注解用于配置从给定 Kubernetes 服务到特定 URL 的具体映射关系。
|
||||
每个映射中可以包括多个注解，用于配置路由。
|
||||
注解的例子有速率限制、协议、跨源请求共享（CORS）、流量影射和路由规则等。
|
||||
|
||||
<!--
|
||||
## A Basic Ambassador Example
|
||||
Ambassador is typically installed as a Kubernetes deployment, and is also available as a Helm chart. To configure Ambassador, create a Kubernetes service with the Ambassador annotations. Here is an example that configures Ambassador to route requests to /httpbin/ to the public httpbin.org service:
|
||||
-->
|
||||
|
||||
## 一个简单的 Ambassador 示例
|
||||
|
||||
Ambassador 通常作为 Kubernetes Deployment 来安装，也可以作为 Helm Chart 使用。
|
||||
配置 Ambassador 时，请使用 Ambassador 注解创建 Kubernetes 服务。
|
||||
下面是一个例子，用来配置 Ambassador，将针对 /httpbin/ 的请求路由到公共的 httpbin.org 服务：
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: httpbin
|
||||
annotations:
|
||||
getambassador.io/config: |
|
||||
---
|
||||
apiVersion: ambassador/v0
|
||||
kind: Mapping
|
||||
name: httpbin_mapping
|
||||
prefix: /httpbin/
|
||||
service: httpbin.org:80
|
||||
host_rewrite: httpbin.org
|
||||
spec:
|
||||
type: ClusterIP
|
||||
ports:
|
||||
- port: 80
|
||||
```
|
||||
|
||||
<!--
|
||||
A mapping object is created with a prefix of /httpbin/ and a service name of httpbin.org. The host_rewrite annotation specifies that the HTTP host header should be set to httpbin.org.
|
||||
-->
|
||||
|
||||
例子中创建了一个 Mapping 对象，其 prefix 设置为 /httpbin/，service 名称为 httpbin.org。
|
||||
其中的 host_rewrite 注解指定 HTTP 的 host 头部字段应设置为 httpbin.org。
|
||||
|
||||
<!--
|
||||
## Kubeflow
|
||||
Kubeflow provides a simple way to easily deploy machine learning infrastructure on Kubernetes. The Kubeflow team needed a proxy that provided a central point of authentication and routing to the wide range of services used in Kubeflow, many of which are ephemeral in nature.
|
||||
<center><i>Kubeflow architecture, pre-Ambassador</center></i>
|
||||
-->
|
||||
|
||||
## Kubeflow
|
||||
|
||||
[Kubeflow](https://github.com/kubeflow/kubeflow) 提供了一种简单的方法，用于在 Kubernetes 上轻松部署机器学习基础设施。
|
||||
Kubeflow 团队需要一个代理，为 Kubeflow 中所使用的各种服务提供集中化的认证和路由能力；Kubeflow 中许多服务本质上都是生命期很短的。
|
||||
|
||||
<center><i>Kubeflow architecture, pre-Ambassador</center></i>
|
||||
|
||||
<!--
|
||||
## Service configuration
|
||||
With Ambassador, Kubeflow can use a distributed model for configuration. Instead of a central configuration file, Ambassador allows each service to configure its route in Ambassador via Kubernetes annotations. Here is a simplified example configuration:
|
||||
-->
|
||||
|
||||
## 服务配置
|
||||
|
||||
有了 Ambassador，Kubeflow 可以使用分布式模型进行配置。
|
||||
Ambassador 不使用集中的配置文件，而是允许每个服务通过 Kubernetes 注解在 Ambassador 中配置其路由。
|
||||
下面是一个简化的配置示例：
|
||||
|
||||
```
|
||||
---
|
||||
apiVersion: ambassador/v0
|
||||
kind: Mapping
|
||||
name: tfserving-mapping-test-post
|
||||
prefix: /models/test/
|
||||
rewrite: /model/test/:predict
|
||||
method: POST
|
||||
service: test.kubeflow:8000
|
||||
```
|
||||
|
||||
<!--
|
||||
In this example, the “test” service uses Ambassador annotations to dynamically configure a route to the service, triggered only when the HTTP method is a POST, and the annotation also specifies a rewrite rule.
|
||||
-->
|
||||
|
||||
示例中，“test” 服务使用 Ambassador 注解来为服务动态配置路由。
|
||||
所配置的路由仅在 HTTP 方法是 POST 时触发；注解中同时还给出了一条重写规则。
|
||||
|
||||
<!--
|
||||
With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic to specific backends. For example, when deploying TensorFlow services, Kubeflow creates and and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing.
|
||||
If you’re interested in using Ambassador with Kubeflow, the standard Kubeflow install automatically installs and configures Ambassador.
|
||||
If you’re interested in using Ambassador as an API Gateway or Kubernetes ingress solution for your non-Kubeflow services, check out the Getting Started with Ambassador guide.
|
||||
## Kubeflow and Ambassador
|
||||
-->
|
||||
|
||||
## Kubeflow 和 Ambassador
|
||||
|
||||
通过 Ambassador，Kubeflow 可以使用 Kubernetes 注解轻松管理路由。
|
||||
Kubeflow 配置同一个 Ingress 对象，将流量定向到 Ambassador，然后根据需要创建具有 Ambassador 注解的服务，以将流量定向到特定后端。
|
||||
例如，在部署 TensorFlow 服务时，Kubeflow 会创建 Kubernetes 服务并为其添加注解，
|
||||
以便用户能够在 `https://<ingress主机>/models/<模型名称>/` 处访问到模型本身。
|
||||
Kubeflow 还可以使用 Envoy Proxy 来进行实际的 L7 路由。
|
||||
通过 Ambassador，Kubeflow 能够更充分地利用 URL 重写和基于方法的路由等额外的路由配置能力。
|
||||
|
||||
如果您对在 Kubeflow 中使用 Ambassador 感兴趣，标准的 Kubeflow 安装会自动安装和配置 Ambassador。
|
||||
|
||||
如果您有兴趣将 Ambassador 用作 API 网关或 Kubernetes 的 Ingress 解决方案，
|
||||
请参阅 [Ambassador 入门指南](https://www.getambassador.io/user-guide/getting-started)。
|
||||
|
||||
@@ -0,0 +1,306 @@
|
||||
---
|
||||
layout: blog
|
||||
title: 'KubeDirector：在 Kubernetes 上运行复杂状态应用程序的简单方法'
|
||||
date: 2018-10-03
|
||||
---
|
||||
|
||||
<!--
|
||||
layout: blog
|
||||
title: 'KubeDirector: The easy way to run complex stateful applications on Kubernetes'
|
||||
date: 2018-10-03
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Author**: Thomas Phelan (BlueData)
|
||||
-->
|
||||
|
||||
**作者**：Thomas Phelan（BlueData）
|
||||
|
||||
<!--
|
||||
KubeDirector is an open source project designed to make it easy to run complex stateful scale-out application clusters on Kubernetes. KubeDirector is built using the custom resource definition (CRD) framework and leverages the native Kubernetes API extensions and design philosophy. This enables transparent integration with Kubernetes user/resource management as well as existing clients and tools.
|
||||
-->
|
||||
KubeDirector 是一个开源项目，旨在简化在 Kubernetes 上运行复杂的有状态扩展应用程序集群。KubeDirector 使用自定义资源定义（CRD）
|
||||
框架构建，并利用了本地 Kubernetes API 扩展和设计哲学。这支持与 Kubernetes 用户/资源 管理以及现有客户端和工具的透明集成。
|
||||
|
||||
<!--
|
||||
We recently [introduced the KubeDirector project](https://medium.com/@thomas_phelan/operation-stateful-introducing-bluek8s-and-kubernetes-director-aa204952f619/), as part of a broader open source Kubernetes initiative we call BlueK8s. I’m happy to announce that the pre-alpha
|
||||
code for [KubeDirector](https://github.com/bluek8s/kubedirector/) is now available. And in this blog post, I’ll show how it works.
|
||||
-->
|
||||
我们最近[介绍了 KubeDirector 项目](https://medium.com/@thomas_phelan/operation-stateful-introducing-bluek8s-and-kubernetes-director-aa204952f619/)，作为我们称为 BlueK8s 的更广泛的 Kubernetes 开源项目的一部分。我很高兴地宣布 [KubeDirector](https://github.com/bluek8s/kubedirector/) 的
|
||||
pre-alpha 代码现在已经可用。在这篇博客文章中，我将展示它是如何工作的。
|
||||
|
||||
<!--
|
||||
KubeDirector provides the following capabilities:
|
||||
-->
|
||||
KubeDirector 提供以下功能：
|
||||
|
||||
<!--
|
||||
* The ability to run non-cloud native stateful applications on Kubernetes without modifying the code. In other words, it’s not necessary to decompose these existing applications to fit a microservices design pattern.
|
||||
* Native support for preserving application-specific configuration and state.
|
||||
* An application-agnostic deployment pattern, minimizing the time to onboard new stateful applications to Kubernetes.
|
||||
-->
|
||||
|
||||
* 无需修改代码即可在 Kubernetes 上运行非云原生有状态应用程序。换句话说，不需要分解这些现有的应用程序来适应微服务设计模式。
|
||||
* 本机支持保存特定于应用程序的配置和状态。
|
||||
* 与应用程序无关的部署模式，最大限度地减少将新的有状态应用程序装载到 Kubernetes 的时间。
|
||||
|
||||
<!--
|
||||
KubeDirector enables data scientists familiar with data-intensive distributed applications such as Hadoop, Spark, Cassandra, TensorFlow, Caffe2, etc. to run these applications on Kubernetes -- with a minimal learning curve and no need to write GO code. The applications controlled by KubeDirector are defined by some basic metadata and an associated package of configuration artifacts. The application metadata is referred to as a KubeDirectorApp resource.
|
||||
-->
|
||||
KubeDirector 使熟悉数据密集型分布式应用程序（如 Hadoop、Spark、Cassandra、TensorFlow、Caffe2 等）的数据科学家能够在 Kubernetes 上运行这些应用程序 -- 只需极少的学习曲线，无需编写 GO 代码。由 KubeDirector 控制的应用程序由一些基本元数据和相关的配置工件包定义。应用程序元数据称为 KubeDirectorApp 资源。
|
||||
|
||||
<!--
|
||||
To understand the components of KubeDirector, clone the repository on [GitHub](https://github.com/bluek8s/kubedirector/) using a command similar to:
|
||||
-->
|
||||
要了解 KubeDirector 的组件，请使用类似于以下的命令在 [GitHub](https://github.com/bluek8s/kubedirector/) 上克隆存储库：
|
||||
|
||||
```
|
||||
git clone http://<userid>@github.com/bluek8s/kubedirector.
|
||||
```
|
||||
|
||||
<!--
|
||||
The KubeDirectorApp definition for the Spark 2.2.1 application is located
|
||||
in the file `kubedirector/deploy/example_catalog/cr-app-spark221e2.json`.
|
||||
-->
|
||||
Spark 2.2.1 应用程序的 KubeDirectorApp 定义位于文件 `kubedirector/deploy/example_catalog/cr-app-spark221e2.json` 中。
|
||||
|
||||
```
|
||||
~> cat kubedirector/deploy/example_catalog/cr-app-spark221e2.json
|
||||
{
|
||||
"apiVersion": "kubedirector.bluedata.io/v1alpha1",
|
||||
"kind": "KubeDirectorApp",
|
||||
"metadata": {
|
||||
"name" : "spark221e2"
|
||||
},
|
||||
"spec" : {
|
||||
"systemctlMounts": true,
|
||||
"config": {
|
||||
"node_services": [
|
||||
{
|
||||
"service_ids": [
|
||||
"ssh",
|
||||
"spark",
|
||||
"spark_master",
|
||||
"spark_worker"
|
||||
],
|
||||
…
|
||||
```
|
||||
|
||||
<!--
|
||||
The configuration of an application cluster is referred to as a KubeDirectorCluster resource. The
|
||||
KubeDirectorCluster definition for a sample Spark 2.2.1 cluster is located in the file
|
||||
`kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml`.
|
||||
-->
|
||||
应用程序集群的配置称为 KubeDirectorCluster 资源。示例 Spark 2.2.1 集群的 KubeDirectorCluster 定义位于文件
|
||||
`kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml` 中。
|
||||
|
||||
```
|
||||
~> cat kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml
|
||||
apiVersion: "kubedirector.bluedata.io/v1alpha1"
|
||||
kind: "KubeDirectorCluster"
|
||||
metadata:
|
||||
name: "spark221e2"
|
||||
spec:
|
||||
app: spark221e2
|
||||
roles:
|
||||
- name: controller
|
||||
replicas: 1
|
||||
resources:
|
||||
requests:
|
||||
memory: "4Gi"
|
||||
cpu: "2"
|
||||
limits:
|
||||
memory: "4Gi"
|
||||
cpu: "2"
|
||||
- name: worker
|
||||
replicas: 2
|
||||
resources:
|
||||
requests:
|
||||
memory: "4Gi"
|
||||
cpu: "2"
|
||||
limits:
|
||||
memory: "4Gi"
|
||||
cpu: "2"
|
||||
- name: jupyter
|
||||
…
|
||||
```
|
||||
|
||||
<!--
|
||||
## Running Spark on Kubernetes with KubeDirector
|
||||
-->
|
||||
|
||||
## 使用 KubeDirector 在 Kubernetes 上运行 Spark
|
||||
|
||||
<!--
|
||||
With KubeDirector, it’s easy to run Spark clusters on Kubernetes.
|
||||
-->
|
||||
使用 KubeDirector，可以轻松在 Kubernetes 上运行 Spark 集群。
|
||||
|
||||
<!--
|
||||
First, verify that Kubernetes (version 1.9 or later) is running, using the command `kubectl version`
|
||||
-->
|
||||
首先，使用命令 `kubectl version` 验证 Kubernetes（版本 1.9 或更高）是否正在运行
|
||||
|
||||
```
|
||||
~> kubectl version
|
||||
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
|
||||
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
|
||||
```
|
||||
|
||||
<!--
|
||||
Deploy the KubeDirector service and the example KubeDirectorApp resource definitions with the commands:
|
||||
-->
|
||||
使用以下命令部署 KubeDirector 服务和示例 KubeDirectorApp 资源定义：
|
||||
|
||||
```
|
||||
cd kubedirector
|
||||
make deploy
|
||||
```
|
||||
|
||||
<!--
|
||||
These will start the KubeDirector pod:
|
||||
-->
|
||||
这些将启动 KubeDirector pod：
|
||||
|
||||
```
|
||||
~> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
kubedirector-58cf59869-qd9hb 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
List the installed KubeDirector applications with `kubectl get KubeDirectorApp`
|
||||
-->
|
||||
`kubectl get KubeDirectorApp` 列出中已安装的 KubeDirector 应用程序
|
||||
|
||||
```
|
||||
~> kubectl get KubeDirectorApp
|
||||
NAME AGE
|
||||
cassandra311 30m
|
||||
spark211up 30m
|
||||
spark221e2 30m
|
||||
```
|
||||
|
||||
<!--
|
||||
Now you can launch a Spark 2.2.1 cluster using the example KubeDirectorCluster file and the
|
||||
`kubectl create -f deploy/example_clusters/cr-cluster-spark211up.yaml` command.
|
||||
Verify that the Spark cluster has been started:
|
||||
-->
|
||||
现在，您可以使用示例 KubeDirectorCluster 文件和 `kubectl create -f deploy/example_clusters/cr-cluster-spark211up.yaml` 命令
|
||||
启动 Spark 2.2.1 集群。验证 Spark 集群已经启动:
|
||||
|
||||
```
|
||||
~> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
kubedirector-58cf59869-djdwl 1/1 Running 0 19m
|
||||
spark221e2-controller-zbg4d-0 1/1 Running 0 23m
|
||||
spark221e2-jupyter-2km7q-0 1/1 Running 0 23m
|
||||
spark221e2-worker-4gzbz-0 1/1 Running 0 23m
|
||||
spark221e2-worker-4gzbz-1 1/1 Running 0 23m
|
||||
```
|
||||
|
||||
<!--
|
||||
The running services now include the Spark services:
|
||||
-->
|
||||
现在运行的服务包括 Spark 服务：
|
||||
|
||||
```
|
||||
~> kubectl get service
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kubedirector ClusterIP 10.98.234.194 <none> 60000/TCP 1d
|
||||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
|
||||
svc-spark221e2-5tg48 ClusterIP None <none> 8888/TCP 21s
|
||||
svc-spark221e2-controller-tq8d6-0 NodePort 10.104.181.123 <none> 22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP 20s
|
||||
svc-spark221e2-jupyter-6989v-0 NodePort 10.105.227.249 <none> 22:30632/TCP,8888:30355/TCP 20s
|
||||
svc-spark221e2-worker-d9892-0 NodePort 10.107.131.165 <none> 22:30358/TCP,8081:32144/TCP 20s
|
||||
svc-spark221e2-worker-d9892-1 NodePort 10.110.88.221 <none> 22:30294/TCP,8081:31436/TCP 20s
|
||||
```
|
||||
|
||||
<!--
|
||||
Pointing the browser at port 31533 connects to the Spark Master UI:
|
||||
-->
|
||||
将浏览器指向端口 31533 连接到 Spark 主节点 UI：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
That’s all there is to it!
|
||||
In fact, in the example above we also deployed a Jupyter notebook along with the Spark cluster.
|
||||
-->
|
||||
就是这样!
|
||||
事实上，在上面的例子中，我们还部署了一个 Jupyter notebook 和 Spark 集群。
|
||||
|
||||
<!--
|
||||
To start another application (e.g. Cassandra), just specify another KubeDirectorApp file:
|
||||
-->
|
||||
要启动另一个应用程序（例如 Cassandra），只需指定另一个 KubeDirectorApp 文件：
|
||||
|
||||
```
|
||||
kubectl create -f deploy/example_clusters/cr-cluster-cassandra311.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
See the running Cassandra cluster:
|
||||
-->
|
||||
查看正在运行的 Cassandra 集群：
|
||||
|
||||
```
|
||||
~> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cassandra311-seed-v24r6-0 1/1 Running 0 1m
|
||||
cassandra311-seed-v24r6-1 1/1 Running 0 1m
|
||||
cassandra311-worker-rqrhl-0 1/1 Running 0 1m
|
||||
cassandra311-worker-rqrhl-1 1/1 Running 0 1m
|
||||
kubedirector-58cf59869-djdwl 1/1 Running 0 1d
|
||||
spark221e2-controller-tq8d6-0 1/1 Running 0 22m
|
||||
spark221e2-jupyter-6989v-0 1/1 Running 0 22m
|
||||
spark221e2-worker-d9892-0 1/1 Running 0 22m
|
||||
spark221e2-worker-d9892-1 1/1 Running 0 22m
|
||||
```
|
||||
|
||||
<!--
|
||||
Now you have a Spark cluster (with a Jupyter notebook) and a Cassandra cluster running on Kubernetes.
|
||||
Use `kubectl get service` to see the set of services.
|
||||
-->
|
||||
现在，您有一个 Spark 集群（带有 Jupyter notebook ）和一个运行在 Kubernetes 上的 Cassandra 集群。
|
||||
使用 `kubectl get service` 查看服务集。
|
||||
|
||||
```
|
||||
~> kubectl get service
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kubedirector ClusterIP 10.98.234.194 <none> 60000/TCP 1d
|
||||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
|
||||
svc-cassandra311-seed-v24r6-0 NodePort 10.96.94.204 <none> 22:31131/TCP,9042:30739/TCP 3m
|
||||
svc-cassandra311-seed-v24r6-1 NodePort 10.106.144.52 <none> 22:30373/TCP,9042:32662/TCP 3m
|
||||
svc-cassandra311-vhh29 ClusterIP None <none> 8888/TCP 3m
|
||||
svc-cassandra311-worker-rqrhl-0 NodePort 10.109.61.194 <none> 22:31832/TCP,9042:31962/TCP 3m
|
||||
svc-cassandra311-worker-rqrhl-1 NodePort 10.97.147.131 <none> 22:31454/TCP,9042:31170/TCP 3m
|
||||
svc-spark221e2-5tg48 ClusterIP None <none> 8888/TCP 24m
|
||||
svc-spark221e2-controller-tq8d6-0 NodePort 10.104.181.123 <none> 22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP 24m
|
||||
svc-spark221e2-jupyter-6989v-0 NodePort 10.105.227.249 <none> 22:30632/TCP,8888:30355/TCP 24m
|
||||
svc-spark221e2-worker-d9892-0 NodePort 10.107.131.165 <none> 22:30358/TCP,8081:32144/TCP 24m
|
||||
svc-spark221e2-worker-d9892-1 NodePort 10.110.88.221 <none> 22:30294/TCP,8081:31436/TCP 24m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Get Involved
|
||||
-->
|
||||
|
||||
## 参与其中
|
||||
|
||||
<!--
|
||||
KubeDirector is a fully open source, Apache v2 licensed, project – the first of multiple open source projects within a broader initiative we call BlueK8s.
|
||||
The pre-alpha code for KubeDirector has just been released and we would love for you to join the growing community of developers, contributors, and adopters.
|
||||
Follow [@BlueK8s](https://twitter.com/BlueK8s/) on Twitter and get involved through these channels:
|
||||
-->
|
||||
KubeDirector 是一个完全开放源码的 Apache v2 授权项目 – 在我们称为 BlueK8s 的更广泛的计划中，它是多个开放源码项目中的第一个。
|
||||
KubeDirector 的 pre-alpha 代码刚刚发布，我们希望您加入到不断增长的开发人员、贡献者和使用者社区。
|
||||
在 Twitter 上关注 [@BlueK8s](https://twitter.com/BlueK8s/)，并通过以下渠道参与:
|
||||
|
||||
<!--
|
||||
* KubeDirector [chat room on Slack](https://join.slack.com/t/bluek8s/shared_invite/enQtNDUwMzkwODY5OTM4LTRhYmRmZmE4YzY3OGUzMjA1NDg0MDVhNDQ2MGNkYjRhM2RlMDNjMTI1NDQyMjAzZGVlMDFkNThkNGFjZGZjMGY/)
|
||||
* KubeDirector [GitHub repo](https://github.com/bluek8s/kubedirector/)
|
||||
-->
|
||||
|
||||
* KubeDirector [Slack 聊天室](https://join.slack.com/t/bluek8s/shared_invite/enQtNDUwMzkwODY5OTM4LTRhYmRmZmE4YzY3OGUzMjA1NDg0MDVhNDQ2MGNkYjRhM2RlMDNjMTI1NDQyMjAzZGVlMDFkNThkNGFjZGZjMGY/)
|
||||
* KubeDirector [GitHub 仓库](https://github.com/bluek8s/kubedirector/)
|
||||
@@ -0,0 +1,268 @@
|
||||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes 中的拓扑感知数据卷供应'
|
||||
date: 2018-10-11
|
||||
---
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
title: 'Topology-Aware Volume Provisioning in Kubernetes'
|
||||
date: 2018-10-11
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Author**: Michelle Au (Google)
|
||||
-->
|
||||
**作者**: Michelle Au（谷歌）
|
||||
|
||||
<!--
|
||||
The multi-zone cluster experience with persistent volumes is improving in Kubernetes 1.12 with the topology-aware dynamic provisioning beta feature. This feature allows Kubernetes to make intelligent decisions when dynamically provisioning volumes by getting scheduler input on the best place to provision a volume for a pod. In multi-zone clusters, this means that volumes will get provisioned in an appropriate zone that can run your pod, allowing you to easily deploy and scale your stateful workloads across failure domains to provide high availability and fault tolerance.
|
||||
-->
|
||||
通过提供拓扑感知动态卷供应功能，具有持久卷的多区域集群体验在 Kubernetes 1.12 中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策，方法是从调度器获得为 Pod 提供数据卷的最佳位置。在多区域集群环境，这意味着数据卷能够在满足你的 Pod 运行需要的合适的区域被供应，从而允许您跨故障域轻松部署和扩展有状态工作负载，从而提供高可用性和容错能力。
|
||||
|
||||
<!--
|
||||
## Previous challenges
|
||||
-->
|
||||
## 以前的挑战
|
||||
|
||||
<!--
|
||||
Before this feature, running stateful workloads with zonal persistent disks (such as AWS ElasticBlockStore, Azure Disk, GCE PersistentDisk) in multi-zone clusters had many challenges. Dynamic provisioning was handled independently from pod scheduling, which meant that as soon as you created a PersistentVolumeClaim (PVC), a volume would get provisioned. This meant that the provisioner had no knowledge of what pods were using the volume, and any pod constraints it had that could impact scheduling.
|
||||
-->
|
||||
在此功能被提供之前，在多区域集群中使用区域化的持久磁盘（例如 AWS ElasticBlockStore，Azure Disk，GCE PersistentDisk）运行有状态工作负载存在许多挑战。动态供应独立于 Pod 调度处理，这意味着只要您创建了一个 PersistentVolumeClaim（PVC），一个卷就会被供应。这也意味着供应者不知道哪些 Pod 正在使用该卷，也不清楚任何可能影响调度的 Pod 约束。
|
||||
|
||||
<!--
|
||||
This resulted in unschedulable pods because volumes were provisioned in zones that:
|
||||
-->
|
||||
这导致了不可调度的 Pod，因为在以下区域中配置了卷：
|
||||
|
||||
<!--
|
||||
* did not have enough CPU or memory resources to run the pod
|
||||
* conflicted with node selectors, pod affinity or anti-affinity policies
|
||||
* could not run the pod due to taints
|
||||
-->
|
||||
* 没有足够的 CPU 或内存资源来运行 Pod
|
||||
* 与节点选择器、Pod 亲和或反亲和策略冲突
|
||||
* 由于污点（taint）不能运行 Pod
|
||||
|
||||
<!--
|
||||
Another common issue was that a non-StatefulSet pod using multiple persistent volumes could have each volume provisioned in a different zone, again resulting in an unschedulable pod.
|
||||
-->
|
||||
另一个常见问题是，使用多个持久卷的非有状态 Pod 可能会在不同的区域中配置每个卷，从而导致一个不可调度的 Pod。
|
||||
|
||||
<!--
|
||||
Suboptimal workarounds included overprovisioning of nodes, or manual creation of volumes in the correct zones, making it difficult to dynamically deploy and scale stateful workloads.
|
||||
-->
|
||||
次优的解决方法包括节点超配，或在正确的区域中手动创建卷，但这会造成难以动态部署和扩展有状态工作负载的问题。
|
||||
|
||||
<!--
|
||||
The topology-aware dynamic provisioning feature addresses all of the above issues.
|
||||
-->
|
||||
拓扑感知动态供应功能解决了上述所有问题。
|
||||
|
||||
<!--
|
||||
## Supported Volume Types
|
||||
-->
|
||||
## 支持的卷类型
|
||||
|
||||
<!--
|
||||
In 1.12, the following drivers support topology-aware dynamic provisioning:
|
||||
-->
|
||||
在 1.12 中，以下驱动程序支持拓扑感知动态供应：
|
||||
|
||||
<!--
|
||||
* AWS EBS
|
||||
* Azure Disk
|
||||
* GCE PD (including Regional PD)
|
||||
* CSI (alpha) - currently only the GCE PD CSI driver has implemented topology support
|
||||
-->
|
||||
* AWS EBS
|
||||
* Azure Disk
|
||||
* GCE PD （包括 Regional PD）
|
||||
* CSI（alpha） - 目前只有 GCE PD CSI 驱动实现了拓扑支持
|
||||
|
||||
<!--
|
||||
## Design Principles
|
||||
-->
|
||||
## 设计原则
|
||||
|
||||
<!--
|
||||
While the initial set of supported plugins are all zonal-based, we designed this feature to adhere to the Kubernetes principle of portability across environments. Topology specification is generalized and uses a similar label-based specification like in Pod nodeSelectors and nodeAffinity. This mechanism allows you to define your own topology boundaries, such as racks in on-premise clusters, without requiring modifications to the scheduler to understand these custom topologies.
|
||||
-->
|
||||
虽然最初支持的插件集都是基于区域的，但我们设计此功能时遵循 Kubernetes 跨环境可移植性的原则。
|
||||
拓扑规范是通用的，并使用类似于基于标签的规范，如 Pod nodeSelectors 和 nodeAffinity。
|
||||
该机制允许您定义自己的拓扑边界，例如内部部署集群中的机架，而无需修改调度程序以了解这些自定义拓扑。
|
||||
|
||||
<!--
|
||||
In addition, the topology information is abstracted away from the pod specification, so a pod does not need knowledge of the underlying storage system’s topology characteristics. This means that you can use the same pod specification across multiple clusters, environments, and storage systems.
|
||||
-->
|
||||
此外，拓扑信息是从 Pod 规范中抽象出来的，因此 Pod 不需要了解底层存储系统的拓扑特征。
|
||||
这意味着您可以在多个集群、环境和存储系统中使用相同的 Pod 规范。
|
||||
|
||||
<!--
|
||||
## Getting Started
|
||||
-->
|
||||
## 入门
|
||||
|
||||
<!--
|
||||
To enable this feature, all you need to do is to create a StorageClass with `volumeBindingMode` set to `WaitForFirstConsumer`:
|
||||
-->
|
||||
要启用此功能，您需要做的就是创建一个将 `volumeBindingMode` 设置为 `WaitForFirstConsumer` 的 StorageClass：
|
||||
|
||||
```
|
||||
kind: StorageClass
|
||||
apiVersion: storage.k8s.io/v1
|
||||
metadata:
|
||||
name: topology-aware-standard
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
volumeBindingMode: WaitForFirstConsumer
|
||||
parameters:
|
||||
type: pd-standard
|
||||
```
|
||||
|
||||
<!--
|
||||
This new setting instructs the volume provisioner to not create a volume immediately, and instead, wait for a pod using an associated PVC to run through scheduling. Note that previous StorageClass `zone` and `zones` parameters do not need to be specified anymore, as pod policies now drive the decision of which zone to provision a volume in.
|
||||
-->
|
||||
这个新设置表明卷配置器不立即创建卷，而是等待使用关联的 PVC 的 Pod 通过调度运行。
|
||||
请注意，不再需要指定以前的 StorageClass `zone` 和 `zones` 参数，因为现在在哪个区域中配置卷由 Pod 策略决定。
|
||||
|
||||
<!--
|
||||
Next, create a pod and PVC with this StorageClass. This sequence is the same as before, but with a different StorageClass specified in the PVC. The following is a hypothetical example, demonstrating the capabilities of the new feature by specifying many pod constraints and scheduling policies:
|
||||
-->
|
||||
接下来，使用此 StorageClass 创建一个 Pod 和 PVC。
|
||||
此过程与之前相同，但在 PVC 中指定了不同的 StorageClass。
|
||||
以下是一个假设示例，通过指定许多 Pod 约束和调度策略来演示新功能特性：
|
||||
|
||||
<!--
|
||||
* multiple PVCs in a pod
|
||||
* nodeAffinity across a subset of zones
|
||||
* pod anti-affinity on zones
|
||||
-->
|
||||
* 一个 Pod 多个 PVC
|
||||
* 跨子区域的节点亲和
|
||||
* 同一区域 Pod 反亲和
|
||||
|
||||
```
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: web
|
||||
spec:
|
||||
serviceName: "nginx"
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
affinity:
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: failure-domain.beta.kubernetes.io/zone
|
||||
operator: In
|
||||
values:
|
||||
- us-central1-a
|
||||
- us-central1-f
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: app
|
||||
operator: In
|
||||
values:
|
||||
- nginx
|
||||
topologyKey: failure-domain.beta.kubernetes.io/zone
|
||||
containers:
|
||||
- name: nginx
|
||||
image: gcr.io/google_containers/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- name: www
|
||||
mountPath: /usr/share/nginx/html
|
||||
- name: logs
|
||||
mountPath: /logs
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: topology-aware-standard
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
- metadata:
|
||||
name: logs
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: topology-aware-standard
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
<!--
|
||||
Afterwards, you can see that the volumes were provisioned in zones according to the policies set by the pod:
|
||||
-->
|
||||
之后，您可以看到根据 Pod 设置的策略在区域中配置卷：
|
||||
|
||||
```
|
||||
$ kubectl get pv -o=jsonpath='{range .items[*]}{.spec.claimRef.name}{"\t"}{.metadata.labels.failure\-domain\.beta\.kubernetes\.io/zone}{"\n"}{end}'
|
||||
www-web-0 us-central1-f
|
||||
logs-web-0 us-central1-f
|
||||
www-web-1 us-central1-a
|
||||
logs-web-1 us-central1-a
|
||||
```
|
||||
|
||||
<!--
|
||||
## How can I learn more?
|
||||
-->
|
||||
## 我怎样才能了解更多？
|
||||
|
||||
<!--
|
||||
Official documentation on the topology-aware dynamic provisioning feature is available here:https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
|
||||
-->
|
||||
有关拓扑感知动态供应功能的官方文档可在此处获取：https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
|
||||
|
||||
<!--
|
||||
Documentation for CSI drivers is available at https://kubernetes-csi.github.io/docs/
|
||||
-->
|
||||
有关 CSI 驱动程序的文档，请访问：https://kubernetes-csi.github.io/docs/
|
||||
|
||||
<!--
|
||||
## What’s next?
|
||||
-->
|
||||
## 下一步是什么？
|
||||
|
||||
<!--
|
||||
We are actively working on improving this feature to support:
|
||||
-->
|
||||
我们正积极致力于改进此功能以支持：
|
||||
|
||||
<!--
|
||||
* more volume types, including dynamic provisioning for local volumes
|
||||
* dynamic volume attachable count and capacity limits per node
|
||||
-->
|
||||
* 更多卷类型，包括本地卷的动态供应
|
||||
* 动态容量可附加计数和每个节点的容量限制
|
||||
|
||||
<!--
|
||||
## How do I get involved?
|
||||
-->
|
||||
## 我如何参与？
|
||||
|
||||
<!--
|
||||
If you have feedback for this feature or are interested in getting involved with the design and development, join the [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). We’re rapidly growing and always welcome new contributors.
|
||||
-->
|
||||
如果您对此功能有反馈意见或有兴趣参与设计和开发，请加入 [Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)（SIG）。我们正在快速成长，并始终欢迎新的贡献者。
|
||||
|
||||
<!--
|
||||
Special thanks to all the contributors that helped bring this feature to beta, including Cheng Xing ([verult](https://github.com/verult)), Chuqiang Li ([lichuqiang](https://github.com/lichuqiang)), David Zhu ([davidz627](https://github.com/davidz627)), Deep Debroy ([ddebroy](https://github.com/ddebroy)), Jan Šafránek ([jsafrane](https://github.com/jsafrane)), Jordan Liggitt ([liggitt](https://github.com/liggitt)), Michelle Au ([msau42](https://github.com/msau42)), Pengfei Ni ([feiskyer](https://github.com/feiskyer)), Saad Ali ([saad-ali](https://github.com/saad-ali)), Tim Hockin ([thockin](https://github.com/thockin)), and Yecheng Fu ([cofyc](https://github.com/cofyc)).
|
||||
-->
|
||||
特别感谢帮助推出此功能的所有贡献者，包括 Cheng Xing ([verult](https://github.com/verult))、Chuqiang Li ([lichuqiang](https://github.com/lichuqiang))、David Zhu ([davidz627](https://github.com/davidz627))、Deep Debroy ([ddebroy](https://github.com/ddebroy))、Jan Šafránek ([jsafrane](https://github.com/jsafrane))、Jordan Liggitt ([liggitt](https://github.com/liggitt))、Michelle Au ([msau42](https://github.com/msau42))、Pengfei Ni ([feiskyer](https://github.com/feiskyer))、Saad Ali ([saad-ali](https://github.com/saad-ali))、Tim Hockin ([thockin](https://github.com/thockin))，以及 Yecheng Fu ([cofyc](https://github.com/cofyc))。
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
layout: blog
|
||||
title: '2018 年督导委员会选举结果'
|
||||
date: 2018-10-15
|
||||
---
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
title: '2018 Steering Committee Election Results'
|
||||
date: 2018-10-15
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- **Authors**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google) -->
|
||||
**作者**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google)
|
||||
|
||||
<!--
|
||||
## Results
|
||||
-->
|
||||
## 结果
|
||||
<!--
|
||||
The [Kubernetes Steering Committee Election](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/) is now complete and the following candidates came ahead to secure two year terms that start immediately:
|
||||
-->
|
||||
[Kubernetes 督导委员会选举](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/)现已完成，以下候选人获得了立即开始的两年任期：
|
||||
|
||||
* Aaron Crickenberger, Google, [@spiffxp](https://github.com/spiffxp)
|
||||
* Davanum Srinivas, Huawei, [@dims](https://github.com/dims)
|
||||
* Tim St. Clair, Heptio, [@timothysc](https://github.com/timothysc)
|
||||
|
||||
<!--
|
||||
## Big Thanks!
|
||||
-->
|
||||
## 十分感谢！
|
||||
|
||||
<!--
|
||||
* Steering Committee Member Emeritus [Quinton Hoole](https://github.com/quinton-hoole) for his service to the community over the past year. We look forward to
|
||||
* The candidates that came forward to run for election. May we always have a strong set of people who want to push community forward like yours in every election.
|
||||
* All 307 voters who cast a ballot.
|
||||
* And last but not least...Cornell University for hosting [CIVS](https://civs.cs.cornell.edu/)!
|
||||
-->
|
||||
* 督导委员会荣誉退休成员 [Quinton Hoole](https://github.com/quinton-hoole)，表扬他在过去一年为社区所作的贡献。我们期待着
|
||||
* 参加竞选的候选人。愿我们永远拥有一群强大的人，他们希望在每一次选举中都能像你们一样推动社区向前发展。
|
||||
* 共计 307 名选民参与投票。
|
||||
* 本次选举由康奈尔大学主办 [CIVS](https://civs.cs.cornell.edu/)！
|
||||
|
||||
<!--
|
||||
## Get Involved with the Steering Committee
|
||||
-->
|
||||
## 加入督导委员会
|
||||
<!--
|
||||
You can follow along to Steering Committee [backlog items](https://git.k8s.io/steering/backlog.md) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They meet bi-weekly on [Wednesdays at 8pm UTC](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors.
|
||||
-->
|
||||
你可以关注督导委员会的[任务清单](https://git.k8s.io/steering/backlog.md)，并通过向他们的[代码仓库](https://github.com/kubernetes/steering)提交 issue 或 PR 的方式来参与。他们也会在[UTC 时间每周三晚 8 点](https://github.com/kubernetes/steering)举行会议，并定期与我们的贡献者见面。
|
||||
|
||||
<!--
|
||||
Steering Committee Meetings:
|
||||
-->
|
||||
督导委员会会议：
|
||||
|
||||
* [YouTube 播放列表](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM)
|
||||
|
||||
<!--
|
||||
Meet Our Contributors Steering AMA’s:
|
||||
-->
|
||||
与我们的贡献者会面：
|
||||
|
||||
<!--
|
||||
* [Oct 3 2018](https://youtu.be/x6Jm8p0K-IQ)
|
||||
* [Sept 5 2018](https://youtu.be/UbxWV12Or58)
|
||||
-->
|
||||
|
||||
* [2018 年 10 月 3 日](https://youtu.be/x6Jm8p0K-IQ)
|
||||
* [2018 年 7 月 5 日](https://youtu.be/UbxWV12Or58)
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
---
|
||||
layout: "Blog"
|
||||
title: "Kubernetes 2018 年北美贡献者峰会"
|
||||
date: 2018-10-16
|
||||
---
|
||||
<!--
|
||||
---
|
||||
layout: "Blog"
|
||||
title: "Kubernetes 2018 North American Contributor Summit"
|
||||
date: 2018-10-16
|
||||
---
|
||||
-->
|
||||
<!--
|
||||
**Authors:**
|
||||
-->
|
||||
**作者：**
|
||||
<!--
|
||||
[Bob Killen][bob] (University of Michigan)
|
||||
[Sahdev Zala][sahdev] (IBM),
|
||||
[Ihor Dvoretskyi][ihor] (CNCF)
|
||||
-->
|
||||
[Bob Killen][bob]（密歇根大学）
|
||||
[Sahdev Zala][sahdev]（IBM），
|
||||
[Ihor Dvoretskyi][ihor]（CNCF）
|
||||
|
||||
<!--
|
||||
The 2018 North American Kubernetes Contributor Summit to be hosted right before
|
||||
[KubeCon + CloudNativeCon][kubecon] Seattle is shaping up to be the largest yet.
|
||||
-->
|
||||
2018 年北美 Kubernetes 贡献者峰会将在西雅图 [KubeCon + CloudNativeCon][kubecon] 会议之前举办，这将是迄今为止规模最大的一次盛会。
|
||||
<!--
|
||||
It is an event that brings together new and current contributors alike to
|
||||
connect and share face-to-face; and serves as an opportunity for existing
|
||||
contributors to help shape the future of community development. For new
|
||||
community members, it offers a welcoming space to learn, explore and put the
|
||||
contributor workflow to practice.
|
||||
-->
|
||||
这是一个将新老贡献者聚集在一起，面对面交流和分享的活动；并为现有的贡献者提供一个机会，帮助塑造社区发展的未来。它为新的社区成员提供了一个学习、探索和实践贡献工作流程的良好空间。
|
||||
|
||||
<!--
|
||||
Unlike previous Contributor Summits, the event now spans two-days with a more
|
||||
relaxed ‘hallway’ track and general Contributor get-together to be hosted from
|
||||
5-8pm on Sunday December 9th at the [Garage Lounge and Gaming Hall][garage], just
|
||||
a short walk away from the Convention Center. There, contributors can enjoy
|
||||
billiards, bowling, trivia and more; accompanied by a variety of food and drink.
|
||||
-->
|
||||
与之前的贡献者峰会不同，本次活动为期两天，有一个更为轻松的行程安排，一般贡献者将于 12 月 9 日（周日）下午 5 点至 8 点在距离会议中心仅几步远的 [Garage Lounge and Gaming Hall][garage] 举办峰会。在那里，贡献者也可以进行台球、保龄球等娱乐活动，而且还有各种食品和饮料。
|
||||
|
||||
<!--
|
||||
Things pick up the following day, Monday the 10th with three separate tracks:
|
||||
-->
|
||||
接下来的一天，也就是 10 号星期一，有三个独立的会议你可以选择参与：
|
||||
|
||||
<!--
|
||||
### New Contributor Workshop:
|
||||
A half day workshop aimed at getting new and first time contributors onboarded
|
||||
and comfortable with working within the Kubernetes Community. Staying for the
|
||||
duration is required; this is not a workshop you can drop into.
|
||||
-->
|
||||
### 新贡献者研讨会：
|
||||
|
||||
为期半天的研讨会旨在让新贡献者加入社区，并营造一个良好的 Kubernetes 社区工作环境。
|
||||
请在开会期间保持在场，该讨论会不允许随意进出。
|
||||
|
||||
<!--
|
||||
### Current Contributor Track:
|
||||
Reserved for those that are actively engaged with the development of the
|
||||
project; the Current Contributor Track includes Talks, Workshops, Birds of a
|
||||
Feather, Unconferences, Steering Committee Sessions, and more! Keep an eye on
|
||||
the [schedule in GitHub][schedule] as content is frequently being updated.
|
||||
-->
|
||||
### 当前贡献者追踪：
|
||||
|
||||
保留给那些积极参与项目开发的贡献者；目前的贡献者追踪包括讲座、研讨会、聚会、Unconferences 会议、指导委员会会议等等!
|
||||
请留意 [GitHub 中的时间表][时间表]，因为内容经常更新。
|
||||
|
||||
<!--
|
||||
### Docs Sprint:
|
||||
SIG-Docs will have a curated list of issues and challenges to be tackled closer
|
||||
to the event date.
|
||||
-->
|
||||
### Docs 冲刺：
|
||||
|
||||
SIG-Docs 将在活动日期临近的时候列出一个需要处理的问题和挑战列表。
|
||||
|
||||
<!--
|
||||
## To Register:
|
||||
To register for the Contributor Summit, see the [Registration section of the
|
||||
Event Details in GitHub][register]. Please note that registrations are being
|
||||
reviewed. If you select the “Current Contributor Track” and are not an active
|
||||
contributor, you will be asked to attend the New Contributor Workshop, or asked
|
||||
to be put on a waitlist. With thousands of contributors and only 300 spots, we
|
||||
need to make sure the right folks are in the room.
|
||||
-->
|
||||
## 注册：
|
||||
|
||||
要注册贡献者峰会，请参阅 Git Hub 上的[活动详情注册部分][注册]。请注意报名正在审核中。
|
||||
如果您选择了 “当前贡献者追踪”，而您却不是一个活跃的贡献者，您将被要求参加新贡献者研讨会，或者被要求进入候补名单。
|
||||
成千上万的贡献者只有 300 个位置，我们需要确保正确的人被安排席位。
|
||||
|
||||
<!--
|
||||
If you have any questions or concerns, please don’t hesitate to reach out to
|
||||
the Contributor Summit Events Team at community@kubernetes.io.
|
||||
-->
|
||||
如果您有任何问题或疑虑，请随时通过 community@kubernetes.io 联系贡献者峰会组织团队。
|
||||
|
||||
<!--
|
||||
Look forward to seeing everyone there!
|
||||
-->
|
||||
期待在那里看到每个人！
|
||||
|
||||
[bob]: https://twitter.com/mrbobbytables
|
||||
[sahdev]: https://twitter.com/sp_zala
|
||||
[ihor]: https://twitter.com/idvoretskyi
|
||||
[kubecon]: https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
|
||||
[garage]: https://www.garagebilliards.com/
|
||||
[时间表]: https://git.k8s.io/community/events/2018/12-contributor-summit#agenda
|
||||
[注册]: https://git.k8s.io/community/events/2018/12-contributor-summit#registration
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes 文档更新，国际版'
|
||||
date: 2018-11-08
|
||||
---
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes Docs Updates, International Edition'
|
||||
date: 2018-11-08
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- **Author**: Zach Corleissen (Linux Foundation) -->
|
||||
**作者**：Zach Corleissen （Linux 基金会）
|
||||
|
||||
<!-- As a co-chair of SIG Docs, I'm excited to share that Kubernetes docs have a fully mature workflow for localization (l10n). -->
|
||||
作为文档特别兴趣小组（SIG Docs）的联合主席，我很高兴能与大家分享 Kubernetes 文档在本地化（l10n）方面所拥有的一个完全成熟的工作流。
|
||||
|
||||
<!-- ## Abbreviations galore -->
|
||||
## 丰富的缩写
|
||||
|
||||
<!-- L10n is an abbreviation for _localization_. -->
|
||||
L10n 是 _localization_ 的缩写。
|
||||
|
||||
<!-- I18n is an abbreviation for _internationalization_. -->
|
||||
I18n 是 _internationalization_ 的缩写。
|
||||
|
||||
<!-- I18n is [what you do](https://www.w3.org/International/questions/qa-i18n) to make l10n easier. L10n is a fuller, more comprehensive process than translation (_t9n_). -->
|
||||
I18n 定义了[做什么](https://www.w3.org/International/questions/qa-i18n) 能让 l10n 更容易。而 L10n 更全面，相比翻译（ _t9n_ ）具备更完善的流程。
|
||||
|
||||
<!-- ## Why localization matters -->
|
||||
## 为什么本地化很重要
|
||||
|
||||
<!-- The goal of SIG Docs is to make Kubernetes easier to use for as many people as possible. -->
|
||||
SIG Docs 的目标是让 Kubernetes 更容易为尽可能多的人使用。
|
||||
|
||||
<!-- One year ago, we looked at whether it was possible to host the output of a Chinese team working independently to translate the Kubernetes docs. After many conversations (including experts on OpenStack l10n), [much transformation](https://kubernetes.io/blog/2018/05/05/hugo-migration/), and [renewed commitment to easier localization](https://github.com/kubernetes/website/pull/10485), we realized that open source documentation is, like open source software, an ongoing exercise at the edges of what's possible. -->
|
||||
一年前，我们研究了是否有可能由一个独立翻译 Kubernetes 文档的中国团队来主持文档输出。经过多次交谈（包括 OpenStack l10n 的专家），[多次转变](https://kubernetes.io/blog/2018/05/05/hugo-migration/)，以及[重新致力于更轻松的本地化](https://github.com/kubernetes/website/pull/10485)，我们意识到，开源文档就像开源软件一样，是在可能的边缘不断进行实践。
|
||||
|
||||
<!-- Consolidating workflows, language labels, and team-level ownership may seem like simple improvements, but these features make l10n scalable for increasing numbers of l10n teams. While SIG Docs continues to iterate improvements, we've paid off a significant amount of technical debt and streamlined l10n in a single workflow. That's great for the future as well as the present. -->
|
||||
整合工作流程、语言标签和团队级所有权可能看起来像是十分简单的改进，但是这些功能使 l10n 可以扩展到规模越来越大的 l10n 团队。随着 SIG Docs 不断改进，我们已经在单一工作流程中偿还了大量技术债务并简化了 l10n。这对未来和现在都很有益。
|
||||
|
||||
<!-- ## Consolidated workflow -->
|
||||
## 整合的工作流程
|
||||
|
||||
<!-- Localization is now consolidated in the [kubernetes/website](https://github.com/kubernetes/website) repository. We've configured the Kubernetes CI/CD system, [Prow](https://github.com/kubernetes/test-infra/tree/master/prow), to handle automatic language label assignment as well as team-level PR review and approval. -->
|
||||
现在，本地化已整合到 [kubernetes/website](https://github.com/kubernetes/website) 存储库。我们已经配置了 Kubernetes CI/CD 系统，[Prow](https://github.com/kubernetes/test-infra/tree/master/prow) 来处理自动语言标签分配以及团队级 PR 审查和批准。
|
||||
|
||||
<!-- ### Language labels -->
|
||||
### 语言标签
|
||||
|
||||
<!-- Prow automatically applies language labels based on file path. Thanks to SIG Docs contributor [June Yi](https://github.com/kubernetes/test-infra/pull/9835), folks can also manually assign language labels in pull request (PR) comments. For example, when left as a comment on an issue or PR, this command assigns the label `language/ko` (Korean). -->
|
||||
Prow 根据文件路径自动添加语言标签。感谢 SIG Docs 贡献者 [June Yi](https://github.com/kubernetes/test-infra/pull/9835)，他让人们还可以在 pull request（PR）注释中手动分配语言标签。例如，当为 issue 或 PR 留下下述注释时，将为之分配标签 `language/ko`（Korean）。
|
||||
|
||||
```
|
||||
/language ko
|
||||
```
|
||||
|
||||
|
||||
<!-- These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for [PRs with Chinese content](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh). -->
|
||||
这些存储库标签允许审阅者按语言过滤 PR 和 issue。例如，您现在可以过滤 kubernetes/website 面板中[具有中文内容的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh)。
|
||||
|
||||
<!-- ### Team review -->
|
||||
### 团队审核
|
||||
|
||||
<!-- L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/master/content/en/OWNERS) in the top subfolder for English content. -->
|
||||
L10n 团队现在可以审查和批准他们自己的 PR。例如，英语的审核和批准权限在位于用于显示英语内容的顶级子文件夹中的 [OWNERS 文件中指定](https://github.com/kubernetes/website/blob/master/content/en/OWNERS)。
|
||||
|
||||
<!-- Adding `OWNERS` files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency. -->
|
||||
将 `OWNERS` 文件添加到子目录可以让本地化团队审查和批准更改，而无需由可能并不擅长该门语言的审阅者进行批准。
|
||||
|
||||
<!-- ## What's next -->
|
||||
## 下一步是什么
|
||||
|
||||
<!-- We're looking forward to the [doc sprint in Shanghai](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) to serve as a resource for the Chinese l10n team. -->
|
||||
我们期待着[上海的 doc sprint](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) 能作为中国 l10n 团队的资源。
|
||||
|
||||
<!-- We're excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress. -->
|
||||
我们很高兴继续支持正在取得良好进展的日本和韩国 l10n 队伍。
|
||||
|
||||
<!-- If you're interested in localizing Kubernetes for your own language or region, check out our [guide to localizing Kubernetes docs](https://kubernetes.io/docs/contribute/localization/) and reach out to a [SIG Docs chair](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for support. -->
|
||||
如果您有兴趣将 Kubernetes 本地化为您自己的语言或地区，请查看我们的[本地化 Kubernetes 文档指南](https://kubernetes.io/docs/contribute/localization/)，并联系 [SIG Docs 主席团](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)获取支持。
|
||||
|
||||
<!-- ### Get involved with SIG Docs -->
|
||||
### 加入SIG Docs
|
||||
|
||||
<!-- If you're interested in Kubernetes documentation, come to a SIG Docs [weekly meeting](https://github.com/kubernetes/community/tree/master/sig-docs#meetings), or join [#sig-docs in Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/details/). -->
|
||||
如果您对 Kubernetes 文档感兴趣，请参加 SIG Docs [每周会议](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)，或在 [Kubernetes Slack 加入 #sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/details/)。
|
||||
@@ -3,7 +3,6 @@ layout: blog
|
||||
title: '新贡献者工作坊上海站'
|
||||
date: 2018-12-05
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
|
||||
@@ -1,15 +1,14 @@
|
||||
---
|
||||
title: 案例研究
|
||||
linkTitle: 案例研究
|
||||
bigheader: Kubernetes 用户案例研究
|
||||
abstract: 在生产环境中运行 Kubernetes 的用户集合。
|
||||
title: 案例分析
|
||||
linkTitle: 案例分析
|
||||
bigheader: Kubernetes 用户案例分析
|
||||
abstract: 在生产环境下使用 Kubernetes 的案例集
|
||||
layout: basic
|
||||
class: gridPage
|
||||
cid: caseStudies
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
---
|
||||
title: Case Studies
|
||||
linkTitle: Case Studies
|
||||
@@ -19,5 +18,4 @@ layout: basic
|
||||
class: gridPage
|
||||
cid: caseStudies
|
||||
---
|
||||
|
||||
-->
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: CCP Games
|
||||
content_url: https://cloud.google.com/customers/ccp-games/
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Goldman Sachs
|
||||
content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
@@ -0,0 +1,433 @@
|
||||
---
|
||||
title: 华为案例分析
|
||||
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_huawei.css
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Huawei Case Study
|
||||
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_huawei.css
|
||||
---
|
||||
-->
|
||||
|
||||
<div class="banner1">
|
||||
<h1> 案例分析：<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">以用户和供应商身份拥抱云原生</div></h1>
|
||||
<!--
|
||||
<h1> CASE STUDY:<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">Embracing Cloud Native as a User – and a Vendor</div></h1>
|
||||
-->
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
公司 <b>华为</b> 地点 <b>中国深圳</b> 产业 <b>通信设备</b>
|
||||
<!--
|
||||
Company <b>Huawei</b> Location <b>Shenzhen, China</b> Industry <b>Telecommunications Equipment</b>
|
||||
-->
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
|
||||
<section class="section1">
|
||||
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
<h2>挑战</h2>
|
||||
<!--
|
||||
<h2>Challenge</h2>
|
||||
-->
|
||||
华为是世界上最大的电信设备制造商，拥有超过 18 万名员工。
|
||||
<!--
|
||||
A multinational company that’s the largest telecommunications equipment manufacturer in the world,
|
||||
Huawei has more than 180,000 employees.
|
||||
-->
|
||||
|
||||
为了支持华为在全球的快速业务发展，<a href="http://www.huawei.com/">华为</a>内部 IT 部门有 8 个数据中心，
|
||||
这些数据中心在 100K+ VMs 上运行了 800 多个应用程序，服务于这 18 万用户。
|
||||
<!--
|
||||
In order to support its fast business development around the globe,
|
||||
<a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department,
|
||||
which have been running 800+ applications in 100K+ VMs to serve these 180,000 users.
|
||||
-->
|
||||
|
||||
随着新应用程序的快速增长，基于 VM 的应用程序的管理和部署的成本和效率都成为业务敏捷性的关键挑战。
|
||||
<!--
|
||||
With the rapid increase of new applications, the cost and efficiency of management and
|
||||
deployment of VM-based apps all became critical challenges for business agility.
|
||||
-->
|
||||
|
||||
该公司首席软件架构师、开源社区总监侯培新表示：
|
||||
“这是一个超大的分布式系统，因此我们发现，以更一致的方式管理所有任务始终是一个挑战。
|
||||
我们希望进入一种更敏捷、更得体的实践”。
|
||||
<!--
|
||||
"It’s very much a distributed system so we found that managing all of the tasks
|
||||
in a more consistent way is always a challenge," says Peixin Hou,
|
||||
the company’s Chief Software Architect and Community Director for Open Source.
|
||||
"We wanted to move into a more agile and decent practice."
|
||||
-->
|
||||
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
<h2>解决方案</h2>
|
||||
<!--
|
||||
<h2>Solution</h2>
|
||||
-->
|
||||
在决定使用容器技术后，华为开始将内部 IT 部门的应用程序迁移到<a href="http://kubernetes.io/"> Kubernetes </a>上运行。
|
||||
到目前为止，大约 30% 的应用程序已经转移为云原生程序。
|
||||
<!--
|
||||
After deciding to use container technology, Huawei began moving the internal I.T. department’s applications
|
||||
to run on <a href="http://kubernetes.io/">Kubernetes</a>.
|
||||
So far, about 30 percent of these applications have been transferred to cloud native.
|
||||
-->
|
||||
<br>
|
||||
<br>
|
||||
<h2>影响</h2>
|
||||
<!--
|
||||
<h2>Impact</h2>
|
||||
-->
|
||||
“到 2016 年底，华为的内部 IT 部门使用基于 Kubernetes 的平台即服务（PaaS）解决方案管理了 4000 多个节点和数万个容器。
|
||||
全局部署周期从一周缩短到几分钟，应用程序交付效率提高了 10 倍”。
|
||||
<!--
|
||||
"By the end of 2016, Huawei’s internal I.T. department managed more than 4,000 nodes with tens of thousands containers
|
||||
using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou.
|
||||
"The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold."
|
||||
-->
|
||||
|
||||
对于底线，侯培新表示，“我们还看到运营开支大幅削减，在某些情况下可削减 20% 到 30%，我们认为这对我们的业务非常有帮助”。
|
||||
<!--
|
||||
For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent,
|
||||
which we think is very helpful for our business."
|
||||
-->
|
||||
|
||||
这里给出一些华为内部结果资料、外部需求，也是公司的技术包装产品<a href="http://developer.huawei.com/ict/en/site-paas"> FusionStage™ </a>，
|
||||
它被作为一套 PaaS 解决方案提供给其客户。
|
||||
<!--
|
||||
Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies
|
||||
into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers.
|
||||
-->
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
“如果你是一个供应商，为了说服你的客户，你应该自己使用它。
|
||||
幸运的是，因为华为有很多员工，我们可以利用这种技术来展示我们所能构建的云的规模。”
|
||||
<!--
|
||||
"If you’re a vendor, in order to convince your customer, you should use it yourself.
|
||||
Luckily because Huawei has a lot of employees,
|
||||
we can demonstrate the scale of cloud we can build using this technology."
|
||||
-->
|
||||
|
||||
<br style="height:25px">
|
||||
<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;">
|
||||
<br>- 侯培新，首席软件架构师、开源社区总监
|
||||
<!--
|
||||
<br>- Peixin Hou, chief software architect and community director for open source
|
||||
-->
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section2">
|
||||
|
||||
<div class="fullcol">
|
||||
华为的 Kubernetes 之旅始于一位开发者。
|
||||
<!--
|
||||
Huawei’s Kubernetes journey began with one developer.
|
||||
-->
|
||||
|
||||
两年前，这家网络和电信巨头雇佣的一名工程师对<a href="http://kubernetes.io/"> Kubernetes </a>
|
||||
这一跨主机集群的管理应用程序容器的技术产生了兴趣，并开始为其开源社区作出贡献。
|
||||
<!--
|
||||
Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested
|
||||
in <a href="http://kubernetes.io/">Kubernetes</a>,
|
||||
the technology for managing application containers across clusters of hosts,
|
||||
and started contributing to its open source community.
|
||||
-->
|
||||
|
||||
随着技术和社区的发展，他不断地将这门技术告诉他的经理们。<br><br>
|
||||
<!--
|
||||
As the technology developed and the community grew, he kept telling his managers about it.<br><br>
|
||||
-->
|
||||
|
||||
与此同时，华为也在为其内部的企业 IT 部门寻找更好的编排系统，该系统应该支持每一个业务的流程处理。
|
||||
<!--
|
||||
And as fate would have it, at the same time,
|
||||
Huawei was looking for a better orchestration system for its internal enterprise I.T. department,
|
||||
which supports every business flow processing.
|
||||
-->
|
||||
|
||||
华为首席软件架构师、开源社区总监侯培新表示，
|
||||
“我们在全球拥有逾 18 万名员工，内部流程复杂，所以这个部门可能每周都需要开发一些新的应用程序。
|
||||
<!--
|
||||
"We have more than 180,000 employees worldwide, and a complicated internal procedure,
|
||||
so probably every week this department needs to develop some new applications," says Peixin Hou,
|
||||
Huawei’s Chief Software Architect and Community Director for Open Source.
|
||||
-->
|
||||
|
||||
我们的 IT 部门经常需要启动数万个容器，任务要跨越全球数千个节点。
|
||||
这是一个超大的分布式的系统，所以我们发现以更一致的方式管理所有的任务总是一个挑战”。<br><br>
|
||||
<!--
|
||||
"Very often our I.T. departments need to launch tens of thousands of containers,
|
||||
with tasks running across thousands of nodes across the world.
|
||||
It’s very much a distributed system, so we found that managing all of the tasks
|
||||
in a more consistent way is always a challenge."<br><br>
|
||||
-->
|
||||
|
||||
过去，华为曾使用虚拟机来封装应用程序，但是，“每次我们启动虚拟机时”，侯培新说，
|
||||
“无论是因为它是一项新服务，还是因为它是一项由于节点功能异常而被关闭的服务，都需要花费大量时间”。
|
||||
<!--
|
||||
In the past, Huawei had used virtual machines to encapsulate applications,
|
||||
but "every time when we start a VM," Hou says,
|
||||
"whether because it’s a new service or because it was a service that was shut down
|
||||
because of some abnormal node functioning, it takes a lot of time."
|
||||
-->
|
||||
|
||||
华为转向了容器化，所以是时候尝试 Kubernetes 了。
|
||||
采纳了这位工程师的建议花费了一年的时间，这个过程“不是一蹴而就的”，侯说，
|
||||
<!--
|
||||
Huawei turned to containerization, so the timing was right to try Kubernetes.
|
||||
It took a year to adopt that engineer’s suggestion – the process "is not overnight," says Hou –
|
||||
-->
|
||||
|
||||
但一旦投入使用，“Kubernetes 基本上解决了我们的大部分问题。
|
||||
以前，部署时间大约需要一周，现在只需几分钟。
|
||||
<!--
|
||||
but once in use, he says, "Kubernetes basically solved most of our problems.
|
||||
Before, the time of deployment took about a week, now it only takes minutes.
|
||||
-->
|
||||
|
||||
开发人员非常高兴。使用 Kubernetes 的那个部门也十分高兴”。<br><br>
|
||||
<!--
|
||||
The developers are happy. That department is also quite happy."<br><br>
|
||||
-->
|
||||
|
||||
侯培新看到了使用这项技术给公司带来的巨大好处，
|
||||
“Kubernetes 为基于云的应用程序带来了敏捷性、扩展能力和 DevOps 实践”，他说，
|
||||
<!--
|
||||
Hou sees great benefits to the company that come with using this technology:
|
||||
"Kubernetes brings agility, scale-out capability,
|
||||
and DevOps practice to the cloud-based applications," he says.
|
||||
-->
|
||||
|
||||
“它为我们提供了自定义调度体系结构的能力，这使得容器任务之间的关联性成为可能，从而提高了效率。
|
||||
它支持多种容器格式，同时广泛支持各种容器网络解决方案和容器存储方案”。
|
||||
<!--
|
||||
"It provides us with the ability to customize the scheduling architecture,
|
||||
which makes possible the affinity between container tasks that gives greater efficiency.
|
||||
It supports multiple container formats. It has extensive support for various container
|
||||
networking solutions and container storage."
|
||||
-->
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner3">
|
||||
<div class="banner3text">
|
||||
“Kubernetes 基本上解决了我们的大部分问题。
|
||||
以前，部署时间大约需要一周，现在只需几分钟。
|
||||
开发人员很高兴。使用 Kubernetes 的部门也很高兴。”
|
||||
<!--
|
||||
"Kubernetes basically solved most of our problems.
|
||||
Before, the time of deployment took about a week, now it only takes minutes.
|
||||
The developers are happy. That department is also quite happy."
|
||||
-->
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
最重要的是，这对底线有影响。侯培新说，
|
||||
“我们还看到，在某些情况下，运营开支会大幅削减 20% 到 30%，这对我们的业务非常有帮助”。<br><br>
|
||||
<!--
|
||||
And not least of all, there’s an impact on the bottom line.
|
||||
Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent,
|
||||
which is very helpful for our business."<br><br>
|
||||
-->
|
||||
|
||||
华为对这些初步结果感到满意，并看到客户对云原生技术的需求，因此加大了 Kubernetes 的投入。
|
||||
2016 年春，公司不仅成为用户，而且成为了供应商。<br><br>
|
||||
<!--
|
||||
Pleased with those initial results, and seeing a demand for cloud native technologies from its customers,
|
||||
Huawei doubled down on Kubernetes.
|
||||
In the spring of 2016, the company became not only a user but also a vendor.<br><br>
|
||||
-->
|
||||
|
||||
“我们构建了 Kubernetes 技术解决方案”，侯培新说，
|
||||
指的是华为的<a href="http://developer.huawei.com/ict/en/site-paas"> FusionStage™ </a> PaaS 输出。
|
||||
<!--
|
||||
"We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei’s
|
||||
<a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering.
|
||||
-->
|
||||
|
||||
“我们的客户，从非常大的电信运营商到银行，都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。
|
||||
但是他们需要花费大量的时间来分解他们的应用程序，将它们转换为微服务体系结构。
|
||||
作为解决方案提供者，我们帮助他们。
|
||||
<!--
|
||||
"Our customers, from very big telecommunications operators to banks, love the idea of cloud native.
|
||||
They like Kubernetes technology. But they need to spend a lot of time to decompose their applications
|
||||
to turn them into microservice architecture, and as a solution provider, we help them.
|
||||
-->
|
||||
|
||||
我们已经开始与一些中国银行合作，我们看到中国移动（China Mobile）和德国电信（Deutsche Telekom）等客户对我们很感兴趣”。<br><br>
|
||||
<!--
|
||||
We’ve started to work with some Chinese banks, and we see a lot of interest from our customers
|
||||
like <a href="http://www.chinamobileltd.com/">China Mobile</a> and
|
||||
<a href="https://www.telekom.com/en">Deutsche Telekom</a>."<br><br>
|
||||
-->
|
||||
|
||||
“如果你是一个用户，你就仅仅是个用户”，侯培新补充道，“但如果你是一个供应商，为了说服你的客户，你应该自己使用它。
|
||||
<!--
|
||||
"If you’re just a user, you’re just a user," adds Hou.
|
||||
"But if you’re a vendor, in order to even convince your customers, you should use it yourself.
|
||||
-->
|
||||
|
||||
幸运的是，因为华为有很多员工，我们可以利用这种技术来展示我们所能构建的云的规模，向客户提供智慧服务”。
|
||||
<!--
|
||||
Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology.
|
||||
We provide customer wisdom."
|
||||
-->
|
||||
|
||||
尽管华为拥有自己的私有云，但其许多客户使用华为的解决方案运行跨云应用程序。
|
||||
这是一个很大的卖点，大多数公共云提供商现在都支持 Kubernetes。
|
||||
侯培新说，“这使得跨云转换比其他解决方案更容易”。<br><br>
|
||||
<!--
|
||||
While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei’s solutions.
|
||||
It’s a big selling point that most of the public cloud providers now support Kubernetes.
|
||||
"This makes the cross-cloud transition much easier than with other solutions," says Hou.<br><br>
|
||||
-->
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner4">
|
||||
<div class="banner4text">
|
||||
“我们的客户，从非常大的电信运营商到银行，都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。
|
||||
但是他们需要花很多时间来分解他们的应用程序，把它们变成微服务体系结构，作为一个解决方案提供商，我们帮助他们。”
|
||||
<!--
|
||||
"Our customers, from very big telecommunications operators to banks, love the idea of cloud native.
|
||||
They like Kubernetes technology. But they need to spend a lot of time to decompose their applications
|
||||
to turn them into microservice architecture, and as a solution provider, we help them."
|
||||
-->
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section4">
|
||||
<div class="fullcol">
|
||||
|
||||
在华为内部，一旦他的团队完成内部业务流程部门向 Kubernetes 的转型，侯培新希望说服更多部门转向云原生开发和实践。
|
||||
<!--
|
||||
Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes,
|
||||
Hou is looking to convince more departments to move over to the cloud native development cycle and practice.
|
||||
-->
|
||||
|
||||
“我们有很多软件开发人员，所以我们将为他们提供我们的平台作为服务解决方案，我们自己的产品”，
|
||||
他说，“我们希望在他们的迭代周期中看到显著的成本削减”。<br><br>
|
||||
<!--
|
||||
"We have a lot of software developers,
|
||||
so we will provide them with our platform as a service solution, our own product," he says.
|
||||
"We would like to see significant cuts in their iteration cycle."<br><br>
|
||||
-->
|
||||
|
||||
在见证了华为最开始的向 Kubernetes 的转型之后，侯培新为其他考虑该技术的公司提供了建议，
|
||||
“当你开始设计应用程序的架构时，首先考虑云原生，然后再考虑微服务架构”，他说，“我想你会从中受益”。<br><br>
|
||||
<!--
|
||||
Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology:
|
||||
"When you start to design the architecture of your application, think about cloud native,
|
||||
think about microservice architecture from the beginning," he says.
|
||||
"I think you will benefit from that."<br><br>
|
||||
-->
|
||||
|
||||
但是如果您已经有了遗留应用程序，“首先从这些应用程序中一些对微服务友好的部分开始，
|
||||
这些部分相对容易分解成更简单的部分，并且相对轻量级”，侯培新说，
|
||||
<!--
|
||||
But if you already have legacy applications, "start from some microservice-friendly part of those applications first,
|
||||
parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says.
|
||||
-->
|
||||
|
||||
“不要从一开始就认为我想在几天内将整个架构或所有东西都迁移到微服务中。
|
||||
不要把它当作目标。你应该循序渐进地做这件事。
|
||||
我想说的是，对于遗留应用程序，并不是每个部分都适合微服务架构”。<br><br>
|
||||
<!--
|
||||
"Don’t think from day one that within how many days I want to move the whole architecture,
|
||||
or move everything into microservices. Don’t put that as a kind of target.
|
||||
You should do it in a gradual manner. And I would say for legacy applications,
|
||||
not every piece would be suitable for microservice architecture. No need to force it."<br><br>
|
||||
-->
|
||||
|
||||
毕竟，尽管侯培新对华为的 Kubernetes 充满热情，但他估计，
|
||||
“未来 10 年，或许 80% 的工作负载可以分布式地在云原生环境中运行，但仍然有 20% 不是，但是没关系。
|
||||
如果我们能够让 80% 的工作负载真正是云原生的、敏捷的，那么最终会有一个更好的世界”。
|
||||
<!--
|
||||
After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years,
|
||||
maybe 80 percent of the workload can be distributed, can be run on the cloud native environments.
|
||||
There’s still 20 percent that’s not, but it’s fine.
|
||||
If we can make 80 percent of our workload really be cloud native, to have agility,
|
||||
it’s a much better world at the end of the day."
|
||||
-->
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner5">
|
||||
<div class="banner5text">
|
||||
“未来 10 年，可能 80% 的工作负载可以分布式地在云原生环境中运行，但仍然有 20% 不是，不过没关系。
|
||||
如果我们能够让 80% 的工作负载真正是云原生的、敏捷的，那么最终会有一个更好的世界。”
|
||||
<!--
|
||||
"In the next 10 years, maybe 80 percent of the workload can be distributed,
|
||||
can be run on the cloud native environments.
|
||||
There’s still 20 percent that’s not, but it’s fine.
|
||||
If we can make 80 percent of our workload really be cloud native, to have agility,
|
||||
it’s a much better world at the end of the day."
|
||||
-->
|
||||
</div>
|
||||
</div>
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
在不久的将来，侯培新期待着围绕着 Kubernetes 开发的新功能，尤其是华为正在开发的那些功能。
|
||||
<!--
|
||||
In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes,
|
||||
not least of all the ones that Huawei is contributing to.
|
||||
-->
|
||||
|
||||
华为的工程师已经在为联邦功能(将多个 Kubernetes 集群放在一个框架中进行无缝管理)、调度、容器网络和存储，以及刚刚发布的一项名为
|
||||
<a href="http://containerops.org/"的> Container Ops </a>的技术工作，这是一个 DevOps 管道引擎。
|
||||
<!--
|
||||
Huawei engineers have worked on the federation feature
|
||||
(which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling,
|
||||
container networking and storage, and a just-announced technology called
|
||||
<a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine.
|
||||
-->
|
||||
|
||||
“这将把每个 DevOps 作业放到一个容器中”，他解释说，“这种容器机制使用 Kubernetes 运行，也用于测试 Kubernetes。
|
||||
有了这种机制，我们可以比以前更容易地创建、共享和管理容器化 DevOps 作业”。<br><br>
|
||||
<!--
|
||||
"This will put every DevOps job into a container," he explains.
|
||||
"And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes.
|
||||
With that mechanism, we can make the containerized DevOps jobs be created,
|
||||
shared and managed much more easily than before."<br><br>
|
||||
-->
|
||||
|
||||
尽管如此，侯培新认为这项技术只是实现其全部潜力的一半。
|
||||
首先，也是最重要的，他想要扩大它可以协调的规模，
|
||||
这对于华为这样的超大规模公司以及它的一些客户来说非常重要。<br><br>
|
||||
<!--
|
||||
Still, Hou sees this technology as only halfway to its full potential.
|
||||
First and foremost, he’d like to expand the scale it can orchestrate,
|
||||
which is important for supersized companies like Huawei – as well as some of its customers.<br><br>
|
||||
-->
|
||||
|
||||
侯培新自豪地指出，在华为第一位工程师成为 Kubernetes 的贡献者和传道者两年后，华为现在是这个社区的最大贡献者。
|
||||
他说，“我们发现，你对社区的贡献越大，你得到的回报也就越多”。
|
||||
<!--
|
||||
Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes,
|
||||
Huawei is now a top contributor to the community. "We’ve learned that the more you contribute to the community,"
|
||||
he says, "the more you get back."
|
||||
-->
|
||||
</div>
|
||||
</section>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: LivePerson
|
||||
content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Monzo
|
||||
content_url: https://youtu.be/YkOY7DgXKyw
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.4 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Philips
|
||||
content_url: https://cloud.google.com/customers/philips/
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 3.8 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Pokemon GO
|
||||
content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Samsung SDS
|
||||
content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: SoundCloud
|
||||
content_url: https://www.youtube.com/watch?v=5378N5iLb2Q
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: Squarespace 案例分析
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Squarespace Case Study
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- <div class="banner1 desktop" style="background-image: url('/images/CaseStudy_squarespace_banner1.jpg')">
|
||||
<h1> CASE STUDY:<img src="/images/squarespace_logo.png" class="header_logo"><br>
|
||||
<div class="subhead">Squarespace: Gaining Productivity and Resilience with Kubernetes</div>
|
||||
</h1>
|
||||
</div> -->
|
||||
|
||||
<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_squarespace_banner1.jpg')">
|
||||
<h1> 案例分析：<img src="/images/squarespace_logo.png" class="header_logo"><br>
|
||||
<div class="subhead">Squarespace: 借力 Kubernetes 提升效率和可靠性</div>
|
||||
</h1>
|
||||
</div>
|
||||
|
||||
<!-- <div class="details">
|
||||
Company <b>Squarespace</b> Location <b>New York, N.Y.</b> Industry <b>Software as a Service, Website-Building Platform</b>
|
||||
</div> -->
|
||||
|
||||
<div class="details">
|
||||
公司名 <b>Squarespace</b> 地址 <b>纽约市，纽约州</b> 行业 <b>软件服务，网站构建平台</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
<!-- <h2>Challenge</h2>
|
||||
Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down." -->
|
||||
<h2>挑战</h2>
|
||||
自从 2014 年，我们从 monolith 架构移植到微服务架构，
|
||||
“虽然解决了开发端的问题，但却带来了架构组的问题”，Squarespace 网站可靠性组的主任工程师 Kevin Lynch 说道。
|
||||
“5000 个 VM 主机上的部署过程，让每个人都举步维艰。”
|
||||
|
||||
<br>
|
||||
<!-- <h2>Solution</h2>
|
||||
The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in 2016. -->
|
||||
<h2>解决方案</h2>
|
||||
网站可靠性组开始尝试使用不同的容器编排平台，然后发现 Kubernetes “解决了我们所有的既有问题”，Lynch 说道。于是整个公司在 2016 年开始在自己的数据中心中运行 Kubernetes 集群。
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
<!-- <h2>Impact</h2>
|
||||
Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%.
|
||||
Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes,
|
||||
and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver,"
|
||||
he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."
|
||||
Resilience has also been improved with Kubernetes: "If a node goes down, it’s rescheduled immediately and there’s no performance impact." -->
|
||||
|
||||
<h2>影响</h2>
|
||||
自从 Squarespace 开始全面使用 Kubernetes，伴随着网络技术栈的革新，部署时间大幅减少85%。
|
||||
以前，他们的 VM 部署需要耗费半个小时；现在，Lynch 提到，“一个人可以生成一个模板应用，在五分钟内部署，并将实例容器化，并在模拟环境下运行。”正因为如此，“开发效率节省了大量的成本。”
|
||||
他又补充道，“当我们开始用 Kubernetes 时，我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。”
|
||||
Kubernetes 也同样提升了可靠性：“如果一个节点宕掉，马上会重新调度一个新的节点，没有任何性能上的影响。”
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/feQkzJkW-SA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
<br><br>“一旦你验证了 Kubernetes 可以解决一个问题，每个人都会立即着手解决其它的问题，无需你的布道。”
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Kevin Lynch，Squarespace 网站可靠性组的主任工程师</span>
|
||||
</div>
|
||||
</div>
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<!-- <h2>Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites.</h2> -->
|
||||
<h2>从 2003 年宿舍起步， Squarespace 已经为数百万人提供了网站构建服务。</h2>
|
||||
|
||||
<!-- Behind the scenes, though, the company’s monolithic Java application was making things not so simple for its developers to keep improving the platform.
|
||||
So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace’s Site Reliability team.
|
||||
"But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side,
|
||||
but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."<br><br> -->
|
||||
|
||||
但在幕后，公司的单体应用却让开发人员在平台创新上举步维艰。所以在 2014 年，公司决定”走微服务之路”，Kevin Lynch 提到，Squarespace 网站稳定性组的主任工程师。
|
||||
“但是我们还是一直在自己的 vCenter VMware 虚拟机[我们自己的数据中心]上部署应用。微服务解决了开发端的问题，但是让问题转变到了基础架构组这一边。我们在5000个虚拟机主机上的部署流程让每个人的开发效率都提高不起来。”
|
||||
|
||||
<!-- After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says,
|
||||
the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
|
||||
Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that.
|
||||
"We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.<br><br> -->
|
||||
|
||||
在尝试过另外一个容器编排平台，“非常痛苦地拆解它”，Lynch 说道，我们组开始在 2016 年年中尝试 Kubernetes，发现它“能解决我们所有的问题”。
|
||||
将 Kubernetes 部署在数据中心，而非公有云上是我们最大的挑战，但在当时，并没有很多其它的公司会这么做。
|
||||
“我们必须要自己摸索出如何在自己的基础架构中部署它，我们也必须要将其和我们其它的应用做集成，”Lynch补充道。<br><br>
|
||||
|
||||
<!-- At the same time, Squarespace’s Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network.
|
||||
"It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for
|
||||
<a href="https://github.com/containernetworking/cnihttps://github.com/containernetworking/cni">CNI networking for Kubernetes</a>,
|
||||
so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs." -->
|
||||
|
||||
与此同时，Squarespace 的网络工程组也正在革新它们的网络技术栈，从传统的 L2 网络转变为 L3 脊叶网络架构。
|
||||
“” Lynch 说道，“它给了我们服务器直接通过架顶交换机通信的能力。我们使用 Calico 作为
|
||||
<a href="https://github.com/containernetworking/cnihttps://github.com/containernetworking/cni">Kubernetes 的 CNI 网络插件</a>”，
|
||||
因而，我们可以为每个 Kubernetes pod 分配 IP 地址，并将它们和其它仍在虚拟机中创建的服务无缝衔接。
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_squarespace_banner3.jpg')">
|
||||
<!-- <div class="banner3text">
|
||||
After experimenting with another container orchestration platform and "breaking it in very painful ways,"
|
||||
Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
|
||||
</div> -->
|
||||
<div class="banner3text">
|
||||
在尝试过另外一个容器编排平台，“非常痛苦地拆解它”，Lynch 说道，我们组开始在 2016 年年中尝试 Kubernetes，发现它“能解决我们所有的问题”。
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
<!-- Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production.
|
||||
They also added Zipkin and CNCF projects <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> to their cloud native stack.
|
||||
"We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process,
|
||||
so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file,
|
||||
and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds.
|
||||
"Now there is little configuration variation." -->
|
||||
|
||||
几个月的时间，它们就有了一个稳定的集群供内部使用，并开始在生产环境下使用 Kubernetes。
|
||||
他们同时还在自己的云原生技术栈中用到了 Zipkin 和 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> 。
|
||||
“我们换到 Kubernetes，就像进入了一个新世界，我们也同时改进了其它的工具，” Lynch 说道。“它让我们简化了流程，因而，我们才能更加方便地从模板中创建整个微服务项目，生成代码和部署管道，生成 Docker 文件，
|
||||
并迅速地将可用的、可部署的项目发布到 Kubernetes 集群上。”在 Dev/QA/Stage/Prod 不同环境间的部署也变得 “异常的简单，” Lynch 补充道。
|
||||
“现在，环境间的配置差异变得很小。”
|
||||
|
||||
<br><br>
|
||||
<!-- And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
|
||||
"From end to end that probably took half an hour, and that’s not accounting for the fact that an infrastructure engineer would be responsible for doing that,
|
||||
so there’s some business delay in there as well." -->
|
||||
|
||||
而且整个部署过程只需要五分钟，和虚拟机部署相比，几乎节约了 85% 的时间。
|
||||
“从端到端可能要半个小时，这还没有考虑可能需要基础架构工程师来做这方面的工作，因而，也还有一些业务上的延时。”
|
||||
<br><br>
|
||||
<!-- With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service,
|
||||
and they just started integrating that with our storage back end without our involvement"—which wouldn’t have been possible before Kubernetes.
|
||||
He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." -->
|
||||
|
||||
部署变快之后，“开发效率节省了大量的成本，” Lynch 提到，“我们有个组想要实现新的文件存储服务，他们就径直和我们的存储后来做了集成，而不需要我们的参与”，这在采用 Kubernetes 之前是不可想象的。
|
||||
他又补充道：“在我们开始 Kubernetes 项目时，我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。”
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_squarespace_banner4.jpg')">
|
||||
<div class="banner4text">
|
||||
<!-- "We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates,"
|
||||
Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. -->
|
||||
|
||||
“我们换到 Kubernetes，就像进入了一个新世界....它让我们简化了流程，因而，我们才能更加方便地从模板中创建整个微服务项目，”
|
||||
Lynch 说道。整个部署过程只需要五分钟，和虚拟机部署相比，几乎节约了 85% 的时间。
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5" style="padding:0px !important">
|
||||
<div class="fullcol">
|
||||
<!-- There’s also been a positive impact on the application’s resilience. "When we’re deploying VMs, we have to build tooling to ensure that a service is
|
||||
spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down,
|
||||
it’s rescheduled immediately and there’s no performance impact." -->
|
||||
|
||||
同样在应用程序的可靠性方面也有积极的影响。“当我们在部署虚拟机时，我们需要工具来保障服务散布在机架间，可以承受失败，”他说道，“Kubernetes 正好可以做到这一点。如果节点宕掉，可以马上重新调度，没有性能影响。”
|
||||
<br><br>
|
||||
<!-- Another big benefit is autoscaling. "It wasn’t really possible with the way we’ve been using VMware," says Lynch, "but now we can just
|
||||
add the appropriate autoscaling features via Kubernetes directly, and boom, it’s scaling up as demand increases. And it worked out of the box." -->
|
||||
|
||||
另一个很大的好处就是扩缩容。“按照我们使用 VMware 的方式，扩缩容好像不可能实现，”Lynch 说道，“但现在，我们可以直接通过 Kubernetes 加入合适的扩缩容功能，然后，随着需求的增加而扩容。开箱即用！”
|
||||
<br><br>
|
||||
<!-- For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you’ve planned things out, just execute.
|
||||
Kubernetes has been really great for trying something out quickly and seeing if it works or not." -->
|
||||
|
||||
针对刚开始使用 Kubernetes 的人，Lynch 说他最后的建议就是“快速失败”：“一旦计划后，马上执行。Kubernetes 真的是非常适合快速实验，看看是否可行。”
|
||||
|
||||
</div>
|
||||
|
||||
<div class="banner5">
|
||||
<div class="banner5text">
|
||||
<!-- "When we’re deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure,"
|
||||
he says. "Kubernetes just does it. If a node goes down, it’s rescheduled immediately and there’s no performance impact." -->
|
||||
|
||||
“当我们在部署虚拟机时，我们需要工具来保障服务散布在机架间，可以承受失败，”他说道，“Kubernetes 正好可以做到这一点。如果节点宕掉，可以马上重新调度，没有性能影响。”
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
<!-- Lynch and his team are planning to open source some of the tools they’ve developed to extend Kubernetes and use it as an API itself.
|
||||
The first tool injects dependent applications as containers in a pod.
|
||||
"When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that,
|
||||
for example, fluentd for logging," he explains. With this tool, the developer doesn’t need to worry about the configurations. -->
|
||||
|
||||
Lynch 和他的小组正准备开源一些他们的工具，这些工具用来延展 Kubernetes，将其作为 API 使用。
|
||||
第一个工具在 pod 将依赖应用作为容器注入。
|
||||
“当你在发布应用时，常常需要一系列的依赖应用，例如，日志用的 fluentd，” 他解释道。
|
||||
有了这个工具，开发人员就不需要担心配置了。
|
||||
|
||||
<br><br>
|
||||
<!-- Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of
|
||||
existing services have been migrated. "Our monolithic application is going to be the last one, just because it’s so big and complex," says Lynch.
|
||||
"But now I’m seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it,
|
||||
it’s probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!" -->
|
||||
|
||||
自此之后，Squarespace 所有新的微服务都将直接部署到 Kubernetes 上，而最终的目标是要扩大到所有的服务上。
|
||||
现在已经有四分之一的服务已经移植完。“我的单体应用将是最后一个被移植的，仅仅是以为它太大、太复杂，”Lynch 说道。
|
||||
“但现在我已经看到其它的服务已经被移植到 Kubernetes 上，例如文件存储服务。有人解决了，而且并不复杂。
|
||||
所以我坚信如果我们着手解决它，很可能回避我们所担心的要轻松许多。也许我应该接受自己的建议，“快速失败”！”
|
||||
|
||||
</div>
|
||||
|
||||
</section>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: WePay
|
||||
content_url: http://thenewstack.io/wepay-kubernetes-changed-business/
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Yahoo! Japan
|
||||
content_url: https://kubernetes.io/blog/2016/10/kubernetes-and-openstack-at-yahoo-japan
|
||||
---
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: 社区
|
||||
layout: basic
|
||||
cid: community
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Community
|
||||
layout: basic
|
||||
cid: community
|
||||
---
|
||||
-->
|
||||
|
||||
<section id="mainContent">
|
||||
<main>
|
||||
<!-- <div class="content">
|
||||
<h3>Ensuring Kubernetes works well everywhere and for everyone.</h3>
|
||||
<p>Connect with the Kubernetes community on our <a href="http://slack.k8s.io/">Slack channel</a>, <a href="https://discuss.kubernetes.io/">discussion board</a>, or join the
|
||||
<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. A weekly
|
||||
community meeting takes place via video conference to discuss the state of affairs, see
|
||||
<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">these instructions</a> for information
|
||||
on how to participate.</p>
|
||||
<p>You can also join Kubernetes all around the world through our
|
||||
<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> and the
|
||||
<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a>.</p>
|
||||
</div> -->
|
||||
|
||||
<div class="content">
|
||||
<h3>保证 Kubernetes 到处都适用，每个人都喜欢。</h3>
|
||||
<p>在我们的<a href="http://slack.k8s.io/">Slack channel</a>,
|
||||
<a href="https://discuss.kubernetes.io/">讨论版</a>, 或者
|
||||
<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google 群主</a>上和 Kubernetes 互动。
|
||||
同时，每周我们也有社区视频会议，讨论最新进展。参见
|
||||
<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">这些指导</a>了解如何参与其中。</p>
|
||||
<p>你也可以在世界各地通过我们的
|
||||
<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup 社区</a> 以及
|
||||
<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup 社区</a>来参与。</p>
|
||||
</div>
|
||||
|
||||
<!-- <div class="content">
|
||||
<h3>Special Interest Groups (SIGs)</h3>
|
||||
<p>Have a special interest in how Kubernetes works with another technology? See our ever growing
|
||||
<a href="https://git.k8s.io/community/sig-list.md">lists of SIGs</a>,
|
||||
from AWS and Openstack to Big Data and Scalability, there's a place for you to contribute and instructions
|
||||
for forming a new SIG if your special interest isn't covered (yet).</p>
|
||||
|
||||
<p>As a member of the Kubernetes community, you are welcome to join any of the SIG meetings
|
||||
you are interested in. No registration required.</p>
|
||||
</div> -->
|
||||
|
||||
<div class="content">
|
||||
<h3>特殊兴趣小组 （Special Interest Groups，SIGs）</h3>
|
||||
<p>对于 Kubernetes 是如何和另外的技术协作感兴趣？了解下我们不停发展的
|
||||
<a href="https://git.k8s.io/community/sig-list.md">SIGs 群组</a>,
|
||||
从 AWS 和 Openstack 到 大数据和可扩展性，总会有一个适合你，如果你所关注的不在其列，也有指导帮助你成立新的 SIG。</p>
|
||||
|
||||
<p>作为 Kubernetes 社区的一员，你可以随意加入任何你感兴趣的 SIG 会议。不需要额外注册。</p>
|
||||
</div>
|
||||
|
||||
<!-- <div class="content">
|
||||
<h3>Code of Conduct</h3>
|
||||
<p>The Kubernetes community values respect and inclusiveness, and
|
||||
enforces a <a href="code-of-conduct/">Code of Conduct</a> in all
|
||||
interactions. If you notice a violation of the Code of Conduct at
|
||||
an event or meeting, in Slack, or in another communication
|
||||
mechanism, reach out to the <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a>
|
||||
<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
|
||||
Your anonymity will be protected.</p>
|
||||
</p>
|
||||
</div> -->
|
||||
|
||||
<div class="content">
|
||||
<h3>行为规范</h3>
|
||||
<p>Kubernetes 社区重视尊重和包容，并要求在所有场合都遵循
|
||||
<a href="code-of-conduct/">行为规范</a>。
|
||||
如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为，请联系
|
||||
<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes 行为规范委员会</a>
|
||||
<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
|
||||
我们会确保您的匿名性。</p>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
|
||||
<!-- <section id="talkToUs">
|
||||
<main>
|
||||
<h3>Talk to Us!</h3>
|
||||
<h4>We would love to hear from you, how you are using Kubernetes,<br> and what we can do to make it better.</h4>
|
||||
<div id="bigSocial">
|
||||
<div>
|
||||
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
|
||||
<p>Get the latest news and updates.</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
|
||||
<p>Check out the project and consider contributing.</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="http://slack.k8s.io/">#kubernetes-users</a>
|
||||
<p>Our Slack channel is the best way to contact our engineers and share your ideas with them.</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
|
||||
<p>Our user forum is a great place to go for community support.</p>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
</section> -->
|
||||
|
||||
<section id="talkToUs">
|
||||
<main>
|
||||
<h3>与我们联系！</h3>
|
||||
<h4>我们很希望听到你的声音，你是如何使用 Kubernetes 的，<br>以及我们可以将 Kubernetes 变得更美好。</h4>
|
||||
<div id="bigSocial">
|
||||
<div>
|
||||
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
|
||||
<p>获取更多的资讯和更新。</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="https://github.com/kubernetes/kubernetes">Github 项目</a>
|
||||
<p>了解项目，作出贡献。</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="http://slack.k8s.io/">#kubernetes-users</a>
|
||||
<p>Slack channel 是联系工程师，分享想法的最佳方法。</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
|
||||
<p>我们的论坛是获得社区支持的最佳地点。</p>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: 社区
|
||||
layout: basic
|
||||
cid: community
|
||||
css: /css/community.css
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
title: Community
|
||||
layout: basic
|
||||
cid: community
|
||||
css: /css/community.css
|
||||
--- -->
|
||||
|
||||
<div class="community_main">
|
||||
<!-- <h1>Kubernetes Community Code of Conduct</h1> -->
|
||||
<h1>Kubernetes 社区行为规范</h1>
|
||||
|
||||
<!-- Kubernetes follows the
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF Code of Conduct</a>.
|
||||
The text of the CNCF CoC is replicated below, as of
|
||||
<a href="https://github.com/cncf/foundation/blob/0ce4694e5103c0c24ca90c189da81e5408a46632/code-of-conduct.md">commit 0ce4694</a>.
|
||||
If you notice that this is out of date, please
|
||||
<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>. -->
|
||||
|
||||
Kubernetes 遵循
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF 行为规范</a>。
|
||||
CNCF 社区规范文本如下链接
|
||||
<a href="https://github.com/cncf/foundation/blob/0ce4694e5103c0c24ca90c189da81e5408a46632/code-of-conduct.md">commit 0ce4694</a>。
|
||||
如果您发现这个 CNCF 社区规范文本已经过时，请
|
||||
<a href="https://github.com/kubernetes/website/issues/new">提交 issue</a>。
|
||||
|
||||
<!-- If you notice a violation of the Code of Conduct at an event or meeting, in
|
||||
Slack, or in another communication mechanism, reach out to
|
||||
the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) <conduct@kubernetes.io>.
|
||||
Your anonymity will be protected. -->
|
||||
|
||||
如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为，请联系[Kubernetes 行为规范委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)<conduct@kubernetes.io>。
|
||||
我们会确保您的匿名性。
|
||||
|
||||
<div class="cncf_coc_container">
|
||||
{{< include "/static/cncf-code-of-conduct.md" >}}
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,5 @@
|
||||
<!-- The files in this directory have been imported from other sources. Do not
|
||||
edit them directly, except by replacing them with new versions. -->
|
||||
|
||||
本路径下的文件从其它地方导入。
|
||||
除了版本更新，不要直接修改。
|
||||
@@ -0,0 +1,46 @@
|
||||
<!-- Do not edit this file directly. Get the latest from
|
||||
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
|
||||
## CNCF Community Code of Conduct v1.0
|
||||
|
||||
### Contributor Code of Conduct
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of fostering
|
||||
an open and welcoming community, we pledge to respect all people who contribute
|
||||
through reporting issues, posting feature requests, updating documentation,
|
||||
submitting pull requests or patches, and other activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free experience for
|
||||
everyone, regardless of level of experience, gender, gender identity and expression,
|
||||
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
|
||||
religion, or nationality.
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery
|
||||
* Personal attacks
|
||||
* Trolling or insulting/derogatory comments
|
||||
* Public or private harassment
|
||||
* Publishing other's private information, such as physical or electronic addresses,
|
||||
without explicit permission
|
||||
* Other unethical or unprofessional conduct.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject
|
||||
comments, commits, code, wiki edits, issues, and other contributions that are not
|
||||
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
|
||||
commit themselves to fairly and consistently applying these principles to every aspect
|
||||
of managing this project. Project maintainers who do not follow or enforce the Code of
|
||||
Conduct may be permanently removed from the project team.
|
||||
|
||||
This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting
|
||||
the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) <conduct@kubernetes.io>.
|
||||
|
||||
This Code of Conduct is adapted from the Contributor Covenant
|
||||
(http://contributor-covenant.org), version 1.2.0, available at
|
||||
http://contributor-covenant.org/version/1/2/0/
|
||||
|
||||
### CNCF Events Code of Conduct
|
||||
|
||||
CNCF events are governed by the Linux Foundation [Code of Conduct](http://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
title: 文档
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
title: Home
|
||||
weight: 5
|
||||
--- -->
|
||||
|
||||
@@ -3,40 +3,40 @@ approvers:
|
||||
- bgrant0607
|
||||
- erictune
|
||||
- lavalamp
|
||||
title: Kubernetes API访问控制
|
||||
title: Kubernetes API 访问控制
|
||||
---
|
||||
|
||||
用户通过 `kubectl`、客户端库或者通过发送REST请求[访问API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和[Kubernetes服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行API访问。
|
||||
请求到达API服务器后会经过几个阶段，具体说明如图：
|
||||
用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。
|
||||
请求到达 API 服务器后会经过几个阶段，具体说明如图：
|
||||
|
||||
|
||||
|
||||
## 传输层安全
|
||||
|
||||
在典型的Kubernetes集群中，API通过443端口提供服务。
|
||||
API服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常
|
||||
包含该API服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的`$USER/.kube/config`。 如果集群中存在多个用户，则创建者需要与其他用户共享证书。
|
||||
在典型的 Kubernetes 集群中，API 通过 443 端口提供服务。
|
||||
API 服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常
|
||||
包含该 API 服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的 `$USER/.kube/config`。 如果集群中存在多个用户，则创建者需要与其他用户共享证书。
|
||||
|
||||
## 认证
|
||||
|
||||
一旦 TLS 连接建立，HTTP请求就进入到了认证的步骤。即图中的步骤 **1** 。
|
||||
集群创建脚本或集群管理员会为API服务器配置一个或多个认证模块。
|
||||
更具体的认证相关的描述详见 [这里](/docs/admin/authentication/)。
|
||||
一旦 TLS 连接建立，HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。
|
||||
集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。
|
||||
更具体的认证相关的描述详见[这里](/docs/admin/authentication/)。
|
||||
|
||||
认证步骤的输入是整个HTTP请求，但这里通常只是检查请求头和/或客户端证书。
|
||||
认证步骤的输入是整个 HTTP 请求，但这里通常只是检查请求头和 / 或客户端证书。
|
||||
|
||||
认证模块支持客户端证书，密码和Plain Tokens，
|
||||
Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
|
||||
认证模块支持客户端证书，密码和 Plain Tokens，
|
||||
Bootstrap Tokens，以及 JWT Tokens（用于服务账户）。
|
||||
|
||||
（管理员）可以同时设置多种认证模块，在设置了多个认证模块的情况下，每个模块会依次尝试认证，
|
||||
直到其中一个认证成功。
|
||||
|
||||
在 GCE 平台中，客户端证书，密码和Plain Tokens，Bootstrap Tokens，以及JWT Tokens同时被启用。
|
||||
在 GCE 平台中，客户端证书，密码和 Plain Tokens，Bootstrap Tokens，以及 JWT Tokens 同时被启用。
|
||||
|
||||
如果请求认证失败，则请求被拒绝，返回401状态码。
|
||||
如果请求认证失败，则请求被拒绝，返回 401 状态码。
|
||||
如果认证成功，则被认证为具体的 `username`，该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系，另一些则没有。
|
||||
|
||||
尽管Kubernetes使用 "用户名" 来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。
|
||||
尽管 Kubernetes 使用“用户名”来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。
|
||||
|
||||
## 授权
|
||||
|
||||
@@ -44,7 +44,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
|
||||
|
||||
请求须包含请求者的用户名，请求动作，以及该动作影响的对象。 如果存在相应策略，声明该用户具有进行相应操作的权限，则该请求会被授权。
|
||||
|
||||
例如，如果Bob有如下策略，那么他只能够读取`projectCaribou`命名空间下的pod资源：
|
||||
例如，如果 Bob 有如下策略，那么他只能够读取 `projectCaribou` 命名空间下的 pod 资源：
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -58,7 +58,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
|
||||
}
|
||||
}
|
||||
```
|
||||
如果Bob发起以下请求，那么请求能够通过授权，因为Bob被允许访问 `projectCaribou` 命名空间下的对象：
|
||||
如果 Bob 发起以下请求，那么请求能够通过授权，因为 Bob 被允许访问 `projectCaribou` 命名空间下的对象：
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -74,20 +74,20 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
|
||||
}
|
||||
}
|
||||
```
|
||||
如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。
|
||||
如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。
|
||||
|
||||
Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的，因为除Kubernetes外，这些访问控制系统还可能与其他的API进行交互。
|
||||
Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的，因为除 Kubernetes 外，这些访问控制系统还可能与其他的 API 进行交互。
|
||||
|
||||
Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook模式。 管理员创建集群时，会配置API服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝(HTTP状态码403)。
|
||||
Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhook 模式。 管理员创建集群时，会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes 将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝（HTTP 状态码 403）。
|
||||
|
||||
要了解更多的Kubernetes授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。
|
||||
要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。
|
||||
|
||||
|
||||
## 准入控制
|
||||
|
||||
准入控制模块是能够修改或拒绝请求的软件模块。
|
||||
作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。
|
||||
它们作用于对象的创建，删除，更新和连接 (proxy)阶段，但不包括对象的读取。
|
||||
它们作用于对象的创建，删除，更新和连接（proxy）阶段，但不包括对象的读取。
|
||||
|
||||
可以同时配置多个准入控制器，它们会按顺序依次被调用。
|
||||
|
||||
@@ -99,23 +99,23 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook
|
||||
|
||||
可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。
|
||||
|
||||
一旦请求通过所有准入控制器，将使用对应API对象的验证流程对其进行验证，然后写入对象存储 (如步骤 **4**)。
|
||||
一旦请求通过所有准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储 （如步骤 **4**）。
|
||||
|
||||
|
||||
## API的端口和IP
|
||||
## API 的端口和 IP
|
||||
|
||||
上述讨论适用于发送请求到API服务器的安全端口(典型情况)。
|
||||
实际上API服务器可以通过两个端口提供服务：
|
||||
上述讨论适用于发送请求到 API 服务器的安全端口（典型情况）。
|
||||
实际上 API 服务器可以通过两个端口提供服务：
|
||||
|
||||
默认情况下，API服务器在2个端口上提供HTTP服务：
|
||||
默认情况下，API 服务器在 2 个端口上提供 HTTP 服务：
|
||||
|
||||
1. `Localhost Port`:
|
||||
|
||||
- 用于测试和启动，以及管理节点的其他组件
|
||||
(scheduler, controller-manager)与API的交互
|
||||
- 没有TLS
|
||||
- 默认值为8080，可以通过 `--insecure-port` 标记来修改。
|
||||
- 默认的IP地址为localhost， 可以通过 `--insecure-bind-address`标记来修改。
|
||||
（scheduler, controller-manager）与 API 的交互
|
||||
- 没有 TLS
|
||||
- 默认值为 8080，可以通过 `--insecure-port` 标记来修改。
|
||||
- 默认的 IP 地址为 localhost， 可以通过 `--insecure-bind-address` 标记来修改。
|
||||
- 请求会 **绕过** 认证和鉴权模块。
|
||||
- 请求会被准入控制模块处理。
|
||||
- 其访问需要主机访问的权限。
|
||||
@@ -124,12 +124,12 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook
|
||||
|
||||
- 尽可能使用该端口访问
|
||||
- 应用 TLS。 可以通过 `--tls-cert-file` 设置证书， 通过 `--tls-private-key-file` 设置私钥。
|
||||
- 默认值为6443，可以通过 `--secure-port` 标记来修改。
|
||||
- 默认IP是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。
|
||||
- 默认值为 6443，可以通过 `--secure-port` 标记来修改。
|
||||
- 默认 IP 是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。
|
||||
- 请求会经过认证和鉴权模块处理。
|
||||
- 请求会被准入控制模块处理。
|
||||
- 要求认证和授权模块正常运行。
|
||||
|
||||
通过 `kube-up.sh`创建集群时， 对 Google Compute Engine (GCE)
|
||||
和一些其他的云供应商来说， API通过443端口提供服务。 对
|
||||
GCE而言，项目上配置了防火墙规则，允许外部的HTTPS请求访问API，其他（厂商的）集群设置方法各不相同。
|
||||
通过 `kube-up.sh` 创建集群时， 对 Google Compute Engine（GCE）
|
||||
和一些其他的云供应商来说， API 通过 443 端口提供服务。 对
|
||||
GCE 而言，项目上配置了防火墙规则，允许外部的 HTTPS 请求访问 API，其他（厂商的）集群设置方法各不相同。
|
||||
|
||||
@@ -16,63 +16,62 @@ content_template: templates/concept
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
在 Kubernetes 里，您必须经过身份验证(登录)，才能授权您的请求(授予访问权限).。有关认证的信息，请参阅[访问控制概述](/docs/admin/access-the-api/)。
|
||||
在 Kubernetes 里，您必须经过身份验证 ( 登录 )，才能授权您的请求 ( 授予访问权限 ).。有关认证的信息，请参阅[访问控制概述](/docs/admin/access-the-api/)。
|
||||
|
||||
Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用，该系统可以处理除 Kubernetes API 之外的其他 API。
|
||||
|
||||
## 确定请求是允许还是被拒绝
|
||||
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性，并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行，这意味着默认情况下是拒绝权限。
|
||||
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性，并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行，这意味着默认情况下是拒绝权限。
|
||||
|
||||
(虽然 Kubernetes 使用 API 服务器，访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
|
||||
( 虽然 Kubernetes 使用 API 服务器，访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
|
||||
|
||||
当配置多个授权模块时，按顺序检查每个模块，如果有任何模块授权请求，则可以继续执行该请求。如果所有模块拒绝请求，则拒绝该请求(HTTP状态代码403)。
|
||||
当配置多个授权模块时，按顺序检查每个模块，如果有任何模块授权请求，则可以继续执行该请求。如果所有模块拒绝请求，则拒绝该请求 (HTTP 状态代码 403)。
|
||||
|
||||
## 查看您的请求属性
|
||||
|
||||
Kubernetes 仅查看以下API请求属性:
|
||||
Kubernetes 仅查看以下 API 请求属性 :
|
||||
|
||||
* **user** - 验证期间提供的 `user` 字符串
|
||||
* **group** - 认证用户所属的组名列表
|
||||
* **“extra"** - 由认证层提供的任意字符串键到字符串值的映射
|
||||
* **API** - 指示请求是否用于API资源
|
||||
* **Request path** - 诸如`/api`或`/healthz`的其他非资源端点的路径(请参阅[kubectl](#kubectl)).
|
||||
* **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete`和`deletecollection`用于资源请求。要确定资源 API 端点的请求动词，请参阅**确定下面的请求动词**.
|
||||
* **HTTP request verb** - HTTP动词`get`，`post`，`put`和`delete`用于非资源请求
|
||||
* **Resource** - 正在访问的资源的ID或名称(仅适用于资源请求)
|
||||
--* 对于使用`get`, `update`, `patch`, 和 `delete`动词的资源请求，您必须提供资源名称。
|
||||
* **Subresource** - 正在访问的子资源(仅用于资源请求)
|
||||
* **Namespace** - 正在被访问的对象的命名空间(仅针对命名空间的资源请求)
|
||||
* **API group** - 正在访问的API组(仅用于资源请求). 一个空字符串指定[核心 API 组](/docs/api/).
|
||||
* **extra** - 由认证层提供的任意字符串键到字符串值的映射
|
||||
* **API** - 指示请求是否用于 API 资源
|
||||
* **Request path** - 诸如 `/api` 或 `/healthz` 的其他非资源端点的路径 ( 请参阅[kubectl](#kubectl)).
|
||||
* **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅**确定下面的请求动词**.
|
||||
* **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求
|
||||
* **Resource** - 正在访问的资源的 ID 或名称 ( 仅适用于资源请求 )，对于使用 `get`, `update`, `patch`, 和 `delete` 动词的资源请求，您必须提供资源名称。
|
||||
* **Subresource** - 正在访问的子资源 ( 仅用于资源请求 )
|
||||
* **Namespace** - 正在被访问的对象的命名空间 ( 仅针对命名空间的资源请求 )
|
||||
* **API group** - 正在访问的 API 组 ( 仅用于资源请求 ). 一个空字符串指定[核心 API 组](/docs/api/).
|
||||
|
||||
## 确定请求动词
|
||||
|
||||
要确定资源 API 端点的请求动词，请查看所使用的HTTP动词以及请求是否对单个资源或资源集合进行操作:
|
||||
要确定资源 API 端点的请求动词，请查看所使用的 HTTP 动词以及请求是否对单个资源或资源集合进行操作 :
|
||||
|
||||
HTTP动词| 请求动词
|
||||
HTTP 动词 | 请求动词
|
||||
---------- | ---------------
|
||||
POST | 创建
|
||||
GET，HEAD | 获取(个人资源)，列表(集合)
|
||||
GET，HEAD | 获取 ( 个人资源 )，列表 ( 集合 )
|
||||
PUT | 更新
|
||||
PATCH | 补丁
|
||||
DELETE| 删除(个人资源)，删除(收藏)
|
||||
DELETE| 删除 ( 个人资源 )，删除 ( 收藏 )
|
||||
|
||||
Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如:
|
||||
Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如 :
|
||||
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)在`extensions` API组中的`podsecuritypolicies`资源上检查`use`动词的授权。
|
||||
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在`rbac.authorization.k8s.io` API组中的`roles`和`clusterroles`资源上检查`bind`动词的授权。
|
||||
* [认证](/docs/admin/authentication/) 在核心API组中的`users`，`groups`和`serviceaccounts`上的`impersonate`动词的授权以及`authentication.k8s.io` API组中的`userextras`进行层次检查。
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) 在 `extensions` API 组中的 `podsecuritypolicies` 资源上检查 `use` 动词的授权。
|
||||
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在 `rbac.authorization.k8s.io` API 组中的 `roles` 和 `clusterroles` 资源上检查 `bind` 动词的授权。
|
||||
* [认证](/docs/admin/authentication/) 在核心 API 组中的 `users`，`groups` 和 `serviceaccounts` 上的 `impersonate` 动词的授权以及 `authentication.k8s.io` API 组中的 `userextras` 进行层次检查。
|
||||
|
||||
## 授权模块
|
||||
* **ABAC模式** - 基于属性的访问控制(ABAC)定义了访问控制范例，通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性(用户属性，资源属性，对象，环境属性等)。要了解有关使用ABAC模式的更多信息，请参阅[ABAC模式](/docs/admin/authorization/abac/)
|
||||
* **RBAC模式** - 基于角色的访问控制(RBAC)是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下，访问是单个用户执行特定任务(例如查看，创建或修改文件)的能力。要了解有关使用RBAC模式的更多信息，请参阅[RBAC模式](/docs/admin/authorization/rbac/)
|
||||
*当指定 "RBAC"(基于角色的访问控制)使用 "rbac.authorization.k8s.io" API组来驱动授权决定时，允许管理员通过Kubernetes API动态配置权限策略.
|
||||
.. *截至1.6 RBAC模式是测试版.
|
||||
.. *要启用RBAC，请使用 `--authorization-mode=RBAC` 启动 apiserver.
|
||||
* **Webhook模式** - WebHook 是HTTP回调:发生事件时发生的HTTP POST; 通过HTTP POST简单的事件通知. 实施 WebHooks 的 Web 应用程序将在某些事情发生时向URL发送消息. 要了解有关使用Webhook模式的更多信息，请参阅[Webhook模式](/docs/admin/authorization/webhook/)
|
||||
* **自定义模块** - 您可以创建使用Kubernetes的自定义模块. 要了解更多信息，请参阅下面的**自定义模块**。
|
||||
* **ABAC 模式** - 基于属性的访问控制 (ABAC) 定义了访问控制范例，通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性 ( 用户属性，资源属性，对象，环境属性等 )。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/docs/admin/authorization/abac/)
|
||||
* **RBAC 模式** - 基于角色的访问控制 (RBAC) 是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下，访问是单个用户执行特定任务 ( 例如查看，创建或修改文件 ) 的能力。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/docs/admin/authorization/rbac/)
|
||||
*当指定 "RBAC"( 基于角色的访问控制 ) 使用 "rbac.authorization.k8s.io" API 组来驱动授权决定时，允许管理员通过 Kubernetes API 动态配置权限策略 .
|
||||
.. *截至 1.6 RBAC 模式是测试版 .
|
||||
.. *要启用 RBAC，请使用 `--authorization-mode=RBAC` 启动 apiserver.
|
||||
* **Webhook 模式** - WebHook 是 HTTP 回调 : 发生事件时发生的 HTTP POST; 通过 HTTP POST 简单的事件通知 . 实施 WebHooks 的 Web 应用程序将在某些事情发生时向 URL 发送消息 . 要了解有关使用 Webhook 模式的更多信息，请参阅[Webhook 模式](/docs/admin/authorization/webhook/)
|
||||
* **自定义模块** - 您可以创建使用 Kubernetes 的自定义模块 . 要了解更多信息，请参阅下面的**自定义模块**。
|
||||
|
||||
### 自定义模块
|
||||
可以相当容易地开发其他实现,APIserver 调用 Authorizer 接口：
|
||||
可以相当容易地开发其他实现 ,APIserver 调用 Authorizer 接口：
|
||||
|
||||
```go
|
||||
type Authorizer interface {
|
||||
@@ -80,15 +79,15 @@ type Authorizer interface {
|
||||
}
|
||||
```
|
||||
|
||||
以确定是否允许每个API操作.
|
||||
以确定是否允许每个 API 操作 .
|
||||
|
||||
授权插件是实现此接口的模块.授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。
|
||||
授权插件是实现此接口的模块 . 授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。
|
||||
|
||||
授权模块可以完全实现，也可以拨出远程授权服务。 授权模块可以实现自己的缓存，以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。
|
||||
|
||||
#### 检查API访问
|
||||
#### 检查 API 访问
|
||||
|
||||
Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问API授权者决策的普通资源。 无论您选择使用哪个授权器，您都可以使用`SubjectAccessReview`发出一个`POST`，就像webhook授权器的`apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样，并回复一个响应。 例如：
|
||||
Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问 API 授权者决策的普通资源。 无论您选择使用哪个授权器，您都可以使用 `SubjectAccessReview` 发出一个 `POST`，就像 webhook 授权器的 `apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样，并回复一个响应。 例如：
|
||||
|
||||
|
||||
```bash
|
||||
@@ -128,16 +127,16 @@ subjectaccessreview "" created
|
||||
|
||||
## 为您的授权模块使用标志
|
||||
|
||||
您的策略中必须包含一个标志，以指出您的策略包含哪个授权模块:
|
||||
您的策略中必须包含一个标志，以指出您的策略包含哪个授权模块 :
|
||||
|
||||
可以使用以下标志:
|
||||
- `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。
|
||||
- `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用Kubernetes API创建和存储策略.
|
||||
- `--authorization-mode=Webhook` WebHook是一种HTTP回调模式，允许您使用远程REST管理授权。
|
||||
- `--authorization-mode=AlwaysDeny` 此标志阻止所有请求. 仅使用此标志进行测试。
|
||||
- `--authorization-mode=AlwaysAllow` 此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志。
|
||||
可以使用以下标志 :
|
||||
- `--authorization-mode=ABAC` 基于属性的访问控制 (ABAC) 模式允许您使用本地文件配置策略。
|
||||
- `--authorization-mode=RBAC` 基于角色的访问控制 (RBAC) 模式允许您使用 Kubernetes API 创建和存储策略 .
|
||||
- `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程 REST 管理授权。
|
||||
- `--authorization-mode=AlwaysDeny` 此标志阻止所有请求 . 仅使用此标志进行测试。
|
||||
- `--authorization-mode=AlwaysAllow` 此标志允许所有请求 . 只有在您不需要 API 请求授权的情况下才能使用此标志。
|
||||
|
||||
您可以选择多个授权模块. 如果其中一种模式为 `AlwaysAllow`，则覆盖其他模式，并允许所有API请求。
|
||||
您可以选择多个授权模块，如果其中一种模式为 `AlwaysAllow`，则覆盖其他模式，并允许所有 API 请求。
|
||||
|
||||
## 版本控制
|
||||
|
||||
|
||||
@@ -20,36 +20,36 @@ content_template: templates/concept
|
||||
|
||||
基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
|
||||
|
||||
此文件是 JSON 格式[每行都是一个JSON对象](http://jsonlines.org/)，不应存在封闭的列表或映射，每行只有一个映射。
|
||||
此文件是 JSON 格式[每行都是一个 JSON 对象](http://jsonlines.org/)，不应存在封闭的列表或映射，每行只有一个映射。
|
||||
|
||||
每一行都是一个 "策略对象"，策略对象是具有以下映射的属性:
|
||||
每一行都是一个 " 策略对象 "，策略对象是具有以下映射的属性 :
|
||||
|
||||
- 版本控制属性:
|
||||
- `apiVersion`，字符串类型: 有效值为"abac.authorization.kubernetes.io/v1beta1"，允许版本控制和转换策略格式。
|
||||
- `kind`，字符串类型: 有效值为 "Policy"，允许版本控制和转换策略格式。
|
||||
- `spec` 配置为具有以下映射的属性:
|
||||
- 匹配属性:
|
||||
- `user`，字符串类型; 来自 `--token-auth-file` 的用户字符串，如果你指定`user`，它必须与验证用户的用户名匹配。
|
||||
- `group`，字符串类型; 如果指定`group`，它必须与经过身份验证的用户的一个组匹配，`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。
|
||||
- 资源匹配属性:
|
||||
- `apiGroup`，字符串类型; 一个 API 组。
|
||||
- 例: `extensions`
|
||||
- 通配符: `*`匹配所有 API 组。
|
||||
- `namespace`，字符串类型; 一个命名空间。
|
||||
- 例如: `kube-system`
|
||||
- 通配符: `*` 匹配所有资源请求。
|
||||
- `resource`，字符串类型; 资源类型。
|
||||
- 例:`pods`
|
||||
- 通配符: `*`匹配所有资源请求。
|
||||
- 非资源匹配属性:
|
||||
- `nonResourcePath`，字符串类型; 非资源请求路径。
|
||||
- 例如:`/version`或`/apis`
|
||||
- 通配符:
|
||||
- 版本控制属性 :
|
||||
- `apiVersion`，字符串类型 : 有效值为 "abac.authorization.kubernetes.io/v1beta1"，允许版本控制和转换策略格式。
|
||||
- `kind`，字符串类型 : 有效值为 "Policy"，允许版本控制和转换策略格式。
|
||||
- `spec` 配置为具有以下映射的属性 :
|
||||
- 匹配属性 :
|
||||
- `user`，字符串类型 ; 来自 `--token-auth-file` 的用户字符串，如果你指定 `user`，它必须与验证用户的用户名匹配。
|
||||
- `group`，字符串类型 ; 如果指定 `group`，它必须与经过身份验证的用户的一个组匹配，`system:authenticated` 匹配所有经过身份验证的请求。`system:unauthenticated` 匹配所有未经过身份验证的请求。
|
||||
- 资源匹配属性 :
|
||||
- `apiGroup`，字符串类型 ; 一个 API 组。
|
||||
- 例 : `extensions`
|
||||
- 通配符 : `*` 匹配所有 API 组。
|
||||
- `namespace`，字符串类型 ; 一个命名空间。
|
||||
- 例如 : `kube-system`
|
||||
- 通配符 : `*` 匹配所有资源请求。
|
||||
- `resource`，字符串类型 ; 资源类型。
|
||||
- 例 :`pods`
|
||||
- 通配符 : `*` 匹配所有资源请求。
|
||||
- 非资源匹配属性 :
|
||||
- `nonResourcePath`，字符串类型 ; 非资源请求路径。
|
||||
- 例如 :`/version` 或 `/apis`
|
||||
- 通配符 :
|
||||
- `*` 匹配所有非资源请求。
|
||||
- `/foo/*` 匹配`/foo/`的所有子路径。
|
||||
- `/foo/*` 匹配 `/foo/` 的所有子路径。
|
||||
- `readonly`，键入 boolean，如果为 true，则表示该策略仅适用于 get，list 和 watch 操作。
|
||||
|
||||
**注意:** 未设置的属性与类型设置为零值的属性相同(例如空字符串，0、false)，然而未知的应该可读性优先。
|
||||
**注意 :** 未设置的属性与类型设置为零值的属性相同 ( 例如空字符串，0、false)，然而未知的应该可读性优先。
|
||||
|
||||
在将来，策略可能以 JSON 格式表示，并通过 REST 界面进行管理。
|
||||
|
||||
@@ -57,58 +57,58 @@ content_template: templates/concept
|
||||
|
||||
请求具有与策略对象的属性对应的属性。
|
||||
|
||||
当接收到请求时，确定属性。 未知属性设置为其类型的零值（例如: 空字符串，0，false）。
|
||||
当接收到请求时，确定属性。 未知属性设置为其类型的零值（例如 : 空字符串，0，false）。
|
||||
|
||||
设置为`“*"`的属性将匹配相应属性的任何值。
|
||||
设置为 `"*"` 的属性将匹配相应属性的任何值。
|
||||
|
||||
检查属性的元组，以匹配策略文件中的每个策略。 如果至少有一行匹配请求属性，则请求被授权（但可能会在稍后验证失败）。
|
||||
|
||||
要允许任何经过身份验证的用户执行某些操作，请将策略组属性设置为 `"system:authenticated“`。
|
||||
要允许任何经过身份验证的用户执行某些操作，请将策略组属性设置为 `"system:authenticated"`。
|
||||
|
||||
要允许任何未经身份验证的用户执行某些操作，请将策略组属性设置为`"system:authentication“`。
|
||||
要允许任何未经身份验证的用户执行某些操作，请将策略组属性设置为 `"system:authentication"`。
|
||||
|
||||
要允许用户执行任何操作，请使用 apiGroup，命名空间，
|
||||
资源和 nonResourcePath 属性设置为 `“*"`的策略.
|
||||
资源和 nonResourcePath 属性设置为 `"*"` 的策略。
|
||||
|
||||
要允许用户执行任何操作，请使用设置为`“*”` 的 apiGroup，namespace，resource 和 nonResourcePath 属性编写策略。
|
||||
要允许用户执行任何操作，请使用设置为 `"*"` 的 apiGroup，namespace，resource 和 nonResourcePath 属性编写策略。
|
||||
|
||||
## Kubectl
|
||||
|
||||
Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服务器版本。 通过创建/更新来验证发送到API的对象操作，kubectl 查询某些 swagger 资源。 对于API版本"v1", 那就是`/swaggerapi/api/v1` ＆ `/swaggerapi/ experimental/v1`。
|
||||
Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端 / 服务器版本。 通过创建 / 更新来验证发送到 API 的对象操作，kubectl 查询某些 swagger 资源。 对于 API 版本 "v1", 那就是 `/swaggerapi/api/v1` ＆ `/swaggerapi/ experimental/v1`。
|
||||
|
||||
当使用 ABAC 授权时，这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来(参见下面的[例子](#examples)):
|
||||
当使用 ABAC 授权时，这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来 ( 参见下面的[例子](#examples)):
|
||||
|
||||
* `/api`，`/api/*`，`/apis`和`/apis/*` 用于 API 版本协商.
|
||||
* `/version` 通过 `kubectl version` 检索服务器版本.
|
||||
* `/swaggerapi/*` 用于创建/更新操作.
|
||||
* `/api`，`/api/*`，`/apis` 和 `/apis/*` 用于 API 版本协商。
|
||||
* `/version` 通过 `kubectl version` 检索服务器版本。
|
||||
* `/swaggerapi/*` 用于创建 / 更新操作。
|
||||
|
||||
要检查涉及到特定kubectl操作的HTTP调用，您可以调整详细程度：
|
||||
要检查涉及到特定 kubectl 操作的 HTTP 调用，您可以调整详细程度：
|
||||
|
||||
kubectl --v=8 version
|
||||
|
||||
## 例子
|
||||
|
||||
1. Alice 可以对所有资源做任何事情:
|
||||
1. Alice 可以对所有资源做任何事情 :
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
|
||||
```
|
||||
2. Kubelet 可以读取任何pod:
|
||||
2. Kubelet 可以读取任何 pod:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
|
||||
```
|
||||
3. Kubelet 可以读写事件:
|
||||
3. Kubelet 可以读写事件 :
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
|
||||
```
|
||||
4. Bob 可以在命名空间“projectCaribou"中读取 pod:
|
||||
4. Bob 可以在命名空间 “projectCaribou” 中读取 pod：
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
|
||||
```
|
||||
5. 任何人都可以对所有非资源路径进行只读请求:
|
||||
5. 任何人都可以对所有非资源路径进行只读请求：
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
@@ -119,7 +119,7 @@ Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服
|
||||
|
||||
## 服务帐户的快速说明
|
||||
|
||||
服务帐户自动生成用户。 用户名是根据命名约定生成的:
|
||||
服务帐户自动生成用户。 用户名是根据命名约定生成的：
|
||||
|
||||
```shell
|
||||
system:serviceaccount:<namespace>:<serviceaccountname>
|
||||
@@ -130,13 +130,13 @@ system:serviceaccount:<namespace>:<serviceaccountname>
|
||||
system:serviceaccount:<namespace>:default
|
||||
```
|
||||
|
||||
例如，如果要将 API 的 kube-system 完整权限中的默认服务帐户授予，则可以将此行添加到策略文件中:
|
||||
例如，如果要将 API 的 kube-system 完整权限中的默认服务帐户授予，则可以将此行添加到策略文件中 :
|
||||
|
||||
```json
|
||||
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
|
||||
```
|
||||
|
||||
需要重新启动 apiserver 以获取新的策略行.
|
||||
需要重新启动 apiserver 以获取新的策略行。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -29,10 +29,10 @@ WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通
|
||||
clusters:
|
||||
- name: name-of-remote-authz-service
|
||||
cluster:
|
||||
certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的CA。
|
||||
certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的 CA。
|
||||
server: https://authz.example.com/authorize # 远程服务的查询 URL. 必须使用 'https'。
|
||||
|
||||
# users 代表 API 服务器的 webhook 配置.
|
||||
# users 代表 API 服务器的 webhook 配置 .
|
||||
users:
|
||||
- name: name-of-api-server
|
||||
user:
|
||||
@@ -55,7 +55,7 @@ contexts:
|
||||
|
||||
需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从 [版本兼容规则](/docs/api/) 。
|
||||
实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段以确保能被正确地反序列化。
|
||||
此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组(`--runtime-config=authorization.k8s.io/v1beta1=true`)。
|
||||
此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
|
||||
|
||||
|
||||
一个请求内容的例子：
|
||||
|
||||
@@ -15,8 +15,8 @@ Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
|
||||
|
||||
启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于
|
||||
`kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。
|
||||
控制器管理器中的控制器TokenCleaner能够删除过期的令牌。在节点发现的过程中Kubernetes会使用特殊的ConfigMap对象。
|
||||
控制器管理器中的BootstrapSigner控制器也会使用启动引导令牌为这类对象生成签名信息。
|
||||
控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。在节点发现的过程中 Kubernetes 会使用特殊的 ConfigMap 对象。
|
||||
控制器管理器中的 BootstrapSigner 控制器也会使用启动引导令牌为这类对象生成签名信息。
|
||||
|
||||
目前，启动引导令牌处于 **alpha** 阶段，但是预期也不会有大的突破性变化。
|
||||
|
||||
@@ -26,7 +26,7 @@ Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
|
||||
更加规范地说，它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。
|
||||
|
||||
令牌的第一部分是 "Token ID" ，它是公共信息。用于引用某个令牌，并确保不会泄露认证所使用的秘密信息。
|
||||
第二部分是 "令牌秘密（Token Secret）"，它应该被共享给收信的第三方。
|
||||
第二部分是“令牌秘密（Token Secret）”，它应该被共享给收信的第三方。
|
||||
|
||||
## 启用启动引导令牌
|
||||
|
||||
@@ -82,19 +82,19 @@ TokenCleaner 控制器会删除过期的令牌。
|
||||
|
||||
## 使用 `kubeadm` 管理令牌
|
||||
|
||||
你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群(`/etc/kubernetes/admin.conf`)
|
||||
你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群（`/etc/kubernetes/admin.conf`）
|
||||
自动抓取默认管理员密码。你可以通过参数 `--kubeconfig` 对下面命令指定一个另外的 kubeconfig 文件抓取密码。
|
||||
|
||||
* `kubeadm token list` 列举了令牌，同时显示了它们的过期时间和用途。
|
||||
* `kubeadm token create` 创建一个新令牌。
|
||||
* `--description` 设置新令牌的描述。
|
||||
* `--ttl duration` 设置令牌从 "现在" 起到过期时间的差值。
|
||||
* `--ttl duration` 设置令牌从“现在”起到过期时间的差值。
|
||||
默认是 0 ，也就是不过期。
|
||||
* `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。
|
||||
* `kubeadm token delete <token id>|<token id>.<token secret>` 删除令牌。
|
||||
令牌可以只用 ID 来确认，也可以用整个令牌的值。如果只用 ID 的情况下，密文不匹配的令牌也会被删除。
|
||||
|
||||
### ConfigMap签名
|
||||
### ConfigMap 签名
|
||||
|
||||
除了认证之外，令牌可以用于签名 ConfigMap。这在集群启动过程的早期，在客户端信任 API 服务器之前被使用。
|
||||
被签名的 ConfigMap 可以通过共享令牌被认证。
|
||||
@@ -131,6 +131,6 @@ ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件
|
||||
这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。
|
||||
|
||||
签名是一个 JWS 签名，使用了 "detached" 模式。为了检验签名，用户应该按照 JWS 规则
|
||||
(base64 编码而忽略结尾的 `=`)对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间
|
||||
（base64 编码而忽略结尾的 `=`）对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间
|
||||
，用于形成一个完整的 JWS。可以使用令牌的完整信息（比如 `07401b.f395accd246ae52d`）作为共享密钥，
|
||||
通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。
|
||||
|
||||
@@ -7,12 +7,12 @@ title: 创建大规模集群
|
||||
|
||||
## 支持规格
|
||||
|
||||
在 {{< param "version" >}}，Kubernetes支持最多5000节点规模的集群。 更具体地说，我们支持满足以下 *所有* 标准的配置：
|
||||
在 {{< param "version" >}}，Kubernetes 支持最多 5000 节点规模的集群。 更具体地说，我们支持满足以下 *所有* 标准的配置：
|
||||
|
||||
* 不超过5000节点
|
||||
* 总共不超过15000个pod
|
||||
* 总共不超过300000个容器
|
||||
* 每个节点不超过100个pod
|
||||
* 不超过 5000 节点
|
||||
* 总共不超过 15000 个 pod
|
||||
* 总共不超过 300000 个容器
|
||||
* 每个节点不超过 100 个 pod
|
||||
|
||||
<br>
|
||||
|
||||
@@ -21,64 +21,64 @@ title: 创建大规模集群
|
||||
|
||||
## 创建
|
||||
|
||||
集群是一组运行Kubernetes代理组件的节点(物理或虚拟机)，它们被 "master" (集群管理平面)所管理。
|
||||
集群是一组运行 Kubernetes 代理组件的节点（物理或虚拟机），它们被 `master`（集群管理平面）所管理。
|
||||
|
||||
一般来说，集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制，(例如，详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。
|
||||
一般来说，集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制，（例如，详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)）。
|
||||
|
||||
对很多云提供商来说，单纯地修改`NUM_NODES` 为一个非常大的值，可能会导致集群的创建脚本失败。 例如，在GCE中部署时，会因配额不足，导致集群启动失败。
|
||||
对很多云提供商来说，单纯地修改 `NUM_NODES` 为一个非常大的值，可能会导致集群的创建脚本失败。 例如，在 GCE 中部署时，会因配额不足，导致集群启动失败。
|
||||
|
||||
当建立一个大型的Kubernetes集群，以下几个问题必须考虑。
|
||||
当建立一个大型的 Kubernetes 集群，以下几个问题必须考虑。
|
||||
|
||||
### 配额问题
|
||||
|
||||
为了避免出现配额问题，当创建包含大量节点的集群时，考虑：
|
||||
|
||||
* 提高相关配额，如CPU，IP等。
|
||||
* 如，在 [GCE](https://cloud.google.com/compute/docs/resource-quotas)中，你可能需要提高以下资源的配额：
|
||||
* 提高相关配额，如 CPU，IP 等。
|
||||
* 如，在 [GCE](https://cloud.google.com/compute/docs/resource-quotas) 中，你可能需要提高以下资源的配额：
|
||||
* CPU
|
||||
* 虚机实例
|
||||
* 磁盘
|
||||
* 使用的IP地址
|
||||
* 使用的 IP 地址
|
||||
* 防火墙规则
|
||||
* 转发规则
|
||||
* 路由
|
||||
* 对象池
|
||||
* 设置创建脚本，使其以较小的规模分批次拉起新的节点，并在其间设置一定的等待时间，因为一些云供应商可能对虚机的创建速率进行了限制。
|
||||
|
||||
### Etcd存储
|
||||
### Etcd 存储
|
||||
|
||||
为了提升大规模集群的性能，我们将事件对象存储到独立的etcd实例中。
|
||||
为了提升大规模集群的性能，我们将事件对象存储到独立的 etcd 实例中。
|
||||
|
||||
创建集群时，当前的salt脚本：
|
||||
创建集群时，当前的 salt 脚本：
|
||||
|
||||
* 启动并配置额外的etcd实例
|
||||
* 配置api-server，将该etcd实例用于事件对象的存储
|
||||
* 启动并配置额外的 etcd 实例
|
||||
* 配置 api-server，将该 etcd 实例用于事件对象的存储
|
||||
|
||||
### 管理节点和组件的规格
|
||||
|
||||
在 GCE/Google Kubernetes Engine 或 AWS平台中， `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上，用户需要手动配置。 作为参考，GCE使用的规格为：
|
||||
在 GCE/Google Kubernetes Engine 或 AWS 平台中， `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上，用户需要手动配置。 作为参考，GCE 使用的规格为：
|
||||
|
||||
* 1-5 节点： n1-standard-1
|
||||
* 6-10 节点： n1-standard-2
|
||||
* 11-100 节点： n1-standard-4
|
||||
* 101-250 节点： n1-standard-8
|
||||
* 251-500 节点： n1-standard-16
|
||||
* 500节点以上： n1-standard-32
|
||||
* 500 节点以上： n1-standard-32
|
||||
|
||||
AWS使用的规格为：
|
||||
AWS 使用的规格为：
|
||||
|
||||
* 1-5 节点： m3.medium
|
||||
* 6-10 节点： m3.large
|
||||
* 11-100 节点： m3.xlarge
|
||||
* 101-250 节点： m3.2xlarge
|
||||
* 251-500 节点： c4.4xlarge
|
||||
* 500节点以上： c4.8xlarge
|
||||
* 500 节点以上： c4.8xlarge
|
||||
|
||||
注意，管理节点的规格只会在集群创建时进行设置，后续集群规模发生变化 (如 手动增删节点或集群自动扩缩容)后不会再调整。
|
||||
注意，管理节点的规格只会在集群创建时进行设置，后续集群规模发生变化（如手动增删节点或集群自动扩缩容）后不会再调整。
|
||||
|
||||
### 插件的资源占用
|
||||
|
||||
为防止 [集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) 耗尽节点资源引起内存泄漏或其他资源问题， Kubernetes 设置了插件容器资源的上限，来限制其对CPU和内存资源的占用 (参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files))。
|
||||
为防止[集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)耗尽节点资源引起内存泄漏或其他资源问题， Kubernetes 设置了插件容器资源的上限，来限制其对 CPU 和内存资源的占用（参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files)）。
|
||||
|
||||
例如：
|
||||
|
||||
@@ -92,31 +92,31 @@ AWS使用的规格为：
|
||||
memory: 200Mi
|
||||
```
|
||||
|
||||
除 Heapster 外，这些限制是静态的，基于4个节点规模的集群上运行的插件所采集的数据 (详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多 (详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整，插件可能会因为资源占用达到上限而不断被杀死。
|
||||
除 Heapster 外，这些限制是静态的，基于 4 个节点规模的集群上运行的插件所采集的数据（详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225)）。 而实际大规模集群中插件所消耗的资源要多得多（详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085)）。 所以如果部署大规模集群时不对这些值进行调整，插件可能会因为资源占用达到上限而不断被杀死。
|
||||
|
||||
为了避免集群插件的资源问题，创建多节点的集群时，考虑以下几点：
|
||||
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件的内存和CPU限制 (通过一个实例处理整个集群，因此其内存和CPU使用量往往与集群的大小/负载成比例增长)：
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件的内存和 CPU 限制（通过一个实例处理整个集群，因此其内存和 CPU 使用量往往与集群的大小/负载成比例增长）：
|
||||
* [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
|
||||
* [kubedns, dnsmasq, 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kubedns-controller.yaml.in)
|
||||
* [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件副本数 (每个组件有多个副本，因此增加副本将有助于处理增加的负载，但是，由于每个副本的负载也略有增加，也应考虑提高CPU /内存上限)：
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件副本数（每个组件有多个副本，因此增加副本将有助于处理增加的负载，但是，由于每个副本的负载也略有增加，也应考虑提高 CPU / 内存上限）：
|
||||
* [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
|
||||
* 当扩大集群规模时，如果涉及，略微扩大以下插件的内存和CPU限制 (每个节点一个副本， 但是CPU/内存使用随集群的大小/负载增长变化不明显)：
|
||||
* 当扩大集群规模时，如果涉及，略微扩大以下插件的内存和 CPU 限制（每个节点一个副本， 但是 CPU / 内存使用随集群的大小/负载增长变化不明显）：
|
||||
* [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
|
||||
* [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
|
||||
|
||||
Heapster的资源限制是基于集群的初始规模动态设置的 (参考 [#16185](http://issue.k8s.io/16185)
|
||||
和 [#22940](http://issue.k8s.io/22940))。 当发现Heapster资源耗尽，应考虑调整计算Heapster内存请求的公式 (参考上述PR)。
|
||||
Heapster 的资源限制是基于集群的初始规模动态设置的 ( 参考 [#16185](http://issue.k8s.io/16185)
|
||||
和 [#22940](http://issue.k8s.io/22940))。 当发现 Heapster 资源耗尽，应考虑调整计算 Heapster 内存请求的公式（参考上述 PR）。
|
||||
|
||||
关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。
|
||||
|
||||
[将来](http://issue.k8s.io/13048)，我们期望基于集群规模来设置集群插件的资源限制，并且在集群规模增长或缩小时能够动态调整。
|
||||
欢迎提出PR来实现这些特性。
|
||||
欢迎提出 PR 来实现这些特性。
|
||||
|
||||
### 启动时允许部分失败
|
||||
|
||||
因为种种原因 (详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969))，在 `NUM_NODES` 值很大的情况下执行
|
||||
因为种种原因（详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969)），在 `NUM_NODES` 值很大的情况下执行
|
||||
`kube-up.sh`， 可能因为其中一小部分节点没有正常启动而失败。
|
||||
这时我们有两种选择：重启集群 (`kube-down.sh` 然后再 `kube-up.sh`），或者在执行 `kube-up.sh`之前，
|
||||
这时我们有两种选择：重启集群（`kube-down.sh` 然后再 `kube-up.sh`），或者在执行 `kube-up.sh` 之前，
|
||||
将环境变量 `ALLOWED_NOTREADY_NODES` 设置为合适的值。 这将允许 `kube-up.sh` 以少于 `NUM_NODES` 的节点数量启动集群。 依据失败的具体原因，另外的节点可能在后面加入集群，或者集群节点数量将保持在 `NUM_NODES - ALLOWED_NOTREADY_NODES`。
|
||||
|
||||
@@ -6,12 +6,12 @@ title: 构建高可用集群
|
||||
## 简介
|
||||
|
||||
|
||||
本文描述了如何构建一个高可用（high-availability, HA）的Kubernetes集群。这是一个非常高级的主题。
|
||||
本文描述了如何构建一个高可用（high-availability, HA）的 Kubernetes 集群。这是一个非常高级的主题。
|
||||
|
||||
对于仅希望使用Kubernetes进行试验的用户，推荐使用更简单的配置工具进行搭建，例如：
|
||||
[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行Kubernetes。
|
||||
对于仅希望使用 Kubernetes 进行试验的用户，推荐使用更简单的配置工具进行搭建，例如：
|
||||
[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行 Kubernetes。
|
||||
|
||||
此外，当前在我们的端到端（e2e）测试环境中，没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项，但当前对单节点master的安装测试得更加严格。
|
||||
此外，当前在我们的端到端（e2e）测试环境中，没有对 Kubernetes 高可用的支持进行连续测试。我们将会增加这个连续测试项，但当前对单节点 master 的安装测试得更加严格。
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
@@ -23,10 +23,10 @@ title: 构建高可用集群
|
||||
|
||||
相关步骤如下：
|
||||
|
||||
* [创建可靠的组成节点，共同形成我们的高可用主节点实现。](#可靠的节点)
|
||||
* [使用etcd集群，搭建一个冗余的，可靠的存储层。](#建立一个冗余的，可靠的存储层)
|
||||
* [启动具有备份和负载均衡能力的Kubernetes API 服务](#复制的API服务)
|
||||
* [搭建运行master选举的Kubernetes scheduler和controller-manager守护程序](#进行master选举的组件)
|
||||
* [创建可靠的组成节点，共同形成我们的高可用主节点实现。](# 可靠的节点 )
|
||||
* [使用 etcd 集群，搭建一个冗余的，可靠的存储层。](# 建立一个冗余的，可靠的存储层 )
|
||||
* [启动具有备份和负载均衡能力的 Kubernetes API 服务](# 复制的 API 服务 )
|
||||
* [搭建运行 master 选举的 Kubernetes scheduler 和 controller-manager 守护程序](# 进行 master 选举的组件 )
|
||||
|
||||
系统完成时看起来应该像这样：
|
||||
|
||||
@@ -36,28 +36,28 @@ title: 构建高可用集群
|
||||
## 初始配置
|
||||
|
||||
|
||||
本文假设你正在搭建一个3节点的主节点集群，每个节点上都运行者某种Linux系统。
|
||||
本文假设你正在搭建一个 3 节点的主节点集群，每个节点上都运行者某种 Linux 系统。
|
||||
|
||||
指南中的示例使用Debian发行版，但它们应该可以被轻松移植到其他发行版上。
|
||||
指南中的示例使用 Debian 发行版，但它们应该可以被轻松移植到其他发行版上。
|
||||
|
||||
同样的，不管在公有云还是私有云亦或是裸机上，这个配置都应该可以运行。
|
||||
|
||||
|
||||
从一个现成的单主节点集群开始是实现一个高可用Kubernetes集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。
|
||||
从一个现成的单主节点集群开始是实现一个高可用 Kubernetes 集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。
|
||||
|
||||
## 可靠的节点
|
||||
|
||||
|
||||
我们在每个主节点上都将运行数个实现Kubernetes API的进程。使他们可靠的第一步是保证在发生故障时，每一个进程都可以自动重启。为了实现这个目标，我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的`kubelet`进程。这会带来便利性，因为我们使用了容器来分发我们的二进制文件，所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然，我们也需要一些手段来监控kubelete本身（在此监测监控者本身是一个有趣的话题）。对于Debian系统我们选择了monit，但也有许多可替代的工具。例如在基于systemd的系统上（如RHEL, CentOS），你可以运行 'systemctl enable kubelet'。
|
||||
我们在每个主节点上都将运行数个实现 Kubernetes API 的进程。使他们可靠的第一步是保证在发生故障时，每一个进程都可以自动重启。为了实现这个目标，我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的 `kubelet` 进程。这会带来便利性，因为我们使用了容器来分发我们的二进制文件，所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然，我们也需要一些手段来监控 kubelete 本身（在此监测监控者本身是一个有趣的话题）。对于 Debian 系统我们选择了 monit，但也有许多可替代的工具。例如在基于 systemd 的系统上（如 RHEL, CentOS），你可以运行 'systemctl enable kubelet'。
|
||||
|
||||
|
||||
如果你是从标准的Kubernetes安装扩展而来，那么`kubelet`二进制文件应该已经存在于你的系统中。你可以运行`which kubelet`来判断是否确实安装了这个二进制文件。如果没有安装的话，你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet),
|
||||
[kubelet init file](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet)脚本。
|
||||
如果你是从标准的 Kubernetes 安装扩展而来，那么 `kubelet` 二进制文件应该已经存在于你的系统中。你可以运行 `which kubelet` 来判断是否确实安装了这个二进制文件。如果没有安装的话，你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet),
|
||||
[kubelet init file](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet) 脚本。
|
||||
|
||||
如果使用monit，你还需要安装monit守护程序（`apt-get install monit`）以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和
|
||||
如果使用 monit，你还需要安装 monit 守护程序（`apt-get install monit`）以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和
|
||||
[monit-docker](/docs/admin/high-availability/monit-docker) 配置。
|
||||
|
||||
在使用systemd的系统上，你可以执行 `systemctl enable kubelet` 和 `systemctl enable docker`。
|
||||
在使用 systemd 的系统上，你可以执行 `systemctl enable kubelet` 和 `systemctl enable docker`。
|
||||
|
||||
|
||||
## 建立一个冗余的，可靠的存储层
|
||||
@@ -66,35 +66,35 @@ title: 构建高可用集群
|
||||
高可用方案的中心基础是一个冗余的，可靠的存储层。高可用的头条规则是保护数据。不管发生了什么，不管什么着了火，只要还有数据，你就可以重建。如果丢掉了数据，你就完了。
|
||||
|
||||
|
||||
集群化的etcd已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据，三个节点的物理（或虚拟）硬盘需要全部同时故障。这种情况发生的概率是比较低的，所以对于许多人来说，运行一个复制的etcd集群可能已经足够的可靠了。你可以将集群数量从3个增大到5个来增加集群的可靠性。如果那样还不够，你可以添加[更多的可靠性到你的存储层](#更加可靠的存储)。
|
||||
集群化的 etcd 已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据，三个节点的物理（或虚拟）硬盘需要全部同时故障。这种情况发生的概率是比较低的，所以对于许多人来说，运行一个复制的 etcd 集群可能已经足够的可靠了。你可以将集群数量从 3 个增大到 5 个来增加集群的可靠性。如果那样还不够，你可以添加[更多的可靠性到你的存储层](# 更加可靠的存储 )。
|
||||
|
||||
|
||||
### 集群化etcd
|
||||
### 集群化 etcd
|
||||
|
||||
|
||||
集群化etcd的完整细节超出了本文范围，你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md)找到许多详细内容。这个例子仅走查一个简单的集群建立过程，使用etcd内置的发现功能来构建我们的集群。
|
||||
集群化 etcd 的完整细节超出了本文范围，你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md) 找到许多详细内容。这个例子仅走查一个简单的集群建立过程，使用 etcd 内置的发现功能来构建我们的集群。
|
||||
|
||||
|
||||
首先，调用etcd发现服务来创建一个新令牌:
|
||||
首先，调用 etcd 发现服务来创建一个新令牌 :
|
||||
|
||||
```shell
|
||||
curl https://discovery.etcd.io/new?size=3
|
||||
```
|
||||
|
||||
|
||||
在每个节点上，拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到`/etc/kubernetes/manifests/etcd.yaml`。
|
||||
在每个节点上，拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到 `/etc/kubernetes/manifests/etcd.yaml`。
|
||||
|
||||
|
||||
每个节点上的kubelet会动态的监控这个文件夹的内容，并且会按照`etcd.yaml`里对pod的定义创建一个`etcd`服务的实例。
|
||||
每个节点上的 kubelet 会动态的监控这个文件夹的内容，并且会按照 `etcd.yaml` 里对 pod 的定义创建一个 `etcd` 服务的实例。
|
||||
|
||||
|
||||
请注意，你应该使用上文中获取的令牌URL替换全部三个节点上`etcd.yaml`中的`${DISCOVERY_TOKEN}`项。同时还应该将每个节点上的 `${NODE_NAME}`替换为一个不同的名字（例如：`node-1`），并将 `${NODE_IP}`替换为正确的IP地址。
|
||||
请注意，你应该使用上文中获取的令牌 URL 替换全部三个节点上 `etcd.yaml` 中的 `${DISCOVERY_TOKEN}` 项。同时还应该将每个节点上的 `${NODE_NAME}` 替换为一个不同的名字（例如：`node-1`），并将 `${NODE_IP}` 替换为正确的 IP 地址。
|
||||
|
||||
|
||||
#### 验证你的集群
|
||||
|
||||
|
||||
如果已经将这个文件拷贝到所有三个节点，你应该已经搭建起了一个集群化的etcd。你可以在主节点上进行验证：
|
||||
如果已经将这个文件拷贝到所有三个节点，你应该已经搭建起了一个集群化的 etcd。你可以在主节点上进行验证：
|
||||
```shell
|
||||
kubectl exec < pod_name > etcdctl member list
|
||||
```
|
||||
@@ -106,43 +106,43 @@ kubectl exec < pod_name > etcdctl cluster-health
|
||||
```
|
||||
|
||||
|
||||
你也可以在一个节点上运行 `etcdctl set foo bar`，在另一个节点上运行`etcdctl get foo`来验证集群是否工作正常。
|
||||
你也可以在一个节点上运行 `etcdctl set foo bar`，在另一个节点上运行 `etcdctl get foo` 来验证集群是否工作正常。
|
||||
|
||||
|
||||
### 更加可靠的存储
|
||||
|
||||
|
||||
当然，如果你对增加数据的可靠性感兴趣，这里还有一些更深入的选项可以使etcd把它的数据存放在比常规硬盘更可靠的地方（裤带和背带，ftw!）。
|
||||
当然，如果你对增加数据的可靠性感兴趣，这里还有一些更深入的选项可以使 etcd 把它的数据存放在比常规硬盘更可靠的地方（裤带和背带，ftw!）。
|
||||
|
||||
|
||||
如果你使用云服务，那么你的提供商通常会为你提供这个特性，例如Google Cloud Platform上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。
|
||||
如果你使用云服务，那么你的提供商通常会为你提供这个特性，例如 Google Cloud Platform 上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。
|
||||
|
||||
|
||||
如果运行于物理机之上，你仍然可以使用iSCSI或者NFS接口通过网络来连接冗余存储。
|
||||
此外，你还可以运行一个集群文件系统，比如Gluster或者Ceph。最后，你还可以在你的每个物理机器上运行RAID矩阵。
|
||||
如果运行于物理机之上，你仍然可以使用 iSCSI 或者 NFS 接口通过网络来连接冗余存储。
|
||||
此外，你还可以运行一个集群文件系统，比如 Gluster 或者 Ceph。最后，你还可以在你的每个物理机器上运行 RAID 矩阵。
|
||||
|
||||
|
||||
不管你选择如何实现，如果已经选择了使用其中的一个选项，那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享，那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导，我们都假设这个存储被挂载到你机器上的`/var/etcd/data`路径。
|
||||
不管你选择如何实现，如果已经选择了使用其中的一个选项，那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享，那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导，我们都假设这个存储被挂载到你机器上的 `/var/etcd/data` 路径。
|
||||
|
||||
|
||||
## 复制的API服务
|
||||
## 复制的 API 服务
|
||||
|
||||
|
||||
在正确搭建复制的etcd之后，我们还需要使用kubelet安装apiserver。
|
||||
在正确搭建复制的 etcd 之后，我们还需要使用 kubelet 安装 apiserver。
|
||||
|
||||
|
||||
|
||||
|
||||
首先，你需要创建初始的日志文件，这样Docker才会挂载一个文件而不是一个文件夹：
|
||||
首先，你需要创建初始的日志文件，这样 Docker 才会挂载一个文件而不是一个文件夹：
|
||||
```shell
|
||||
touch /var/log/kube-apiserver.log
|
||||
```
|
||||
|
||||
接下来，你需要在每个节点上创建一个`/srv/kubernetes/`文件夹。这个文件夹包含：
|
||||
接下来，你需要在每个节点上创建一个 `/srv/kubernetes/` 文件夹。这个文件夹包含：
|
||||
|
||||
* basic_auth.csv - 基本认证的用户名和密码
|
||||
* ca.crt - CA证书
|
||||
* known_tokens.csv - 实体（例如kubelet）用来和apiserver通信的令牌
|
||||
* ca.crt - CA 证书
|
||||
* known_tokens.csv - 实体（例如 kubelet）用来和 apiserver 通信的令牌
|
||||
* kubecfg.crt - 客户端证书，公钥
|
||||
* kubecfg.key - 客户端证书，私钥
|
||||
* server.cert - 服务端证书，公钥
|
||||
@@ -152,46 +152,46 @@ touch /var/log/kube-apiserver.log
|
||||
创建这个文件夹最简单的方法可以是从一个工作正常的集群的主节点拷贝，或者你也可以手动生成它们。
|
||||
|
||||
|
||||
### 启动API服务
|
||||
### 启动 API 服务
|
||||
|
||||
|
||||
一旦这些文件已经存在了，拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/`文件夹。
|
||||
一旦这些文件已经存在了，拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/` 文件夹。
|
||||
|
||||
|
||||
kubelet会监控这个文件夹，并且会按照文件里对pod的定义创建一个`kube-apiserver`容器。
|
||||
kubelet 会监控这个文件夹，并且会按照文件里对 pod 的定义创建一个 `kube-apiserver` 容器。
|
||||
|
||||
|
||||
### 负载均衡
|
||||
|
||||
|
||||
现在，你应该有3个全部正常工作的apiserver了。如果搭建了网络负载均衡器，你应该能够通过那个负载均衡器访问你的集群，并且看到负载在apiserver实例间分发。设置负载均衡器依赖于你的平台的实际情况，例如对于Google Cloud Platform的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/)找到。
|
||||
现在，你应该有 3 个全部正常工作的 apiserver 了。如果搭建了网络负载均衡器，你应该能够通过那个负载均衡器访问你的集群，并且看到负载在 apiserver 实例间分发。设置负载均衡器依赖于你的平台的实际情况，例如对于 Google Cloud Platform 的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/) 找到。
|
||||
|
||||
|
||||
请注意，如果使用了身份认证，你可能需要重新生成你的证书，除每个节点的IP地址外额外包含负载均衡器的IP地址。
|
||||
请注意，如果使用了身份认证，你可能需要重新生成你的证书，除每个节点的 IP 地址外额外包含负载均衡器的 IP 地址。
|
||||
|
||||
|
||||
对于部署在集群中的pods， `kubernetes`服务/dns名称应该自动的为主节点提供了负载均衡的endpoint。
|
||||
对于部署在集群中的 pods， `kubernetes` 服务 /dns 名称应该自动的为主节点提供了负载均衡的 endpoint。
|
||||
|
||||
|
||||
对于使用API的外部用户（如命令行运行的`kubectl`，持续集成管道或其他客户端）你会希望将他们配置成为访问外部负载均衡器的地址。
|
||||
对于使用 API 的外部用户（如命令行运行的 `kubectl`，持续集成管道或其他客户端）你会希望将他们配置成为访问外部负载均衡器的地址。
|
||||
|
||||
|
||||
## 进行Master选举的组件
|
||||
## 进行 Master 选举的组件
|
||||
|
||||
|
||||
到目前为止，我们已经搭建了状态存储，也搭建好了API服务，但我们还没有运行任何真正改变集群状态的服务，比如controller manager和scheduler。为了可靠的实现这个目标，我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点，我们打算在API中使用一个lease-lock来执行master选举。我们会对每一个scheduler和controller-manager使用`--leader-elect`标志，从而在API中使用一个租约来保证同一时间只有一个scheduler和controller-manager的实例正在运行。
|
||||
到目前为止，我们已经搭建了状态存储，也搭建好了 API 服务，但我们还没有运行任何真正改变集群状态的服务，比如 controller manager 和 scheduler。为了可靠的实现这个目标，我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点，我们打算在 API 中使用一个 lease-lock 来执行 master 选举。我们会对每一个 scheduler 和 controller-manager 使用 `--leader-elect` 标志，从而在 API 中使用一个租约来保证同一时间只有一个 scheduler 和 controller-manager 的实例正在运行。
|
||||
|
||||
|
||||
scheduler和controller-manager可以配置为只和位于它们相同节点（即127.0.0.1）上的API服务通信，也可以配置为使用API服务的负载均衡器的IP地址。不管它们如何配置，当使用`--leader-elect` 时scheduler和controller-manager都将完成上文提到的leader选举过程。
|
||||
scheduler 和 controller-manager 可以配置为只和位于它们相同节点（即 127.0.0.1）上的 API 服务通信，也可以配置为使用 API 服务的负载均衡器的 IP 地址。不管它们如何配置，当使用 `--leader-elect` 时 scheduler 和 controller-manager 都将完成上文提到的 leader 选举过程。
|
||||
|
||||
|
||||
为了防止访问API服务失败，选举出的leader不能通过更新租约来选举一个新的leader。当scheduler和controller-manager通过127.0.0.1访问API服务，而相同节点上的API服务不可用时，这一点相当重要。
|
||||
为了防止访问 API 服务失败，选举出的 leader 不能通过更新租约来选举一个新的 leader。当 scheduler 和 controller-manager 通过 127.0.0.1 访问 API 服务，而相同节点上的 API 服务不可用时，这一点相当重要。
|
||||
|
||||
|
||||
### 安装配置文件
|
||||
|
||||
|
||||
首先，在每个节点上创建空白日志文件，这样Docker就会挂载这些文件而不是创建一个新文件夹：
|
||||
首先，在每个节点上创建空白日志文件，这样 Docker 就会挂载这些文件而不是创建一个新文件夹：
|
||||
|
||||
```shell
|
||||
touch /var/log/kube-scheduler.log
|
||||
@@ -199,16 +199,16 @@ touch /var/log/kube-controller-manager.log
|
||||
```
|
||||
|
||||
|
||||
接下来，在每个节点上配置scheduler和controller manager pods的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到`/etc/kubernetes/manifests/` 文件夹。
|
||||
接下来，在每个节点上配置 scheduler 和 controller manager pods 的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到 `/etc/kubernetes/manifests/` 文件夹。
|
||||
|
||||
|
||||
## 结尾
|
||||
|
||||
|
||||
此时，你已经完成了master组件的配置（耶！），但你还需要添加工作者节点（噗！）。
|
||||
此时，你已经完成了 master 组件的配置（耶！），但你还需要添加工作者节点（噗！）。
|
||||
|
||||
|
||||
如果你有一个现成的集群，你只需要在每个节点上简单的重新配置你的kubeletes连接到负载均衡的endpoint并重启它们。
|
||||
如果你有一个现成的集群，你只需要在每个节点上简单的重新配置你的 kubeletes 连接到负载均衡的 endpoint 并重启它们。
|
||||
|
||||
|
||||
如果你搭建的是一个全新的集群，你将需要在每个工作节点上安装kubelet和kube-proxy，并设置 `--apiserver`指向复制的endpoint。
|
||||
如果你搭建的是一个全新的集群，你将需要在每个工作节点上安装 kubelet 和 kube-proxy，并设置 `--apiserver` 指向复制的 endpoint。
|
||||
@@ -9,7 +9,7 @@ notitle: true
|
||||
### 概要
|
||||
|
||||
|
||||
Kubernetes API server 为 api 对象验证并配置数据，包括 pods、 services、 replicationcontrollers和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端，所有其他组件通过它进行交互。
|
||||
Kubernetes API server 为 api 对象验证并配置数据，包括 pods、 services、 replicationcontrollers 和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端，所有其他组件通过它进行交互。
|
||||
|
||||
```
|
||||
kube-apiserver
|
||||
@@ -18,99 +18,99 @@ kube-apiserver
|
||||
### 选项
|
||||
```
|
||||
|
||||
--admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的NamespaceLifecycle列表。(默认值[AlwaysAdmit])
|
||||
--admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的 NamespaceLifecycle 列表。（默认值 [AlwaysAdmit]）
|
||||
|
||||
--admission-control-config-file string 包含准入控制配置的文件。
|
||||
|
||||
--advertise-address ip 向集群成员通知apiserver消息的IP地址。这个地址必须能够被集群中其他成员访问。如果IP地址为空，将会使用--bind-address，如果未指定--bind-address，将会使用主机的默认接口地址。
|
||||
--advertise-address ip 向集群成员通知 apiserver 消息的 IP 地址。这个地址必须能够被集群中其他成员访问。如果 IP 地址为空，将会使用 --bind-address，如果未指定 --bind-address，将会使用主机的默认接口地址。
|
||||
|
||||
--allow-privileged 如果为true, 将允许特权容器.
|
||||
--allow-privileged 如果为 true, 将允许特权容器。
|
||||
|
||||
--anonymous-auth 启用到API server的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为system:anonymous，用户组名为system:unauthenticated。（默认值true）
|
||||
--anonymous-auth 启用到 API server 的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为 system:anonymous，用户组名为 system:unauthenticated。（默认值 true）
|
||||
|
||||
--apiserver-count int 集群中运行的apiserver数量，必须为正数。（默认值1）
|
||||
--apiserver-count int 集群中运行的 apiserver 数量，必须为正数。（默认值 1）
|
||||
|
||||
--audit-log-maxage int 基于文件名中的时间戳，旧审计日志文件的最长保留天数。
|
||||
|
||||
--audit-log-maxbackup int 旧审计日志文件的最大保留个数.
|
||||
--audit-log-maxbackup int 旧审计日志文件的最大保留个数。
|
||||
|
||||
--audit-log-maxsize int 审计日志被轮转前的最大兆字节数。
|
||||
|
||||
--audit-log-path string 如果设置该值，所有到apiserver的请求都将会被记录到这个文件。'-'表示记录到标准输出。
|
||||
--audit-log-path string 如果设置该值，所有到 apiserver 的请求都将会被记录到这个文件。'-' 表示记录到标准输出。
|
||||
|
||||
--audit-policy-file string 定义审计策略配置的文件的路径。需要打开'AdvancedAuditing'特性开关。AdvancedAuditing需要一个配置来启用审计功能。
|
||||
--audit-policy-file string 定义审计策略配置的文件的路径。需要打开 'AdvancedAuditing' 特性开关。AdvancedAuditing 需要一个配置来启用审计功能。
|
||||
|
||||
--audit-webhook-config-file string 一个具有kubeconfig格式文件的路径，该文件定义了审计的webhook配置。需要打开'AdvancedAuditing'特性开关。
|
||||
--audit-webhook-config-file string 一个具有 kubeconfig 格式文件的路径，该文件定义了审计的 webhook 配置。需要打开 'AdvancedAuditing' 特性开关。
|
||||
|
||||
--audit-webhook-mode string 发送审计事件的策略。 Blocking模式表示正在发送事件时应该阻塞服务器的响应。 Batch模式使webhook异步缓存和发送事件。 Known模式为batch,blocking。 （默认值"batch")
|
||||
--audit-webhook-mode string 发送审计事件的策略。 Blocking 模式表示正在发送事件时应该阻塞服务器的响应。 Batch 模式使 webhook 异步缓存和发送事件。 Known 模式为 batch,blocking。（默认值 "batch")
|
||||
|
||||
--authentication-token-webhook-cache-ttl duration 从webhook令牌认证者获取的响应的缓存时长。(默认值2m0s)
|
||||
--authentication-token-webhook-cache-ttl duration 从 webhook 令牌认证者获取的响应的缓存时长。( 默认值 2m0s)
|
||||
|
||||
--authentication-token-webhook-config-file string 包含webhook配置的文件，用于令牌认证，具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。
|
||||
--authentication-token-webhook-config-file string 包含 webhook 配置的文件，用于令牌认证，具有 kubeconfig 格式。API server 将查询远程服务来决定对 bearer 令牌的认证。
|
||||
|
||||
--authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值"AlwaysAllow"）
|
||||
--authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值 "AlwaysAllow"）
|
||||
|
||||
--authorization-policy-file string 包含权限验证策略的csv文件，和--authorization-mode=ABAC一起使用，作用在安全端口上。
|
||||
--authorization-policy-file string 包含权限验证策略的 csv 文件，和 --authorization-mode=ABAC 一起使用，作用在安全端口上。
|
||||
|
||||
--authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s）
|
||||
--authorization-webhook-cache-authorized-ttl duration 从 webhook 授权者获得的 'authorized' 响应的缓存时长。（默认值 5m0s）
|
||||
|
||||
--authorization-webhook-cache-unauthorized-ttl duration 从webhook授权者获得的'unauthorized'响应的缓存时长。（默认值30s）
|
||||
--authorization-webhook-cache-unauthorized-ttl duration 从 webhook 授权者获得的 'unauthorized' 响应的缓存时长。（默认值 30s）
|
||||
|
||||
--authorization-webhook-config-file string 包含webhook配置的kubeconfig格式文件，和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。
|
||||
--authorization-webhook-config-file string 包含 webhook 配置的 kubeconfig 格式文件，和 --authorization-mode=Webhook 一起使用。API server 将查询远程服务来决定对 API server 安全端口的访问。
|
||||
|
||||
--azure-container-registry-config string 包含Azure容器注册表配置信息的文件的路径。
|
||||
--azure-container-registry-config string 包含 Azure 容器注册表配置信息的文件的路径。
|
||||
|
||||
--basic-auth-file string 如果设置该值，这个文件将会被用于准许通过http基本认证到API server安全端口的请求。
|
||||
--basic-auth-file string 如果设置该值，这个文件将会被用于准许通过 http 基本认证到 API server 安全端口的请求。
|
||||
|
||||
--bind-address ip 监听--seure-port的IP地址。被关联的接口必须能够被集群其它节点和CLI/web客户端访问。如果为空，则将使用所有接口（0.0.0.0）。（默认值0.0.0.0）
|
||||
--bind-address ip 监听 --seure-port 的 IP 地址。被关联的接口必须能够被集群其它节点和 CLI/web 客户端访问。如果为空，则将使用所有接口（0.0.0.0）。（默认值 0.0.0.0）
|
||||
|
||||
--cert-dir string 存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项，该标志将被忽略。（默认值 "/var/run/kubernetes"）
|
||||
--cert-dir string 存放 TLS 证书的目录。如果提供了 --tls-cert-file 和 --tls-private-key-file 选项，该标志将被忽略。（默认值 "/var/run/kubernetes"）
|
||||
|
||||
--client-ca-file string 如果设置此标志，对于任何请求，如果存包含client-ca-file中的authorities签名的客户端证书，将会使用客户端证书中的CommonName对应的身份进行认证。
|
||||
--client-ca-file string 如果设置此标志，对于任何请求，如果存包含 client-ca-file 中的 authorities 签名的客户端证书，将会使用客户端证书中的 CommonName 对应的身份进行认证。
|
||||
|
||||
--cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件.
|
||||
--cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件 .
|
||||
|
||||
--cloud-provider string 云服务提供商，空字符串表示无提供商。
|
||||
|
||||
--contention-profiling 如果已经启用profiling，则启用锁竞争profiling。
|
||||
--contention-profiling 如果已经启用 profiling，则启用锁竞争 profiling。
|
||||
|
||||
--cors-allowed-origins stringSlice CORS的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS.
|
||||
--cors-allowed-origins stringSlice CORS 的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用 CORS.
|
||||
|
||||
--delete-collection-workers int 用于DeleteCollection调用的工作者数量。这被用于加速namespace的清理。(默认值1)
|
||||
--delete-collection-workers int 用于 DeleteCollection 调用的工作者数量。这被用于加速 namespace 的清理。( 默认值 1)
|
||||
|
||||
--deserialization-cache-size int 在内存中缓存的反序列化json对象的数量。
|
||||
--deserialization-cache-size int 在内存中缓存的反序列化 json 对象的数量。
|
||||
|
||||
--enable-aggregator-routing 打开到endpoints IP的aggregator路由请求，替换cluster IP。
|
||||
--enable-aggregator-routing 打开到 endpoints IP 的 aggregator 路由请求，替换 cluster IP。
|
||||
|
||||
--enable-garbage-collector 启用通用垃圾回收器. 必须与kube-controller-manager对应的标志保持同步。 （默认值true）
|
||||
--enable-garbage-collector 启用通用垃圾回收器 . 必须与 kube-controller-manager 对应的标志保持同步。 （默认值 true）
|
||||
|
||||
--enable-logs-handler 如果为true，则为apiserver日志功能安装一个/logs处理器。（默认值true）
|
||||
--enable-logs-handler 如果为 true，则为 apiserver 日志功能安装一个 /logs 处理器。（默认值 true）
|
||||
|
||||
--enable-swagger-ui 在apiserver的/swagger-ui路径启用swagger ui。
|
||||
--enable-swagger-ui 在 apiserver 的 /swagger-ui 路径启用 swagger ui。
|
||||
|
||||
--etcd-cafile string 用于保护etcd通信的SSL CA文件。
|
||||
--etcd-cafile string 用于保护 etcd 通信的 SSL CA 文件。
|
||||
|
||||
--etcd-certfile string 用于保护etcd通信的的SSL证书文件。
|
||||
--etcd-certfile string 用于保护 etcd 通信的的 SSL 证书文件。
|
||||
|
||||
--etcd-keyfile string 用于保护etcd通信的SSL密钥文件.
|
||||
--etcd-keyfile string 用于保护 etcd 通信的 SSL 密钥文件 .
|
||||
|
||||
--etcd-prefix string 附加到所有etcd中资源路径的前缀。 （默认值"/registry"）
|
||||
--etcd-prefix string 附加到所有 etcd 中资源路径的前缀。 （默认值 "/registry"）
|
||||
|
||||
--etcd-quorum-read 如果为true, 启用quorum读。
|
||||
--etcd-quorum-read 如果为 true, 启用 quorum 读。
|
||||
|
||||
--etcd-servers stringSlice 连接的etcd服务器列表,形式为（scheme://ip:port)，使用逗号分隔。
|
||||
--etcd-servers stringSlice 连接的 etcd 服务器列表 , 形式为（scheme://ip:port)，使用逗号分隔。
|
||||
|
||||
--etcd-servers-overrides stringSlice 针对单个资源的etcd服务器覆盖配置, 以逗号分隔。 单个配置覆盖格式为: group/resource#servers, 其中servers形式为http://ip:port, 以分号分隔。
|
||||
--etcd-servers-overrides stringSlice 针对单个资源的 etcd 服务器覆盖配置 , 以逗号分隔。 单个配置覆盖格式为 : group/resource#servers, 其中 servers 形式为 http://ip:port, 以分号分隔。
|
||||
|
||||
--event-ttl duration 事件驻留时间。（默认值1h0m0s)
|
||||
--event-ttl duration 事件驻留时间。（默认值 1h0m0s)
|
||||
|
||||
--enable-bootstrap-token-auth 启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。
|
||||
--enable-bootstrap-token-auth 启用此选项以允许 'kube-system' 命名空间中的 'bootstrap.kubernetes.io/token' 类型密钥可以被用于 TLS 的启动认证。
|
||||
|
||||
--experimental-encryption-provider-config string 包含加密提供程序的配置的文件，该加密提供程序被用于在etcd中保存密钥。
|
||||
--experimental-encryption-provider-config string 包含加密提供程序的配置的文件，该加密提供程序被用于在 etcd 中保存密钥。
|
||||
|
||||
--external-hostname string 为此master生成外部URL时使用的主机名(例如Swagger API文档)。
|
||||
--external-hostname string 为此 master 生成外部 URL 时使用的主机名 ( 例如 Swagger API 文档 )。
|
||||
|
||||
--feature-gates mapStringBool 一个描述alpha/experimental特性开关的键值对列表。 选项包括:
|
||||
--feature-gates mapStringBool 一个描述 alpha/experimental 特性开关的键值对列表。 选项包括 :
|
||||
Accelerators=true|false (ALPHA - default=false)
|
||||
AdvancedAuditing=true|false (ALPHA - default=false)
|
||||
AffinityInAnnotations=true|false (ALPHA - default=false)
|
||||
@@ -128,102 +128,102 @@ RotateKubeletServerCertificate=true|false (ALPHA - default=false)
|
||||
StreamingProxyRedirects=true|false (BETA - default=true)
|
||||
TaintBasedEvictions=true|false (ALPHA - default=false)
|
||||
|
||||
--google-json-key string 用于认证的Google Cloud Platform服务账号的JSON密钥。
|
||||
--google-json-key string 用于认证的 Google Cloud Platform 服务账号的 JSON 密钥。
|
||||
|
||||
--insecure-allow-any-token username/group1,group2 如果设置该值, 你的服务将处于非安全状态。任何令牌都将会被允许，并将从令牌中把用户信息解析成为username/group1,group2。
|
||||
--insecure-allow-any-token username/group1,group2 如果设置该值 , 你的服务将处于非安全状态。任何令牌都将会被允许，并将从令牌中把用户信息解析成为 username/group1,group2。
|
||||
|
||||
--insecure-bind-address ip 用于监听--insecure-port的IP地址 (设置成0.0.0.0表示监听所有接口)。（默认值127.0.0.1)
|
||||
--insecure-bind-address ip 用于监听 --insecure-port 的 IP 地址 ( 设置成 0.0.0.0 表示监听所有接口 )。（默认值 127.0.0.1)
|
||||
|
||||
--insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则，使得这个端口不能从集群外访问。对集群的公共地址的443端口的访问将被代理到这个端口。默认设置中使用nginx实现。（默认值8080）
|
||||
--insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则，使得这个端口不能从集群外访问。对集群的公共地址的 443 端口的访问将被代理到这个端口。默认设置中使用 nginx 实现。（默认值 8080）
|
||||
|
||||
--kubelet-certificate-authority string 证书authority的文件路径。
|
||||
--kubelet-certificate-authority string 证书 authority 的文件路径。
|
||||
|
||||
--kubelet-client-certificate string 用于TLS的客户端证书文件路径。
|
||||
--kubelet-client-certificate string 用于 TLS 的客户端证书文件路径。
|
||||
|
||||
--kubelet-client-key string 用于TLS的客户端证书密钥文件路径.
|
||||
--kubelet-client-key string 用于 TLS 的客户端证书密钥文件路径 .
|
||||
|
||||
--kubelet-https 为kubelet启用https。 （默认值true）
|
||||
--kubelet-https 为 kubelet 启用 https。 （默认值 true）
|
||||
|
||||
--kubelet-preferred-address-types stringSlice 用于kubelet连接的首选NodeAddressTypes列表。 (默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
|
||||
--kubelet-preferred-address-types stringSlice 用于 kubelet 连接的首选 NodeAddressTypes 列表。 ( 默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
|
||||
|
||||
--kubelet-read-only-port uint 已废弃: kubelet端口. （默认值10255）
|
||||
--kubelet-read-only-port uint 已废弃 : kubelet 端口 . （默认值 10255）
|
||||
|
||||
--kubelet-timeout duration kubelet操作超时时间。（默认值
|
||||
--kubelet-timeout duration kubelet 操作超时时间。（默认值
|
||||
5s）
|
||||
|
||||
--kubernetes-service-node-port int 如果不为0，Kubernetes master服务（用于创建/管理apiserver）将会使用NodePort类型，并将这个值作为端口号。如果为0，Kubernetes master服务将会使用ClusterIP类型。
|
||||
--kubernetes-service-node-port int 如果不为 0，Kubernetes master 服务（用于创建 / 管理 apiserver）将会使用 NodePort 类型，并将这个值作为端口号。如果为 0，Kubernetes master 服务将会使用 ClusterIP 类型。
|
||||
|
||||
--master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"）
|
||||
--master-service-namespace string 已废弃 : 注入到 pod 中的 kubernetes master 服务的命名空间。（默认值 "default"）
|
||||
|
||||
--max-connection-bytes-per-sec int 如果不为0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。
|
||||
--max-connection-bytes-per-sec int 如果不为 0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。
|
||||
|
||||
--max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值200）
|
||||
--max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0 值表示没有限制。（默认值 200）
|
||||
|
||||
--max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值400）
|
||||
--max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0 值表示没有限制。（默认值 400）
|
||||
|
||||
--min-request-timeout int 一个可选字段，表示一个handler在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值1800）。
|
||||
--min-request-timeout int 一个可选字段，表示一个 handler 在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求 handler 有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值 1800）。
|
||||
|
||||
--oidc-ca-file string 如果设置该值，将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证，否则将会使用主机的根CA对其进行验证。
|
||||
--oidc-ca-file string 如果设置该值，将会使用 oidc-ca-file 中的任意一个 authority 对 OpenID 服务的证书进行验证，否则将会使用主机的根 CA 对其进行验证。
|
||||
|
||||
--oidc-client-id string 使用OpenID连接的客户端的ID，如果设置了oidc-issuer-url，则必须设置这个值。
|
||||
--oidc-client-id string 使用 OpenID 连接的客户端的 ID，如果设置了 oidc-issuer-url，则必须设置这个值。
|
||||
|
||||
--oidc-groups-claim string 如果提供该值，这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
--oidc-groups-claim string 如果提供该值，这个自定义 OpenID 连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
|
||||
--oidc-issuer-url string OpenID颁发者URL，只接受HTTPS方案。如果设置该值，它将被用于验证OIDC JSON Web Token(JWT)。
|
||||
--oidc-issuer-url string OpenID 颁发者 URL，只接受 HTTPS 方案。如果设置该值，它将被用于验证 OIDC JSON Web Token(JWT)。
|
||||
|
||||
--oidc-username-claim string 用作用户名的OpenID声明值。注意，不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
--oidc-username-claim string 用作用户名的 OpenID 声明值。注意，不保证除默认 ('sub') 外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
|
||||
--profiling 在web接口host:port/debug/pprof/上启用profiling。（默认值true）
|
||||
--profiling 在 web 接口 host:port/debug/pprof/ 上启用 profiling。（默认值 true）
|
||||
|
||||
--proxy-client-cert-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。
|
||||
--proxy-client-cert-file string 当必须调用外部程序时，用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。它期望这个证书包含一个来自于 CA 中的 --requestheader-client-ca-file 标记的签名。该 CA 在 kube-system 命名空间的 'extension-apiserver-authentication' configmap 中发布。从 Kube-aggregator 收到调用的组件应该使用该 CA 进行他们部分的双向 TLS 验证。
|
||||
|
||||
--proxy-client-key-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。
|
||||
--proxy-client-key-file string 当必须调用外部程序时，用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书密钥。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。
|
||||
|
||||
--repair-malformed-updates 如果为true，服务将会尽力修复更新请求以通过验证，例如：将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。
|
||||
--repair-malformed-updates 如果为 true，服务将会尽力修复更新请求以通过验证，例如：将更新请求 UID 的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。
|
||||
|
||||
--requestheader-allowed-names stringSlice 使用--requestheader-username-headers指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。
|
||||
--requestheader-allowed-names stringSlice 使用 --requestheader-username-headers 指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过 --requestheader-client-ca-file 中 authorities 验证的客户端证书都是被允许的。
|
||||
|
||||
--requestheader-client-ca-file string 在信任请求头中以--requestheader-username-headers指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。
|
||||
--requestheader-client-ca-file string 在信任请求头中以 --requestheader-username-headers 指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。
|
||||
|
||||
--requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。
|
||||
--requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用 X-Remote-Extra-。
|
||||
|
||||
--requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用X-Remote-Group.
|
||||
--requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用 X-Remote-Group.
|
||||
|
||||
--requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用X-Remote-User。
|
||||
--requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用 X-Remote-User。
|
||||
|
||||
--runtime-config mapStringString 传递给apiserver用于描述运行时配置的键值对集合。 apis/<groupVersion>键可以被用来打开/关闭特定的api版本。apis/<groupVersion>/<resource>键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本.
|
||||
--runtime-config mapStringString 传递给 apiserver 用于描述运行时配置的键值对集合。 apis/<groupVersion> 键可以被用来打开 / 关闭特定的 api 版本。apis/<groupVersion>/<resource> 键被用来打开 / 关闭特定的资源 . api/all 和 api/legacy 键分别用于控制所有的和遗留的 api 版本 .
|
||||
|
||||
--secure-port int 用于监听具有认证授权功能的HTTPS协议的端口。如果为0，则不会监听HTTPS协议。 （默认值6443)
|
||||
--secure-port int 用于监听具有认证授权功能的 HTTPS 协议的端口。如果为 0，则不会监听 HTTPS 协议。 （默认值 6443)
|
||||
|
||||
--service-account-key-file stringArray 包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件，用于验证ServiceAccount令牌。如果设置该值，--tls-private-key-file将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。
|
||||
--service-account-key-file stringArray 包含 PEM 加密的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。如果设置该值，--tls-private-key-file 将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。
|
||||
|
||||
--service-cluster-ip-range ipNet CIDR表示的IP范围，服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。
|
||||
--service-cluster-ip-range ipNet CIDR 表示的 IP 范围，服务的 cluster ip 将从中分配。 一定不要和分配给 nodes 和 pods 的 IP 范围产生重叠。
|
||||
|
||||
--ssh-keyfile string 如果不为空，在使用安全的SSH代理访问节点时，将这个文件作为用户密钥文件。
|
||||
--ssh-keyfile string 如果不为空，在使用安全的 SSH 代理访问节点时，将这个文件作为用户密钥文件。
|
||||
|
||||
--storage-backend string 持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'.
|
||||
--storage-backend string 持久化存储后端。 选项为 : 'etcd3' ( 默认 ), 'etcd2'.
|
||||
|
||||
--storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型，并且忽略该配置项。（默认值 "application/vnd.kubernetes.protobuf")
|
||||
|
||||
--storage-versions string 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来，所有注册组的首选版本列表。 （默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
|
||||
--storage-versions string 按组划分资源存储的版本。 以 "group1/version1,group2/version2,..." 的格式指定。当对象从一组移动到另一组时 , 你可以指定 "group1=group2/v1beta1,group3/v1beta1,..." 的格式。你只需要传入你希望从结果中改变的组的列表。默认为从 KUBE_API_VERSIONS 环境变量集成而来，所有注册组的首选版本列表。 （默认值 "admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
|
||||
|
||||
--target-ram-mb int apiserver内存限制，单位为MB(用于配置缓存大小等)。
|
||||
--target-ram-mb int apiserver 内存限制，单位为 MB( 用于配置缓存大小等 )。
|
||||
|
||||
--tls-ca-file string 如果设置该值，这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中.
|
||||
--tls-ca-file string 如果设置该值，这个证书 authority 将会被用于从 Admission Controllers 过来的安全访问。它必须是一个 PEM 加密的合法 CA 捆绑包。此外 , 该证书 authority 可以被添加到以 --tls-cert-file 提供的证书文件中 .
|
||||
|
||||
--tls-cert-file string 包含用于HTTPS的默认x509证书的文件。（如果有CA证书，则附加于server证书之后）。如果启用了HTTPS服务，并且没有提供--tls-cert-file和--tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。
|
||||
--tls-cert-file string 包含用于 HTTPS 的默认 x509 证书的文件。（如果有 CA 证书，则附加于 server 证书之后）。如果启用了 HTTPS 服务，并且没有提供 --tls-cert-file 和 --tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于 /var/run/kubernetes 目录。
|
||||
|
||||
--tls-private-key-file string 包含匹配--tls-cert-file的x509证书私钥的文件。
|
||||
--tls-private-key-file string 包含匹配 --tls-cert-file 的 x509 证书私钥的文件。
|
||||
|
||||
--tls-sni-cert-key namedCertKey 一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[])
|
||||
--tls-sni-cert-key namedCertKey 一对 x509 证书和私钥的文件路径 , 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀 , 则将提取证书名。 非通配符版本优先于通配符版本 , 显示的域形式优先于证书中提取的名字。 对于多个密钥 / 证书对, 请多次使用 --tls-sni-cert-key。例如 : "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[])
|
||||
|
||||
--token-auth-file string 如果设置该值，这个文件将被用于通过令牌认证来保护API服务的安全端口。
|
||||
--token-auth-file string 如果设置该值，这个文件将被用于通过令牌认证来保护 API 服务的安全端口。
|
||||
|
||||
--version version[=true] 打印版本信息并退出。
|
||||
|
||||
--watch-cache 启用apiserver的监视缓存。（默认值true）
|
||||
--watch-cache 启用 apiserver 的监视缓存。（默认值 true）
|
||||
|
||||
--watch-cache-sizes stringSlice 每种资源（pods, nodes等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size是一个数字。在watch-cache启用时生效。
|
||||
--watch-cache-sizes stringSlice 每种资源（pods, nodes 等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size 是一个数字。在 watch-cache 启用时生效。
|
||||
```
|
||||
|
||||
###### Auto generated by spf13/cobra on 11-Jul-2017
|
||||
|
||||
@@ -8,58 +8,58 @@ title: 多区域运行
|
||||
|
||||
## 介绍
|
||||
|
||||
Kubernetes 从v1.2开始支持将集群运行在多个故障域中。
|
||||
(GCE 中称其为 "区（Zones）"， AWS 中称其为 "可用区（Availability Zones）"，这里我们也称其为 "区")。
|
||||
它是广泛意义上的集群联邦特性的轻量级版本 (之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
|
||||
Kubernetes 从 v1.2 开始支持将集群运行在多个故障域中。
|
||||
(GCE 中称其为 " 区（Zones）"， AWS 中称其为 " 可用区（Availability Zones）"，这里我们也称其为 " 区 ")。
|
||||
它是广泛意义上的集群联邦特性的轻量级版本 ( 之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
|
||||
完整的集群联邦能够将多个分别运行在不同区或云供应商（或本地数据中心）的集群集中管理。
|
||||
然而，很多用户只是希望通过将单一云供应商上的Kubernetes集群运行在多个区域，来提高集群的可用性，
|
||||
这就是1.2版本中提供的对多区域的支持。
|
||||
(之前被称为 "Ubernetes Lite")。
|
||||
然而，很多用户只是希望通过将单一云供应商上的 Kubernetes 集群运行在多个区域，来提高集群的可用性，
|
||||
这就是 1.2 版本中提供的对多区域的支持。
|
||||
( 之前被称为 "Ubernetes Lite")。
|
||||
|
||||
多区域的支持是有明确限制的： Kubernetes集群能够运行在多个区，但必须在同一个地域内 (云供应商也须一致)。
|
||||
目前只有GCE和AWS自动支持 (尽管在其他云甚至裸机上，也很容易通过为节点和卷添加合适的标签来实现类似的支持)。
|
||||
多区域的支持是有明确限制的： Kubernetes 集群能够运行在多个区，但必须在同一个地域内 ( 云供应商也须一致 )。
|
||||
目前只有 GCE 和 AWS 自动支持 ( 尽管在其他云甚至裸机上，也很容易通过为节点和卷添加合适的标签来实现类似的支持 )。
|
||||
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 功能
|
||||
|
||||
节点启动时，Kubelet自动为其添加区信息的标签。
|
||||
节点启动时，Kubelet 自动为其添加区信息的标签。
|
||||
|
||||
在单一区域的集群中，Kubernetes 会自动将副本管理器或服务的pod分布到各节点上 (以减轻单实例故障的影响)。
|
||||
在单一区域的集群中，Kubernetes 会自动将副本管理器或服务的 pod 分布到各节点上 ( 以减轻单实例故障的影响 )。
|
||||
在多区域的集群中，这种分布的行为扩展到了区域级别
|
||||
(以减少区域故障对整体的影响)。 (通过 `SelectorSpreadPriority` 来实现)。
|
||||
( 以减少区域故障对整体的影响 )。 ( 通过 `SelectorSpreadPriority` 来实现 )。
|
||||
这种分发是尽力而为（best-effort）的，所以如果集群在各个区之间是异构的
|
||||
(比如，各区间的节点数量不同、节点类型不同、pod的资源需求不同等)可能导致pod无法完全均匀地分布。
|
||||
如果需要的话，用户可以使用同质的区(节点数量和节点类型相同)来减少区域之间分配不均匀的可能。
|
||||
( 比如，各区间的节点数量不同、节点类型不同、pod 的资源需求不同等 ) 可能导致 pod 无法完全均匀地分布。
|
||||
如果需要的话，用户可以使用同质的区 ( 节点数量和节点类型相同 ) 来减少区域之间分配不均匀的可能。
|
||||
|
||||
当卷被创建时， `PersistentVolumeLabel`准入控制器会自动为其添加区域的标签。
|
||||
调度器 (通过 `VolumeZonePredicate` 断言) 会确申领该卷的pod被调度到该卷对应的区域，
|
||||
当卷被创建时， `PersistentVolumeLabel` 准入控制器会自动为其添加区域的标签。
|
||||
调度器 ( 通过 `VolumeZonePredicate` 断言 ) 会确申领该卷的 pod 被调度到该卷对应的区域，
|
||||
因为卷是不支持跨区挂载的。
|
||||
|
||||
## 限制
|
||||
|
||||
对多区的支持有一些重要的限制：
|
||||
|
||||
* 我们假设不同的区域间在网络上离得很近，所以我们不做任何的区域感知路由。 特别是，通过服务的网络访问可能跨区域 (即使该服务后端pod的其中一些运行在与客户端相同的区域中)，这可能导致额外的延迟和损耗。
|
||||
* 我们假设不同的区域间在网络上离得很近，所以我们不做任何的区域感知路由。 特别是，通过服务的网络访问可能跨区域 ( 即使该服务后端 pod 的其中一些运行在与客户端相同的区域中 )，这可能导致额外的延迟和损耗。
|
||||
|
||||
* 卷的区域亲和性只对 `PersistentVolume`有效。 例如，如果你在pod的spec中直接指定一个EBS的卷，则不会生效。
|
||||
* 卷的区域亲和性只对 `PersistentVolume` 有效。 例如，如果你在 pod 的 spec 中直接指定一个 EBS 的卷，则不会生效。
|
||||
|
||||
* 集群不支持跨云平台或地域 (这些功能需要完整的集群联邦特性支持)。
|
||||
* 集群不支持跨云平台或地域 ( 这些功能需要完整的集群联邦特性支持 )。
|
||||
|
||||
* 尽管节点位于多区域，目前默认情况下 kube-up 创建的管理节点是单实例的。 所以尽管服务是高可用的，并且能够容忍跨区域的性能损耗，管理平面还是单区域的。 需要高可用的管理平面的用户可以按照 [高可用](/docs/admin/high-availability) 指导来操作。
|
||||
|
||||
* 目前StatefulSet的卷动态创建时的跨区域分配，与pod的亲和性/反亲和性不兼容。
|
||||
* 目前 StatefulSet 的卷动态创建时的跨区域分配，与 pod 的亲和性 / 反亲和性不兼容。
|
||||
|
||||
* StatefulSet的名称包含破折号 ("-")时，可能影响到卷在区域间的均匀分布。
|
||||
* StatefulSet 的名称包含破折号 ("-") 时，可能影响到卷在区域间的均匀分布。
|
||||
|
||||
* 为deployment或pod指定多个PVC时，要求其StorageClass处于同一区域内，否则，相应的PV卷需要在一个区域中静态配置。 另一种方式是使用StatefulSet，这可以确保同一副本所挂载的卷位于同一区内。
|
||||
* 为 deployment 或 pod 指定多个 PVC 时，要求其 StorageClass 处于同一区域内，否则，相应的 PV 卷需要在一个区域中静态配置。 另一种方式是使用 StatefulSet，这可以确保同一副本所挂载的卷位于同一区内。
|
||||
|
||||
|
||||
## 演练
|
||||
|
||||
接下来我们将介绍如何同时在 GCE 和 AWS 上创建和使用多区域的集群。 为此，你需要创建一个完整的集群
|
||||
(指定 `MULTIZONE=true`)，然后再次执行 `kube-up`（指定 `KUBE_USE_EXISTING_MASTER=true`）来添加其他区域的节点。
|
||||
( 指定 `MULTIZONE=true`)，然后再次执行 `kube-up`（指定 `KUBE_USE_EXISTING_MASTER=true`）来添加其他区域的节点。
|
||||
|
||||
### 创建集群
|
||||
|
||||
@@ -99,7 +99,7 @@ kubernetes-minion-a12q Ready 6m v1.6.0+fff5156 beta.
|
||||
|
||||
### 添加其它区中的节点
|
||||
|
||||
接下来我们复用已有的管理节点，添加运行于其它区域 （us-central1-b或us-west-2b）中的节点。
|
||||
接下来我们复用已有的管理节点，添加运行于其它区域 （us-central1-b 或 us-west-2b）中的节点。
|
||||
再次执行 kube-up， 通过指定 `KUBE_USE_EXISTING_MASTER=true`，
|
||||
kube-up 不会创建新的管理节点，而是会复用之前创建的。
|
||||
|
||||
@@ -109,14 +109,14 @@ GCE:
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
在 AWS 中我们还需要为新增的子网指定网络CIDR，还有管理节点的内部IP地址。
|
||||
在 AWS 中我们还需要为新增的子网指定网络 CIDR，还有管理节点的内部 IP 地址。
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
|
||||
再次查看节点，3个新增的节点已经启动，并被标记为us-central1-b：
|
||||
再次查看节点，3 个新增的节点已经启动，并被标记为 us-central1-b：
|
||||
|
||||
```shell
|
||||
> kubectl get nodes --show-labels
|
||||
@@ -133,7 +133,7 @@ kubernetes-minion-wf8i Ready 2m v1.6.0+fff5156 beta
|
||||
|
||||
### 卷的亲和性
|
||||
|
||||
使用动态创建卷的功能创建一个卷 (只有PV持久卷才支持区域亲和性)：
|
||||
使用动态创建卷的功能创建一个卷 ( 只有 PV 持久卷才支持区域亲和性 )：
|
||||
|
||||
```json
|
||||
kubectl create -f - <<EOF
|
||||
@@ -160,11 +160,11 @@ kubectl create -f - <<EOF
|
||||
EOF
|
||||
```
|
||||
|
||||
**注意：** Kubernetes 1.3以上的版本中可以将PVC分发到多个已配置的区域中，在1.2版本中， 动态卷只能创建在管理节点所在的区域内(即这里的 us-central1-a / us-west-2a)；相关issue
|
||||
**注意：** Kubernetes 1.3 以上的版本中可以将 PVC 分发到多个已配置的区域中，在 1.2 版本中， 动态卷只能创建在管理节点所在的区域内 ( 即这里的 us-central1-a / us-west-2a)；相关 issue
|
||||
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
|
||||
在1.3后续的版本中已解决。
|
||||
在 1.3 后续的版本中已解决。
|
||||
|
||||
现在我们验证一下 Kubernetes 自动为创建的PV打上了所在地域和区域的标签。
|
||||
现在我们验证一下 Kubernetes 自动为创建的 PV 打上了所在地域和区域的标签。
|
||||
|
||||
```shell
|
||||
> kubectl get pv --show-labels
|
||||
@@ -172,9 +172,9 @@ NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
|
||||
pv-gce-mj4gm 5Gi RWO Bound default/claim1 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
|
||||
```
|
||||
|
||||
现在我们将创建使用这些PVC的pod。
|
||||
因为 GCE 的PD存储 / AWS 的EBS 卷 不支持跨区域挂载，
|
||||
这意味着相应的pod只能创建在卷所在的区域中。
|
||||
现在我们将创建使用这些 PVC 的 pod。
|
||||
因为 GCE 的 PD 存储 / AWS 的 EBS 卷 不支持跨区域挂载，
|
||||
这意味着相应的 pod 只能创建在卷所在的区域中。
|
||||
|
||||
```yaml
|
||||
kubectl create -f - <<EOF
|
||||
@@ -196,7 +196,7 @@ spec:
|
||||
EOF
|
||||
```
|
||||
|
||||
注意pod被自动创建在了卷所在的区域中，因为云供应商通常不支持卷的跨区域挂载（attach）。
|
||||
注意 pod 被自动创建在了卷所在的区域中，因为云供应商通常不支持卷的跨区域挂载（attach）。
|
||||
|
||||
```shell
|
||||
> kubectl describe pod mypod | grep Node
|
||||
@@ -206,9 +206,9 @@ NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
```
|
||||
|
||||
### Pod的跨区域分布
|
||||
### Pod 的跨区域分布
|
||||
|
||||
副本管理器或服务的pod被自动创建在了不同的区域。 首先，在第三个区域内启动节点：
|
||||
副本管理器或服务的 pod 被自动创建在了不同的区域。 首先，在第三个区域内启动节点：
|
||||
|
||||
GCE:
|
||||
|
||||
@@ -222,19 +222,19 @@ AWS:
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
验证你现在在3个区域内拥有节点:
|
||||
验证你现在在 3 个区域内拥有节点 :
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
创建 guestbook-go 示例应用， 它包含一个副本数为3的RC，运行一个简单的网络应用：
|
||||
创建 guestbook-go 示例应用， 它包含一个副本数为 3 的 RC，运行一个简单的网络应用：
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
|
||||
```
|
||||
|
||||
Pod应该分布在全部3个区域上：
|
||||
Pod 应该分布在全部 3 个区域上：
|
||||
|
||||
```shell
|
||||
> kubectl describe pod -l app=guestbook | grep Node
|
||||
@@ -268,7 +268,7 @@ LoadBalancer Ingress: 130.211.126.21
|
||||
"HOSTNAME": "guestbook-ppm40",
|
||||
```
|
||||
|
||||
负载平衡器正确指向了所有的pod，即使它们位于不同的区域内。
|
||||
负载均衡器正确指向了所有的 pod，即使它们位于不同的区域内。
|
||||
|
||||
### 停止集群
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ title: 节点设置校验
|
||||
|
||||
## 限制
|
||||
|
||||
在 Kubernetes 1.5版本中，节点合规性测试存在以下限制：
|
||||
在 Kubernetes 1.5 版本中，节点合规性测试存在以下限制：
|
||||
|
||||
* 节点合规性测试只支持 Docker 作为容器运行时环境。
|
||||
|
||||
@@ -60,7 +60,7 @@ Kubernetes 也为其他硬件体系结构的系统提供了节点合规性测试
|
||||
```shell
|
||||
sudo docker run -it --rm --privileged --net=host \
|
||||
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
|
||||
-e FOCUS=MirrorPod \ # 只运行MirrorPod测试
|
||||
-e FOCUS=MirrorPod \ # 只运行 MirrorPod 测试
|
||||
k8s.gcr.io/node-test:0.2
|
||||
```
|
||||
|
||||
@@ -69,7 +69,7 @@ sudo docker run -it --rm --privileged --net=host \
|
||||
```shell
|
||||
sudo docker run -it --rm --privileged --net=host \
|
||||
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
|
||||
-e SKIP=MirrorPod \ # 运行除MirrorPod外的所有测试
|
||||
-e SKIP=MirrorPod \ # 运行除 MirrorPod 外的所有测试
|
||||
k8s.gcr.io/node-test:0.2
|
||||
```
|
||||
|
||||
@@ -80,5 +80,5 @@ sudo docker run -it --rm --privileged --net=host \
|
||||
|
||||
## 注意事项
|
||||
|
||||
* 测试会在节点上遗留一些Docker镜像， 包括节点合规性测试本身的镜像，和功能测试相关的镜像。
|
||||
* 测试会在节点上遗留一些 Docker 镜像， 包括节点合规性测试本身的镜像和功能测试相关的镜像。
|
||||
* 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。
|
||||
|
||||
@@ -4,18 +4,18 @@ approvers:
|
||||
title: Kubernetes OpenVSwitch GRE/VxLAN 网络
|
||||
---
|
||||
|
||||
本文档介绍了如何使用OpenVSwitch，在跨nodes的pods之间设置网络。
|
||||
隧道类型可以是GRE或者是VxLAN。如需在网络内执行大规模隔离时，最好使用VxLAN。
|
||||
本文档介绍了如何使用 OpenVSwitch，在跨 nodes 的 pods 之间设置网络。
|
||||
隧道类型可以是 GRE 或者是 VxLAN。如需在网络内执行大规模隔离时，最好使用 VxLAN。
|
||||
|
||||
|
||||
|
||||
Kubernetes中Vagrant的设置如下：
|
||||
Kubernetes 中 Vagrant 的设置如下：
|
||||
|
||||
docker网桥被brctl生成的Linux网桥(kbr0)所代替，kbr0是具有256个地址空间的子网。总的来说，node会得到10.244.x.0/24的子网，docker上配置使用的网桥会代替默认docker0的网桥。
|
||||
docker 网桥被 brctl 生成的 Linux 网桥（kbr0） 所代替，kbr0 是具有 256 个地址空间的子网。总的来说，node 会得到 10.244.x.0/24 的子网，docker 上配置使用的网桥会代替默认 docker0 的网桥。
|
||||
|
||||
另外，OVS网桥创建(obr0)，并将其作为端口添加到kbr0的网桥中。所有OVS网桥通过GRE隧道连接所有的nodes。因此，每个node都有一个到其他nodes的出站GRE隧道。这个隧道没有必要是一个完整的网状物，但是越像网状结构越好。在网桥上开启STP(生成树)模式以防止环路的发生。
|
||||
另外，OVS 网桥创建（obr0），并将其作为端口添加到 kbr0 的网桥中。所有 OVS 网桥通过 GRE 隧道连接所有的 nodes。因此，每个 node 都有一个到其他 nodes 的出站 GRE 隧道。这个隧道没有必要是一个完整的网状物，但是越像网状结构越好。在网桥上开启 STP （生成树）模式以防止环路的发生。
|
||||
|
||||
路由规则允许任何10.244.0.0/16通过与隧道相连的OVS网桥到达目标。
|
||||
路由规则允许任何 10.244.0.0/16 通过与隧道相连的 OVS 网桥到达目标。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,58 +4,58 @@ approvers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
- liggitt
|
||||
title: 管理Service Accounts
|
||||
title: 管理 Service Accounts
|
||||
---
|
||||
|
||||
*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
|
||||
*这是一篇针对 service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts) 中的信息。*
|
||||
|
||||
*对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述service accounts，有时这些不完善的特性也会被提及。*
|
||||
*对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述 service accounts，有时这些不完善的特性也会被提及。*
|
||||
|
||||
## 用户账户与服务账户
|
||||
|
||||
Kubernetes 区分用户账户和服务账户的概念主要基于以下原因：
|
||||
|
||||
- 用户账户是针对人而言的。 服务账户是针对运行在pod中的进程而言的。
|
||||
- 用户账户是全局性的。 其名称在集群各namespace中都是全局唯一的，未来的用户资源不会做namespace隔离，
|
||||
服务账户是namespace隔离的。
|
||||
- 通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 (即权限最小化原则)。
|
||||
- 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。
|
||||
- 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，
|
||||
服务账户是 namespace 隔离的。
|
||||
- 通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。
|
||||
- 对人员和服务账户审计所考虑的因素可能不同。
|
||||
- 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建，并且有namespace级别的名称，这种配置是很轻量的。
|
||||
- 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建，并且有 namespace 级别的名称，这种配置是很轻量的。
|
||||
|
||||
## 服务账户的自动化
|
||||
|
||||
三个独立组件协作完成服务账户相关的自动化:
|
||||
三个独立组件协作完成服务账户相关的自动化 :
|
||||
|
||||
- 服务账户准入控制器（Service account admission controller）
|
||||
- Token控制器（Token controller）
|
||||
- Token 控制器（Token controller）
|
||||
- 服务账户控制器（Service account controller）
|
||||
|
||||
### 服务账户准入控制器
|
||||
|
||||
对pod的改动通过一个被称为[Admission Controller](/docs/admin/admission-controllers)的插件来实现。它是apiserver的一部分。
|
||||
当pod被创建或更新时，它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的)，当pod被创建或更新时它会进行以下动作：
|
||||
对 pod 的改动通过一个被称为 [Admission Controller](/docs/admin/admission-controllers) 的插件来实现。它是 apiserver 的一部分。
|
||||
当 pod 被创建或更新时，它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 )，当 pod 被创建或更新时它会进行以下动作：
|
||||
|
||||
1. 如果该pod没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。
|
||||
2. 保证pod所关联的 `ServiceAccount` 存在，否则拒绝该pod。
|
||||
4. 如果pod不包含 `ImagePullSecrets`设置，那么 将 `ServiceAccount`中的`ImagePullSecrets` 信息添加到pod中。
|
||||
5. 将一个包含用于API访问的token的 `volume` 添加到pod中。
|
||||
6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount` 的 `volumeSource`添加到pod下的每个容器中。
|
||||
1. 如果该 pod 没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。
|
||||
2. 保证 pod 所关联的 `ServiceAccount` 存在，否则拒绝该 pod。
|
||||
4. 如果 pod 不包含 `ImagePullSecrets` 设置，那么 将 `ServiceAccount` 中的 `ImagePullSecrets` 信息添加到 pod 中。
|
||||
5. 将一个包含用于 API 访问的 token 的 `volume` 添加到 pod 中。
|
||||
6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount` 的 `volumeSource` 添加到 pod 下的每个容器中。
|
||||
|
||||
### Token管理器
|
||||
### Token 管理器
|
||||
|
||||
Token管理器是controller-manager的一部分。 以异步的形式工作：
|
||||
Token 管理器是 controller-manager 的一部分。 以异步的形式工作：
|
||||
|
||||
- 检测服务账户的创建，并且创建相应的Secret以支持API访问。
|
||||
- 检测服务账户的删除，并且删除所有相应的服务账户Token Secret。
|
||||
- 检测Secret的增加，保证相应的服务账户存在，如有需要，为Secret增加token。
|
||||
- 检测Secret的删除，如有需要，从相应的服务账户中移除引用。
|
||||
- 检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。
|
||||
- 检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。
|
||||
- 检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。
|
||||
- 检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。
|
||||
|
||||
你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至Token管理器。 私钥用于为生成的服务账户token签名。
|
||||
同样地，你需要通过 `--service-account-key-file` 参数将对应的公钥传入kube-apiserver。 公钥用于认证过程中的token校验。
|
||||
你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至 Token 管理器。 私钥用于为生成的服务账户 token 签名。
|
||||
同样地，你需要通过 `--service-account-key-file` 参数将对应的公钥传入 kube-apiserver。 公钥用于认证过程中的 token 校验。
|
||||
|
||||
#### 创建额外的 API tokens
|
||||
|
||||
控制器中有专门的循环来保证每个服务账户中都存在API token对应的Secret。 当需要为服务账户创建额外的API token时，创建一个类型为 `ServiceAccountToken` 的Secret，并在annotation中引用服务账户，控制器会生成token并更新:
|
||||
控制器中有专门的循环来保证每个服务账户中都存在 API token 对应的 Secret。 当需要为服务账户创建额外的 API token 时，创建一个类型为 `ServiceAccountToken` 的 Secret，并在 annotation 中引用服务账户，控制器会生成 token 并更新 :
|
||||
|
||||
secret.json:
|
||||
|
||||
@@ -78,7 +78,7 @@ kubectl create -f ./secret.json
|
||||
kubectl describe secret mysecretname
|
||||
```
|
||||
|
||||
#### 删除/失效 服务账户token
|
||||
#### 删除 / 失效 服务账户 token
|
||||
|
||||
```shell
|
||||
kubectl delete secret mysecretname
|
||||
|
||||
@@ -39,7 +39,7 @@ weight: 40
|
||||
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. -->
|
||||
|
||||
* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)和[kube-scheduler](/docs/admin/kube-scheduler/)。
|
||||
* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
|
||||
* 集群中的每个非 master 节点都运行两个进程：
|
||||
* **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
|
||||
@@ -50,7 +50,7 @@ weight: 40
|
||||
|
||||
<!-- Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. -->
|
||||
|
||||
Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
|
||||
Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
|
||||
|
||||
<!-- The basic Kubernetes objects include: -->
|
||||
|
||||
@@ -77,7 +77,7 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容
|
||||
|
||||
<!-- The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. -->
|
||||
|
||||
关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程，管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任一的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
|
||||
关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
|
||||
|
||||
<!-- For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. -->
|
||||
|
||||
@@ -93,7 +93,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne
|
||||
|
||||
<!-- > The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. -->
|
||||
|
||||
> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的性能及冗余。
|
||||
> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。
|
||||
|
||||
<!-- ### Kubernetes Nodes -->
|
||||
|
||||
@@ -108,7 +108,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne
|
||||
#### 对象元数据
|
||||
|
||||
|
||||
* [注释](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [注解](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Kubernetes 架构"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Kubernetes Architecture"
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
@@ -1,175 +1,458 @@
|
||||
title: 云控制器管理器的基本概念
|
||||
---
|
||||
title: 云控制器管理器的基础概念
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
## 云控制器管理器
|
||||
<!--
|
||||
---
|
||||
title: Concepts Underlying the Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器，API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动，这种情况下，CCM运行在Kubernetes系统之上。
|
||||
|
||||
云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
|
||||
-->
|
||||
|
||||
云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。
|
||||
|
||||
<!--
|
||||
The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
|
||||
-->
|
||||
|
||||
云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。
|
||||
|
||||
<!--
|
||||
This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
|
||||
-->
|
||||
|
||||
本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。
|
||||
|
||||
下面这张图描述了没有云控制器管理器的Kubernetes集群架构：
|
||||
<!--
|
||||
Here's the architecture of a Kubernetes cluster without the cloud controller manager: -->
|
||||
|
||||
这是没有云控制器管理器的 Kubernetes 集群的架构：
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Design
|
||||
-->
|
||||
|
||||
|
||||
|
||||
## 设计
|
||||
|
||||
在上图中，Kubernetes和云服务供应商通过几个不同的组件进行了集成，分别是：
|
||||
<!--
|
||||
In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
|
||||
-->
|
||||
|
||||
在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：
|
||||
|
||||
<!--
|
||||
* Kubelet
|
||||
* Kubernetes controller manager
|
||||
* Kubernetes API server
|
||||
-->
|
||||
|
||||
* Kubelet
|
||||
* Kubernetes 控制管理器
|
||||
* Kubernetes API服务器
|
||||
* Kubernetes API 服务器
|
||||
|
||||
而CCM整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示：
|
||||
<!--
|
||||
The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
|
||||
-->
|
||||
|
||||
|
||||
CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：
|
||||
|
||||
## CCM的组件
|
||||
<!--  -->
|
||||
|
||||
CCM突破了Kubernetes控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎：
|
||||
|
||||
|
||||
<!--
|
||||
## Components of the CCM
|
||||
-->
|
||||
## CCM 的组成部分
|
||||
|
||||
<!--
|
||||
The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
|
||||
-->
|
||||
|
||||
CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器：
|
||||
|
||||
<!--
|
||||
* Node controller
|
||||
* Volume controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
-->
|
||||
|
||||
* 节点控制器
|
||||
* 卷控制器
|
||||
* 路由控制器
|
||||
* 服务控制器
|
||||
<!--
|
||||
In version 1.9, the CCM runs the following controllers from the preceding list:
|
||||
-->
|
||||
|
||||
在1.8版本中，当前运行中的CCM从上面的列表中运行以下控制器：
|
||||
在 1.9 版本中，CCM 运行前述列表中的以下控制器：
|
||||
|
||||
<!--
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
-->
|
||||
|
||||
* 节点控制器
|
||||
* 路由控制器
|
||||
* 服务控制器
|
||||
|
||||
另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域（Zone）和 区（Region）标签进行设置。
|
||||
<!--
|
||||
Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.
|
||||
-->
|
||||
|
||||
**注意**：卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到CCM之中。
|
||||
此外，它还运行另一个名为 PersistentVolumeLabels Controller 的控制器，这个控制器负责在 GCP 和 AWS 云中创建的 PersistentVolumes 的域（zone）和区（region）标签进行设置。
|
||||
|
||||
原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。
|
||||
{{< note >}}
|
||||
<!--
|
||||
Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
|
||||
-->
|
||||
|
||||
考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至CSI准备就绪。
|
||||
注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。
|
||||
|
||||
云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。
|
||||
{{< /note >}}
|
||||
|
||||
## CCM功能
|
||||
<!--
|
||||
The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
|
||||
-->
|
||||
|
||||
CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。
|
||||
使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。
|
||||
|
||||
<!--
|
||||
Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
|
||||
-->
|
||||
|
||||
考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。
|
||||
|
||||
<!--
|
||||
## Functions of the CCM
|
||||
-->
|
||||
|
||||
## CCM 的功能
|
||||
|
||||
<!--
|
||||
The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
|
||||
-->
|
||||
|
||||
CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。
|
||||
|
||||
<!--
|
||||
### 1. Kubernetes controller manager
|
||||
-->
|
||||
|
||||
### 1. Kubernetes 控制器管理器
|
||||
|
||||
CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制引擎：
|
||||
<!--
|
||||
The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
|
||||
-->
|
||||
|
||||
CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。
|
||||
|
||||
<!--
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
* PersistentVolumeLabels controller
|
||||
-->
|
||||
|
||||
* 节点控制器
|
||||
* 路由控制器
|
||||
* 服务控制器
|
||||
* PersistentVolumeLabels控制器
|
||||
* PersistentVolumeLabels 控制器
|
||||
|
||||
<!--
|
||||
#### Node controller
|
||||
-->
|
||||
|
||||
#### 节点控制器
|
||||
|
||||
节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能：
|
||||
<!--
|
||||
The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
|
||||
-->
|
||||
|
||||
1.使用云特定域（Zone）/区（Region）标签初始化节点。
|
||||
节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能：
|
||||
|
||||
1.使用特定于云的实例详细信息初始化节点，例如类型和大小。
|
||||
<!--
|
||||
1. Initialize a node with cloud specific zone/region labels.
|
||||
2. Initialize a node with cloud specific instance details, for example, type and size.
|
||||
3. Obtain the node's network addresses and hostname.
|
||||
4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
|
||||
If the node has been deleted from the cloud, delete the Kubernetes Node object.
|
||||
-->
|
||||
|
||||
1.获取节点的网络地址和主机名。
|
||||
1. 使用特定于云的域（zone）/区（region）标签初始化节点；
|
||||
2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小；
|
||||
3. 获取节点的网络地址和主机名；
|
||||
4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。
|
||||
|
||||
1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除Kubernetes节点对象。
|
||||
<!--
|
||||
#### Route controller
|
||||
-->
|
||||
|
||||
#### 路由控制器
|
||||
|
||||
路由控制器负责为云 配置正确的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。
|
||||
<!--
|
||||
The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
|
||||
-->
|
||||
|
||||
Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。
|
||||
|
||||
<!--
|
||||
#### Service Controller
|
||||
-->
|
||||
|
||||
#### 服务控制器
|
||||
|
||||
服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如ELB或Google LB）以反映Kubernetes中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。
|
||||
<!--
|
||||
The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB or Google LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
|
||||
-->
|
||||
|
||||
服务控制器负责监听服务的创建、更新和删除事件。根据 Kubernetes 中各个服务的当前状态，它配置云负载均衡器（如 ELB 或 Google LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端是最新的。
|
||||
|
||||
<!--
|
||||
#### PersistentVolumeLabels controller
|
||||
-->
|
||||
|
||||
#### PersistentVolumeLabels 控制器
|
||||
|
||||
PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。
|
||||
<!--
|
||||
The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes.
|
||||
-->
|
||||
|
||||
这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。
|
||||
PersistentVolumeLabels 控制器在创建 AWS EBS/GCE PD 卷时应用标签，这样就无需用户手动设置这些卷上的标签。
|
||||
|
||||
PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说，在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器（它是一个许可控制器）中的PV标签逻辑移动到CCM。 它不在KCM上运行。
|
||||
<!--
|
||||
These labels are essential for the scheduling of pods as these volumes are constrained to work only within the region/zone that they are in. Any Pod using these volumes needs to be scheduled in the same region/zone.
|
||||
-->
|
||||
|
||||
这些标签对于 pod 的调度至关重要，因为这些卷仅限于在它们所在的域（zone）/区（region）内工作，使用这些卷的任何 Pod 都需要在同一域（zone）/区（region）中进行调度。
|
||||
|
||||
<!--
|
||||
The PersistentVolumeLabels controller was created specifically for the CCM; that is, it did not exist before the CCM was created. This was done to move the PV labelling logic in the Kubernetes API server (it was an admission controller) to the CCM. It does not run on the KCM.
|
||||
-->
|
||||
|
||||
PersistentVolumeLabels 控制器专门为 CCM 创建； 也就是说，在创建 CCM 之前它不存在。这样做是为了将 Kubernetes API 服务器（它是一个准入控制器）中的 PV 标记逻辑移动到 CCM，它不在 KCM 上运行。
|
||||
|
||||
<!--
|
||||
### 2. Kubelet
|
||||
-->
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前，是由kubelet采用包含云特定信息的方式对节点进行初始化，如IP地址、区（Region）/域（Zone）标签和实例类型信息；引入CCM之后，这部分的初始化操作就从kubelet转移到了CCM中。
|
||||
<!--
|
||||
The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
|
||||
-->
|
||||
|
||||
在引入CCM后的新的模型中，kubelet采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到CCM使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。
|
||||
节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。
|
||||
|
||||
### 3. Kubernetes API服务器
|
||||
<!--
|
||||
In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
|
||||
-->
|
||||
|
||||
在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。
|
||||
|
||||
<!--
|
||||
### 3. Kubernetes API server
|
||||
-->
|
||||
|
||||
### 3. Kubernetes API 服务器
|
||||
|
||||
<!--
|
||||
The PersistentVolumeLabels controller moves the cloud-dependent functionality of the Kubernetes API server to the CCM as described in the preceding sections.
|
||||
-->
|
||||
|
||||
PersistentVolumeLabels 控制器将 Kubernetes API 服务器的依赖于云的功能移至 CCM，如前面部分所述。
|
||||
|
||||
<!--
|
||||
## Plugin mechanism
|
||||
-->
|
||||
|
||||
PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM，如前面部分所述。
|
||||
|
||||
## 插件机制
|
||||
|
||||
云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。
|
||||
<!--
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
|
||||
-->
|
||||
|
||||
上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。
|
||||
云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。
|
||||
|
||||
有关开发插件的更多信息，请参阅
|
||||
[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。
|
||||
|
||||
<!--
|
||||
The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
|
||||
-->
|
||||
|
||||
上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。
|
||||
|
||||
<!--
|
||||
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
-->
|
||||
|
||||
有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
|
||||
|
||||
<!--
|
||||
## Authorization
|
||||
-->
|
||||
|
||||
## 授权
|
||||
|
||||
本节分解了CCM对各种API对象的访问，以执行其操作。
|
||||
<!--
|
||||
This section breaks down the access required on various API objects by the CCM to perform its operations.
|
||||
-->
|
||||
|
||||
本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。
|
||||
|
||||
<!--
|
||||
### Node Controller
|
||||
-->
|
||||
|
||||
### 节点控制器
|
||||
|
||||
节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。
|
||||
<!--
|
||||
The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
|
||||
-->
|
||||
|
||||
Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。
|
||||
|
||||
<!--
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Create
|
||||
- Update
|
||||
- Patch
|
||||
- Watch
|
||||
- Delete
|
||||
-->
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Create
|
||||
- Update
|
||||
- Patch
|
||||
- Watch
|
||||
- Delete
|
||||
|
||||
<!--
|
||||
### Route controller
|
||||
-->
|
||||
|
||||
### 路由控制器
|
||||
|
||||
路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。
|
||||
<!--
|
||||
The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
|
||||
-->
|
||||
|
||||
路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
|
||||
<!--
|
||||
### Service controller
|
||||
-->
|
||||
|
||||
### 服务控制器
|
||||
|
||||
服务控制器侦听服务对象创建、更新和删除事件，然后对这些服务的端点进行恰当的配置。
|
||||
<!--
|
||||
The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
|
||||
-->
|
||||
|
||||
要访问服务，它需要罗列和监控权限。要更新服务，它需要修补和更新权限。
|
||||
服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。
|
||||
|
||||
要为服务设置端点，需要访问创建、列表、获取、监视和更新。
|
||||
<!--
|
||||
To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
|
||||
-->
|
||||
|
||||
要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。
|
||||
|
||||
<!--
|
||||
To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
|
||||
-->
|
||||
|
||||
要为服务设置端点，需要访问 create、list、get、watch 和 update。
|
||||
|
||||
v1/Service:
|
||||
|
||||
- List
|
||||
- Get
|
||||
- Watch
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
<!--
|
||||
### PersistentVolumeLabels controller
|
||||
-->
|
||||
|
||||
### PersistentVolumeLabels 控制器
|
||||
|
||||
PersistentVolumeLabels控制器监听PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。
|
||||
<!--
|
||||
The PersistentVolumeLabels controller listens on PersistentVolume (PV) create events and then updates them. This controller requires access to get and update PVs.
|
||||
-->
|
||||
|
||||
PersistentVolumeLabels 控制器侦听 PersistentVolume（PV）创建事件并更新它们，该控制器需要访问以获取和更新 PV。
|
||||
|
||||
v1/PersistentVolume:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Watch
|
||||
- Update
|
||||
|
||||
<!--
|
||||
### Others
|
||||
-->
|
||||
|
||||
### 其它
|
||||
|
||||
CCM核心的实现需要创建事件的权限，为了确保安全操作，需要创建ServiceAccounts的权限。
|
||||
<!--
|
||||
The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
|
||||
-->
|
||||
|
||||
CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。
|
||||
|
||||
v1/Event:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
v1/ServiceAccount:
|
||||
|
||||
- Create
|
||||
|
||||
针对CCM的RBAC ClusterRole如下所示：
|
||||
<!--
|
||||
The RBAC ClusterRole for the CCM looks like this:
|
||||
-->
|
||||
|
||||
|
||||
针对 CCM 的 RBAC ClusterRole 看起来像这样：
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
@@ -233,9 +516,18 @@ rules:
|
||||
- update
|
||||
```
|
||||
|
||||
<!--
|
||||
## Vendor Implementations
|
||||
-->
|
||||
|
||||
|
||||
## 供应商实施
|
||||
|
||||
以下云服务供应商为自己的云部署了CCM。
|
||||
<!--
|
||||
The following cloud providers have implemented CCMs:
|
||||
-->
|
||||
|
||||
以下云服务提供商已实现了 CCM：
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
@@ -246,4 +538,10 @@ rules:
|
||||
|
||||
## 群集管理
|
||||
|
||||
[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。
|
||||
<!--
|
||||
Complete instructions for configuring and running the CCM are provided
|
||||
[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). -->
|
||||
|
||||
[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -40,7 +40,7 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser
|
||||
从 master（apiserver）到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。
|
||||
|
||||
|
||||
### apiserver -> kubelet
|
||||
## apiserver -> kubelet
|
||||
|
||||
|
||||
从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
|
||||
@@ -52,19 +52,19 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser
|
||||
为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。
|
||||
|
||||
|
||||
如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)。
|
||||
如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
|
||||
|
||||
|
||||
最后，应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
|
||||
最后，应该启用 [Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
|
||||
|
||||
|
||||
### apiserver -> nodes, pods, and services
|
||||
## apiserver -> nodes, pods, and services
|
||||
|
||||
|
||||
从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。
|
||||
从 apiserver 到 node、pod 或者 service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给 API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。
|
||||
|
||||
|
||||
### SSH 隧道
|
||||
## SSH 隧道
|
||||
|
||||
|
||||
[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
|
||||
|
||||
@@ -61,8 +61,8 @@ redirect_from:
|
||||
| ---------------- | ---------------------------------------- |
|
||||
| `OutOfDisk` | `True` 表示 node 的空闲空间不足以用于添加新 pods, 否则为 `False` |
|
||||
| `Ready` | `True` 表示 node 是健康的并已经准备好接受 pods；`False` 表示 node 不健康而且不能接受 pods；`Unknown` 表示 node 控制器在最近 40 秒内没有收到 node 的消息 |
|
||||
| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低, 否则为 `False` |
|
||||
| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低, 否则为 `False` |
|
||||
| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低，否则为 `False` |
|
||||
| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低，否则为 `False` |
|
||||
|
||||
|
||||
Node 条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的 node。
|
||||
@@ -77,10 +77,10 @@ Node 条件使用一个 JSON 对象表示。例如，下面的响应描述了一
|
||||
```
|
||||
|
||||
|
||||
如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数)，node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5分钟**。某些情况下，当 node 不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区 node 上运行。
|
||||
如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下，当 node 不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区 node 上运行。
|
||||
|
||||
|
||||
在 1.5 版本之前的 Kubernetes 里，node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群，集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。
|
||||
在 1.5 版本之前的 Kubernetes 里，node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在 node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群，集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。
|
||||
|
||||
|
||||
### 容量
|
||||
@@ -117,7 +117,7 @@ Node 条件使用一个 JSON 对象表示。例如，下面的响应描述了一
|
||||
Kubernetes 会在内部创一个 node 对象（象征 node），并基于 `metadata.name` 字段（我们假设 `metadata.name` 能够被解析）通过健康检查来验证 node。如果 node 可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。请注意，Kubernetes 将保存不可用 node 的对象，除非它被客户端显式的删除。Kubernetes 将持续检查 node 是否变的可用。
|
||||
|
||||
|
||||
当前，有3个组件同 Kubernetes node 接口交互：node 控制器、kubelet 和 kubectl。
|
||||
当前，有 3 个组件同 Kubernetes node 接口交互：node 控制器、kubelet 和 kubectl。
|
||||
|
||||
|
||||
### Node 控制器
|
||||
@@ -141,13 +141,13 @@ Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当
|
||||
大部分情况下， node 控制器把删除频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它在 10 秒钟内不会从超过一个 node 上删除 pods。
|
||||
|
||||
|
||||
当一个 availability zone 中的 node 变为不健康时，它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），删除速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为50），删除将会停止，否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones，那就只有一个 availability zone（整个集群）。
|
||||
当一个 availability zone 中的 node 变为不健康时，它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），删除速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为 50），删除将会停止，否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones，那就只有一个 availability zone（整个集群）。
|
||||
|
||||
|
||||
在多个 availability zones 分布你的 nodes 的一个关键原因是当整个 zone 故障时，工作负载可以转移到健康的 zones。因此，如果一个 zone 中的所有 nodes 都不健康时，node 控制器会以正常的速率 `--node-eviction-rate` 删除。在所有的 zones 都不健康（也即集群中没有健康 node）的极端情况下，node 控制器将假设 master 的连接出了某些问题，它将停止所有删除动作直到一些连接恢复。
|
||||
|
||||
|
||||
从 Kubernetes 1.6 开始，NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods，如果这些 pods 没有 tolerate 这些 taints。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据 node 故障（例如 node 不可访问或没有 ready）添加 taints。请查看 [这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。
|
||||
从 Kubernetes 1.6 开始，NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods，如果这些 pods 没有 tolerate 这些 taints。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据 node 故障（例如 node 不可访问或没有 ready）添加 taints。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。
|
||||
|
||||
|
||||
### Nodes 自注册
|
||||
@@ -180,7 +180,7 @@ Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当
|
||||
如果管理员希望手动创建 node 对象，请设置 kubelet 标记 `--register-node=false`。
|
||||
|
||||
|
||||
管理员可以修改 node 资源（忽略 `--register-node` 设置）。修改包括在 node 上设置 labels及标记它为不可调度。
|
||||
管理员可以修改 node 资源（忽略 `--register-node` 设置）。修改包括在 node 上设置 labels 及标记它为不可调度。
|
||||
|
||||
|
||||
Nodes 上的 labels 可以和 pods 的 node selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的 nodes 子集上运行。
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "计算、存储和网络扩展"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Compute, Storage, and Networking Extensions"
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
@@ -24,7 +24,7 @@ Add-ons 扩展了 Kubernetes 的功能。
|
||||
* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件， 能够透明的实施 HTTP/API/L7 策略。 同时支持路由（routing）和叠加/封装（ overlay/encapsulation）模式。
|
||||
* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。
|
||||
* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
|
||||
* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。
|
||||
|
||||
@@ -33,7 +33,7 @@ Add-ons 扩展了 Kubernetes 的功能。
|
||||
|
||||
|
||||
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services 等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。
|
||||
|
||||
|
||||
## 遗留 Add-ons
|
||||
|
||||
@@ -17,7 +17,7 @@ title: 证书
|
||||
`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`。
|
||||
|
||||
执行该脚本时需传入两个参数。 第一个参数为 API 服务器的 IP 地址，第二个参数为对象的候补名称列表，
|
||||
形如 `IP:<ip地址> 或 DNS:<dns名称>`。
|
||||
形如 `IP:<ip 地址 > 或 DNS:<dns 名称 >`。
|
||||
|
||||
脚本生成三个文件： `ca.crt`、`server.crt` 和 `server.key`。
|
||||
|
||||
@@ -44,7 +44,7 @@ title: 证书
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
1. 生成服务器证书和密钥。
|
||||
参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP`
|
||||
通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range`同时用于
|
||||
通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range` 同时用于
|
||||
API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。
|
||||
下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
|
||||
@@ -78,7 +78,7 @@ title: 证书
|
||||
|
||||
openssl genrsa -out server.key 2048
|
||||
1. 创建用于生成证书签名请求（CSR）的配置文件。
|
||||
确保在将其保存至文件（如`csr.conf`）之前将尖括号标记的值（如`<MASTER_IP>`）
|
||||
确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`）
|
||||
替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
|
||||
(service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
|
||||
|
||||
@@ -105,5 +105,3 @@ Kubernetes 利用 OpenStack 服务目录对它知道如何使用的服务进行
|
||||
bs-version=v2
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/concept
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。
|
||||
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对[用户指南](/docs/user-guide/)中的概念有一些熟悉。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -24,7 +24,7 @@ content_template: templates/concept
|
||||
|
||||
- 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
|
||||
- **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。
|
||||
- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
|
||||
- 你的集群是在**本地**还是**云（IaaS）**上？ Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
|
||||
- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/)，它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。
|
||||
- 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）**上运行？
|
||||
- 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
@@ -49,10 +49,10 @@ content_template: templates/concept
|
||||
* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
|
||||
|
||||
* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可.
|
||||
* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api)描述了如何为用户和 service accounts 建立权限许可。
|
||||
|
||||
|
||||
* [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能，包括许多认证选项。
|
||||
* [用户认证](/docs/admin/authentication)阐述了 Kubernetes 中的认证功能，包括许多认证选项。
|
||||
|
||||
|
||||
* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。
|
||||
@@ -64,7 +64,7 @@ content_template: templates/concept
|
||||
* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
|
||||
|
||||
* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。
|
||||
* [审计](/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。
|
||||
|
||||
|
||||
### 保护 kubelet
|
||||
@@ -77,11 +77,9 @@ content_template: templates/concept
|
||||
## 可选集群服务
|
||||
|
||||
|
||||
* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。
|
||||
* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。
|
||||
|
||||
|
||||
* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。
|
||||
* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: 控制器管理器指标
|
||||
content_template: templates/concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Controller manager metrics
|
||||
content_template: templates/concept
|
||||
weight: 100
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Controller manager metrics provide important insight into the performance and health of
|
||||
the controller manager.
|
||||
-->
|
||||
|
||||
控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## What are controller manager metrics
|
||||
|
||||
Controller manager metrics provide important insight into the performance and health of the controller manager.
|
||||
These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
|
||||
etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
|
||||
to gauge the health of a cluster.
|
||||
|
||||
Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
|
||||
These metrics can be used to monitor health of persistent volume operations.
|
||||
|
||||
For example, for GCE these metrics are called:
|
||||
-->
|
||||
|
||||
## 什么是控制器管理器度量
|
||||
|
||||
控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
|
||||
这些度量包括常见的 Go 语言运行时度量，比如 go_routine 计数，以及控制器特定的度量，比如 etcd 请求延迟或 云提供商（AWS、GCE、OpenStack）的 API 延迟，这些参数可以用来测量集群的健康状况。
|
||||
|
||||
从 Kubernetes 1.7 版本开始，详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。
|
||||
这些度量可用于监视持久卷操作的健康状况。
|
||||
|
||||
例如，在 GCE 中这些指标叫做：
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
<!--
|
||||
## Configuration
|
||||
|
||||
|
||||
In a cluster, controller-manager metrics are available from `http://localhost:10252/metrics`
|
||||
from the host where the controller-manager is running.
|
||||
|
||||
The metrics are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
|
||||
|
||||
In a production environment you may want to configure prometheus or some other metrics scraper
|
||||
to periodically gather these metrics and make them available in some kind of time series database.
|
||||
-->
|
||||
|
||||
## 配置
|
||||
|
||||
在集群中，控制器管理器指标可从它所在的主机上的 `http://localhost:10252/metrics` 中获得。
|
||||
|
||||
这些指标是以 [prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) 发出的，是人类可读的。
|
||||
|
||||
在生产环境中，您可能想配置 prometheus 或其他一些指标收集工具，以定期收集这些指标数据，并将它们应用到某种时间序列数据库中。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,261 @@
|
||||
---
|
||||
title: 配置 kubelet 垃圾回收策略
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Configuring kubelet Garbage Collection
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
垃圾回收是 kubelet 的一个有用功能，它将清理未使用的镜像和容器。
|
||||
|
||||
<!--
|
||||
Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers.
|
||||
-->
|
||||
|
||||
Kubelet 将每分钟对容器执行一次垃圾回收，每五分钟对镜像执行一次垃圾回收。
|
||||
|
||||
<!--
|
||||
Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes.
|
||||
-->
|
||||
|
||||
不建议使用外部垃圾收集工具，因为这些工具可能会删除原本期望存在的容器进而破坏 kubelet 的行为。
|
||||
|
||||
<!--
|
||||
External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.
|
||||
-->
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 镜像回收
|
||||
|
||||
<!--
|
||||
## Image Collection
|
||||
-->
|
||||
|
||||
Kubernetes 借助于 cadvisor 通过 imageManager 来管理所有镜像的生命周期。
|
||||
|
||||
<!--
|
||||
Kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
of cadvisor.
|
||||
-->
|
||||
|
||||
镜像垃圾回收策略只考虑两个因素：`HighThresholdPercent` 和 `LowThresholdPercent`。
|
||||
|
||||
<!--
|
||||
The policy for garbage collecting images takes two factors into consideration:
|
||||
`HighThresholdPercent` and `LowThresholdPercent`.
|
||||
-->
|
||||
|
||||
磁盘使用率超过上限阈值（HighThresholdPercent）将触发垃圾回收。
|
||||
|
||||
<!--
|
||||
Disk usage above the high threshold will trigger garbage collection.
|
||||
-->
|
||||
|
||||
垃圾回收将删除最近最少使用的镜像，直到磁盘使用率满足下限阈值（LowThresholdPercent）。
|
||||
|
||||
<!--
|
||||
The garbage collection will delete least recently used images until the low
|
||||
threshold has been met.
|
||||
-->
|
||||
|
||||
## 容器回收
|
||||
|
||||
<!--
|
||||
## Container Collection
|
||||
-->
|
||||
|
||||
容器垃圾回收策略考虑三个用户定义变量。
|
||||
|
||||
<!--
|
||||
The policy for garbage collecting containers considers three user-defined variables.
|
||||
-->
|
||||
|
||||
`MinAge` 是容器可以被执行垃圾回收的最小年龄。
|
||||
|
||||
<!--
|
||||
`MinAge` is the minimum age at which a container can be garbage collected.
|
||||
-->
|
||||
|
||||
`MaxPerPodContainer` 是每个 pod 内允许存在的死亡容器的最大数量。
|
||||
|
||||
<!--
|
||||
`MaxPerPodContainer` is the maximum number of dead containers every single
|
||||
pod (UID, container name) pair is allowed to have.
|
||||
-->
|
||||
|
||||
`MaxContainers` 是全部死亡容器的最大数量。
|
||||
|
||||
<!--
|
||||
`MaxContainers` is the maximum number of total dead containers.
|
||||
-->
|
||||
|
||||
可以分别独立地通过将 `MinAge` 设置为 0，以及将 `MaxPerPodContainer` 和 `MaxContainers` 设置为小于 0 来禁用这些变量。
|
||||
|
||||
<!--
|
||||
These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero.
|
||||
-->
|
||||
|
||||
Kubelet 将处理无法辨识的、已删除的以及超出前面提到的参数所设置范围的容器。最老的容器通常会先被移除。
|
||||
|
||||
<!--
|
||||
Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first.
|
||||
-->
|
||||
|
||||
`MaxPerPodContainer` 和 `MaxContainer` 在某些场景下可能会存在冲突，例如在保证每个 pod 内死亡容器的最大数量（`MaxPerPodContainer`）的条件下可能会超过允许存在的全部死亡容器的最大数量（`MaxContainer`）。
|
||||
|
||||
<!--
|
||||
`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`).
|
||||
-->
|
||||
|
||||
`MaxPerPodContainer` 在这种情况下会被进行调整：最坏的情况是将 `MaxPerPodContainer` 降级为 1，并驱逐最老的容器。
|
||||
|
||||
<!--
|
||||
`MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers.
|
||||
-->
|
||||
|
||||
此外，pod 内已经被删除的容器一旦年龄超过 `MinAge` 就会被清理。
|
||||
|
||||
<!--
|
||||
Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`.
|
||||
-->
|
||||
|
||||
不被 kubelet 管理的容器不受容器垃圾回收的约束。
|
||||
|
||||
<!--
|
||||
Containers that are not managed by kubelet are not subject to container garbage collection.
|
||||
-->
|
||||
|
||||
## 用户配置
|
||||
|
||||
<!--
|
||||
## User Configuration
|
||||
-->
|
||||
|
||||
用户可以使用以下 kubelet 参数调整相关阈值来优化镜像垃圾回收：
|
||||
|
||||
<!--
|
||||
Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags :
|
||||
-->
|
||||
|
||||
<!--
|
||||
1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
|
||||
Default is 85%.
|
||||
|
||||
2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
|
||||
to free. Default is 80%.
|
||||
-->
|
||||
|
||||
1. `image-gc-high-threshold`，触发镜像垃圾回收的磁盘使用率百分比。默认值为 85%。
|
||||
|
||||
2. `image-gc-low-threshold`，镜像垃圾回收试图释放资源后达到的磁盘使用率百分比。默认值为 80%。
|
||||
|
||||
我们还允许用户通过以下 kubelet 参数自定义垃圾收集策略：
|
||||
|
||||
<!--
|
||||
We also allow users to customize garbage collection policy through the following kubelet flags:
|
||||
-->
|
||||
|
||||
<!--
|
||||
1. `minimum-container-ttl-duration`, minimum age for a finished container before it is
|
||||
garbage collected. Default is 0 minute, which means every finished container will be garbage collected.
|
||||
|
||||
2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained
|
||||
per container. Default is 1.
|
||||
|
||||
3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
|
||||
Default is -1, which means there is no global limit.
|
||||
-->
|
||||
|
||||
1. `minimum-container-ttl-duration`，完成的容器在被垃圾回收之前的最小年龄，默认是 0 分钟，这意味着每个完成的容器都会被执行垃圾回收。
|
||||
|
||||
2. `maximum-dead-containers-per-container`，每个容器要保留的旧实例的最大数量。默认值为 1。
|
||||
|
||||
3. `maximum-dead-containers`，要全局保留的旧容器实例的最大数量。默认值是 -1，这意味着没有全局限制。
|
||||
|
||||
容器可能会在其效用过期之前被垃圾回收。这些容器可能包含日志和其他对故障诊断有用的数据。
|
||||
|
||||
<!--
|
||||
Containers can potentially be garbage collected before their usefulness has expired. These containers
|
||||
can contain logs and other data that can be useful for troubleshooting.
|
||||
-->
|
||||
|
||||
强烈建议为 `maximum-dead-containers-per-container` 设置一个足够大的值，以便每个预期容器至少保留一个死亡容器。
|
||||
|
||||
<!--
|
||||
A sufficiently large value for `maximum-dead-containers-per-container` is highly recommended
|
||||
to allow at least 1 dead container to be retained per expected container.
|
||||
-->
|
||||
|
||||
由于同样的原因，`maximum-dead-containers` 也建议使用一个足够大的值。
|
||||
|
||||
<!--
|
||||
A larger value for `maximum-dead-containers` is also recommended for a similar reason.
|
||||
-->
|
||||
|
||||
查阅 [这个问题](https://github.com/kubernetes/kubernetes/issues/13287) 获取更多细节。
|
||||
|
||||
<!--
|
||||
See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
|
||||
-->
|
||||
|
||||
## 弃用
|
||||
|
||||
<!--
|
||||
## Deprecation
|
||||
-->
|
||||
|
||||
这篇文档中的一些 kubelet 垃圾收集（Garbage Collection）功能将在未来被 kubelet 驱逐回收（eviction）所替代。
|
||||
|
||||
<!--
|
||||
Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future.
|
||||
-->
|
||||
|
||||
包括:
|
||||
|
||||
| 现存参数 | 新参数 | 解释 |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现存的驱逐回收信号可以触发镜像垃圾回收 |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收实现相同行为 |
|
||||
| `--maximum-dead-containers` | | 一旦旧日志存储在容器上下文之外，就会被弃用 |
|
||||
| `--maximum-dead-containers-per-container` | | 一旦旧日志存储在容器上下文之外，就会被弃用 |
|
||||
| `--minimum-container-ttl-duration` | | 一旦旧日志存储在容器上下文之外，就会被弃用 |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 驱逐回收将磁盘阈值泛化到其他资源 |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 驱逐回收将磁盘压力转换到其他资源 |
|
||||
|
||||
<!--
|
||||
Including:
|
||||
|
||||
| Existing Flag | New Flag | Rationale |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
|
||||
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
|
||||
-->
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
查阅 [配置驱逐回收资源的策略](/docs/tasks/administer-cluster/out-of-resource/) 获取更多细节。
|
||||
|
||||
<!--
|
||||
See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details.
|
||||
-->
|
||||
|
||||
{{% /capture %}}
|
||||
+460
@@ -0,0 +1,460 @@
|
||||
---
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: 日志架构
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
|
||||
-->
|
||||
应用和系统日志可以让您了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。
|
||||
|
||||
<!--
|
||||
However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
|
||||
-->
|
||||
但是，由容器引擎或 runtime 提供的原生功能通常不足以满足完整的日志记录方案。例如，如果发生容器崩溃、pod 被逐出或节点宕机等情况，您仍然想访问到应用日志。因此，日志应该具有独立的存储和生命周期，与节点、pod 或容器的生命周期相独立。这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。Kubernetes 没有为日志数据提供原生存储方案，但是您可以集成许多现有的日志解决方案到 Kubernetes 集群中。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
Cluster-level logging architectures are described in assumption that
|
||||
a logging backend is present inside or outside of your cluster. If you're
|
||||
not interested in having cluster-level logging, you might still find
|
||||
the description of how logs are stored and handled on the node to be useful.
|
||||
-->
|
||||
集群级日志架构假定在集群内部或者外部有一个日志后台。如果您对集群级日志不感兴趣，您仍会发现关于如何在节点上存储和处理日志的描述对您是有用的。
|
||||
|
||||
<!--
|
||||
## Basic logging in Kubernetes
|
||||
|
||||
In this section, you can see an example of basic logging in Kubernetes that
|
||||
outputs data to the standard output stream. This demonstration uses
|
||||
a [pod specification](/examples/debug/counter-pod.yaml) with
|
||||
a container that writes some text to standard output once per second.
|
||||
-->
|
||||
## Kubernetes 中的基本日志记录
|
||||
|
||||
本节，您会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。
|
||||
这里通过一个特定的 [pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器，并令该容器每秒钟向标准输出写入数据。
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
To run this pod, use the following command:
|
||||
-->
|
||||
用下面的命令运行 pod：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
pod/counter created
|
||||
```
|
||||
|
||||
<!--
|
||||
To fetch the logs, use the `kubectl logs` command, as follows:
|
||||
-->
|
||||
使用 `kubectl logs` 命令获取日志:
|
||||
|
||||
```shell
|
||||
$ kubectl logs counter
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
-->
|
||||
一旦发生容器崩溃，您可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。
|
||||
如果 pod 中有多个容器，您应该向该命令附加一个容器名以访问对应容器的日志。
|
||||
详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。
|
||||
|
||||
<!--
|
||||
## Logging at the node level
|
||||
-->
|
||||
## 节点级日志记录
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
|
||||
-->
|
||||
容器化应用写入 `stdout` 和 `stderr` 的任何数据，都会被容器引擎捕获并被重定向到某个位置。
|
||||
例如，Docker 容器引擎将这两个输出流重定向到某个 [日志驱动](https://docs.docker.com/engine/admin/logging/overview) ，
|
||||
该日志驱动在 Kubernetes 中配置为以 json 格式写入文件。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
Docker json 日志驱动将日志的每一行当作一条独立的消息。该日志驱动不直接支持多行消息。您需要在日志代理级别或更高级别处理多行消息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
|
||||
-->
|
||||
默认情况下，如果容器重启，kubelet 会保留被终止的容器日志。
|
||||
如果 pod 在工作节点被驱逐，该 pod 中所有的容器也会被驱逐，包括容器日志。
|
||||
|
||||
<!--
|
||||
An important consideration in node-level logging is implementing log rotation,
|
||||
so that logs don't consume all available storage on the node. Kubernetes
|
||||
currently is not responsible for rotating logs, but rather a deployment tool
|
||||
should set up a solution to address that.
|
||||
For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
|
||||
there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
|
||||
tool configured to run each hour. You can also set up a container runtime to
|
||||
rotate application's logs automatically, e.g. by using Docker's `log-opt`.
|
||||
In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
|
||||
and the former approach is used in any other environment. In both cases, by
|
||||
default rotation is configured to take place when log file exceeds 10MB.
|
||||
-->
|
||||
节点级日志记录中，需要重点考虑实现日志的轮转，以此来保证日志不会消耗节点上所有的可用空间。
|
||||
Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个解决问题的方案。
|
||||
例如，在 Kubernetes 集群中，用 `kube-up.sh` 部署一个每小时运行的工具 [`logrotate`](https://linux.die.net/man/8/logrotate)。
|
||||
您也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 `log-opt` 选项。
|
||||
在 `kube-up.sh` 脚本中，使用后一种方式来处理 GCP 上的 COS 镜像，而使用前一种方式来处理其他环境。
|
||||
这两种方式，默认日志超过 10MB 大小时都会触发日志轮转。
|
||||
|
||||
<!--
|
||||
As an example, you can find detailed information about how `kube-up.sh` sets
|
||||
up logging for COS image on GCP in the corresponding [script]
|
||||
[cosConfigureHelper].
|
||||
-->
|
||||
例如，您可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息，
|
||||
相应的脚本在 [这里][cosConfigureHelper]。
|
||||
|
||||
<!--
|
||||
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
|
||||
the basic logging example, the kubelet on the node handles the request and
|
||||
reads directly from the log file, returning the contents in the response.
|
||||
-->
|
||||
当运行 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) 时，
|
||||
节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Currently, if some external system has performed the rotation,
|
||||
only the contents of the latest log file will be available through
|
||||
`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
|
||||
the rotation and there are two files, one 10MB in size and one empty,
|
||||
`kubectl logs` will return an empty response.
|
||||
-->
|
||||
当前，如果有其他系统机制执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。
|
||||
比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。
|
||||
|
||||
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch">}}/cluster/gce/gci/configure-helper.sh
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### System component logs
|
||||
|
||||
There are two types of system components: those that run in a container and those
|
||||
that do not run in a container. For example:
|
||||
-->
|
||||
### 系统组件日志
|
||||
|
||||
有两种类型的系统组件，运行在容器中的和未运行在容器中的。例如：
|
||||
|
||||
<!--
|
||||
* The Kubernetes scheduler and kube-proxy run in a container.
|
||||
* The kubelet and container runtime, for example Docker, do not run in containers.
|
||||
-->
|
||||
* 运行在容器中的 Kubernetes 调度器和 kube-proxy。
|
||||
* 未运行在容器中的 kubelet 和容器 runtime，比如 Docker。
|
||||
|
||||
<!--
|
||||
On machines with systemd, the kubelet and container runtime write to journald. If
|
||||
systemd is not present, they write to `.log` files in the `/var/log` directory.
|
||||
System components inside containers always write to the `/var/log` directory,
|
||||
bypassing the default logging mechanism. They use the [glog][glog]
|
||||
logging library. You can find the conventions for logging severity for those
|
||||
components in the [development docs on logging](https://git.k8s.io/community/contributors/devel/logging.md).
|
||||
-->
|
||||
在使用 systemd 机制的服务器上，kubelet 和容器 runtime 写入日志到 journald。
|
||||
如果没有 systemd，他们写入日志到 `/var/log` 目录的 `.log` 文件。
|
||||
容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。他们使用 [glog][glog] 日志库。
|
||||
您可以在[日志开发文档](https://git.k8s.io/community/contributors/devel/logging.md)找到这些组件的日志告警级别协议。
|
||||
|
||||
<!--
|
||||
Similarly to the container logs, system component logs in the `/var/log`
|
||||
directory should be rotated. In Kubernetes clusters brought up by
|
||||
the `kube-up.sh` script, those logs are configured to be rotated by
|
||||
the `logrotate` tool daily or once the size exceeds 100MB.
|
||||
-->
|
||||
和容器日志类似，`/var/log` 目录中的系统组件日志也应该被轮转。
|
||||
通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中，日志被工具 `logrotate` 执行每日轮转，或者日志大小超过 100MB 时触发轮转。
|
||||
|
||||
[glog]: https://godoc.org/github.com/golang/glog
|
||||
|
||||
<!--
|
||||
## Cluster-level logging architectures
|
||||
-->
|
||||
## 集群级别日志架构
|
||||
|
||||
<!--
|
||||
While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options:
|
||||
|
||||
* Use a node-level logging agent that runs on every node.
|
||||
* Include a dedicated sidecar container for logging in an application pod.
|
||||
* Push logs directly to a backend from within an application.
|
||||
-->
|
||||
虽然 Kubernetes 并未提供原生的集群级记录日志方案，但是您可以考虑几种常见的方式。以下是一些选项：
|
||||
|
||||
* 使用运行在各个节点上的节点级日志代理。
|
||||
* 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。
|
||||
* 在应用程序中将日志直接推送到后台。
|
||||
|
||||
<!--
|
||||
### Using a node logging agent
|
||||
-->
|
||||
### 使用节点级日志代理
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node.
|
||||
-->
|
||||
您可以在每个节点上使用 _节点级的日志代理_ 来实现集群级日志记录。
|
||||
日志代理是专门的工具，它会暴露出日志或将日志推送到后台。
|
||||
通常来说，日志代理是一个容器，这个容器可以访问这个节点上所有应用容器的日志目录。
|
||||
|
||||
<!--
|
||||
Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged.
|
||||
-->
|
||||
因为日志代理必须在每个节点上运行，所以通常的实现方式为，DaemonSet 副本、manifest pod 或者专用于本地的进程。
|
||||
但是后两种方式已被弃用并且不被推荐。
|
||||
|
||||
<!--
|
||||
Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_.
|
||||
-->
|
||||
对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式，因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。
|
||||
但是，节点级的日志 _仅适用于应用程序的标准输出和标准错误输出_。
|
||||
|
||||
<!--
|
||||
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
|
||||
-->
|
||||
Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
|
||||
[Stackdriver 日志](/docs/user-guide/logging/stackdriver) 适用于 Google Cloud Platform，和 [Elasticsearch](/docs/user-guide/logging/elasticsearch)。
|
||||
您可以在专门的文档中找到更多的信息和说明。两者都使用 [fluentd](http://www.fluentd.org/) 与自定义配置作为节点上的代理。
|
||||
|
||||
<!--
|
||||
### Using a sidecar container with the logging agent
|
||||
-->
|
||||
### 使用 sidecar 容器和日志代理
|
||||
|
||||
<!--
|
||||
You can use a sidecar container in one of the following ways:
|
||||
-->
|
||||
您可以通过以下方式之一使用 sidecar 容器：
|
||||
|
||||
<!--
|
||||
* The sidecar container streams application logs to its own `stdout`.
|
||||
* The sidecar container runs a logging agent, which is configured to pick up logs from an application container.
|
||||
-->
|
||||
* sidecar 容器将应用程序日志传送到自己的标准输出。
|
||||
* sidecar 容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。
|
||||
|
||||
<!--
|
||||
#### Streaming sidecar container
|
||||
-->
|
||||
#### 传输数据流的 sidecar 容器
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
By having your sidecar containers stream to their own `stdout` and `stderr`
|
||||
streams, you can take advantage of the kubelet and the logging agent that
|
||||
already run on each node. The sidecar containers read logs from a file, a socket,
|
||||
or the journald. Each individual sidecar container prints log to its own `stdout`
|
||||
or `stderr` stream.
|
||||
-->
|
||||
利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式，您就可以利用每个节点上的 kubelet 和日志代理来处理日志。
|
||||
sidecar 容器从文件，socket 或 journald 读取日志。每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。
|
||||
|
||||
<!--
|
||||
This approach allows you to separate several log streams from different
|
||||
parts of your application, some of which can lack support
|
||||
for writing to `stdout` or `stderr`. The logic behind redirecting logs
|
||||
is minimal, so it's hardly a significant overhead. Additionally, because
|
||||
`stdout` and `stderr` are handled by the kubelet, you can use built-in tools
|
||||
like `kubectl logs`.
|
||||
-->
|
||||
这种方式允许您分离出不同的日志流，这些日志流来自您应用的不同功能，其中一些可能缺乏对写入 `stdout` 和 `stderr` 的支持。
|
||||
重定向背后的逻辑很小，所以不会是很严重的开销。
|
||||
除此之外，因为 kubelet 处理 `stdout` 和 `stderr`，所以您照样可以使用 `kubectl logs` 工具。
|
||||
|
||||
<!--
|
||||
Consider the following example. A pod runs a single container, and the container
|
||||
writes to two different log files, using two different formats. Here's a
|
||||
configuration file for the Pod:
|
||||
-->
|
||||
考虑接下来的例子。pod 的容器向两个文件写不同格式的日志，下面是这个 pod 的配置文件:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
It would be a mess to have log entries of different formats in the same log
|
||||
stream, even if you managed to redirect both components to the `stdout` stream of
|
||||
the container. Instead, you could introduce two sidecar containers. Each sidecar
|
||||
container could tail a particular log file from a shared volume and then redirect
|
||||
the logs to its own `stdout` stream.
|
||||
-->
|
||||
在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使您试图重定向它们到容器的 `stdout` 流。
|
||||
取而代之的是，您可以引入两个 sidecar 容器。
|
||||
每一个 sidecar 容器可以从共享卷跟踪特定的日志文件，并重定向文件内容到各自的 `stdout` 流。
|
||||
|
||||
<!--
|
||||
Here's a configuration file for a pod that has two sidecar containers:
|
||||
-->
|
||||
这是运行两个 sidecar 容器的 pod 文件。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
<!--
|
||||
Now when you run this pod, you can access each log stream separately by
|
||||
running the following commands:
|
||||
-->
|
||||
现在当您运行这个 pod 时，您可以分别地访问每一个日志流，运行如下命令：
|
||||
|
||||
```shell
|
||||
$ kubectl logs counter count-log-1
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl logs counter count-log-2
|
||||
Mon Jan 1 00:00:00 UTC 2001 INFO 0
|
||||
Mon Jan 1 00:00:01 UTC 2001 INFO 1
|
||||
Mon Jan 1 00:00:02 UTC 2001 INFO 2
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
The node-level agent installed in your cluster picks up those log streams
|
||||
automatically without any further configuration. If you like, you can configure
|
||||
the agent to parse log lines depending on the source container.
|
||||
-->
|
||||
无需深入配置，集群中的节点级代理即可自动地收集流日志。如果您愿意，您可以配置代理程序来解析源容器的日志行。
|
||||
|
||||
<!--
|
||||
Note, that despite low CPU and memory usage (order of couple of millicores
|
||||
for cpu and order of several megabytes for memory), writing logs to a file and
|
||||
then streaming them to `stdout` can double disk usage. If you have
|
||||
an application that writes to a single file, it's generally better to set
|
||||
`/dev/stdout` as destination rather than implementing the streaming sidecar
|
||||
container approach.
|
||||
-->
|
||||
注意，尽管 CPU 和内存使用率都很低（以多个 cpu millicores 指标排序或者按 memory 的兆字节排序），
|
||||
向文件写日志然后输出到 `stdout` 流仍然会成倍地增加磁盘使用率。
|
||||
如果您的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，而不是使用流式的 sidecar 容器方式。
|
||||
|
||||
<!--
|
||||
Sidecar containers can also be used to rotate log files that cannot be
|
||||
rotated by the application itself. [An example](https://github.com/samsung-cnct/logrotate)
|
||||
of this approach is a small container running logrotate periodically.
|
||||
However, it's recommended to use `stdout` and `stderr` directly and leave rotation
|
||||
and retention policies to the kubelet.
|
||||
-->
|
||||
应用本身如果不具备轮转日志文件的功能，可以通过 sidecar 容器实现。
|
||||
该方式的 [例子](https://github.com/samsung-cnct/logrotate) 是运行一个定期轮转日志的容器。
|
||||
然而，还是推荐直接使用 `stdout` 和 `stderr`，将日志的轮转和保留策略交给 kubelet。
|
||||
|
||||
<!--
|
||||
#### Sidecar container with a logging agent
|
||||
-->
|
||||
### 具有日志代理功能的 sidecar 容器
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
If the node-level logging agent is not flexible enough for your situation, you
|
||||
can create a sidecar container with a separate logging agent that you have
|
||||
configured specifically to run with your application.
|
||||
-->
|
||||
如果节点级的日志代理对您的环境来说不够灵活，您可以在 sidecar 容器中创建一个独立的、专门为您的应用而配置的日志代理。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Using a logging agent in a sidecar container can lead
|
||||
to significant resource consumption. Moreover, you won't be able to access
|
||||
those logs using `kubectl logs` command, because they are not controlled
|
||||
by the kubelet.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
在 sidecar 容器中使用日志代理会导致严重的资源损耗。此外，您不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
|
||||
which uses fluentd as a logging agent. Here are two configuration files that
|
||||
you can use to implement this approach. The first file contains
|
||||
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
|
||||
-->
|
||||
例如，您可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，它用 fluentd 作为日志代理。
|
||||
这是实现此种方式的两个配置文件。
|
||||
第一个文件包含配置 fluentd 的 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The configuration of fluentd is beyond the scope of this article. For
|
||||
information about configuring fluentd, see the
|
||||
[official fluentd documentation](http://docs.fluentd.org/).
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
fluentd 的配置文件已经超出了本文的讨论范畴。
|
||||
有关配置 fluentd 的更多信息，请见 [官方 fluentd 文档](http://docs.fluentd.org/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The second file describes a pod that has a sidecar container running fluentd.
|
||||
The pod mounts a volume where fluentd can pick up its configuration data.
|
||||
-->
|
||||
第二个文件描述了运行 fluentd sidecar 容器的 pod 。flutend 通过 pod 的挂载卷获取它的配置数据。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
|
||||
<!--
|
||||
After some time you can find log messages in the Stackdriver interface.
|
||||
-->
|
||||
一段时间后，您可以在 Stackdriver 界面看到日志消息。
|
||||
|
||||
<!--
|
||||
Remember, that this is just an example and you can actually replace fluentd
|
||||
with any logging agent, reading from any source inside an application
|
||||
container.
|
||||
-->
|
||||
记住，这只是一个例子，事实上您可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。
|
||||
|
||||
<!--
|
||||
### Exposing logs directly from the application
|
||||
-->
|
||||
|
||||
### 从应用中直接暴露日志目录
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
You can implement cluster-level logging by exposing or pushing logs directly from
|
||||
every application; however, the implementation for such a logging mechanism
|
||||
is outside the scope of Kubernetes.
|
||||
-->
|
||||
通过暴露或推送每个应用的日志，您可以实现集群级日志记录；然而，这种日志记录机制的实现已超出 Kubernetes 的范围。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,629 @@
|
||||
---
|
||||
reviewers:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
- mikedanese
|
||||
title: 管理资源
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
- mikedanese
|
||||
title: Managing Resources
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/).
|
||||
-->
|
||||
您已经部署了应用并通过服务暴露它。然后呢？Kubernetes 提供了一些工具来帮助管理您的应用部署，包括缩扩容和更新。我们将更深入讨论的特性包括[配置文件](/docs/concepts/configuration/overview/)和[标签](/docs/concepts/overview/working-with-objects/labels/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Organizing resource configurations
|
||||
|
||||
Many applications require multiple resources to be created, such as a Deployment and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by `---` in YAML). For example:
|
||||
-->
|
||||
## 组织资源配置
|
||||
|
||||
许多应用需要创建多个资源，例如 Deployment 和 Service。可以通过将多个资源组合在同一个文件中（在 YAML 中以 `---` 分隔）来简化对它们的管理。例如：
|
||||
|
||||
{{< codenew file="application/nginx-app.yaml" >}}
|
||||
|
||||
<!--
|
||||
Multiple resources can be created the same way as a single resource:
|
||||
-->
|
||||
可以用创建单个资源相同的方式来创建多个资源：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
service/my-nginx-svc created
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
The resources will be created in the order they appear in the file. Therefore, it's best to specify the service first, since that will ensure the scheduler can spread the pods associated with the service as they are created by the controller(s), such as Deployment.
|
||||
-->
|
||||
资源将按照它们在文件中的顺序创建。因此，最好先指定服务，这样在控制器（例如 Deployment）创建 Pod 时能够确保调度器可以将与服务关联的多个 Pod 分散到不同节点。
|
||||
|
||||
<!--
|
||||
`kubectl create` also accepts multiple `-f` arguments:
|
||||
-->
|
||||
`kubectl create` 也接受多个 `-f` 参数:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
And a directory can be specified rather than or in addition to individual files:
|
||||
-->
|
||||
还可以指定目录路径，而不用添加多个单独的文件：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/application/nginx/
|
||||
```
|
||||
|
||||
<!--
|
||||
`kubectl` will read any files with suffixes `.yaml`, `.yml`, or `.json`.
|
||||
|
||||
It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, then you can then simply deploy all of the components of your stack en masse.
|
||||
|
||||
A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github:
|
||||
-->
|
||||
`kubectl` 将读取任何后缀为 `.yaml`，`.yml` 或者 `.json` 的文件。
|
||||
|
||||
建议的做法是，将同一个微服务或同一应用层相关的资源放到同一个文件中，将同一个应用相关的所有文件按组存放到同一个目录中。如果应用的各层使用 DNS 相互绑定，那么您可以简单地将堆栈的所有组件一起部署。
|
||||
|
||||
还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
## Bulk operations in kubectl
|
||||
|
||||
Resource creation isn't the only operation that `kubectl` can perform in bulk. It can also extract resource names from configuration files in order to perform other operations, in particular to delete the same resources you created:
|
||||
-->
|
||||
## kubectl 中的批量操作
|
||||
|
||||
资源创建并不是 `kubectl` 可以批量执行的唯一操作。`kubectl` 还可以从配置文件中提取资源名，以便执行其他操作，特别是删除您之前创建的资源：
|
||||
|
||||
```shell
|
||||
$ kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
||||
<!--
|
||||
In the case of just two resources, it's also easy to specify both on the command line using the resource/name syntax:
|
||||
-->
|
||||
在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中同时指定这两个资源：
|
||||
|
||||
```shell
|
||||
$ kubectl delete deployments/my-nginx services/my-nginx-svc
|
||||
```
|
||||
|
||||
<!--
|
||||
For larger numbers of resources, you'll find it easier to specify the selector (label query) specified using `-l` or `--selector`, to filter resources by their labels:
|
||||
-->
|
||||
对于资源数目较大的情况，您会发现使用 `-l` 或 `--selector` 指定的筛选器（标签查询）能很容易根据标签筛选资源：
|
||||
|
||||
```shell
|
||||
$ kubectl delete deployment,services -l app=nginx
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
||||
<!--
|
||||
Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`:
|
||||
-->
|
||||
由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同，所以很容易使用 `$()` 或 `xargs` 进行链式操作：
|
||||
|
||||
```shell
|
||||
$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
||||
```
|
||||
|
||||
<!--
|
||||
With the above commands, we first create resources under `examples/application/nginx/` and print the resources created with `-o name` output format
|
||||
(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`.
|
||||
-->
|
||||
上面的命令中，我们首先使用 `examples/application/nginx/` 下的配置文件创建资源，并使用 `-o name` 的输出格式（以"资源/名称"的形式打印每个资源）打印所创建的资源。然后，我们通过 `grep` 来过滤 "service"，最后再打印 `kubectl get` 的内容。
|
||||
|
||||
<!--
|
||||
If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag.
|
||||
-->
|
||||
如果您碰巧在某个路径下的多个子路径中组织资源，那么也可以递归地在所有子路径上执行操作，方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。
|
||||
|
||||
<!--
|
||||
For instance, assume there is a directory `project/k8s/development` that holds all of the manifests needed for the development environment, organized by resource type:
|
||||
-->
|
||||
例如，假设有一个目录路径为 `project/k8s/development`，它保存开发环境所需的所有清单，并按资源类型组织：
|
||||
|
||||
```
|
||||
project/k8s/development
|
||||
├── configmap
|
||||
│ └── my-configmap.yaml
|
||||
├── deployment
|
||||
│ └── my-deployment.yaml
|
||||
└── pvc
|
||||
└── my-pvc.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we had tried to create the resources in this directory using the following command, we would have encountered an error:
|
||||
-->
|
||||
默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级，而不是处理所有子目录。
|
||||
如果我们试图使用以下命令在此目录中创建资源，则会遇到一个错误：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f project/k8s/development
|
||||
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
||||
```
|
||||
|
||||
<!--
|
||||
Instead, specify the `--recursive` or `-R` flag with the `--filename,-f` flag as such:
|
||||
-->
|
||||
然而，在 `--filename,-f` 后面标明 `--recursive` 或者 `-R` 之后：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f project/k8s/development --recursive
|
||||
configmap/my-config created
|
||||
deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
<!--
|
||||
The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout} etc.`
|
||||
|
||||
The `--recursive` flag also works when multiple `-f` arguments are provided:
|
||||
-->
|
||||
`--recursive` 可以用于接受 `--filename,-f` 参数的任何操作，例如：`kubectl {create,get,delete,describe,rollout}` 等。
|
||||
|
||||
有多个 `-f` 参数出现的时候，`--recursive` 参数也能正常工作：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f project/k8s/namespaces -f project/k8s/development --recursive
|
||||
namespace/development created
|
||||
namespace/staging created
|
||||
configmap/my-config created
|
||||
deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
<!--
|
||||
If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/reference/kubectl/overview/).
|
||||
-->
|
||||
如果您有兴趣学习更多关于 `kubectl` 的内容，请阅读 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
|
||||
<!--
|
||||
## Using labels effectively
|
||||
|
||||
The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.
|
||||
-->
|
||||
## 有效地使用标签
|
||||
|
||||
到目前为止我们使用的示例中的资源最多使用了一个标签。在许多情况下，应使用多个标签来区分集合。
|
||||
|
||||
<!--
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
-->
|
||||
例如，不同的应用可能会为 `app` 标签设置不同的值。
|
||||
但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 这样的多层应用，还需要区分每一层。前端可以带以下标签：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
while the Redis master and slave would have different `tier` labels, and perhaps even an additional `role` label:
|
||||
-->
|
||||
Redis 的主节点和从节点会有不同的 `tier` 标签，甚至还有一个额外的 `role` 标签：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: master
|
||||
```
|
||||
|
||||
<!--
|
||||
and
|
||||
-->
|
||||
以及
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: slave
|
||||
```
|
||||
|
||||
<!--
|
||||
The labels allow us to slice and dice our resources along any dimension specified by a label:
|
||||
-->
|
||||
标签允许我们按照标签指定的任何维度对我们的资源进行切片和切块：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
|
||||
$ kubectl get pods -Lapp -Ltier -Lrole
|
||||
NAME READY STATUS RESTARTS AGE APP TIER ROLE
|
||||
guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master
|
||||
guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave
|
||||
guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave
|
||||
my-nginx-divi2 1/1 Running 0 29m nginx <none> <none>
|
||||
my-nginx-o0ef1 1/1 Running 0 29m nginx <none> <none>
|
||||
$ kubectl get pods -lapp=guestbook,role=slave
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
guestbook-redis-slave-2q2yf 1/1 Running 0 3m
|
||||
guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Canary deployments
|
||||
-->
|
||||
## 金丝雀部署
|
||||
|
||||
<!--
|
||||
Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
|
||||
-->
|
||||
另一个需要多标签的场景是用来区分同一组件的不同版本或者不同配置的多个部署。常见的做法是部署一个使用*金丝雀发布*来部署新应用版本（在 pod 模板中通过镜像标签指定），保持新旧版本应用同时运行，这样，新版本在完全发布之前也可以接收实时的生产流量。
|
||||
|
||||
<!--
|
||||
For instance, you can use a `track` label to differentiate different releases.
|
||||
|
||||
The primary, stable release would have a `track` label with value as `stable`:
|
||||
-->
|
||||
例如，您可以使用 `track` 标签来区分不同的版本。
|
||||
|
||||
主要稳定的发行版将有一个 `track` 标签，其值为 `stable`：
|
||||
|
||||
```yaml
|
||||
name: frontend
|
||||
replicas: 3
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: stable
|
||||
...
|
||||
image: gb-frontend:v3
|
||||
```
|
||||
|
||||
<!--
|
||||
and then you can create a new release of the guestbook frontend that carries the `track` label with different value (i.e. `canary`), so that two sets of pods would not overlap:
|
||||
-->
|
||||
然后，您可以创建 guestbook 前端的新版本，让这些版本的 `track` 标签带有不同的值（即 `canary`），以便两组 pod 不会重叠：
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
replicas: 1
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: canary
|
||||
...
|
||||
image: gb-frontend:v4
|
||||
```
|
||||
|
||||
<!--
|
||||
The frontend service would span both sets of replicas by selecting the common subset of their labels (i.e. omitting the `track` label), so that the traffic will be redirected to both applications:
|
||||
-->
|
||||
前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本，以便流量可以转发到两个应用：
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
|
||||
Once you're confident, you can update the stable track to the new application release and remove the canary one.
|
||||
-->
|
||||
您可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心，您就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`，并且将老版本应用删除。
|
||||
|
||||
<!--
|
||||
For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
|
||||
-->
|
||||
想要了解更具体的示例，请查看 [Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。
|
||||
|
||||
<!--
|
||||
## Updating labels
|
||||
|
||||
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
|
||||
For example, if you want to label all your nginx pods as frontend tier, simply run:
|
||||
-->
|
||||
## 更新标签
|
||||
|
||||
有时，现有的 pod 和其它资源需要在创建新资源之前重新标记。这可以用 `kubectl label` 完成。
|
||||
例如，如果想要将所有 nginx pod 标记为前端层，只需运行：
|
||||
|
||||
```shell
|
||||
$ kubectl label pods -l app=nginx tier=fe
|
||||
pod/my-nginx-2035384211-j5fhi labeled
|
||||
pod/my-nginx-2035384211-u2c7e labeled
|
||||
pod/my-nginx-2035384211-u3t6x labeled
|
||||
```
|
||||
|
||||
<!--
|
||||
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
|
||||
To see the pods you just labeled, run:
|
||||
-->
|
||||
首先用标签 "app=nginx" 过滤所有的 pod，然后用 "tier=fe" 标记它们。想要查看您刚才标记的 pod，请运行：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l app=nginx -L tier
|
||||
NAME READY STATUS RESTARTS AGE TIER
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe
|
||||
my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
|
||||
my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
||||
```
|
||||
|
||||
<!--
|
||||
This outputs all "app=nginx" pods, with an additional label column of pods' tier (specified with `-L` or `--label-columns`).
|
||||
|
||||
For more information, please see [labels](/docs/concepts/overview/working-with-objects/labels/) and [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
|
||||
-->
|
||||
这将输出所有 "app=nginx" 的 pod，并有一个额外的描述 pod 的 tier 的标签列（用参数 `-L` 或者 `--label-columns` 标明）。
|
||||
|
||||
想要了解更多信息，请参考 [标签](/docs/concepts/overview/working-with-objects/labels/) 和 [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)。
|
||||
|
||||
<!--
|
||||
## Updating annotations
|
||||
|
||||
Sometimes you would want to attach annotations to resources. Annotations are arbitrary non-identifying metadata for retrieval by API clients such as tools, libraries, etc. This can be done with `kubectl annotate`. For example:
|
||||
-->
|
||||
## 更新注解
|
||||
|
||||
有时，您可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如：
|
||||
|
||||
```shell
|
||||
$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
||||
$ kubectl get pods my-nginx-v4-9gw19 -o yaml
|
||||
apiversion: v1
|
||||
kind: pod
|
||||
metadata:
|
||||
annotations:
|
||||
description: my frontend running nginx
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
For more information, please see [annotations](/docs/concepts/overview/working-with-objects/annotations/) and [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) document.
|
||||
-->
|
||||
想要了解更多信息，请参考 [注解](/docs/concepts/overview/working-with-objects/annotations/) 和 [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 文档。
|
||||
|
||||
<!--
|
||||
## Scaling your application
|
||||
|
||||
When load on your application grows or shrinks, it's easy to scale with `kubectl`. For instance, to decrease the number of nginx replicas from 3 to 1, do:
|
||||
-->
|
||||
## 缩扩您的应用
|
||||
|
||||
当应用上的负载增长或收缩时，使用 `kubectl` 能够轻松实现规模的缩扩。例如，要将 nginx 副本的数量从 3 减少到 1，请执行以下操作：
|
||||
|
||||
```shell
|
||||
$ kubectl scale deployment/my-nginx --replicas=1
|
||||
deployment.extensions/my-nginx scaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Now you only have one pod managed by the deployment.
|
||||
-->
|
||||
现在，您的 deployment 管理的 pod 只有一个了。
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l app=nginx
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 30m
|
||||
```
|
||||
|
||||
<!--
|
||||
To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do:
|
||||
-->
|
||||
想要让系统自动选择需要 nginx 副本的数量，范围从 1 到 3，请执行以下操作：
|
||||
|
||||
```shell
|
||||
$ kubectl autoscale deployment/my-nginx --min=1 --max=3
|
||||
horizontalpodautoscaler.autoscaling/my-nginx autoscaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Now your nginx replicas will be scaled up and down as needed, automatically.
|
||||
|
||||
For more information, please see [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document.
|
||||
-->
|
||||
现在，您的 nginx 副本将根据需要自动地增加或者减少。
|
||||
|
||||
想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 和 [pod 水平自动伸缩](/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。
|
||||
|
||||
<!--
|
||||
## In-place updates of resources
|
||||
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
|
||||
-->
|
||||
## 就地更新资源
|
||||
|
||||
有时，有必要对您所创建的资源进行小范围、无干扰地更新。
|
||||
|
||||
### kubectl apply
|
||||
|
||||
<!--
|
||||
It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)),
|
||||
so that they can be maintained and versioned along with the code for the resources they configure.
|
||||
Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to push your configuration changes to the cluster.
|
||||
-->
|
||||
建议在源代码管理中维护一组配置文件（参见[配置即代码](http://martinfowler.com/bliki/InfrastructureAsCode.html)），这样，它们就可以和应用代码一样进行维护和版本管理。然后，您可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。
|
||||
|
||||
<!--
|
||||
This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
|
||||
-->
|
||||
这个命令将会把推送的版本与以前的版本进行比较，并应用您所做的更改，但是不会自动覆盖任何你没有指定更改的属性。
|
||||
|
||||
```shell
|
||||
$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
deployment.apps/my-nginx configured
|
||||
```
|
||||
|
||||
<!--
|
||||
Note that `kubectl apply` attaches an annotation to the resource in order to determine the changes to the configuration since the previous invocation. When it's invoked, `kubectl apply` does a three-way diff between the previous configuration, the provided input and the current configuration of the resource, in order to determine how to modify the resource.
|
||||
-->
|
||||
注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。当调用它时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间找出三方差异，以确定如何修改资源。
|
||||
|
||||
<!--
|
||||
Currently, resources are created without this annotation, so the first invocation of `kubectl apply` will fall back to a two-way diff between the provided input and the current configuration of the resource. During this first invocation, it cannot detect the deletion of properties set when the resource was created. For this reason, it will not remove them.
|
||||
-->
|
||||
目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 将使用提供的输入和资源的当前配置双方之间差异进行比较。在第一次调用期间，它无法检测资源创建时属性集的删除情况。因此，不会删除它们。
|
||||
|
||||
<!--
|
||||
All subsequent calls to `kubectl apply`, and other commands that modify the configuration, such as `kubectl replace` and `kubectl edit`, will update the annotation, allowing subsequent calls to `kubectl apply` to detect and perform deletions using a three-way diff.
|
||||
-->
|
||||
所有后续调用 `kubectl apply` 以及其它修改配置的命令，如 `kubectl replace` 和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
想要使用 apply，请始终使用 `kubectl apply` 或 `kubectl create --save-config` 创建资源。
|
||||
{{< /note >}}
|
||||
|
||||
### kubectl edit
|
||||
|
||||
<!--
|
||||
Alternatively, you may also update resources with `kubectl edit`:
|
||||
-->
|
||||
或者，您也可以使用 `kubectl edit` 更新资源：
|
||||
|
||||
```shell
|
||||
$ kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
This is equivalent to first `get` the resource, edit it in text editor, and then `apply` the resource with the updated version:
|
||||
-->
|
||||
这相当于首先 `get` 资源，在文本编辑器中编辑它，然后用更新的版本 `apply` 资源：
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
|
||||
$ vi /tmp/nginx.yaml
|
||||
# do some edit, and then save the file
|
||||
$ kubectl apply -f /tmp/nginx.yaml
|
||||
deployment.apps/my-nginx configured
|
||||
$ rm /tmp/nginx.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
This allows you to do more significant changes more easily. Note that you can specify the editor with your `EDITOR` or `KUBE_EDITOR` environment variables.
|
||||
|
||||
For more information, please see [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) document.
|
||||
-->
|
||||
这使您可以更加容易地进行更重大的更改。请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。
|
||||
|
||||
想要了解更多信息，请参考 [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。
|
||||
|
||||
### kubectl patch
|
||||
|
||||
<!--
|
||||
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
|
||||
JSON merge patch, and strategic merge patch. See
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
||||
and
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
-->
|
||||
您可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch，JSON merge patch，以及 strategic merge patch。 请参考
|
||||
[使用 kubectl patch 更新 API 对象](/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
||||
和
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
|
||||
<!--
|
||||
## Disruptive updates
|
||||
|
||||
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may just want to make a recursive change immediately, such as to fix broken pods created by a Deployment. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can simply modify your original configuration file:
|
||||
-->
|
||||
## 破坏性的更新
|
||||
|
||||
在某些情况下，您可能需要更新某些初始化后无法更新的资源字段，或者您可能只想立即进行递归更改，例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，它将删除并重新创建资源。在这种情况下，您可以简单地修改原始配置文件：
|
||||
|
||||
```shell
|
||||
$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
||||
deployment.apps/my-nginx deleted
|
||||
deployment.apps/my-nginx replaced
|
||||
```
|
||||
|
||||
<!--
|
||||
## Updating your application without a service outage
|
||||
-->
|
||||
## 在不中断服务的情况下更新应用
|
||||
|
||||
<!--
|
||||
At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
|
||||
-->
|
||||
在某些时候，您最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，每种更新操作都适用于不同的场景。
|
||||
|
||||
<!--
|
||||
We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers,
|
||||
you should read [how to use `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) instead.
|
||||
-->
|
||||
我们将指导您通过 Deployment 如何创建和更新应用。如果部署的应用由 `ReplicationController` 管理，那么您应该阅读 [怎么样使用 `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/)。
|
||||
|
||||
<!--
|
||||
Let's say you were running version 1.7.9 of nginx:
|
||||
-->
|
||||
假设您正运行的是 1.7.9 版本的 nginx：
|
||||
|
||||
```shell
|
||||
$ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
|
||||
-->
|
||||
要更新到 1.9.1 版本，只需使用我们前面学到的 kubectl 命令将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 修改为 `nginx:1.9.1`。
|
||||
|
||||
```shell
|
||||
$ kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/).
|
||||
-->
|
||||
没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 pod 数量的新副本被创建。想要了解更多细节，请参考 [Deployment](/docs/concepts/workloads/controllers/deployment/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
- [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
|
||||
- [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/)
|
||||
-->
|
||||
- [学习怎么样使用 `kubectl` 观察和调试应用](/docs/tasks/debug-application-cluster/debug-application-introspection/)
|
||||
- [配置最佳实践和技巧](/docs/concepts/configuration/overview/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "配置"
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Configuration"
|
||||
weight: 70
|
||||
---
|
||||
-->
|
||||
@@ -1,22 +1,74 @@
|
||||
---
|
||||
title: 为容器管理计算资源
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
feature:
|
||||
title: 自动装箱
|
||||
description: >
|
||||
根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Managing Compute Resources for Containers
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
feature:
|
||||
title: Automatic binpacking
|
||||
description: >
|
||||
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
|
||||
<!--
|
||||
When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how
|
||||
much CPU and memory (RAM) each Container needs. When Containers have resource
|
||||
requests specified, the scheduler can make better decisions about which nodes to
|
||||
place Pods on. And when Containers have their limits specified, contention for
|
||||
resources on a node can be handled in a specified manner. For more details about
|
||||
the difference between requests and limits, see
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||
-->
|
||||
当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Resource types
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit.
|
||||
CPU is specified in units of cores, and memory is specified in units of bytes.
|
||||
CPU and memory are collectively referred to as *compute resources*, or just
|
||||
*resources*. Compute
|
||||
resources are measurable quantities that can be requested, allocated, and
|
||||
consumed. They are distinct from
|
||||
[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and
|
||||
[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified
|
||||
through the Kubernetes API server.
|
||||
-->
|
||||
|
||||
## 资源类型
|
||||
|
||||
*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。
|
||||
*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。
|
||||
|
||||
CPU和内存统称为*计算资源* ，也可以称为*资源* 。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
|
||||
CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。
|
||||
|
||||
<!--
|
||||
## Resource requests and limits of Pod and Container
|
||||
Each Container of a Pod can specify one or more of the following:
|
||||
* `spec.containers[].resources.limits.cpu`
|
||||
* `spec.containers[].resources.limits.memory`
|
||||
* `spec.containers[].resources.requests.cpu`
|
||||
* `spec.containers[].resources.requests.memory`
|
||||
Although requests and limits can only be specified on individual Containers, it
|
||||
is convenient to talk about Pod resource requests and limits. A
|
||||
*Pod resource request/limit* for a particular resource type is the sum of the
|
||||
resource requests/limits of that type for each Container in the Pod.
|
||||
-->
|
||||
|
||||
## Pod 和 容器的资源请求和限制
|
||||
|
||||
@@ -29,6 +81,27 @@ Pod 中的每个容器都可以指定以下的一个或者多个值：
|
||||
|
||||
尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。
|
||||
|
||||
<!--
|
||||
## Meaning of CPU
|
||||
Limits and requests for CPU resources are measured in *cpu* units.
|
||||
One cpu, in Kubernetes, is equivalent to:
|
||||
- 1 AWS vCPU
|
||||
- 1 GCP Core
|
||||
- 1 Azure vCore
|
||||
- 1 IBM vCPU
|
||||
- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading
|
||||
Fractional requests are allowed. A Container with
|
||||
`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much
|
||||
CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the
|
||||
expression `100m`, which can be read as "one hundred millicpu". Some people say
|
||||
"one hundred millicores", and this is understood to mean the same thing. A
|
||||
request with a decimal point, like `0.1`, is converted to `100m` by the API, and
|
||||
precision finer than `1m` is not allowed. For this reason, the form `100m` might
|
||||
be preferred.
|
||||
CPU is always requested as an absolute quantity, never as a relative quantity;
|
||||
0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine.
|
||||
-->
|
||||
|
||||
## CPU 的含义
|
||||
|
||||
CPU 资源的限制和请求以 *cpu* 为单位。
|
||||
@@ -44,6 +117,14 @@ Kubernetes 中的一个 cpu 等于：
|
||||
|
||||
CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。
|
||||
|
||||
<!--
|
||||
## Meaning of memory
|
||||
Limits and requests for `memory` are measured in bytes. You can express memory as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
-->
|
||||
|
||||
## 内存的含义
|
||||
|
||||
内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值：
|
||||
@@ -52,6 +133,14 @@ CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
Here's an example.
|
||||
The following Pod has two Containers. Each Container has a request of 0.25 cpu
|
||||
and 64MiB (2<sup>26</sup> bytes) of memory. Each Container has a limit of 0.5
|
||||
cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128
|
||||
MiB of memory, and a limit of 1 cpu and 256MiB of memory.
|
||||
-->
|
||||
|
||||
下面是个例子。
|
||||
|
||||
以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。
|
||||
@@ -83,27 +172,91 @@ spec:
|
||||
cpu: "500m"
|
||||
```
|
||||
|
||||
<!--
|
||||
## How Pods with resource requests are scheduled
|
||||
When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
|
||||
run on. Each node has a maximum capacity for each of the resource types: the
|
||||
amount of CPU and memory it can provide for Pods. The scheduler ensures that,
|
||||
for each resource type, the sum of the resource requests of the scheduled
|
||||
Containers is less than the capacity of the node. Note that although actual memory
|
||||
or CPU resource usage on nodes is very low, the scheduler still refuses to place
|
||||
a Pod on a node if the capacity check fails. This protects against a resource
|
||||
shortage on a node when resource usage later increases, for example, during a
|
||||
daily peak in request rate.
|
||||
-->
|
||||
|
||||
## 具有资源请求的 Pod 如何调度
|
||||
|
||||
当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。
|
||||
|
||||
<!--
|
||||
## How Pods with resource limits are run
|
||||
When the kubelet starts a Container of a Pod, it passes the CPU and memory limits
|
||||
to the container runtime.
|
||||
When using Docker:
|
||||
-->
|
||||
|
||||
## 具有资源限制的 Pod 如何运行
|
||||
|
||||
当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。
|
||||
|
||||
当使用 Docker 时：
|
||||
|
||||
- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值，这是个浮点数，并乘以1024，这个数字中的较大者或2用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
|
||||
<!--
|
||||
- The `spec.containers[].resources.requests.cpu` is converted to its core value,
|
||||
which is potentially fractional, and multiplied by 1024. The greater of this number
|
||||
or 2 is used as the value of the
|
||||
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint)
|
||||
flag in the `docker run` command.
|
||||
- The `spec.containers[].resources.limits.cpu` is converted to its millicore value and
|
||||
multiplied by 100. The resulting value is the total amount of CPU time that a container can use
|
||||
every 100ms. A container cannot use more than its share of CPU time during this interval.
|
||||
-->
|
||||
|
||||
- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值，这是个浮点数，并乘以 1024，这个数字中的较大者或 2 用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
|
||||
|
||||
- `spec.containers[].resources.limits.cpu` 被转换成 millicore 值。被乘以 100000 然后 除以 1000。这个数字用作 `docker run` 命令中的 [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) 标志的值。[`--cpu-quota` ] 标志被设置成了 100000，表示测量配额使用的默认100ms 周期。如果 [`--cpu-cfs-quota`] 标志设置为 true，则 kubelet 会强制执行 cpu 限制。从 Kubernetes 1.2 版本起，此标志默认为 true。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
|
||||
{{</ note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
默认配额限制为 100 毫秒。 CPU配额的最小单位为 1 毫秒。
|
||||
{{</ note >}}
|
||||
|
||||
- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。
|
||||
|
||||
<!--
|
||||
If a Container exceeds its memory limit, it might be terminated. If it is
|
||||
restartable, the kubelet will restart it, as with any other type of runtime
|
||||
failure.
|
||||
If a Container exceeds its memory request, it is likely that its Pod will
|
||||
be evicted whenever the node runs out of memory.
|
||||
A Container might or might not be allowed to exceed its CPU limit for extended
|
||||
periods of time. However, it will not be killed for excessive CPU usage.
|
||||
To determine whether a Container cannot be scheduled or is being killed due to
|
||||
resource limits, see the
|
||||
[Troubleshooting](#troubleshooting) section.
|
||||
-->
|
||||
|
||||
如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。
|
||||
|
||||
如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。
|
||||
|
||||
容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。
|
||||
|
||||
要确定容器是否由于资源限制而无法安排或被杀死，请参阅 [疑难解答](#troubleshooting) 部分。
|
||||
要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。
|
||||
|
||||
<!--
|
||||
## Monitoring compute resource usage
|
||||
The resource usage of a Pod is reported as part of the Pod status.
|
||||
If [optional monitoring](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)
|
||||
is configured for your cluster, then Pod resource usage can be retrieved from
|
||||
the monitoring system.
|
||||
-->
|
||||
|
||||
## 监控计算资源使用
|
||||
|
||||
@@ -111,6 +264,14 @@ Pod 的资源使用情况被报告为 Pod 状态的一部分。
|
||||
|
||||
如果为集群配置了 [可选监控](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
### My Pods are pending with event message failedScheduling
|
||||
If the scheduler cannot find any node where a Pod can fit, the Pod remains
|
||||
unscheduled until a place can be found. An event is produced each time the
|
||||
scheduler fails to find a place for the Pod, like this:
|
||||
-->
|
||||
|
||||
## 疑难解答
|
||||
|
||||
### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling
|
||||
@@ -124,8 +285,29 @@ Events:
|
||||
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||
```
|
||||
|
||||
<!-
|
||||
In the preceding example, the Pod named "frontend" fails to be scheduled due to
|
||||
insufficient CPU resource on the node. Similar error messages can also suggest
|
||||
failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod
|
||||
is pending with a message of this type, there are several things to try:
|
||||
- Add more nodes to the cluster.
|
||||
- Terminate unneeded Pods to make room for pending Pods.
|
||||
- Check that the Pod is not larger than all the nodes. For example, if all the
|
||||
nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will
|
||||
never be scheduled.
|
||||
You can check node capacities and amounts allocated with the
|
||||
`kubectl describe nodes` command. For example:
|
||||
-->
|
||||
|
||||
在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情：
|
||||
|
||||
- 向集群添加更多节点。
|
||||
- 终止不需要的 Pod，为待处理的 Pod 腾出空间。
|
||||
- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。
|
||||
|
||||
您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如：
|
||||
|
||||
|
||||
```shell
|
||||
$ kubectl describe nodes e2e-test-minion-group-4lw4
|
||||
Name: e2e-test-minion-group-4lw4
|
||||
@@ -156,6 +338,21 @@ Allocated resources:
|
||||
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
|
||||
```
|
||||
|
||||
<!--
|
||||
In the preceding output, you can see that if a Pod requests more than 1120m
|
||||
CPUs or 6.23Gi of memory, it will not fit on the node.
|
||||
By looking at the `Pods` section, you can see which Pods are taking up space on
|
||||
the node.
|
||||
The amount of resources available to Pods is less than the node capacity, because
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
|
||||
to limit the total amount of resources that can be consumed. If used in conjunction
|
||||
with namespaces, it can prevent one team from hogging all the resources.
|
||||
-->
|
||||
|
||||
在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。
|
||||
|
||||
通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。
|
||||
@@ -164,6 +361,13 @@ Pod 可用的资源量小于节点容量，因为系统守护程序使用一部
|
||||
|
||||
可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。
|
||||
|
||||
<!--
|
||||
### My Container is terminated
|
||||
Your Container might get terminated because it is resource-starved. To check
|
||||
whether a Container is being killed because it is hitting a resource limit, call
|
||||
`kubectl describe pod` on the Pod of interest:
|
||||
-->
|
||||
|
||||
## 我的容器被终止了
|
||||
|
||||
您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`：
|
||||
@@ -210,6 +414,13 @@ Events:
|
||||
|
||||
您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。
|
||||
|
||||
<!--
|
||||
In the preceding example, the `Restart Count: 5` indicates that the `simmemleak`
|
||||
Container in the Pod was terminated and restarted five times.
|
||||
You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
|
||||
of previously terminated Containers:
|
||||
-->
|
||||
|
||||
```shell
|
||||
[13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-60xbc
|
||||
Container Name: simmemleak
|
||||
@@ -218,6 +429,10 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
|
||||
|
||||
您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。
|
||||
|
||||
<!--
|
||||
You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory.
|
||||
-->
|
||||
|
||||
## 不透明整型资源（Alpha功能）
|
||||
|
||||
Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源允许集群运维人员发布新的节点级资源，否则系统将不了解这些资源。
|
||||
@@ -275,6 +490,26 @@ spec:
|
||||
pod.alpha.kubernetes.io/opaque-int-resource-foo: 1
|
||||
```
|
||||
|
||||
<!--
|
||||
## Planned Improvements
|
||||
Kubernetes version 1.5 only allows resource quantities to be specified on a
|
||||
Container. It is planned to improve accounting for resources that are shared by
|
||||
all Containers in a Pod, such as
|
||||
[emptyDir volumes](/docs/concepts/storage/volumes/#emptydir).
|
||||
Kubernetes version 1.5 only supports Container requests and limits for CPU and
|
||||
memory. It is planned to add new resource types, including a node disk space
|
||||
resource, and a framework for adding custom
|
||||
[resource types](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/scheduling/resources.md).
|
||||
Kubernetes supports overcommitment of resources by supporting multiple levels of
|
||||
[Quality of Service](http://issue.k8s.io/168).
|
||||
In Kubernetes version 1.5, one unit of CPU means different things on different
|
||||
cloud providers, and on different machine types within the same cloud providers.
|
||||
For example, on AWS, the capacity of a node is reported in
|
||||
[ECUs](http://aws.amazon.com/ec2/faqs/), while in GCE it is reported in logical
|
||||
cores. We plan to revise the definition of the cpu resource to allow for more
|
||||
consistency across providers and platforms.
|
||||
-->
|
||||
|
||||
## 计划改进
|
||||
|
||||
在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。
|
||||
@@ -288,12 +523,15 @@ Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||
* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
-->
|
||||
|
||||
- 获取将 [CPU 和内存资源分配给容器](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) 的实践经验
|
||||
- [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
|
||||
- [ResourceRequirements](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,280 @@
|
||||
---
|
||||
title: 使用 kubeconfig 文件组织集群访问
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Organizing Cluster Access Using kubeconfig Files
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Use kubeconfig files to organize information about clusters, users, namespaces, and
|
||||
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
|
||||
find the information it needs to choose a cluster and communicate with the API server
|
||||
of a cluster.
|
||||
--->
|
||||
使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
A file that is used to configure access to clusters is called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
--->
|
||||
{{< note >}}
|
||||
注意：用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
|
||||
You can specify other kubeconfig files by setting the `KUBECONFIG` environment
|
||||
variable or by setting the
|
||||
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
|
||||
--->
|
||||
默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。您可以通过设置 `KUBECONFIG` 环境变量或者设置[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。
|
||||
|
||||
<!--
|
||||
For step-by-step instructions on creating and specifying kubeconfig files, see
|
||||
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
|
||||
--->
|
||||
有关创建和指定 kubeconfig 文件的分步说明，请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Supporting multiple clusters, users, and authentication mechanisms
|
||||
--->
|
||||
## 支持多集群、用户和身份认证机制
|
||||
|
||||
<!--
|
||||
Suppose you have several clusters, and your users and components authenticate
|
||||
in a variety of ways. For example:
|
||||
--->
|
||||
假设您有多个集群，并且您的用户和组件以多种方式进行身份认证。比如：
|
||||
|
||||
<!--
|
||||
- A running kubelet might authenticate using certificates.
|
||||
- A user might authenticate using tokens.
|
||||
- Administrators might have sets of certificates that they provide to individual users.
|
||||
--->
|
||||
- 正在运行的 kubelet 可能使用证书在进行认证。
|
||||
- 用户可能通过令牌进行认证。
|
||||
- 管理员可能拥有多个证书集合提供给各用户。
|
||||
|
||||
<!--
|
||||
With kubeconfig files, you can organize your clusters, users, and namespaces.
|
||||
You can also define contexts to quickly and easily switch between
|
||||
clusters and namespaces.
|
||||
--->
|
||||
使用 kubeconfig 文件，您可以组织集群、用户和命名空间。您还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。
|
||||
|
||||
<!--
|
||||
## Context
|
||||
--->
|
||||
## 上下文（Context）
|
||||
|
||||
<!--
|
||||
A *context* element in a kubeconfig file is used to group access parameters
|
||||
under a convenient name. Each context has three parameters: cluster, namespace, and user.
|
||||
By default, the `kubectl` command-line tool uses parameters from
|
||||
the *current context* to communicate with the cluster.
|
||||
--->
|
||||
通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。
|
||||
|
||||
<!--
|
||||
To choose the current context:
|
||||
--->
|
||||
选择当前上下文
|
||||
```
|
||||
kubectl config use-context
|
||||
```
|
||||
|
||||
<!--
|
||||
## The KUBECONFIG environment variable
|
||||
--->
|
||||
## KUBECONFIG 环境变量
|
||||
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable holds a list of kubeconfig files.
|
||||
For Linux and Mac, the list is colon-delimited. For Windows, the list
|
||||
is semicolon-delimited. The `KUBECONFIG` environment variable is not
|
||||
required. If the `KUBECONFIG` environment variable doesn't exist,
|
||||
`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`.
|
||||
--->
|
||||
`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。`KUBECONFIG` 环境变量不是必要的。如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
|
||||
|
||||
<!--
|
||||
If the `KUBECONFIG` environment variable does exist, `kubectl` uses
|
||||
an effective configuration that is the result of merging the files
|
||||
listed in the `KUBECONFIG` environment variable.
|
||||
--->
|
||||
如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
|
||||
|
||||
<!--
|
||||
## Merging kubeconfig files
|
||||
--->
|
||||
## 合并 kubeconfig 文件
|
||||
|
||||
<!--
|
||||
To see your configuration, enter this command:
|
||||
--->
|
||||
要查看配置，输入以下命令：
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
As described previously, the output might be from a single kubeconfig file,
|
||||
or it might be the result of merging several kubeconfig files.
|
||||
--->
|
||||
如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
|
||||
|
||||
<!--
|
||||
Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
||||
--->
|
||||
以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。
|
||||
|
||||
<!--
|
||||
1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge.
|
||||
Only one instance of this flag is allowed.
|
||||
|
||||
Otherwise, if the `KUBECONFIG` environment variable is set, use it as a
|
||||
list of files that should be merged.
|
||||
Merge the files listed in the `KUBECONFIG` environment variable
|
||||
according to these rules:
|
||||
|
||||
* Ignore empty filenames.
|
||||
* Produce errors for files with content that cannot be deserialized.
|
||||
* The first file to set a particular value or map key wins.
|
||||
* Never change the value or map key.
|
||||
Example: Preserve the context of the first file to set `current-context`.
|
||||
Example: If two files specify a `red-user`, use only values from the first file's `red-user`.
|
||||
Even if the second file has non-conflicting entries under `red-user`, discard them.
|
||||
--->
|
||||
1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。
|
||||
|
||||
否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件：
|
||||
|
||||
* 忽略空文件名。
|
||||
* 对于内容无法反序列化的文件，产生错误信息。
|
||||
* 第一个设置特定值或者映射键的文件将生效。
|
||||
* 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。
|
||||
|
||||
<!--
|
||||
For an example of setting the `KUBECONFIG` environment variable, see
|
||||
[Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
|
||||
--->
|
||||
有关设置 `KUBECONFIG` 环境变量的示例，请参阅[设置 KUBECONFIG 环境变量](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
|
||||
<!--
|
||||
Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
|
||||
--->
|
||||
否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。
|
||||
|
||||
<!--
|
||||
1. Determine the context to use based on the first hit in this chain:
|
||||
|
||||
1. Use the `--context` command-line flag if it exists.
|
||||
2. Use the `current-context` from the merged kubeconfig files.
|
||||
--->
|
||||
1. 根据此链中的第一个匹配确定要使用的上下文。
|
||||
|
||||
1. 如果存在，使用 `--context` 命令行参数。
|
||||
2. 使用合并的 kubeconfig 文件中的 `current-context`。
|
||||
|
||||
<!--
|
||||
An empty context is allowed at this point.
|
||||
--->
|
||||
这种场景下允许空上下文。
|
||||
|
||||
<!--
|
||||
1. Determine the cluster and user. At this point, there might or might not be a context.
|
||||
Determine the cluster and user based on the first hit in this chain,
|
||||
which is run twice: once for user and once for cluster:
|
||||
|
||||
1. Use a command-line flag if it exists: `--user` or `--cluster`.
|
||||
2. If the context is non-empty, take the user or cluster from the context.
|
||||
--->
|
||||
1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。
|
||||
|
||||
1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。
|
||||
2. 如果上下文非空，从上下文中获取用户或集群。
|
||||
|
||||
<!--
|
||||
The user and cluster can be empty at this point.
|
||||
--->
|
||||
这种场景下用户和集群可以为空。
|
||||
|
||||
<!--
|
||||
1. Determine the actual cluster information to use. At this point, there might or
|
||||
might not be cluster information.
|
||||
Build each piece of the cluster information based on this chain; the first hit wins:
|
||||
|
||||
1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`.
|
||||
2. If any cluster information attributes exist from the merged kubeconfig files, use them.
|
||||
3. If there is no server location, fail.
|
||||
--->
|
||||
1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：
|
||||
|
||||
1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。
|
||||
2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。
|
||||
3. 如果没有 server 配置，则配置无效。
|
||||
|
||||
<!--
|
||||
2. Determine the actual user information to use. Build user information using the same
|
||||
rules as cluster information, except allow only one authentication
|
||||
technique per user:
|
||||
|
||||
1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`.
|
||||
2. Use the `user` fields from the merged kubeconfig files.
|
||||
3. If there are two conflicting techniques, fail.
|
||||
--->
|
||||
2. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：
|
||||
|
||||
1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。
|
||||
2. 使用合并的 kubeconfig 文件中的 `user` 字段。
|
||||
3. 如果存在两种冲突技术，则配置无效。
|
||||
|
||||
<!--
|
||||
3. For any information still missing, use default values and potentially
|
||||
prompt for authentication information.
|
||||
--->
|
||||
3. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。
|
||||
|
||||
<!--
|
||||
## File references
|
||||
--->
|
||||
## 文件引用
|
||||
|
||||
<!--
|
||||
File and path references in a kubeconfig file are relative to the location of the kubeconfig file.
|
||||
File references on the command line are relative to the current working directory.
|
||||
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
|
||||
are stored absolutely.
|
||||
--->
|
||||
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
--->
|
||||
* [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
reviewers:
|
||||
- bsalamat
|
||||
title: 调度器性能调优
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
reviewers:
|
||||
- bsalamat
|
||||
title: Scheduler Performance Tuning
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
--- -->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" >}}
|
||||
|
||||
<!-- Kube-scheduler is the Kubernetes default scheduler. It is responsible for
|
||||
placement of Pods on Nodes in a cluster. Nodes in a cluster that meet the
|
||||
scheduling requirements of a Pod are called "feasible" Nodes for the Pod. The
|
||||
scheduler finds feasible Nodes for a Pod and then runs a set of functions to
|
||||
score the feasible Nodes and picks a Node with the highest score among the
|
||||
feasible ones to run the Pod. The scheduler then notifies the API server about this
|
||||
decision in a process called "Binding". -->
|
||||
|
||||
Kube-scheduler 是 Kubernetes 的默认调度器。负责将 Pods 安排到集群中的节点上。
|
||||
集群中达到 Pod 调度要求的节点也被称为这个 Pod 的“可行性”节点。
|
||||
调度器首先找出 Pod 的可行性节点，然后运行一套打分函数来为可行性节点打分，
|
||||
最后挑选出分数最高的可行性节点来运行 Pod。随后，调度器将这个决定通知给 API 服务器，
|
||||
这个通知流程叫做“绑定”（"Binding"）。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- ## Percentage of Nodes to Score -->
|
||||
## 可行性打分的节点比例
|
||||
|
||||
<!-- Before Kubernetes 1.12, Kube-scheduler used to check the feasibility of all the
|
||||
nodes in a cluster and then scored the feasible ones. Kubernetes 1.12 has a new
|
||||
feature that allows the scheduler to stop looking for more feasible nodes once
|
||||
it finds a certain number of them. This improves the scheduler's performance in
|
||||
large clusters. The number is specified as a percentage of the cluster size and
|
||||
is controlled by a configuration option called `percentageOfNodesToScore`. The
|
||||
range should be between 1 and 100. Other values are considered as 100%. The
|
||||
default value of this option is 50%. A cluster administrator can change this value by providing a
|
||||
different value in the scheduler configuration. However, it may not be necessary to change this value. -->
|
||||
|
||||
在 Kubernetes 1.12 之前， Kube-scheduler 曾经是检查集群中所有节点的可行性，并为它们依次打分。
|
||||
而在 Kubernetes 1.12 中加入了一项新的功能，允许调度器在找到足够合适的可行性节点之后，停止搜索。
|
||||
这项功能将提高调度器在大型集群应用中的性能。这是一个比例参数，通过一个名为 `percentageOfNodesToScore` 的配置选项，
|
||||
指明了集群大小中的比例。参数值范围在 1 到 100 之间。其它的数值将被认为是 100%。
|
||||
选项的默认值为 50%。集群管理员也可以在调度器的配置文件中，提供不同数值来做修改。
|
||||
但可能也并不需要修改这个值。
|
||||
|
||||
```yaml
|
||||
apiVersion: componentconfig/v1alpha1
|
||||
kind: KubeSchedulerConfiguration
|
||||
algorithmSource:
|
||||
provider: DefaultProvider
|
||||
|
||||
...
|
||||
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
<!-- **Note**: In clusters with zero or less than 50 feasible nodes, the
|
||||
scheduler still checks all the nodes, simply because there are not enough
|
||||
feasible nodes to stop the scheduler's search early. -->
|
||||
|
||||
**注意**：如果集群中可行性节点的数量为 0 或者小于 50 个，调度器还是会检查所有的节点，
|
||||
仅仅是因为没有足够多的可行性节点让调度器终止搜索。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- **To disable this feature**, you can set `percentageOfNodesToScore` to 100. -->
|
||||
可以将 `percentageOfNodesToScore` 设置为 100 来**禁止这项功能**。
|
||||
|
||||
<!-- ### Tuning percentageOfNodesToScore -->
|
||||
### 调优 `percentageOfNodesToScore`
|
||||
|
||||
<!-- `percentageOfNodesToScore` must be a value between 1 and 100
|
||||
with the default value of 50. There is also a hardcoded minimum value of 50
|
||||
nodes which is applied internally. The scheduler tries to find at
|
||||
least 50 nodes regardless of the value of `percentageOfNodesToScore`. This means
|
||||
that changing this option to lower values in clusters with several hundred nodes
|
||||
will not have much impact on the number of feasible nodes that the scheduler
|
||||
tries to find. This is intentional as this option is unlikely to improve
|
||||
performance noticeably in smaller clusters. In large clusters with over a 1000
|
||||
nodes setting this value to lower numbers may show a noticeable performance
|
||||
improvement. -->
|
||||
|
||||
`percentageOfNodesToScore` 的数值必须在 1 到 100 之间，默认值为 50。
|
||||
在内部设计里面，还存在有硬编码的至少 50 个节点的要求。无论 `percentageOfNodesToScore` 设置如何，
|
||||
调度器都至少会搜索 50 个节点。换言之，在只有数百个节点的集群中调低这个参数，并不会对调度器搜索可行性节点有影响。
|
||||
这样设计是经过考虑的，因为在较小的集群中，这个参数并不会显著提升性能。
|
||||
而在超过 1000 个节点的大型集群中调低这个参数，将会有显著的性能提升。
|
||||
|
||||
<!-- An important note to consider when setting this value is that when a smaller
|
||||
number of nodes in a cluster are checked for feasibility, some nodes are not
|
||||
sent to be scored for a given Pod. As a result, a Node which could possibly
|
||||
score a higher value for running the given Pod might not even be passed to the
|
||||
scoring phase. This would result in a less than ideal placement of the Pod. For
|
||||
this reason, the value should not be set to very low percentages. A general rule
|
||||
of thumb is to never set the value to anything lower than 30. Lower values
|
||||
should be used only when the scheduler's throughput is critical for your
|
||||
application and the score of nodes is not important. In other words, you prefer
|
||||
to run the Pod on any Node as long as it is feasible. -->
|
||||
|
||||
在设置这个数值时，需要注意一点，如果集群中只有较少的一部分节点进行了可行性检查，
|
||||
有些节点将不会被作可行性打分。
|
||||
因而，有运行 Pod 可行性分数更高的节点甚至可能不会到达打分阶段。这会造成一个并不十分理想的安排结果。
|
||||
正因为如此，这个数值不应该设置得非常低。
|
||||
一个重要原则就是这个数值不应该小于 30。
|
||||
更小的数值只应该在应用对调度器的吞吐量十分敏感，而节点的可行性打分相对不重要的前提下使用。
|
||||
换言之，只要节点适合运行 Pod 就可以安排到该节点上运行。
|
||||
|
||||
<!-- It is not recommended to lower this value from its default if your cluster has
|
||||
only several hundred Nodes. It is unlikely to improve the scheduler's
|
||||
performance significantly. -->
|
||||
|
||||
如果集群只有数百个节点，我们不建议将参数值调到比默认值低。因为这并不能显著提升调度器的性能。
|
||||
|
||||
<!-- ### How the scheduler iterates over Nodes -->
|
||||
### 调度器是如何遍历节点的
|
||||
|
||||
<!-- This section is intended for those who want to understand the internal details
|
||||
of this feature. -->
|
||||
|
||||
这一节是为那些希望了解这项功能内部细节的人准备的。
|
||||
|
||||
<!-- In order to give all the Nodes in a cluster a fair chance of being considered
|
||||
for running Pods, the scheduler iterates over the nodes in a round robin
|
||||
fashion. You can imagine that Nodes are in an array. The scheduler starts from
|
||||
the start of the array and checks feasibility of the nodes until it finds enough
|
||||
Nodes as specified by `percentageOfNodesToScore`. For the next Pod, the
|
||||
scheduler continues from the point in the Node array that it stopped at when checking
|
||||
feasibility of Nodes for the previous Pod. -->
|
||||
|
||||
为了让集群中所有的节点都有平等的机会被考虑运行 Pods，调度器需要以轮转的方式遍历所有的节点。
|
||||
你可以这样理解：所有节点都在记录在某数组之中，调度器从数组的一端开始检查节点的可行性，直到找到 `percentageOfNodesToScore`
|
||||
指明的、足够多的节点。对于下一个 pod，调度器将从前一个 Pod 的结束节点开始，继续开始搜索。
|
||||
|
||||
<!-- If Nodes are in multiple zones, the scheduler iterates over Nodes in various
|
||||
zones to ensure that Nodes from different zones are considered in the
|
||||
feasibility checks. As an example, consider six nodes in two zones: -->
|
||||
|
||||
如果节点在不同的区域，调度器也将遍历不同区域的所有节点，保证不同区域的节点都会被考虑在列。
|
||||
例如，如果六个节点分布在两个区域：
|
||||
|
||||
```
|
||||
Zone 1: Node 1, Node 2, Node 3, Node 4
|
||||
Zone 2: Node 5, Node 6
|
||||
```
|
||||
|
||||
<!-- The Scheduler evaluates feasibility of the nodes in this order: -->
|
||||
|
||||
调度器将会按照下面的顺序来对所有的节点进行可行性检查：
|
||||
|
||||
```
|
||||
Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
|
||||
```
|
||||
|
||||
<!-- After going over all the Nodes, it goes back to Node 1. -->
|
||||
|
||||
当遍历完所有的节点后，会重新从 Node 1 开始搜索。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -548,13 +548,13 @@ spec:
|
||||
|
||||
### 客户端使用 Secret API
|
||||
|
||||
当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。
|
||||
当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](/docs/admin/authorization/rbac/) 之类的 [授权策略](/docs/admin/authorization/) 来限制访问。
|
||||
|
||||
Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
|
||||
|
||||
由于这些原因，在命名空间中 `watch` 和 `list` secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中`watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。
|
||||
|
||||
需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。
|
||||
需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。
|
||||
|
||||
为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "容器"
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Containers"
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
@@ -0,0 +1,229 @@
|
||||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: 容器生命周期钩子
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Container Lifecycle Hooks
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
-->
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page describes how kubelet managed Containers can use the Container lifecycle hook framework
|
||||
to run code triggered by events during their management lifecycle.
|
||||
-->
|
||||
这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
|
||||
## 概述
|
||||
|
||||
<!--
|
||||
Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular,
|
||||
Kubernetes provides Containers with lifecycle hooks.
|
||||
The hooks enable Containers to be aware of events in their management lifecycle
|
||||
and run code implemented in a handler when the corresponding lifecycle hook is executed.
|
||||
-->
|
||||
类似于许多具有生命周期钩子组件的编程语言框架，例如Angular，Kubernetes为容器提供了生命周期钩子。
|
||||
钩子使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期钩子时运行在处理程序中实现的代码。
|
||||
|
||||
<!--
|
||||
## Container hooks
|
||||
-->
|
||||
|
||||
## 容器钩子
|
||||
|
||||
<!--
|
||||
There are two hooks that are exposed to Containers:
|
||||
-->
|
||||
有两个钩子暴露在容器中:
|
||||
|
||||
`PostStart`
|
||||
|
||||
<!--
|
||||
This hook executes immediately after a container is created.
|
||||
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
|
||||
No parameters are passed to the handler.
|
||||
-->
|
||||
这个钩子在创建容器之后立即执行。
|
||||
但是，不能保证钩子会在容器入口点之前执行。
|
||||
没有参数传递给处理程序。
|
||||
|
||||
`PreStop`
|
||||
|
||||
<!--
|
||||
This hook is called immediately before a container is terminated.
|
||||
It is blocking, meaning it is synchronous,
|
||||
so it must complete before the call to delete the container can be sent.
|
||||
No parameters are passed to the handler.
|
||||
-->
|
||||
在容器终止之前立即调用此钩子。
|
||||
它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。
|
||||
没有参数传递给处理程序。
|
||||
|
||||
<!--
|
||||
A more detailed description of the termination behavior can be found in
|
||||
[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
|
||||
-->
|
||||
有关终止行为的更详细描述，请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。
|
||||
|
||||
<!--
|
||||
### Hook handler implementations
|
||||
-->
|
||||
|
||||
### 钩子处理程序的实现
|
||||
|
||||
<!--
|
||||
Containers can access a hook by implementing and registering a handler for that hook.
|
||||
There are two types of hook handlers that can be implemented for Containers:
|
||||
-->
|
||||
容器可以通过实现和注册该钩子的处理程序来访问该钩子。
|
||||
针对容器，有两种类型的钩子处理程序可供实现：
|
||||
|
||||
<!--
|
||||
* Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container.
|
||||
Resources consumed by the command are counted against the Container.
|
||||
* HTTP - Executes an HTTP request against a specific endpoint on the Container.
|
||||
-->
|
||||
|
||||
* Exec - 执行一个特定的命令，例如 `pre-stop.sh`，在容器的 cgroups 和名称空间中。
|
||||
命令所消耗的资源根据容器进行计算。
|
||||
* HTTP - 对容器上的特定端点执行 HTTP 请求。
|
||||
|
||||
<!--
|
||||
### Hook handler execution
|
||||
-->
|
||||
|
||||
### 钩子处理程序执行
|
||||
|
||||
<!--
|
||||
When a Container lifecycle management hook is called,
|
||||
the Kubernetes management system executes the handler in the Container registered for that hook.
|
||||
-->
|
||||
当调用容器生命周期管理钩子时，Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。
|
||||
|
||||
<!--
|
||||
Hook handler calls are synchronous within the context of the Pod containing the Container.
|
||||
This means that for a `PostStart` hook,
|
||||
the Container ENTRYPOINT and hook fire asynchronously.
|
||||
However, if the hook takes too long to run or hangs,
|
||||
the Container cannot reach a `running` state.
|
||||
-->
|
||||
钩子处理程序调用在包含容器的 Pod 上下文中是同步的。
|
||||
这意味着对于 `PostStart` 钩子，容器入口点和钩子异步触发。
|
||||
但是，如果钩子运行或挂起的时间太长，则容器无法达到 `running` 状态。
|
||||
|
||||
<!--
|
||||
The behavior is similar for a `PreStop` hook.
|
||||
If the hook hangs during execution,
|
||||
the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
|
||||
If a `PostStart` or `PreStop` hook fails,
|
||||
it kills the Container.
|
||||
-->
|
||||
行为与 `PreStop` 钩子的行为类似。
|
||||
如果钩子在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
|
||||
如果 `PostStart` 或 `PreStop` 钩子失败，它会杀死容器。
|
||||
|
||||
<!--
|
||||
Users should make their hook handlers as lightweight as possible.
|
||||
There are cases, however, when long running commands make sense,
|
||||
such as when saving state prior to stopping a Container.
|
||||
-->
|
||||
用户应该使他们的钩子处理程序尽可能的轻量级。
|
||||
但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。
|
||||
|
||||
<!--
|
||||
### Hook delivery guarantees
|
||||
-->
|
||||
|
||||
### 钩子寄送保证
|
||||
|
||||
<!--
|
||||
Hook delivery is intended to be *at least once*,
|
||||
which means that a hook may be called multiple times for any given event,
|
||||
such as for `PostStart` or `PreStop`.
|
||||
It is up to the hook implementation to handle this correctly.
|
||||
-->
|
||||
钩子的寄送应该是*至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，钩子可以被调用多次。
|
||||
如何正确处理，是钩子实现所要考虑的问题。
|
||||
|
||||
<!--
|
||||
Generally, only single deliveries are made.
|
||||
If, for example, an HTTP hook receiver is down and is unable to take traffic,
|
||||
there is no attempt to resend.
|
||||
In some rare cases, however, double delivery may occur.
|
||||
For instance, if a kubelet restarts in the middle of sending a hook,
|
||||
the hook might be resent after the kubelet comes back up.
|
||||
-->
|
||||
通常情况下，只会进行单次寄送。
|
||||
例如，如果 HTTP 钩子接收器宕机，无法接收流量，则不会尝试重新发送。
|
||||
然而，偶尔也会发生重复寄送的可能。
|
||||
例如，如果 kubelet 在发送钩子的过程中重新启动，钩子可能会在 kubelet 恢复后重新发送。
|
||||
|
||||
<!--
|
||||
### Debugging Hook handlers
|
||||
-->
|
||||
|
||||
### 调试钩子处理程序
|
||||
|
||||
<!--
|
||||
The logs for a Hook handler are not exposed in Pod events.
|
||||
If a handler fails for some reason, it broadcasts an event.
|
||||
For `PostStart`, this is the `FailedPostStartHook` event,
|
||||
and for `PreStop`, this is the `FailedPreStopHook` event.
|
||||
You can see these events by running `kubectl describe pod <pod_name>`.
|
||||
Here is some example output of events from running this command:
|
||||
-->
|
||||
钩子处理程序的日志不会在 Pod 事件中公开。
|
||||
如果处理程序由于某种原因失败，它将播放一个事件。
|
||||
对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。
|
||||
您可以通过运行 `kubectl describe pod <pod_name>` 命令来查看这些事件。
|
||||
下面是运行这个命令的一些事件输出示例:
|
||||
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
|
||||
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
|
||||
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
|
||||
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
|
||||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Learn more about the [Container environment](/docs/concepts/containers/container-environment-variables/).
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
-->
|
||||
|
||||
* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。
|
||||
* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -124,13 +124,13 @@ Docker将私有仓库的密钥存放在`$HOME/.dockercfg`或`$HOME/.docker/confi
|
||||
|
||||
推荐如下步骤来为node配置私有仓库。以下示例在PC或笔记本电脑中操作
|
||||
|
||||
1.对于想要使用的每一种凭证，运行 `docker login [server]`，它会更新`$HOME/.docker/config.json`。
|
||||
1.使用编辑器查看`$HOME/.docker/config.json`，保证文件中包含了想要使用的凭证
|
||||
1.获取node列表，例如
|
||||
- 如果使用node名称，`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
|
||||
- 如果使用node IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
|
||||
1.将本地的`.docker/config.json`拷贝到每个节点root用户目录下
|
||||
- 例如： `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done`
|
||||
1. 对于想要使用的每一种凭证，运行 `docker login [server]`，它会更新`$HOME/.docker/config.json`。
|
||||
1. 使用编辑器查看`$HOME/.docker/config.json`，保证文件中包含了想要使用的凭证
|
||||
1. 获取node列表，例如
|
||||
- 如果使用node名称，`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
|
||||
- 如果使用node IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
|
||||
1. 将本地的`.docker/config.json`拷贝到每个节点root用户目录下
|
||||
- 例如： `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done`
|
||||
|
||||
创建使用私有仓库的pod来验证，例如：
|
||||
|
||||
|
||||
@@ -0,0 +1,197 @@
|
||||
---
|
||||
reviewers:
|
||||
- tallclair
|
||||
- dchen1107
|
||||
title: RuntimeClass
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
This page describes the RuntimeClass resource and runtime selection mechanism.
|
||||
-->
|
||||
本页面讨论了 RuntimeClass 资源和运行时的选择机制。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## RuntimeClass
|
||||
|
||||
<!--
|
||||
RuntimeClass is an alpha feature for selecting the container runtime configuration to use to run a
|
||||
pod's containers.
|
||||
-->
|
||||
RuntimeClass 是一个 alpha 功能，用来选择运行 pod 中容器的容器运行时配置。
|
||||
|
||||
<!--
|
||||
### Set Up
|
||||
-->
|
||||
### 设置
|
||||
|
||||
<!--
|
||||
As an early alpha feature, there are some additional setup steps that must be taken in order to use
|
||||
the RuntimeClass feature:
|
||||
-->
|
||||
作为一个处于早期状态的 alpha 特性，必须要完成以下步骤才能使用 RuntimeClass 功能：
|
||||
|
||||
<!--
|
||||
1. Enable the RuntimeClass feature gate (on apiservers & kubelets, requires version 1.12+)
|
||||
2. Install the RuntimeClass CRD
|
||||
3. Configure the CRI implementation on nodes (runtime dependent)
|
||||
4. Create the corresponding RuntimeClass resources
|
||||
-->
|
||||
1. 开启 RuntimeClass 特性门控（在 apiservers ＆ kubelets 上，需要 1.12 及以上版本）
|
||||
2. 安装 RuntimeClass CRD
|
||||
3. 在节点上配置 CRI 的实现（取决于所选的运行时）
|
||||
4. 创建相应的 RuntimeClass 资源
|
||||
|
||||
<!--
|
||||
#### 1. Enable the RuntimeClass feature gate
|
||||
-->
|
||||
#### 1. 开启 RuntimeClass 特性门控
|
||||
|
||||
<!--
|
||||
See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation
|
||||
of enabling feature gates. The RuntimeClass feature gate must be enabled on apiservers _and_ kubelets.
|
||||
-->
|
||||
参见[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)文档了解如何开启特定的特性门控。
|
||||
`RuntimeClass` 特性门控必须在 apiservers _和_ kubelets 上同时开启，才能使用。
|
||||
|
||||
<!--
|
||||
#### 2. Install the RuntimeClass CRD
|
||||
-->
|
||||
#### 2. 安装 RuntimeClass CRD
|
||||
|
||||
<!--
|
||||
The RuntimeClass [CustomResourceDefinition][/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/] (CRD) can be found in the addons directory of the
|
||||
Kubernetes git repo:
|
||||
-->
|
||||
可以在 Kubernetes git 仓库的 addons 目录中找到
|
||||
RuntimeClass [CustomResourceDefinition (CRD)](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) 的定义：
|
||||
|
||||
https://github.com/kubernetes/kubernetes/tree/release-1.12/cluster/addons/runtimeclass/runtimeclass_crd.yaml
|
||||
|
||||
<!--
|
||||
Install the CRD with `kubectl apply -f runtimeclass_crd.yaml`.
|
||||
-->
|
||||
|
||||
使用 `kubectl apply -f runtimeclass_crd.yaml` 命令安装 CRD。
|
||||
|
||||
<!--
|
||||
#### 3. Configure the CRI implementation on nodes
|
||||
-->
|
||||
#### 3. 在节点上配置 CRI 实现
|
||||
|
||||
<!--
|
||||
The configurations to select between with RuntimeClass are CRI implementation dependent. See the
|
||||
corresponding documentation for your CRI implementation for how to configure. As this is an alpha
|
||||
feature, not all CRIs support multiple RuntimeClasses yet.
|
||||
-->
|
||||
各 RuntimeClass 所支持的配置选项取决于 CRI 的实现本身。
|
||||
请参阅 CRI 实现的相应文档了解具体如何配置。
|
||||
由于这是一个 alpha 特性功能，并非所有 CRI 都支持多个 RuntimeClass。
|
||||
|
||||
<!--
|
||||
RuntimeClass currently assumes a homogeneous node configuration across the cluster
|
||||
(which means that all nodes are configured the same way with respect to container runtimes). Any heterogeneity (varying configurations) must be
|
||||
managed independently of RuntimeClass through scheduling features
|
||||
(see [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)).
|
||||
-->
|
||||
{{< note >}}
|
||||
RuntimeClass 当前假设的是集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。
|
||||
任何异构性（不同的配置）必须通过调度功能在 RuntimeClass 之外单独管理（请参阅[在节点上分配 Pods](/docs/concepts/configuration/assign-pod-node/)）。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The configurations have a corresponding `RuntimeHandler` name, referenced by the RuntimeClass. The
|
||||
RuntimeHandler must be a valid DNS-1123 subdomain (alpha-numeric characters, `-`, or `.`).
|
||||
-->
|
||||
所有这些配置都具有相应的 `RuntimeHandler` 名，并被 RuntimeClass 引用。
|
||||
RuntimeHandler 必须是有效的 DNS-1123 子域（字母数字字符、`-` 或 `.`）。
|
||||
|
||||
<!--
|
||||
#### 4. Create the corresponding RuntimeClass resources
|
||||
-->
|
||||
|
||||
#### 4. 创建相应的 RuntimeClass 资源
|
||||
|
||||
<!--
|
||||
The configurations setup in step 3 should each have an associated `RuntimeHandler` name, which
|
||||
identifies the configuration. For each RuntimeHandler (and optionally the empty `""` handler),
|
||||
create a corresponding RuntimeClass object
|
||||
.-->
|
||||
步骤 3 中的配置设置应该有相应的 `RuntimeHandler` 名，用于标识配置。
|
||||
对应每个 RuntimeHandler（以及 `""` 所代表的空处理程序），都创建相应的 RuntimeClass 对象。
|
||||
|
||||
<!--The RuntimeClass resource currently only has 2 significant fields: the RuntimeClass name
|
||||
(`metadata.name`) and the RuntimeHandler (`spec.runtimeHandler`). The object definition looks like this:
|
||||
-->
|
||||
RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名 (`metadata.name`) 和 RuntimeHandler (`spec.runtimeHandler`)。
|
||||
对象定义如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1alpha1 # 在 node.k8s.io API 中对 RuntimeClass 进行定义
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: myclass # 引用 RuntimeClass
|
||||
# RuntimeClass 是不属于任何名字空间的资源
|
||||
spec:
|
||||
runtimeHandler: myconfiguration # 给出 CRI 配置的名称
|
||||
```
|
||||
|
||||
<!--
|
||||
It is recommended that RuntimeClass write operations (create/update/patch/delete) be
|
||||
restricted to the cluster administrator. This is typically the default. See [Authorization
|
||||
Overview](/docs/reference/access-authn-authz/authorization/) for more details.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。
|
||||
通常这是默认配置。参阅[授权概述](/docs/reference/access-authn-authz/authorization/)了解更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Usage
|
||||
Once RuntimeClasses are configured for the cluster, using them is very simple. Specify a
|
||||
`runtimeClassName` in the Pod spec. For example:
|
||||
-->
|
||||
|
||||
### 使用说明
|
||||
|
||||
一旦完成集群中 RuntimeClasses 的配置，使用起来非常简便。
|
||||
在 Pod spec 中指定 `runtimeClassName` 即可。例如:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
runtimeClassName: myclass
|
||||
# ...
|
||||
```
|
||||
|
||||
<!--This will instruct the Kubelet to use the named RuntimeClass to run this pod. If the named
|
||||
RuntimeClass does not exist, or the CRI cannot run the corresponding handler, the pod will enter the
|
||||
`Failed` terminal [phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase). Look for a
|
||||
corresponding [event](/docs/tasks/debug-application-cluster/debug-application-introspection/) for an
|
||||
error message.-->
|
||||
|
||||
这一设置会告诉 Kubelet 使用所指的 RuntimeClass 来运行该 pod。
|
||||
如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，那么 pod 将会进入 `Failed` 终止[阶段](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。
|
||||
你可以查看相应的[事件](/docs/tasks/debug-application-cluster/debug-application-introspection/)，获取出错信息。
|
||||
|
||||
<!--
|
||||
If no `runtimeClassName` is specified, the default RuntimeHandler will be used, which is equivalent
|
||||
to the behavior when the RuntimeClass feature is disabled.
|
||||
-->
|
||||
如果未指定 `runtimeClassName` ，则将使用默认的 RuntimeHandler，相当于禁用 RuntimeClass 功能特性。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 扩展 Kubernetes
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Extending Kubernetes
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 扩展 Kubernetes API
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Extending the Kubernetes API
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user