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

ZH-trans: merge release1.16-temporary to master (#18217)

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

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

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

* update chinese docs (#16985)

* Fix ordered list (#16988)

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

update

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

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

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

update

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

update

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

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

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

update

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

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

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

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

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

* update format problem (#16956)

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

update

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

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

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

* fix confict update zh translation (#16863)

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

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

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

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

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

* Update RC's link (#16935)

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

Update

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

update the style

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

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

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

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

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

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

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

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

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

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

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

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

* update Unkown ->  Unknown (#17062)

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

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

* update Runnning -> Running (#17061)

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

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

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

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

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

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

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

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

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

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

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

Add Chinese translation for scheduler-perf-tuning

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

Add Chinese translation for scheduler-perf-tuning

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

Add Chinese translation for scheduler-perf-tuning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Update pod-topology-spread-constraints.md

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

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

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

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

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

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

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

* pr_release-1.16_crictl (#17201)

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

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

* translate configure_upgrade_etcd (#17160)

* translate kubeadm_upgrade_apply (#17159)

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

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

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

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

zh-trans replace the wrong translation

* Merged 1.14~1.16 changes (#17117)

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

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

* pr_release-1.16_basic-ss (#17169)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* pr_release-1.16_reconfig-kubelet (#17200)

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

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

* Update jobs-run-completion.md

* Update jobs-run-completion.md

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

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

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

kubeadm_join_phase_control-plane-prepare_download-certs.md

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

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

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

* ZH-trans: add _index.md

* add _index.md file

* add _index.md files

* pr_release-1.16_crd-versions (#17198)

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

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

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

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

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

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

* x

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

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

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

* update zh-translation document (#17096)

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

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

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

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

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

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

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

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

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

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

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

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

* Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

* Update kube-scheduler.md

* Add Chinese translation for kube-scheduler

* Update kube-scheduler.md

* Update kube-scheduler.md

* Update kube-scheduler.md

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

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

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

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

* translate kubeadm-certs.md (#17090)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Create advanced.md (#17256)

* Create advanced.md

* trans the advanced.md and fix the build bugs

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

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

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

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

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

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

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

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

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

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

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

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

* Update kubeadm_init_phase_etcd.md

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

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

* Update kubeadm_alpha_kubelet.md

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

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

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

* Update kubeadm_init_phase_etcd_local.md

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

* zh trans update-daemon-set.md

* Update update-daemon-set.md

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

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

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

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

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

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

* Update kubeadm_alpha.md

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

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

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

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

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

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

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

* Improve previously translated documents (#17327)

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

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

* Update zh.toml

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

* Update zh.toml

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

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

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

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

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

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

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

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

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

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

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

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

* Update cluster-large.md

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

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

* Update kubeadm_init_phase_certs_etcd-server.md

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

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

* update zh trans kubelet (#17379)

* update zh trans kubelet

* update the file according to feedback from reviewer tengqm

* update 1000-1757 lines

* update the advice zh trans

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

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

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

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

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

* pr_release-1.16_api-overview (#17444)

* pr_release-1.16_daemonset (#17435)

* pr_release-1.16_gc (#17445)

* pr_release-1.16_qos-class (#17442)

* fix QoS Class to QoS 类 (#17464)

* pr_release-1.16-abac (#17427)

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

* pr_release-1.16_endpoint-slice (#17468)

* pr_release-1.16_taint (#17469)

* pr_release-1.16_operator-pattern (#17467)

* pr_release-1.16_ss (#17433)

* pr_release-1.16_admission-controller (#17440)

* pr_release-1.16_containerd (#17441)

* pr_release-1.16_app-container (#17466)

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

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

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

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

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

* pr-release-1.16_logging (#17491)

* pr-release-1.16_cri (#17486)

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

* pattern translate into 模式 (#17485)

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

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

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

* pr-release-1.16_cncf (#17490)

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

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

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

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

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

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

* update deployment.md

* pr-release-1.16_extensions (#17492)

* pr-release-1.16_toleration (#17493)

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

This reverts commit 1134c14e0a39bdc3d1a920ac9797139a6dcccf4b.

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

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

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

* Update toleration.md

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

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

* Broken Link (#17546)

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

* Update trans kubeadm_upgrade_plan.md (#17395)

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

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

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

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

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

Add back the Original English

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

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

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

update table title and reference

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

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

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

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

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

* Update _index.html

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

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

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

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

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

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

update-750

*  fix-up 1575 line and udpate 2483 line

* update to line 2980

* update to the last line 3160

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

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

* zh-trs:container-runtimes.md

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

* Update container-runtimes.md

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

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

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

* Sorry, wrong commit, roll back...

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

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

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

* Create trans kubeadm_upgrade_diff.md (#17392)

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Create _index.md (#17831)

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

* Update volume-snapshots.md (#17829)

* Update volume-snapshots.md

* Update volume-snapshots.md

* Update volume-snapshots.md

* Create ovirt.md (#17849)

* Create ovirt.md

* Update ovirt.md

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

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

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

* Sorry, wrong commit, roll back...

* Update translation after tengqm's review.

* Update cloud-providers.md

* Update dual-stack.md (#17836)

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

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

* Create validate-dual-stack.md

* Update validate-dual-stack.md

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

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

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

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

* Apply suggestions from code review

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

* Fix format issue (#17921)

* Create topology-manager.md (#17901)

* Create topology-manager.md

* Update topology-manager.md

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

* Update pod-overhead.md (#17931)

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

* Create dcos.md (#17932)

* Create dcos.md

* Update dcos.md

* Update object-management.md (#17937)

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

* Create imperative-config.md (#17956)

* Create imperative-config.md

* Update imperative-config.md

* Create self-hosting.md (#17950)

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

* Create nodelocaldns.md (#17938)

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

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

* Update config.toml

* Remove ru language

* Update the conflict and merge the two commits

* add nginx-deployment.yaml file

Co-authored-by: ZhongliangXiong <xiong.zhongliang@zte.com.cn>
Co-authored-by: Yixiang Wang <wang.yixiang@zte.com.cn>
Co-authored-by: li mengyang <hwdef97@gmail.com>
Co-authored-by: PingWang <wang.ping5@zte.com.cn>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: Sophy417 <53026875+Sophy417@users.noreply.github.com>
Co-authored-by: zhangx501 <zhang0000xun@gmail.com>
Co-authored-by: Qiming <tengqim@cn.ibm.com>
Co-authored-by: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com>
Co-authored-by: senwang <wang.sen2@zte.com.cn>
Co-authored-by: lichuqiang <lichuqiang@huawei.com>
Co-authored-by: lpf7551321 <liupengfei20@huawei.com>
Co-authored-by: Hongcai Ren <renhongcai@huawei.com>
Co-authored-by: jiajie <jiaj12@chinaunicom.cn>
Co-authored-by: heqg <56527988+heqg@users.noreply.github.com>
Co-authored-by: IreneByron <zhangbingqing7@huawei.com>
Co-authored-by: Wang Bing <wangbing.adam@gmail.com>
Co-authored-by: Damini Satya <daminisatya@gmail.com>
Co-authored-by: liufangwai <liufangwai@huawei.com>
Co-authored-by: wangcong <congfairy2536@gmail.com>
Co-authored-by: XuefeiWang2 <wangxuefei2@huawei.com>
Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Co-authored-by: Ziqiu Zhu <zzqshu@126.com>
Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com>
Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-authored-by: jiazxjason <52809535+jiazxjason@users.noreply.github.com>
Co-authored-by: Coffey Gao <coffiney@qq.com>
Co-authored-by: Bingshen Wang <bingshen.wbs@alibaba-inc.com>
This commit is contained in:
LiuDui
2019-12-25 08:51:29 +08:00
committed by Kubernetes Prow Robot
parent 9135bdbe6d
commit b8b2cc7c74
933 changed files with 113346 additions and 8088 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/debug-application-cluster/_index.md
+5 -6
View File
@@ -1,12 +1,11 @@
---
title: "监控、日志和排错"
weight: 80
---
<!--
---
title: "Monitor, Log, and Debug"
weight: 80
---
-->
---
title: "监控、日志和排错"
weight: 80
---
content/zh/docs/tasks/debug-application-cluster/audit.md
+1 -1
View File
@@ -602,7 +602,7 @@ Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1beta1/types.go
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
[kubeconfig]: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
[fluentd]: http://www.fluentd.org/
[fluentd_install_doc]: https://docs.fluentd.org/v/0.12/articles/quickstart#step1-installing-fluentd
[logstash]: https://www.elastic.co/products/logstash
content/zh/docs/tasks/debug-application-cluster/crictl.md
+488
View File
@@ -0,0 +1,488 @@
---
reviewers:
- Random-Liu
- feiskyer
- mrunalp
title: 使用 crictl 对 Kubernetes 节点进行调试
content_template: templates/task
---
<!--
---
reviewers:
- Random-Liu
- feiskyer
- mrunalp
title: Debugging Kubernetes nodes with crictl
content_template: templates/task
---
-->
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
<!--
`crictl` is a command-line interface for CRI-compatible container runtimes.
You can use it to inspect and debug container runtimes and applications on a
Kubernetes node. `crictl` and its source are hosted in the
[cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository.
-->
`crictl` 是 CRI 兼容的容器运行时命令行接口。
您可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
`crictl`和它的源代码在 [cri-tools](https://github.com/kubernetes-incubator/cri-tools) 代码库。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
`crictl` requires a Linux operating system with a CRI runtime.
-->
`crictl` 需要带有 CRI 运行时的 Linux 操作系统。
{{% /capture %}}
{{% capture steps %}}
<!--
## Installing crictl
You can download a compressed archive `crictl` from the cri-tools [release
page](https://github.com/kubernetes-incubator/cri-tools/releases), for several
different architectures. Download the version that corresponds to your version
of Kubernetes. Extract it and move it to a location on your system path, such as
`/usr/local/bin/`.
-->
## 安装 crictl
您可以从 cri-tools [发布页面](https://github.com/kubernetes-incubator/cri-tools/releases)下载一个压缩的 `crictl` 归档文件，用于几种不同的架构。
下载与您的 kubernetes 版本相对应的版本。
提取它并将其移动到系统路径上的某个位置，例如`/usr/local/bin/`。
<!--
## General usage
-->
## 一般用法
<!--
The `crictl` command has several subcommands and runtime flags. Use
`crictl help` or `crictl <subcommand> help` for more details.
-->
`crictl` 命令有几个子命令和运行时参数。
有关详细信息，请使用 `crictl help` 或 `crictl <subcommand> help` 获取帮助信息。
<!--
`crictl` connects to `unix:///var/run/dockershim.sock` by default. For other
runtimes, you can set the endpoint in multiple different ways:
-->
`crictl` 默认连接到 `unix:///var/run/dockershim.sock`。
对于其他的运行时，您可以用多种不同的方法设置端点：
<!--
- By setting flags `--runtime-endpoint` and `--image-endpoint`
- By setting environment variables `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT`
- By setting the endpoint in the config file `--config=/etc/crictl.yaml`
-->
- 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint`
- 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`
- 通过在配置文件中设置端点 `--config=/etc/crictl.yaml`
<!--
You can also specify timeout values when connecting to the server and enable or
disable debugging, by specifying `timeout` or `debug` values in the configuration
file or using the `--timeout` and `--debug` command-line flags.
-->
您还可以在连接到服务器并启用或禁用调试时指定超时值，方法是在配置文件中指定 `timeout` 或 `debug` 值，或者使用 `--timeout` 和 `--debug` 命令行参数。
<!--
To view or edit the current configuration, view or edit the contents of
`/etc/crictl.yaml`.
-->
要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。
```sh
cat /etc/crictl.yaml
runtime-endpoint: unix:///var/run/dockershim.sock
image-endpoint: unix:///var/run/dockershim.sock
timeout: 10
debug: true
```
<!--
## Example crictl commands
The following examples show some `crictl` commands and example output.
-->
## crictl 命令示例
{{< warning >}}
<!--If you use `crictl` to create pod sandboxes or containers on a running
Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
general purpose workflow tool, but a tool that is useful for debugging.-->
如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器，kubelet 最终将删除它们。
`crictl`不是一个通用的工作流工具，而是一个对调试有用的工具。
{{< /warning >}}
<!--
### List pods
List all pods:
-->
### 打印 Pod 清单
打印所有 Pod 的清单：
```bash
crictl pods
```
```none
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0
4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0
a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0
919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0
```
<!--
List pods by name:
-->
根据名称打印 Pod 清单：
```bash
crictl pods --name nginx-65899c769f-wv2gp
```
```none
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0
```
<!--
List pods by label:
-->
根据标签打印 Pod 清单：
```bash
crictl pods --label run=nginx
```
```none
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0
```
<!--
### List images
List all images:
-->
### 打印镜像清单
打印所有镜像清单：
```bash
crictl images
```
```none
IMAGE TAG IMAGE ID SIZE
busybox latest 8c811b4aec35f 1.15MB
k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB
k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB
nginx latest cd5239a0906a6 109MB
```
<!--
List images by repository:
-->
根据仓库打印镜像清单：
```bash
crictl images nginx
```
```none
IMAGE TAG IMAGE ID SIZE
nginx latest cd5239a0906a6 109MB
```
<!--
Only list image IDs:
-->
只打印镜像 ID：
```bash
crictl images -q
```
```none
sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a
sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5
sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e
sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569
```
<!--
### List containers
List all containers:
-->
### 打印容器清单
打印所有容器清单：
```bash
crictl ps -a
```
```none
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1
9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0
87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0
1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0
```
<!--
List running containers:
-->
打印正在运行的容器清单：
```bash
crictl ps
```
```none
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1
87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0
1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0
```
<!--
### Execute a command in a running container
-->
### 在正在运行的容器上执行命令
```bash
crictl exec -i -t 1f73f2d81bf98 ls
```
```none
bin dev etc home proc root sys tmp usr var
```
<!--
### Get a container's logs
Get all container logs:
-->
### 获取容器日志
获取容器的所有日志：
```bash
crictl logs 87d3992f84f74
```
```none
10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
```
<!--
Get only the latest `N` lines of logs:
-->
获取最近的 `N` 行日志：
```bash
crictl logs --tail=1 87d3992f84f74
```
```none
10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
```
<!--
### Run a pod sandbox
Using `crictl` to run a pod sandbox is useful for debugging container runtimes.
On a running Kubernetes cluster, the sandbox will eventually be stopped and
deleted by the Kubelet.
-->
### 运行 Pod 沙盒
用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。
在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。
1. <!--Create a JSON file like the following:-->
编写下面的 JSON 文件：
```json
{
"metadata": {
"name": "nginx-sandbox",
"namespace": "default",
"attempt": 1,
"uid": "hdishd83djaidwnduwk28bcsb"
},
"logDirectory": "/tmp",
"linux": {
}
}
```
2. <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
```bash
crictl runp pod-config.json
```
<!--The ID of the sandbox is returned.-->
返回了沙盒的 ID。
<!--
### Create a container
Using `crictl` to create a container is useful for debugging container runtimes.
On a running Kubernetes cluster, the sandbox will eventually be stopped and
deleted by the Kubelet.
-->
### 创建容器
用 `crictl` 创建容器对容器运行时排错很有帮助。
在运行的 Kubernetes 集群中，沙盒会随机的被 kubelet 停止和删除。
1. <!--Pull a busybox image-->
拉取 busybox 镜像
```bash
crictl pull busybox
Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
```
2. <!--Create configs for the pod and the container:-->
创建 Pod 和容器的配置：
<!--**Pod config**:-->
**Pod 配置**：
```yaml
{
"metadata": {
"name": "nginx-sandbox",
"namespace": "default",
"attempt": 1,
"uid": "hdishd83djaidwnduwk28bcsb"
},
"log_directory": "/tmp",
"linux": {
}
}
```
<!--**Container config**:-->
**容器配置**：
```yaml
{
"metadata": {
"name": "busybox"
},
"image":{
"image": "busybox"
},
"command": [
"top"
],
"log_path":"busybox.log",
"linux": {
}
}
```
3. <!--Create the container, passing the ID of the previously-created pod, the
container config file, and the pod config file. The ID of the container is
returned.-->
创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
```bash
crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
```
4. <!--List all containers and verify that the newly-created container has its
state set to `Created`.-->
查询所有容器并确认新创建的容器状态为 `Created`。
```bash
crictl ps -a
```
```none
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
3e025dd50a72d busybox 32 seconds ago Created busybox 0
```
<!--
### Start a container
To start a container, pass its ID to `crictl start`:
-->
### 启动容器
要启动容器，要将容器 ID 传给 `crictl start`：
```bash
crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
```
```none
3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
```
<!--
Check the container has its state set to `Running`.
-->
确认容器的状态为 `Running`。
```bash
crictl ps
```
```none
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
3e025dd50a72d busybox About a minute ago Running busybox 0
```
{{% /capture %}}
{{% capture discussion %}}
<!--
See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)
for more information.
-->
更多信息请参考 [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
+545
View File
@@ -0,0 +1,545 @@
---
reviewers:
- janetkuo
- thockin
content_template: templates/concept
title: 应用自测与调试
---
{{% capture overview %}}
<!--
Once your application is running, you'll inevitably need to debug problems with it.
Earlier we described how you can use `kubectl get pods` to retrieve simple status information about
your pods. But there are a number of ways to get even more information about your application.
-->
运行应用时，不可避免的需要定位问题。
前面我们介绍了如何使用 `kubectl get pods` 来查询 pod 的简单信息。
除此之外，还有一系列的方法来获取应用的更详细信息。
{{% /capture %}}
{{% capture body %}}
<!--
## Using `kubectl describe pod` to fetch details about pods
-->
## 使用 `kubectl describe pod` 命令获取 pod 详情
<!--
For this example we'll use a Deployment to create two pods, similar to the earlier example.
-->
与之前的例子类似，我们使用一个 Deployment 来创建两个 pod。
{{< codenew file="application/nginx-with-request.yaml" >}}
<!--
Create deployment by running following command:
-->
使用如下命令创建 deployment：
```shell
kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
```
```none
deployment.apps/nginx-deployment created
```
<!--
Check pod status by following command:
-->
使用如下命令查看 pod 状态：
```shell
kubectl get pods
```
```none
NAME READY STATUS RESTARTS AGE
nginx-deployment-1006230814-6winp 1/1 Running 0 11s
nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s
```
<!--
We can retrieve a lot more information about each of these pods using `kubectl describe pod`. For example:
-->
我们可以使用 `kubectl describe pod` 命令来查询每个 pod 的更多信息，比如：
```shell
kubectl describe pod nginx-deployment-1006230814-6winp
```
```none
Name: nginx-deployment-1006230814-6winp
Namespace: default
Node: kubernetes-node-wul5/10.240.0.9
Start Time: Thu, 24 Mar 2016 01:39:49 +0000
Labels: app=nginx,pod-template-hash=1006230814
Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1956810328","uid":"14e607e7-8ba1-11e7-b5cb-fa16" ...
Status: Running
IP: 10.244.0.6
Controllers: ReplicaSet/nginx-deployment-1006230814
Containers:
nginx:
Container ID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
Image: nginx
Image ID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
Port: 80/TCP
QoS Tier:
cpu: Guaranteed
memory: Guaranteed
Limits:
cpu: 500m
memory: 128Mi
Requests:
memory: 128Mi
cpu: 500m
State: Running
Started: Thu, 24 Mar 2016 01:39:51 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5kdvl (ro)
Conditions:
Type Status
Initialized True
Ready True
PodScheduled True
Volumes:
default-token-4bcbi:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-4bcbi
Optional: false
QoS Class: Guaranteed
Node-Selectors: <none>
Tolerations: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
54s 54s 1 {default-scheduler } Normal Scheduled Successfully assigned nginx-deployment-1006230814-6winp to kubernetes-node-wul5
54s 54s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulling pulling image "nginx"
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulled Successfully pulled image "nginx"
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Created Created container with docker id 90315cc9f513
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Started Started container with docker id 90315cc9f513
```
<!--
Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.),
as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.).
-->
这里可以看到容器和 pod 的 label、资源需求等配置信息，还可以看到状态、就绪状态、重启次数、事件等状态信息。
<!--
The container state is one of Waiting, Running, or Terminated.
Depending on the state, additional information will be provided -- here you can see that for a container in Running state, the system tells you when the container started.
-->
容器状态包括 Waiting、Running 和 Terminated。
根据状态的不同，将提供额外的信息——在这里您可以看到，对于处于运行状态的容器，系统会告诉您容器的启动时间。
<!--
Ready tells you whether the container passed its last readiness probe.
(In this case, the container does not have a readiness probe configured; the container is assumed to be ready if no readiness probe is configured.)
-->
Ready 指示是否通过了最后一个就绪探测。
(在本例中，容器没有配置就绪探测；如果没有配置就绪探测，则假定容器已经就绪。)
<!--
Restart Count tells you how many times the container has been restarted;
this information can be useful for detecting crash loops in containers that are configured with a restart policy of 'always.'
-->
Restart Count 告诉您容器已重启的次数；
这些信息对于定位配置了“always”重启策略的容器持续崩溃问题非常有用。
<!--
Currently the only Condition associated with a Pod is the binary Ready condition,
which indicates that the pod is able to service requests and should be added to the load balancing pools of all matching services.
-->
目前，唯一与 Pod 有关的状态是就绪状态，这表明 Pod 能够为请求提供服务，并且应该添加到相应服务的负载平衡池中。
<!--
Lastly, you see a log of recent events related to your Pod.
The system compresses multiple identical events by indicating the first and last time it was seen and the number of times it was seen.
"From" indicates the component that is logging the event,
"SubobjectPath" tells you which object (e.g. container within the pod) is being referred to,
and "Reason" and "Message" tell you what happened.
-->
最后，您将看到与 Pod 相关的近期事件。
系统通过指示第一次和最后一次看到它以及看到它的次数来压缩多个相同的事件。
“From”表示记录事件的组件，
“SubobjectPath”告诉您引用了哪个对象(例如pod中的容器)，
“Reason”和“Message”告诉您发生了什么。
<!--
## Example: debugging Pending Pods
-->
## 例子: 调试 Pending Pods
<!--
A common scenario that you can detect using events is when you've created a Pod that won't fit on any node.
For example, the Pod might request more resources than are free on any node,
or it might specify a label selector that doesn't match any nodes.
Let's say we created the previous Deployment with 5 replicas (instead of 2) and requesting 600 millicores instead of 500,
on a four-node cluster where each (virtual) machine has 1 CPU.
In that case one of the Pods will not be able to schedule.
(Note that because of the cluster addon pods such as fluentd, skydns, etc., that run on each node, if we requested 1000 millicores then none of the Pods would be able to schedule.)
-->
一个常见的场景是，当你创建了一个 Pod，但是他没有被调度到任何一个 node，可以使用 event 来调试。
比如说，这个 Pod 需求的资源比较多，没有任何一个 node 能够满足，或者它指定了一个标签，没有 node 被匹配到。
假如，我们创建之前的 Deployment 时指定副本数是5（不再是2），并且需求 600 millicore（不再是 500），
对于一个4个节点的集群并且每个节点只有1个CPU。
这个情况下，至少有一个 Pod 不能被调度。
（需要注意的是，其他集群组件，比如 fluentd、skydns等等会在每个 node 上运行，
如果我们需求 1000 millicore，那么将不会有 Pod 会被调度。）
```shell
kubectl get pods
```
```none
NAME READY STATUS RESTARTS AGE
nginx-deployment-1006230814-6winp 1/1 Running 0 7m
nginx-deployment-1006230814-fmgu3 1/1 Running 0 7m
nginx-deployment-1370807587-6ekbw 1/1 Running 0 1m
nginx-deployment-1370807587-fg172 0/1 Pending 0 1m
nginx-deployment-1370807587-fz9sd 0/1 Pending 0 1m
```
<!--
To find out why the nginx-deployment-1370807587-fz9sd pod is not running, we can use `kubectl describe pod` on the pending Pod and look at its events:
-->
为了查找 Pod nginx-deployment-1370807587-fz9sd 没有运行的原因，我们可以使用 `kubectl describe pod` 命令查询处理 pending 状态的 Pod：
```shell
kubectl describe pod nginx-deployment-1370807587-fz9sd
```
```none
Name: nginx-deployment-1370807587-fz9sd
Namespace: default
Node: /
Labels: app=nginx,pod-template-hash=1370807587
Status: Pending
IP:
Controllers: ReplicaSet/nginx-deployment-1370807587
Containers:
nginx:
Image: nginx
Port: 80/TCP
QoS Tier:
memory: Guaranteed
cpu: Guaranteed
Limits:
cpu: 1
memory: 128Mi
Requests:
cpu: 1
memory: 128Mi
Environment Variables:
Volumes:
default-token-4bcbi:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-4bcbi
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 48s 7 {default-scheduler } Warning FailedScheduling pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node
fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000
fit failure on node (kubernetes-node-wul5): Node didn't have enough resource: CPU, requested: 1000, used: 1100, capacity: 2000
```
<!--
Here you can see the event generated by the scheduler saying that the Pod failed to schedule for reason `FailedScheduling` (and possibly others).
The message tells us that there were not enough resources for the Pod on any of the nodes.
-->
这里你可以看到由调度器记录的事件，它表明了 Pod 不能被调度的原因是 `FailedScheduling`（也可能是其他值）。
这个信息表明，没有任何 node 拥有足够多的资源。
<!--
To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas.
(Or you could just leave the one Pod pending, which is harmless.)
-->
要纠正这种情况，可以使用“kubectl scale”更新部署，以指定四个或更少的副本。
(或者你可以让 Pod 继续保持这个状态，这是无害的。)
<!--
Events such as the ones you saw at the end of `kubectl describe pod` are persisted in etcd and
provide high-level information on what is happening in the cluster.
To list all events you can use
-->
与您在“kubectl describe pod”结尾处看到的一样，这些事件都将保存在 etcd 中，并提供关于集群中正在发生的事情的高级信息。
如果需要列出所有事件，可使用命令：
```shell
kubectl get events
```
<!--
but you have to remember that events are namespaced.
This means that if you're interested in events for some namespaced object
(e.g. what happened with Pods in namespace `my-namespace`) you need to explicitly provide a namespace to the command:
-->
但是，需要注意的是，事件是按照 namespace 分组的。
如果你对些些 namespace 下的对象感兴趣（比如查看 namespace `my-namespace` 下的 Pod 事件）,
你需要显式的在命令行中指定 namespace：
```shell
kubectl get events --namespace=my-namespace
```
<!--
To see events from all namespaces, you can use the `--all-namespaces` argument.
-->
查看所有 namespace 的事件，可使用 `--all-namespaces` 参数：
<!--
In addition to `kubectl describe pod`, another way to get extra information about a pod (beyond what is provided by `kubectl get pod`) is
to pass the `-o yaml` output format flag to `kubectl get pod`.
This will give you, in YAML format, even more information than `kubectl describe pod`--essentially all of the information the system has about the Pod.
Here you will see things like annotations (which are key-value metadata without the label restrictions, that is used internally by Kubernetes system components),
restart policy, ports, and volumes.
-->
除了 `kubectl describe pod` 以外，另一种获取 Pod 额外信息（超越 `kubectl get pod`）的方法是给 `kubectl get pod` 增加 `-o yaml` 输出格式参数。
这将以YAML格式为您提供比“kubectl describe pod”更多的信息——实际上是系统拥有的关于pod的所有信息。
在这里，您将看到注释(没有标签限制的键值元数据，由Kubernetes系统组件在内部使用)、重启策略、端口和卷。
```shell
kubectl get pod nginx-deployment-1006230814-6winp -o yaml
```
```yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubernetes.io/created-by: |
{"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1006230814","uid":"4c84c175-f161-11e5-9a78-42010af00005","apiVersion":"extensions","resourceVersion":"133434"}}
creationTimestamp: 2016-03-24T01:39:50Z
generateName: nginx-deployment-1006230814-
labels:
app: nginx
pod-template-hash: "1006230814"
name: nginx-deployment-1006230814-6winp
namespace: default
resourceVersion: "133447"
uid: 4c879808-f161-11e5-9a78-42010af00005
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: nginx
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
cpu: 500m
memory: 128Mi
requests:
cpu: 500m
memory: 128Mi
terminationMessagePath: /dev/termination-log
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-4bcbi
readOnly: true
dnsPolicy: ClusterFirst
nodeName: kubernetes-node-wul5
restartPolicy: Always
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
volumes:
- name: default-token-4bcbi
secret:
secretName: default-token-4bcbi
status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2016-03-24T01:39:51Z
status: "True"
type: Ready
containerStatuses:
- containerID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
image: nginx
imageID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
lastState: {}
name: nginx
ready: true
restartCount: 0
state:
running:
startedAt: 2016-03-24T01:39:51Z
hostIP: 10.240.0.9
phase: Running
podIP: 10.244.0.6
startTime: 2016-03-24T01:39:49Z
```
<!--
## Example: debugging a down/unreachable node
-->
## 例子: 调试 down/unreachable node
<!--
Sometimes when debugging it can be useful to look at the status of a node
-- for example, because you've noticed strange behavior of a Pod that's running on the node,
or to find out why a Pod won't schedule onto the node.
As with Pods, you can use `kubectl describe node` and `kubectl get node -o yaml` to
retrieve detailed information about nodes.
For example, here's what you'll see if a node is down
(disconnected from the network, or kubelet dies and won't restart, etc.).
Notice the events that show the node is NotReady, and
also notice that the pods are no longer running
(they are evicted after five minutes of NotReady status).
-->
有时候，在调试时，查看节点的状态是很有用的——例如，因为您已经注意到节点上运行的 Pod 的奇怪行为，
或者想了解为什么 Pod 不会调度到节点上。
与Pods一样，您可以使用 `kubectl describe node` 和 `kubectl get node -o yaml` 来查询节点的详细信息。
例如，如果某个节点关闭(与网络断开连接，或者 kubelet 挂掉，无法重新启动，等等)，您将看到以下情况。
请注意显示节点未就绪的事件，也请注意 pod 不再运行(它们在5分钟未就绪状态后被驱逐)。
```shell
kubectl get nodes
```
```none
NAME STATUS ROLES AGE VERSION
kubernetes-node-861h NotReady <none> 1h v1.13.0
kubernetes-node-bols Ready <none> 1h v1.13.0
kubernetes-node-st6x Ready <none> 1h v1.13.0
kubernetes-node-unaj Ready <none> 1h v1.13.0
```
```shell
kubectl describe node kubernetes-node-861h
```
```none
Name: kubernetes-node-861h
Role
Labels: kubernetes.io/arch=amd64
kubernetes.io/os=linux
kubernetes.io/hostname=kubernetes-node-861h
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-detach=true
Taints: <none>
CreationTimestamp: Mon, 04 Sep 2017 17:13:23 +0800
Phase:
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
OutOfDisk Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
MemoryPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
DiskPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
Ready Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
Addresses: 10.240.115.55,104.197.0.26
Capacity:
cpu: 2
hugePages: 0
memory: 4046788Ki
pods: 110
Allocatable:
cpu: 1500m
hugePages: 0
memory: 1479263Ki
pods: 110
System Info:
Machine ID: 8e025a21a4254e11b028584d9d8b12c4
System UUID: 349075D1-D169-4F25-9F2A-E886850C47E3
Boot ID: 5cd18b37-c5bd-4658-94e0-e436d3f110e0
Kernel Version: 4.4.0-31-generic
OS Image: Debian GNU/Linux 8 (jessie)
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://1.12.5
Kubelet Version: v1.6.9+a3d1dfa6f4335
Kube-Proxy Version: v1.6.9+a3d1dfa6f4335
ExternalID: 15233045891481496305
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
......
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%)
Events: <none>
```
```shell
kubectl get node kubernetes-node-861h -o yaml
```
```yaml
apiVersion: v1
kind: Node
metadata:
creationTimestamp: 2015-07-10T21:32:29Z
labels:
kubernetes.io/hostname: kubernetes-node-861h
name: kubernetes-node-861h
resourceVersion: "757"
selfLink: /api/v1/nodes/kubernetes-node-861h
uid: 2a69374e-274b-11e5-a234-42010af0d969
spec:
externalID: "15233045891481496305"
podCIDR: 10.244.0.0/24
providerID: gce://striped-torus-760/us-central1-b/kubernetes-node-861h
status:
addresses:
- address: 10.240.115.55
type: InternalIP
- address: 104.197.0.26
type: ExternalIP
capacity:
cpu: "1"
memory: 3800808Ki
pods: "100"
conditions:
- lastHeartbeatTime: 2015-07-10T21:34:32Z
lastTransitionTime: 2015-07-10T21:35:15Z
reason: Kubelet stopped posting node status.
status: Unknown
type: Ready
nodeInfo:
bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897
containerRuntimeVersion: docker://Unknown
kernelVersion: 3.16.0-0.bpo.4-amd64
kubeProxyVersion: v0.21.1-185-gffc5a86098dc01
kubeletVersion: v0.21.1-185-gffc5a86098dc01
machineID: ""
osImage: Debian GNU/Linux 7 (wheezy)
systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
```
{{% /capture %}}
{{% capture whatsnext %}}
<!--
Learn about additional debugging tools, including:
-->
了解更多的调试工具：
<!--
* [Logging](/docs/concepts/cluster-administration/logging/)
* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/)
* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/)
-->
* [日志](/docs/concepts/cluster-administration/logging/)
* [监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [使用 `exec` 进入容器](/docs/tasks/debug-application-cluster/get-shell-running-container/)
* [使用代理连接容器](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
* [使用端口转发连接容器](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [使用 crictl 检查节点](/docs/tasks/debug-application-cluster/crictl/)
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
+224
View File
@@ -0,0 +1,224 @@
---
reviewers:
- bprashanth
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
- smarterclayton
title: 调试 Init 容器
content_template: templates/task
---
<!--
---
reviewers:
- bprashanth
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
- smarterclayton
title: Debug Init Containers
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to investigate problems related to the execution of
Init Containers. The example command lines below refer to the Pod as
`<pod-name>` and the Init Containers as `<init-container-1>` and
`<init-container-2>`.
-->
此页显示如何核查与 init 容器执行相关的问题。
下面的示例命令行将 Pod 称为 `<pod-name>`，而 init 容器称为 `<init-container-1>` 和 `<init-container-2>`。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
* You should be familiar with the basics of
[Init Containers](/docs/concepts/abstractions/init-containers/).
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
-->
* 您应该熟悉 [Init 容器](/docs/concepts/abstractions/init-containers/)的基础知识。
* 您应该已经[配置好一个 Init 容器](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
{{% /capture %}}
{{% capture steps %}}
<!--
## Checking the status of Init Containers
Display the status of your pod:
-->
## 检查 Init 容器的状态
显示你的 Pod 的状态：
```shell
kubectl get pod <pod-name>
```
<!--
For example, a status of `Init:1/2` indicates that one of two Init Containers
has completed successfully:
-->
例如，状态 `Init:1/2` 表明两个 Init 容器中的一个已经成功完成：
```
NAME READY STATUS RESTARTS AGE
<pod-name> 0/1 Init:1/2 0 7s
```
<!--
See [Understanding Pod status](#understanding-pod-status) for more examples of
status values and their meanings.
-->
更多状态值及其含义请参考[了解 Pod 的状态](#understanding-pod-status)。
<!--
## Getting details about Init Containers
-->
## 获取 Init 容器详情
<!--
View more detailed information about Init Container execution:
-->
查看 Init 容器运行的更多详情：
```shell
kubectl describe pod <pod-name>
```
<!--
For example, a Pod with two Init Containers might show the following:
-->
例如，对于包含两个 Init 容器的 Pod 应该显示如下信息：
```
Init Containers:
<init-container-1>:
Container ID: ...
...
State: Terminated
Reason: Completed
Exit Code: 0
Started: ...
Finished: ...
Ready: True
Restart Count: 0
...
<init-container-2>:
Container ID: ...
...
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: ...
Finished: ...
Ready: False
Restart Count: 3
...
```
<!--
You can also access the Init Container statuses programmatically by reading the
`status.initContainerStatuses` field on the Pod Spec:
-->
您还可以通过读取 Pod Spec 上的 `status.initContainerStatuses` 字段以编程方式了解 Init 容器的状态：
```shell
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
```
<!--
This command will return the same information as above in raw JSON.
-->
此命令将返回与原始 JSON 中相同的信息.
<!--
## Accessing logs from Init Containers
-->
## 通过 Init 容器访问日志
<!--
Pass the Init Container name along with the Pod name
to access its logs.
-->
一起传递 Init 容器名称与 Pod 名称来访问它的日志。
```shell
kubectl logs <pod-name> -c <init-container-2>
```
<!--
Init Containers that run a shell script print
commands as they're executed. For example, you can do this in Bash by running
`set -x` at the beginning of the script.
-->
运行 shell 脚本打印命令的init容器,执行 shell 脚本。
例如，您可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。
{{% /capture %}}
{{% capture discussion %}}
<!--
## Understanding Pod status
-->
## 了解 Pod 的状态
<!--
A Pod status beginning with `Init:` summarizes the status of Init Container
execution. The table below describes some example status values that you might
see while debugging Init Containers.
-->
以 `Init:` 开头的 Pod 状态汇总了 Init 容器执行的状态。
下表介绍调试 Init 容器时可能看到的一些状态值示例。
<!--
Status | Meaning
------ | -------
`Init:N/M` | The Pod has `M` Init Containers, and `N` have completed so far.
`Init:Error` | An Init Container has failed to execute.
`Init:CrashLoopBackOff` | An Init Container has failed repeatedly.
`Pending` | The Pod has not yet begun executing Init Containers.
`PodInitializing` or `Running` | The Pod has already finished executing Init Containers.
-->
状态 | 含义
------ | -------
`Init:N/M` | Pod 包含 `M` 个 Init 容器，其中 `N` 个已经运行完成。
`Init:Error` | Init 容器已执行失败。
`Init:CrashLoopBackOff` | Init 容器反复执行失败。
`Pending` | Pod 还没有开始执行 Init 容器。
`PodInitializing` or `Running` | Pod 已经完成执行 Init 容器。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+199 -35
View File
@@ -1,61 +1,194 @@
---
title: 调试Pods和Replication Controllers
reviewers:
- bprashanth
title: 调试 Pods 和 Replication Controllers
content_template: templates/task
---
<!--
---
reviewers:
- bprashanth
title: Debug Pods and ReplicationControllers
content_template: templates/task
---
-->
{{< toc >}}
{{% capture overview %}}
## 调试Pods
<!--
This page shows how to debug Pods and ReplicationControllers.
-->
此页面告诉您如何调试 Pod 和 ReplicationController。
调试一个pod的第一步是观察它。使用下面的命令检查这个pod的当前状态和最近事件：
{{% /capture %}}
$ kubectl describe pods ${POD_NAME}
{{% capture prerequisites %}}
看看pod中的容器的状态。他们都是`Running`吗？有最近重启了吗？
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
根据pod的状态继续调试。
<!--
* You should be familiar with the basics of
[Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
-->
* 您应该先熟悉
[Pods](/docs/concepts/workloads/pods/pod/) 和 [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。
### 我的Pod保持Pending
{{% /capture %}}
如果一个pod被卡在`Pending`中，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足
阻止调度。 看看上面的命令`kubectl describe ...`的输出。调度器的消息中应该会包含无法调度Pod的原因。
理由包括：
{{% capture steps %}}
<!--
## Debugging Pods
-->
## 调试 Pod
<!--
The first step in debugging a pod is taking a look at it. Check the current
state of the pod and recent events with the following command:
-->
调试一个 pod 的第一步是观察它。使用下面的命令检查这个 pod 的当前状态和最近事件：
```shell
kubectl describe pods ${POD_NAME}
```
<!--
Look at the state of the containers in the pod. Are they all `Running`? Have
there been recent restarts?
Continue debugging depending on the state of the pods.
-->
看看 pod 中的容器的状态。他们都是 `Running` 吗？有最近重启了吗？
根据 pod 的状态继续调试。
<!--
### My pod stays pending
-->
### 我的 Pod 卡在 Pending
<!--
If a pod is stuck in `Pending` it means that it can not be scheduled onto a
node. Generally this is because there are insufficient resources of one type or
another that prevent scheduling. Look at the output of the `kubectl describe
...` command above. There should be messages from the scheduler about why it
can not schedule your pod. Reasons include:
-->
如果一个 pod 被卡在 `Pending` 状态，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足而
阻止调度。 看看上面的命令 `kubectl describe ...` 的输出。调度器的消息中应该会包含无法调度 Pod 的原因。
原因包括：
<!--
#### Insufficient resources
-->
#### 资源不足
您可能已经耗尽了集群中供应的CPU或内存。在这个情况下你可以尝试几件事情：
<!--
You may have exhausted the supply of CPU or Memory in your cluster. In this
case you can try several things:
* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
to make room for pending pods.
* Check that the pod is not larger than your nodes. For example, if all
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 with the `kubectl get nodes -o <format>`
command. Here are some example command lines that extract just the necessary
information:
-->
您可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情：
* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
* [终止不需要的pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
为pending中的pods提供空间。
* [终止不需要的 pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
为 pending 中的 pod 提供空间。
* 检查该pod是否不大于您的节点。例如，如果全部节点具有`cpu:1`容量，那么具有`cpu: 1.1`请求的pod永远不会被调度。
* 检查该 pod 是否不大于您的节点。例如，如果全部节点具有 `cpu:1` 容量，那么具有 `cpu: 1.1` 请求的 pod 永远不会被调度。
您可以使用`kubectl get nodes -o <format>`命令来检查节点容量。
您可以使用 `kubectl get nodes -o <format>` 命令来检查节点容量。
下面是一些能够提取必要信息的命令示例：
kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
```shell
kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
```
可以考虑配置[资源配额](/docs/concepts/policy/resource-quotas/)来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
<!--
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.
-->
可以考虑配置 [资源配额](/docs/concepts/policy/resource-quotas/) 来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
<!--
#### Using hostPort
-->
#### 使用hostPort
当你将一个pod绑定到一个`hostPort`时，这个pod能被调度的位置数量有限。
在大多数情况下，`hostPort`是不必要的; 尝试使用服务对象来暴露您的pod。
如果你需要`hostPort`，那么你可以调度的Pod数量不能超过集群的节点个数。
<!--
When you bind a pod to a `hostPort` there are a limited number of places that
the pod can be scheduled. In most cases, `hostPort` is unnecessary; try using a
service object to expose your pod. If you do require `hostPort` then you can
only schedule as many pods as there are nodes in your container cluster.
-->
当你将一个 pod 绑定到一个 `hostPort` 时，这个 pod 能被调度的位置数量有限。
在大多数情况下，`hostPort` 是不必要的; 尝试使用服务对象来暴露您的 pod。
如果你需要 `hostPort`，那么你可以调度的 Pod 数量不能超过集群的节点个数。
### 我的Pod一直在Waiting
<!--
### My pod stays waiting
-->
### 我的 Pod 一直在 Waiting
如果一个pod被卡在`Waiting`状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
再次，来自`kubectl describe ...`的内容应该是可以提供信息的。
最常见的原因`Waiting`的pod是无法拉取镜像。有三件事要检查：
<!--
If a pod is stuck in the `Waiting` state, then it has been scheduled to a
worker node, but it can't run on that machine. Again, the information from
`kubectl describe ...` should be informative. The most common cause of
`Waiting` pods is a failure to pull the image. There are three things to check:
* Make sure that you have the name of the image correct.
* Have you pushed the image to the repository?
* Run a manual `docker pull <image>` on your machine to see if the image can be
pulled.
-->
如果一个 pod 被卡在 `Waiting` 状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
再次，来自 `kubectl describe ...` 的内容应该是可以提供信息的。
最常见的原因 `Waiting` 的 pod 是无法拉取镜像。有三件事要检查：
* 确保您的镜像的名称正确。
* 您是否将镜像推送到存储库？
* 在您的机器上手动运行`docker pull <image>`，看看是否可以拉取镜像。
* 在您的机器上手动运行 `docker pull <image>`，看看是否可以拉取镜像。
### 我的Pod一直Crashing或者有别的不健康状态
<!--
### My pod is crashing or otherwise unhealthy
First, take a look at the logs of the current container:
```shell
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
```
If your container has previously crashed, you can access the previous
container's crash log with:
```shell
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
```
Alternately, you can run commands inside that container with `exec`:
```shell
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
```
-->
### 我的 Pod 一直 Crashing 或者有别的不健康状态
首先，查看当前容器的日志：
@@ -65,22 +198,53 @@ title: 调试Pods和Replication Controllers
$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
或者，您可以使用`exec`在该容器内运行命令：
或者，您可以使用 `exec` 在该容器内运行命令：
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
请注意，`-c ${CONTAINER_NAME}`是可选的，对于pod只包含一个容器可以省略。
<!--
{{< note >}}
`-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
only contain a single container.
{{< /note >}}
-->
{{< note >}}
`-c ${CONTAINER_NAME}` 是可选的，对于只包含一个容器的 pod 可以省略。
{{< /note >}}
<!--
As an example, to look at the logs from a running Cassandra pod, you might run:
-->
例如，要查看正在运行的Cassandra pod的日志，可以运行：
$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
```shell
kubectl exec cassandra -- cat /var/log/cassandra/system.log
```
如果这些方法都不起作用，您可以找到该运行pod所在的主机并SSH到该主机。
<!--
If none of these approaches work, you can find the host machine that the pod is
running on and SSH into that host.
-->
如果这些方法都不起作用，您可以找到该运行 pod 所在的主机并 SSH 到该主机。
## 调试Replication Controllers
<!--
## Debugging ReplicationControllers
-->
## 调试 Replication Controller
Replication Controllers相当简单。他们能或不能创建pod。如果他们无法创建pod，那么请参考
[上面的说明](#debugging_pods)来调试你的pod。
<!--
ReplicationControllers are fairly straightforward. They can either create pods
or they can't. If they can't create pods, then please refer to the
[instructions above](#debugging-pods) to debug your pods.
-->
Replication Controller 相当简单。他们只会能或不能创建 pod。如果他们无法创建 pod，那么请参考
[上面的说明](#debugging_pods) 来调试你的pod。
<!--
You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events
related to the replication controller.
-->
您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/debug-service.md
+1180
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+172
View File
@@ -0,0 +1,172 @@
---
title: 确定 Pod 失败的原因
content_template: templates/task
---
<!--
---
title: Determine the Reason for Pod Failure
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to write and read a Container
termination message.
-->
本文介绍如何编写和读取容器的终止消息。
<!--
Termination messages provide a way for containers to write information about
fatal events to a location where it can be easily retrieved and surfaced by
tools like dashboards and monitoring software. In most cases, information that
you put in a termination message should also be written to the general
[Kubernetes logs](/docs/concepts/cluster-administration/logging/).
-->
终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
在大多数情况下，您放入终止消息中的信息也应该写入[常规 Kubernetes 日志](/docs/concepts/cluster-administration/logging/)。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!--
## Writing and reading a termination message
In this exercise, you create a Pod that runs one container.
The configuration file specifies a command that runs when
the container starts.
-->
## 读写终止消息
在本练习中，您将创建运行一个容器的 Pod。
配置文件指定在容器启动时要运行的命令。
{{< codenew file="debug/termination.yaml" >}}
1. <!--Create a Pod based on the YAML configuration file:-->基于 YAML 配置文件创建 Pod：
kubectl create -f https://k8s.io/examples/debug/termination.yaml
<!--In the YAML file, in the `cmd` and `args` fields, you can see that the
container sleeps for 10 seconds and then writes "Sleep expired" to
the `/dev/termination-log` file. After the container writes
the "Sleep expired" message, it terminates.-->
YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired" 写入 `/dev/termination-log` 文件。
容器写完 "Sleep expired" 消息后，它就终止了。
1. <!--Display information about the Pod:-->显示 Pod 的信息：
kubectl get pod termination-demo
<!--Repeat the preceding command until the Pod is no longer running.-->
重复前面的命令直到 Pod 不再运行。
1. <!--Display detailed information about the Pod:-->显示 Pod 的详细信息：
kubectl get pod --output=yaml
<!--The output includes the "Sleep expired" message:-->输出结果包含 "Sleep expired" 消息：
apiVersion: v1
kind: Pod
...
lastState:
terminated:
containerID: ...
exitCode: 0
finishedAt: ...
message: |
Sleep expired
...
1. <!--Use a Go template to filter the output so that it includes only the termination message:-->使用 Go 模板过滤输出结果，使其只含有终止消息：
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
<!--
## Customizing the termination message
-->
## 定制终止消息
<!--
Kubernetes retrieves termination messages from the termination message file
specified in the `terminationMessagePath` field of a Container, which as a default
value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
to use a different file. Kubernetes use the contents from the specified file to
populate the Container's status message on both success and failure.
-->
Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息，默认值为 `/dev/termination-log`。
通过定制这个字段，您可以告诉 Kubernetes 使用不同的文件。
Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状态消息。
<!--
In the following example, the container writes termination messages to
`/tmp/my-log` for Kubernetes to retrieve:
-->
在下例中，容器将终止消息写入 `/tmp/my-log` 给 Kubernetes 来接收：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: msg-path-demo
spec:
containers:
- name: msg-path-demo-container
image: debian
terminationMessagePath: "/tmp/my-log"
```
<!--
Moreover, users can set the `terminationMessagePolicy` field of a Container for
further customization. This field defaults to "`File`" which means the termination
messages are retrieved only from the termination message file. By setting the
`terminationMessagePolicy` to "`FallbackToLogsOnError`", you can tell Kubernetes
to use the last chunk of container log output if the termination message file
is empty and the container exited with an error. The log output is limited to
2048 bytes or 80 lines, whichever is smaller.
-->
此外，用户可以设置容器的 `terminationMessagePolicy` 字段，以便进一步自定义。
此字段默认为 "`File`"，这意味着仅从终止消息文件中检索终止消息。
通过将 `terminationMessagePolicy` 设置为 "`FallbackToLogsOnError`"，你就可以告诉 Kubernetes，在容器因错误退出时，如果终止消息文件为空，则使用容器日志输出的最后一块作为终止消息。
日志输出限制为 2048 字节或 80 行，以较小者为准。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* See the `terminationMessagePath` field in
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
* Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/).
* Learn about [Go templates](https://golang.org/pkg/text/template/).
-->
* 参考[容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)的 `terminationMessagePath` 字段。
* 了解[接收日志](/docs/concepts/cluster-administration/logging/)。
* 了解 [Go 模版](https://golang.org/pkg/text/template/)。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md
+167
View File
@@ -0,0 +1,167 @@
---
reviewers:
- piosz
- x13n
content_template: templates/concept
title: StackDriver 中的事件
---
<!--
---
reviewers:
- piosz
- x13n
content_template: templates/concept
title: Events in Stackdriver
---
-->
{{% capture overview %}}
<!--
Kubernetes events are objects that provide insight into what is happening
inside a cluster, such as what decisions were made by scheduler or why some
pods were evicted from the node. You can read more about using events
for debugging your application in the [Application Introspection and Debugging
](/docs/tasks/debug-application-cluster/debug-application-introspection/)
section.
-->
Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
您可以在[应用程序自检和调试](/docs/tasks/debug-application-cluster/debug-application-introspection/)中阅读有关使用事件调试应用程序的更多信息。
<!--
Since events are API objects, they are stored in the apiserver on master. To
avoid filling up master's disk, a retention policy is enforced: events are
removed one hour after the last occurrence. To provide longer history
and aggregation capabilities, a third party solution should be installed
to capture events.
-->
由于事件是 API 对象，因此它们存储在主节点上的 apiserver 中。
为了避免主节点磁盘空间被填满，将强制执行保留策略：在最后一次事件发生一小时后删除事件。
为了提供更长的历史记录和聚合能力，应该安装第三方解决方案来捕获事件。
<!--
This article describes a solution that exports Kubernetes events to
Stackdriver Logging, where they can be processed and analyzed.
-->
本文描述了一个将 Kubernetes 事件导出为 Stackdriver Logging 的解决方案，在这里可以对它们进行处理和分析。
{{< note >}}
<!--
It is not guaranteed that all events happening in a cluster will be
exported to Stackdriver. One possible scenario when events will not be
exported is when event exporter is not running (e.g. during restart or
upgrade). In most cases it's fine to use events for purposes like setting up
[metrics][sdLogMetrics] and [alerts][sdAlerts], but you should be aware
of the potential inaccuracy.
-->
不能保证集群中发生的所有事件都将导出到 Stackdriver。
事件不能导出的一种可能情况是事件导出器没有运行（例如，在重新启动或升级期间）。
在大多数情况下，可以将事件用于设置 [metrics][sdLogMetrics] 和 [alerts][sdAlerts] 等目的，但您应该注意潜在的不准确性。
{{< /note >}}
[sdLogMetrics]: https://cloud.google.com/logging/docs/view/logs_based_metrics
[sdAlerts]: https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy
{{% /capture %}}
{{% capture body %}}
<!--
## Deployment
-->
## 部署
### Google Kubernetes Engine
<!--
In Google Kubernetes Engine, if cloud logging is enabled, event exporter
is deployed by default to the clusters with master running version 1.7 and
higher. To prevent disturbing your workloads, event exporter does not have
resources set and is in the best effort QOS class, which means that it will
be the first to be killed in the case of resource starvation. If you want
your events to be exported, make sure you have enough resources to facilitate
the event exporter pod. This may vary depending on the workload, but on
average, approximately 100Mb RAM and 100m CPU is needed.
-->
在 Google Kubernetes Engine 中，如果启用了云日志，那么事件导出器默认部署在主节点运行版本为 1.7 及更高版本的集群中。
为了防止干扰您的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
如果要导出事件，请确保有足够的资源给事件导出器 Pod 使用。
这可能会因为工作负载的不同而有所不同，但平均而言，需要大约 100MB 的内存和 100m 的 CPU。
<!--
### Deploying to the Existing Cluster
-->
### 部署到现有集群
<!--
Deploy event exporter to your cluster using the following command:
-->
使用下面的命令将事件导出器部署到您的集群：
```shell
kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml
```
<!--
Since event exporter accesses the Kubernetes API, it requires permissions to
do so. The following deployment is configured to work with RBAC
authorization. It sets up a service account and a cluster role binding
to allow event exporter to read events. To make sure that event exporter
pod will not be evicted from the node, you can additionally set up resource
requests. As mentioned earlier, 100Mb RAM and 100m CPU should be enough.
-->
由于事件导出器访问 Kubernetes API，因此它需要权限才能访问。
以下的部署配置为使用 RBAC 授权。
它设置服务帐户和集群角色绑定，以允许事件导出器读取事件。
为了确保事件导出器 Pod 不会从节点中退出，您可以另外设置资源请求。
如前所述，100MB 内存和 100m CPU 应该就足够了。
{{< codenew file="debug/event-exporter.yaml" >}}
<!--
## User Guide
-->
## 用户指南
<!--
Events are exported to the `GKE Cluster` resource in Stackdriver Logging.
You can find them by selecting an appropriate option from a drop-down menu
of available resources:
-->
事件在 Stackdriver Logging 中被导出到 `GKE Cluster` 资源。
您可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Events location in the Stackdriver Logging interface" width="500">
<!--
You can filter based on the event object fields using Stackdriver Logging
[filtering mechanism](https://cloud.google.com/logging/docs/view/advanced_filters).
For example, the following query will show events from the scheduler
about pods from deployment `nginx-deployment`:
-->
您可以使用 Stackdriver Logging 的[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)基于事件对象字段进行过滤。
例如，下面的查询将显示调度程序中有关 Deployment `nginx-deployment` 中的 Pod 的事件：
```
resource.type="gke_cluster"
jsonPayload.kind="Event"
jsonPayload.source.component="default-scheduler"
jsonPayload.involvedObject.name:"nginx-deployment"
```
{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md
+241
View File
@@ -0,0 +1,241 @@
---
reviewers:
- caesarxuchao
- mikedanese
title: 获取正在运行容器的 Shell
content_template: templates/task
---
<!--
---
reviewers:
- caesarxuchao
- mikedanese
title: Get a Shell to a Running Container
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to use `kubectl exec` to get a shell to a
running Container.
-->
本文介绍怎样使用 `kubectl exec` 命令获取正在运行容器的 Shell。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!--
## Getting a shell to a Container
-->
## 获取容器的 Shell
<!--
In this exercise, you create a Pod that has one Container. The Container
runs the nginx image. Here is the configuration file for the Pod:
-->
在本练习中，你将创建包含一个容器的 Pod。容器运行 nginx 镜像。下面是 Pod 的配置文件：
{{< codenew file="application/shell-demo.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
```
<!--
Verify that the Container is running:
-->
检查容器是否运行正常：
```shell
kubectl get pod shell-demo
```
<!--
Get a shell to the running Container:
-->
获取正在运行容器的 Shell：
```shell
kubectl exec -it shell-demo -- /bin/bash
```
{{< note >}}
<!--
The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments.
-->
双破折号 "--" 用于将要传递给命令的参数与 kubectl 的参数分开。
note >}}
<!--
In your shell, list the root directory:
-->
在 shell 中，打印根目录：
```shell
root@shell-demo:/# ls /
```
<!--
In your shell, experiment with other commands. Here are
some examples:
-->
在 shell 中，实验其他命令。下面是一些示例：
```shell
root@shell-demo:/# ls /
root@shell-demo:/# cat /proc/mounts
root@shell-demo:/# cat /proc/1/maps
root@shell-demo:/# apt-get update
root@shell-demo:/# apt-get install -y tcpdump
root@shell-demo:/# tcpdump
root@shell-demo:/# apt-get install -y lsof
root@shell-demo:/# lsof
root@shell-demo:/# apt-get install -y procps
root@shell-demo:/# ps aux
root@shell-demo:/# ps aux | grep nginx
```
<!--
## Writing the root page for nginx
-->
## 编写 nginx 的 根页面
<!--
Look again at the configuration file for your Pod. The Pod
has an `emptyDir` volume, and the Container mounts the volume
at `/usr/share/nginx/html`.
-->
在看一下 Pod 的配置文件。该 Pod 有个 `emptyDir` 卷，容器将该卷挂载到了 `/usr/share/nginx/html`。
<!--
In your shell, create an `index.html` file in the `/usr/share/nginx/html`
directory:
-->
在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html 文件：
```shell
root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
```
<!--
In your shell, send a GET request to the nginx server:
-->
在 shell 中，向 nginx 服务器发送 GET 请求：
```shell
root@shell-demo:/# apt-get update
root@shell-demo:/# apt-get install curl
root@shell-demo:/# curl localhost
```
<!--
The output shows the text that you wrote to the `index.html` file:
-->
输出结果显示了你在 `index.html` 中写入的文本。
```shell
Hello shell demo
```
<!--
When you are finished with your shell, enter `exit`.
-->
当用完 shell 后，输入 `exit` 退出。
<!--
## Running individual commands in a Container
-->
## 在容器中运行单个命令
<!--
In an ordinary command window, not your shell, list the environment
variables in the running Container:
-->
在普通的命令窗口（而不是 shell）中，打印环境运行容器中的变量：
```shell
kubectl exec shell-demo env
```
<!--
Experiment running other commands. Here are some examples:
-->
实验运行其他命令。下面是一些示例：
```shell
kubectl exec shell-demo ps aux
kubectl exec shell-demo ls /
kubectl exec shell-demo cat /proc/1/mounts
```
{{% /capture %}}
{{% capture discussion %}}
<!--
## Opening a shell when a Pod has more than one Container
-->
## 当 Pod 包含多个容器时打开 shell
<!--
If a Pod has more than one Container, use `--container` or `-c` to
specify a Container in the `kubectl exec` command. For example,
suppose you have a Pod named my-pod, and the Pod has two containers
named main-app and helper-app. The following command would open a
shell to the main-app Container.
-->
如果 Pod 有多个容器，`--container` 或者 `-c` 可以在 `kubectl exec` 命令中指定容器。
例如，您有个名为 my-pod 的容器，该 Pod 有两个容器分别为 main-app 和 healper-app。
下面的命令将会打开一个 shell 访问 main-app 容器。
```shell
kubectl exec -it my-pod --container main-app -- /bin/bash
```
{{% /capture %}}
{{% capture whatsnext %}}
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/local-debugging.md
+126
View File
@@ -0,0 +1,126 @@
---
title: 在本地开发和调试服务
content_template: templates/task
---
<!--
---
title: Developing and debugging services locally
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell.
-->
Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，需要[在运行的容器上打开 shell](/docs/tasks/debug-application-cluster/get-shell-running-container/)，然后在远端 shell 中运行您所需的工具。
<!--
`telepresence` is a tool to ease the process of developing and debugging services locally, while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster.
-->
`telepresence` 是一种工具，用于在本地轻松开发和调试服务，同时将服务代理到远程 Kubernetes 集群。
使用 `telepresence` 可以为本地服务使用自定义工具（如调试器和 IDE），并提供对 Configmap、Secrets 和远程集群上运行的服务的完全访问。
<!--
This document describes using `telepresence` to develop and debug services running on a remote cluster locally.
--
本文档描述如何在本地使用 `telepresence` 开发和调试远程集群上运行的服务。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
* Kubernetes cluster is installed
* `kubectl` is configured to communicate with the cluster
* [Telepresence](https://www.telepresence.io/reference/install) is installed
-->
* Kubernetes 集群安装完毕
* 配置好 `kubectl` 与集群交互
* [Telepresence](https://www.telepresence.io/reference/install) 安装完毕
{{% /capture %}}
{{% capture steps %}}
<!--
## Getting a shell on a remote cluster
Open a terminal and run `telepresence` with no arguments to get a `telepresence` shell. This shell runs locally, giving you full access to your local filesystem.
-->
打开终端，不带参数运行 `telepresence`，以打开 `telepresence` shell。这个 shell 在本地运行，使您可以完全访问本地文件系统。
<!--
The `telepresence` shell can be used in a variety of ways. For example, write a shell script on your laptop, and run it directly from the shell in real time. You can do this on a remote shell as well, but you might not be able to use your preferred code editor, and the script is deleted when the container is terminated.
Enter `exit` to quit and close the shell.
-->
`telepresence` shell 的使用方式多种多样。
例如，在你的笔记本电脑上写一个 shell 脚本，然后直接在 shell 中实时运行它。
您也可以在远端 shell 上执行此操作，但这样可能无法使用首选的代码编辑器，并且在容器终止时脚本将被删除。
<!--
## Developing or debugging an existing service
When developing an application on Kubernetes, you typically program or debug a single service. The service might require access to other services for testing and debugging. One option is to use the continuous deployment pipeline, but even the fastest deployment pipeline introduces a delay in the program or debug cycle.
-->
## 开发和调试现有的服务
在 Kubernetes 上开发应用程序时，通常对单个服务进行编程或调试。
服务可能需要访问其他服务以进行测试和调试。
一种选择是使用连续部署管道，但即使最快的部署管道也会在程序或调试周期中引入延迟。
<!--
Use the `--swap-deployment` option to swap an existing deployment with the Telepresence proxy. Swapping allows you to run a service locally and connect to the remote Kubernetes cluster. The services in the remote cluster can now access the locally running instance.
To run telepresence with `--swap-deployment`, enter:
-->
使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。交换允许您在本地运行服务并能够连接到远端的 Kubernetes 集群。远端的集群中的服务现在就可以访问本地运行的实例。
到运行 telepresence 并带有 `--swap-deployment` 选项，请输入：
`telepresence --swap-deployment $DEPLOYMENT_NAME`
<!--
where $DEPLOYMENT_NAME is the name of your existing deployment.
Running this command spawns a shell. In the shell, start your service. You can then make edits to the source code locally, save, and see the changes take effect immediately. You can also run your service in a debugger, or any other local development tool.
-->
这里的 $DEPLOYMENT_NAME 是您现有的部署名称。
运行此命令将生成 shell。在 shell 中，启动您的服务。
然后，您就可以在本地对源代码进行编辑、保存并能看到更改立即生效。您还可以在调试器或任何其他本地开发工具中运行服务。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine.
-->
如果您对实践教程感兴趣，请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s)，其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。
<!--
Telepresence has [numerous proxying options](https://www.telepresence.io/reference/methods), depending on your situation.
For further reading, visit the [Telepresence website](https://www.telepresence.io).
-->
Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods)，以满足您的各种情况。
要了解更多信息，请访问 [Telepresence 网站](https://www.telepresence.io)。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+193
View File
@@ -0,0 +1,193 @@
---
reviewers:
- piosz
- x13n
content_template: templates/concept
title: 使用 ElasticSearch 和 Kibana 进行日志管理
---
<!--
---
reviewers:
- piosz
- x13n
content_template: templates/concept
title: Logging Using Elasticsearch and Kibana
---
-->
{{% capture overview %}}
<!--
On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
-->
在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是 [Stackdriver Logging](https://cloud.google.com/logging/)，在 [使用 Stackdriver Logging 管理日志](/docs/user-guide/logging/stackdriver)中详细描述了这一点。
<!--
This article describes how to set up a cluster to ingest logs into
[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
Stackdriver Logging when running on GCE.
-->
本文介绍了如何设置一个集群，将日志导入[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用 [Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上运行应用时使用 Stackdriver Logging 管理日志的替代方案。
{{< note >}}
<!--
You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
-->
您不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动的部署 Elasticsearch 和 Kibana。您必须手动部署它们。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!--
To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
kube-up.sh:
-->
要使用 Elasticsearch 和 Kibana 处理集群日志，您应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量：
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
```
<!--
You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
-->
您还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
<!--
Now, when you create a cluster, a message will indicate that the Fluentd log
collection daemons that run on each node will target Elasticsearch:
-->
现在，当您创建集群时，将有一条消息将指示每个节点上运行的 Fluentd 日志收集守护进程以 ElasticSearch 为日志输出目标：
```shell
$ cluster/kube-up.sh
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
```
<!--
The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
all be running in the kube-system namespace soon after the cluster comes to
life.
-->
每个节点的 Fluentd pod、Elasticsearch pod 和 Kibana pod 都应该在集群启动后不久运行在 kube-system 命名空间中。
```shell
$ kubectl get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
kibana-logging-v1-bhpo8 1/1 Running 0 2h
kube-dns-v3-7r1l9 3/3 Running 0 2h
monitoring-heapster-v4-yl332 1/1 Running 1 2h
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
```
<!--
The `fluentd-elasticsearch` pods gather logs from each node and send them to
the `elasticsearch-logging` pods, which are part of a
[service](/docs/concepts/services-networking/service/) named `elasticsearch-logging`. These
Elasticsearch pods store the logs and expose them via a REST API.
The `kibana-logging` pod provides a web UI for reading the logs stored in
Elasticsearch, and is part of a service named `kibana-logging`.
-->
`fluentd-elasticsearch` pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` pods，该 pod 是名为 `elasticsearch-logging` 的[服务](/docs/concepts/services-networking/service/)的一部分。
这些 ElasticSearch pod 存储日志，并通过 REST API 将其公开。
`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，它是名为 `kibana-logging` 的服务的一部分。
<!--
The Elasticsearch and Kibana services are both in the `kube-system` namespace
and are not directly exposed via a publicly reachable IP address. To reach them,
follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
-->
Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中，并且没有通过可公开访问的 IP 地址直接暴露。
要访问它们，请参照[访问集群中运行的服务](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster)的说明进行操作。
<!--
If you try accessing the `elasticsearch-logging` service in your browser, you'll
see a status page that looks something like this:
-->
如果你想在浏览器中访问 `elasticsearch-logging` 服务，你将看到类似下面的状态页面：
![Elasticsearch Status](/images/docs/es-browser.png)
<!--
You can now type Elasticsearch queries directly into the browser, if you'd
like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
for more details on how to do so.
-->
现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。
请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。
<!--
Alternatively, you can view your cluster's logs using Kibana (again using the
[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
The first time you visit the Kibana URL you will be presented with a page that
asks you to configure your view of the ingested logs. Select the option for
timeseries values and select `@timestamp`. On the following page select the
`Discover` tab and then you should be able to see the ingested logs.
You can set the refresh interval to 5 seconds to have the logs
regularly refreshed.
-->
或者，您可以使用 Kibana 查看集群的日志（再次使用[访问集群中运行的服务的说明](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)）。
第一次访问 Kibana URL 时，将显示一个页面，要求您配置所接收日志的视图。
选择时间序列值的选项，然后选择 `@timestamp`。
在下面的页面中选择 `Discover` 选项卡，然后您应该能够看到所摄取的日志。
您可以将刷新间隔设置为 5 秒，以便定期刷新日志。
<!--
Here is a typical view of ingested logs from the Kibana viewer:
-->
以下是从 Kibana 查看器中摄取日志的典型视图：
![Kibana logs](/images/docs/kibana-logs.png)
{{% /capture %}}
{{% capture whatsnext %}}
<!--
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-->
Kibana 为浏览您的日志提供了各种强大的选项！有关如何深入研究它的一些想法，请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md
+315
View File
@@ -0,0 +1,315 @@
---
content_template: templates/task
title: 节点健康监测
---
<!--
---
reviewers:
- Random-Liu
- dchen1107
content_template: templates/task
title: Monitor Node Health
---
-->
{{% capture overview %}}
*节点问题探测器* 是一个 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 用来监控节点健康。它从各种守护进程收集节点问题，并以[NodeCondition](/docs/concepts/architecture/nodes/#condition) 和 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) 的形式报告给 apiserver 。
<!--
*Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
node health. It collects node problems from various daemons and reports them
to the apiserver as [NodeCondition](/docs/concepts/architecture/nodes/#condition)
and [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core).
-->
<!--
It supports some known kernel issue detection now, and will detect more and
more node problems over time.
-->
它现在支持一些已知的内核问题检测，并将随着时间的推移，检测更多节点问题。
<!--
Currently Kubernetes won't take any action on the node conditions and events
generated by node problem detector. In the future, a remedy system could be
introduced to deal with node problems.
-->
目前，Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。将来可能会引入一个补救系统来处理这些节点问题。
<!--
See more information
[here](https://github.com/kubernetes/node-problem-detector).
-->
更多信息请参阅 [这里](https://github.com/kubernetes/node-problem-detector)。
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!--
## Limitations
-->
## 局限性
<!--
* The kernel issue detection of node problem detector only supports file based
kernel log now. It doesn't support log tools like journald.
-->
* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。 它不支持像 journald 这样的命令行日志工具。
<!--
* The kernel issue detection of node problem detector has assumption on kernel
log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
it to [support other log format](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format).
-->
* 节点问题检测器的内核问题检测对内核日志格式有一定要求，现在它只适用于 Ubuntu 和 Debian。但是，将其扩展为 [支持其它日志格式](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format) 也很容易。
<!--
## Enable/Disable in GCE cluster
-->
## 在 GCE 集群中启用/禁用
<!--
Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
gce cluster.
-->
节点问题检测器在 gce 集群中以[集群插件的形式](/docs/setup/cluster-large/#addon-resources)默认启用。
<!--
You can enable/disable it by setting the environment variable
`KUBE_ENABLE_NODE_PROBLEM_DETECTOR` before `kube-up.sh`.
-->
您可以在运行 `kube-up.sh` 之前，以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。
<!--
## Use in Other Environment
-->
## 在其它环境中使用
<!--
To enable node problem detector in other environment outside of GCE, you can use
either `kubectl` or addon pod.
-->
要在 GCE 之外的其他环境中启用节点问题检测器，您可以使用 `kubectl` 或插件 pod。
<!--
### Kubectl
-->
### Kubectl
<!--
This is the recommended way to start node problem detector outside of GCE. It
provides more flexible management, such as overwriting the default
configuration to fit it into your environment or detect
customized node problems.
-->
这是在 GCE 之外启动节点问题检测器的推荐方法。它的管理更加灵活，例如覆盖默认配置以使其适合您的环境或检测自定义节点问题。
<!--
* **Step 1:** `node-problem-detector.yaml`:
-->
* **步骤 1:** `node-problem-detector.yaml`:
{{< codenew file="debug/node-problem-detector.yaml" >}}
<!--
***Notice that you should make sure the system log directory is right for your
OS distro.***
-->
***请注意保证您的系统日志路径与您的 OS 发行版相对应。***
<!--
* **Step 2:** Start node problem detector with `kubectl`:
-->
* **步骤 2:** 执行 `kubectl` 来启动节点问题检测器：
```shell
kubectl create -f https://k8s.io/examples/debug/node-problem-detector.yaml
```
<!--
### Addon Pod
-->
### 插件 Pod
<!--
This is for those who have their own cluster bootstrap solution, and don't need
to overwrite the default configuration. They could leverage the addon pod to
further automate the deployment.
-->
这适用于拥有自己的集群引导程序解决方案的用户，并且不需要覆盖默认配置。 他们可以利用插件 Pod 进一步自动化部署。
<!--
Just create `node-problem-detector.yaml`, and put it under the addon pods directory
`/etc/kubernetes/addons/node-problem-detector` on master node.
-->
只需创建 `node-problem-detector.yaml`，并将其放在主节点上的插件 pod 目录 `/etc/kubernetes/addons/node-problem-detector` 下。
<!--
## Overwrite the Configuration
-->
## 覆盖配置文件
<!--
The [default configuration](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)
is embedded when building the docker image of node problem detector.
-->
构建节点问题检测器的 docker 镜像时，会嵌入[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。
<!--
However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to overwrite it
following the steps:
-->
不过，您可以像下面这样使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 将其覆盖：
<!--
* **Step 1:** Change the config files in `config/`.
* **Step 2:** Create the ConfigMap `node-problem-detector-config` with `kubectl create configmap
node-problem-detector-config --from-file=config/`.
* **Step 3:** Change the `node-problem-detector.yaml` to use the ConfigMap:
-->
* **步骤 1:** 在 `config/` 中更改配置文件。
* **步骤 2:** 使用 `kubectl create configmap node-problem-detector-config --from-file=config/` 创建 `node-problem-detector-config` 。
* **步骤 3:** 更改 `node-problem-detector.yaml` 以使用 ConfigMap:
{{< codenew file="debug/node-problem-detector-configmap.yaml" >}}
<!--
* **Step 4:** Re-create the node problem detector with the new yaml file:
-->
* **步骤 4:** 使用新的 yaml 文件重新创建节点问题检测器：
```shell
kubectl delete -f https://k8s.io/examples/debug/node-problem-detector.yaml # If you have a node-problem-detector running
kubectl create -f https://k8s.io/examples/debug/node-problem-detector-configmap.yaml
```
<!--
***Notice that this approach only applies to node problem detector started with `kubectl`.***
-->
***请注意，此方法仅适用于通过 `kubectl` 启动的节点问题检测器。***
<!--
For node problem detector running as cluster addon, because addon manager doesn't support
ConfigMap, configuration overwriting is not supported now.
-->
由于插件管理器不支持ConfigMap，因此现在不支持对于作为集群插件运行的节点问题检测器的配置进行覆盖。
<!--
## Kernel Monitor
-->
## 内核监视器
<!--
*Kernel Monitor* is a problem daemon in node problem detector. It monitors kernel log
and detects known kernel issues following predefined rules.
-->
*内核监视器* 是节点问题检测器中的问题守护进程。它监视内核日志并按照预定义规则检测已知内核问题。
<!--
The Kernel Monitor matches kernel issues according to a set of predefined rule list in
[`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json).
The rule list is extensible, and you can always extend it by overwriting the
configuration.
-->
内核监视器根据 [`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json) 中的一组预定义规则列表匹配内核问题。
规则列表是可扩展的，您始终可以通过覆盖配置来扩展它。
<!--
### Add New NodeConditions
-->
### 添加新的 NodeCondition
<!--
To support new node conditions, you can extend the `conditions` field in
`config/kernel-monitor.json` with new condition definition:
-->
您可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。
```json
{
"type": "NodeConditionType",
"reason": "CamelCaseDefaultNodeConditionReason",
"message": "arbitrary default node condition message"
}
```
<!--
### Detect New Problems
-->
### 检测新的问题
<!--
To detect new problems, you can extend the `rules` field in `config/kernel-monitor.json`
with new rule definition:
-->
您可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。
```json
{
"type": "temporary/permanent",
"condition": "NodeConditionOfPermanentIssue",
"reason": "CamelCaseShortReason",
"message": "regexp matching the issue in the kernel log"
}
```
<!--
### Change Log Path
-->
### 更改日志路径
<!--
Kernel log in different OS distros may locate in different path. The `log`
field in `config/kernel-monitor.json` is the log path inside the container.
You can always configure it to match your OS distro.
-->
不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。您始终可以修改配置使其与您的 OS 发行版匹配。
<!--
### Support Other Log Format
-->
### 支持其它日志格式
<!--
Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/pkg/kernelmonitor/translator/translator.go)
plugin to translate kernel log the internal data structure. It is easy to
implement a new translator for a new log format.
-->
内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。我们可以很容易为新的日志格式实现新的翻译器。
{{% /capture %}}
{{% capture discussion %}}
<!--
## Caveats
-->
## 注意事项
<!--
It is recommended to run the node problem detector in your cluster to monitor
the node health. However, you should be aware that this will introduce extra
resource overhead on each node. Usually this is fine, because:
-->
我们建议在集群中运行节点问题检测器来监视节点运行状况。但是，您应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响，因为：
<!--
* The kernel log is generated relatively slowly.
* Resource limit is set for node problem detector.
* Even under high load, the resource usage is acceptable.
(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
-->
* 内核日志生成相对较慢。
* 节点问题检测器有资源限制。
* 即使在高负载下，资源使用也是可以接受的。
(参阅 [基准测试结果](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+105
View File
@@ -0,0 +1,105 @@
---
reviewers:
- fgrzadkowski
- piosz
title: 资源指标管道
content_template: templates/concept
---
<!--
---
reviewers:
- fgrzadkowski
- piosz
title: Resource metrics pipeline
content_template: templates/concept
---
-->
{{% capture overview %}}
<!--
Starting from Kubernetes 1.8, resource usage metrics, such as container CPU and memory usage,
are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
Horizontal Pod Autoscaler, to make decisions.
-->
从 Kubernetes 1.8开始，资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。这些指标可以直接被用户访问，比如使用`kubectl top`命令行，或者这些指标由集群中的控制器使用，例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
{{% /capture %}}
{{% capture body %}}
<!--
## The Metrics API
-->
## Metrics API
<!--
Through the Metrics API you can get the amount of resource currently used
by a given node or a given pod. This API doesn't store the metric values,
so it's not possible for example to get the amount of resources used by a
given node 10 minutes ago.
-->
通过 Metrics API，您可以获得指定节点或 pod 当前使用的资源量。此 API 不存储指标值，因此想要获取某个指定节点10分钟前的资源使用量是不可能的。
<!--
The API is no different from any other API:
-->
此 API 与其他 API 没有区别：
<!--
- it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
- it offers the same security, scalability and reliability guarantees
-->
- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，路径为`/apis/metrics.k8s.io/`
- 它提供相同的安全性、可扩展性和可靠性保证
<!--
The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
repository. You can find more information about the API there.
-->
Metrics API 在[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
仓库中定义。您可以在那里找到有关 Metrics API 的更多信息。
<!--
The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
-->
{{< note >}}
Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
{{< /note >}}
<!--
## Metrics Server
-->
## Metrics Server
<!--
[Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
Starting from Kubernetes 1.8 it's deployed by default in clusters created by `kube-up.sh` script
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy).
It's supported in Kubernetes 1.7+ (see details below).
-->
[Metrics Server](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
从 Kubernetes 1.8开始，它作为 Deployment 对象，被默认部署在由`kube-up.sh`脚本创建的集群中。
如果您使用不同的 Kubernetes 安装方法，则可以使用提供的[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)来部署。它在 Kubernetes 1.7+中得到支持（详见下文）。
<!--
Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
-->
Metric server 从每个节点上的 [Kubelet](/docs/admin/kubelet/) 公开的 Summary API 中采集指标信息。
<!--
Metrics Server registered in the main API server through
[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/),
which was introduced in Kubernetes 1.7.
-->
通过在主 API server 中注册的 Metrics Server [Kubernetes 聚合器](/docs/concepts/api-extension/apiserver-aggregation/) 来采集指标信息， 这是在 Kubernetes 1.7 中引入的。
<!--
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-->
在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics Server 的更多信息。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+105
View File
@@ -0,0 +1,105 @@
---
reviewers:
- mikedanese
content_template: templates/concept
title: 资源监控工具
---
<!--
---
reviewers:
- mikedanese
content_template: templates/concept
title: Tools for Monitoring Resources
---
-->
{{% capture overview %}}
<!--
To scale an application and provide a reliable service, you need to
understand how the application behaves when it is deployed. You can examine
application performance in a Kubernetes cluster by examining the containers,
[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
the characteristics of the overall cluster. Kubernetes provides detailed
information about an application's resource usage at each of these levels.
This information allows you to evaluate your application's performance and
where bottlenecks can be removed to improve overall performance.
-->
要扩展应用程序并提供可靠的服务，您需要了解应用程序在部署时的行为。
您可以通过检测容器检查 Kubernetes 集群中的应用程序性能，[pods](/docs/user-guide/pods), [服务](/docs/user-guide/services)和整个集群的特征。
Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
此信息使您可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
{{% /capture %}}
{{% capture body %}}
<!--
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
-->
在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。
在新集群上，您可以使用[资源度量](#资源度量管道)或[完整度量](#完整度量管道)管道来收集监视统计信息。
<!--
## Resource metrics pipeline
-->
## 资源度量管道
<!--
The resource metrics pipeline provides a limited set of metrics related to
cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
These metrics are collected by the lightweight, short-term, in-memory
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
are exposed via the `metrics.k8s.io` API.
-->
资源指标管道提供了一组与集群组件，例如[Horizontal Pod Autoscaler]控制器(/docs/tasks/run-application/horizontal-pod-autoscale)，以及 `kubectl top` 实用程序相关的有限度量。
这些指标是由轻量级的、短期内存[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，通过 `metrics.k8s.io` 公开。
<!--
metrics-server discovers all nodes on the cluster and
queries each node's
[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and
memory usage. The kubelet acts as a bridge between the Kubernetes master and
the nodes, managing the pods and containers running on a machine. The kubelet
translates each pod into its constituent containers and fetches individual
container usage statistics from the container runtime through the container
runtime interface. The kubelet fetches this information from the integrated
cAdvisor for the legacy Docker integration. It then exposes the aggregated pod
resource usage statistics through the metrics-server Resource Metrics API.
This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and
read-only ports.
-->
度量服务器发现集群中的所有节点，并且查询每个节点的[kubelet](/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
kubelet 将每个 pod 转换为其组成的容器，并在容器运行时通过容器运行时界面获取各个容器使用情况统计信息。
kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
然后，它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。
该 API 在 kubelet 的经过身份验证和只读的端口上的`/metrics/resource/v1beta1`中提供。
<!--
## Full metrics pipeline
-->
## 完整度量管道
<!--
A full metrics pipeline gives you access to richer metrics. Kubernetes can
respond to these metrics by automatically scaling or adapting the cluster
based on its current state, using mechanisms such as the Horizontal Pod
Autoscaler. The monitoring pipeline fetches metrics from the kubelet and
then exposes them to Kubernetes via an adapter by implementing either the
`custom.metrics.k8s.io` or `external.metrics.k8s.io` API.
-->
一个完整度量管道可以让您访问更丰富的度量。
Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，通过自动调用扩展或调整集群来响应这些度量。
监控管道从 kubelet 获取度量，然后通过适配器将它们公开给 Kubernetes，方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
<!--
[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.
-->
[Prometheus](https://prometheus.io)，一个 CNCF 项目，可以原生监控 Kubernetes、节点和
Prometheus 本身。
完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。
{{% /capture %}}
content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
+220
View File
@@ -0,0 +1,220 @@
---
reviewers:
- brendandburns
- davidopp
content_template: templates/concept
title: 排错
---
<!--
---
reviewers:
- brendandburns
- davidopp
content_template: templates/concept
title: Troubleshooting
---
-->
{{% capture overview %}}
<!--
Sometimes things go wrong. This guide is aimed at making them right. It has
two sections:
-->
有时候事情会出错。本指南旨在正确解决这些问题。它包含两个部分：
<!--
* [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful for users who are deploying code into Kubernetes and wondering why it is not working.
* [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy.
-->
* [应用排错](/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
* [集群排错](/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。
<!--
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
you're using.
-->
您也应该查看所用[版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。
{{% /capture %}}
{{% capture body %}}
<!--
## Getting help
If your problem isn't answered by any of the guides above, there are variety of
ways for you to get help from the Kubernetes team.
-->
## 获取帮助
如果您的问题在上述指南中没有得到答案，您还有另外几种方式从 Kubernetes 团队获得帮助。
<!--
### Questions
The documentation on this site has been structured to provide answers to a wide
range of questions. [Concepts](/docs/concepts/) explain the Kubernetes
architecture and how each component works, while [Setup](/docs/setup/) provides
practical instructions for getting started. [Tasks](/docs/tasks/) show how to
accomplish commonly used tasks, and [Tutorials](/docs/tutorials/) are more
comprehensive walkthroughs of real-world, industry-specific, or end-to-end
development scenarios. The [Reference](/docs/reference/) section provides
detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
-->
### 提问
网站上的文档针对回答各类问题进行了结构化组织和分类。
[概念](/docs/concepts/)部分解释了 Kubernetes 体系结构以及每个组件的工作方式，[安装](/docs/setup/)部分提供了入门的实用说明。
[任务](/docs/tasks/)部分展示了如何完成常用任务，[入门](/docs/tutorials/)部分则是对现实世界、特定行业或端到端开发场景的更全面的演练。
[参考](/docs/reference/)部分提供了详细的 [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档和命令行 (CLI) 接口，例如[`kubectl`](/docs/user-guide/kubectl-overview/)。
<!--
You may also find the Stack Overflow topics relevant:
-->
您还可以找到堆栈溢出相关的主题：
* [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
* [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine)
<!--
## Help! My question isn't covered! I need help now!
-->
## 求救！我的问题还没有解决！我需要立即得到帮助！
<!--
### Stack Overflow
-->
### 堆栈溢出
<!--
Someone else from the community may have already asked a similar question or may
be able to help with your problem. The Kubernetes team will also monitor
[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)!
-->
社区中的其他人可能已经问过和您类似的问题，这或许能帮助解决您的问题。
Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](http://stackoverflow.com/questions/tagged/kubernetes)。
如果现有的问题对您没有帮助，请[问一个新问题](http://stackoverflow.com/questions/ask?tags=kubernetes)!
<!--
### Slack
The Kubernetes team hangs out on Slack in the `#kubernetes-users` channel. You
can participate in discussion with the Kubernetes team [here](https://kubernetes.slack.com).
Slack requires registration, but the Kubernetes team is open invitation to
anyone to register [here](http://slack.kubernetes.io). Feel free to come and ask
any and all questions.
-->
### Slack
Kubernetes 团队在 Slack 中建有 `#kubernetes-users` 频道。
您可以[在这里](https://kubernetes.slack.com)参加与 Kubernetes 团队的讨论。
Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](http://slack.kubernetes.io)注册。
欢迎您随时来问任何问题。
<!--
Once registered, browse the growing list of channels for various subjects of
interest. For example, people new to Kubernetes may also want to join the
`#kubernetes-novice` channel. As another example, developers should join the
`#kubernetes-dev` channel.
-->
一旦注册完成，您就可以浏览各种感兴趣的频道列表。
例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。作为另一个例子，开发人员应该加入 `#kubernetes-dev` 频道。
<!--
There are also many country specific/local language channels. Feel free to join
these channels for localized support and info:
-->
还有许多国家/地区语言频道。请随时加入这些频道以获得本地化支持和信息：
<!--
- China: `#cn-users`, `#cn-events`
- France: `#fr-users`, `#fr-events`
- Germany: `#de-users`, `#de-events`
- India: `#in-users`, `#in-events`
- Italy: `#it-users`, `#it-events`
- Japan: `#jp-users`, `#jp-events`
- Korea: `#kr-users`
- Netherlands: `#nl-users`
- Norway: `#norw-users`
- Poland: `#pl-users`
- Russia: `#ru-users`
- Spain: `#es-users`
- Turkey: `#tr-users`, `#tr-events`
-->
- 中国： `#cn-users`, `#cn-events`
- 法国： `#fr-users`, `#fr-events`
- 德国： `#de-users`, `#de-events`
- 印度： `#in-users`, `#in-events`
- 意大利： `#it-users`, `#it-events`
- 日本： `#jp-users`, `#jp-events`
- 韩国： `#kr-users`
- 荷兰： `#nl-users`
- 挪威： `#norw-users`
- 波兰： `#pl-users`
- 俄罗斯： `#ru-users`
- 西班牙： `#es-users`
- 土耳其： `#tr-users`, `#tr-events`
<!--
### Forum
The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io)
-->
### 论坛
Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io)
<!--
### Bugs and Feature requests
If you have what looks like a bug, or you would like to make a feature request,
please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
-->
如果你发现一个看起来像 bug 的东西，或者你想提出一个功能请求，请使用[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。
<!--
Before you file an issue, please search existing issues to see if your issue is
already covered.
If filing a bug, please include detailed information about how to reproduce the
problem, such as:
-->
在提交问题之前，请搜索现有问题以查看是否已涵盖您的问题。
如果提交 bug，请提供如何重现问题的详细信息，例如：
<!--
* Kubernetes version: `kubectl version`
* Cloud provider, OS distro, network configuration, and Docker version
* Steps to reproduce the problem
-->
* Kubernetes 版本：获取版本的命令为 `kubectl version`
* 云提供商，OS 发行版、网络配置和 Docker 版本
* 重现问题的步骤
{{% /capture %}}