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

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

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

* Update coredns.md (#16930)

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

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

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

* update chinese docs (#16985)

* Fix ordered list (#16988)

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

update

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

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

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

update

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

update

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

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

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

update

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

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

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

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

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

* update format problem (#16956)

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

update

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

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

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

* fix confict update zh translation (#16863)

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

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

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

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

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

* Update RC's link (#16935)

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

Update

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

update the style

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

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

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

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

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

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

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

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

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

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

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

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

* update Unkown ->  Unknown (#17062)

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

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

* update Runnning -> Running (#17061)

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

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

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

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

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

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

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

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

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

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

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

Add Chinese translation for scheduler-perf-tuning

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

Add Chinese translation for scheduler-perf-tuning

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

Add Chinese translation for scheduler-perf-tuning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Update pod-topology-spread-constraints.md

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

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

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

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

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

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

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

* pr_release-1.16_crictl (#17201)

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

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

* translate configure_upgrade_etcd (#17160)

* translate kubeadm_upgrade_apply (#17159)

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

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

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

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

zh-trans replace the wrong translation

* Merged 1.14~1.16 changes (#17117)

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

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

* pr_release-1.16_basic-ss (#17169)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* pr_release-1.16_reconfig-kubelet (#17200)

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

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

* Update jobs-run-completion.md

* Update jobs-run-completion.md

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

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

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

kubeadm_join_phase_control-plane-prepare_download-certs.md

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

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

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

* ZH-trans: add _index.md

* add _index.md file

* add _index.md files

* pr_release-1.16_crd-versions (#17198)

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

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

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

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

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

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

* x

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

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

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

* update zh-translation document (#17096)

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

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

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

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

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

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

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

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

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

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

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

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

* Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

Add Chinese translation for kube-scheduler

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

* Update kube-scheduler.md

* Add Chinese translation for kube-scheduler

* Update kube-scheduler.md

* Update kube-scheduler.md

* Update kube-scheduler.md

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

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

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

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

* translate kubeadm-certs.md (#17090)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Create advanced.md (#17256)

* Create advanced.md

* trans the advanced.md and fix the build bugs

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

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

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

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

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

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

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

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

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

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

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

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

* Update kubeadm_init_phase_etcd.md

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

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

* Update kubeadm_alpha_kubelet.md

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

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

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

* Update kubeadm_init_phase_etcd_local.md

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

* zh trans update-daemon-set.md

* Update update-daemon-set.md

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

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

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

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

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

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

* Update kubeadm_alpha.md

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

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

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

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

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

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

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

* Improve previously translated documents (#17327)

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

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

* Update zh.toml

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

* Update zh.toml

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

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

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

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

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

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

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

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

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

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

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

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

* Update cluster-large.md

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

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

* Update kubeadm_init_phase_certs_etcd-server.md

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

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

* update zh trans kubelet (#17379)

* update zh trans kubelet

* update the file according to feedback from reviewer tengqm

* update 1000-1757 lines

* update the advice zh trans

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

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

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

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

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

* pr_release-1.16_api-overview (#17444)

* pr_release-1.16_daemonset (#17435)

* pr_release-1.16_gc (#17445)

* pr_release-1.16_qos-class (#17442)

* fix QoS Class to QoS 类 (#17464)

* pr_release-1.16-abac (#17427)

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

* pr_release-1.16_endpoint-slice (#17468)

* pr_release-1.16_taint (#17469)

* pr_release-1.16_operator-pattern (#17467)

* pr_release-1.16_ss (#17433)

* pr_release-1.16_admission-controller (#17440)

* pr_release-1.16_containerd (#17441)

* pr_release-1.16_app-container (#17466)

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

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

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

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

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

* pr-release-1.16_logging (#17491)

* pr-release-1.16_cri (#17486)

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

* pattern translate into 模式 (#17485)

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

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

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

* pr-release-1.16_cncf (#17490)

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

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

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

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

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

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

* update deployment.md

* pr-release-1.16_extensions (#17492)

* pr-release-1.16_toleration (#17493)

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

This reverts commit 1134c14e0a39bdc3d1a920ac9797139a6dcccf4b.

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

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

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

* Update toleration.md

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

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

* Broken Link (#17546)

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

* Update trans kubeadm_upgrade_plan.md (#17395)

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

* Update kubeadm_upgrade_plan.md

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

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

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

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

Add back the Original English

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

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

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

update table title and reference

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

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

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

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

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

* Update _index.html

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

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

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

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

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

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

update-750

*  fix-up 1575 line and udpate 2483 line

* update to line 2980

* update to the last line 3160

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

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

* zh-trs:container-runtimes.md

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

* Update container-runtimes.md

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

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

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

* Sorry, wrong commit, roll back...

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

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

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

* Create trans kubeadm_upgrade_diff.md (#17392)

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Update kubeadm_upgrade_diff.md

* Create _index.md (#17831)

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

* Update volume-snapshots.md (#17829)

* Update volume-snapshots.md

* Update volume-snapshots.md

* Update volume-snapshots.md

* Create ovirt.md (#17849)

* Create ovirt.md

* Update ovirt.md

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

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

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

* Sorry, wrong commit, roll back...

* Update translation after tengqm's review.

* Update cloud-providers.md

* Update dual-stack.md (#17836)

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

* Update dual-stack.md

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

* Create validate-dual-stack.md

* Update validate-dual-stack.md

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

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

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

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

* Apply suggestions from code review

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

* Fix format issue (#17921)

* Create topology-manager.md (#17901)

* Create topology-manager.md

* Update topology-manager.md

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

* Update pod-overhead.md (#17931)

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

* Create dcos.md (#17932)

* Create dcos.md

* Update dcos.md

* Update object-management.md (#17937)

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

* Create imperative-config.md (#17956)

* Create imperative-config.md

* Update imperative-config.md

* Create self-hosting.md (#17950)

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

* Create nodelocaldns.md (#17938)

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

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

* Update config.toml

* Remove ru language

* fix shotcode mismatch

Co-authored-by: zhangx501 <zhang0000xun@gmail.com>
Co-authored-by: ZhongliangXiong <xiong.zhongliang@zte.com.cn>
Co-authored-by: Yixiang Wang <wang.yixiang@zte.com.cn>
Co-authored-by: li mengyang <hwdef97@gmail.com>
Co-authored-by: PingWang <wang.ping5@zte.com.cn>
Co-authored-by: chentanjun <tanjunchen20@gmail.com>
Co-authored-by: Sophy417 <53026875+Sophy417@users.noreply.github.com>
Co-authored-by: Qiming <tengqim@cn.ibm.com>
Co-authored-by: yuxiaobo96 <41496192+yuxiaobo96@users.noreply.github.com>
Co-authored-by: senwang <wang.sen2@zte.com.cn>
Co-authored-by: lichuqiang <lichuqiang@huawei.com>
Co-authored-by: lpf7551321 <liupengfei20@huawei.com>
Co-authored-by: Hongcai Ren <renhongcai@huawei.com>
Co-authored-by: jiajie <jiaj12@chinaunicom.cn>
Co-authored-by: heqg <56527988+heqg@users.noreply.github.com>
Co-authored-by: IreneByron <zhangbingqing7@huawei.com>
Co-authored-by: LiuDui <1693291525@qq.com>
Co-authored-by: Wang Bing <wangbing.adam@gmail.com>
Co-authored-by: Damini Satya <daminisatya@gmail.com>
Co-authored-by: liufangwai <liufangwai@huawei.com>
Co-authored-by: wangcong <congfairy2536@gmail.com>
Co-authored-by: XuefeiWang2 <wangxuefei2@huawei.com>
Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Co-authored-by: Ziqiu Zhu <zzqshu@126.com>
Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com>
Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-authored-by: jiazxjason <52809535+jiazxjason@users.noreply.github.com>
Co-authored-by: Coffey Gao <coffiney@qq.com>
Co-authored-by: Bingshen Wang <bingshen.wbs@alibaba-inc.com>
This commit is contained in:
SataQiu
2019-12-25 08:53:29 +08:00
committed by Kubernetes Prow Robot
parent 6be3e1414d
commit 0f2bd2871b
932 changed files with 113356 additions and 8088 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/_index.md
+173
View File
@@ -0,0 +1,173 @@
---
content_template: templates/concept
title: 为 Kubernetes 文档做贡献
linktitle: 贡献
main_menu: true
weight: 80
---
<!--
---
content_template: templates/concept
title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
weight: 80
---
-->
{{% capture overview %}}
<!--
If you would like to help contribute to the Kubernetes documentation or website,
we're happy to have your help! Anyone can contribute, whether you're new to the
project or you've been around a long time, and whether you self-identify as a
developer, an end user, or someone who just can't stand seeing typos.
-->
如果你想帮助对 Kubernetes 文档或网站做出贡献，我们很高兴得到你的帮助！
任何人都可以做出贡献，无论你刚参与项目还是参与了很长时间，无论你是开发人员还是用户，或是无法忍受看到拼写错误的人。
<!--
For more ways to get involved in the Kubernetes community or to learn about us,
also visit the [Kubernetes community site](/community/).
-->
更多途径参与 Kubernetes 社区或了解我们，请访问 [Kubernetes 社区网站](/community/)。
<!--
Looking for the [style guide](/docs/contribute/style/style-guide/) or the
[Kubernetes Community site](/community/)?
-->
查找 [样式指南](/docs/contribute/style/style-guide/) 或者 [Kubernetes 社区网站](/community/)？
{{% /capture %}}
{{% capture body %}}
<!--
## Types of contributor
-->
## 贡献者类型
<!--
- A _member_ of the Kubernetes organization has [signed the CLA](/docs/contribute/start#sign-the-cla)
and contributed some time and effort to the project. See
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for specific criteria for membership.
-->
- [签署了 CLA](/docs/contribute/start#sign-the-cla)并为项目贡献了时间和精力的 Kubernetes 组织的_成员_。
参见 [社区成员](https://github.com/kubernetes/community/blob/master/community-membership.md) 中对于成员资格的具体标准。
<!--
- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
expressed interest in reviewing documentation pull requests and who has been
added to the appropriate Github group and `OWNERS` files in the Github
repository, by a SIG Docs Approver.
-->
- SIG Docs 的_评审者_是对评审文档 PR 感兴趣，并被 SIG Docs 审批者添加到 Github 群组并在 Github 仓库中 `OWNERS` 文件的 Kubernetes 组织的成员。
<!--
- A SIG Docs _approver_ is a member in good standing who has shown a continued
commitment to the project and is granted the ability to merge pull requests
and thus to publish content on behalf of the Kubernetes organization.
Approvers can also represent SIG Docs in the larger Kubernetes community.
Some of the duties of a SIG Docs approver, such as coordinating a release,
require a significant time commitment.
-->
- SIG Docs 的_审批者_是对项目持续贡献，并被授予合并 PR 权限和代表 Kubernetes 组织发布内容的成员。
批准人也可以在更广泛的 Kubernetes 社区中代表 SIG Docs 团队。
SIG Docs审批者的一些职责，如协调发布版本，需要大量的时间投入。
<!--
## Ways to contribute
-->
## 贡献途径
<!--
This list is divided into things anyone can do, things Kubernetes organization
members can do, and things that require a higher level of access and familiarity
with SIG Docs processes. Contributing consistently over time can help you
understand some of the tooling and organizational decisions that have already
been made.
-->
以下列表将工作分成了：任何人都可以做的工作、Kubernetes 组织成员可以做的工作，和熟悉 SIG Docs 流程并且有更高访问权限才能做的工作。
持续的贡献可以帮助你理解已有的工具和组织决策。
<!--
This is not an exhaustive list of ways you can contribute to the Kubernetes
documentation, but it should help you get started.
-->
你对 Kubernetes 文档可以做出的贡献不仅限于列表列出的条目，但它可以帮助你开动起来。
<!--
- [Anyone](/docs/contribute/start/)
- File actionable bugs
-->
- [任何人](/docs/contribute/start/)
- 登记记录可修正的错误
<!--
- [Member](/docs/contribute/start/)
- Improve existing docs
- Bring up ideas for improvement on Slack or SIG docs mailing list
- Improve docs accessibility
- Provide non-binding feedback on PRs
- Write a blog post or case study
-->
- [成员](/docs/contribute/start/)
- 完善已有文档
- 在 Slack 或 SIG Docs 邮件列表中提出改进意见
- 提升文档的易用性
- 对 PR 提出无约束的反馈
- 编写博文和案例分析
<!--
- [Reviewer](/docs/contribute/intermediate/)
- Document new features
- Triage and categorize issues
- Review PRs
- Create diagrams, graphics assets, and embeddable screencasts / videos
- Localization
- Contribute to other repos as a docs representative
- Edit user-facing strings in code
- Improve code comments, Godoc
-->
- [评审者](/docs/contribute/intermediate/)
- 为新功能特性编写文档
- 对 issue 进行筛选和分类
- 评审 PR
- 创建图表、图形分析和嵌入式的屏幕/视频
- 本地化
- 作为 docs 小组的代表为其他项目仓库做贡献
- 在代码中编辑面向用户的字符串
- 改进代码注释和 Godoc
<!--
- [Approver](/docs/contribute/advanced/)
- Publish contributor content by approving and merging PRs
- Participate in a Kubernetes release team as a docs representative
- Propose improvements to the style guide
- Propose improvements to docs tests
- Propose improvements to the Kubernetes website or other tooling
-->
- [审批者](/docs/contribute/advanced/)
- 通过批准和合并 PR 发布贡献成果
- 作为 docs 团队的代表参与 Kubernetes 发布团队
- 对样式指南提出改进建议
- 对文档测试提出改进建议
- 对 Kubernetes 网站或其他工具提出改进建议
{{% /capture %}}
content/zh/docs/contribute/advanced.md
+473
View File
@@ -0,0 +1,473 @@
---
title: 高级贡献
slug: advanced
content_template: templates/concept
weight: 30
---
<!--
---
title: Advanced contributing
slug: advanced
content_template: templates/concept
weight: 30
---
-->
{{% capture overview %}}
<!--
This page assumes that you've read and mastered the
[Start contributing](/docs/contribute/start/) and
[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-->
如果你已经阅读并掌握[开始贡献](/docs/contribute/start/)和[中级贡献](/docs/contribute/intermediate/)，并准备了解更多贡献的途径，请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。
{{% /capture %}}
{{% capture body %}}
<!--
## Be the PR Wrangler for a week
-->
## 做一周的 PR 管理者
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) take regular turns as the PR wrangler for the repository and are added to the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) for weekly rotations.
-->
SIG Docs 的 [approvers](/docs/contribute/participating/#approvers) 可以成为 PR 管理者。SIG Docs approvers 会每周轮换地加入到 [PR 管理者轮换日程](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2)中。
<!--
The PR wrangler’s duties include:
-->
PR 管理者的工作职责包括：
<!--
- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [style guide](/docs/contribute/style/style-guide/).
- Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`).
- Review as many PRs as you can.
- Ensure that the CLA is signed by each contributor.
- Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA.
- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs.
- Provide inline suggestions on the PR for the proposed content changes.
- If you need to verify content, comment on the PR and request more details.
- Assign relevant `sig/` label(s).
- If needed, assign reviewers from the `reviewers:` block in the file's front matter.
- Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status.
- Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed.
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata.
-->
- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[风格指南]](/docs/contribute/style/style-guide/)。
- 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。
- 尽可能多地审阅 PR。
- 确保每个贡献者完成 CLA 签署。
- 指导新的贡献者签署 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)。
- 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 CLA 的贡献者签署 CLA。
- 针对所建议的更改提供反馈，并帮助协调其他 SIG 成员进行技术审核。
- 为 PR 所建议的内容更改提供在线反馈。
- 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
- 设置相关的 `sig/` 标签。
- 如果需要，请从文件开头的 `reviewers:` 块中指定审阅者。
- 设置 `Docs Review` 和 `Tech Review` 标签以标示 PR 的审阅状态。
- 为尚未审阅的 PR 设置 `Needs Doc Review` 或者 `Needs Tech Review` 标签。
- 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。
- 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。
- 合并已经就绪的，或关闭不应该接受的 PR。
- 每天对新增的 issues 进行分类和标记。有关 SIG 文档如何使用 metadata 的准则，请参见[中级贡献](/docs/contribute/intermediate/)。
<!--
### Helpful GitHub queries for wranglers
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
-->
### 对于负责人有用的 GitHub 查询
执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。
<!--
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review
or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along.
- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
-->
- [没有签署 CLA, 不能 merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
**在作者没有签署 CLA 之前，不要审阅他们的 PR！**
- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。
- [有 LGTM ，需要批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 `/approve`。
- [非 master 分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)：
如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。请添加带有 `/assign @<负责人的 github 账号>` 的注释，确保[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。
<!--
### When to close Pull Requests
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
-->
### 什么时候关闭 PR
审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。
<!--
- Close any PR where the CLA hasn’t been signed for two weeks.
PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
To close a pull request, leave a `/close` comment on the PR.
-->
- 关闭两个星期未签署 CLA 的 PR。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。
不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。通常，关闭通知会激励作者继续完成其贡献。
要关闭 PR，请在 PR 上输入 `/close`。
{{< note >}}
<!--
An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
-->
一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 issues 停滞 90 天后会自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< /note >}}
<!--
## Propose improvements
SIG Docs
[members](/docs/contribute/participating/#members) can propose improvements.
-->
## 提出改进建议
SIG Docs 的 [成员](/docs/contribute/participating/#members) 可以提出改进建议。
<!--
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improvement to the style guide, the toolchain used to build
the documentation, the website style, the processes for reviewing and merging
pull requests, or other aspects of the documentation. For maximum transparency,
these types of proposals need to be discussed in a SIG Docs meeting or on the
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
In addition, it can really help to have some context about the way things
currently work and why past decisions have been made before proposing sweeping
changes. The quickest way to get answers to questions about how the documentation
currently works is to ask in the `#sig-docs` Slack channel on
[kubernetes.slack.com](https://kubernetes.slack.com)
-->
在对 Kubernetes 文档贡献了一段时间后，你可能会对样式指南、用于构建文档的工具链、网页样式、评审和合入 PR 的流程，或者文档的其他方面产生改进的想法。为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)上讨论。此外，在提出全面的改进之前，它能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。想了解文档的当前运作方式，最快的途径是咨询 [kubernetes.slack.com](https://kubernetes.slack.com) 中的 `#sig-docs` 聊天群组。
<!--
After the discussion has taken place and the SIG is in agreement about the desired
outcome, you can work on the proposed changes in the way that is the most
appropriate. For instance, an update to the style guide or the website's
functionality might involve opening a pull request, while a change related to
documentation testing might involve working with sig-testing.
-->
在进行了讨论并且 SIG 就期望的结果达成一致之后，你就能以最合理的方式处理改进建议了。例如，样式指南或网站功能的更新可能涉及 PR 的新增，而与文档测试相关的更改可能涉及 sig-testing。
<!--
## Coordinate docs for a Kubernetes release
-->
## 为 Kubernetes 版本发布协调文档
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
docs for a Kubernetes release.
-->
SIG Docs 的[批准者（approvers）](/docs/contribute/participating/#approvers) 可以为 Kubernetes 版本发布协调文档。
<!--
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
release include an overall release lead, as well as representatives from sig-pm,
sig-testing, and others. To find out more about Kubernetes release processes,
refer to
[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
-->
每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-pm、sig-testing 的代表等。了解更多关于 Kubernetes 版本发布的流程，请参考 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。
<!--
The SIG Docs representative for a given release coordinates the following tasks:
-->
SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
<!--
- Monitor the feature-tracking spreadsheet for new or changed features with an
impact on documentation. If documentation for a given feature won't be ready
for the release, the feature may not be allowed to go into the release.
- Attend sig-release meetings regularly and give updates on the status of the
docs for the release.
- Review and copyedit feature documentation drafted by the SIG responsible for
implementing the feature.
- Merge release-related pull requests and maintain the Git feature branch for
the release.
- Mentor other SIG Docs contributors who want to learn how to do this role in
the future. This is known as "shadowing".
- Publish the documentation changes related to the release when the release
artifacts are published.
-->
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
- 定期参加 sig-release 会议并汇报文档的发布状态。
- 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。
- 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。
- 指导那些想学习并有意愿担当该角色的 SIG Docs 贡献者。这就是我们常说的“实习”。
- 发布版本的组件发布时，相关的文档更新也需要发布。
<!--
Coordinating a release is typically a 3-4 month commitment, and the duty is
rotated among SIG Docs approvers.
-->
协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs approvers 轮流承担。
<!--
## Serve as a New Contributor Ambassador
-->
## 担任新的贡献者大使
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
New Contributor Ambassadors.
New Contributor Ambassadors work together to welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
few PR submissions.
Responsibilities for New Contributor Ambassadors include:
-->
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新的贡献者大使。
新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，以及在前几份 PR 提交中指导新贡献者。
新的贡献者大使的职责包括：
<!--
- Being available on the [Kubernetes #sig-docs channel](https://kubernetes.slack.com) to answer questions from new contributors.
- Working with PR wranglers to identify good first issues for new contributors.
- Mentoring new contributors through their first few PRs to the docs repo.
- Helping new contributors create the more complex PRs they need to become Kubernetes members.
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
-->
- 可在 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上回答新贡献者的问题。
- 与 PR 管理者合作为新参与者寻找合适的第一个 issues。
- 通过前几个 PR 指导新贡献者到文档存储库。
- 帮助新的贡献者创建成为 Kubernetes 成员所需的更复杂的 PR。
- [为贡献者提供担保](/docs/contribute/advanced/#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。
<!--
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
-->
当前新贡献者大使将在每次 SIG 文档会议上以及 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com)中宣布。
<!--
## Sponsor a new contributor
-->
## 为新的贡献者提供担保
<!--
SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
new contributors.
-->
SIG Docs 的 [reviewers](/docs/contribute/participating/#reviewers) 可以为新的贡献者提供担保。
<!--
After a new contributor has successfully submitted 5 substantive pull requests
to one or more Kubernetes repositories, they are eligible to apply for
[membership](/docs/contribute/participating#members) in the Kubernetes
organization. The contributor's membership needs to be backed by two sponsors
who are already reviewers.
-->
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织 [成员身份](/docs/contribute/participating#members)。贡献者的成员资格需要同时得到两位 reviewers 的保荐。
<!--
New docs contributors can request sponsors by asking in the #sig-docs channel
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
If you feel confident about the applicant's work, you volunteer to sponsor them.
When they submit their membership application, reply to the application with a
"+1" and include details about why you think the applicant is a good fit for
membership in the Kubernetes organization.
-->
新的文档贡献者可以通过咨询 [Kubernetes Slack 实例](https://kubernetes.slack.com) 上的 #sig-docs 频道或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。
<!--
## Serve as a SIG Co-chair
SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs.
### Prerequisites
-->
## 担任 SIG 联合主席
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任 SIG Docs 的联合主席。
### 前提条件
<!--
Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
-->
Approvers 必须满足以下要求才能成为联合主席：
- 已维持 SIG Docs approver 身份至少 6 个月
- [曾领导 Kubernetes 文档发布](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) 或者在两个版本发布中有实习经历
- 理解 SIG Docs 工作流程和工具：git、Hugo、本地化、博客子项目
- 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括：[k/org 中的团队](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)、[k/community 中的流程](https://github.com/kubernetes/community/tree/master/sig-docs)、[k/test-infra](https://github.com/kubernetes/test-infra/) 中的插件、[SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture) 中的角色。
- 在至少 6 个月的时段内，确保每周至少投入 5 个小时（通常更多）
<!--
### Responsibilities
The role of co-chair is primarily one of service: co-chairs handle process and policy, schedule and run meetings, schedule PR wranglers, and generally do the things that no one else wants to do in order to build contributor capacity.
Responsibilities include:
-->
### 职责范围
联合主席主要提供以下服务：
联合主席负责处理流程和政策、时间安排和召开会议、安排 PR 管理员、以及一些其他人不想做的事情，目的是增长贡献者团队。
职责范围包括：
<!--
- Keep SIG Docs focused on maximizing developer happiness through excellent documentation
- Exemplify the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and hold SIG members accountable to it
- Learn and set best practices for the SIG by updating contribution guidelines
- Schedule and run SIG meetings: weekly status updates, quarterly retro/planning sessions, and others as needed
- Schedule and run doc sprints at KubeCon events and other conferences
- Recruit for and advocate on behalf of SIG Docs with the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} and its platinum partners, including Google, Oracle, Azure, IBM, and Huawei
- Keep the SIG running smoothly
-->
- 保持 SIG Docs 专注于通过出色的文档最大限度地提高开发人员的满意度
- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 并要求 SIG 成员对自身行为负责
- 通过更新贡献准则，为 SIG 学习并设置最佳实践
- 安排和举行 SIG 会议：每周状态更新，每季度回顾/计划会议以及其他需要的会议
- 在 KubeCon 活动和其他会议上安排和负责文档工作
- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传
- 负责 SIG 正常运行
<!--
### Running effective meetings
To schedule and run effective meetings, these guidelines show what to do, how to do it, and why.
**Uphold the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**:
- Hold respectful, inclusive discussions with respectful, inclusive language.
-->
### 召开高效的会议
为了安排和召开高效的会议，这些准则说明了如何做、怎样做以及原因。
**坚持[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**：
- 相互尊重地、包容地进行讨论。
<!--
**Set a clear agenda**:
- Set a clear agenda of topics
- Publish the agenda in advance
For weekly meetings, copypaste the previous week's notes into the "Past meetings" section of the notes
-->
**设定明确的议程**：
- 设定清晰的主题议程
- 提前发布议程
对于每周一次的会议，请将前一周的笔记复制并粘贴到笔记的“过去的会议”部分中
<!--
**Collaborate on accurate notes**:
- Record the meeting's discussion
- Consider delegating the role of note-taker
**Assign action items clearly and accurately**:
- Record the action item, who is assigned to it, and the expected completion date
-->
**通过协作，完成准确的记录**：
- 记录会议讨论
- 考虑委派笔记记录员的角色
**清晰准确地分配执行项目**：
- 记录操作项，分配给它的人员以及预期的完成日期
<!--
**Moderate as needed**:
- If discussion strays from the agenda, refocus participants on the current topic
- Make room for different discussion styles while keeping the discussion focused and honoring folks' time
**Honor folks' time**:
- Begin and end meetings punctually
-->
**根据需要来进行协调**：
- 如果讨论偏离议程，请让参与者重新关注当前主题
- 为不同的讨论风格留出空间，同时保持讨论重点并尊重人们的时间
**尊重大家的时间**:
- 准时开始和结束会议
<!--
**Use Zoom effectively**:
- Familiarize yourself with [Zoom guidelines for Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md)
- Claim the host role when you log in by entering the host key
<img src="/images/docs/contribute/claim-host.png" width="75%" alt="Claiming the host role in Zoom" />
-->
**有效利用 Zoom**：
- 熟悉 [ Kubernetes Zoom 指南](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md)
- 输入主持人密钥登录时声明主持人角色
<img src="/images/docs/contribute/claim-host.png" width="75%" alt="声明 Zoom 角色" />
<!--
### Recording meetings on Zoom
When you’re ready to start the recording, click Record to Cloud.
When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
-->
### 录制 Zoom 会议
准备开始录制时，请单击“录制到云”。
准备停止录制时，请单击“停止”。
视频会自动上传到 YouTube。
{{% /capture %}}
content/zh/docs/contribute/generate-ref-docs/_index.md
+21
View File
@@ -0,0 +1,21 @@
---
title: 参考文档概述
main_menu: true
weight: 80
---
<!--
---
title: Reference docs overview
main_menu: true
weight: 80
---
-->
<!--
Much of the Kubernetes reference documentation is generated from Kubernetes
source code, using scripts. The topics in this section document how to generate
this type of content.
-->
许多 Kubernetes 参考文档都是使用脚本从 Kubernetes 源代码生成的。本节的主题是如何生成这种类型的文档。
content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
+405
View File
@@ -0,0 +1,405 @@
---
title: 为上游 Kubernetes 代码库做出贡献
content_template: templates/task
---
<!--
---
title: Contributing to the Upstream Kubernetes Code
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to contribute to the upstream kubernetes/kubernetes project
to fix bugs found in the Kubernetes API documentation or the `kube-*`
components such as `kube-apiserver`, `kube-controller-manager`, etc.
-->
此页面描述如何为上游 kubernetes/kubernetes 项目做出贡献，如修复 Kubernetes API 文档或 `kube-*` 组件（例如 kube-apiserver、kube-controller-manager 等）中发现的错误。
<!--
If you instead want to regenerate the reference documentation for the Kubernetes
API or the `kube-*` components from the upstream code, see the following instructions:
-->
相反，如果您想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明：
<!--
- [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
- [Generating Reference Documentation for the Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
-->
- [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
- [生成 Kubernetes 组件和工具的参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/)
{{% /capture %}}
{{% capture prerequisites %}}
<!--
You need to have these tools installed:
-->
您需要安装以下工具：
<!--
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* [Golang](https://golang.org/doc/install) version 1.9.1 or later
* [Docker](https://docs.docker.com/engine/installation/)
* [etcd](https://github.com/coreos/etcd/)
-->
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* [Golang](https://golang.org/doc/install) Go 版本大于 1.9.1
* [Docker](https://docs.docker.com/engine/installation/)
* [etcd](https://github.com/coreos/etcd/)
<!--
Your $GOPATH environment variable must be set, and the location of `etcd`
must be in your $PATH environment variable.
-->
必须设置 $GOPATH 环境变量，并且 `etcd` 的位置必须在 $PATH 环境变量中。
<!--
You need to know how to create a pull request to a GitHub repository.
Typically, this involves creating a fork of the repository. For more
information, see
[Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and
[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
-->
您需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。
通常，这涉及创建代码仓库的分支。要获取更多的信息请参考[创建 PR](https://help.github.com/articles/creating-a-pull-request/) 和
[GitHub 标准 Fork 和 PR 工作流程](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。
{{% /capture %}}
{{% capture steps %}}
<!--
## The big picture
-->
## 基本原则
<!--
The reference documentation for the Kubernetes API and the `kube-*` components
such as `kube-apiserver`, `kube-controller-manager` are automatically generated
from the source code in the [upstream Kubernetes](https://github.com/kubernetes/kubernetes/).
-->
Kubernetes API 和 `kube-*` 组件（例如 `kube-apiserver`、`kube-controller-manager`）的参考文档是根据[上游 Kubernetes](https://github.com/kubernetes/kubernetes/) 中的源代码自动生成的。
<!--
When you see bugs in the generated documentation, you may want to consider
creating a patch to fix it in the upstream project.
-->
当您在生成的文档中看到错误时，您可能需要考虑创建一个 PR 用来在上游项目中对其进行修复。
<!--
## Cloning the Kubernetes repository
-->
## 克隆 Kubernetes 代码仓库
<!--
If you don't already have the kubernetes/kubernetes repository, get it now:
-->
如果您还没有 kubernetes/kubernetes 代码仓库，请立即参照下列命令获取：
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
```
<!--
Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
-->
确定您的 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库克隆的基本目录。
例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes/kubernetes`。
接下来其余步骤将您的基本目录称为 `<k8s-base>`。
<!--
Determine the base directory of your clone of the
[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes-sigs/reference-docs.`
The remaining steps refer to your base directory as `<rdocs-base>`.
-->
确定您的 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 代码仓库克隆的基本目录。
例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。
接下来其余步骤将您的基本目录称为 `<rdocs-base>`。
<!--
## Editing the Kubernetes source code
-->
## 编辑 Kubernetes 源代码
<!--
The Kubernetes API reference documentation is automatically generated from
an OpenAPI spec, which is generated from the Kubernetes source code. If you
want to change the API reference documentation, the first step is to change one
or more comments in the Kubernetes source code.
-->
Kubernetes API 参考文档是根据 OpenAPI 规范自动生成的，该规范是从 Kubernetes 源代码生成的。如果要更改 API 参考文档，第一步是更改 Kubernetes 源代码中的一个或多个注释。
<!--
The documentation for the `kube-*` components is also generated from the upstream
source code. You must change the code related to the component
you want to fix in order to fix the generated documentation.
-->
`kube-*` 组件的文档也是从上游源代码生成的。您必须更改与要修复的组件相关的代码，才能修复生成的文档。
<!--
### Making changes to the upstream source code
-->
### 更改上游 Kubernetes 源代码
<!--
The following steps are an example, not a general procedure. Details
will be different in your situation.
-->
{{< note >}}
以下步骤仅作为示例，不是一般步骤，具体情况因您而异。
{{< /note >}}
<!--
Here's an example of editing a comment in the Kubernetes source code.
-->
以下在 Kubernetes 源代码中编辑注释的示例。
<!--
In your local kubernetes/kubernetes repository, check out the master branch,
and make sure it is up to date:
-->
在您本地的 kubernetes/kubernetes 代码仓库中，切换出本地 master 分支，并确保它是最新的：
```shell
cd <k8s-base>
git checkout master
git pull https://github.com/kubernetes/kubernetes master
```
<!--
Suppose this source file in the master branch has the typo "atmost":
-->
假设 master 分支中的此源文件的拼写错误为 "atmost"：
[kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go)
<!--
In your local environment, open `types.go`, and change "atmost" to "at most".
-->
在您的本地环境中，打开 `types.go` 文件，然后将 "atmost" 更改为 "at most"。
<!--
Verify that you have changed the file:
-->
以下命令查看您已更改的文件：
```shell
git status
```
<!--
The output shows that you are on the master branch, and that the `types.go`
source file has been modified:
-->
输出显示您在 master 分支上，`types.go` 源文件已被修改：
```shell
On branch master
...
modified: staging/src/k8s.io/api/apps/v1/types.go
```
<!--
### Committing your edited file
-->
### 提交已编辑的文件
<!--
Run `git add` and `git commit` to commit the changes you have made so far. In the next step,
you will do a second commit. It is important to keep your changes separated into two commits.
-->
运行 `git add` 和 `git commit` 命令提交到目前为止所做的更改。在下一步中，您将进行第二次提交，将更改分成两个提交很重要。
<!--
### Generating the OpenAPI spec and related files
-->
### 生成 OpenAPI 规范和相关文件
<!--
Go to `<k8s-base>` and run these scripts:
-->
进入 `<k8s-base>` 目录并运行以下脚本：
```shell
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
<!--
Run `git status` to see what was generated.
-->
运行 `git status` 命令查看生成的东西。
```shell
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/swagger-spec/apps_v1.json
modified: docs/api-reference/apps/v1/definitions.html
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
```
<!--
View the contents of `api/openapi-spec/swagger.json` to make sure the typo is fixed.
For example, you could run `git diff -a api/openapi-spec/swagger.json`.
This is important, because `swagger.json` is the input to the second stage of
the doc generation process.
-->
查看 `api/openapi-spec/swagger.json` 的内容，以确保 typo 已经被修正。例如，您可以运行 `git diff -a api/openapi-spec/swagger.json` 命令。这很重要，因为 `swagger.json` 是文档生成过程中第二阶段的输入。
<!--
Run `git add` and `git commit` to commit your changes. Now you have two commits:
one that contains the edited `types.go` file, and one that contains the generated OpenAPI spec
and related files. Keep these two commits separate. That is, do not squash your commits.
-->
运行 `git add` 和 `git commit` 命令来提交您的更改。现在您有两个提交：
一种包含编辑的 `types.go` 文件，另一种包含生成的 OpenAPI 规范和相关文件。
将这两个提交分开独立。也就是说，不要 squash 您的提交。
<!--
Submit your changes as a
[pull request](https://help.github.com/articles/creating-a-pull-request/) to the
master branch of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it is merged.
-->
将您的更改作为 [PR](https://help.github.com/articles/creating-a-pull-request/) 提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库的 master 分支。关注您的 PR，并根据需要回复 reviewer 的评论。继续关注您的 PR，直到 PR 被合并为止。
<!--
[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758)
is an example of a pull request that fixes a typo in the Kubernetes source code.
-->
[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是修复 Kubernetes 源代码中的拼写错误的拉取请求的示例。
<!--
It can be tricky to determine the correct source file to be changed. In the
preceding example, the authoritative source file is in the `staging` directory
in the `kubernetes/kubernetes` repository. But in your situation,the `staging` directory
might not be the place to find the authoritative source. For guidance, check the
`README` files in
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging)
repository and in related repositories, such as
[kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md).
-->
{{< note >}}
确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 `kubernetes/kubernetes` 代码仓库的 `staging` 目录中。但是根据您的情况，`staging` 目录可能不是找到官方源文件的地方。根据指导原则，请检查 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) 代码仓库和相关代码仓库（例如 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)）中的 `README` 文件。
{{< /note >}}
<!--
### Cherry picking your commit into a release branch
-->
### Cherry Pick 将您的提交纳入发布分支
<!--
In the preceding section, you edited a file in the master branch and then ran scripts
to generate an OpenAPI spec and related files. Then you submitted your changes in a pull request
to the master branch of the kubernetes/kubernetes repository. Now suppose you want to backport
your change into a release branch. For example, suppose the master branch is being used to develop
Kubernetes version 1.10, and you want to backport your change into the release-1.9 branch.
-->
在上一节中，您在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。然后将您的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支的 pull request 中。 现在，需要将您的更改反向移植到已经 release 的分支。例如，假设使用 master 分支来开发 Kubernetes 1.10 版，并且您想将更改反向移植到 release-1.9 分支。
<!--
Recall that your pull request has two commits: one for editing `types.go`
and one for the files generated by scripts. The next step is to propose a cherry pick of your first
commit into the release-1.9 branch. The idea is to cherry pick the commit that edited `types.go`, but not
the commit that has the results of running the scripts. For instructions, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
-->
回想一下，您的 pull request 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。下一步的目的是对您的第一次提交 cherry pick 到 release-1.9 分支。这个想法是 cherry pick 编辑了 types.go 的提交，但不是具有运行脚本结果的提交。有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。
<!--
Proposing a cherry pick requires that you have permission to set a label and a milestone in your
pull request. If you don't have those permissions, you will need to work with someone who can set the label
and milestone for you.
-->
{{< note >}}
提出 cherry pick 要求您有权在 pull request 中设置标签和里程碑。如果您没有这些权限，则需要与可以为您设置标签和里程碑的人员合作。
{{< /note >}}
<!--
When you have a pull request in place for cherry picking your one commit into the release-1.9 branch,
the next step is to run these scripts in the release-1.9 branch of your local environment.
-->
当您提出一个 pull request，希望将您的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9 分支中运行这些脚本。
```shell
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
<!--
Now add a commit to your cherry-pick pull request that has the recently generated OpenAPI spec
and related files. Monitor your pull request until it gets merged into the release-1.9 branch.
-->
现在将提交添加到您的 Cherry-pick pull request 中，该请求具有最近生成的 OpenAPI 规范和相关文件。关注您的 pull request 请求，直到其合并到 release-1.9 分支中为止。
<!--
At this point, both the master branch and the release-1.9 branch have your updated `types.go`
file and a set of generated files that reflect the change you made to `types.go`. Note that the
generated OpenAPI spec and other generated files in the release-1.9 branch are not necessarily
the same as the generated files in the master branch. The generated files in the release-1.9 branch
contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain
API elements that are not in 1.9, but are under development for 1.10.
-->
此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件，这些文件反映了您对 `types.go` 所做的更改。请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。
<!--
## Generating the published reference docs
-->
## 生成已发布的参考文档
<!--
The preceding section showed how to edit a source file and then generate
several files, including `api/openapi-spec/swagger.json` in the
`kubernetes/kubernetes` repository.
The `swagger.json` file is the OpenAPI definition file to use for generating
the API reference documentation.
-->
上一节显示了如何编辑源文件然后生成多个文件，包括在 `kubernetes/kubernetes` 代码仓库中的 `api/openapi-spec/swagger.json`。
`swagger.json` 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。
<!--
You are now ready to follow the [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) guide to generate the
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-->
现在，您可以按照[生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)指南来生成
[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
-->
* [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/)
* [生成 kubectl 命令的参考文档](/docs/home/contribute/generated-reference/kubectl/)
{{% /capture %}}
content/zh/docs/contribute/generate-ref-docs/kubectl.md
+487
View File
@@ -0,0 +1,487 @@
---
title: 为 kubectl 命令集生成参考文档
content_template: templates/task
---
<!--
---
title: Generating Reference Documentation for kubectl Commands
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to automatically generate reference pages for the
commands provided by the `kubectl` tool.
-->
该页面显示了如何自动生成 `kubectl` 工具提供的命令的参考页面。
{{< note >}}
<!--
This topic shows how to generate reference documentation for
[kubectl commands](/docs/reference/generated/kubectl/kubectl-commands)
like
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
-->
本主题展示了如何为 [kubectl 命令集](/docs/reference/generated/kubectl/kubectl-commands) 生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。
<!--
This topic does not show how to generate the
[kubectl](/docs/reference/generated/kubectl/kubectl/)
options reference page. For instructions on how to generate the kubectl options
reference page, see
[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
-->
本主题没有展示如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件的参考页面。相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
<!--
* You need to have
[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
installed.
-->
* 你需要安装 [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。
<!--
* You need to have
[Golang](https://golang.org/doc/install) version 1.9.1 or later installed,
and your `$GOPATH` environment variable must be set.
-->
* 你需要安装 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install), 并在环境变量中设置 `$GOPATH`。
<!--
* You need to have
[Docker](https://docs.docker.com/engine/installation/) installed.
-->
* 你需要安装 [Docker](https://docs.docker.com/engine/installation/)。
<!--
* You need to know how to create a pull request to a GitHub repository.
Typically, this involves creating a fork of the repository. For more
information, see
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/) and
[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
-->
* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。
{{% /capture %}}
{{% capture steps %}}
<!--
## Setting up the local repositories
-->
## 设置本地仓库
<!--
Create a local workspace and set your `GOPATH`.
-->
创建本地工作区并设置您的 `GOPATH`。
```shell
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
<!--
Get a local clone of the following repositories:
-->
获取以下仓库的本地克隆：
```shell
go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u kubernetes-incubator/reference-docs
```
<!--
If you don't already have the kubernetes/website repository, get it now:
-->
如果您还没有下载过 `kubernetes/website` 仓库，现在下载：
```shell
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
<!--
Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes:
-->
克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes：
```shell
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
<!--
Remove the spf13 package from `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`.
-->
从 `$GOPATH/src/k8s.io/kubernetes/vendor/github.com` 中卸载 spf13 软件包。
```shell
rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13
```
<!--
The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code.
-->
kubernetes/kubernetes 仓库提供对 kubectl 和 kustomize 源代码的访问。
<!--
* Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/k8s.io/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
-->
确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/k8s.io/kubernetes.`。下文将该目录称为 `<k8s-base>`。
<!--
* Determine the base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/<your-username>/website.`
The remaining steps refer to your base directory as `<web-base>`.
-->
确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/<your-username>/website`。下文将该目录称为 `<web-base>`。
<!--
* Determine the base directory of your clone of the
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.`
The remaining steps refer to your base directory as `<rdocs-base>`. -->
确定 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。下文将该目录称为 `<rdocs-base>`。
<!--
In your local k8s.io/kubernetes repository, check out the branch of interest,
and make sure it is up to date. For example, if you want to generate docs for
Kubernetes 1.15, you could use these commands:
-->
在您当地的 k8s.io/kubernetes 仓库中，检查感兴趣的分支并确保它是最新的。例如，如果您想要生成 Kubernetes 1.15 的文档，您可以使用以下命令：
```shell
cd <k8s-base>
git checkout release-1.15
git pull https://github.com/kubernetes/kubernetes release-1.15
```
<!--
If you do not need to edit the kubectl source code, follow the instructions to [Edit the Makefile](#editing-makefile).
-->
如果不需要编辑 kubectl 源码，请按照说明[编辑 Makefile](#editing-makefile)。
<!--
## Editing the kubectl source code
-->
## 编辑 kubectl 源码
<!--
The kubectl command reference documentation is automatically generated from
the kubectl source code. If you want to change the reference documentation, the first step
is to change one or more comments in the kubectl source code. Make the change in your
local kubernetes/kubernetes repository, and then submit a pull request to the master branch of
[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
-->
kubectl 命令集的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。
<!--
[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files)
is an example of a pull request that fixes a typo in the kubectl source code.
-->
[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl 源码中的笔误进行修复的 PR 示例。
<!--
Monitor your pull request, and respond to reviewer comments. Continue to monitor your
pull request until it is merged into the master branch of the kubernetes/kubernetes repository.
-->
跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 master 分支中。
<!--
## Cherry picking your change into a release branch
-->
## 以 cherry-pick 方式将你的修改合入已发布分支
<!--
Your change is now in the master branch, which is used for development of the next
Kubernetes release. If you want your change to appear in the docs for a Kubernetes
version that has already been released, you need to propose that your change be
cherry picked into the release branch.
-->
你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。
<!--
For example, suppose the master branch is being used to develop Kubernetes 1.10,
and you want to backport your change to the release-1.15 branch. For instructions
on how to do this, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
-->
例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.15 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。
<!--
Monitor your cherry-pick pull request until it is merged into the release branch.
-->
跟踪你的 cherry-pick PR，直到它合入到已发布分支中。
{{< note >}}
<!--
Proposing a cherry pick requires that you have permission to set a label and a
milestone in your pull request. If you don’t have those permissions, you will
need to work with someone who can set the label and milestone for you.
-->
提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。
{{< /note >}}
<!--
## Editing Makefile
-->
## 编辑 Makefile
<!--
Go to `<rdocs-base>`, and open the `Makefile` for editing:
-->
进入 `<rdocs-base>` 目录, 打开 `Makefile` 进行编辑：
<!--
* Set `K8SROOT` to `<k8s-base>`.
* Set `WEBROOT` to `<web-base>`.
* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
-->
* 设置 `K8SROOT` 为 `<k8s-base>`。
* 设置 `WEBROOT` 为 `<web-base>`。
* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。
<!--
For example, update the following variables:
-->
例如，更新以下变量：
```
WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
MINOR_VERSION=15
```
<!--
## Creating a version directory
-->
## 创建版本目录
<!--
The version directory is a staging area for the kubectl command reference build.
The YAML files in this directory are used to create the structure and navigation
of the kubectl command reference.
-->
版本目录是 kubectl 命令集构建的临时区域。该目录中的 YAML 文件用于创建 kubectl 命令集参考的结构和导航。
<!--
In the `<rdocs-base>/gen-kubectldocs/generators` directory, if you do not already
have a directory named `v1_<MINOR_VERSION>`, create one now by copying the directory
for the previous version. For example, suppose you want to generate docs for
Kubernetes 1.15, but you don't already have a `v1_15` directory. Then you could
create and populate a `v1_15` directory by running these commands:
-->
在 `gen-kubectldocs/generators` 目录中，如果你还没有一个名为 `v1_MINOR_VERSION` 的目录，那么现在通过复制前一版本的目录来创建一个。例如，假设你想要为 Kubernetes 1.15 版本生成文档，但是还没有 `v1_15` 目录，这时可以通过运行以下命令来创建并填充 `v1_15` 目录：
```shell
cd <k8s-base>
git checkout release-1.15
git pull https://github.com/kubernetes/kubernetes release-1.15
```
<!--
## Checking out a branch in k8s.io/kubernetes
-->
## 从 kubernetes/kubernetes 检出一个分支
<!--
In your local <k8s-base> repository, checkout the branch that has
the version of Kubernetes that you want to document. For example, if you want
to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure
you local branch is up to date.
-->
在本地 <k8s-base> 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。例如，如果希望为 Kubernetes 1.15 版本生成文档，请检出 1.15 分支。确保本地分支是最新的。
```shell
cd <k8s-base>
git checkout release-1.15
git pull https://github.com/kubernetes/kubernetes release-1.15
```
<!--
## Running the doc generation code
-->
## 运行文档生成代码
<!--
In your local kubernetes-incubator/reference-docs repository, build and run the
kubectl command reference generation code. You might need to run the command as root:
-->
在 kubernetes-incubator/reference-docs 仓库的本地目录中，构建并运行 kubectl 命令集参数生成代码。你可能需要以 root 用户运行命令：
```shell
cd <rdocs-base>
make copycli
```
<!--
The `copycli` command will clean the staging directories, generate the kubectl command files,
and copy the collated kubectl reference HTML page and assets to `<web-base>`.
-->
`copycli` 命令将清理暂存目录，生成 kubectl 命令集文件，并将整理后的 kubectl 参考 HTML 页面和文件复制到 `<web-base>`。
<!--
## Locate the generated files
-->
## 找到生成的文件
<!--
Verify that these two files have been generated:
-->
验证是否已生成以下两个文件：
```shell
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
<!--
## Locate the copied files
-->
## 找到复制的文件
<!--
Verify that all generated files have been copied to your `<web-base>`:
-->
确认所有生成的文件都已复制到您的 `<web-base>`：
```shell
cd <web-base>
git status
```
<!--
The output should include the modified files:
-->
输出应包括修改后的文件：
```
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
```
<!--
Additionally, the output might show the modified files:
-->
此外，输出可能显示修改后的文件：
```
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css
```
<!--
## Locally test the documentation
-->
## 在本地测试文档
<!--
Build the Kubernetes documentation in your local `<web-base>`.
-->
在本地 `<web-base>` 中构建 Kubernetes 文档。
```shell
cd <web-base>
make docker-serve
```
<!--
View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
-->
查看[本地预览](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/)。
<!--
## Adding and committing changes in kubernetes/website
-->
## 在 kubernetes/website 中添加和提交更改
<!--
Run `git add` and `git commit` to commit the files.
-->
运行 `git add` 和 `git commit` 提交修改文件。
<!--
## Creating a pull request
-->
## 创建 PR
<!--
Create a pull request to the `kubernetes/website` repository. Monitor your
pull request, and respond to review comments as needed. Continue to monitor
your pull request until it is merged.
-->
对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。
<!--
A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home).
-->
在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
-->
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/)
* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/)
* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/)
{{% /capture %}}
content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md
+364
View File
@@ -0,0 +1,364 @@
---
title: 为 Kubernetes API 生成参考文档
content_template: templates/task
---
<!--
---
title: Generating Reference Documentation for the Kubernetes API
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to update the generated reference docs for the Kubernetes API.
The Kubernetes API reference documentation is built from the
[Kubernetes OpenAPI spec](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)
and tools from [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs).
If you find bugs in the generated documentation, you need to
[fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/).
If you need only to regenerate the reference documentation from the [OpenAPI](https://github.com/OAI/OpenAPI-Specification)
spec, continue reading this page.
-->
本页面展示了如何为 Kubernetes API 更新自动生成的参考文档。
Kubernetes API 参考文档是从 [Kubernetes OpenAPI 规范](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)构建的，而工具是从 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 构建的。
如果您在生成的文档中发现错误，则需要[将其上游修复](/docs/contribute/generate-ref-docs/contribute-upstream/)。
如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页面。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
You need to have these tools installed:
-->
你需要安装以下软件：
<!--
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* [Golang](https://golang.org/doc/install) version 1.9.1 or later
-->
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install)
<!--
You need to know how to create a pull request (PR) to a GitHub repository.
Typically, this involves creating a fork of the repository. For more
information, see
[Creating a Documentation Pull Request](/docs/contribute/start/) and
[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
-->
你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的 fork 分支。想了解更多信息，请参见[创建一个文档 PR](/docs/contribute/start/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。
{{% /capture %}}
{{% capture steps %}}
<!--
## Setting up the local repositories
-->
## 设置本地仓库
<!--
Create a local workspace and set your `GOPATH`.
-->
创建本地工作区并设置您的 `GOPATH`。
```shell
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
<!--
Get a local clone of the following repositories:
-->
获取以下仓库的本地克隆：
```shell
go get -u github.com/kubernetes-incubator/reference-docs
go get -u github.com/go-openapi/loads
go get -u github.com/go-openapi/spec
```
<!--
If you don't already have the kubernetes/website repository, get it now: -->
如果您还没有下载过 `kubernetes/website` 仓库，现在下载：
```shell
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
<!--
Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes:
-->
克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes：
```shell
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
<!--
* The base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository is
`$GOPATH/src/k8s.io/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
* The base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository is
`$GOPATH/src/github.com/<your username>/website.`
The remaining steps refer to your base directory as `<web-base>`.
* The base directory of your clone of the
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs)
repository is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.`
The remaining steps refer to your base directory as `<rdocs-base>`.
-->
* [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库克隆后的基本目录为 `$GOPATH/src/k8s.io/kubernetes`。
其余后续步骤将您的基本目录称为 `<k8s-base>`。
* [kubernetes/website](https://github.com/kubernetes/website) 仓库克隆后的基本目录为 `$GOPATH/src/github.com/<your username>/website`。
其余后续步骤将您的基本目录称为 `<web-base>`。
* [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库克隆后的基本目录为 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。
其余后续步骤将您的基本目录称为 `<rdocs-base>`。
<!--
## Generating the API reference docs
-->
## 生成 API 参考文档
<!--
This section shows how to generate the
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-->
本节说明如何生成[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
<!--
### Modifying the Makefile
-->
### 修改 Makefile 文件
<!--
Go to `<rdocs-base>`, and open the `Makefile` for editing:
-->
进入 `<rdocs-base>` 目录，然后编辑 `Makefile` 文件：
<!--
* Set `K8SROOT` to `<k8s-base>`.
* Set `WEBROOT` to `<web-base>`.
* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
-->
* 设置 `K8SROOT` 为 `<k8s-base>`.
* 设置 `WEBROOT` 为 `<web-base>`.
* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。
<!--
For example, update the following variables:
-->
例如，更新以下变量：
```
WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
MINOR_VERSION=15
```
<!--
### Copying the OpenAPI spec
-->
### 复制 OpenAPI 规范
<!--
Run the following command in `<rdocs-base>`:
-->
在 `<rdocs-base>` 目录中运行以下命令：
```shell
make updateapispec
```
<!--
The output shows that the file was copied:
-->
输出显示文件已被复制：
```shell
cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json
```
<!--
### Building the API reference docs
-->
### 构建 API 参考文档
<!--
Run the following command in `<rdocs-base>`:
-->
在 `<rdocs-base>` 目录中运行以下命令：
```shell
make api
```
<!--
Verify that these two files have been generated:
-->
验证是否已生成这两个文件：
```shell
[ -e "<rdocs-base>/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
<!--
### Creating directories for published docs
-->
### 创建发布文档的目录
<!--
Create the directories in `<web-base>` for the generated API reference files:
-->
在 `<web-base>` 目录中为生成的 API 参考文件创建目录：
```shell
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/css
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/fonts
```
<!--
## Copying the generated docs to the kubernetes/website repository
-->
## 将生成的文档复制到 kubernetes/website 仓库
<!--
Run the following command in `<rdocs-base>` to copy the generated files to
your local kubernetes/website repository:
-->
在 `<rdocs-base>` 目录中运行以下命令，将生成的文件复制到本地 kubernetes/website 仓库。
```shell
make copyapi
```
<!--
Go to the base of your local kubernetes/website repository, and
see which files have been modified:
-->
进入 kubernetes/website 仓库的本地主目录，并查看已修改的文件：
```shell
cd <web-base>
git status
```
<!--
The output shows the modified files:
-->
输出显示修改后的文件：
```
static/docs/reference/generated/kubernetes-api/v1.15/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.15/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.15/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.15/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.15/index.html
static/docs/reference/generated/kubernetes-api/v1.15/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.15/navData.js
static/docs/reference/generated/kubernetes-api/v1.15/scroll.js
```
<!--
## Updating the API reference index pages
-->
## 更新 API 参考索引页面
<!--
* Open `<web-base>/content/en/docs/reference/kubernetes-api/index.md` for editing, and update the API reference
version number. For example:
-->
* 打开 `<web-base>/content/en/docs/reference/kubernetes-api/index.md` 文件进行编辑，并且更新 API 参考版本号。例如：
```
---
title: v1.15
---
[Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/)
```
<!--
* Open `<web-base>/content/en/docs/reference/_index.md` for editing, and add a
new link for the latest API reference. Remove the oldest API reference version.
There should be five links to the most recent API references.
-->
* 打开 `<web-base>/content/en/docs/reference/_index.md` 文件进行编辑，并添加新链接以获取最新的 API 参考。移除最旧的 API 参考版本。应该有五个指向最新 API 参考的链接。
<!--
## Locally test the API reference
-->
## 在本地测试 API 参考
<!--
Publish a local version of the API reference.
Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/).
-->
发布 API 参考的本地版本。
验证 [本地预览](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/)。
```shell
cd <web-base>
make docker-serve
```
<!--
## Commit the changes
-->
## 提交更改
<!--
In `<web-base>` run `git add` and `git commit` to commit the change. -->
在 `<web-base>` 中运行 `git add` 和 `git commit` 来提交更改。
<!--
Submit your changes as a
[pull request](/docs/contribute/start/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-->
将您的更改[创建 PR](/docs/contribute/start/) 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
-->
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/)
* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/)
* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/)
{{% /capture %}}
content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md
+412
View File
@@ -0,0 +1,412 @@
---
title: 为 Kubernetes 组件和工具生成参考页面
content_template: templates/task
---
<!--
---
title: Generating Reference Pages for Kubernetes Components and Tools
content_template: templates/task
---
-->
{{% capture overview %}}
<!--
This page shows how to use the `update-imported-docs` tool to generate
reference documentation for tools and components in the
[Kubernetes](https://github.com/kubernetes/kubernetes) and
[Federation](https://github.com/kubernetes/federation) repositories.
-->
本页面展示了如何使用 `update-imported-docs` 工具来为 [Kubernetes](https://github.com/kubernetes/kubernetes) 和 [Federation](https://github.com/kubernetes/federation) 仓库中的工具和组件生成参考文档。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
* You need a machine that is running Linux or macOS.
-->
* 你需要一个运行着 Linux 或 macOS 操作系统的机器。
<!--
* You need to have this software installed:
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* [Golang](https://golang.org/doc/install) version 1.9 or later
* [make](https://www.gnu.org/software/make/)
* [gcc compiler/linker](https://gcc.gnu.org/)
-->
* 你需要安装以下软件：
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* 1.9或更高版本的 [Golang](https://golang.org/doc/install)
* [make](https://www.gnu.org/software/make/)
* [gcc compiler/linker](https://gcc.gnu.org/)
<!--
* Your `$GOPATH` environment variable must be set.
-->
* 在环境变量中设置 `$GOPATH`。
<!--
* You need to know how to create a pull request to a GitHub repository.
Typically, this involves creating a fork of the repository. For more
information, see
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
-->
* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/)。
{{% /capture %}}
{{% capture steps %}}
<!--
## Getting two repositories
-->
## 下载两个仓库
<!--
If you don't already have the `kubernetes/website` repository, get it now:
-->
如果你还没有下载过 `kubernetes/website` 仓库，现在下载：
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/website
```
<!--
Determine the base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository.
For example, if you followed the preceding step to get the repository,
your base directory is `$GOPATH/src/github.com/kubernetes/website.`
The remaining steps refer to your base directory as `<web-base>`.
-->
确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 `<web-base>`。
<!--
If you plan on making changes to the ref docs, and if you don't already have
the `kubernetes/kubernetes` repository, get it now:
-->
如果你想对参考文档进行修改，但是你还没下载过 `kubernetes/kubernetes` 仓库，现在下载：
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
```
<!--
Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository,
your base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
-->
确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 `<k8s-base>`。
{{< note >}}
<!--
If you only need to generate, but not change, the reference docs, you don't need to
manually get the `kubernetes/kubernetes` repository. When you run the `update-imported-docs`
tool, it automatically clones the `kubernetes/kubernetes` repository.
-->
如果你只想生成参考文档，而不需要修改，则不需要手动下载 `kubernetes/kubernetes` 仓库。当你运行 `update-imported-docs` 工具时，它会自动克隆 `kubernetes/kubernetes` 仓库。
{{< /note >}}
<!--
## Editing the Kubernetes source code
-->
## 编辑 Kubernetes 源码
<!--
The reference documentation for the Kubernetes components and tools is automatically
generated from the Kubernetes source code. If you want to change the reference documentation,
the first step is to change one or more comments in the Kubernetes source code. Make the
change in your local kubernetes/kubernetes repository, and then submit a pull request to
the master branch of
[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
-->
Kubernetes 组件和工具的参考文档是基于 Kubernetes 源码自动生成的。如果想要修改参考文档，可以从修改 Kubernetes 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。
<!--
[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942)
is an example of a pull request that makes changes to comments in the Kubernetes
source code.
-->
[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942) 是一个对 Kubernetes 源码中的注释进行修改的 PR 示例。
<!--
Monitor your pull request, and respond to reviewer comments. Continue to monitor
your pull request until it is merged into the master branch of the
`kubernetes/kubernetes` repository.
-->
跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 `kubernetes/kubernetes` 仓库的 master 分支中。
<!--
## Cherry picking your change into a release branch
-->
## 以 cherry-pick 方式将你的修改合入已发布分支
<!--
Your change is now in the master branch, which is used for development of the next
Kubernetes release. If you want your change to appear in the docs for a Kubernetes
version that has already been released, you need to propose that your change be cherry
picked into the release branch.
-->
你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。
<!--
For example, suppose the master branch is being used to develop Kubernetes 1.10, and
you want to backport your change to the release-1.9 branch. For instructions on how
to do this, see
[Propose a Cherry Pick](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md).
-->
例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.9 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。
<!--
Monitor your cherry-pick pull request until it is merged into the release branch.
-->
跟踪你的 cherry-pick PR，直到它合入到已发布分支中。
{{< note >}}
<!--
Proposing a cherry pick requires that you have permission to set a label
and a milestone in your pull request. If you don’t have those permissions, you will
need to work with someone who can set the label and milestone for you.
-->
提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。
{{< /note >}}
<!--
## Overview of update-imported-docs
-->
## update-imported-docs 概述
<!--
The `update-imported-docs` tool is located in the `kubernetes/website/update-imported-docs/`
directory. The tool performs the following steps:
-->
`update-imported-docs` 工具在 `kubernetes/website/update-imported-docs/` 目录下。它执行以下步骤：
<!--
1. Clones the related repositories specified in a configuration file. For the
purpose of generating reference docs, the repositories that are cloned by
default are `kubernetes-incubator/reference-docs` and `kubernetes/federation`.
1. Runs commands under the cloned repositories to prepare the docs generator and
then generates the Markdown files.
1. Copies the generated Markdown files to a local clone of the `kubernetes/website`
repository under locations specified in the configuration file.
-->
1. 克隆配置文件中指定的相关仓库。为了生成参考文档，默认情况下克隆的仓库是 `kubernetes-incubator/reference-docs` 和 `kubernetes/federation`。
1. 在克隆出的仓库下运行命令来准备文档生成器，然后生成 Markdown 文件。
1. 将生成的 Markdown 文件复制到配置文件中指定的 `kubernetes/website` 仓库的本地目录中。
<!--
When the Markdown files are in your local clone of the `kubernetes/website`
repository, you can submit them in a
[pull request](/docs/home/contribute/create-pull-request/)
to `kubernetes/website`.
-->
当 Markdown 文件放入 `kubernetes/website` 仓库的本地目录中后，你就可以创建 [PR](/docs/home/contribute/create-pull-request/) 将它们提交到 `kubernetes/website`。
<!--
## Customizing the config file
-->
## 自定义配置文件
<!--
Open `<web-base>/update-imported-docs/reference.yml` for editing.
Do not change the content for the `generate-command` entry unless you understand
what it is doing and need to change the specified release branch.
-->
打开 `<web-base>/update-imported-docs/reference.yml` 进行编辑。不要修改 `generate-command` 条目的内容，除非你了解它的作用，并且需要修改指定的已发布分支。
```shell
repos:
- name: reference-docs
remote: https://github.com/kubernetes-incubator/reference-docs.git
# This and the generate-command below needs a change when reference-docs has
# branches properly defined
branch: master
generate-command: |
cd $GOPATH
git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes
cd src/k8s.io/kubernetes
git checkout release-1.11
make generated_files
cp -L -R vendor $GOPATH/src
rm -r vendor
cd $GOPATH
go get -v github.com/kubernetes-incubator/reference-docs/gen-compdocs
cd src/github.com/kubernetes-incubator/reference-docs/
make comp
```
<!--
In reference.yml, the `files` field is a list of `src` and `dst` fields. The `src` field
specifies the location of a generated Markdown file, and the `dst` field specifies
where to copy this file in the cloned `kubernetes/website` repository.
For example:
-->
在 reference.yml 中，`files` 字段是 `src` 和 `dst` 字段的列表。`src` 字段指定生成的 Markdown 文件的位置，而 `dst` 字段指定将此文件复制到 `kubernetes/website` 仓库的本地目录的哪个位置。例如：
```yaml
repos:
- name: reference-docs
remote: https://github.com/kubernetes-incubator/reference-docs.git
files:
- src: gen-compdocs/build/kube-apiserver.md
dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
...
```
<!--
Note that when there are many files to be copied from the same source directory
to the same destination directory, you can use wildcards in the value given to
`src` and you can just provide the directory name as the value for `dst`.
For example:
-->
注意，当有许多文件要从同一个源目录复制到同一个目标目录时，可以使用通配符给 `src` 赋值，而使用目录名给 `dst` 赋值。例如：
```shell
files:
- src: gen-compdocs/build/kubeadm*.md
dst: content/en/docs/reference/setup-tools/kubeadm/generated/
```
<!--
## Running the update-imported-docs tool
-->
## 运行 update-imported-docs 工具
<!--
After having reviewed and/or customized the `reference.yaml` file, you can run
the `update-imported-docs` tool:
-->
在检查与或自定义 `reference.yaml` 文件后，运行 `update-imported-docs` 工具：
```shell
cd <web-base>/update-imported-docs
./update-imported-docs reference.yml
```
<!--
## Adding and committing changes in kubernetes/website
-->
## 在 kubernetes/website 中添加和提交修改
<!--
List the files that were generated and copied to the `kubernetes/website`
repository:
-->
列出生成并准备合入到 `kubernetes/website` 仓库中的文件：
```
cd <web-base>
git status
```
<!--
The output shows the new and modified files. For example, the output
might look like this:
-->
输出展示了新增和修改的文件。例如，输出可能如下所示：
```shell
...
modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
modified: content/en/docs/reference/command-line-tools-reference/federation-apiserver.md
modified: content/en/docs/reference/command-line-tools-reference/federation-controller-manager.md
modified: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
modified: content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
modified: content/en/docs/reference/command-line-tools-reference/kube-proxy.md
modified: content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
...
```
<!--
Run `git add` and `git commit` to commit the files.
-->
运行 `git add` 和 `git commit` 将提交上述文件。
<!--
## Creating a pull request
-->
## 创建 PR
<!--
Create a pull request to the `kubernetes/website` repository. Monitor your
pull request, and respond to review comments as needed. Continue to monitor
your pull request until it is merged.
-->
对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。
<!--
A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home/).
-->
在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
-->
* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/)
* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/)
* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/)
{{% /capture %}}
content/zh/docs/contribute/intermediate.md
+1449
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/contribute/localization.md
+559
View File
@@ -0,0 +1,559 @@
---
title: 本地化 Kubernetes 文档
content_template: templates/concept
card:
name: contribute
weight: 30
title: 翻译文档
---
<!--
---
title: Localizing Kubernetes Documentation
content_template: templates/concept
approvers:
- remyleone
- rlenferink
- zacharysarah
card:
name: contribute
weight: 30
title: Translating the docs
---
-->
{{% capture overview %}}
<!--
This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language.
-->
此页面显示了如何为其他语言的文档提供[本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)。
{{% /capture %}}
{{% capture body %}}
<!--
## Getting started
Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization.
All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you.
-->
## 入门
由于贡献者无法批准他们自己的请求，因此您至少需要两个贡献者才能开始本地化。
所有本地化团队必须使用自身的资源独立工作。我们很高兴支持你的工作，但无法为你翻译。
<!--
### Find your two-letter language code
First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your localization's two-letter country code. For example, the two-letter code for Korean is `ko`.
### Fork and clone the repo
First, [create your own fork](/docs/contribute/start/#improve-existing-content) of the [kubernetes/website](https://github.com/kubernetes/website) repository.
-->
### 找到两个字母的语言代码
首先，有关本地化的两个字母的国家代码，请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。例如，韩国的两个字母代码是 `ko`。
### fork 并且克隆仓库 {#fork-and-clone-the-repo}
首先，在 [kubernetes/website](https://github.com/kubernetes/website) 仓库中的 [fork 你自己的分支](/docs/contribute/start/#improve-existing-content)。
<!--
Then, clone your fork and `cd` into it:
-->
然后，克隆 website 仓库并通过 `cd` 命令进入 website 目录：
```shell
git clone https://github.com/<username>/website
cd website
```
<!--
### Open a pull request
Next, [open a pull request](https://kubernetes.io/docs/contribute/start/#submit-a-pull-request) (PR) to add a localization to the `kubernetes/website` repository.
The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved.
For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548).
-->
### 发起 pr
接下来，[提交 PR 请求](https://kubernetes.io/docs/contribute/start/#submit-a-pull-request)，将本地化添加到 `kubernetes/website` 仓库。
PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。
有关添加新本地化的示例，请参见添加[法语文档]（https://github.com/kubernetes/website/pull/12548） 的 PR。
### Join the Kubernetes GitHub organization
<!--
Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository.
-->
提交本地化 PR 后，您可以成为 Kubernetes GitHub 组织的成员。团队中的每个人都需要在 `kubernetes/org` 仓库中创建自己的[组织成员资格申请](https://github.com/kubernetes/org/issues/new/choose)。
<!--
### Add your localization team in GitHub
Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685).
Members of `sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`.
The `sig-docs-**-reviews` team automates review assignment for new PRs.
-->
### 在 GitHub 中添加您的本地化团队
接下来，将您的 Kubernetes 本地化团队添加到[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)。有关添加本地化团队的示例，请参见添加[西班牙本地化团队](https://github.com/kubernetes/org/pull/685) 的 PR。
`sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。
`sig-docs-**-reviews` 团队自动分派新 PR 的审阅任务。
<!--
Members of `sig-docs-l10n-admins` can create new development branches to coordinate translation efforts.
Members of `website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs.
-->
`sig-docs-l10n-admins` 成员可以创建新的开发分支来协调翻译工作。
`website-milestone-maintainers` 成员可以使用 `/milestone` [Prow 命令](https://prow.k8s.io/command-help) 为 issues 或 PR 设定里程碑。
<!--
### Configure the workflow
Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label lets you filter issues and pull requests for your specific language.
For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316).
-->
### 配置工作流程
接下来，在 `kubernetes/test-infra` 仓库中为您的本地化添加一个 GitHub 标签。标签可让您过滤 issues 并提出针对特定语言的 pr。
有关添加标签的示例，请参见添加[意大利语标签](https://github.com/kubernetes/test-infra/pull/11316)的 PR。
<!--
### Find community
Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have.
You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605).
-->
### 寻找社区
让 Kubernetes SIG Docs 知道您对创建本地化感兴趣！ 加入[SIG Docs Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)。其他本地化团队很乐意帮助您入门并回答您的任何问题。
您还可以在 `kubernetes/community` 存储库中为本地化创建一个 Slack 频道。有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。
<!--
## Minimum required content
### Modify the site configuration
The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml) file. To support a new localization, you'll need to modify `config.toml`.
Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. The German block, for example, looks like:
-->
## 最低要求内容 {#minimum-required-content}
### 修改站点配置
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)文件中。为了支持新的本地化，您需要修改 `config.toml`。
在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。例如，下面是德语的配置示例：
```toml
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
contentDir = "content/de"
weight = 3
```
<!--
When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value.
For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".
-->
为您的块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。
有关 Hugo 多语言支持的更多信息，请参阅"[多语言模式](https://gohugo.io/content-management/multilingual/)"。
<!--
### Add a new localization directory
Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/master/content) folder in the repository. For example, the two-letter code for German is `de`:
-->
### 添加一个新的本地化目录
将特定语言的子目录添加到仓库中的 [`content`](https://github.com/kubernetes/website/tree/master/content) 文件夹下。例如，德语的两个字母的代码是 `de`：
```shell
mkdir content/de
```
<!--
### Localize the Community Code of Conduct
Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language.
### Add a localized README
-->
### 本地化社区行为准则
针对 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) 仓库提交 PR，添加您所用语言版本的行为准则。
### 添加本地化的 README 文件
<!--
To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`.
Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as:
- A point of contact for the localization project
- Any information specific to the localization
-->
为了指导其他本地化贡献者，请在 k/website 的根目录添加一个新的 [`README-**.md`](https://help.github.com/articles/about-readmes/)，其中 `**` 是两个字母的语言代码。例如，德语 README 文件为 `README-de.md`。
在本地化的 `README-**.md` 文件中为本地化贡献者提供指导。包含 `README.md` 中包含的相同信息，以及：
- 本地化项目的联系人
- 任何有关本地化的信息
<!--
After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct.
-->
创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接，并给出英文形式的联系信息。您可以提供 GitHub ID、电子邮件地址、[Slack 频道](https://slack.com/)或其他联系方式。您还必须提供指向本地化的社区行为准则的链接。
<!--
### Setting up the OWNERS files
To set the roles of each user contributing to the localization, create an `OWNERS` file inside the language-specific subdirectory with:
- **reviewers**: A list of kubernetes teams with reviewer roles, in this case, the `sig-docs-**-reviews` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github).
- **approvers**: A list of kubernetes teams with approvers roles, in this case, the `sig-docs-**-owners` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github).
- **labels**: A list of GitHub labels to automatically apply to a PR, in this case, the language label created in [Configure the workflow](#configure-the-workflow).
-->
### 设置 OWNERS 文件
要设置每个对本地化做出贡献用户的角色，请在特定于语言的子目录内创建一个 `OWNERS` 文件，其中：
- **reviewers**: 具有 reviewer 角色的 kubernetes 团队的列表，在本例中为在[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中创建的 `sig-docs-**-reviews` 团队。
- **approvers**: 具有 approver 角色的 kubernetes 团队的列表，在本例中为在[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中创建的 `sig-docs-**-owners` 团队。
- **labels**: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为[配置工作流程](#configure-the-workflow)中创建的语言标签。
<!--
More information about the `OWNERS` file can be found at [go.k8s.io/owners](https://go.k8s.io/owners).
The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), with language code `es`, looks like:
-->
有关 `OWNERS` 文件的更多信息，请访问[go.k8s.io/owners](https://go.k8s.io/owners)。
带有语言代码 `es` 的[西班牙 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像：
<!--
```yaml
# See the OWNERS docs at https://go.k8s.io/owners
# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
reviewers:
- sig-docs-es-reviews
approvers:
- sig-docs-es-owners
labels:
- language/es
```
-->
```yaml
# 在 https://go.k8s.io/owners 地址查看 OWNERS 文档
# 这是西班牙语的本地化项目。
# 团队和成员位于 https://github.com/orgs/kubernetes/teams。
reviewers:
- sig-docs-es-reviews
approvers:
- sig-docs-es-owners
labels:
- language/es
```
<!--
After adding the language-specific `OWNERS` file, update the [root `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`.
For each team, add the list of GitHub users requested in [Add your localization team in GitHub](#add-your-localization-team-in-github), in alphabetical order.
-->
添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 团队更新 [根目录下的 OWNERS_ALIAES](https://git.k8s.io/website/OWNERS_ALIASES) 文件进行本地化，即 `sig-docs-**-owners` 和 `sig-docs-**-reviews`。
对于每个团队，请按字母顺序添加[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中请求的 GitHub 用户列表。
```diff
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
- stewart-yu
- xiangpengzhao
- zhangxiaoyu-zidif
+ sig-docs-es-owners: # Admins for Spanish content
+ - alexbrand
+ - raelga
+ sig-docs-es-reviews: # PR reviews for Spanish content
+ - alexbrand
+ - electrocucaracha
+ - glo-pena
+ - raelga
sig-docs-fr-owners: # Admins for French content
- perriea
- remyleone
```
<!--
## Translating content
Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and expand over time.
At a minimum, all localizations must include:
-->
## 翻译文档
本地化*所有* Kubernetes 文档是一项艰巨的任务。从小做起，循序渐进。
所有本地化至少必须包括：
<!--
Description | URLs
-----|-----
Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
-->
描述 | 网址
-----|-----
主页 | [所有标题和副标题网址](/docs/home/)
安装 | [所有标题和副标题网址](/docs/setup/)
教程 | [Kubernetes 基础](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
网站字符串 | [新的本地化 TOML 文件中的所有网站字符串](https://github.com/kubernetes/website/tree/master/i18n)
<!--
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
-->
翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。例如，要准备将 [Kubernetes 基础](/docs/tutorials/kubernetes-basics/) 教程翻译为德语，请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源：
```shell
mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
```
<!--
Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text.
-->
翻译工具可以加快翻译过程。例如，某些编辑器提供了用于快速翻译文本的插件。
<!--
Machine-generated translation alone does not meet the minimum standard of quality and requires extensive human review to meet that standard.
-->
{{< caution >}}
机器生成的翻译不能达到最低质量标准，需要进行大量人工审查才能达到该标准。
{{< /caution >}}
<!--
To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing.
-->
为了确保语法和含义的准确性，本地化团队的成员应在发布之前仔细检查所有由机器生成的翻译。
<!--
### Source files
Localizations must be based on the English files from the most recent release, {{< latest-version >}}.
To find source files for the most recent release:
1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website.
2. Select the `release-1.X` branch for the most recent version.
The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}).
-->
### 源文件
本地化必须基于最新版本 {{< latest-version >}} 中的英文文件。
要查找最新版本的源文件：
1. 导航到 Kubernetes website 仓库，网址为 https://github.com/kubernetes/website。
2. 选择最新版本的 `release-1.X` 分支。
最新版本是 {{< latest-version >}}，所以最新的发行分支是 [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。
<!--
### Site strings in i18n/
-->
### i18n/ 中的网站字符串
<!--
Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`.
-->
本地化必须在新的语言特定文件中包含 [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) 的内容。以德语为例：`i18n/de.toml`。
<!--
Add a new localization file to `i18n/`. For example, with German (`de`):
-->
将新的本地化文件添加到 `i18n/`。例如德语 (`de`)：
```shell
cp i18n/en.toml i18n/de.toml
```
<!--
Then translate the value of each string:
-->
然后翻译每个字符串的值：
```TOML
[docs_label_i_am]
other = "ICH BIN..."
```
<!--
Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page.
-->
本地化网站字符串允许你自定义网站范围的文本和特性：例如，每个页面页脚中的合法版权文本。
<!--
### Language specific style guide and glossary
Some language teams have their own language-specific style guide and glossary. For example, see the [Korean Localization Guide](/ko/docs/contribute/localization_ko/).
-->
### 特定语言的样式指南和词汇表
一些语言团队有自己的特定语言风格指南和词汇表。例如，请参见[韩语本地化指南](/ko/docs/contribute/localization_ko/)。
<!--
## Branching strategy
-->
### 分支策略
<!--
Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches.
-->
因为本地化项目是高度协同的工作，所以我们鼓励团队基于共享的开发分支工作。
<!--
To collaborate on a development branch:
-->
在开发分支上协作：
<!--
1. A team member of [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) opens a development branch from a source branch on https://github.com/kubernetes/website.
Your team approvers joined the `sig-docs-l10n-admins` team when you [added your localization team](#add-your-localization-team-in-github) to the `kubernetes/org` repository.
We recommend the following branch naming scheme:
`dev-<source version>-<language code>.<team milestone>`
For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12.
-->
1. [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) 中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个开发分支。
当您给 `kubernetes/org` 存储库[添加您的本地化团队](#add-your-localization-team-in-github)时，您的团队 approvers 便加入了 `sig-docs-l10n-admins`。
我们推荐以下分支命名方案：
`dev-<source version>-<language code>.<team milestone>`
例如，一个德语本地化团队的 approvers 基于 Kubernetes v1.12 版本的源分支直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。
<!--
2. Individual contributors open feature branches based on the development branch.
For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`.
3. Approvers review and merge feature branches into the development branch.
4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request.
-->
2. 个人贡献者基于开发分支新建特性分支。
例如，一个德国贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。
3. Approvers 审查功能分支并将其合并到开发分支中。
4. approver 会定期打开并批准新的 pr，将开发分支合并到其源分支。在批准 pr 之前，请确保先 squash 提交。
<!--
Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc.
-->
根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语开发分支将是：`dev-1.12-de.2`、`dev-1.12-de.3`，等等。
<!--
Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}.
-->
团队必须将本地化内容合入到发布分支中，该发布分支也正是内容的来源。例如，源于 {{< release-branch >}} 的开发分支必须基于 {{< release-branch >}}。
<!--
An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
-->
approver 必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。开发分支的存在时间越长，通常需要的维护工作就越多。考虑定期合并开发分支并新建分支，而不是维护一个持续时间很长的开发分支。
<!--
At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch.
-->
在每个团队里程碑的起点，打开一个 issue 来比较先前的开发分支和当前的开发分支之间的上游变化很有帮助。
<!--
While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
-->
虽然只有 approver 才能开启新的开发分支并合并 pr，但任何人都可以为新的开发分支提交一个拉取请求（PR）。不需要特殊权限。
<!--
For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo).
-->
有关基于 fork 或直接从仓库开展工作的更多信息，请参见 ["fork 和克隆"](#fork-and-clone-the-repo)。
<!--
## Upstream contributions
-->
### 上游贡献
<!--
SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source.
-->
Sig Docs 欢迎[上游贡献和修正](/docs/contribute/intermediate#localize-content) 到英文原文。
<!--
## Help an existing localization
-->
## 帮助现有的本地化
<!--
You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help.
-->
您还可以向现有本地化添加或改进内容提供帮助。加入 [Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)进行本地化，然后开始新建 PR 来提供帮助。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
Once a localization meets requirements for workflow and minimum output, SIG docs will:
-->
本地化满足工作流程和最低输出要求后，SIG 文档将：
<!--
- Enable language selection on the website
- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
-->
- 在网站上启用语言选择
- 通过[Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) 频道, 包括[ Kubernetes 博客](https://kubernetes.io/blog/)公开本地化的可用性。
{{% /capture %}}
content/zh/docs/contribute/participating.md
+532
View File
@@ -0,0 +1,532 @@
---
title: 参与 SIG Docs
content_template: templates/concept
card:
name: contribute
weight: 40
---
{{% capture overview %}}
<!--
SIG Docs is one of the
[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
within the Kubernetes project, focused on writing, updating, and maintaining
the documentation for Kubernetes as a whole. See
[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
for more information about the SIG.
-->
SIG Docs 是 Kubernetes 项目中的一个 [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)，
总的来说，它负责编写、更新和维护 Kubernetes 文档。
<!--
SIG Docs welcomes content and reviews from all contributors. Anyone can open a
pull request (PR), and anyone is welcome to file issues about content or comment
on pull requests in progress.
-->
SIG Docs 欢迎所有贡献者提供内容和检视。任何人可以提交拉取请求（PR），
欢迎对文档内容提交 issue 和 对正在进行中的 PR 进行评论。
<!--
Within SIG Docs, you may also become a [member](#members),
[reviewer](#reviewers), or [approver](#approvers). These roles require greater
access and entail certain responsibilities for approving and committing changes.
See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for more information on how membership works within the Kubernetes community.
The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
-->
在 SIG Docs，你可以成为 [member](#members)、[reviewer](#reviewers) 或者 [approver](#approvers)。
这些角色拥有更高的权限，并且需要承担批准和提交更改的责任。
有关 Kubernetes 社区中的成员如何工作的更多信息，请参见 [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)。
本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式，
SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。
{{% /capture %}}
{{% capture body %}}
<!--
## Roles and responsibilities
-->
## 角色和责任
<!--
When a pull request is merged to the branch used to publish content (currently
`master`), that content is published and available to the world. To ensure that
the quality of our published content is high, we limit merging pull requests to
SIG Docs approvers. Here's how it works.
-->
当一个 pull 请求被合并到用于发布内容的分支(当前为“master”)，该内容将发布并向全世界开放。
为了确保发布内容的质量较高，每个 pull 请求需要 SIG Docs 的 approver 审批。
它是这样工作的。
<!--
- When a pull request has both the `lgtm` and `approve` labels and has no `hold`
labels, the pull request merges automatically.
- Kubernetes organization members and SIG Docs approvers can add comments to
prevent automatic merging of a given pull request (by adding a `/hold` comment
or withholding a `/lgtm` comment).
- Any Kubernetes member can add the `lgtm` label, by adding a `/lgtm` comment.
- Only an approver who is a member of SIG Docs can cause a pull request to merge
by adding an `/approve` comment. Some approvers also perform additional
specific roles, such as [PR Wrangler](#pr-wrangler) or
[SIG Docs chairperson](#sig-docs-chairperson).
-->
- 当某个 pull request 拥有 `lgtm` 和 `approve` 标签， 并且没有 `hold` 标签时，这个 pull request 会自动合入。
- Kubernetes 组织成员 和 SIG Docs 的 approvers 可以通过评论的方式阻止某个 pull request 自动合入（评论中包含 `/hold` 或 取消 `/lgtm` 的内容）。
- 任何 Kubernetes 成员都可以通过在评论回复 `/lgtm` 来增加 `/lgtm` 标签。
- 只有 SIG Docs 的 approver 可以在评论中回复 `/approve` 并触发合并。
某些 approver 还兼具其他角色，比如 [PR Wrangler](#pr-wrangler) 或 [SIG Docs chairperson](#sig-docs-chairperson)。
<!--
For more information about expectations and differences between the roles of
Kubernetes organization member and SIG Docs approvers, see
[Types of contributor](/docs/contribute#types-of-contributor). The following
sections cover more details about these roles and how they work within
SIG Docs.
-->
关于 Kubernetes 组织成员和 SIG Docs approver 的区别，请参考 [Types of contributor](/docs/contribute#types-of-contributor)。
以下部分将详细介绍这些角色及其内部的工作方式。
### Anyone
<!--
Anyone can file an issue against any part of Kubernetes, including documentation.
-->
任何人可以针对 Kubernetes 的任何内容（包括文档）提交 issue。
<!--
Anyone who has signed the CLA can submit a pull request. If you cannot sign the
CLA, the Kubernetes project cannot accept your contribution.
-->
任何人想到提交 pull request，必须要签署 CLA。 否则 Kubernetes 项目则不能接受你的贡献。
### Members
<!--
Any member of the [Kubernetes organization](https://github.com/kubernetes) can
review a pull request, and SIG Docs team members frequently request reviews from
members of other SIGs for technical accuracy.
SIG Docs also welcomes reviews and feedback regardless of a person's membership
status in the Kubernetes organization. You can indicate your approval by adding
a comment of `/lgtm` to a pull request. If you are not a member of the
Kubernetes organization, your `/lgtm` has no effect on automated systems.
-->
任何 [Kubernetes 组织成员](https://github.com/kubernetes) 都可以检视 pull request。
SIG Docs 组成员经常需要检视来自其他 SIG 的 pull request，以确保技术上的准确性。
<!--
Any member of the Kubernetes organization can add a `/hold` comment to prevent
the pull request from being merged. Any member can also remove a `/hold` comment
to cause a PR to be merged if it already has both `/lgtm` and `/approve` applied
by appropriate people.
-->
作何 Kubernetes 组织成员都可以在评论中增加 `/hold` 标签来阻止 PR 被合入。
任何 Kubernetes 组织成员都可以移除 `/hold` 标签来让PR 合入（必须此前已有 `/lgtm` 和 `/approve` 标签）。
<!--
#### Becoming a member
-->
#### 成为一个 member
<!--
After you have successfully submitted at least 5 substantive pull requests, you
can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
in the Kubernetes organization. Follow these steps:
-->
在你成功的提交至少 5 个PR后，你就可以向 Kubernetes 组织提交申请 [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)。
按照如下流程：
<!--
1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor)
your membership.
Ask for sponsorship in the [#sig-docs channel on the
Kubernetes Slack instance](https://kubernetes.slack.com) or on the
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
{{< note >}}
Don't send a direct email or Slack direct message to an individual
SIG Docs member.
{{< /note >}}
2. Open a GitHub issue in the `kubernetes/org` repository to request membership.
Fill out the template using the guidelines at
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
3. Let your sponsors know about the GitHub issue, either by at-mentioning them
in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly,
so that they can add a `+1` vote.
4. When your membership is approved, the github admin team member assigned to your request updates the
GitHub issue to show approval and then closes the GitHub issue.
Congratulations, you are now a member!
-->
1. 找到两个 reviewer 或 approver 为你提名。
通过 [#sig-docs channel on the Kubernetes Slack instance](https://kubernetes.slack.com) 或者
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
来寻找为你提名的人。
{{< note >}}
不要单独发送邮件给某个人或在 Slack 中私聊。
{{< /note >}}
2. 在 `kubernetes/org` 仓库中提交一个 issue 发起请求。
按照[指导模板](https://github.com/kubernetes/community/blob/master/community-membership.md)填写请求。
3. 告知你的提名人，可以通过在 issue 中 `@<GitHub-username>` 或者直接发送给他们 issue 链接，
这样他们可以过来投票（`+1`）。
4. 当请求被批准后，github 管理员团队成员会告诉你批准加入并且关闭 issue："Congratulations, you are now a member!"。
<!--
If for some reason your membership request is not accepted right away, the
membership committee provides information or steps to take before applying
again.
-->
如果因为某些原因你的申请没有被批准，会员委员会成员会告诉你原因并指导你如何继续申请。
### Reviewers
<!--
Reviewers are members of the
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
-->
Reviewers 是 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) 成员。
<!--
Reviewers review documentation pull requests and provide feedback on proposed
changes.
-->
Reviewers 负责检视文档的 PR 并提供反馈。
<!--
Automation assigns reviewers to pull requests, and contributors can request a
review from a specific reviewer with a comment on the pull request: `/assign
[@_github_handle]`. To indicate that a pull request is technically accurate and
requires no further changes, a reviewer adds a `/lgtm` comment to the pull
request.
-->
每个 PR 都会自动分配 reviewer，任何贡献者都可以在评论中回复 `/assign [@_github_handle]`
来请求某个 reviewer 来检视。
如果 reviewer 觉得没有问题且不需要进一步更改时，reviewer 会在评论中回复 `/lgtm` 。
<!--
If the assigned reviewer has not yet reviewed the content, another reviewer can
step in. In addition, you can assign technical reviewers and wait for them to
provide `/lgtm`.
-->
如果自动分配的 reviewer 未能及时检视，其他的 reviewer 也会参与。
此外，你可以指定某个 reviewer 或者等他们回复 `/lgtm`。
<!--
For a trivial change or one that needs no technical review, the SIG Docs
[approver](#approvers) can provide the `/lgtm` as well.
-->
对于不重要的更改或者非技术性的检视，SIG Docs 的 [approver](#approvers) 也可以提供 `/lgtm` 标签。
<!--
A `/approve` comment from a reviewer is ignored by automation.
-->
如果一个 reviewer 在评论中回复 `/approve` 会被自动忽略。
<!--
For more about how to become a SIG Docs reviewer and the responsibilities and
time commitment involved, see
[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer).
-->
关于如何成为 SIG Docs reviewer 以及其责任、时间承诺等更多内容，请参照
[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer)。
<!--
#### Becoming a reviewer
-->
#### 成为 reviewer
<!--
When you meet the
[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
separately for reviewer status in SIG Docs.
-->
当你满足[需求](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时，
你就可以成为 SIG Docs 的 reviewer。
其他 SIG 的 reviewer 也需要单独向 SIG Docs 申请。
<!--
To apply, open a pull request to add yourself to the `reviewers` section of the
[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS)
in the `kubernetes/website` repository. Assign the PR to one or more current SIG
Docs approvers.
-->
通过提交一个 PR 并把自己加到位于 `kubernetes/website` 仓库顶层的 [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) 文件中的 `reviewers` 部分，指定一个或多个当前 SIG Docs 的 approver。
<!--
If your pull request is approved, you are now a SIG Docs reviewer.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
will assign and suggest you as a reviewer on new pull requests.
-->
如果你的 PR 被批准，你就成为了 SIG Docs reviewer 了。
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) 会在接下来的 PR 中请求你检视。
<!--
If you are approved, request that a current SIG Docs approver add you to the
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
add new members to a GitHub group.
-->
如果您的 PR 被批准，你就会加入 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) 组。只有 `kubernetes-website-admins` 组的成员才可以加入新成员。
### Approvers
<!--
Approvers are members of the
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
-->
approver 是 GitHub [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) 组织成员。
参考 [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs)。
<!--
Approvers have the ability to merge a PR, and thus, to publish content on the
Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on
the PR. If someone who is not an approver leaves the approval comment,
automation ignores it.
-->
approver 有权限合入 PR，这意味着他们可以发布内容到 Kubernetes 网站。
如果一个 approver 留下 `/approve` 评论，则代表他批准了 PR。
如果非 approver 成员尝试批准，则会被自动忽略。
<!--
If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`,
the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on
a change that doesn't need additional technical review.
-->
如果某个 PR 已有 `/lgtm` 标签，approver 再回复一个 `/lgtm` ，则这个 PR 会自动合入。
SIG Docs approver 应该只在不需要额外的技术检视的情况下才可以标记 `/lgtm`。
<!--
For more about how to become a SIG Docs approver and the responsibilities and
time commitment involved, see
[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer).
-->
关于如何成为 SIG Docs 的 approver 及其责任和时间承诺等信息，请参考 [Becoming a reviewer or approver](#becoming-an-approver-or-reviewer)。
<!--
#### Becoming an approver
-->
#### 成为 approver
<!--
When you meet the
[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
you can become a SIG Docs approver. Approvers in other SIGs must apply
separately for approver status in SIG Docs.
-->
当满足[要求](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) 时，你可以成为 SIG Docs 的 approver。其他的 SIG 的 approver 要想成为 SIG Docs 的 approver 需要单独申请。
<!--
To apply, open a pull request to add yourself to the `approvers` section of the
[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS)
in the `kubernetes/website` repository. Assign the PR to one or more current SIG
Docs approvers.
-->
通过提交一个 PR 并把自己加到位于 `kubernetes/website` 仓库顶层的 [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) 文件中的 `approvers` 部分，指定一个或多个当前 SIG Docs 的 approver。
<!--
If your pull request is approved, you are now a SIG Docs approver.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
will assign and suggest you as a reviewer on new pull requests.
-->
一旦你的 PR 被批准，你就是一个 SIG Docs 的 approver 了。
<!--
If you are approved, request that a current SIG Docs approver add you to the
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
add new members to a GitHub group.
-->
如果您的 PR 被批准，你就会加入[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) 组。只有 `kubernetes-website-admins` 组的成员才可以加入新成员。
<!--
#### Approver responsibilities
-->
#### Approver 职责
<!--
Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:
-->
Approvers 通过查看拉取请求（pr）并将其合并到网站仓库中来完善文档。因为此角色具有其他特权，所以 approvers 还具有其他职责：
<!--
- Approvers can use the `/approve` command, which merges PRs into the repo.
A careless merge can break the site, so be sure that when you merge something, you mean it.
- Make sure that proposed changes meet the contribution guidelines.
If you ever have a question, or you're not sure about something, feel free to call for additional review.
- Verify that netlify tests pass before you `/approve` a PR.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" />
- Visit the netlify page preview for a PR to make sure things look good before approving.
-->
- Approvers 可以使用 `/approve` 命令将 PR 合并到仓库中。
粗心的合并会破坏站点，因此请确保在合并某些内容时，您是清楚的。
- 确保建议的更改符合贡献准则。
如果您有任何疑问，或者不确定某个问题，请随时联系他人进行审核。
- 在 `/approve` PR 之前，请验证 netlify 测试是否通过。
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须确保 Netlify 测试通过" />
- 请访问 netlify 页面预览 PR，确保批准前一切正常。
<!--
#### PR Wrangler
-->
#### PR 协调者
<!--
SIG Docs approvers participate in the
[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
for weekly rotations. SIG Docs expects all approvers to participate in this
rotation. See
[Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
for more details.
-->
每个 SIG Docs approver 都会参与 [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
所有 SIG Docs approver 都会参与轮值。
更多信息，请参考[做一周的PR协调者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)。
<!--
#### SIG Docs chairperson
-->
#### SIG Docs 主席
<!--
Each SIG, including SIG Docs, selects one or more SIG members to act as
chairpersons. These are points of contact between SIG Docs and other parts of
the Kubernetes organization. They require extensive knowledge of the structure
of the Kubernetes project as a whole and how SIG Docs works within it. See
[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
for the current list of chairpersons.
-->
每个 SIG，包括 SIG Docs，都会选出 1 位或多位成员作为主席。
主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。
他们需要了解整个 Kubernetes 项目，并明白 SIG Docs 如何运作。
如需查询当前的主席，请查阅 [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。
<!--
## SIG Docs teams and automation
-->
## SIG Docs 团队和自动化
<!--
Automation in SIG Docs relies on two different mechanisms for automation:
GitHub groups and OWNERS files.
-->
SIG 文档中的自动化依赖于两种不同的自动化机制:
GitHub 组和 OWNERS 文件。
### GitHub groups
<!--
The SIG Docs group defines two teams on GitHub:
-->
SIG Docs 组定义了两个 GitHub 组：
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
<!--
Each can be referenced with their `@name` in GitHub comments to communicate with
everyone in that group.
-->
可以在 GitHub 的评论中 `@name` 他们来与他们沟通。
<!--
These teams overlap, but do not exactly match, the groups used by the automation
tooling. For assignment of issues, pull requests, and to support PR approvals,
the automation uses information from OWNERS files.
-->
这些团队与自动化工具使用的组有所重叠，但并不完全匹配。
对于分配 issue、拉请求和批准 PR，自动化使用来自 OWNERS 文件的信息。
<!--
### OWNERS files and front-matter
-->
### OWNERS 文件和扉页
<!--
The Kubernetes project uses an automation tool called prow for automation
related to GitHub issues and pull requests. The
[Kubernetes website repository](https://github.com/kubernetes/website) uses
two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
-->
Kubernetes 项目使用名为 prow 的自动化工具来处理 GitHub issue 和 PR。
[Kubernetes website repository](https://github.com/kubernetes/website) 使用了两个
[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210)：
- blunderbuss
- approve
<!--
These two plugins use the
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
files in the top level of the `kubernetes/website` GitHub repository to control
how prow works within the repository.
-->
这两个插件使用位于 `kubernetes/website` 仓库顶层的
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) 和
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) 来控制工作流程。
<!--
An OWNERS file contains a list of people who are SIG Docs reviewers and
approvers. OWNERS files can also exist in subdirectories, and can override who
can act as a reviewer or approver of files in that subdirectory and its
descendents. For more information about OWNERS files in general, see
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
-->
OWNERS 文件包含 SIG Docs reviewer 和 approver 的列表。
OWNERS 文件也可以存在于子目录中中，可以重写 reviewer 和 approver，并且它自动继承上级。
关于 OWNERS 的更多信息，请参考 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)。
<!--
In addition, an individual Markdown file can list reviewers and approvers in its
front-matter, either by listing individual GitHub usernames or GitHub groups.
-->
此外，一个单独的 Markdown 格式的文件将会列出 reviewer 和 approver（扉页），或者列出
其 GitHub 用户名 或者列出其组名。
<!--
The combination of OWNERS files and front-matter in Markdown files determines
the advice PR owners get from automated systems about who to ask for technical
and editorial review of their PR.
-->
结合 OWNERS 文件及扉页可以给 PR 作者提供向谁请求检视的建议。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
For more information about contributing to the Kubernetes documentation, see:
-->
关于贡献 Kubernetes 的更多文档，请参考：
- [Start contributing](/docs/contribute/start/)
- [Documentation style](/docs/contribute/style/)
{{% /capture %}}
content/zh/docs/contribute/start.md
+634
View File
@@ -0,0 +1,634 @@
---
title: 开始贡献
slug: start
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 10
---
<!--
---
title: Start contributing
slug: start
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 10
---
-->
{{% capture overview %}}
<!--
If you want to get started contributing to the Kubernetes documentation, this
page and its linked topics can help you get started. You don't need to be a
developer or a technical writer to make a big impact on the Kubernetes
documentation and user experience! All you need for the topics on this page is
a [GitHub account](https://github.com/join) and a web browser.
If you're looking for information on how to start contributing to Kubernetes
code repositories, refer to
[the Kubernetes community guidelines](https://github.com/kubernetes/community/blob/master/governance.md).
-->
如果您想要为 Kubernetes 文档做贡献，本页面的内容和链接的主题能够给您帮助。您不必是一位开发者或者技术作者，也同样可以为 Kubernetes 文档及其用户体验带来巨大的影响！您只需要有一个 [Github 账号](https://github.com/join) 和一个浏览器。
如果您在寻找有关如何开始向 Kubernetes 仓库贡献代码的信息，请参考 [Kubernetes 社区指南](https://github.com/kubernetes/community/blob/master/governance.md)。
{{% /capture %}}
{{% capture body %}}
<!--
## The basics about our docs
-->
## 关于我们文档的基础知识
<!--
The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
You can file issues, edit content, and review changes from others, all from the
GitHub website. You can also use GitHub's embedded history and search tools.
-->
Kubernetes 文档是以 Markdown 形式编写的，使用 Hugo 进行部署。源码位于 Github 的 [https://github.com/kubernetes/website](https://github.com/kubernetes/website)。大部分文档源码位于 `/content/en/docs/`。有些参考文档是由 `update-imported-docs/` 目录内的脚本自动生产的。
您可以提交 issue、编辑内容或者对其他人的提交内容进行复审，这些都可以在 Github 网站上完成。您也可以使用 Github 内置的历史功能和查询工具。
<!--
Not all tasks can be done in the GitHub UI, but these are discussed in the
[intermediate](/docs/contribute/intermediate/) and
[advanced](/docs/contribute/advanced/) docs contribution guides.
### Participating in SIG Docs
-->
并非所有的任务都可以通过 Github UI 完成，这些任务会在[中级](/docs/contribute/intermediate/)和[高级](/docs/contribute/advanced/)文档贡献指南中讨论
### 参与文档特别兴趣小组（SIG Docs）
<!--
The Kubernetes documentation is maintained by a
{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG)
called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and
weekly video meetings. New participants are welcome. For more information, see
[Participating in SIG Docs](/docs/contribute/participating/).
-->
Kubernetes 文档是由 {{< glossary_tooltip text="特别兴趣小组" term_id="sig" >}} (SIG) 维护的，该小组名为 SIG Docs。我们通过 Slack 频道、邮件列表和网络视频周会进行[交流](#participate-in-sig-docs-discussions)。欢迎新的参与者加入。更多信息，请参考[参与 SIG Docs](/docs/contribute/participating/)。
<!--
### Content guildelines
The SIG Docs community created guidelines about what kind of content is allowed
in the Kubernetes documentation. Look over the [Documentation Content
Guide](/docs/contribute/style/content-guide/) to determine if the content
contribution you want to make is allowed. You can ask questions about allowed
content in the [#sig-docs]((#participate-in-sig-docs-discussions)) Slack
channel.
-->
### 内容指南
SIG Docs 社区创建了有关 Kubernetes 文档中允许哪种内容的指南。查看[文档内容指南](/docs/contribute/style/content-guide/)确定是否允许您要进行的内容贡献。您可以在 [#sig-docs]((#participate-in-sig-docs-discussions)) 频道中询问有关允许内容的问题。
<!--
### Style guidelines
We maintain a [style guide](/docs/contribute/style/style-guide/) with information
about choices the SIG Docs community has made about grammar, syntax, source
formatting, and typographic conventions. Look over the style guide before you
make your first contribution, and use it when you have questions.
-->
### 风格指南
我们维护了一个[风格指南](/docs/contribute/style/style-guide/)页面，上面有关于 SIG Docs 社区对于语法、句法、源格式和排版的约定。在您做首次贡献前或者在有疑问的时候请先查阅风格指南。
<!--
Changes to the style guide are made by SIG Docs as a group. To propose a change
or addition, [add it to the agenda](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more
information.
-->
风格的变化是由 SIG Docs 组共同决定的。如您想提交变更或增加内容，请将内容[添加到议题](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#)并参与会议讨论。更多信息，参见[进阶贡献](/docs/contribute/advanced/)主题。
<!--
### Page templates
We use page templates to control the presentation of our documentation pages.
Be sure to understand how these templates work by reviewing
[Using page templates](/docs/contribute/style/page-templates/).
### Hugo shortcodes
-->
### 页面模板
我们使用页面模板来控制文档页面。需要确保您理解这些模版是如何工作的，请阅读[使用页面模板](/docs/contribute/style/page-templates/)。
### Hugo 短代码
<!--
The Kubernetes documentation is transformed from Markdown to HTML using Hugo.
We make use of the standard Hugo shortcodes, as well as a few that are custom to
the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for
information about how to use them.
### Multiple languages
-->
Kubernetes 文档使用 Hugo 将 Markdown 转换成 HTML。我们使用标准的 Hugo 短代码，同时也会有部分为 Kubernetes 定制化的代码。有关如何使用短代码的信息，请参见[自定义 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。
### 多语言
<!--
Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide.
-->
在 `/content/` 目录中有文档源码的多语言版本。每个语言拥有其自己的目录，采用 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php) 的两位编码命名。例如，英文文档源码位于 `/content/en/docs/` 目录。
更多关于对多语言文档做贡献的信息，请参考中级贡献指南中的["本地化内容"](/docs/contribute/intermediate#localize-content)。
<!--
If you're interested in starting a new localization, see ["Localization"](/docs/contribute/localization/).
## File actionable issues
-->
如果您有兴趣开始一个新的本地化语言项目，请参考["本地化"](/docs/contribute/localization/)。
## 提出可操作的 issues
<!--
Anyone with a GitHub account can file an issue (bug report) against the
Kubernetes documentation. If you see something wrong, even if you have no idea
how to fix it, [file an issue](#how-to-file-an-issue). The exception to this
rule is a tiny bug like a typo that you intend to fix yourself. In that case,
you can instead [fix it](#improve-existing-content) without filing a bug first.
### How to file an issue
-->
任何拥有 Github 账号的人都能对于 Kubernetes 提出可行的 issue（或者 bug report）。如果发现问题，即便您不知道如何修复它，请[提出 issue](#how-to-file-an-issue)。除非您发现微小的错误的情况，例如发现了一个拼写错误，您想自己进行修复。在这种情况下，您可以[修复它](#improve-existing-content)，而不用先提出一个 bug。
### 如何提出 issue
<!--
- **On an existing page**
If you see a problem in an existing page in the [Kubernetes docs](/docs/),
go to the bottom of the page and click the **Create an Issue** button. If
you are not currently logged in to GitHub, log in. A GitHub issue form
appears with some pre-populated content.
Using Markdown, fill in as many details as you can. In places where you see
empty square brackets (`[ ]`), put an `x` between the set of brackets that
represents the appropriate choice. If you have a proposed solution to fix
the issue, add it.
-->
- **对于已有页面**
如果您在已有的 [Kubernetes 文档](/docs/)页面，在页面底部直接点击 **创建 Issue** 按钮。如果您当前未登录 Github，那么请登录。Github 文档表单会带着预填的信息出现。
使用 Markdown 格式，填写尽可能多的详细信息。在方括号 (`[ ]`) 中，使用 `x` 代码选择了该选项。如果您提交了修复 issue 的方法，也填在里面。
<!--
- **Request a new page**
If you think content should exist, but you aren't sure where it should go or
you don't think it fits within the pages that currently exist, you can
still file an issue. You can either choose an existing page near where you think the
new content should go and file the issue from that page, or go straight to
[https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/)
and file the issue from there.
-->
- **请求创建一个新页面**
如果认为有些内容应该存在，但您不知道应该将这些内容存放在哪里，或者任何不适合放在现有页面中，那么也可以提出一个 issue。您可以选择通过内容相近的页面创建 issue，或者直接在 [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/)中记录 issue。
<!--
### How to file great issues
To ensure that we understand your issue and can act on it, keep these guidelines
in mind:
-->
### 如何记录好的 issues
要确保我们能理解您的 issue，并能付诸行动，请谨记如下指南：
<!--
- Use the issue template, and fill out as many details as you can.
- Clearly explain the specific impact the issue has on users.
- Limit the scope of a given issue to a reasonable unit of work. For problems
with a large scope, break them down into smaller issues.
For instance, "Fix the security docs" is not an actionable issue, but "Add
details to the 'Restricting network access' topic" might be.
- If the issue relates to another issue or pull request, you can refer to it
either by its full URL or by the issue or pull request number prefixed
with a `#` character. For instance, `Introduced by #987654`.
- Be respectful and avoid venting. For instance, "The docs about X suck" is not
helpful or actionable feedback. The
[Code of Conduct](/community/code-of-conduct/) also applies to interactions on
Kubernetes GitHub repositories.
-->
- 使用 issue 模板，尽可能填写详细的信息。
- 清楚地描述该 issue 对用户造成的具体影响。
- 限制 issue 的范围，以提交给合理的工作组。如果问题范围很大，将其拆分成若干个 issues。
例如，“修复安全文档”就是一个不可执行的 issue，但 “为'限制网络访问'主题添加详细信息”就是可执行的。
- 如果 issue 与另一个 issue 或者拉取请求（PR）有关，您可以通过 issue 的完整 URL 或者 PR 的序号（以 `#` 为前缀）进行关联。例如 `如 #987654`。
- 保持尊重，避免发泄。例如，“关于 X 的文档很差”就是无用且不可执行的反馈。[行为准测](/community/code-of-conduct/) 也适用于 Kubernetes Github 仓库的交互。
<!--
## Participate in SIG Docs discussions
The SIG Docs team communicates using the following mechanisms:
- [Join the Kubernetes Slack instance](http://slack.k8s.io/), then join the
`#sig-docs` channel, where we discuss docs issues in real-time. Be sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
- Participate in the [weekly SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) video meeting, which is announced on the Slack channel and the mailing list. Currently, these meetings take place on Zoom, so you'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
-->
## 参与 SIG Docs 讨论
SIG Docs 团队交流采用如下机制：
- [加入 Kubernetes 的 Slack 工作组](http://slack.k8s.io/)，然后加入 `#sig-docs` 频道，在那里我会实时讨论文档的 issues。一定要做自我介绍！
- [加入 `kubernetes-sig-docs` 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)，在这里会有广泛的讨论以及官方决策的记录。
- 参与 [SIG Docs 视频周例会](https://github.com/kubernetes/community/tree/master/sig-docs)，会通过 Slack 频道和邮件列表通知。
目前通过 Zoom 进行会议，所以您需要下载 [Zoom 客户端](https://zoom.us/download)，或者通过手机拨入。
{{< note >}}
<!--
You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
-->您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。
{{< /note >}}
<!--
## Improve existing content
To improve existing content, you file a _pull request (PR)_ after creating a
_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
For the purposes of this topic, you don't need to know everything about them,
because you can do everything using your web browser. When you continue to the
[intermediate docs contributor guide](/docs/contribute/intermediate/), you will
need more background in Git terminology.
-->
## 改进现有内容
要改进现有的内容，您可以在创建 _fork_ 之后起草一个 _拉取请求（PR）_ 。这两个术语是 [Github 专用的](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/)。
出于本主题的目的，您无需了解有关它们的所有信息，因为您可以通过浏览器做所有的事情。当您继续阅读[贡献者中级指南](/docs/contribute/intermediate/)，您会需要更多 Git 术语的背景知识。
{{< note >}}
<!--
**Kubernetes code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, your process is a bit different. See
[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for
process guidelines and information about deadlines.
-->**Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。
关于流程指南和最后期限的信息，请参阅[编写功能文档](/docs/contribute/intermediate/#sig-members-documenting-new-features)。
{{< /note >}}
<!--
### Sign the CNCF CLA {#sign-the-cla}
Before you can contribute code or documentation to Kubernetes, you **must** read
the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and
[sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Don't worry -- this doesn't take long!
### Find something to work on
-->
## 签署 CNCF CLA {#sign-the-cla}
在贡献 Kubernetes 的代码或文档前，您 **必须** 阅读[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)，并[签署贡献者许可协议（CLA）](https://github.com/kubernetes/community/blob/master/CLA.md)。
别担心 -- 不需要太多时间！
### 开始贡献
<!--
If you see something you want to fix right away, just follow the instructions
below. You don't need to [file an issue](#file-actionable-issues) (although you
certainly can).
If you want to start by finding an existing issue to work on, go to
[https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues)
and look for issues with the label `good first issue` (you can use
[this](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) shortcut). Read through the comments and make sure there is not an open pull
request against the issue and that nobody has left a comment saying they are
working on the issue recently (3 days is a good rule). Leave a comment saying
that you would like to work on the issue.
-->
如果您发现了一些想要马上修复的问题，只需要遵循如下指南。您不需要[提出一个 issue](#file-actionable-issues)（尽管你当然可以这么做）。
如果您想从处理现有的 issue 开始，前往 [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) 找一些有 `good first issue` 标签的 issue （您可以使用[这个](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) 快捷方式)。阅读评论，确保针对此 issue 没有打开的 PR，并且没有人留言说他们最近正在解决这个 issue （3 天是个很好的规则）。留言说您会去解决这个 issue。
<!--
### Choose which Git branch to use
The most important aspect of submitting pull requests is choosing which branch
to base your work on. Use these guidelines to make the decision:
-->
### 选择使用的 Git 分支
提交 PR 最重要的方面就是选择您工作所基于的基础分支。使用如下指南来做决定：
<!--
- Use `master` for fixing problems in content that is already published, or
making improvements to content that already exists.
- Use a release branch (such as `dev-{{< release-branch >}}` for the {{< release-branch >}} release) to document upcoming features
or changes for an upcoming release that is not yet published.
- Use a feature branch that has been agreed upon by SIG Docs to collaborate on
big improvements or changes to the existing documentation, including content
reorganization or changes to the look and feel of the website.
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or
attend a weekly SIG Docs meeting to get clarity.
-->
- 用 `master` 来解决以及发布的内容中的问题，或者对于已经存在的内容进行改进。
- 使用 release 分支（比如 `dev-{{< release-branch >}}` 用于 {{< release-branch >}} 发布）来撰写新的特性或者下个版本还未发布的变更说明。
- 使用 SIG Docs 已经同意的 feature 分支来协作对现有文档进行重大改进或更改，包括内容重组或网站外观的更改。
如果您还不确定应该使用哪个分支，在 Slack 上询问 `#sig-docs` 或者参与 SIG Docs 周例会来确认。
<!--
### Submit a pull request
-->
### 提交 PR
<!--
Follow these steps to submit a pull request to improve the Kubernetes
documentation.
1. On the page where you see the issue, click the pencil icon at the top right.
A new GitHub page appears, with some help text.
2. If you have never created a fork of the Kubernetes documentation
repository, you are prompted to do so. Create the fork under your GitHub
username, rather than another organization you may be a member of. The
fork usually has a URL such as `https://github.com/<username>/website`,
unless you already have a repository with a conflicting name.
The reason you are prompted to create a fork is that you do not have
access to push a branch directly to the definitive Kubernetes repository.
3. The GitHub Markdown editor appears with the source Markdown file loaded.
Make your changes. Below the editor, fill in the **Propose file change**
form. The first field is the summary of your commit message and should be
no more than 50 characters long. The second field is optional, but can
include more detail if appropriate.
-->
按照如下步骤提交 PR 来改善 Kubernetes 文档。
1. 在您提交 issue 的页面上，点击右上角的铅笔图标。新的页面就会出现，上面会有一些帮助信息。
2. 如果您从未创建过 Kubernetes 文档仓库的 fork，会提示您需要创建。请在您的 Github 账号下创建 fork，而不是在您所在的组织下创建。fork URL 通常是这样的 `https://github.com/<username>/website`，除非您已经有一个同名的仓库，那样会造成冲突。
您创建 fork 的原因是您无权直接将分支推送到确定的 Kubernetes 仓库。
3. Github Markdown 编辑器会载入着文档源码一起出现。根据实际情况撰写变化内容。在编辑器下方填写 **Propose file change（建议修改文件）** 表格。第一个区域需要填写提交说明消息，不能超过 50 个字符。第二个区域是可选的，也能够填写更多详细信息。
{{< note >}}
<!--
Do not include references to other GitHub issues or pull
requests in your commit message. You can add those to the pull request
description later.
-->不要把 Github issues 或者 PR 的关联信息放在您的提交说明消息中。您可以之后把这些内容添加到 PR 的描述中。
{{< /note >}}
<!--
Click **Propose file change**. The change is saved as a commit in a
new branch in your fork, which is automatically named something like
`patch-1`.
-->
点击 **建议修改文件（Propose file change）** 按钮。变更会保存为您 fork 新分支（通常会自动命名为 `patch-1`）中的一个提交内容。
<!--
4. The next screen summarizes the changes you made, by comparing your new
branch (the **head fork** and **compare** selection boxes) to the current
state of the **base fork** and **base** branch (`master` on the
`kubernetes/website` repository by default). You can change any of the
selection boxes, but don't do that now. Have a look at the difference
viewer on the bottom of the screen, and if everything looks right, click
**Create pull request**.
-->
4. 接下来屏幕会总结您的变更，将您的新分支（**head fork** 和 **compare** 选择框）与 **base fork**
和 **base** 分支(默认是 `kubernetes/website` 的 `master` 分支)进行比较。您可以更改选择框，但现在请不要这么做。看一下屏幕底部显示的变化内容，如果看起来没问题，点击 **创建 PR（Create pull request）** 按钮。
{{< note >}}
<!--
If you don't want to create the pull request now, you can do it
later, by browsing to the main URL of the Kubernetes website repository or
your fork's repository. The GitHub website will prompt you to create the
pull request if it detects that you pushed a new branch to your fork.
-->如果您现在还不想创建 PR，也可以稍后再做，通过浏览 Kubernetes 网站代码仓库或者您 fork 仓库的网站主页 URL。Github 网站会检查到您推送了一个新分支到 fork，并提示创建 PR。
{{< /note >}}
<!--
5. The **Open a pull request** screen appears. The subject of the pull request
is the same as the commit summary, but you can change it if needed. The
body is populated by your extended commit message (if present) and some
template text. Read the template text and fill out the details it asks for,
then delete the extra template text. If you add to the description `fixes #<000000>`
or `closes #<000000>`, where `#<000000>` is the number of an associated issue,
GitHub will automatically close the issue when the PR merges.
Leave the **Allow edits from maintainers** checkbox selected. Click
**Create pull request**.
-->
5. **Open a pull request（打开一个 PR）** 屏幕出现了。PR 的主题和提交说明的内容一致，
如有需要您也可以修改。主体内容会自动填充您的扩展提交消息（如果存在）和一些模板文本。
阅读模板文本并填写要求的详细信息，然后删除额外的模板文本。
如果在描述中添加 `fixes #<000000>` 或者 `closes #<000000>`，其中 `#<000000>` 是相关问题的编号，则当PR合并时，GitHub 将自动关闭该问题。
保留选中 **Allow edits from maintainers（允许维护者编辑）** 复选框。
单击 **Create pull request（创建拉取请求）** 按钮。
<!--
Congratulations! Your pull request is available in
[Pull requests](https://github.com/kubernetes/website/pulls).
After a few minutes, you can preview the website with your PR's changes
applied. Go to the **Conversation** tab of your PR and click the **Details**
link for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default.
-->
祝贺您！您的 PR 就出现在了[拉取请求](https://github.com/kubernetes/website/pulls) 中。
几分钟后，您可以预览 PR 所带来的变化。前往您 PR 的 **Conversation（对话）** 标签页，
点击 `deploy/netlify` 测试的 **Details（详细信息）** 链接，它在页面底部附件。
默认会在同一个浏览器窗口中打开。
{{< note >}}
<!--
Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
-->请将 PR 请求限制为每种 PR 只能使用一种语言。例如，如果您需要对多种语言的同一代码示例进行相同的更改，请为每种语言打开一个单独的 PR。
{{< /note >}}
<!--
6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`.
If a reviewer asks you to make changes, you can go to the **Files changed**
tab and click the pencil icon on any files that have been changed by the
pull request. When you save the changed file, a new commit is created in
the branch being monitored by the pull request. If you are waiting on a
reviewer to review the changes, proactively reach out to the reviewer
once every 7 days. You can also drop into #sig-docs Slack channel,
which is a good place to ask for help regarding PR reviews.
7. If your change is accepted, a reviewer merges your pull request, and the
change is live on the Kubernetes website a few minutes later.
-->
6. 等待复审。通常，复审人员会由 `k8s-ci-robot` 建议指定。如果复审人员建议您修改，您可以
前往 **Files changed（改变的文件内容）** 标签页，点击任意 PR 中改变的文件页面上的铅笔图标。
保存更改的文件时，将在 PR 监视的分支中创建新的提交。如果您正在等待复审者审核更改，
请每 7 天主动与复审者联系一次。您也可以进入 #sig-docs Slack 频道，这是寻求有关 PR 审查的帮助的好地方。
7. 如果修改被接受，复审人员会合并您的 PR，修改就会在几分钟后在 Kubernetes 网站上生效。
<!--
This is only one way to submit a pull request. If you are already a Git and
GitHub advanced user, you can use a local GUI or command-line Git client
instead of using the GitHub UI. Some basics about using the command-line Git
client are discussed in the [intermediate](/docs/contribute/intermediate/) docs
contribution guide.
-->
这是提交 PR 的唯一方式。如果您已经是一名 Git 和 Github 的高级用户，您也可以使用本地 GUI 或者
Git 命令行。关于使用 Git 客户端的基础会在[中级](/docs/contribute/intermediate/) 贡献者指南中讨论。
<!--
## Review docs pull requests
People who are not yet approvers or reviewers can still review pull requests.
The reviews are not considered "binding", which means that your review alone
won't cause a pull request to be merged. However, it can still be helpful. Even
if you don't leave any review comments, you can get a sense of pull request
conventions and etiquette and get used to the workflow.
-->
## 复审文档 PR
就算不是批注者或者复审者，也同样可以复审 PR。复审人员并不是"固定"的，意味着您单独的评审并不会让 PR 合并。然而，这依然对我们是很有帮助的。即使您没有留下任何评审意见，您可以了解 PR 的规范和礼仪，并习惯工作流程。
<!--
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
You see a list of every open pull request against the Kubernetes website and
docs.
-->
1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)。
请会看到一个列表，里面包含了所有对于 Kubernetes 网站和文档提的 PR。
<!--
2. By default, the only filter that is applied is `open`, so you don't see
pull requests that have already been closed or merged. It's a good idea to
apply the `cncf-cla: yes` filter, and for your first review, it's a good
idea to add `size/S` or `size/XS`. The `size` label is applied automatically
based on how many lines of code the PR modifies. You can apply filters using
the selection boxes at the top of the page, or use
[this shortcut](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) for only small PRs. All filters are `AND`ed together, so
you can't search for both `size/XS` and `size/S` in the same query.
-->
2. 默认情况下，使用的筛选器是 `open`，所以您不会看见已经关闭或合并的 PR。
最好使用 `cncf-cla: yes` 筛选器，并且对于第一次复审来说，最好加上 `size/S`
或者 `size/XS`。`size` 标签会根据 PR 修改的代码行数自动生成。
您可以通过页面顶端的选择框应用筛选器，或者使用
[快捷方式](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS)
来查找所有小型 PR。所有筛选条件都是 `与` 的，所以您不能在一次查询中同时查找 `size/XS` 和 `size/S` 的结果。
<!--
3. Go to the **Files changed** tab. Look through the changes introduced in the
PR, and if applicable, also look at any linked issues. If you see a problem
or room for improvement, hover over the line and click the `+` symbol that
appears.
You can type a comment, and either choose **Add single comment** or **Start
a review**. Typically, starting a review is better because it allows you to
leave multiple comments and notifies the PR owner only when you have
completed the review, rather than a separate notification for each comment.
-->
3. 前往 **Files changed（文件修改）** 标签页。查看 PR 中的变化部分，如果适用，也看一下关联的问题。如果您发现问题或者可以改进的空间，
将鼠标悬浮在那一行并点击前面出现的 `+` 加号。
你可以留下评论，选择 **Add single comment（仅添加评论）** 或者也可以 **Start a review（开始复审）**。典型来说，开始复审更好，因为这样您就可以在多行下留下评论，并且只有在完成复审后统一提交并通知 PR 的作者，而不是每一条评论都发送通知。
<!--
4. When finished, click **Review changes** at the top of the page. You can
summarize your review, and you can choose to comment, approve, or request
changes. New contributors should always choose **Comment**.
-->
4. 完成后，点击页面顶端但 **Review changes（复审修改）** 按钮。您可以总结复审，并且可以选择comment（评论），approve（批准），或者 request changes（请求变更）。新的贡献者应该选择 **Comment（评论）**。
<!--
Thanks for reviewing a pull request! When you are new to the project, it's a
good idea to ask for feedback on your pull request reviews. The `#sig-docs`
Slack channel is a great place to do this.
## Write a blog post
-->
感谢您对于 PR 的复审工作！当您对于项目还是新人时，最好在拉取请求评论中征求反馈意见。Slack 的 `#sig-docs` 频道就是一个征求意见好去处。
## 撰写博客文章
<!--
Anyone can write a blog post and submit it for review. Blog posts should not be
commercial in nature and should consist of content that will apply broadly to
the Kubernetes community.
To submit a blog post, you can either submit it using the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform),
or follow the steps below.
-->
任何人都可以撰写博客并提交复审。博客文章不应具有商业性质，而应包含广泛适用于 Kubernetes 社区的内容。
要提交博客文章，您可以选择使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)或者按如下步骤进行：
<!--
1. [Sign the CLA](#sign-the-cla) if you have not yet done so.
2. Have a look at the Markdown format for existing blog posts in the
[website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
3. Write out your blog post in a text editor of your choice.
4. On the same link from step 2, click the **Create new file** button. Paste
your content into the editor. Name the file to match the proposed title of
the blog post, but don't put the date in the file name. The blog reviewers
will work with you on the final file name and the date the blog will be
published.
5. When you save the file, GitHub will walk you through the pull request
process.
6. A blog post reviewer will review your submission and work with you on
feedback and final details. When the blog post is approved, the blog will be
scheduled for publication.
-->
1. 如果您还未签署 CLA，请[签署 CLA](#sign-the-cla)。
2. 查看现有博客文章的 Markdown 格式，位于[网站代码仓库](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts)。
3. 在您选择的文本编辑器中写下您的博客文章。
4. 在步骤 2 的相同链接中，点击 **Create new file（创建新文件）** 按钮。
将您的内容粘贴到编辑器中。将文件命名为与博客文章的标题的名称，
但不要将日期放在文件名中。博客复审人员将与您一起确定最终文件名和博客发布日期。
5. 保存文件时，Github 将引导您完成 PR 过程。
6. 博客复审人员会对您的提交对内容进行复审，并与您一起完成反馈意见和最终的详细信息。
博客文章获得批准后，博客将会安排时间进行发布。
<!--
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. They are written in collaboration with the Kubernetes
marketing team, which is handled by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/)
to submit your proposal.
-->
## 提交案例研究
案例研究强调组织如何使用 Kubernetes 解决实际问题。它们是由 Kubernetes 市场团队共同撰写的，由 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 进行处理。
看一下[现有案例研究](https://github.com/kubernetes/website/tree/master/content/en/case-studies)的源码。
使用 [Kubernetes 案例研究提交表](https://www.cncf.io/people/end-user-community/)提交您的提案。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
When you are comfortable with all of the tasks discussed in this topic and you
want to engage with the Kubernetes docs team in deeper ways, read the
[intermediate docs contribution guide](/docs/contribute/intermediate/).
-->
当您对本主题中讨论的所有任务感到满意，并且您希望以更深入的方式与 Kubernetes 文档团队合作，请阅读[中级贡献者指南](/docs/contribute/intermediate/)。
{{% /capture %}}
content/zh/docs/contribute/style/_index.md
+21
View File
@@ -0,0 +1,21 @@
---
title: 文档风格概述
main_menu: true
weight: 80
---
<!--
---
title: Documentation style overview
main_menu: true
weight: 80
---
-->
<!--
The topics in this section provide guidance on writing style, content formatting
and organization, and using Hugo customizations specific to Kubernetes
documentation.
-->
本节的主题是提供有关编写风格、内容格式和组织以及使用 Hugo 定制生成 Kubernetes 文档的指导。
content/zh/docs/contribute/style/content-organization.md
+270
View File
@@ -0,0 +1,270 @@
---
title: 内容组织
content_template: templates/concept
weight: 40
---
<!--
---
title: Content organization
content_template: templates/concept
weight: 40
---
-->
{{% capture overview %}}
<!--
This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept.
-->
本网站使用了 Hugo。在 Hugo 中，[内容组织](https://gohugo.io/content-management/organization/) 是一个核心概念。
{{% /capture %}}
{{% capture body %}}
{{% note %}}
<!--
**Hugo Tip:** Start Hugo with `hugo server --navigateToChanged` for content edit-sessions.
-->
**Hugo 提示:** 用 `hugo server --navigateToChanged` 命令启动 Hugo 以进行内容编辑会话。
{{% /note %}}
<!--
## Page Lists
-->
## 页面列表
<!--
### Page Order
-->
### 页面顺序
<!--
The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first), and finally by the link title.
-->
文档侧方菜单、文档页面浏览器等以 Hugo 的默认排序顺序列出，它按照权重（从1开始）、日期（最新的排第一个）排序，最后按链接标题排序。
<!--
Given that, if you want to move a page or a section up, set a weight in the page's front matter:
-->
如果你想提升一个页面或一个章节，请在页面头部设置一个较高的权重：
```yaml
title: My Page
weight: 10
```
{{% note %}}
<!--
For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval, say 10, 20, 30... This allows you to insert pages where you want later.
-->
对于页面的权重，不建议使用连续的数值，比如1、2、3...，而是采用间隔的数值，比如10、20、30...，这样你可以将后续的页面插入到想要的位置。
{{% /note %}}
<!--
### Documentation Main Menu
-->
### 文档主菜单
<!--
The `Documentation` main menu is built from the sections below `docs/` with the `main_menu` flag set in front matter of the `_index.md` section content file:
-->
`Documentation` 主菜单是从 `docs/` 下面的章节构建的，它在 `_index.md` 章节内容文件的头部设置了 `main_menu` 标志：
```yaml
main_menu: true
```
<!--
Note that the link title is fetched from the page's `linkTitle`, so if you want it to be something different than the title, change it in the content file:
-->
注意，链接标题是从页面的 `linkTitle` 中提取的，因此如果希望它与标题不同，请在内容文件中更改它：
```yaml
main_menu: true
title: Page Title
linkTitle: Title used in links
```
{{% note %}}
<!--
The above needs to be done per language. If you don't see your section in the menu, it is probably because it is not identified as a section by Hugo. Create a `_index.md` content file in the section folder.
-->
以上每种语言都需要完成。如果在菜单中没有看到你的章节，这可能是因为它没有被 Hugo 标识为一个章节。请在章节对应的目录下创建 `_index.md` 内容文件。
{{% /note %}}
<!--
### Documentation Side Menu
-->
### 文档侧方菜单
<!--
The documentation side-bar menu is built from the _current section tree_ starting below `docs/`.
-->
文档侧方菜单是从 `docs/` 下面的 _current 章节的 tree_ 开始构建的。
<!--
It will show all sections and their pages.
-->
它将显示所有的章节和它们的页面。
<!--
If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter:
-->
如果你不想列出某个章节或页面，请在页面头部将 `toc_hide` 标志设置为 `true`。
```yaml
toc_hide: true
```
<!--
When you navigate to a section that has content, the specific section or page (e.g. `_index.md`) is shown. Else, the first page inside that section is shown.
-->
当导航到具有内容的章节时，将显示出指定的章节或页面（例如 `_index.md`）。否则，将显示该章节里的第一个页面。
<!--
### Documentation Browser
-->
### 文档浏览器
<!--
The page browser on the documentation home page is built using all the sections and pages that are directly below the `docs section`.
-->
文档主页上的页面浏览器是用 `docs section` 下一层的所有章节和页面构建的。
<!--
If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter:
-->
如果你不想列出某个章节或页面，请在页面头部将 `toc_hide` 标志设置为 `true`。
```yaml
toc_hide: true
```
<!--
### The Main Menu
-->
### 主菜单
<!--
The site links in the top-right menu -- and also in the footer -- are built by page-lookups. This is to make sure that the page actually exists. So, if the `case-studies` section does not exist in a site (language), it will not be linked to.
-->
右上菜单中的网站链接（也在页脚中）是通过页面查找构建的。这是为了确保页面实际存在。因此，如果 `case-studies` 章节在网站中不存在（按语言），则它将链接不到。
<!--
## Page Bundles
-->
## 页面包
<!--
In addition to standalone content pages (Markdown files), Hugo supports [Page Bundles](https://gohugo.io/content-management/page-bundles/).
-->
除了独立的内容页面（Markdown文件），Hugo 还支持 [页面包](https://gohugo.io/content-management/page-bundles/)。
<!--
One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/). It is considered a `leaf bundle`. Everything below the directory, including the `index.md`, will be part of the bundle. This also includes page-relative links, images that can be processed etc.:
-->
一个例子是 [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。它被认为是 `leaf bundle`。目录下的所有内容，包括 `index.md`，都是包的一部分。这还包括页面相关的链接、可被处理的图像等：
```bash
en/docs/home/contribute/includes
├── example1.md
├── example2.md
├── index.md
└── podtemplate.json
```
<!--
Another widely used example is the `includes` bundle. It sets `headless: true` in front matter, which means that it does not get its own URL. It is only used in other pages.
-->
另一个广泛使用的例子是 `includes` 包。它在页面头部设置 `headless: true`，这意味着它没有得到自己的 URL。它只用于其他页面。
```bash
en/includes
├── default-storage-class-prereqs.md
├── federated-task-tutorial-prereqs.md
├── federation-content-moved.md
├── index.md
├── partner-script.js
├── partner-style.css
├── task-tutorial-prereqs.md
├── user-guide-content-moved.md
└── user-guide-migration-notice.md
```
<!--
Some important notes to the files in the bundles:
-->
包中文件的一些重要说明：
<!--
* For translated bundles, any missing non-content files will be inherited from languages above. This avoids duplication.
* All the files in a bundle are what Hugo calls `Resources` and you can provide metadata per language, such as parameters and title, even if it does not supports front matter (YAML files etc.). See [Page Resources Metadata](https://gohugo.io/content-management/page-resources/#page-resources-metadata).
* The value you get from `.RelPermalink` of a `Resource` is page-relative. See [Permalinks](https://gohugo.io/content-management/urls/#permalinks).
-->
* 对于已翻译的包，任何丢失的非内容文件将从上面的语言继承。这避免了重复。
* 包中的所有文件都是 Hugo 所指的 `Resources`，你可以为每种语言提供元数据，例如参数和标题，即使它不支持头部设置（YAML 文件等）。参见[页面资源元数据](https://gohugo.io/content-management/page-resources/#page-resources-metadata)。
* 从 `Resource` 的 `.RelPermalink` 中获得的值是页面相关的。参见 [Permalinks](https://gohugo.io/content-management/urls/#permalinks)。
<!--
## Styles
-->
## 样式
<!--
The `SASS` source of the stylesheets for this site is stored below `src/sass` and can be built with `make sass` (note that Hugo will get `SASS` support soon, see https://github.com/gohugoio/hugo/issues/4243).
-->
本网站的样式表的 `SASS` 源存储在 `src/sass` 下面，可以用 `make sass` 构建（Hugo很快就会得到 `SASS` 的支持，参见https://github.com/gohugoio/hugo/issues/4243）。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)
* [Style guide](/docs/contribute/style/style-guide)
-->
* [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)
* [样式指南](/docs/contribute/style/style-guide)
{{% /capture %}}
content/zh/docs/contribute/style/hugo-shortcodes/example1.md
+23
View File
@@ -0,0 +1,23 @@
---
title: 例子 #1
---
<!--
---
title: Example #1
---
-->
<!--
This is an **example** content file inside the **includes** leaf bundle.
-->
这是一个内容文件**示例**，位于一个**includes**叶子包中。
{{< note >}}
<!--
Included content files can also contain shortcodes.
-->
包含的内容文件也可以包含短代码。
{{< /note >}}
content/zh/docs/contribute/style/hugo-shortcodes/example2.md
+17
View File
@@ -0,0 +1,17 @@
---
title: 例子 #1
---
<!--
---
title: Example #1
---
-->
<!--
This is another **example** content file inside the **includes** leaf bundle.
-->
这是另一个内容文件**示例**，位于一个**includes**叶子包中。
content/zh/docs/contribute/style/hugo-shortcodes/index.md
+272
View File
@@ -0,0 +1,272 @@
---
approvers:
- chenopis
title: 定制 Hugo 短代码
content_template: templates/concept
---
<!-- ---
approvers:
- chenopis
title: Custom Hugo Shortcodes
content_template: templates/concept
--- -->
{{% capture overview %}}
<!-- This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation. -->
本页面将介绍定制 Hugo 短代码，可以用于 Kubernetes markdown 文档书写。
<!-- Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes). -->
更多关于短代码参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。
{{% /capture %}}
{{% capture body %}}
<!-- ## Feature state -->
## 功能状态
<!-- In a markdown page (.md file) on this site, you can add a shortcode to display version and state of the documented feature. -->
本站上面的 markdown 页面，你可以加入短代码来展示已经文档介绍的功能的版本和状态(state)。
<!-- ### Feature state demo -->
### 功能状态演示
<!-- Below is a demo of the feature state snippet, which displays the feature as stable in Kubernetes version 1.10. -->
下面是一个功能状态代码段的演示，表明这个功能已经在 Kubernetes v1.10时就已经稳定了。
```
{{</* feature-state for_k8s_version="v1.10" state="stable" */>}}
```
<!-- Will render to: -->
会转换为：
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
<!-- The valid values for `state` are: -->
`state`的可选值如下：
* alpha
* beta
* deprecated
* stable
<!-- ### Feature state code -->
### 功能状态代码
<!-- Below is the template code for each available feature state. -->
下面是为每个现有的功能状态的模板代码。
<!-- The displayed Kubernetes version defaults to that of the page or the site. This can be changed by passing the <code>for_k8s_version</code> shortcode parameter. -->
显示的 Kubernetes 默认为该页或站点版本。
这个可以通过修改 <code>for_k8s_version</code> 短代码参数来调整。
```
{{</* feature-state for_k8s_version="v1.10" state="stable" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
<!-- #### Alpha feature -->
#### Alpha 功能
```
{{</* feature-state feature-state state="alpha" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state state="alpha" >}}
<!-- #### Beta feature -->
#### Beta 功能
```
{{</* feature-state feature-state state="beta" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state state="beta" >}}
<!-- #### Stable feature -->
#### 稳定功能
```
{{</* feature-state feature-state state="stable" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state state="stable" >}}
<!-- #### Deprecated feature -->
#### 废弃功能
```
{{</* feature-state feature-state state="deprecated" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state state="deprecated" >}}
<!-- ## Glossary -->
## 词汇
<!-- You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
using the online documentation, the glossary entry will display a tooltip. -->
你可以通过加入术语词汇的短代码，来自动更新和替换相应链接中的内容（[我们的词汇库](/docs/reference/glossary/)）
这样，在浏览在线文档，鼠标移到术语上时，术语解释就会显示在提示框中。
<!-- The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term. -->
词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary)，每个内容文件对应相应的术语解释。
<!-- ### Glossary Demo -->
### 词汇演示
<!-- For example, the following include within the markdown will render to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: -->
例如，下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`，然后在提示框中显示。
````liquid
{{</* glossary_tooltip text="cluster" term_id="cluster" */>}}
````
<!-- ## Tabs -->
## 标签页
<!-- In a markdown page (`.md` file) on this site, you can add a tab set to display multiple flavors of a given solution. -->
在本站的 markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示不同形式的解决方案。
<!-- The `tabs` shortcode takes these parameters: -->
标签页的短代码包含以下参数：
<!-- * `name`: The name as shown on the tab.
* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting.
* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- will be looked up in the bundle itself. If not, the content page to include will be looked up relative to the current. Note that with the `include` you will not have any shortcode inner content and must use the self-closing syntax, e.g. {{</* tab name="Content File #1" include="example1" /*/>}}. Non-content files will be code-highlighted. The language to use will be taken from the filename if not provided in `codelang`. -->
* `name`: 标签页上的名字。
* `codelang`: 如果要在`tab`短代码中加入内部内容，需要告知 Hugo 使用的是什么代码语言，方便代码高亮。
* `include`: 标签页中所要包含的文件。如果标签页是在 Hugo 的页面包（[leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles)）中，文件（可以是 Hugo 所支持的 MIME 类型文件）将会在包中查找。如果不是，所要包含的内容页面将会在当前路径的相关路径下查找。注意，在`include`属性部分，不能加入短代码内部内容，必须要使用自结束（self-closing）的语法。
非内容文件将会被代码高亮。如果没有在`codelang`进行声明的话，所用的代码语言将会来自文件名。
<!-- * If your inner content is markdown, you must use `%`-delimiter to surorund the tab, e.g. `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
* You can combine the variations mentioned above inside a tab set. -->
* 如果内部内容是 markdown， 你必须要使用 `%` 分隔符来包装标签页，例如，`{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
* 可以在标签页集中混合使用上面的各种变形。
<!-- Below is a demo of the tabs shortcode. -->
下面是演示标签页短代码。
{{< note >}}
The tab **name** in a `tabs` definition must be unique within a content page.
一个内容页面下的，标签页定义中的标签页 **名** 必须是唯一的。
{{< /note >}}
<!-- ### Tabs demo: Code highlighting -->
### 标签页演示：代码高亮
```go-text-template
{{</* tabs name="tab_with_code" >}}
{{{< tab name="Tab 1" codelang="bash" >}}
echo "This is tab 1."
{{< /tab >}}
{{< tab name="Tab 2" codelang="go" >}}
println "This is tab 2."
{{< /tab >}}}
{{< /tabs */>}}
```
<!-- Will be rendered as: -->
会转换为：
{{< tabs name="tab_with_code" >}}
{{< tab name="Tab 1" codelang="bash" >}}
echo "This is tab 1."
{{< /tab >}}
{{< tab name="Tab 2" codelang="go" >}}
println "This is tab 2."
{{< /tab >}}
{{< /tabs >}}
### Tabs demo: Inline Markdown and HTML
```go-html-template
{{</* tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
This is **some markdown.**
{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}}
{{% /tab %}}
{{< tab name="HTML" >}}
<div>
<h3>Plain HTML</h3>
<p>This is some <i>plain</i> HTML.</p>
</div>
{{< /tab >}}
{{< /tabs */>}}
```
<!-- Will be rendered as: -->
会转换为：
{{< tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
This is **some markdown.**
{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}}
{{% /tab %}}
{{< tab name="HTML" >}}
<div>
<h3>Plain HTML</h3>
<p>This is some <i>plain</i> HTML.</p>
</div>
{{< /tab >}}
{{< /tabs >}}
<!-- ### Tabs demo: File include -->
### 标签页演示：文件嵌套
```go-text-template
{{</* tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs */>}}
```
<!-- Will be rendered as: -->
会转换为：
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
<!-- * Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/).
* Learn about [using page templates](/docs/home/contribute/page-templates/).
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). -->
* 了解 [Hugo](https://gohugo.io/)。
* 了解 [撰写新的话题](/docs/home/contribute/write-new-topic/)。
* 了解 [使用页面模板](/docs/home/contribute/page-templates/)。
* 了解 [暂存修改](/docs/home/contribute/stage-documentation-changes/)。
* 了解 [创建 pull request](/docs/home/contribute/create-pull-request/)。
{{% /capture %}}
content/zh/docs/contribute/style/hugo-shortcodes/podtemplate.json
+22
View File
@@ -0,0 +1,22 @@
{
"apiVersion": "v1",
"kind": "PodTemplate",
"metadata": {
"name": "nginx"
},
"template": {
"metadata": {
"labels": {
"name": "nginx"
},
"generateName": "nginx-"
},
"spec": {
"containers": [{
"name": "nginx",
"image": "dockerfile/nginx",
"ports": [{"containerPort": 80}]
}]
}
}
}
content/zh/docs/contribute/style/page-templates.md
+352
View File
@@ -0,0 +1,352 @@
---
title: 使用页面模板
content_template: templates/concept
weight: 30
---
<!--
---
title: Using Page Templates
content_template: templates/concept
weight: 30
---
-->
{{% capture overview %}}
<!--
When contributing new topics, apply one of the following templates to them.
This standardizes the user experience of a given page.
-->
当贡献新主题时，选择下列模板中的一种。
这使指定页面的用户体验标准化。
<!--
The page templates are in the
[`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates)
directory of the [`kubernetes/website`](https://github.com/kubernetes/website)
repository.
-->
页面模板在 [`kubernetes/website`](https://github.com/kubernetes/website) 仓库的 [`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) 目录中。
{{< note >}}
<!--
Every new topic needs to use a template. If you are unsure which
template to use for a new topic, start with the
[concept template](#concept-template).
-->
每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板，请从[概念模板](#concept-template)开始。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!--
## Concept template
-->
## 概念模板
<!--
A concept page explains some aspect of Kubernetes. For example, a concept
page might describe the Kubernetes Deployment object and explain the role it
plays as an application once it is deployed, scaled, and updated. Typically, concept
pages don't include sequences of steps, but instead provide links to tasks or
tutorials.
-->
每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。
<!--
To write a new concept page, create a Markdown file in a subdirectory of the
`/content/en/docs/concepts` directory, with the following characteristics:
-->
要编写新的概念页面，请在 `/content/en/docs/concepts` 目录的子目录中创建一个 Markdown 文件，其特点如下：
<!--
- In the page's YAML front-matter, set `content_template: templates/concept`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_template: templates/concept`。
- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量：
| 变量 | 必需? |
|---------------|-----------|
| overview | 是 |
| body | 是 |
| whatsnext | 否 |
<!--
The page's body will look like this (remove any optional captures you don't
need):
-->
页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）：
```
{{%/* capture overview */%}}
{{%/* /capture */%}}
{{%/* capture body */%}}
{{%/* /capture */%}}
{{%/* capture whatsnext */%}}
{{%/* /capture */%}}
```
<!--
- Within each section, write your content. Use the following guidelines:
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- For `body`, explain the concept using free-form Markdown.
- For `whatsnext`, give a bullet list of up to 5 topics the reader might be
interested in reading next.
-->
- 在每个章节中写下你的内容。请遵从以下规则：
- 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。
- 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。
- 在 `body` 节，使用自由形式的 Markdown 文件来解释概念。
- 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。
<!--
An example of a published topic that uses the concept template is
[Annotations](/docs/concepts/overview/working-with-objects/annotations/). The
page you are currently reading also uses the concept template.
-->
使用概念模板的已发布主题的一个示例是[注解](/docs/concepts/overview/working-with-objects/annotations/)。你当前正在阅读的页面也使用概念模板。
<!--
## Task template
-->
## 任务模板
<!--
A task page shows how to do a single thing, typically by giving a short
sequence of steps. Task pages have minimal explanation, but often provide links
to conceptual topics that provide related background and knowledge.
-->
任务页面展示了如何完成单个任务，通常是通过给出一个简短的步骤序列。任务页面中解释性质的文字极少，但是通常会给出提供相关背景和知识的概念主题的链接。
<!--
To write a new task page, create a Markdown file in a subdirectory of the
`/content/en/docs/tasks` directory, with the following characteristics:
-->
要编写新的任务页面，请在 `/content/en/docs/tasks` 目录的子目录中创建一个 Markdown 文件，其特点如下：
<!--
- In the page's YAML front-matter, set `content_template: templates/task`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_template: templates/task`。
- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量：
| 变量 | 必需? |
|---------------|-----------|
| overview | 是 |
| prerequisites | 是 |
| steps | 否 |
| discussion | 否 |
| whatsnext | 否 |
<!--
The page's body will look like this (remove any optional captures you don't
need):
-->
页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）：
```
{{%/* capture overview */%}}
{{%/* /capture */%}}
{{%/* capture prerequisites */%}}
{{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}}
{{%/* /capture */%}}
{{%/* capture steps */%}}
{{%/* /capture */%}}
{{%/* capture discussion */%}}
{{%/* /capture */%}}
{{%/* capture whatsnext */%}}
{{%/* /capture */%}}
```
<!--
- Within each section, write your content. Use the following guidelines:
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- For `prerequisites`, use bullet lists when possible. Start adding additional
prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster.
- For `steps`, use numbered lists.
- For discussion, use normal content to expand upon the information covered
in `steps`.
- For `whatsnext`, give a bullet list of up to 5 topics the reader might be
interested in reading next.
-->
- 在每个章节中写下你的内容。请遵从以下规则：
- 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。
- 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。
- 在 `prerequisites 节`，如果有可能，请使用列表。在 `include` 下开始添加额外的先决条件。默认的先决条件包括运行中的 Kubernetes 集群。
- 在 `steps` 节，使用编号列表。
- 在讨论部分，使用通常的内容来扩展 `steps` 中包含的信息。
- 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。
<!--
An example of a published topic that uses the task template is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api).
-->
使用任务模板的已发布主题的一个示例是[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api)。
<!--
## Tutorial template
-->
## 教程模板
<!--
A tutorial page shows how to accomplish a goal that is larger than a single
task. Typically a tutorial page has several sections, each of which has a
sequence of steps. For example, a tutorial might provide a walkthrough of a
code sample that illustrates a certain feature of Kubernetes. Tutorials can
include surface-level explanations, but should link to related concept topics
for deep explanations.
-->
教程页面展示了如何完成比单个任务更大的目标。通常教程页有几个章节，每个章节都有步骤说明。例如，教程可以提供说明 Kubernetes 的特定特性的代码示例的演练。教程可以包括表层解释，但是应该链接到相关的概念主题以进行深入解释。
<!--
To write a new tutorial page, create a Markdown file in a subdirectory of the
`/content/en/docs/tutorials` directory, with the following characteristics:
-->
要编写新的教程页面，请在 `/content/en/docs/tutorials` 目录的子目录中创建一个 Markdown 文件，其特点如下：
<!--
- In the page's YAML front-matter, set `content_template: templates/tutorial`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_template: templates/tutorial`。
- 在页面的 body 中，设置所需的 `capture` 变量和所有想要包含的变量：
| 变量 | 必需? |
|---------------|-----------|
| overview | 是 |
| prerequisites | 是 |
| objectives | 是 |
| lessoncontent | 是 |
| cleanup | 否 |
| whatsnext | 否 |
<!--
The page's body will look like this (remove any optional captures you don't
need):
-->
页面的 body 看起来像这样（移除所有不想要的可选 `capture` 变量）：
```
{{%/* capture overview */%}}
{{%/* /capture */%}}
{{%/* capture prerequisites */%}}
{{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}}
{{%/* /capture */%}}
{{%/* capture objectives */%}}
{{%/* /capture */%}}
{{%/* capture lessoncontent */%}}
{{%/* /capture */%}}
{{%/* capture cleanup */%}}
{{%/* /capture */%}}
{{%/* capture whatsnext */%}}
{{%/* /capture */%}}
```
<!--
- Within each section, write your content. Use the following guidelines:
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- For `prerequisites`, use bullet lists when possible. Add additional
prerequisites below the ones included by default.
- For `objectives`, use bullet lists.
- For `lessoncontent`, use a mix of numbered lists and narrative content as
appropriate.
- For `cleanup`, use numbered lists to describe the steps to clean up the
state of the cluster after finishing the task.
- For `whatsnext`, give a bullet list of up to 5 topics the reader might be
interested in reading next.
-->
- 在每个章节中写下你的内容。请遵从以下规则：
- 使用不低于 H2 级别的标题（避免使用 H1 的标题，但 H3、H4 的标题是可以的）（以两个 `#` 字符开头）。这些章节本身是由模板自动命名的。
- 在 `overview` 节，用一个段落的篇幅来为当前话题设定语境。
- 在 `prerequisites` 节，如果有可能，请使用列表。在默认情况下添加额外的先决条件。
- 在 `objectives` 节，使用列表。
- 在 `lessoncontent` 节，适当地使用编号列表和叙述内容的组合。
- 在 `cleanup` 节，使用编号列表描述完成任务后清理集群状态的步骤。
- 在 `whatsnext` 节，列出读者接下来可能感兴趣的最多 5 个主题。
<!--
An example of a published topic that uses the tutorial template is
[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
-->
使用教程模板的已发布主题的一个示例是[使用部署运行无状态应用程序](/docs/tutorials/stateless-application/run-stateless-application-deployment/)。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
- Learn about the [style guide](/docs/contribute/style/style-guide/)
- Learn about [content organization](/docs/contribute/style/content-organization/)
-->
- 学习[样式指南](/docs/contribute/style/style-guide/)
- 学习[内容组织](/docs/contribute/style/content-organization/)
{{% /capture %}}
content/zh/docs/contribute/style/write-new-topic.md
+346
View File
@@ -0,0 +1,346 @@
---
title: 撰写新主题
content_template: templates/task
weight: 20
---
<!--
---
title: Writing a new topic
content_template: templates/task
weight: 20
---
-->
{{% capture overview %}}
<!--
This page shows how to create a new topic for the Kubernetes docs.
-->
本页面展示如何为 Kubernetes 文档库创建新主题。
{{% /capture %}}
{{% capture prerequisites %}}
<!--
Create a fork of the Kubernetes documentation repository as described in
[Start contributing](/docs/contribute/start/).
-->
创建 Kubernetes 文档仓库的一个分支，如[开始贡献](/docs/contribute/start/)中所述。
{{% /capture %}}
{{% capture steps %}}
<!--
## Choosing a page type
-->
## 选择页面类型
<!--
As you prepare to write a new topic, think about the page type that would fit your content the best:
-->
当你准备写一个新的主题时，考虑一下最适合你的内容的页面类型：
<!--
<table>
<tr>
<td>Concept</td>
<td>A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.</td>
</tr>
<tr>
<td>Task</td>
<td>A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a></td>
</tr>
<tr>
<td>Tutorial</td>
<td>A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.</td>
</tr>
</table>
-->
<table>
<tr>
<td>概念</td>
<td>每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。一个概念主题的示例，请参见 <a href="/docs/concepts/architecture/nodes/">节点</a>.</td>
</tr>
<tr>
<td>任务</td>
<td>任务页面展示了如何完成单个任务。这样做的目的是给读者一系列步骤，让他们在阅读时能够真正做到这一点。任务页面可长可短，前提是它始终聚焦在一个区域。在任务页面中，可以将简短的解释与要执行的步骤混合在一起，但如果需要提供冗长的解释，则应在概念主题中进行。相关联的任务和概念主题可以相互链接。一个简短的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">配置一个使用卷进行存储的 Pod</a>. 一个较长的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活动性和就绪性探测器</a></td>
</tr>
<tr>
<td>教程</td>
<td>教程页面展示了如何实现将几个 Kubernetes 特性联系在一起的目标。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的演练。教程可以包括对 Kubernetes 几个关联特性的简要解释，但应该链接到相关概念主题，以便深入解释各个特性。</td>
</tr>
</table>
<!--
Use a template for each new page. Each page type has a
[template](/docs/contribute/style/page-templates/)
that you can use as you write your topic. Using templates helps ensure
consistency among topics of a given type.
-->
为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。
<!--
## Choosing a title and filename
-->
## 选择标题和文件名
<!--
Choose a title that has the keywords you want search engines to find.
Create a filename that uses the words in your title separated by hyphens.
For example, the topic with title
[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
has filename `http-proxy-access-api.md`. You don't need to put
"kubernetes" in the filename, because "kubernetes" is already in the
URL for the topic, for example:
-->
选择一个标题，标题中包含了要通过搜索引擎要查找的关键字。创建一个文件名，使用标题中由连字符分隔的单词。例如，标题为[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) 的主题的文件名为 `http-proxy-access-api.md`。你不需要在文件名中加上 "kubernetes"，因为 "kubernetes" 已经在主题的 URL 中了，例如：
/docs/tasks/access-kubernetes-api/http-proxy-access-api/
<!--
## Adding the topic title to the front matter
-->
## 在页面头部添加主题标题
<!--
In your topic, put a `title` field in the
[front matter](https://jekyllrb.com/docs/frontmatter/).
The front matter is the YAML block that is between the
triple-dashed lines at the top of the page. Here's an example:
-->
在你的主题中，在[页面头部](https://jekyllrb.com/docs/frontmatter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子：
<!--
---
title: Using an HTTP Proxy to Access the Kubernetes API
---
-->
---
title: 使用 HTTP 代理访问 Kubernetes API
---
<!--
## Choosing a directory
-->
## 选择目录
<!--
Depending on your page type, put your new file in a subdirectory of one of these:
-->
根据页面类型，将新文件放入其中一个子目录中：
* /content/en/docs/tasks/
* /content/en/docs/tutorials/
* /content/en/docs/concepts/
<!--
You can put your file in an existing subdirectory, or you can create a new
subdirectory.
-->
你可以将文件放在现有的子目录中，也可以创建一个新的子目录。
<!--
## Placing your topic in the table of contents
-->
## 将主题放在目录中
<!--
The table of contents is built dynamically using the directory structure of the
documentation source. The top-level directories under `/content/en/docs/` create
top-level navigation, and subdirectories each have entries in the table of
contents.
-->
目录是使用文档源的目录结构动态构建的。`/content/en/docs/` 下的顶层目录创建顶层导航，它和子目录在目录中都有条目。
<!--
Each subdirectory has a file `_index.md`, which represents the "home" page for
a given subdirectory's content. The `_index.md` does not need a template. It
can contain overview content about the topics in the subdirectory.
-->
每个子目录都有一个 `_index.md` 文件，它表示指定子目录内容的主页面。`_index.md` 文件不需要模板。它可以包含有关子目录中主题的概述内容。
<!--
Other files in a directory are sorted alphabetically by default. This is almost
never the best order. To control the relative sorting of topics in a
subdirectory, set the `weight:` front-matter key to an integer. Typically, we
use multiples of 10, to account for adding topics later. For instance, a topic
with weight `10` will come before one with weight `20`.
-->
默认情况下，目录中的其他文件按字母顺序排序。这几乎不是最好的顺序。要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数。通常我们使用10的倍数，添加后续主题时权重值递增。例如，权重为 `10` 的主题将位于权重为 `20` 的主题之前。
<!--
## Embedding code in your topic
-->
## 在主题中嵌入代码
<!--
If you want to include some code in your topic, you can embed the code in your
file directly using the markdown code block syntax. This is recommended for the
following cases (not an exhaustive list):
-->
如果你想在主题中包含一些代码，可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况（并非详尽列表）：
<!--
- The code shows the output from a command such as
`kubectl get deploy mydeployment -o json | jq '.status'`.
- The code is not generic enough for users to try out. As an example, you can
embed the YAML
file for creating a Pod which depends on a specific
[Flexvolume](/docs/concepts/storage/volumes#flexvolume) implementation.
- The code is an incomplete example because its purpose is to highlight a
portion of a larger file. For example, when describing ways to
customize the [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
for some reasons, you can provide a short snippet directly in your topic file.
- The code is not meant for users to try out due to other reasons. For example,
when describing how a new attribute should be added to a resource using the
`kubectl edit` command, you can provide a short example that includes only
the attribute to add.
-->
- 代码显示来自命令的输出，例如 `kubectl get deploy mydeployment -o json | jq '.status'`。
- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定 [Flexvolume](/docs/concepts/storage/volumes#flexvolume)实现的 Pod。
- 该代码是一个不完整的示例，因为它的目的是高亮显示大文件的部分内容。例如，在描述自定义 [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)的方法时，出于某些原因，你可以直接在主题文件中提供一个简短的片段。
- 由于其他原因，该代码不适合用户验证。例如，当使用 `kubectl edit` 命令描述如何将新属性添加到资源时，你可以提供一个仅包含要添加的属性的简短示例。
<!--
## Including code from another file
-->
## 引用来自其他文件的代码
<!--
Another way to include code in your topic is to create a new, complete sample
file (or group of sample files) and then reference the sample from your topic.
Use this method to include sample YAML files when the sample is generic and
reusable, and you want the reader to try it out themselves.
-->
在主题中引用代码的另一种方法是创建一个新的、完整的示例文件（或示例文件组），然后从主题中引用这些示例。当示例是通用的和可重用的，并且你希望读者自己验证时，使用此方法引用示例 YAML 文件。
<!--
When adding a new standalone sample file, such as a YAML file, place the code in
one of the `<LANG>/examples/` subdirectories where `<LANG>` is the language for
the topic. In your topic file, use the `codenew` shortcode:
-->
添加新的独立示例文件（如 YAML 文件）时，将代码放在 `<LANG>/examples/` 的某个子目录中，其中 `<LANG>` 是该主题的语言。在主题文件中使用 `codenew` 短代码：
<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
<!--
where `<RELPATH>` is the path to the file to include, relative to the
`examples` directory. The following Hugo shortcode references a YAML
file located at `/content/en/examples/pods/storage/gce-volume.yaml`.
-->
`<RELPATH>` 是要引用的文件的路径，相对于 `examples` 目录。以下 Hugo 短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML 文件。
```none
{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
```
{{< note >}}
<!--
To show raw Hugo shortcodes as in the above example and prevent Hugo
from interpreting them, use C-style comments directly after the `<` and before
the `>` characters. View the code for this page for an example.
-->
要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释，请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。
{{< /note >}}
<!--
## Showing how to create an API object from a configuration file
-->
## 显示如何从配置文件创建 API 对象
<!--
If you need to demonstrate how to create an API object based on a
configuration file, place the configuration file in one of the subdirectories
under `<LANG>/examples`.
-->
如果需要演示如何基于配置文件创建 API 对象，请将配置文件放在 `<LANG>/examples` 下的某个子目录中。
<!--
In your topic, show this command:
-->
在主题中展示以下命令：
```
kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
```
{{< note >}}
<!--
When adding new YAML files to the `<LANG>/examples` directory, make
sure the file is also included into the `<LANG>/examples_test.go` file. The
Travis CI for the Website automatically runs this test case when PRs are
submitted to ensure all examples pass the tests.
-->
将新的 YAML 文件添加到 `<LANG>/examples` 目录时，请确保该文件也在 `<LANG>/examples_test.go` 文件中被引用。当提交拉取请求时，网站的 Travis CI 会自动运行此测试用例，以确保所有示例都通过测试。
{{< /note >}}
<!--
For an example of a topic that uses this technique, see
[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
-->
有关使用此技术的主题的示例，请参见[运行单实例有状态的应用](/docs/tutorials/stateful-application/run-stateful-application/)。
<!--
## Adding images to a topic
-->
## 向主题添加镜像
<!--
Put image files in the `/images` directory. The preferred
image format is SVG.
-->
将镜像文件放入 `/images` 目录。首选的镜像格式是 SVG。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* Learn about [using page templates](/docs/home/contribute/page-templates/).
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/).
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
-->
* 学习[使用页面模板](/docs/home/contribute/page-templates/)。
* 学习[展示你的修改](/docs/home/contribute/stage-documentation-changes/)。
* 学习[创建一个拉取请求](/docs/home/contribute/create-pull-request/)。
{{% /capture %}}