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

resolving conflicts

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-07-08 16:01:48 -04:00
parent 754c6b1a64 0ce44ec17f
commit 0ebc16c10c
421 changed files with 10650 additions and 8434 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/_index.md
+4 -186
View File
@@ -1,191 +1,9 @@
---
content_type: concept
title: 为 Kubernetes 文档做贡献
linktitle: 贡献
main_menu: true
weight: 80
title: 贡献新内容
weight: 20
---
<!--
---
content_type: concept
title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
weight: 80
---
title: Contributing new content
weight: 20
-->
<!-- 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/)？
<!-- 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 网站或其他工具提出改进建议
<!--
## Additional ways to contribute
-->
## 其他贡献途径
<!--
- To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/).
-->
- 如果您要通过 Twitter 或 Stack Overflow 等在线论坛为社区做贡献，或了解本地会议及 Kubernetes 事件，请查看 [Kubernetes 社区网站](/community/).
<!--
- To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started.
-->
- 如果您要开发新的特性，请阅读 [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet).
content/zh/docs/contribute/advanced.md
+86 -58
View File
@@ -2,29 +2,28 @@
title: 高级贡献
slug: advanced
content_type: concept
weight: 30
weight: 98
---
<!--
---
title: Advanced contributing
slug: advanced
content_type: concept
weight: 30
---
weight: 98
-->
<!-- 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
This page assumes that you understand how to
[contribute to new content](/docs/contribute/new-content/overview) and
[review others' work](/docs/contribute/review/reviewing-prs/), 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 命令行工具和其他工具做这些工作。
如果你已经了解如何[贡献新内容](/zh/docs/contribute/new-content/overview/)和
[评阅他人工作](/zh/docs/contribute/review/reviewing-prs/)，并准备了解更多贡献的途径，
请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。
<!-- body -->
@@ -34,13 +33,13 @@ client and other tools for some of these tasks.
## 做一周的 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)中。
SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
<!--
The PR wrangler’s duties include:
-->
SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责
[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
PR 管理者的工作职责包括：
<!--
@@ -62,7 +61,7 @@ PR 管理者的工作职责包括：
- 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](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[样式指南](/zh/docs/contribute/style/style-guide/)和[内容指南](/zh/docs/contribute/style/content-guide/)。
- 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。
- 尽可能多地审阅 PR。
- 确保每个贡献者完成 CLA 签署。
@@ -78,7 +77,8 @@ PR 管理者的工作职责包括：
- 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。
- 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。
- 合并已经就绪的，或关闭不应该接受的 PR。
- 每天对新增的 issues 进行分类和标记。有关 SIG 文档如何使用 metadata 的准则，请参见[中级贡献](/docs/contribute/intermediate/)。
- 每天对新增的 Issue 报告进行分类和判别。有关 SIG 文档如何使用 metadata 的准则，请参见
[对 Issue 进行分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。
<!--
### Helpful GitHub queries for wranglers
@@ -86,9 +86,10 @@ PR 管理者的工作职责包括：
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 查询
### 对于管理人有用的 GitHub 查询
执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。
这些查询都排除了本地化的 PR，并仅包含 `master` 分支上的 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):
@@ -102,13 +103,15 @@ reviewed is usually small. These queries specifically exclude localization PRs,
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, 不能合并](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`。
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：对于针对 master 分支的小规模 PR，可以快速审阅。
在浏览 PR 时，可以注意到 size 标签为 "XS" 的 PRs。
- [非 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 作者确定是否所针对的是最合适的分支。
@@ -132,7 +135,7 @@ Don't be afraid to close pull requests. Contributors can easily reopen and resum
To close a pull request, leave a `/close` comment on the PR.
-->
- 关闭两个星期未签署 CLA 的 PR。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。
@@ -140,28 +143,29 @@ PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CL
要关闭 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 >}}
一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90
天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。
PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< /note >}}
<!--
## Propose improvements
SIG Docs
[members](/docs/contribute/participating/#members) can propose improvements.
SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
-->
## 提出改进建议
SIG Docs 的 [成员](/docs/contribute/participating/#members) 可以提出改进建议。
SIG Docs 的 [成员](/zh/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
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
, the [Content Guide](/docs/contribute/style/content-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
@@ -172,7 +176,14 @@ changes. The quickest way to get answers to questions about how the documentatio
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` 聊天群组。
在对 Kubernetes 文档贡献了一段时间后，你可能会对[样式指南](/zh/docs/contribute/style/style-guide/)、
[内容指南](/zh/docs/contribute/style/content-guide/)、用于构建文档的工具链、网站样式、
评审和合并 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
@@ -185,14 +196,14 @@ documentation testing might involve working with 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 版本发布协调文档。
## 为 Kubernetes 版本发布协调文档工作
SIG Docs 的[批准者（approvers）](/zh/docs/contribute/participating/#approvers) 可以为
Kubernetes 版本发布协调文档工作。
<!--
Each Kubernetes release is coordinated by a team of people participating in the
@@ -202,14 +213,14 @@ 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)。
每一个 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.
@@ -224,7 +235,11 @@ SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
- Publish the documentation changes related to the release when the release
artifacts are published.
-->
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。
如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
- 定期参加 sig-release 会议并汇报文档的发布状态。
- 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。
- 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。
@@ -235,14 +250,11 @@ 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 轮流承担。
协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs 批准人轮流承担。
<!--
## Serve as a New Contributor Ambassador
-->
## 担任新的贡献者大使
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
New Contributor Ambassadors.
@@ -252,9 +264,14 @@ few PR submissions.
Responsibilities for New Contributor Ambassadors include:
-->
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新的贡献者大使。
新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，以及在前几份 PR 提交中指导新贡献者。
## 担任新的贡献者大使
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers)
可以担任新的贡献者大使。
新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，
以及在前几份 PR 提交中指导新贡献者。
新的贡献者大使的职责包括：
@@ -265,11 +282,11 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新
- 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) 上回答新贡献者的问题。
- 监听 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上新贡献者的 Issue。
- 与 PR 管理者合作为新参与者寻找合适的第一个 issues。
- 通过前几个 PR 指导新贡献者到文档存储库。
- 通过前几个 PR 指导新贡献者为文档存储库作贡献。
- 帮助新的贡献者创建成为 Kubernetes 成员所需的更复杂的 PR。
- [为贡献者提供担保](/docs/contribute/advanced/#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。
- [为贡献者提供保荐](#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).
@@ -278,14 +295,13 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
<!--
## Sponsor a new contributor
-->
## 为新的贡献者提供担保
<!--
SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
new contributors.
-->
SIG Docs 的 [reviewers](/docs/contribute/participating/#reviewers) 可以为新的贡献者提供担保。
## 为新的贡献者提供保荐 {#sponsor-a-new-contributor}
SIG Docs 的[评审人（Reviewers）](/zh/docs/contribute/participating/#reviewers) 可以为新的贡献者提供保荐。
<!--
After a new contributor has successfully submitted 5 substantive pull requests
@@ -294,7 +310,9 @@ to one or more Kubernetes repositories, they are eligible to apply for
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 的保荐。
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，
就有资格申请 Kubernetes 组织的[成员身份](/zh/docs/contribute/participating#members)。
贡献者的成员资格需要同时得到两位评审人的保荐。
<!--
New docs contributors can request sponsors by asking in the #sig-docs channel
@@ -305,7 +323,10 @@ 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 组织。
新的文档贡献者可以通过咨询 [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
@@ -316,7 +337,8 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term
-->
## 担任 SIG 联合主席
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任 SIG Docs 的联合主席。
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers)
可以担任 SIG Docs 的联合主席。
### 前提条件
@@ -332,9 +354,14 @@ Approvers must meet the following requirements to be a co-chair:
Approvers 必须满足以下要求才能成为联合主席：
- 已维持 SIG Docs approver 身份至少 6 个月
- [曾领导 Kubernetes 文档发布](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) 或者在两个版本发布中有实习经历
- [曾领导 Kubernetes 文档发布](/zh/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) 中的角色。
- 理解其他 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 个小时（通常更多）
<!--
@@ -361,11 +388,13 @@ Responsibilities include:
- Keep the SIG running smoothly
-->
- 保持 SIG Docs 专注于通过出色的文档最大限度地提高开发人员的满意度
- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 并要求 SIG 成员对自身行为负责
- 通过更新贡献准则，为 SIG 学习并设置最佳实践
- 以身作则，践行[社区行为准则](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 的身份招募和宣传
- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴
（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传
- 负责 SIG 正常运行
<!--
@@ -379,7 +408,7 @@ To schedule and run effective meetings, these guidelines show what to do, how to
-->
### 召开高效的会议
为了安排和召开高效的会议，这些准则说明了如何做、怎样做以及原因。
为了安排和召开高效的会议，这些指南说明了如何做、怎样做以及原因。
**坚持[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**：
@@ -470,4 +499,3 @@ The video uploads automatically to YouTube.
视频会自动上传到 YouTube。
content/zh/docs/contribute/intermediate.md
-1453
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/contribute/localization.md
+148 -127
View File
@@ -1,24 +1,24 @@
---
title: 本地化 Kubernetes 文档
content_type: concept
weight: 50
card:
name: contribute
weight: 30
name: 贡献
weight: 50
title: 翻译文档
---
<!--
---
title: Localizing Kubernetes Documentation
content_type: concept
approvers:
- remyleone
- rlenferink
- zacharysarah
weight: 50
card:
name: contribute
weight: 30
weight: 50
title: Translating the docs
---
-->
<!-- overview -->
@@ -26,9 +26,8 @@ card:
<!--
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/)。
此页面描述如何为其他语言的文档提供
[本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)版本。
<!-- body -->
@@ -39,11 +38,11 @@ Because contributors can't approve their own pull requests, you need at least tw
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
@@ -56,16 +55,19 @@ First, [create your own fork](/docs/contribute/start/#improve-existing-content)
-->
### 找到两个字母的语言代码
首先，有关本地化的两个字母的国家代码，请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。例如，韩国的两个字母代码是 `ko`。
首先，有关本地化的两个字母的国家代码，请参考
[ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。
例如，韩国的两个字母代码是 `ko`。
### fork 并且克隆仓库 {#fork-and-clone-the-repo}
### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo}
首先，在 [kubernetes/website](https://github.com/kubernetes/website) 仓库中的 [fork 你自己的分支](/docs/contribute/start/#improve-existing-content)。
首先，为 [kubernetes/website](https://github.com/kubernetes/website) 仓库
[创建你自己的副本](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
<!--
Then, clone your fork and `cd` into it:
-->
然后，克隆 website 仓库并通过 `cd` 命令进入 website 目录：
然后，克隆你的 website 仓库副本并通过 `cd` 命令进入 website 目录：
```shell
git clone https://github.com/<username>/website
@@ -81,46 +83,53 @@ The PR must include all of the [minimum required content](#minimum-required-cont
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）{#open-a-pull-request}
接下来，[提交 PR 请求](https://kubernetes.io/docs/contribute/start/#submit-a-pull-request)，将本地化添加到 `kubernetes/website` 仓库。
接下来，[提交 PR 请求](/zh/docs/contribute/new-content/open-a-pr/#open-a-pr)，
将本地化添加到 `kubernetes/website` 仓库。
PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。
该 PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。
有关添加新本地化的示例，请参见添加[法语文档](https://github.com/kubernetes/website/pull/12548) 的 PR。
### Join the Kubernetes GitHub organization
<!--
### 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)。
### 加入到 Kubernetes GitHub 组织
提交本地化 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/**/`.
Members of `@kubernetes/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.
The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs.
-->
### 在 GitHub 中添加您的本地化团队
### 在 GitHub 中添加你的本地化团队 {#add-your-localization-team-in-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。
接下来，将你的 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。
`@kubernetes/sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。
`sig-docs-**-reviews` 团队自动分派新 PR 的审阅任务。
`@kubernetes/sig-docs-**-reviews` 团队被自动分派新 PR 的审阅任务。
<!--
Members of `sig-docs-l10n-admins` can create new development branches to coordinate translation efforts.
Members of `@kubernetes/website-maintainers` 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` 成员可以创建新的开发分支来协调翻译工作。
`@kubernetes/website-maintainers` 成员可以创建新的开发分支来协调翻译工作。
`website-milestone-maintainers` 成员可以使用 `/milestone` [Prow 命令](https://prow.k8s.io/command-help) 为 issues 或 PR 设定里程碑。
`@kubernetes/website-milestone-maintainers` 成员可以使用 `/milestone`
[Prow 命令](https://prow.k8s.io/command-help) 为 issues 或 PR 设定里程碑。
<!--
### Configure the workflow
@@ -129,9 +138,10 @@ Next, add a GitHub label for your localization in the `kubernetes/test-infra` re
For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316).
-->
### 配置工作流程
### 配置工作流程 {#configure-the-workflow}
接下来，在 `kubernetes/test-infra` 仓库中为您的本地化添加一个 GitHub 标签。标签可让您过滤 issues 并提出针对特定语言的 pr。
接下来，在 `kubernetes/test-infra` 仓库中为您的本地化添加一个 GitHub 标签。
标签可让您过滤 issues 和针对特定语言的 PR。
有关添加标签的示例，请参见添加[意大利语标签](https://github.com/kubernetes/test-infra/pull/11316)的 PR。
@@ -144,9 +154,12 @@ You can also create a Slack channel for your localization in the `kubernetes/com
-->
### 寻找社区
让 Kubernetes SIG Docs 知道您对创建本地化感兴趣！ 加入[SIG Docs Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)。其他本地化团队很乐意帮助您入门并回答您的任何问题。
让 Kubernetes SIG Docs 知道你对创建本地化感兴趣！
加入[SIG Docs Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)。
其他本地化团队很乐意帮助你起步并回答你的任何问题。
您还可以在 `kubernetes/community` 存储库中为本地化创建一个 Slack 频道。有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。
你还可以在 `kubernetes/community` 仓库中为你的本地化创建一个 Slack 频道。
有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。
<!--
## Minimum required content
@@ -161,9 +174,12 @@ Add a configuration block for the new language to `config.toml`, under the exist
### 修改站点配置
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)文件中。为了支持新的本地化，您需要修改 `config.toml`。
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于
[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)文件中。
为了支持新的本地化，您需要修改 `config.toml`。
在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。例如，下面是德语的配置示例：
在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。
例如，下面是德语的配置示例：
```toml
[languages.de]
@@ -179,7 +195,7 @@ When assigning a `weight` parameter for your block, find the language block with
For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".
-->
为您的块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。
为你的语言块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。
有关 Hugo 多语言支持的更多信息，请参阅"[多语言模式](https://gohugo.io/content-management/multilingual/)"。
@@ -190,7 +206,9 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber
-->
### 添加一个新的本地化目录
将特定语言的子目录添加到仓库中的 [`content`](https://github.com/kubernetes/website/tree/master/content) 文件夹下。例如，德语的两个字母的代码是 `de`：
将特定语言的子目录添加到仓库中的
[`content`](https://github.com/kubernetes/website/tree/master/content) 文件夹下。
例如，德语的两个字母的代码是 `de`：
```shell
mkdir content/de
@@ -201,15 +219,15 @@ mkdir content/de
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 文件
在 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages)
仓库提交 PR，添加你所用语言版本的行为准则。
<!--
### Add a localized 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:
@@ -217,17 +235,23 @@ Provide guidance to localization contributors in the localized `README-**.md` fi
- 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 文件
为了指导其他本地化贡献者，请在 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/)或其他联系方式。您还必须提供指向本地化的社区行为准则的链接。
创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接，
并给出英文形式的联系信息。你可以提供 GitHub ID、电子邮件地址、
[Slack 频道](https://slack.com/)或其他联系方式。你还必须提供指向本地化的社区行为准则的链接。
<!--
### Setting up the OWNERS files
@@ -242,9 +266,14 @@ To set the roles of each user contributing to the localization, create an `OWNER
要设置每个对本地化做出贡献用户的角色，请在特定于语言的子目录内创建一个 `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)中创建的语言标签。
- **reviewers**: 具有评审人角色的 kubernetes 团队的列表，在本例中为在
[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github)
中创建的 `sig-docs-**-reviews` 团队。
- **approvers**: 具有批准人角色的 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).
@@ -253,9 +282,9 @@ The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), with la
-->
有关 `OWNERS` 文件的更多信息，请访问[go.k8s.io/owners](https://go.k8s.io/owners)。
带有语言代码 `es` 的[西班牙 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像：
语言代码为 `es` 的[西班牙语 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像：
<!--
```yaml
# See the OWNERS docs at https://go.k8s.io/owners
@@ -271,31 +300,19 @@ approvers:
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`。
添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 本地化团队、
`sig-docs-**-owners` 和 `sig-docs-**-reviews` 列表更新
[根目录下的 OWNERS_ALIAES](https://git.k8s.io/website/OWNERS_ALIASES) 文件。
对于每个团队，请按字母顺序添加[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github) 中请求的 GitHub 用户列表。
对于每个团队，请按字母顺序添加
[在 GitHub 中添加您的本地化团队](#add-your-localization-team-in-github)
中所请求的 GitHub 用户列表。
```diff
--- a/OWNERS_ALIASES
@@ -340,15 +357,17 @@ Site strings | [All site strings in a new localized TOML file](https://github.co
-->
描述 | 网址
-----|-----
主页 | [所有标题和副标题网址](/docs/home/)
安装 | [所有标题和副标题网址](/docs/setup/)
教程 | [Kubernetes 基础](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
主页 | [所有标题和副标题网址](/zh/docs/home/)
安装 | [所有标题和副标题网址](/zh/docs/setup/)
教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/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/` 文件夹下创建一个子文件夹并复制英文源：
翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。
例如，要准备将 [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/) 教程翻译为德语，
请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源：
```shell
mkdir -p content/de/docs/tutorials
@@ -391,32 +410,31 @@ The latest version is {{< latest-version >}}, so the most recent release branch
要查找最新版本的源文件：
1. 导航到 Kubernetes website 仓库，网址为 https://github.com/kubernetes/website。
2. 选择最新版本的 `release-1.X` 分支。
1. 选择最新版本的 `release-1.X` 分支。
最新版本是 {{< latest-version >}}，所以最新的发行分支是 [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。
最新版本是 {{< latest-version >}}，所以最新的发行分支是
[`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。
<!--
### Site strings in 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`.
Add a new localization file to `i18n/`. For example, with German (`de`):
Then translate the value of each string:
-->
### 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`。
本地化必须在新的语言特定文件中包含
[`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
@@ -436,22 +454,20 @@ Some language teams have their own language-specific style guide and glossary. F
-->
### 特定语言的样式指南和词汇表
一些语言团队有自己的特定语言风格指南和词汇表。例如，请参见[韩语本地化指南](/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.
@@ -464,14 +480,17 @@ To collaborate on a development branch:
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`。
1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers)
中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个开发分支。
当你给 `kubernetes/org` 仓库[添加你的本地化团队](#add-your-localization-team-in-github)时，
你的团队批准人便加入了 `@kubernetes/website-maintainers` 团队。
我们推荐以下分支命名方案：
我们推荐以下分支命名方案：
`dev-<source version>-<language code>.<team milestone>`
`dev-<source version>-<language code>.<team milestone>`
例如，一个德语本地化团队的 approvers 基于 Kubernetes v1.12 版本的源分支直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。
例如，一个德语本地化团队的批准人基于 Kubernetes v1.12 版本的源分支，
直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。
<!--
2. Individual contributors open feature branches based on the development branch.
@@ -482,79 +501,81 @@ To collaborate on a 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. 个人贡献者基于开发分支新建特性分支。
2. 个人贡献者基于开发分支创建新的特性分支
例如，一个德国贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。
例如，一个德语贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。
3. Approvers 审查功能分支并将其合并到开发分支中。
3. 批准人审查功能分支并将其合并到开发分支中。
4. approver 会定期打开并批准新的 pr，将开发分支合并到其源分支。在批准 pr 之前，请确保先 squash 提交。
4. 批准人会定期发起并批准新的 PR，将开发分支合并到其源分支。在批准 PR 之前，请确保先 squash commits。
<!--
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`，等等。
根据需要重复步骤 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 必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。开发分支的存在时间越长，通常需要的维护工作就越多。考虑定期合并开发分支并新建分支，而不是维护一个持续时间很长的开发分支。
团队必须将本地化内容合入到发布分支中，该发布分支也正是内容的来源。
例如，源于 {{< release-branch >}} 的开发分支必须基于 {{< release-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.
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）。不需要特殊权限。
在团队每个里程碑的起点，创建一个 issue 来比较先前的开发分支和当前的开发分支之间的上游变化很有帮助。
虽然只有批准人才能创建新的开发分支并合并 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)。
有关基于派生或直接从仓库开展工作的更多信息，请参见 ["派生和克隆"](#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) 到英文原文。
### 上游贡献 {#upstream-contributions}
Sig Docs 欢迎对英文原文的[上游贡献和修正](/zh/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.
Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review.
-->
## 帮助现有的本地化
<!--
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 来提供帮助。
您还可以向现有本地化添加或改进内容提供帮助。
加入本地化团队的 [Slack 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)，
然后开始新建 PR 来提供帮助。
请限制每个 PR 只涉及一种语言，这是因为更改多种语言版本内容的 PR
可能非常难审阅。
## {{% heading "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/).
-->
本地化满足工作流程和最低输出要求后，SIG 文档将：
- 在网站上启用语言选择
- 通过[Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) 频道, 包括[ Kubernetes 博客](https://kubernetes.io/blog/)公开本地化的可用性。
- 通过[Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) 频道,
包括[ Kubernetes 博客](https://kubernetes.io/blog/)公开本地化的可用性。
content/zh/docs/contribute/new-content/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: 贡献新内容
weight: 20
---
content/zh/docs/contribute/new-content/blogs-case-studies.md
+108
View File
@@ -0,0 +1,108 @@
---
title: 提交博客和案例分析
linktitle: 博客和案例分析
slug: blogs-case-studies
content_type: concept
weight: 30
---
<!--
title: Submitting blog posts and case studies
linktitle: Blogs and case studies
slug: blogs-case-studies
content_type: concept
weight: 30
-->
<!-- overview -->
<!--
Anyone can write a blog post and submit it for review.
Case studies require extensive review before they're approved.
-->
任何人都可以撰写博客并提交评阅。
案例分析则在被批准之前需要更多的评阅。
<!-- body -->
<!--
## Write a blog post
Blog posts should not be
vendor pitches. They must contain content that applies broadly to
the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
-->
## 撰写博文 {#write-a-blog-post}
博客内容不可以是销售用语。
其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
负责管理博客的评阅过程。
更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
<!--
To submit a blog post, you can either:
- Use the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- The front matter must include the following:
-->
要提交博文，你可以：
- 使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。
如果你要发起一个 PR，请确保所提交的博文遵从正确的命名规范和前言信息：
- Markdown 文件名必须遵从 `YYY-MM-DD-Your-Title-Here.md` 格式。
例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- 前言部分必须包含以下内容：
<!--
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
-->
```yaml
---
layout: blog
title: "博文标题"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
<!--
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
-->
## 提交案例分析
案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。
Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员
会与你一起工作，撰写所有的案例分析。
请查看
[现有案例分析](https://github.com/kubernetes/website/tree/master/content/en/case-studies)
的源码。
参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
根据指南中的注意事项提交你的 PR 请求。
## {{% heading "whatsnext" %}}
content/zh/docs/contribute/new-content/new-features.md
+267
View File
@@ -0,0 +1,267 @@
---
title: 为发行版本撰写功能特性文档
linktitle: 为发行版本撰写文档
content_type: concept
main_menu: true
weight: 20
card:
name: 贡献
weight: 45
title: 为发行版本撰写功能特性文档
---
<!--
title: Documenting a feature for a release
linktitle: Documenting for a release
content_type: concept
main_menu: true
weight: 20
card:
name: contribute
weight: 45
title: Documenting a feature for a release
-->
<!-- overview -->
<!--
Each major Kubernetes release introduces new features that require documentation.
New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
Generally, the SIG responsible for a feature submits draft documentation of the
feature as a pull request to the appropriate development branch of the
`kubernetes/website` repository, and someone on the SIG Docs team provides
editorial feedback or edits the draft directly. This section covers the branching
conventions and process used during a release by both groups.
-->
Kubernetes 的每个主要版本发布都会包含一些需要文档说明的新功能。
新的发行版本也会对已有功能特性和文档（例如将某功能特性从 alpha 升级为
beta）进行更新。
通常，负责某功能特性的 SIG 要为功能特性的文档草拟文档，并针对 `kubernetes/website`
仓库的合适的开发分支发起拉取请求。
SIG Docs 团队会提供文字方面的反馈意见，或者直接编辑文档草稿。
本节讨论两个小组在分支方面和发行期间所遵从的流程方面的约定。
<!-- body -->
<!--
## For documentation contributors
In general, documentation contributors don't write content from scratch for a release.
Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
After you've chosen a feature to document or assist, ask about it in the `#sig-docs`
Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
feature SIG. If you're given the go-ahead, you can edit into the PR using one of
the techniques described in
[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr).
-->
## 对于文档贡献者
一般而言，文档贡献者不会为某个发行版本从头撰写文档。
相反，他们会与开发该功能特性的 SIG 团队一起，对文档草稿进行润色，
使之符合发布条件。
在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上，
或者在功能特性对应的 PR 上提出咨询。
如果继续工作是没有问题的，你可以使用
[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr)
中描述的技术之一，参与 PR 的编辑工作。
<!--
### Find out about upcoming features
To find out about upcoming features, attend the weekly SIG Release meeting (see
the [community](https://kubernetes.io/community/) page for upcoming meetings)
and monitor the release-specific documentation
in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
directory. The sub-directory contains a release schedule, a draft of the release
notes, and a document listing each person on the release team.
-->
### 了解即将发布的功能特性
要了解即将发布的功能特性，可以参加每周的 SIG Release 例会
（参考[社区](https://kubernetes.io/community/)页面，了解即将召开的会议），
监视 [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
中与发行相关的文档。
每个发行版本在
[/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
下都有一个对应的子目录。
该子目录包含了发行版本的时间计划、发行公告的草稿以及列举发行团队名单的文档。
<!--
The release schedule contains links to all other documents, meetings,
meeting minutes, and milestones relating to the release. It also contains
information about the goals and timeline of the release, and any special
processes in place for this release. Near the bottom of the document, several
release-related terms are defined.
This document also contains a link to the **Feature tracking sheet**, which is
the official way to find out about all new features scheduled to go into the
release.
-->
发行时间计划文件中包含到所有其他文档、会议、会议记录及发行相关的里程碑的链接。
其中也包含关于发行版本的目标列表、时间线，以及当前发行版本中就绪的特殊流程的信息。
文档末尾附近定义了若干与该发行版本有关的术语。
此文档也包含到 **功能特性跟踪清单** 的链接。
这一清单是了解哪些功能特性计划进入某发行版本的正式途径。
<!--
The release team document lists who is responsible for each release role. If
it's not clear who to talk to about a specific feature or question you have,
either attend the release meeting to ask your question, or contact the release
lead so that they can redirect you.
The release notes draft is a good place to find out about
specific features, changes, deprecations, and more about the release. The
content is not finalized until late in the release cycle, so use caution.
-->
发行团队文档列举了哪些人扮演着各个发行版本的不同角色。
如果不清楚要联系谁来讨论特定的功能特性或者回答你的问题，
你可以参加发行团队的会议，提出你的问题，或者联系发行团队的牵头人，
这样他们就可以帮你找到正确的联系人。
发行说明草稿是用来发现与特定发行版本相关的功能特性、变更、废弃以及其他信息的好来源。
由于在发行周期的后段该文档的内容才会最终定稿，参考其中的信息时请谨慎。
<!--
### Feature tracking sheet
The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases)
lists each feature that is planned for a release.
Each line item includes the name of the feature, a link to the feature's main
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
individual responsible for implementing it, whether it
needs docs, a draft release note for the feature, and whether it has been
merged. Keep the following in mind:
-->
### 特性跟踪清单 {#feature-tracking-sheet}
针对[给定 Kubernetes 发行版本](https://github.com/kubernetes/sig-release/tree/master/releases)
特性跟踪清单中列举的是计划包含于该版本中的每个功能特性。
每一行中都包含特性的名称、特性对应的主要 GitHub Issue，其稳定性级别（ALpha、
Beta 或 Stable）、负责实现该特性的 SIG 和个人、是否该特性需要文档、该特性的
发行说明草稿以及该特性是否已经被合并等等。阅读此清单时请注意：
<!--
- Beta and Stable features are generally a higher documentation priority than
Alpha features.
- It's hard to test (and therefore to document) a feature that hasn't been merged,
or is at least considered feature-complete in its PR.
- Determining whether a feature needs documentation is a manual process and
just because a feature is not marked as needing docs doesn't mean it doesn't
need them.
-->
- Beta 和 Stable 功能特性通常比 Alpha 特性更为需要文档支持。
- 如果某功能特性尚未被合并，就很难测试或者为其撰写文档。
对于对应的 PR 而言，也很难讲特性是否完全实现。
- 确定某个功能特性是否需要对应的文档的过程是一个手动的过程。
即使某个功能特性没有标记需要文档，并不意味着该功能真的不需要任何文档。
<!--
## For developers or other SIG members
This section is information for members of other Kubernetes SIGs documenting new features
for a release.
If you are a member of a SIG developing a new feature for Kubernetes, you need
to work with SIG Docs to be sure your feature is documented in time for the
release. Check the
[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and
deadlines.
-->
## 针对开发人员或其他 SIG 成员
本节中的信息是针对为发行版本中新功能特性撰写文档的来自其他 Kubernetes SIGs
的成员。
如果你是某个 SIG 的成员，负责为 Kubernetes 开发某一项新的功能特性，你需要与
SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写文档。
请参考[特性跟踪清单](https://github.com/kubernetes/sig-release/tree/master/releases)
或者 Kubernetes Slack 上的 `#sig-release` 频道，检查时间安排的细节以及截止日期。
<!--
### Open a placeholder PR
1. Open a pull request against the
`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
commit that you will amend later.
2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
assign the PR to the relevant milestone. This alerts the docs person managing
this release that the feature docs are coming.
-->
### 提交占位 PR {#open-a-placeholder-pr}
1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}`
分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。
1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` 将 PR
指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有
新的功能特性要合并到将来版本。
<!--
If your feature does not need
any documentation changes, make sure the sig-release team knows this, by
mentioning it in the `#sig-release` Slack channel. If the feature does need
documentation but the PR is not created, the feature may be removed from the
milestone.
-->
如果对应的功能特性不需要任何类型的文档变更，请通过在 `#sig-release` Slack
频道声明这一点以确保 sig-release 团队了解。
如果功能特性确实需要文档，而没有对应的 PR
提交，该功能特性可能会被从里程碑中移除。
<!--
### PR ready for review
When ready, populate your placeholder PR with feature documentation.
Do your best to describe your feature and how to use it. If you need help
structuring your documentation, ask in the `#sig-docs` slack channel.
When you complete your content, the documentation person assigned to your
feature reviews it. Use their suggestions to get the content to a release
ready state.
If your feature needs documentation and the first draft content is not
received, the feature may be removed from the milestone.
-->
### PR 准备好评阅
时机成熟时，你可以在你的占位 PR 中完成功能特性文档。
尽可能为功能特性提供详尽文档以及使用说明。如果你需要文档组织方面的帮助，请
在 `#sig-docs` Slack 频道中提问。
当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。
尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。
如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅，
该特性可能会被从里程碑中移除。
<!--
### All PRs reviewed and ready to merge
If your PR has not yet been merged into the `dev-{{< skew nextMinorVersion >}}` branch by the release deadline, work with the
docs person managing the release to get it in by the deadline. If your feature needs
documentation and the docs are not ready, the feature may be removed from the
milestone.
If your feature is an Alpha feature and is behind a feature gate, make sure you
add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table
as part of your pull request. If your feature is moving out of Alpha, make sure to
remove it from that table.
-->
### 所有 PRs 均经过评审且合并就绪
如果你的 PR 在发行截止日期之前尚未合并到 `dev-{{< skew nextMinorVersion >}}` 分支，
请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。
如果功能特性需要文档，而文档并未就绪，该特性可能会被从里程碑中去除。
如果你的功能特性是 Alpha 阶段，并且受到某个特性门控的保护，在你的 PR 中，请确保将
该特性门控添加到
[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
表格中。
如果你的功能特性不再是 Alpha 阶段，请确保特性门控状态得到更新。
content/zh/docs/contribute/new-content/open-a-pr.md
+883
View File
@@ -0,0 +1,883 @@
---
title: 发起拉取请求（PR）
slug: new-content
content_type: concept
weight: 10
card:
name: 贡献
weight: 40
---
<!--
title: Opening a pull request
slug: new-content
content_type: concept
weight: 10
card:
name: contribute
weight: 40
-->
<!-- overview -->
<!--
{{< note >}}
**Code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, see
[Document a new feature](/docs/contribute/new-content/new-features/).
{{< /note >}}
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section.
-->
{{< note >}}
**代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性
撰写文档，请参考[为新功能撰写文档](/zh/docs/contribute/new-content/new-features/)。
{{< /note >}}
要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。
请确保你满足了[开始之前](/zh/docs/contribute/new-content/overview/#before-you-begin)
节中所列举的所有要求。
<!--
If your change is small, or you're unfamiliar with git, read [Changes using
GitHub](#changes-using-github) to learn how to edit a page.
If your changes are large, read [Work from a local fork](#fork-the-repo) to
learn how to make changes locally on your computer.
-->
如果你所提交的变更足够小，或者你对 git 工具不熟悉，可以阅读
[使用 GitHub 提交变更](#changes-using-github)以了解如何编辑页面。
如果所提交的变更较大，请阅读[基于本地克隆副本开展工作](#fork-the-repo)以学习
如何在你本地计算机上构造变更。
<!-- body -->
<!--
## Changes using GitHub
If you're less experienced with git workflows, here's an easier method of
opening a pull request.
1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**.
2. Make your changes in the GitHub markdown editor.
3. Below the editor, fill in the **Propose file change**
form. In the first field, give your commit message a title. In
the second field, provide a description.
-->
## 使用 GitHub 提交变更 {#changes-using-github}
如果你在 git 工作流方面欠缺经验，这里有一种发起拉取请求的更为简单的方法。
1. 在你发现问题的网页，选择右上角的铅笔图标。你也可以滚动到页面底端，选择
**编辑此页面**。
2. 在 GitHub 的 Markdown 编辑器中修改内容。
3. 在编辑器的下方，填写 **建议文件变更** 表单。
在第一个字段中，为你的提交消息取一个标题。
在第二个字段中，为你的提交写一些描述文字。
{{< note >}}
不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
你可以在后续的 PR 描述中使用这些关键词。
{{< /note >}}
<!--
4. Select **Propose file change**.
5. Select **Create pull request**.
6. The **Open a pull request** screen appears. Fill in the form:
- The **Subject** field of the pull request defaults to the commit summary.
You can change it if needed.
- The **Body** contains your extended commit message, if you have one,
and some template text. Add the
details the template text asks for, then delete the extra template text.
- Leave the **Allow edits from maintainers** checkbox selected.
-->
4. 选择 **Propose File Change**.
5. 选择 **Create pull request**.
6. 在 **Open a pull request** 屏幕上填写表单：
- **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。
- **Body** 字段包含更为详细的提交消息，如果你之前有填写过的话，以及一些模板文字。
填写模板所要求的详细信息，之后删除多余的模板文字。
- 确保 **Allow edits from maintainers** 复选框被勾选。
<!--
PR descriptions are a great way to help reviewers understand your change. For
more information, see [Opening a PR](#open-a-pr).
-->
{{< note >}}
PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。
更多信息请参考[发起一个 PR](#open-a-pr).
{{< /note >}}
<!-- 7. Select **Create pull request**. -->
7. 选择 **Create pull request**.
<!--
### Addressing feedback in GitHub
Before merging a pull request, Kubernetes community members review and
approve it. The `k8s-ci-robot` suggests reviewers based on the nearest
owner mentioned in the pages. If you have someone specific in mind,
leave a comment with their GitHub username in it.
-->
### 在 GitHub 上处理反馈意见
在合并 PR 之前，Kubernetes 社区成员会评阅并批准它。
`k8s-ci-robot` 会基于页面中最近提及的属主来建议评阅人（reviewers）。
如果你希望特定某人来评阅，可以留下评论，提及该用户的 GitHub 用户名。
<!--
If a reviewer asks you to make changes:
1. Go to the **Files changed** tab.
2. Select the pencil (edit) icon on any files changed by the
pull request.
3. Make the changes requested.
4. Commit the changes.
If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel.
When your review is complete, a reviewer merges your PR and your changes go live a few minutes later.
-->
如果某个评阅人请你修改 PR：
1. 前往 **Files changed** Tab 页面；
1. 选择 PR 所修改的任何文件所对应的铅笔（edit）图标；
1. 根据建议作出修改；
1. 提交所作修改。
如果你希望等待评阅人的反馈，可以每 7 天左右联系一次。
你也可以在 `#sig-docs` Slack 频道发送消息。
当评阅过程结束，某个评阅人会合并你的 PR。
几分钟之后，你所做的变更就会上线了。
<!--
## Work from a local fork {#fork-the-repo}
If you're more experienced with git, or if your changes are larger than a few lines,
work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
-->
## 基于本地克隆副本开展工作 {#work-from-a-local-fork}
如果你有 git 的使用经验，或者你要提议的修改不仅仅几行，请使用本地克隆副本
来开展工作。
首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。
你也可以使用 git 的带用户界面的应用。
<!--
### Fork the kubernetes/website repository
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **Fork**.
-->
### 派生 kubernetes/website 仓库
1. 前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库；
2. 选择 **Fork**.
<!--
### Create a local clone and set the upstream
3. In a terminal window, clone your fork:
-->
### 创建一个本地克隆副本并指定 upstream 仓库
3. 打开终端窗口，克隆你所派生的副本：
```bash
git clone git@github.com/<github_username>/website
```
<!--
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
-->
4. 前往新的 `website` 目录，将 `kubernetes/website` 仓库设置为 `upstream`
远端：
```bash
cd website
git remote add upstream https://github.com/kubernetes/website.git
```
<!--
5. Confirm your `origin` and `upstream` repositories:
-->
5. 确认你现在有两个仓库，`origin` 和 `upstream`：
```bash
git remote -v
```
<!-- Output is similar to: -->
输出类似于：
```bash
origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website (fetch)
upstream https://github.com/kubernetes/website (push)
```
<!--
6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
-->
6. 从你的克隆副本取回 `origin/master` 分支，从 `kubernetes/website` 取回 `upstream/master`：
```bash
git fetch origin
git fetch upstream
```
<!--
This makes sure your local repository is up to date before you start making changes.
-->
这样可以确保你本地的仓库在开始工作前是最新的。
<!--
This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork.
-->
{{< note >}}
此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。在推送你的变更到你的远程派生副本库之前，你不需要将你本地的 `master` 与 `upstream/master` 合并。
{{< /note >}}
<!--
### Create a branch
1. Decide which branch base to your work on:
- For improvements to existing content, use `upstream/master`.
- For new content about existing features, use `upstream/master`.
- For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that
effort.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
-->
### 创建一个分支
1. 决定你要基于哪个分支来开展工作：
- 针对已有内容的改进，请使用 `upstream/master`；
- 针对已有功能特性的新文档内容，请使用 `upstream/master`；
- 对于本地化内容，请基于本地化的约定。
可参考[对 Kubernetes 文档进行本地化](/zh/docs/contribute/localization/)了解详细信息。
- 对于在下一个 Kubernetes 版本中新功能特性的文档，使用独立的功能特性分支。
参考[为发行版本功能特性撰写文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
- 对于很多 SIG Docs 共同参与的，需较长时间才完成的任务，例如内容的重构，
请使用为该任务创建的特性分支。
如果你在选择分支上需要帮助，请在 `#sig-docs` Slack 频道提问。
<!--
2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`:
-->
2. 基于第一步中选定的分支，创建新分支。
下面的例子假定基础分支是 `upstream/master`：
```bash
git checkout -b <my_new_branch> upstream/master
```
<!--
3. Make your changes using a text editor.
-->
3. 使用文本编辑器开始构造变更。
<!--
At any time, use the `git status` command to see what files you've changed.
-->
在任何时候，都可以使用 `git status` 命令查看你所改变了的文件列表。
<!--
### Commit your changes
When you are ready to submit a pull request, commit your changes.
-->
### 提交你的变更
当你准备好发起拉取请求（PR）时，提交你所做的变更。
<!--
1. In your local repository, check which files you need to commit:
```bash
git status
```
Output is similar to:
```bash
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
```
-->
1. 在你的本地仓库中，检查你要提交的文件：
```bash
git status
```
输出类似于：
```bash
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
```
<!--
2. Add the files listed under **Changes not staged for commit** to the commit:
```bash
git add <your_file_name>
```
Repeat this for each file.
-->
2. 将 **Changes not staged for commit** 下列举的文件添加到提交中：
```bash
git add <your_file_name>
```
针对每个文件重复此操作。
<!--
3. After adding all the files, create a commit:
```bash
git commit -m "Your commit message"
```
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
-->
3. 添加完所有文件之后，创建一个提交（commit）：
```bash
git commit -m "Your commit message"
```
{{< note >}}
不要在提交消息中使用任何 [GitHub 关键字](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
你可以在后面创建 PR 时使用这些关键字。
{{< /note >}}
<!--
4. Push your local branch and its new commit to your remote fork:
```bash
git push origin <my_new_branch>
```
-->
4. 推送你本地分支及其中的新提交到你的远程派生副本库：
```bash
git push origin <my_new_branch>
```
<!--
### Preview your changes locally {#preview-locally}
It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems.
You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
-->
### 在本地预览你的变更 {#preview-locally}
在推送变更或者发起 PR 之前在本地查看一下预览是个不错的注意。
通过预览你可以发现构建错误或者 Markdown 格式问题。
你可以构造网站的容器镜像或者在本地运行 Hugo。
构造容器镜像的方式比较慢，不过能够显示 [Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)，
因此对于调试是很有用的。
{{< tabs name="tab_with_hugo" >}}
{{% tab name="在容器内执行 Hugo" %}}
<!--
The following commmand uses Docker as the default container engine.
You can set up the `CONTAINER_ENGINE` to override this behavior.
-->
{{< note >}}
下面的命令中使用 Docker 作为默认的容器引擎。
如果需要重载这一行为，可以设置 `CONTAINER_ENGINE`。
{{< /note >}}
<!--
1. Build the image locally:
-->
1. 在本地构造镜像；
```bash
# 使用 docker (默认)
make container-image
### 或 ###
# 使用 podman
CONTAINER_ENGINE=podman make container-image
```
<!--
2. After building the `kubernetes-hugo` image locally, build and serve the site:
-->
2. 在本地构造了 `kubernetes-hugo` 镜像之后，可以构造并启动网站：
```bash
# 使用 docker (默认)
make container-serve
### 或 ###
# 使用 podman
CONTAINER_ENGINE=podman make container-serve
```
<!--
3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
-->
3. 启动浏览器，浏览 `https://localhost:1313`。
Hugo 会监测文件的变更并根据需要重新构建网站。
4. 要停止本地 Hugo 实例，可返回到终端并输入 `Ctrl+C`，或者关闭终端窗口。
{{% /tab %}}
{{% tab name="在命令行执行 Hugo" %}}
<!--
Alternately, install and use the `hugo` command on your computer:
-->
另一种方式是，在你的本地计算机上安装并使用 `hugo` 命令：
<!--
1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
2. In a terminal, go to your Kubernetes website repository and start the Hugo server:
-->
1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)
文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。
2. 启动一个终端窗口，进入 Kubernetes 网站仓库目录，启动 Hugo 服务器：
```bash
cd <path_to_your_repo>/website
hugo server
```
<!--
3. In your browser’s address bar, enter `https://localhost:1313`.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
-->
3. 在浏览器的地址栏输入： `https://localhost:1313`。
4. 要停止本地 Hugo 实例，返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
{{% /tab %}}
{{< /tabs >}}
<!--
### Open a pull request from your fork to kubernetes/website {#open-a-pr}
-->
### 从你的克隆副本向 kubernetes/website 发起拉取请求（PR） {#open-a-pr}
<!--
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**.
3. Select **compare across forks**.
4. From the **head repository** drop-down menu, select your fork.
5. From the **compare** drop-down menu, select your branch.
6. Select **Create Pull Request**.
7. Add a description for your pull request:
- **Title** (50 characters or less): Summarize the intent of the change.
- **Description**: Describe the change in more detail.
- If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well.
- If you want advice on something specific, include any questions you'd like reviewers to think about in your description.
8. Select the **Create pull request** button.
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
-->
1. 在 Web 浏览器中，前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库；
2. 点击 **New Pull Request**；
3. 选择 **compare across forks**；
4. 从 **head repository** 下拉菜单中，选取你的派生仓库；
5. 从 **compare** 下拉菜单中，选择你的分支；
6. 点击 **Create Pull Request**；
7. 为你的拉取请求添加一个描述：
- **Title** （不超过 50 个字符）：总结变更的目的；
- **Description**：给出变更的详细信息；
- 如果存在一个相关联的 GitHub Issue，可以在描述中包含 `Fixes #12345` 或
`Closes #12345`。GitHub 的自动化设施能够在当前 PR 被合并时自动关闭所提及
的 Issue。如果有其他相关联的 PR，也可以添加对它们的链接。
- 如果你尤其希望获得某方面的建议，可以在描述中包含你希望评阅人思考的问题。
8. 点击 **Create pull request** 按钮。
祝贺你! 你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了！
<!--
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
- If the Netlify build fails, select **Details** for more information.
- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes.
GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
-->
在发起 PR 之后，GitHub 会执行一些自动化的测试，并尝试使用
[Netlify](https://www.netlify.com/) 部署一个预览版本。
- 如果 Netlify 构建操作失败，可选择 **Details** 了解详细信息。
- 如果 Netlify 构建操作成功，选择 **Details** 会打开 Kubernetes 的一个预览
版本，其中包含了你所作的变更。评阅人也使用这一功能来检查你的变更。
GitHub 也会自动为 PR 分派一些标签，以帮助评阅人。
如果有需要，你也可以向 PR 添加标签。
欲了解相关详细信息，可以参考
[添加和删除 Issue 标签](/zh/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)。
<!--
### Addressing feedback locally
1. After making your changes, amend your previous commit:
-->
### 在本地处理反馈
1. 在本地完成修改之后，可以修补（amend）你之前的提交：
```bash
git commit -a --amend
```
<!--
- `-a`: commits all changes
- `--amend`: amends the previous commit, rather than creating a new one
-->
- `-a`：提交所有修改
- `--amend`：对前一次提交进行增补，而不是创建新的提交
<!--
2. Update your commit message if needed.
3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
-->
2. 如果有必要，更新你的提交消息；
3. 使用 `git push origin <my_new_branch>` 来推送你的变更，重新出发 Netlify 测试。
<!--
If you use `git commit -m` instead of amending, you must
[squash your commits](#squashing-commits) before merging.
-->
{{< note >}}
如果你使用 `git commit -m` 而不是增补参数，在 PR 最终合并之前你必须
[squash 你的提交](#squashing-commits)。
{{< /note >}}
<!--
#### Changes from reviewers
Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits.
1. Fetch commits from your remote fork and rebase your working branch:
-->
#### 来自评阅人的修改
有时评阅人会向你的 PR 中提交修改。在作出其他修改之前，请先取回这些提交。
1. 从你的远程派生副本仓库取回提交，让你的工作分支基于所取回的分支：
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
<!--
2. After rebasing, force-push new changes to your fork:
-->
2. 变更基线（rebase）操作完成之后，强制推送本地的新改动到你的派生仓库：
```bash
git push --force-with-lease origin <your-branch-name>
```
<!--
#### Merge conflicts and rebasing
{{< note >}}
For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
-->
#### 合并冲突和重设基线
{{< note >}}
要了解更多信息，可参考
[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、
[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)、
或者在 `#sig-docs` Slack 频道寻求帮助。
{{< /note >}}
<!--
If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR.
1. Update your fork and rebase your local branch:
-->
如果另一个贡献者在别的 PR 中提交了对同一文件的修改，这可能会造成合并冲突。
你必须在你的 PR 中解决所有合并冲突。
1. 更新你的派生副本，重设本地分支的基线：
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
<!-- Then force-push the changes to your fork:-->
之后强制推送修改到你的派生副本仓库：
```bash
git push --force-with-lease origin <your-branch-name>
```
<!--
2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
-->
2. 从 `kubernetes/website` 的 `upstream/master` 分支取回更改，然后重设本地分支的基线：
```bash
git fetch upstream
git rebase upstream/master
```
<!--
3. Inspect the results of the rebase:
-->
3. 检查重设基线操作之后的状态：
```bash
git status
```
<!-- This results in a number of files marked as conflicted. -->
你会看到一组存在冲突的文件。
<!--
4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker.
-->
4. 打开每个存在冲突的文件，查找冲突标记：`>>>`、`<<<` 和 `===`。
解决完冲突之后删除冲突标记。
<!--
For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
-->
{{< note >}}
进一步的详细信息可参见
[冲突是怎样表示的](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
{{< /note >}}
<!--
5. Add the files to the changeset:
-->
5. 添加文件到变更集合：
```bash
git add <filename>
```
<!--
6. Continue the rebase:
-->
6. 继续执行基线变更（rebase）操作：
```bash
git rebase --continue
```
<!--
7. Repeat steps 2 to 5 as needed.
After applying all commits, the `git status` command shows that the rebase is complete.
-->
7. 根据需要重复步骤 2 到 5。
在应用完所有提交之后，`git status` 命令会显示 rebase 操作完成。
<!--
8. Force-push the branch to your fork:
-->
8. 将分支强制推送到你的派生仓库：
```bash
git push --force-with-lease origin <your-branch-name>
```
<!-- The pull request no longer shows any conflicts. -->
PR 不再显示存在冲突。
<!--
### Squashing commits
-->
### 压缩（Squashing）提交 {#squashing-commits}
<!--
For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help.
-->
{{< note >}}
要了解更多信息，可参看
[Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)，
或者在 `#sig-docs` Slack 频道寻求帮助。
{{< /note >}}
<!--
If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally.
-->
如果你的 PR 包含多个提交（commits），你必须将其压缩成一个提交才能被合并。
你可以在 PR 的 **Commits** Tab 页面查看提交个数，也可以在本地通过
`git log` 命令查看提交个数。
<!-- This topic assumes `vim` as the command line text editor.-->
{{< note >}}
本主题假定使用 `vim` 作为命令行文本编辑器。
{{< /note >}}
<!--
1. Start an interactive rebase:
-->
1. 启动一个交互式的 rebase 操作：
```bash
git rebase -i HEAD~<number_of_commits_in_branch>
```
<!--
Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase.
-->
压缩提交的过程也是一种重设基线的过程。
这里的 `-i` 开关告诉 git 你希望交互式地执行重设基线操作。
`HEAD~<number_of_commits_in_branch` 表明在 rebase 操作中查看多少个提交。
<!--Output is similar to:-->
输出类似于；
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
# Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
...
# These lines can be re-ordered; they are executed from top to bottom.
```
<!--
The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete.
For the purposes of rebasing, focus on `squash` and `pick`.
-->
输出的第一部分列举了重设基线操作中的提交。
第二部分给出每个提交的选项。
改变单词 `pick` 就可以改变重设基线操作之后提交的状态。
就重设基线操作本身，我们关注 `squash` 和 `pick` 选项。
<!--
For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
-->
{{< note >}}
进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。
{{< /note >}}
<!--
2. Start editing the file.
Change the original text:
-->
2. 开始编辑文件。
修改原来的文本：
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
```
<!-- To: -->
使之成为：
```bash
pick d875112ca Original commit
squash 4fa167b80 Address feedback 1
squash 7d54e15ee Address feedback 2
```
<!--
This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline.
-->
以上编辑操作会压缩提交 `4fa167b80 Address feedback 1` 和 `7d54e15ee Address feedback 2`
到 `d875112ca Original commit` 中，只留下 `d875112ca Original commit` 成为时间线中的一部分。
<!--
3. Save and exit your file.
4. Push your squashed commit:
-->
3. 保存文件并退出编辑器。
4. 推送压缩后的提交：
```bash
git push --force-with-lease origin <branch_name>
```
<!--
## Contribute to other repos
The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments.
If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization.
This can help you figure out where to submit your issue or PR.
-->
## 贡献到其他仓库
[Kubernetes 项目](https://github.com/kubernetes)包含大约 50 多个仓库。
这些仓库中很多都有文档：提供给最终用户的帮助文本、错误信息、API 参考或者代码注释等。
如果你发现有些文本需要改进，可以使用 GitHub 来搜索 Kubernetes 组织下的所有仓库。
这样有助于发现要在哪里提交 Issue 或 PR。
<!--
Each repository has its own processes and procedures. Before you file an
issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and
`code-of-conduct.md`, if they exist.
Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
-->
每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前，记得阅读仓库的
`README.md`、`CONTRIBUTING.md` 和 `code-of-conduct.md` 文件，如果有的话。
大多数仓库都有自己的 Issue 和 PR 模版。通过查看一些待解决的 Issues 和
PR，也可以添加对它们的链接。你可以多少了解该团队的流程。
在登记 Issue 或提出 PR 时，务必尽量填充所给的模版，多提供详细信息。
## {{% heading "whatsnext" %}}
<!--
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
-->
- 阅读[评阅](/zh/docs/contribute/review/revewing-prs)节，学习评阅过程。
content/zh/docs/contribute/new-content/overview.md
+122
View File
@@ -0,0 +1,122 @@
---
title: 贡献新内容概述
linktitle: 概述
content_type: concept
main_menu: true
weight: 5
---
<!--
title: Contributing new content overview
linktitle: Overview
content_type: concept
main_menu: true
weight: 5
-->
<!-- overview -->
<!--
This section contains information you should know before contributing new content.
-->
本节包含贡献新内容之前你需要知晓的一些信息。
<!-- body -->
<!--
## Contributing basics
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
- 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 or starting a new translation, see [localization](/docs/contribute/localization).
-->
## 基本知识
- 使用 Markdown 来编写 Kubernetes 文档并使用 [Hugo](https://gohugo.io/) 来构建网站
- 源代码位于 [GitHub](https://github.com/kubernetes/website) 仓库中。
你可以在 `/content/en/docs/` 目录下找到 Kubernetes 文档。
某些参考文档是使用位于 `update-imported-docs/` 目录下的脚本自动生成的。
- [页面内容类型](/zh/docs/contribute/style/page-content-types/)使用 Hugo 描述文档内容的表现。
- 除了基本的 Hugo 短代码（shortcodes）外，我们还在文档中使用一些
[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)以控制内容的表现。
- 文档的源代码有多种语言形式，位于`/content/` 目录下。
每种语言都有自己的由两个字母代表的目录，这两个字母是基于
[ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。
例如，英语文档源码位于`/content/en/docs/` 目录下。
- 关于在多种语言中为文档做贡献的详细信息，以及如何启动一种新的语言翻译，
可参考[本地化](/zh/docs/contribute/localization)文档。
<!--
## Before you begin {#before-you-begin}
### Sign the CNCF CLA {#sign-the-cla}
All Kubernetes contributors **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).
Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
-->
## 开始之前 {#before-you-begin}
### 签署 CNCF CLA {#sign-the-cla}
所有 Kubernetes 贡献者 **必须** 阅读
[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
并[签署贡献者授权同意书（Contributor License Agreement，CLA）](https://github.com/kubernetes/community/blob/master/CLA.md)。
来自尚未签署 CLA 的贡献者的 PR 无法通过自动化服务的测试。
你所提供的姓名和邮件地址必须与 `git config` 中所找到的完全相同，
而且你的 git 用户名和邮件地址必须与用来签署 CNCF CLA 的一致。
<!--
### Choose which Git branch to use
When opening a pull request, you need to know in advance which branch to base your work on.
Scenario | Branch
:---------|:------------
Existing or new English language content for the current release | `master`
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
-->
### 选择要使用的分支
在发起拉取请求时，你需要预先知道要基于哪个分支来开展工作。
场景 | 分支
:---------|:------------
针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `master`
针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-release-<version>`。例如，如果某功能特性在 `{{< latest-version >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< release-branch >}}` 分支。
其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。
如果你仍不能确定要选择哪个分支，请在 `#sig-docs` Slack 频道上提问。
<!--
If you already submitted your pull request and you know that the base branch
was wrong, you (and only you, the submitter) can change it.
-->
{{< note >}}
如果你已经提交了你的 PR，并且你发现所针对的分支选错了，你（且只能是你）可以重新选择分支。
{{< /note >}}
<!--
### Languages per PR
Limit pull requests to one language per PR. 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。
<!--
## Tools for contributors
The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
-->
## 为贡献者提供的工具
`kubernetes/website` 仓库的
[文档贡献者工具](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools)
目录中包含了一些工具，能够助你的贡献过程更为顺畅。
content/zh/docs/contribute/participate/_index.md
+225
View File
@@ -0,0 +1,225 @@
---
title: 参与 SIG Docs
content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
<!--
title: Participating in SIG Docs
content_type: concept
weight: 60
card:
name: contribute
weight: 60
-->
<!-- 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 项目
[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md)
中的一个，负责编写、更新和维护 Kubernetes 的总体文档。
参见[社区 GitHub 仓库中 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
以进一步了解该 SIG。
<!--
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 进行评论。
<!--
You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#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.
-->
你也可以成为[成员（member）](/docs/contribute/participating/roles-and-responsibilities/#members)、
[评阅人（reviewer）](/docs/contribute/participating/roles-and-responsibilities/#reviewers) 或者
[批准人（approver）](/docs/contribute/participating/roles-and-responsibilities/#approvers)。
这些角色拥有更高的权限，且需要承担批准和提交变更的责任。
有关 Kubernetes 社区中的成员如何工作的更多信息，请参见
[社区成员身份](https://github.com/kubernetes/community/blob/master/community-membership.md)。
本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。
SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。
<!-- body -->
<!--
#### SIG Docs chairperson
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 Docs 主席
每个 SIG，包括 SIG Docs，都会选出一位或多位成员作为主席。
主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。
他们需要了解整个 Kubernetes 项目的架构，并明白 SIG Docs 如何在其中运作。
如需查询当前的主席名单，请查阅
[领导人员](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。
<!--
## SIG Docs teams and automation
Automation in SIG Docs relies on two different mechanisms for automation:
GitHub groups and OWNERS files.
-->
## SIG Docs 团队和自动化 {#sig-docs-teams-and-automation}
SIG 文档中的自动化服务依赖于两种不同的自动化机制:
GitHub 组和 OWNERS 文件。
<!--
### GitHub teams
There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub:
- `@sig-docs-{language}-owners` are approvers and leads
- `@sig-docs-{language}-reviewers` are reviewers
Each can be referenced with their `@name` in GitHub comments to communicate with
everyone in that group.
Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals,
the automation uses information from `OWNERS` files.
-->
### GitHub 团队 {#github-teams}
GitHub 上有两类 SIG Docs 团队：
- `@sig-docs-{language}-owners` 包含批准人和牵头人
- `@sig-docs-{language}-reviewers` 包含评阅人
可以在 GitHub 的评论中使用团队的名称 `@name` 来与团队成员沟通。
有时候 Prow 所定义的团队和 GitHub 团队有所重叠，并不完全一致。
对于指派 Issue、PR 和批准 PR，自动化工具使用来自 `OWNERS` 文件的信息。
<!--
### OWNERS files and front-matter
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):
-->
### OWNERS 文件和扉页
Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。
[Kubernetes website 仓库](https://github.com/kubernetes/website) 使用了两个
[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins)：
- 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)
文件来控制 prow 在仓库范围的工作方式。
<!--
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 评阅人和批准人的列表。
OWNERS 文件也可以存在于子目录中，可以在子目录层级重新设置哪些人可以作为评阅人和
批准人，并将这一设定传递到下层子目录。
关于 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.
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.
-->
此外，每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人，
每一项可以是 GitHub 用户名，也可以是 GitHub 组名。
结合 OWNERS 文件及 Markdown 文件的前言信息，自动化系统可以给 PR 作者可以就应该
向谁请求技术和文字评阅给出建议。
<!--
## How merging works
When a pull request is merged to the branch used to publish content, that content
is published to http://kubernetes.io. 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.
- When a pull request has both the `lgtm` and `approve` labels, has no `hold`
labels, and all tests are passing, 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 SIG Docs approvers can merge a pull request
by adding an `/approve` comment. Some approvers also perform additional
specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
[SIG Docs chairperson](#sig-docs-chairperson).
-->
## PR 是怎样被合并的 {#how-merging-works}
当某个拉取请求（PR）被合并到用来发布内容的分支，对应的内容就会被发布到 http://kubernetes.io。
为了确保我们所发布的内容的质量足够好，合并 PR 的权限仅限于
SIG Docs 批准人。下面是合并的工作机制：
- 当某个 PR 同时具有 `lgtm` 和 `approve` 标签，没有 `hold` 标签且通过所有测试时，
该 PR 会被自动合并。
- Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并，
即通过 `/hold` 评论或者收回某个 `/lgtm` 评论实现这点。
- 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。
- 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。
某些批准人还会执行一些其他角色，例如
[PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 或
[SIG Docs 主席](#sig-docs-chairperson)等。
## {{% heading "whatsnext" %}}
<!--
For more information about contributing to the Kubernetes documentation, see:
- [Contributing new content](/docs/contribute/overview/)
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
-->
关于贡献 Kubernetes 文档的更多信息，请参考：
- [贡献新内容](/docs/contribute/overview/)
- [评阅内容](/docs/contribute/review/reviewing-prs)
- [文档样式指南](/docs/contribute/style/)
content/zh/docs/contribute/participate/roles-and-responsibilties.md
+409
View File
@@ -0,0 +1,409 @@
---
title: 角色与责任
content_type: concept
weight: 10
---
<!-- overview -->
<!--
Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
These roles allow you to take on more responsibility within the community.
Each role requires more time and commitment. The roles are:
- Anyone: regular contributors to the Kubernetes documentation
- Members: can assign and triage issues and provide non-binding review on pull requests
- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
- Approvers: can lead reviews on documentation and merge changes
-->
任何人都可以为 Kubernetes 作出贡献。随着你对 SIG Docs 的贡献增多，你可以申请
社区内不同级别的成员资格。
这些角色使得你可以在社区中承担更多的责任。
每个角色都需要更多的时间和投入。具体包括：
- 任何人（Anyone）：为 Kubernetes 文档作出贡献的普通贡献者。
- 成员（Members）：可以对 Issue 进行分派和判别，对 PR 提出无约束性的评审意见。
- 评审人（Reviewers）：可以领导对文档 PR 的评审，可以对变更的质量进行判别。
- 批准人（Approvers）：可以领导对文档的评审并合并变更。
<!-- body -->
<!--
## Anyone
Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
Anyone can:
- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
- Give non-binding feedback on a pull request
- Contribute to a localization
- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
- Open a pull request to improve existing content, add new content, or write a blog post or case study
- Create diagrams, graphics assets, and embeddable screencasts and videos
For more information, see [contributing new content](/docs/contribute/new-content/).
-->
## 任何人（Anyone） {#anyone}
任何拥有 GitHub 账号的人都可以对 Kubernetes 作出贡献。SIG Docs
欢迎所有新的贡献者。
任何人都可以：
- 在任何 [Kubernetes](https://github.com/kubernetes/) 仓库，包括
[`kubernetes/website`](https://github.com/kubernetes/website) 上报告 Issue。
- 对某 PR 给出无约束力的反馈信息
- 为本地化提供帮助
- 在 [Slack](http://slack.k8s.io/) 或
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
上提出改进建议。
在[签署了 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 之后，任何人还可以：
- 发起拉取请求（PR），改进现有内容、添加新内容、撰写博客或者案例分析
- 创建示意图、图形资产或者嵌入式的截屏和视频内容
进一步的详细信息，可参见[贡献新内容](/zh/docs/contribute/new-content/)。
<!--
## Members
A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
Members can:
- Do everything listed under [Anyone](#anyone)
- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
{{< note >}}
Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
{{< /note >}}
- Use the `/hold` comment to block merging for a pull request
- Use the `/assign` comment to assign a reviewer to a pull request
- Provide non-binding review on pull requests
- Use automation to triage and categorize issues
- Document new features
-->
## 成员（Members） {#members}
成员是指那些对 `kubernetes/website` 提交很多拉取请求（PR）的人。
成员都要加入 [Kubernetes GitHub 组织](https://github.com/kubernetes)。
成员可以：
- 执行[任何人](#anyone)节区所列举操作
- 使用 `/lgtm` 评论添加 LGTM (looks good to me（我觉得可以）) 标签到某个 PR
{{< note >}}
使用 `/lgtm` 会触发自动化机制。如果你希望提供不拘约束力的批准意见，
直接回复 "LGTM" 也是可以的。
{{< /note >}}
- 利用 `/hold` 评论来阻止某个 PR 被合并
- 使用 `/assign` 评论为某个 PR 指定评审人
- 对 PR 提供非约束性的评审意见
- 使用自动化机制来对 Issue 进行判别和分类
- 为新功能特性撰写文档
<!--
### Becoming a member
After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
-->
### 成为一个成员 {#becoming-a-member}
在你成功地提交至少 5 个 PR 并满足
[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
之后：
<!--
1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
Ask for sponsorship in the [#sig-docs channel on Slack](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. You must request sponsorship before submitting your application.
{{< /note >}}
2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-->
1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供
[担保](/docs/contribute/advanced#sponsor-a-new-contributor)。
通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
来寻找为你担保的人。
{{< note >}}
不要单独发送邮件给某个 SIG Docs 成员或在 Slack 中与其私聊。
在提交申请之前，一定要先确定担保人。
{{< /note >}}
2. 在 [`kubernetes/org`](https://github.com/kubernetes/org/) 仓库
使用 **Organization Membership Request** Issue 模版登记一个 Issue。
<!--
3. Let your sponsors know about the GitHub issue. You can either:
- Mention their GitHub username in an issue (`@<GitHub-username>`)
- Send them the issue link using Slack or email.
Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
4. Accept the invitation to the Kubernetes GitHub organization in your email account.
{{< note >}}
GitHub sends the invitation to the default email address in your account.
{{< /note >}}
-->
3. 告知你的担保人你所创建的 Issue，你可以：
- 在 Issue 中 `@<GitHub-username>` 提及他们的 GitHub 用户名
- 通过 Slack 或 email 直接发送给他们 Issue 链接
担保人会通过 `+1` 投票来批准你的请求。一旦你的担保人批准了该请求，
某个 Kubernetes GitHub 管理员会将你添加为组织成员。恭喜！
如果你的成员请求未被接受，你会收到一些反馈。
当处理完反馈意见之后，可以再次发起申请。
4. 在你的邮件账户中接受来自 Kubernetes GitHub 组织发出的成员邀请。
{{< note >}}
GitHub 会将邀请发送到你的账户中所设置的默认邮件地址。
{{< /note >}}
<!--
## Reviewers
Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
Reviewers can:
- Do everything listed under [Anyone](#anyone) and [Members](#members)
- Review pull requests and provide binding feedback
{{< note >}}
To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
{{< /note >}}
- Edit user-facing strings in code
- Improve code comments
You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
-->
## 评审人（Reviewers） {#reviewers}
评审人负责评审悬决的 PR。
与成员所给的反馈不同，你必须处理评审人的反馈。
评审人是 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 团队的成员。
评审人可以：
- 执行[任何人](#anyone)和[成员](#members)节所列举的操作
- 评审 PR 并提供具约束性的反馈信息
{{< note >}}
要提供非约束性的反馈，可以在你的评语之前添加 "Optionally: " 这样的说法。
{{< /note >}}
- 编辑代码中用户可见的字符串
- 改进代码注释
你可以是 SIG Docs 的评审人，也可以是某个主题领域的文档的评审人。
<!--
### Assigning reviewers to pull requests
Automation assigns reviewers to all pull requests. You can request a
review from a specific person by commenting: `/assign
[@_github_handle]`.
If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
### Using `/lgtm`
LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
-->
### 为 PR 指派评审人 {#assigning-reviewers-to-pull-requests}
自动化引擎会为每个 PR 自动指派评审人。
你可以通过为 PR 添加评论 `/assign [@_github_handle]` 来请求某个特定评审人来评审。
如果所指派的评审人未能及时评审，其他的评审人也可以参与进来。
你可以根据需要指派技术评审人。
### 使用 `/lgtm`
LGTM 代表的是 “Looks Good To Me （我觉得可以）”，用来标示某个 PR
在技术上是准确的，可以被合并。
所有 PR 都需要来自某评审人的 `/lgtm` 评论和来自某批准人的 `/approve`
评论。
来自评审人的 `/lgtm` 评论是具有约束性的，会触发自动化设施添加 `lgtm` 标签。
<!--
### Becoming a 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.
To apply:
-->
### 成为评审人 {#becoming-a-reviewer}
当你满足[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时，
你可以成为一个 SIG Docs 评审人。
来自其他 SIG 的评审人必须为 SIG Docs 单独申请评审人资格。
申请过程如下：
<!--
1. Open a pull request that adds your GitHub user name to a section of the
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
in the `kubernetes/website` repository.
{{ note }}
If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
{{ /note }}
2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-->
1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
文件的特定节。
{{ note }}
如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-reviews`。
{{ /note }}
2. 将 PR 指派给一个或多个 SIG Docs 批准人（`sig-docs-{language}-owners`
下列举的用户名）。
请求被批准之后，SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。
一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
<!--
## Approvers
Approvers review and approve pull requests for merging. Approvers are members of the
[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
-->
## 批准人（Approvers） {#approvers}
批准人负责评审和批准 PR 以将其合并。
批准人是 [@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 团队的成员。
<!--
Approvers can do the following:
- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
- Publish contributor content by approving and merging pull requests using the `/approve` comment
- Propose improvements to the style guide
- Propose improvements to docs tests
- Propose improvements to the Kubernetes website or other tooling
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.
-->
批准人可以执行以下操作：
- 执行列举在[任何人](#anyone)、[成员](#members)和[评审人](#reviewers)节区的操作
- 通过使用 `/approve` 评论来批准、合并 PRs，发布贡献者所贡献的内容。
- 就样式指南给出改进建议
- 对文档测试给出改进建议
- 对 Kubernetes 网站或其他工具给出改进建议
如果某个 PR 已有 `/lgtm` 标签，或者批准人再回复一个 `/lgtm` ，则这个 PR 会自动合并。
SIG Docs 批准人应该只在不需要额外的技术评审的情况下才可以标记 `/lgtm`。
<!--
### Approving pull requests
Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
- Approvers can use the `/approve` command, which merges PRs into the repo.
{{< warning >}}
A careless merge can break the site, so be sure that when you merge something, you mean it.
{{< /warning >}}
- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
If you ever have a question, or you're not sure about something, feel free to call for additional review.
-->
### 批准 PR {#approving-pull-requests}
只有批准人和 SIG Docs Leads 可以将 PR 合并到网站仓库。
这意味着以下责任：
- 批准人可以使用 `/approve` 命令将 PR 合并到仓库中。
{{< warning >}}
不小心的合并可能会破坏整个站点。在执行合并操作时，务必小心。
{{< /warning >}}
- 确保所提议的变更满足[贡献指南](/docs/contribute/style/content-guide/#contributing-content)要求
如果有问题或者疑惑，可以根据需要请他人帮助评审。
- 在 `/approve` PR 之前，须验证 Netlify 测试是否正常通过。
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须通过 Netlify 测试" />
- 在批准之前，请访问 Netlify 的页面预览来确保变更内容可正常显示。
- 参与 [PR 管理者轮值排班](https://github.com/kubernetes/website/wiki/PR-Wranglers)
执行时长为一周的 PR 管理。SIG Docs 期望所有批准人都参与到此轮值工作中。
更多细节可参见[做一周的 PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)。
<!--
### Becoming an 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.
-->
### 成为批准人 {#becoming-an-approver}
当你满足[一定条件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)时，可以成为一个 SIG Docs 批准人。
来自其他 SIGs 的批准人也必须在 SIG Docs 独立申请批准人资格。
<!--
To apply:
1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
{{ note }}
If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
{{ /note }}
2. Assign the PR to one or more current SIG Docs approvers.
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-->
申请流程如下：
1. 发起一个 PR，将自己添加到 `kubernetes/website` 仓库中
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
文件的对应节区。
{{ note }}
如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-owners` 中。
{{ /note }}
2. 将 PR 指派给一个或多个 SIG Docs 批准人。
请求被批准之后，SIG Docs Leads 之一会将你添加到对应的 GitHub 团队。
一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
content/zh/docs/contribute/participating.md
-533
View File
@@ -1,533 +0,0 @@
---
title: 参与 SIG Docs
content_type: concept
card:
name: contribute
weight: 40
---
<!-- 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 网站和文档。
<!-- 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 作者提供向谁请求检视的建议。
## {{% heading "whatsnext" %}}
<!--
For more information about contributing to the Kubernetes documentation, see:
-->
关于贡献 Kubernetes 的更多文档，请参考：
- [Start contributing](/docs/contribute/start/)
- [Documentation style](/docs/contribute/style/)
content/zh/docs/contribute/start.md
-639
View File
@@ -1,639 +0,0 @@
---
title: 开始贡献
slug: start
content_type: concept
weight: 10
card:
name: contribute
weight: 10
---
<!--
---
title: Start contributing
slug: start
content_type: concept
weight: 10
card:
name: contribute
weight: 10
---
-->
<!-- 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)。
<!-- 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 频道、邮件列表和网络视频周会进行[交流](#参与-sig-docs-讨论)。欢迎新的参与者加入。更多信息，请参考[参与 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](#参与-sig-docs-讨论) 频道中询问有关允许内容的问题。
<!--
### 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)，或者通过手机拨入。
<!--
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).
-->
{{< note >}}
您也可以查看 [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 术语的背景知识。
<!--
**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.
-->
{{< note >}}
**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/)提交您的提案。
## {{% heading "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/)。
content/zh/docs/contribute/style/_index.md
+3 -5
View File
@@ -1,15 +1,13 @@
---
title: 文档风格概述
title: 文档样式概述
main_menu: true
weight: 80
---
<!--
---
title: Documentation style overview
main_menu: true
weight: 80
---
-->
<!--
@@ -17,5 +15,5 @@ The topics in this section provide guidance on writing style, content formatting
and organization, and using Hugo customizations specific to Kubernetes
documentation.
-->
本节的主题是提供有关编写风格、内容格式和组织以及使用 Hugo 定制生成 Kubernetes 文档的指导。
本节的主题是提供有关写作风格、内容格式和组织以及如何使用
特定于 Kubernetes 文档的 Hugo 定制代码的指导。
content/zh/docs/contribute/style/content-guide.md
+142
View File
@@ -0,0 +1,142 @@
---
title: 文档内容指南
linktitle: 内容指南
content_type: concept
weight: 10
---
<!--
title: Documentation Content Guide
linktitle: Content guide
content_type: concept
weight: 10
-->
<!-- overview -->
<!--
This page contains guidelines for Kubernetes documentation.
If you have questions about what's allowed, join the #sig-docs channel in
[Kubernetes Slack](http://slack.k8s.io/) and ask!
You can register for Kubernetes Slack at http://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
-->
本页包含 Kubernetes 文档的一些指南。
如果你不清楚哪些事情是可以做的，请加入到
[Kubernetes Slack](http://slack.k8s.io/) 的 `#sig-docs` 频道提问！
你可以在 http://slack.k8s.io 注册到 Kubernetes Slack。
关于为 Kubernetes 文档创建新内容的更多信息，可参考
[样式指南](/zh/docs/contribute/style/style-guide)。
<!-- body -->
<!--
## Overview
Source for the Kubernetes website, including the docs, resides in the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Located in the `kubernetes/website/content/<language_code>/docs` folder, the
majority of Kubernetes documentation is specific to the [Kubernetes
project](https://github.com/kubernetes/kubernetes).
## What's allowed
Kubernetes docs allow content for third-party projects only when:
- Content documents software in the Kubernetes project
- Content documents software that's out of project but necessary for Kubernetes to function
- Content is canonical on kubernetes.io, or links to canonical content elsewhere
-->
## 概述 {#overview}
Kubernetes 网站（包括其文档）源代码位于
[kubernetes/website](https://github.com/kubernetes/website) 仓库中。
在 `kubernetes/website/content/<语言代码>/docs` 目录下, 绝大多数 Kubernetes
文档都是特定于 [Kubernetes 项目](https://github.com/kubernetes/kubernetes)的。
## 可以发布的内容 {#whats-allowed}
只有当以下条件满足时，Kuberentes 文档才允许第三方项目的内容：
- 内容所描述的软件在 Kubernetes 项目内
- 内容所描述的软件不在 Kubernetes 项目内，却是让 Kubernetes 正常工作所必需的
- 内容是被 kubernetes.io 域名收编的，或者是其他位置的标准典型内容
<!--
### Third party content
Kubernetes documentation includes applied examples of projects in the Kubernetes project&mdash;projects that live in the [kubernetes](https://github.com/kubernetes) and
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
Links to active content in the Kubernetes project are always allowed.
Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/).
Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function.
-->
### 第三方内容 {#third-party-content}
Kubernetes 文档包含 Kubernetes 项目下的多个项目的应用示例。
这里的 Kubernetes 项目指的是 [kubernetes](https://github.com/kubernetes) 和
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub 组织
下的项目。
链接到 Kubernetes 项目中活跃的内容是一直允许的。
Kubernetes 需要某些第三方内容才能正常工作。例如
容器运行时（containerd、CRI-O、Docker），
[联网策略](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
（CNI 插件），[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
以及[日志](https://kubernetes.io/zh/docs/concepts/cluster-administration/logging/)等。
只有对应的第三方开源软件（OSS）是运行 Kubernetes 所必需的，才可以在文档中包含
指向这些 Kubernetes 项目之外的软件的链接。
<!--
### Dual sourced content
Wherever possible, Kubernetes docs link to canonical sources instead of hosting
dual-sourced content.
Dual-sourced content requires double the effort (or more!) to maintain
and grows stale more quickly.
{{< note >}}
If you're a maintainer for a Kubernetes project and need help hosting your own docs,
ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/).
{{< /note >}}
-->
### 双重来源的内容 {#dual-sourced-content}
只要有可能，Kubernetes 文档应该指向标准典型的信息源而不是直接托管多重来源的内容。
双重来源的内容需要双倍（甚至更多）的投入才能维护，而且通常很快就会变得停滞不前。
{{< note >}}
如果你是一个 Kubernetes 项目的维护者，需要帮忙托管你的文档，
请在 Kubernetes 的 [#sig-docs 频道](https://kubernetes.slack.com/messages/C1J0BPD2M/)
提出请求。
{{< /note >}}
<!--
### More information
If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
-->
### 更多信息 {#more-information}
如果你对允许出现的内容有疑问，请加入到 [Kubernetes Slack](http://slack.k8s.io/)
的 `#sig-docs` 频道提问！
## {{% heading "whatsnext" %}}
* 阅读[样式指南](/zh/docs/contribute/style/style-guide)。
content/zh/docs/contribute/style/content-organization.md
+72 -113
View File
@@ -3,99 +3,80 @@ title: 内容组织
content_type: concept
weight: 40
---
<!--
---
title: Content organization
content_type: concept
weight: 40
---
-->
<!-- overview -->
<!--
This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept.
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/) 是一个核心概念。
<!-- body -->
{{% note %}}
<!--
**Hugo Tip:** Start Hugo with `hugo server --navigateToChanged` for content edit-sessions.
**Hugo Tip:** Start Hugo with `hugo server -navigateToChanged` for content edit-sessions.
-->
**Hugo 提示:** 用 `hugo server --navigateToChanged` 命令启动 Hugo 以进行内容编辑会话。
{{% /note %}}
{{< note >}}
**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.
Given that, if you want to move a page or a section up, set a weight in the page's front matter:
-->
## 页面列表
<!--
### 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 的默认排序顺序列出。Hugo 会按照权重（从 1 开始）、
日期（最新的排最前面）排序，最后按链接标题排序。
文档侧方菜单、文档页面浏览器等以 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 %}}
{{< note >}}
对于页面的权重，不建议使用连续的数值，比如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` 标志：
`文档` 主菜单是从 `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` 中提取的，因此如果希望它与标题不同，请在内容文件中更改它：
注意，链接标题来自页面的 `linkTitle` 字段，因此如果希望它与页面标题不同，请在内容文件中更改它：
```yaml
main_menu: true
@@ -103,36 +84,31 @@ 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 %}}
{{< note >}}
以上操作需要为每种语言分别完成。如果在菜单中没有看到你的章节，这可能是因为它没有被 Hugo 识别为一个章节。
请在章节对应的目录下创建 `_index.md` 内容文件。
{{< /note >}}
<!--
### Documentation Side Menu
-->
The documentation side-bar menu is built from the _current section tree_ starting below `docs/`.
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:
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.
-->
### 文档侧方菜单
<!--
The documentation side-bar menu is built from the _current section tree_ starting below `docs/`.
-->
文档侧方菜单是基于 `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`。
@@ -140,27 +116,19 @@ If you don't want to list a section or page, set the `toc_hide` flag to `true` i
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`）。否则，将显示该章节里的第一个页面。
当导航到具有内容的章节时，网站将显示出指定的章节或页面（例如 `_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:
-->
### 文档浏览器 {#documentation-browser}
文档主页上的页面浏览器是基于 `docs section` 下一层的所有章节和页面构建的。
如果你不想列出某个章节或页面，请在页面头部将 `toc_hide` 标志设置为 `true`。
@@ -170,34 +138,30 @@ 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` 章节在网站中不存在（按语言），则它将链接不到。
右上菜单中的网站链接（也出现在页脚中）是通过页面查找构建的。
这是为了确保页面实际存在。因此，如果 `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`，都是包的一部分。这还包括页面相关的链接、可被处理的图像等：
除了独立的内容页面（Markdown 文件），Hugo 还支持
[页面包](https://gohugo.io/content-management/page-bundles/)。
一个例子是[定制的 Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)。
它被认为是 `leaf bundle`（叶子包）。
目录下的所有内容，包括 `index.md`，都是包的一部分。此外还包括页面间相对链接、可被处理的图像等：
```bash
en/docs/home/contribute/includes
@@ -210,8 +174,8 @@ en/docs/home/contribute/includes
<!--
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。它只用于其他页面。
另一个广泛使用的例子是 `includes` 包。
这类包在页面头部设置 `headless: true`，意味着它没有得到自己的 URL。它只用于其他页面。
```bash
en/includes
@@ -228,44 +192,39 @@ en/includes
<!--
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)。
* 已翻译的包会从上面的语言继承所有缺失的、非内容文件。这一设计可以避免重复。
* 包中的所有文件都是 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).
-->
## 样式 {#styles}
本网站的样式表的 `SASS` 源存储在 `src/sass` 下面，可以用 `make sass` 构建（Hugo很快就会得到 `SASS` 的支持，参见https://github.com/gohugoio/hugo/issues/4243）。
网站的样式表的 `SASS` 源文件存储在 `src/sass` 下面，可以用 `make sass` 构建
（Hugo 很快就提供 `SASS` 的支持，参见 https://github.com/gohugoio/hugo/issues/4243）。
## {{% heading "whatsnext" %}}
<!--
* [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)
* [Style guide](/docs/contribute/style/style-guide)
* Learn about [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)
* Learn about the [Style guide](/docs/contribute/style/style-guide)
* Learn about the [Content guide](/docs/contribute/style/content-guide)
-->
* [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)
* [样式指南](/docs/contribute/style/style-guide)
* 了解[定制 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)
* 了解[样式指南](/zh/docs/contribute/style/style-guide)
* 了解[内容指南](/zh/docs/contribute/style/content-guide)
content/zh/docs/contribute/style/hugo-shortcodes/example1.md
+3 -6
View File
@@ -3,21 +3,18 @@ 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 >}}
被包含的内容文件也可以包含短代码。
{{< /note >}}
包含的内容文件也可以包含短代码。
{{< /note >}}
content/zh/docs/contribute/style/hugo-shortcodes/example2.md
-5
View File
@@ -1,17 +1,12 @@
---
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
+183 -80
View File
@@ -1,37 +1,41 @@
---
approvers:
- chenopis
title: 定制 Hugo 短代码
content_type: concept
---
<!-- ---
approvers:
- chenopis
<!--
title: Custom Hugo Shortcodes
content_type: concept
--- -->
-->
<!-- 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)。
关于短代码的更多信息可参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。
<!-- body -->
<!-- ## Feature state -->
<!--
## 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.
-->
## 功能状态
<!-- 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)。
在本站的 markdown 页面中，你可以加入短代码来展示所描述的功能特性的版本和状态。
<!-- ### Feature state demo -->
### 功能状态演示
<!--
### 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时就已经稳定了。
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" */>}}
@@ -43,32 +47,33 @@ content_type: concept
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
<!-- The valid values for `state` are: -->
`state`的可选值如下：
`state` 的可选值如下：
* alpha
* beta
* deprecated
* stable
<!-- ### Feature state code -->
<!--
### Feature state code
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.
-->
### 功能状态代码
<!-- 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> 短代码参数来调整。
所显示的 Kubernetes 默认为该页或站点版本。
可以通过修改 <code>for_k8s_version</code> 短代码参数来调整要显示的版本。
```
{{</* feature-state for_k8s_version="v1.10" state="stable" */>}}
{{</* feature-state for_k8s_version="v1.11" state="stable" */>}}
```
<!-- Renders to: -->
会转换为：
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
<!-- #### Alpha feature -->
#### Alpha 功能
@@ -82,7 +87,6 @@ content_type: concept
{{< feature-state state="alpha" >}}
<!-- #### Beta feature -->
#### Beta 功能
@@ -119,63 +123,165 @@ content_type: concept
{{< feature-state state="deprecated" >}}
<!-- ## Glossary -->
<!--
## 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.
-->
## 词汇
<!-- 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/)）
你可以通过加入术语词汇的短代码，来自动更新和替换相应链接中的内容
（[我们的词汇库](/zh/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. -->
<!--
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 -->
<!--
### Glossary Demo
For example, the following include within the markdown will render to
{{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
-->
### 词汇演示
<!-- 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" >}}`，
然后在提示框中显示。
例如，下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`，然后在提示框中显示。
````liquid
```liquid
{{</* glossary_tooltip text="cluster" term_id="cluster" */>}}
````
```
<!-- ## Tabs -->
## 标签页
<!--
## Table captions
<!-- 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. -->
下面是演示标签页短代码。
You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter.
{{< note >}}
The tab **name** in a `tabs` definition must be unique within a content page.
一个内容页面下的，标签页定义中的标签页 **名** 必须是唯一的。
Table captions are visible to screen readers but invisible when viewed in standard HTML.
{{< /note >}}
<!-- ### Tabs demo: Code highlighting -->
Here's an example:
-->
## 表格标题 {#table-captions}
通过添加表格标题，你可以让表格能够被屏幕阅读器读取。
要向表格添加[标题（Caption）](https://www.w3schools.com/tags/tag_caption.asp)，
可用 `table` 短代码包围表格定义，并使用 `caption` 参数给出表格标题。
{{< note >}}
表格标题对屏幕阅读器是可见的，但在标准 HTML 中查看时是不可见的。
{{< /note >}}
下面是一个例子：
<!--
```go-html-template
{{</* table caption="Configuration parameters" >}}
Parameter | Description | Default
`timeout` | The timeout for requests | `30s`
`logLevel` | The log level for log output | `INFO`
{{< /table */>}}
The rendered table looks like this:
{{< table caption="Configuration parameters" >}}
Parameter | Description | Default
`timeout` | The timeout for requests | `30s`
`logLevel` | The log level for log output | `INFO`
{{< /table >}}
-->
```go-html-template
{{</* table caption="配置参数" >}}
参数 | 描述 | 默认值
:---------|:------------|:-------
`timeout` | 请求的超时时长 | `30s`
`logLevel` | 日志输出的级别 | `INFO`
{{< /table */>}}
```
所渲染的表格如下：
{{< table caption="配置参数" >}}
参数 | 描述 | 默认值
:---------|:------------|:-------
`timeout` | 请求的超时时长 | `30s`
`logLevel` | 日志输出的级别 | `INFO`
{{< /table >}}
<!--
If you inspect the HTML for the table, you should see this element immediately after the opening `<table>` element:
```html
<caption style="display: none;">Configuration parameters</caption>
```
-->
如果你查看表格的 HTML 输出结果，你会看到 `<table>` 元素
后面紧接着下面的元素：
```html
<caption style="display: none;">配置参数</caption>
```
<!--
## Tabs
In a markdown page (`.md` file) on this site, you can add a tab set to display
multiple flavors of a given solution.
The `tabs` shortcode takes these parameters:
-->
## 标签页
在本站的 markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示
某解决方案的不同形式。
标签页的短代码包含以下参数：
<!--
* `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 的
[叶子包](https://gohugo.io/content-management/page-bundles/#leaf-bundles)中定义，
Hugo 会在包内查找文件（可以是 Hugo 所支持的任何 MIME 类型文件）。
否则，Hugo 会在当前路径的相对路径下查找所要包含的内容页面。
注意，在 `include` 页面中不能包含短代码内容，必须要使用自结束（self-closing）语法。
非内容文件将会被代码高亮。
如果没有在 `codelang` 进行声明的话，Hugo 会根据文件名推测所用的语言。
<!--
* 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.
The tab **name** in a `tabs` definition must be unique within a content page.
-->
下面是标签页短代码的示例。
{{< note >}}
内容页面下的 **tabs** 定义中的标签页 **name** 必须是唯一的。
{{< /note >}}
<!--
### Tabs demo: Code highlighting
-->
### 标签页演示：代码高亮
```go-text-template
@@ -255,20 +361,17 @@ println "This is tab 2."
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs >}}
## {{% heading "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/). -->
<!--
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/home/contribute/style/page-content-types/).
* 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/)。
* 了解 [撰写新的话题](/zh/docs/contribute/write-new-topic/)。
* 了解 [使用页面类型](/zh/docs/contribute/style/page-content-types/)。
* 了解 [发起 PR](/zh/docs/contribute/new-content/create-a-pr/)。
content/zh/docs/contribute/style/page-content-types.md
+412
View File
@@ -0,0 +1,412 @@
---
title: 页面内容类型
content_type: concept
weight: 30
card:
name: 贡献
weight: 30
---
<!--
title: Page content types
content_type: concept
weight: 30
card:
name: contribute
weight: 30
-->
<!-- overview -->
<!--
The Kubernetes documentation follows several types of page content:
- Concept
- Task
- Tutorial
- Reference
-->
Kubernetes 文档包含以下几种页面内容类型：
- 概念（Concept）
- 任务（Task）
- 教程（Tutorial）
- 参考（Reference）
<!-- body -->
<!--
## Content sections
Each page content type contains a number of sections defined by
Markdown comments and HTML headings. You can add content headings to
your page with the `heading` shortcode. The comments and headings help
maintain the structure of the page content types.
Examples of Markdown comments defining page content sections:
-->
## 内容章节 {#content-sections}
每种页面内容类型都有一些使用 Markdown 注释和 HTML 标题定义的章节。
你可以使用 `heading` 短代码将内容标题添加到你的页面中。
注释和标题有助于维护对应页面内容类型的结构组织。
定义页面内容章节的 Markdown 注释示例：
```markdown
<!-- overview -->
```
```markdown
<!-- body -->
```
<!--
To create common headings in your content pages, use the `heading` shortcode with
a heading string.
Examples of heading strings:
- whatsnext
- prerequisites
- objectives
- cleanup
- synopsis
- seealso
- options
For example, to create a `whatsnext` heading, add the heading shortcode with the "whatsnext" string:
-->
要在内容页面中创建通用的标题，可以使用 `heading` 短代码加上标题字符串。
标题字符串示例：
- whatsnext
- prerequisites
- objectives
- cleanup
- synopsis
- seealso
- options
例如，要创建一个 `whatsnext` 标题，添加 heading 短代码并指定 "whatsnext" 字符串：
```none
## {{%/* heading "whatsnext" */%}}
```
<!--
You can declare a `prerequisites` heading as follows:
-->
你可以像下面这样声明一个 `prerequisites` 标题：
```none
## {{%/* heading "prerequisites" */%}}
```
<!--
The `heading` shortcode expects one string parameter.
The heading string parameter matches the prefix of a variable in the `i18n/<lang>.toml` files.
For example:
-->
短代码 `heading` 需要一个字符串参数。
该字符串参数要与 `i18n/<语言>.toml` 文件中以其为前缀的某个变量匹配。
例如：
`i18n/en.toml`:
```toml
[whatsnext_heading]
other = "What's next"
```
`i18n/ko.toml`:
```toml
[whatsnext_heading]
other = "다음 내용"
```
<!--
## Content types
Each content type informally defines its expected page structure.
Create page content with the suggested page sections.
-->
## 内容类型 {#content-types}
每种内容类型都非正式地定义了期望的页面结构组织。
请按照所建议的页面章节来创建内容页面。
<!--
### Concept
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.
To write a new concept page, create a Markdown file in a subdirectory of the
`/content/en/docs/concepts` directory, with the following characteristics:
Concept pages are divided into three sections:
| Page section |
|----------------|
| overview |
| body |
| whatsnext |
-->
### 概念 {#concept}
概念页面用来解释 Kubernetes 的某些方面。例如，概念页面可以用来描述 Kubernetes
中的 Deployment 对象，解释其作为应用的角色如何部署、扩缩和更新。
通常，概念页面不需要包含步骤序列，但包含指向任务或教程的链接。
要编写一个新的概念页面，在 `/content/en/docs/concepts` 目录下面的子目录中新建
一个 Markdown 文件。该文件具有以下特点。
概念页面分为三个章节：
| 页面章节 |
|--------------------|
| overview （概述） |
| body (主体） |
| whatsnext (接下来）|
<!--
The `overview` and `body` sections appear as comments in the concept page.
You can add the `whatsnext` section to your page with the `heading` shortcode.
Fill each section with content. Follow these guidelines:
- Organize content with H2 and H3 headings.
- For `overview`, set the topic's context with a single paragraph.
- For `body`, explain the concept.
- For `whatsnext`, provide a bulleted list of topics (5 maximum) to learn more about the concept.
[Annotations](/docs/concepts/overview/working-with-objects/annotations/) is a
published example of a concept page.
-->
其中的 `overview` 和 `body` 章节在概念页面中显示为注释。
你可以使用 `heading` 短代码向页面添加 `wahtsnext` 节。
在为每个章节撰写内容时，遵从一些规定：
- 使用二级和三级标题（H2、H3）来组织内容
- 在 `overview` 节中，使用一段文字来为主体部分铺陈上下文；
- 在 `body` 节中，详细解释对应概念；
- 对于 `whatsnext` 节，提供一个项目符号列表（最多 5 个），帮助读者进一步学习掌握概念
[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经
上线的概念页面的例子。
<!--
### Task
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:
| Page section |
|----------------|
| overview |
| prerequisites |
| steps |
| discussion |
| whatsnext |
-->
### 任务（Task） {#task}
任务页面讲解如何完成某项工作，通常包含由为数不多的几个步骤组成的序列。
任务页面的讲解文字很少，不过通常会包含指向概念主题的链接，以便读者
能够了解相关的背景和知识。
编写新的任务页面时，在 `/content/en/docs/tasks` 目录下的子目录中创建一个
新的 Markdown 文件。该文件特点如下。
| 页面章节 |
|---------------------------|
| overview （概述） |
| prerequisites （准备工作）|
| steps （步骤） |
| discussion （讨论） |
| whatsnext （接下来） |
<!--
The `overview`, `steps`, and `discussion` sections appear as comments in the task page.
You can add the `prerequisites` and `whatsnext` sections to your page
with the `heading` shortcode.
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.
An example of a published task topic is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/).
-->
其中的 `overview`、`steps` 和 `discussion` 节在任务页面中显示为注释。
你可以使用 `heading` 短代码添加 `prerequisites` 和 `whatsnext` 小节。
在每个小节内撰写内容时注意以下规定：
- 最低使用二级标题（H2，标题行前带两个 `#` 字符）。每个小节都会由模版自动给出标题。
- 在 `overview` 节中，用一个段落为整个任务主体设定语境；
- 在 `prerequisites` 节中，尽可能使用项目符号列表。
额外的环境准备条件要加在 `include` 短代码之后。
默认的环境准备条件是拥有一个在运行的 Kubernetes 集群。
- 在 `steps` 节中，使用编号符号列表。
- 在 `discussion` 节中，使用正常文字内容来对 `steps` 节中内容展开叙述。
- 在 `whatsnext` 节中，使用项目符号列表（不超过 5 项），列举读者可能接下来有兴趣
阅读的主题。
已上线的任务主题示例之一是[使用 HTTP 代理来访问 Kubernetes API](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/)。
<!--
### Tutorial
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.
To write a new tutorial page, create a Markdown file in a subdirectory of the
`/content/en/docs/tutorials` directory, with the following characteristics:
| Page section |
|----------------|
| overview |
| prerequisites |
| objectives |
| lessoncontent |
| cleanup |
| whatsnext |
-->
### 教程（Tutorial） {#tutorial}
教程页面描述如果完成一个比单一任务规模更大的目标。通常教程页面会有多个小节，
每个小节由一系列步骤组成。例如，每个教程可能提供对代码示例的讲解，便于用户
了解 Kubernetes 的某个功能特性。教程可以包含表面层面的概念解释，对于更深层面
的概念主题应该使用链接。
撰写新的教程页面时，在 `/content/en/docs/tutorials` 目录下面的子目录中创建新的
Markdown 文件。该文件有以下特点。
| 页面节区 |
|---------------------------|
| overview （概述） |
| prerequisites （环境准备）|
| objectives （目标） |
| lessoncontent （教程内容）|
| cleanup （清理工作） |
| whatsnext （接下来） |
<!--
The `overview`, `objectives`, and `lessoncontent` sections appear as comments in the tutorial page.
You can add the `prerequisites`, `cleanup`, and `whatsnext` sections to your page
with the `heading` shortcode.
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.
An example of a published tutorial topic is
[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
-->
教程页面的 `overview`、`objectives` 和 `lessoncontent` 小节显示为注释形式。
你可以使用 `heading` 短代码根据需要添加 `prerequisites`、`cleanup` 和
`whatsnext` 小节。
在每个小节中编写内容时，请注意以下规定：
- 最低使用二级标题（H2，标题前面有两个 `#` 字符）。模版会自动为每个小节设置标题。
- 在 `overview` 节中，用一个段落为整个主题设定语境；
- 在 `prerequisites` 节中，尽可能使用项目符号列表。
额外的环境准备条件要加在已包含的条件之后。
- 在 `objectives` 节中，使用项目符号列表。
- 在 `lessoncontent` 节中，结合使用编号符号列表和叙述性文字。
- 在 `cleanup` 节中，使用编号符号列表来描述任务结束后清理集群状态所需要的步骤。
- 在 `whatsnext` 节中，使用项目符号列表（不超过 5 项），列举读者可能接下来有兴趣
阅读的主题。
已发布的教程主题的一个例子是
[使用 Deployment 运行无状态应用](/zh/docs/tutorials/stateless-application/run-stateless-application-deployment/).
<!--
### Reference
A component tool reference page shows the description and flag options output for
a Kubernetes component tool. Each page generates from scripts using the component tool commands.
A tool reference page has several possible sections:
| Page section |
|--------------------------------|
| synopsis |
| options |
| options from parent commands |
| examples |
| seealso |
Examples of published tool reference pages are:
- [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/)
- [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
- [kubectl](/docs/reference/kubectl/kubectl/)
-->
### 参考（Reference） {#reference}
组件工具的参考页面给出的是某个 Kubernetes 组件工具的描述和参数选项输出。
每个页面都是使用组件工具命令基于脚本生成的。
每个工具参考页面可能包含以下小节：
| 页面小节 |
|-----------------|
| synopsis (用法）|
| options（选项） |
| options from parent commands (从父命令集成的选项） |
| examples （示例）|
| seealso （参考）|
已发布的工具参考页面示例包括：
- [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/)
- [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
- [kubectl](/zh/docs/reference/kubectl/kubectl/)
## {{% heading "whatsnext" %}}
<!--
- Learn about the [Style guide](/docs/contribute/style/style-guide/)
- Learn about the [Content guide](/docs/contribute/style/content-guide/)
- Learn about [content organization](/docs/contribute/style/content-organization/)
-->
- 了解[样式指南](/zh/docs/contribute/style/style-guide/)
- 了解[内容指南](/zh/docs/contribute/style/content-guide/)
- 了解[内容组织](/zh/docs/contribute/style/content-organization/)
content/zh/docs/contribute/style/page-templates.md
-353
View File
@@ -1,353 +0,0 @@
---
title: 使用页面模板
content_type: concept
weight: 30
---
<!--
---
title: Using Page Templates
content_type: concept
weight: 30
---
-->
<!-- 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).
-->
每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板，请从[概念模板](#概念模板)开始。
{{< /note >}}
<!-- 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_type: concept`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_type: 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_type: task`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_type: 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_type: tutorial`.
- In the page's body, set the required `capture` variables and any optional
ones you want to include:
-->
- 在页面的 YAML 头部，设置 `content_type: 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/)。
## {{% heading "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/)
content/zh/docs/contribute/style/style-guide.md
+1207
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/contribute/style/write-new-topic.md
+88 -102
View File
@@ -3,13 +3,10 @@ title: 撰写新主题
content_type: task
weight: 20
---
<!--
---
title: Writing a new topic
content_type: task
weight: 20
---
-->
<!-- overview -->
@@ -18,30 +15,24 @@ This page shows how to create a new topic for the Kubernetes docs.
-->
本页面展示如何为 Kubernetes 文档库创建新主题。
## {{% heading "prerequisites" %}}
<!--
Create a fork of the Kubernetes documentation repository as described in
[Start contributing](/docs/contribute/start/).
-->
如[开始贡献](/docs/contribute/start/)中所述，创建 Kubernetes 文档库的分支。
如[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。
<!-- 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:
-->
## 选择页面类型
当你准备写一个新的主题时，考虑一下最适合你的内容的页面类型：
当你准备编写一个新的主题时，考虑一下最适合你的内容的页面类型：
<!--
Guidelines for choosing a page type
@@ -52,30 +43,25 @@ Task | A task page shows how to do a single thing. The idea is to give readers a
Tutorial | 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.
-->
{{< table caption = "选择页面类型的准则" >}}
{{< table caption = "选择页面类型的说明" >}}
类型 | 描述
:--- | :----------
概念 | 每个概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。一个概念主题的示例，请参见 <a href="/docs/concepts/architecture/nodes/">节点</a>。
任务 | 任务页面展示了如何完成单个任务。这样做的目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">配置一个使用卷进行存储的 Pod</a>。一个较长的任务页面的实例，请参见 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活动性和就绪性探针</a>。
教程 | 教程页面展示如何实现某个目标，该目标将几个 Kubernetes 特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但应该链接到相关概念主题，以便深入解释各个特性。
概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 <a href="/zh/docs/concepts/architecture/nodes/">节点</a>。
任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 <a href="/zh/docs/tasks/configure-pod-container/configure-volume-storage/">配置 Pod 使用卷存储</a>。一个较长的任务页面的实例可参见 <a href="/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">配置活跃性和就绪性探针</a>。
教程（Tutorial） | 教程页面展示如何实现某个目标，该目标将若干 Kubernetes 功能特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但有关更深入的特性解释应该链接到相关概念主题。
{{< /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
Use a [content type](/docs/contribute/style/page-content-types/) for each new page
that you write. Using page type helps ensure
consistency among topics of a given type.
-->
为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)，这个模板可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。
为每个新页面选择其[内容类型](/zh/docs/contribute/style/page-content-types/)。
使用页面类型有助于确保给定类型的各主题之间保持一致。
<!--
## 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
@@ -84,45 +70,47 @@ 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 中了，例如：
选择一个标题，确保其中包含希望搜索引擎发现的关键字。
确定文件名时请使用标题中的单词，由连字符分隔。
例如，标题为[Using an HTTP Proxy to Access Kubernetes API](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/)
的主题的文件名为 `http-proxy-access-api.md`。
你不需要在文件名中加上 "kubernetes"，因为 "kubernetes" 已经在主题的 URL 中了，
例如：
/docs/tasks/access-kubernetes-api/http-proxy-access-api/
/docs/tasks/extend-kubernetes/http-proxy-access-api/
<!--
## Adding the topic title to the front matter
-->
## 在页面头部添加主题标题
<!--
In your topic, put a `title` field in the
[front matter](https://gohugo.io/content-management/front-matter/).
The front matter is the YAML block that is between the
triple-dashed lines at the top of the page. Here's an example:
```
title: Using an HTTP Proxy to Access the Kubernetes API
```
-->
## 在页面前言中添加主题标题
在你的主题中，在[页面头部](https://gohugo.io/content-management/front-matter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子：
在你的主题中，在[前言（front-matter）](https://gohugo.io/content-management/front-matter/)
中设置一个 `title` 字段。
前言是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子：
<!--
---
title: Using an HTTP Proxy to Access the Kubernetes API
---
-->
---
title: 使用 HTTP 代理访问 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:
-->
## 选择目录
根据页面类型，将新文件放入其中一个子目录中：
@@ -134,31 +122,29 @@ Depending on your page type, put your new file in a subdirectory of one of these
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/` 下的顶层目录创建顶层导航，它和子目录在目录中都有条目。
目录是使用文档源的目录结构动态构建的。
`/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` 文件不需要模板。它可以包含有关子目录中主题的概述内容。
每个子目录都有一个 `_index.md` 文件，它表示的是该子目录内容的主页面。
`_index.md` 文件不需要模板。它可以包含各子目录中主题的概述内容。
<!--
Other files in a directory are sorted alphabetically by default. This is almost
@@ -167,22 +153,22 @@ 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 的倍数，添加后续主题时 `weight` 值递增。例如，`weight` 为 `10` 的主题将位于 `weight` 为 `20` 的主题之前。
默认情况下，目录中的其他文件按字母顺序排序。这一般不是最好的顺序。
要控制子目录中主题的相对排序，请将页面头部的键 `weight:` 设置为整数值。
通常我们使用 10 的倍数，添加后续主题时 `weight` 值递增。
例如，`weight` 为 `10` 的主题将位于 `weight` 为 `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):
-->
## 在主题中嵌入代码
如果你想在主题中嵌入一些代码，可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况（并非详尽列表）：
如果你想在主题中嵌入一些代码，可以直接使用 Markdown 代码块语法将代码嵌入到文件中。
建议在以下场合（并非详尽列表）使用嵌入代码：
<!--
- The code shows the output from a command such as
@@ -202,34 +188,41 @@ following cases (not an exhaustive list):
-->
- 代码显示来自命令的输出，例如 `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` 命令描述如何将新属性添加到资源时，你可以提供一个仅包含要添加的属性的简短示例。
- 代码不够通用，用户无法验证。例如，你可以嵌入 YAML 文件来创建一个依赖于特定
[FlexVolume](/zh/docs/concepts/storage/volumes#flexvolume) 实现的 Pod。
- 该代码是一个不完整的示例，因为其目的是突出展现某个大文件中的部分内容。
例如，在描述出于某些原因定制
[PodSecurityPolicy](/zh/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 文件。
在主题中引用代码的另一种方法是创建一个新的、完整的示例文件（或文件组），
然后在主题中引用这些示例。当示例是通用的和可重用的，并且你希望读者自己验证时，
使用此方法引用示例 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` 短代码：
添加新的独立示例文件（如 YAML 文件）时，将代码放在 `<LANG>/examples/` 的某个子目录中，其中 `<LANG>` 是该主题的语言。在主题文件中使用 `codenew` 短代码：
<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
```none
{{</* codenew file="<RELPATH>/my-example-yaml>" */>}}
```
<!--
where `<RELPATH>` is the path to the file to include, relative to the
@@ -237,7 +230,9 @@ where `<RELPATH>` is the path to the file to include, relative to the
file located at `/content/en/examples/pods/storage/gce-volume.yaml`.
-->
`<RELPATH>` 是要引用的文件的路径，相对于 `examples` 目录。以下 Hugo 短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML 文件。
`<RELPATH>` 是要引用的文件的路径，相对于 `examples` 目录。以下 Hugo
短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML
文件。
```none
{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
@@ -249,26 +244,23 @@ from interpreting them, use C-style comments directly after the `<` and before
the `>` characters. View the code for this page for an example.
-->
{{< note >}}
要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释，请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。
要展示上述示例中的原始 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:
-->
## 显示如何从配置文件创建 API 对象
如果需要演示如何基于配置文件创建 API 对象，请将配置文件放在 `<LANG>/examples`
下的某个子目录中。
在主题中展示以下命令：
@@ -283,39 +275,33 @@ Travis CI for the Website automatically runs this test case when PRs are
submitted to ensure all examples pass the tests.
-->
{{< note >}}
将新的 YAML 文件添加到 `<LANG>/examples` 目录时，请确保该文件也在 `<LANG>/examples_test.go` 文件中被引用。当提交拉取请求时，网站的 Travis CI 会自动运行此测试用例，以确保所有示例都通过测试。
将新的 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/)。
有关使用此技术的主题的示例，请参见
[运行单实例有状态的应用](/zh/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。
<!--
Put image files in the `/images` directory. The preferred
image format is SVG.
-->
将镜像文件放入 `/images` 目录。首选的镜像格式是 SVG。
<!--
* 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/).
-->
## {{% heading "whatsnext" %}}
* 学习[使用页面模板](/docs/home/contribute/page-templates/)。
* 学习[展示你的修改](/docs/home/contribute/stage-documentation-changes/)。
* 学习[创建一个拉取请求](/docs/home/contribute/create-pull-request/)。
<!--
* Learn about [using page content types](/docs/contribute/style/page-content-types/).
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
-->
* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/).
* 了解[创建 PR](/zh/docs/contribute/new-content/open-a-pr/).
content/zh/docs/contribute/suggesting-improvements.md
+120
View File
@@ -0,0 +1,120 @@
---
title: 提出内容改进建议
slug: suggest-improvements
content_type: concept
weight: 10
card:
name: 贡献
weight: 20
---
<!--
title: Suggesting content improvements
slug: suggest-improvements
content_type: concept
weight: 10
card:
name: contribute
weight: 20
-->
<!-- overview -->
<!--
If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser.
In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors
then review, categorize and tag issues as needed. Next, you or another member
of the Kubernetes community open a pull request with changes to resolve the issue.
-->
如果你发现 Kubernetes 文档中存在问题，或者你有一个关于新内容的想法，可以考虑
提出一个问题（issue）。你只需要具有 [GitHub 账号](https://github.com/join)和 Web
浏览器就可以完成这件事。
在大多数情况下，Kubernetes 文档的新工作都是开始于 GitHub 上的某个问题。
Kubernetes 贡献者会审阅这些问题并根据需要对其分类、打标签。
接下来，你或者别的 Kubernetes 社区成员就可以发起一个带有变更的拉取请求，
以解决这一问题。
<!-- body -->
<!--
## Opening an issue
If you want to suggest improvements to existing content, or notice an error, then open an issue.
1. Go to the bottom of the page and click the **Create an Issue** button. This redirects you
to a GitHub issue page pre-populated with some headers.
2. Describe the issue or suggestion for improvement. Provide as many details as you can.
3. Click **Submit new issue**.
After submitting, check in on your issue occasionally or turn on GitHub notifications.
Reviewers and other community members might ask questions before
they can take action on your issue.
-->
## 创建问题 {#opening-an-issue}
如果你希望就改进已有内容提出建议，或者在文档中发现了错误，请创建一个问题（issue）。
1. 滚动到页面底部，点击“报告问题”按钮。浏览器会重定向到一个 GitHub 问题页面，其中
包含了一些预先填充的内容。
1. 请描述遇到的问题或关于改进的建议。尽可能提供细节信息。
1. 点击 **提交新问题**.
提交之后，偶尔查看一下你所提交的问题，或者开启 GitHub 通知。
评审人（reviewers）和其他社区成员可能在针对所提问题采取行动之前，问一些问题。
<!--
## Suggesting new content
If you have an idea for new content, but you aren't sure where it should go, you can
still file an issue. Either:
- Choose an existing page in the section you think the content belongs in and click **Create an issue**.
- Go to [GitHub](https://github.com/kubernetes/website/issues/new/) and file the issue directly.
-->
## 关于新内容的建议
如果你对新内容有想法，但是你有不确定这些内容应该放在哪里，你仍可以提出问题。
- 在预期的节区中选择一个现有页面，点击 **创建 issue**.
- 前往 [GitHub Issues 页面](https://github.com/kubernetes/website/issues/new/)，
直接记录问题。
<!--
## How to file great issues
Keep the following in mind when filing an issue:
- Provide a clear issue description. Describe what specifically is missing, out of date,
wrong, or needs improvement.
- 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 example, "Fix the security docs"
is too broad, but "Add details to the 'Restricting network access' topic" is specific enough
to be actionable.
- Search the existing issues to see if there's anything related or similar to the
new issue.
- If the new issue relates to another issue or pull request, refer to it
either by its full URL or by the issue or pull request number prefixed
with a `#` character. For example, `Introduced by #987654`.
- Follow the [Code of Conduct](/community/code-of-conduct/). Respect your
fellow contributors. For example, "The docs are terrible" is not
helpful or polite feedback.
-->
## 如何更好地记录问题
在记录问题时，请注意以下事项：
- 提供问题的清晰描述，描述具体缺失的内容、过期的内容、错误的内容或者需要改进的文字。
- 解释该问题对用户的特定影响。
- 将给定问题的范围限定在一个工作单位范围内。如果问题牵涉的领域较大，可以将其分解为多个
小一点的问题。例如："Fix the security docs" 是一个过于宽泛的问题，而
"Add details to the 'Restricting network access' topic"
就是一个足够具体的、可操作的问题。
- 搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。
- 如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 `#` 字符的 PR 编号
来引用之。例如：`Introduced by #987654`。
- 遵从[行为准则](/community/code-of-conduct/)。尊重同行贡献者。
例如，"The docs are terrible" 就是无用且无礼的反馈。
content/zh/docs/reference/command-line-tools-reference/kube-proxy.md
+2 -2
View File
@@ -1,12 +1,12 @@
---
title: kube-proxy
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
<!--
---
title: kube-proxy
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
-->
content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md
+2 -2
View File
@@ -1,12 +1,12 @@
---
title: kube-scheduler
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
<!--
---
title: kube-scheduler
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
-->
content/zh/docs/reference/command-line-tools-reference/kubelet.md
+1 -1
View File
@@ -1,6 +1,6 @@
---
title: kubelet
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
content/zh/docs/reference/glossary/disruption.md
+45
View File
@@ -0,0 +1,45 @@
---
title: 干扰
id: disruption
date: 2019-09-10
full_link: /docs/concepts/workloads/pods/disruptions/
short_description: >
导致 Pod 服务停止的事件。
aka:
tags:
- fundamental
---
干扰是指导致一个或者多个 {{< glossary_tooltip term_id="pod" text="Pod" >}} 服务停止的事件。
干扰会影响工作负载资源，比如 {{< glossary_tooltip term_id="deployment" >}} 这种依赖于受影响 Pod 的资源。
<!--
---
title: Disruption
id: disruption
date: 2019-09-10
full_link: /docs/concepts/workloads/pods/disruptions/
short_description: >
An event that leads to Pod(s) going out of service
aka:
tags:
- fundamental
---
Disruptions are events that lead to one or more
{{< glossary_tooltip term_id="pod" text="Pods" >}} going out of service.
A disruption has consequences for workload resources, such as
{{< glossary_tooltip term_id="deployment" >}}, that rely on the affected
Pods.
-->
<!--more-->
<!--
If you, as cluster operator, destroy a Pod that belongs to an application,
Kubernetes terms that a _voluntary disruption_. If a Pod goes offline
because of a Node failure, or an outage affecting a wider failure zone,
Kubernetes terms that an _involuntary disruption_.
See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more information.
-->
如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 _自愿干扰_。如果由于节点故障
或者影响更大区域故障的断电导致 Pod 离线，Kubrenetes 视之为 _非愿干扰_。
content/zh/docs/reference/glossary/host-aliases.md
+37
View File
@@ -0,0 +1,37 @@
---
title: HostAliases
id: HostAliases
date: 2019-01-31
full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
short_description: >
主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 Pod 内的 hosts 文件。
aka:
tags:
- operation
---
主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 {{< glossary_tooltip text="Pod" term_id="pod" >}} 内的 hosts 文件。
<!--
---
title: HostAliases
id: HostAliases
date: 2019-01-31
full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
short_description: >
A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file.
aka:
tags:
- operation
---
A HostAliases is a mapping between the IP address and hostname to be injected into a {{< glossary_tooltip text="Pod" term_id="pod" >}}'s hosts file.
-->
<!--more-->
<!--
[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods.
-->
[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) 是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。
该选项仅适用于没有配置 hostNetwork 的 Pod.
content/zh/docs/reference/glossary/mainfest.md
+34
View File
@@ -0,0 +1,34 @@
---
title: 清单
id: manifest
date: 2019-06-28
short_description: >
一个或多个 Kubernetes API 对象的序列化规范。
aka:
tags:
- fundamental
---
JSON 或 YAML 格式的 Kubernetes API 对象规范。
<!--
---
title: Manifest
id: manifest
date: 2019-06-28
short_description: >
A serialized specification of one or more Kubernetes API objects.
aka:
tags:
- fundamental
---
Specification of a Kubernetes API object in JSON or YAML format.
-->
<!--more-->
<!--
A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.
-->
清单指定了在应用该清单时 Kubrenetes 将维护的对象的期望状态。每个配置文件可包含多个清单。
content/zh/docs/reference/glossary/master.md
+34
View File
@@ -0,0 +1,34 @@
---
title: Master
id: master
date: 2020-04-16
short_description: >
遗留术语，作为运行控制平面的节点的同义词使用。
aka:
tags:
- fundamental
---
遗留术语，作为运行 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 的 {{< glossary_tooltip text="节点" term_id="node" >}} 的同义词使用。
<!--
---
title: Master
id: master
date: 2020-04-16
short_description: >
Legacy term, used as synonym for nodes running the control plane.
aka:
tags:
- fundamental
---
Legacy term, used as synonym for {{< glossary_tooltip text="nodes" term_id="node" >}} hosting the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
-->
<!--more-->
<!--
The term is still being used by some provisioning tools, such as {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, and managed services, to {{< glossary_tooltip text="label" term_id="label" >}} {{< glossary_tooltip text="nodes" term_id="node" >}} with `kubernetes.io/role` and control placement of {{< glossary_tooltip text="control plane" term_id="control-plane" >}} {{< glossary_tooltip text="pods" term_id="pod" >}}.
-->
该术语仍被一些配置工具使用，如 {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} 以及托管的服务，为 {{< glossary_tooltip text="节点" term_id="node" >}} 添加 `kubernetes.io/role` 的 {{< glossary_tooltip text="标签" term_id="label" >}}，以及管理控制平面 Pod 的调度。
content/zh/docs/reference/kubectl/kubectl.md
+2 -2
View File
@@ -1,12 +1,12 @@
---
title: kubectl
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
<!--
---
title: kubectl
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
-->
content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md
+134 -90
View File
@@ -1,141 +1,185 @@
<!--
### Synopsis
Show what differences would be applied to existing static pod manifests. See also: kubeadm upgrade apply --dry-run
```
kubeadm upgrade diff [version] [flags]
```
-->
### 概述
显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run
显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run
```
kubeadm upgrade diff [version] [flags]
```
<!--
### Options
```
<tr>
<td colspan="2">--api-server-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-apiserver.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to API server manifest</td>
</tr>
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
<td colspan="2">--api-server-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-apiserver.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to API server manifest</td>
</tr>
<tr>
<td colspan="2">-c, --context-lines int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 3</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">How many lines of context in the diff</td>
</tr>
<tr>
<td colspan="2">--controller-manager-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to controller manifest</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for diff</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
</tr>
<tr>
<td colspan="2">--scheduler-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-scheduler.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to scheduler manifest</td>
</tr>
```
-->
### 选项
<tr>
<td colspan="2">--api-server-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值： "/etc/kubernetes/manifests/kube-apiserver.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">API服务器清单的路径</td>
</tr>
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--config string</td>
<td colspan="2">--api-server-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes/manifests/kube-apiserver.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"> API 服务器清单的路径。</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">API服务器清单的路径</td>
</tr>
<!--
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
</tr>
-->
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径</td>
</tr>
<!--
<tr>
<td colspan="2">-c, --context-lines int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 3</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">How many lines of context in the diff</td>
</tr>
-->
<tr>
<td colspan="2">-c, --context-lines int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值：3</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">差异中有多少行上下文</td>
</tr>
<!--
<tr>
<td colspan="2">--controller-manager-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to controller manifest</td>
</tr>
-->
<tr>
<td colspan="2">--controller-manager-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值： "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">控制器清单的路径</td>
</tr>
<!--
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for diff</td>
</tr>
-->
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td>
</tr>
<!--
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
</tr>
-->
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件，如果标志是未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td>
</tr>
<!--
<tr>
<td colspan="2">--scheduler-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/manifests/kube-scheduler.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">path to scheduler manifest</td>
</tr>
</tbody>
</table>
-->
<tr>
<td colspan="2">-c, --context-lines int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值： 3</td>
<td colspan="2">--scheduler-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes/manifests/kube-scheduler.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">差异中有多少行上下文</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">调度程序清单的路径</td>
</tr>
<tr>
<td colspan="2">--controller-manager-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值： "/etc/kubernetes/manifests/kube-controller-manager.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">控制器清单的路径</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值： "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件，如果标志是未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td>
</tr>
<tr>
<td colspan="2">--scheduler-manifest string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes/manifests/kube-scheduler.yaml"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">调度程序清单的路径</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
```
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
</tr>
```
</tbody>
</table>
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
</tr>
</tbody>
</table>
content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md
+145 -89
View File
@@ -1,147 +1,203 @@
<!--
```
### Synopsis
Check which versions are available to upgrade to and validate whether your current cluster is upgradeable. To skip the internet check, pass in the optional [version] parameter
-->
### 概述
检查可升级到哪些版本，并验证您当前的集群是否可升级。 要跳过互联网检查，请传递可选的 [version] 参数
```
​```
kubeadm upgrade plan [version] [flags]
```
<!--
​```
### Options
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.</td>
</tr>
<tr>
<td colspan="2">--config string</td>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for plan</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for plan</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td>
</tr>
-->
### 选项
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">显示不稳定版本的 Kubernetes 作为升级替代方案，并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies whether the configuration file that will be used in the upgrade should be printed or not.</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">显示 Kubernetes 的发行候选版本作为升级选择，并允许升级到 Kubernetes 的发行候选版本。</td>
</tr>
</tbody>
</table>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径。</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">一组描述各种特征特性门控的键值对。选项有：<br/>IPv6DualStack=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">检查清单，其错误将显示为警告。 例如：“IsPrivilegedUser，Swap”。 值 “all” 忽略所有检查的错误。</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件。 如果标志为未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">指定是否打印将在升级中使用的配置文件。</td>
</tr>
<!--
### Options inherited from parent commands
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
</tr>
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
</tr>
</tbody>
</table>
```
-->
```
### 概述
检查可升级到哪些版本，并验证您当前的集群是否可升级。 要跳过互联网检查，请传递可选的 [version] 参数
​```
kubeadm upgrade plan [version] [flags]
​```
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-experimental-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">显示不稳定版本的 Kubernetes 作为升级替代方案，并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。</td>
</tr>
<tr>
<td colspan="2">--allow-release-candidate-upgrades</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">显示 Kubernetes 的发行候选版本作为升级选择，并允许升级到 Kubernetes 的发行候选版本。</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">配置文件的路径。</td>
</tr>
<tr>
<td colspan="2">--feature-gates string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">一组描述各种特征特性门控的键值对。选项有：IPv6DualStack=true|false (ALPHA - default=false) PublicKeysECDSA=true|false (ALPHA - default=false)</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">帮助</td>
</tr>
<tr>
<td colspan="2">--ignore-preflight-errors stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">检查清单，其错误将显示为警告。 例如：“IsPrivilegedUser，Swap”。 值 “all” 忽略所有检查的错误。</td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">与集群通信时使用的 kubeconfig 文件。 如果标志为未设置，则可以在一组标准位置中搜索现有的 kubeconfig 文件。</td>
</tr>
<tr>
<td colspan="2">--print-config</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">指定是否打印将在升级中使用的配置文件。</td>
</tr>
</tbody>
</table>
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
</tr>
</tbody>
</table>
```
content/zh/docs/tasks/access-application-cluster/access-cluster.md
+1 -1
View File
@@ -145,7 +145,7 @@ In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the
```shell
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
{
"kind": "APIVersions",
content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
+7 -4
View File
@@ -190,13 +190,16 @@ traffic spreading.
<!--
* `service.spec.healthCheckNodePort` - specifies the health check nodePort
(numeric port number) for the service. If not specified, `healthCheckNodePort` is
created by the service API backend with the allocated `nodePort`. It will use the
user-specified `nodePort` value if specified by the client. It only has an
(numeric port number) for the service. If `healthCheckNodePort` isn't specified,
the service controller allocates a port from your cluster's NodePort range. You
can configure that range by setting an API server command line option,
`--service-node-port-range`. It will use the
user-specified `healthCheckNodePort` value if specified by the client. It only has an
effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to Local.
-->
* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定，则 serviceCheckNodePort 由服务 API 后端使用已分配的 nodePort 创建。如果客户端指定，它将使用客户端指定的 nodePort 值。仅当 type 设置为 LoadBalancer 并且 externalTrafficPolicy 设置为 Local 时才生效。
* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定 `healthCheckNodePort`，服务控制器从集群的 NodePort 范围内分配一个端口。您可以通过设置 API 服务器的命令行选项 `--service-node-port-range` 来配置上述范围。它将会使用用户指定的 `healthCheckNodePort` 值（如果被客户端指定）。仅当 `type` 设置为 LoadBalancer 并且 `externalTrafficPolicy` 设置为 Local 时才生效。
<!--
Setting `externalTrafficPolicy` to Local in the Service configuration file
content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
+9 -9
View File
@@ -515,25 +515,25 @@ kubectl delete namespace mem-example
### 应用开发者扩展阅读
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [配置 Pod 的服务质量](/docs/tasks/configure-pod-container/quality-service-pod/)
* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
### 集群管理员扩展阅读
* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [配置命名空间的最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [配置命名空间的最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [配置命名空间下 Pod 总数](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [配置 API 对象配额](/docs/tasks/administer-cluster/quota-api-object/)
* [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
+19 -20
View File
@@ -83,7 +83,7 @@ wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-c
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# 创建 configmap
kubectl create c game-config --from-file=configure-pod-container/configmap/
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
```
<!-- combines the contents of the `configure-pod-container/configmap/` directory -->
@@ -331,7 +331,7 @@ data:
```
<!-- #### Define the key to use when creating a ConfigMap from a file -->
#### 定义从文件创建 ConfigMap 时要使用的密钥
#### 定义从文件创建 ConfigMap 时要使用的键
<!-- You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument: -->
您可以在使用 `--from-file` 参数时,在 ConfigMap 的 `data` 部分中定义除文件名以外的其他键:
@@ -341,7 +341,7 @@ kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
<!-- where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent. -->
`<my-key-name>` 是您要在 ConfigMap 中使用的密钥， `<path-to-file>` 是您想要键表示数据源文件的位置。
`<my-key-name>` 是您要在 ConfigMap 中使用的键名， `<path-to-file>` 是您想要键表示数据源文件的位置。
<!-- For example: -->
例如:
@@ -487,7 +487,7 @@ new ConfigMap is generated each time the content is modified. -->
请注意，生成的 ConfigMap 名称具有通过对内容进行散列而附加的后缀，这样可以确保每次修改内容时都会生成新的 ConfigMap。
<!-- #### Define the key to use when generating a ConfigMap from a file -->
#### 定义从文件生成 ConfigMap 时要使用的密钥
#### 定义从文件生成 ConfigMap 时要使用的键
<!-- You can define a key other than the file name to use in the ConfigMap generator.
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
with the key `game-special-key` -->
@@ -664,7 +664,7 @@ very charm
## 将 ConfigMap 数据添加到一个容器中
<!-- As explained in [Create ConfigMaps from files](#create-configmaps-from-files), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value. -->
如[根据文件创建ConfigMap](＃create-configmaps-from-files)中所述，当您使用 ``--from-file`` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的密钥，文件内容成为密钥的值。
如[根据文件创建ConfigMap](＃create-configmaps-from-files)中所述，当您使用 ``--from-file`` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的键，文件内容成为键对应的值。
<!-- The examples in this section refer to a ConfigMap named special-config, shown below. -->
本节中的示例引用了一个名为 special-config 的 ConfigMap，如下所示：
@@ -679,7 +679,7 @@ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.y
```
<!-- ### Populate a Volume with data stored in a ConfigMap -->
### 使用存储在 ConfigMap 中的数据填充容器
### 使用存储在 ConfigMap 中的数据填充数据卷
<!-- Add the ConfigMap name under the `volumes` section of the Pod specification.
This adds the ConfigMap data to the directory specified as `volumeMounts.mountPath` (in this case, `/etc/config`).
@@ -711,12 +711,12 @@ SPECIAL_TYPE
{{< /caution >}}
<!-- ### Add ConfigMap data to a specific path in the Volume -->
### 将 ConfigMap 数据添加到容器中的特定路径
### 将 ConfigMap 数据添加到数据卷中的特定路径
<!-- Use the `path` field to specify the desired file path for specific ConfigMap items.
In this case, the `SPECIAL_LEVEL` item will be mounted in the `config-volume` volume at `/etc/config/keys`. -->
使用 `path` 字段为特定的 ConfigMap 项目指定所需的文件路径。
在这种情况下, `SPECIAL_LEVEL` 将安装在 `/etc/config/keys` 目录下的 `config-volume` 容器中。
在这种情况下, `SPECIAL_LEVEL` 将挂载在 `/etc/config/keys` 目录下的 `config-volume` 数据卷中。
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
@@ -736,25 +736,25 @@ very
{{< caution >}}
<!-- Like before, all previous files in the `/etc/config/` directory will be deleted. -->
和以前一样，`/etc/config/` 目录中的所有先前文件都将被删除。
如之前所说，`/etc/config/` 目录中所有先前的文件都将被删除。
{{< /caution >}}
<!-- ### Project keys to specific paths and file permissions -->
### 项目密钥以指定路径和文件权限
### 映射键以指定路径和文件权限
<!-- You can project keys to specific paths and specific permissions on a per-file
basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. -->
您可以将密钥映射到每个文件的特定路径和特定权限。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 用户指南说明了语法。
您可以通过映射键来指定每个文件的特定路径和特定权限。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 用户指南说明了语法。
<!-- ### Mounted ConfigMaps are updated automatically -->
### 挂载的 ConfigMap 将自动更新
<!-- When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet. -->
更新已经在容器中使用的 ConfigMap 时，最终也会更新映射键。Kubelet 实时检查是否在每个定期同步中都更新已安装的 ConfigMap。它使用其基于本地 ttl 的缓存来获取 ConfigMap 的当前值。结果，从更新 ConfigMap 到将新密钥映射到 Pod 的总延迟可以与 ConfigMap 在 kubelet 中缓存的 kubelet 同步周期 ttl 一样长。
更新已经在数据卷中使用的 ConfigMap 时，最终也会更新映射键。Kubelet 在每次定期同步时都会检查已挂载的 ConfigMap 是否过期。它使用其基于本地 ttl 的缓存来获取 ConfigMap 的当前值。因此，更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与 kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 ttl 一样长。
{{< note >}}
<!-- A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. -->
使用 ConfigMap 作为子路径[subPath](/docs/concepts/storage/volumes/#using-subpath)的容器将不会收到 ConfigMap 更新。
使用 ConfigMap 作为[子路径](/docs/concepts/storage/volumes/#using-subpath)的数据卷将不会收到 ConfigMap 更新。
{{< /note >}}
@@ -769,11 +769,11 @@ ConfigMap API 资源将配置数据存储为键值对。数据可以在 Pod 中
{{< note >}}
<!-- ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. -->
ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 表示为类似于 Linux `/etc` 目录及其内容的东西。例如，如果您从 ConfigMap 创建[Kubernetes Volume](/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该容器中的单个文件表示。
ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux `/etc` 目录及其内容的东西。例如，如果您从 ConfigMap 创建[Kubernetes Volume](/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该数据卷中的单个文件表示。
{{< /note >}}
<!-- The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. -->
ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以很简单 -- 就像使用 `--from-literal` -- 定义的单个属性一样，也可以很复杂 -- 例如使用 `--from-file` 定义的配置文件或 JSON blob。
ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以简单（如用 `--from-literal` 的单个属性定义）或复杂（如用 `--from-file` 的配置文件或 JSON blob定义）。
```yaml
apiVersion: v1
@@ -797,7 +797,7 @@ data:
### 限制规定
<!-- - You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. -->
- 在 Pod 规范中引用它之前，必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，对 ConfigMap 中不存在的键的引用将阻止容器启动。
- 在 Pod 规范中引用之前，必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，引用 ConfigMap 中不存在的键也会阻止 Pod 启动。
<!-- - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: -->
- 如果您使用 `envFrom` 从 ConfigMap 中定义环境变量，那么将忽略被认为无效的键。可以启动 Pod，但无效名称将记录在事件日志中(InvalidVariableNames)。日志消息列出了每个跳过的键。例如:
@@ -814,15 +814,14 @@ data:
```
<!-- - ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. -->
- ConfigMaps reside in a specific [命令空间](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace.
ConfigMap 驻留在特定的[命令空间](/docs/concepts/overview/working-with-objects/namespaces/)中。ConfigMap 只能由位于相同命令空间中的 Pod 引用。
- ConfigMap 位于特定的[命名空间](/docs/concepts/overview/working-with-objects/namespaces/)中. 每个 ConfigMap 只能被同一命名空间中的 Pod 引用.
<!-- - Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. This includes pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API. -->
- Kubelet 不支持将 ConfigMap 用于未在 API 服务器上找到的 Pod。这包括通过 Kubelet 的 `--manifest-url` 参数，`--config` 参数或者 Kubelet REST API 创建的容器。
- Kubelet 不支持将 ConfigMap 用于未在 API 服务器上找到的 Pod。包括通过 Kubelet 的 `--manifest-url` 参数，`--config` 参数或者 Kubelet REST API 创建的容器。
{{< note >}}
<!-- These are not commonly-used ways to create pods. -->
这些不是创建 pods 的常用方法。
以上并不是创建 Pod 的常用方法。
{{< /note >}}
content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
+2 -2
View File
@@ -532,14 +532,14 @@ Learn about additional debugging tools, including:
* [Logging](/docs/concepts/cluster-administration/logging/)
* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/)
* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/)
-->
* [日志](/docs/concepts/cluster-administration/logging/)
* [监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [使用 `exec` 进入容器](/docs/tasks/debug-application-cluster/get-shell-running-container/)
* [使用代理连接容器](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
* [使用代理连接容器](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
* [使用端口转发连接容器](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [使用 crictl 检查节点](/docs/tasks/debug-application-cluster/crictl/)
content/zh/docs/tasks/debug-application-cluster/debug-service.md
+610 -768
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md
+5 -5
View File
@@ -27,7 +27,7 @@ Cron jobs are useful for creating periodic and recurring tasks, like running bac
Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period.
-->
你可以利用 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。
你可以利用 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。
CronJobs 在创建周期性以及重复性的任务时很有帮助，例如执行备份操作或者发送邮件。CronJobs 也可以在特定时间调度单个任务，例如你想调度低活跃周期的任务。
@@ -51,7 +51,7 @@ For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-j
CronJobs 有一些限制和特点。
例如，在特定状况下，同一个 CronJob 可以创建多个任务。
因此，任务应该是幂等的。
查看更多限制，请参考 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs)。
查看更多限制，请参考 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs)。
@@ -67,7 +67,7 @@ for more), and then restart both the API server and the controller manager
component.
-->
* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/zh/docs/tasks/administer-cluster/cluster-management/#打开或关闭集群的-api-版本)
), 然后重启 API 服务器和控制管理器。
@@ -192,7 +192,7 @@ Deleting the cron job removes all the jobs and pods it created and stops it from
You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
-->
删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/docs/concepts/workloads/controllers/garbage-collection/)。
删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)。
<!--
## Writing a Cron Job Spec
@@ -206,7 +206,7 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co
## 编写 CronJob 声明信息
像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/docs/user-guide/deploying-applications) 和 [使用 kubectl 管理资源](/docs/user-guide/working-with-resources).
像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/).
CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+1 -1
View File
@@ -40,7 +40,7 @@ weight: 20
<!--
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2<span class="btn__next">›</span></a>
-->
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">继续阅读第二单元<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">继续阅读第二单元<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+1 -1
View File
@@ -33,7 +33,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3<span class="btn__next">›</span></a> -->
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">继续阅读第3单元<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">继续阅读第3单元<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+1 -1
View File
@@ -42,7 +42,7 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">继续阅读第4单元<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html
+1 -1
View File
@@ -210,7 +210,7 @@ weight: 10
<!--
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a>
-->
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button"> 开始交互式教程 <span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button"> 开始交互式教程 <span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+1 -1
View File
@@ -38,7 +38,7 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">继续阅读第5单元<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+1 -1
View File
@@ -34,7 +34,7 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button"><!--Continue to Module 6-->继续参阅第6单元<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/update/update-intro/" role="button"><!--Continue to Module 6-->继续参阅第6单元<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+1 -1
View File
@@ -127,7 +127,7 @@ weight: 10
<div class="row">
<div class="col-md-12">
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> -->
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html
+1 -1
View File
@@ -177,7 +177,7 @@ weight: 10
<!--
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a>
-->
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">启动交互教程<span class="btn__next">›</span></a>
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">启动交互教程<span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/stateful-application/basic-stateful-set.md
+5 -5
View File
@@ -867,12 +867,12 @@ Patch the StatefulSet to decrement the partition.
请注意，虽然更新策略是 `RollingUpdate`，StatefulSet 控制器还是会使用原始的容器恢复 Pod。这是因为 Pod 的序号比 `updateStrategy` 指定的 `partition` 更小。
#### 灰度扩容
#### 灰度发布
你可以通过减少 [上文](#分段更新)指定的 `partition` 来进行灰度扩容，以此来测试你的程序的改动。
你可以通过减少 [上文](#分段更新)指定的 `partition` 来进行灰度发布，以此来测试你的程序的改动。
Patch StatefulSet 来减少分区。
通过 patch 命令修改 StatefulSet 来减少分区。
```shell
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
@@ -977,9 +977,9 @@ The partition is currently set to `2`. Set the partition to `0`.
`web-1` 被按照原来的配置恢复，因为 Pod 的序号小于分区。当指定了分区时，如果更新了 StatefulSet 的 `.spec.template`，则所有序号大于或等于分区的 Pod 都将被更新。如果一个序号小于分区的 Pod 被删除或者终止，它将被按照原来的配置恢复。
#### 分阶段的扩容
#### 分阶段的发布
你可以使用类似[灰度扩容](#灰度扩容)的方法执行一次分阶段的扩容（例如一次线性的、等比的或者指数形式的扩容）。要执行一次分阶段的扩容，你需要设置 `partition` 为希望控制器暂停更新的序号。
你可以使用类似[灰度发布](#灰度发布)的方法执行一次分阶段的发布（例如一次线性的、等比的或者指数形式的发布）。要执行一次分阶段的发布，你需要设置 `partition` 为希望控制器暂停更新的序号。
分区当前为`2`。请将分区设置为`0`。
content/zh/examples/admin/sched/my-scheduler.yaml
+13
View File
@@ -17,6 +17,19 @@ roleRef:
name: system:kube-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: my-scheduler-as-volume-scheduler
subjects:
- kind: ServiceAccount
name: my-scheduler
namespace: kube-system
roleRef:
kind: ClusterRole
name: system:volume-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
content/zh/examples/application/deployment-retainkeys.yaml
+19
View File
@@ -0,0 +1,19 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: retainkeys-demo
spec:
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 30%
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: retainkeys-demo-ctr
image: nginx
content/zh/examples/controllers/fluentd-daemonset-update.yaml
+48
View File
@@ -0,0 +1,48 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/zh/examples/controllers/fluentd-daemonset.yaml
+42
View File
@@ -0,0 +1,42 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/zh/examples/examples_test.go
+173 -65
View File
@@ -28,34 +28,105 @@ import (
"testing"
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/apimachinery/pkg/runtime/schema"
"k8s.io/apimachinery/pkg/types"
"k8s.io/apimachinery/pkg/util/validation/field"
"k8s.io/apimachinery/pkg/util/yaml"
utilfeature "k8s.io/apiserver/pkg/util/feature"
// "k8s.io/apiserver/pkg/util/feature"
"k8s.io/kubernetes/pkg/api/legacyscheme"
"k8s.io/kubernetes/pkg/api/testapi"
"k8s.io/kubernetes/pkg/apis/apps"
apps_validation "k8s.io/kubernetes/pkg/apis/apps/validation"
"k8s.io/kubernetes/pkg/apis/autoscaling"
autoscaling_validation "k8s.io/kubernetes/pkg/apis/autoscaling/validation"
"k8s.io/kubernetes/pkg/apis/batch"
batch_validation "k8s.io/kubernetes/pkg/apis/batch/validation"
api "k8s.io/kubernetes/pkg/apis/core"
"k8s.io/kubernetes/pkg/apis/core/validation"
"k8s.io/kubernetes/pkg/apis/extensions"
ext_validation "k8s.io/kubernetes/pkg/apis/extensions/validation"
"k8s.io/kubernetes/pkg/apis/networking"
networking_validation "k8s.io/kubernetes/pkg/apis/networking/validation"
"k8s.io/kubernetes/pkg/apis/policy"
policy_validation "k8s.io/kubernetes/pkg/apis/policy/validation"
"k8s.io/kubernetes/pkg/apis/rbac"
rbac_validation "k8s.io/kubernetes/pkg/apis/rbac/validation"
"k8s.io/kubernetes/pkg/apis/settings"
settings_validation "k8s.io/kubernetes/pkg/apis/settings/validation"
"k8s.io/kubernetes/pkg/apis/storage"
storage_validation "k8s.io/kubernetes/pkg/apis/storage/validation"
"k8s.io/kubernetes/pkg/capabilities"
"k8s.io/kubernetes/pkg/registry/batch/job"
// initialize install packages
_ "k8s.io/kubernetes/pkg/apis/apps/install"
_ "k8s.io/kubernetes/pkg/apis/autoscaling/install"
_ "k8s.io/kubernetes/pkg/apis/batch/install"
_ "k8s.io/kubernetes/pkg/apis/core/install"
_ "k8s.io/kubernetes/pkg/apis/networking/install"
_ "k8s.io/kubernetes/pkg/apis/policy/install"
_ "k8s.io/kubernetes/pkg/apis/rbac/install"
_ "k8s.io/kubernetes/pkg/apis/settings/install"
_ "k8s.io/kubernetes/pkg/apis/storage/install"
)
var (
Groups map[string]TestGroup
serializer runtime.SerializerInfo
)
// TestGroup contains GroupVersion to uniquely identify the API
type TestGroup struct {
externalGroupVersion schema.GroupVersion
}
// GroupVersion makes copy of schema.GroupVersion
func (g TestGroup) GroupVersion() *schema.GroupVersion {
copyOfGroupVersion := g.externalGroupVersion
return &copyOfGroupVersion
}
// Codec returns the codec for the API version to test against
func (g TestGroup) Codec() runtime.Codec {
if serializer.Serializer == nil {
return legacyscheme.Codecs.LegacyCodec(g.externalGroupVersion)
}
return legacyscheme.Codecs.CodecForVersions(serializer.Serializer, legacyscheme.Codecs.UniversalDeserializer(), schema.GroupVersions{g.externalGroupVersion}, nil)
}
func initGroups() {
Groups = make(map[string]TestGroup)
groupNames := []string{
api.GroupName,
apps.GroupName,
autoscaling.GroupName,
batch.GroupName,
networking.GroupName,
policy.GroupName,
rbac.GroupName,
settings.GroupName,
storage.GroupName,
}
for _, gn := range groupNames {
versions := legacyscheme.Scheme.PrioritizedVersionsForGroup(gn)
Groups[gn] = TestGroup{
externalGroupVersion: schema.GroupVersion{
Group: gn,
Version: versions[0].Version,
},
}
}
}
func getCodecForObject(obj runtime.Object) (runtime.Codec, error) {
kinds, _, err := legacyscheme.Scheme.ObjectKinds(obj)
if err != nil {
@@ -63,7 +134,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) {
}
kind := kinds[0]
for _, group := range testapi.Groups {
for _, group := range Groups {
if group.GroupVersion().Group != kind.Group {
continue
}
@@ -85,7 +156,7 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) {
func validateObject(obj runtime.Object) (errors field.ErrorList) {
// Enable CustomPodDNS for testing
utilfeature.DefaultFeatureGate.Set("CustomPodDNS=true")
// feature.DefaultFeatureGate.Set("CustomPodDNS=true")
switch t := obj.(type) {
case *api.ConfigMap:
if t.Namespace == "" {
@@ -96,7 +167,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = validation.ValidateEndpoints(t)
errors = validation.ValidateEndpointsCreate(t)
case *api.LimitRange:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
@@ -115,7 +186,10 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = validation.ValidatePod(t)
opts := validation.PodValidationOptions{
AllowMultipleHugePageResources: true,
}
errors = validation.ValidatePod(t, opts)
case *api.PodList:
for i := range t.Items {
errors = append(errors, validateObject(&t.Items[i])...)
@@ -148,7 +222,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = validation.ValidateService(t)
errors = validation.ValidateService(t, true)
case *api.ServiceAccount:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
@@ -189,11 +263,15 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
t.Namespace = api.NamespaceDefault
}
errors = apps_validation.ValidateDeployment(t)
case *extensions.Ingress:
case *networking.Ingress:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = ext_validation.ValidateIngress(t)
gv := schema.GroupVersion{
Group: networking.GroupName,
Version: legacyscheme.Scheme.PrioritizedVersionsForGroup(networking.GroupName)[0].Version,
}
errors = networking_validation.ValidateIngressCreate(t, gv)
case *policy.PodSecurityPolicy:
errors = policy_validation.ValidatePodSecurityPolicy(t)
case *apps.ReplicaSet:
@@ -206,6 +284,11 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
t.Namespace = api.NamespaceDefault
}
errors = batch_validation.ValidateCronJob(t)
case *networking.NetworkPolicy:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = networking_validation.ValidateNetworkPolicy(t)
case *policy.PodDisruptionBudget:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
@@ -247,10 +330,6 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data
if err != nil {
return err
}
// workaround for Jekyllr limit
if bytes.HasPrefix(data, []byte("---\n")) {
return fmt.Errorf("YAML file cannot start with \"---\", please remove the first line")
}
name := strings.TrimSuffix(file, ext)
var docs [][]byte
@@ -286,11 +365,14 @@ func walkConfigFiles(inDir string, t *testing.T, fn func(name, path string, data
}
func TestExampleObjectSchemas(t *testing.T) {
initGroups()
// Please help maintain the alphabeta order in the map
cases := map[string]map[string][]runtime.Object{
"admin": {
"namespace-dev": {&api.Namespace{}},
"namespace-prod": {&api.Namespace{}},
"namespace-dev": {&api.Namespace{}},
"namespace-prod": {&api.Namespace{}},
"snowflake-deployment": {&apps.Deployment{}},
},
"admin/cloud": {
"ccm-example": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.DaemonSet{}},
@@ -298,6 +380,7 @@ func TestExampleObjectSchemas(t *testing.T) {
"admin/dns": {
"busybox": {&api.Pod{}},
"dns-horizontal-autoscaler": {&apps.Deployment{}},
"dnsutils": {&api.Pod{}},
},
"admin/logging": {
"fluentd-sidecar-config": {&api.ConfigMap{}},
@@ -343,21 +426,23 @@ func TestExampleObjectSchemas(t *testing.T) {
"storagelimits": {&api.LimitRange{}},
},
"admin/sched": {
"my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}},
"my-scheduler": {&api.ServiceAccount{}, &rbac.ClusterRoleBinding{}, &rbac.ClusterRoleBinding{}, &apps.Deployment{}},
"pod1": {&api.Pod{}},
"pod2": {&api.Pod{}},
"pod3": {&api.Pod{}},
},
"application": {
"deployment": {&apps.Deployment{}},
"deployment-patch": {&apps.Deployment{}},
"deployment-scale": {&apps.Deployment{}},
"deployment-update": {&apps.Deployment{}},
"nginx-app": {&api.Service{}, &apps.Deployment{}},
"nginx-with-request": {&apps.Deployment{}},
"shell-demo": {&api.Pod{}},
"simple_deployment": {&apps.Deployment{}},
"update_deployment": {&apps.Deployment{}},
"deployment": {&apps.Deployment{}},
"deployment-patch": {&apps.Deployment{}},
"deployment-retainkeys": {&apps.Deployment{}},
"deployment-scale": {&apps.Deployment{}},
"deployment-update": {&apps.Deployment{}},
"nginx-app": {&api.Service{}, &apps.Deployment{}},
"nginx-with-request": {&apps.Deployment{}},
"php-apache": {&apps.Deployment{}, &api.Service{}},
"shell-demo": {&api.Pod{}},
"simple_deployment": {&apps.Deployment{}},
"update_deployment": {&apps.Deployment{}},
},
"application/cassandra": {
"cassandra-service": {&api.Service{}},
@@ -413,15 +498,17 @@ func TestExampleObjectSchemas(t *testing.T) {
"configmap-multikeys": {&api.ConfigMap{}},
},
"controllers": {
"daemonset": {&apps.DaemonSet{}},
"frontend": {&apps.ReplicaSet{}},
"hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}},
"job": {&batch.Job{}},
"replicaset": {&apps.ReplicaSet{}},
"replication": {&api.ReplicationController{}},
"replication-nginx-1.7.9": {&api.ReplicationController{}},
"replication-nginx-1.9.2": {&api.ReplicationController{}},
"nginx-deployment": {&apps.Deployment{}},
"daemonset": {&apps.DaemonSet{}},
"fluentd-daemonset": {&apps.DaemonSet{}},
"fluentd-daemonset-update": {&apps.DaemonSet{}},
"frontend": {&apps.ReplicaSet{}},
"hpa-rs": {&autoscaling.HorizontalPodAutoscaler{}},
"job": {&batch.Job{}},
"replicaset": {&apps.ReplicaSet{}},
"replication": {&api.ReplicationController{}},
"replication-nginx-1.14.2": {&api.ReplicationController{}},
"replication-nginx-1.16.1": {&api.ReplicationController{}},
"nginx-deployment": {&apps.Deployment{}},
},
"debug": {
"counter-pod": {&api.Pod{}},
@@ -455,6 +542,8 @@ func TestExampleObjectSchemas(t *testing.T) {
"pod-configmap-volume": {&api.Pod{}},
"pod-configmap-volume-specific-key": {&api.Pod{}},
"pod-multiple-configmap-env-variable": {&api.Pod{}},
"pod-nginx-preferred-affinity": {&api.Pod{}},
"pod-nginx-required-affinity": {&api.Pod{}},
"pod-nginx-specific-node": {&api.Pod{}},
"pod-nginx": {&api.Pod{}},
"pod-projected-svc-token": {&api.Pod{}},
@@ -462,6 +551,7 @@ func TestExampleObjectSchemas(t *testing.T) {
"pod-single-configmap-env-variable": {&api.Pod{}},
"pod-with-node-affinity": {&api.Pod{}},
"pod-with-pod-affinity": {&api.Pod{}},
"pod-with-toleration": {&api.Pod{}},
"private-reg-pod": {&api.Pod{}},
"share-process-namespace": {&api.Pod{}},
"simple-pod": {&api.Pod{}},
@@ -471,14 +561,17 @@ func TestExampleObjectSchemas(t *testing.T) {
"redis-pod": {&api.Pod{}},
},
"pods/inject": {
"dapi-envars-container": {&api.Pod{}},
"dapi-envars-pod": {&api.Pod{}},
"dapi-volume": {&api.Pod{}},
"dapi-volume-resources": {&api.Pod{}},
"envars": {&api.Pod{}},
"secret": {&api.Secret{}},
"secret-envars-pod": {&api.Pod{}},
"secret-pod": {&api.Pod{}},
"dapi-envars-container": {&api.Pod{}},
"dapi-envars-pod": {&api.Pod{}},
"dapi-volume": {&api.Pod{}},
"dapi-volume-resources": {&api.Pod{}},
"envars": {&api.Pod{}},
"pod-multiple-secret-env-variable": {&api.Pod{}},
"pod-secret-envFrom": {&api.Pod{}},
"pod-single-secret-env-variable": {&api.Pod{}},
"secret": {&api.Secret{}},
"secret-envars-pod": {&api.Pod{}},
"secret-pod": {&api.Pod{}},
},
"pods/probe": {
"exec-liveness": {&api.Pod{}},
@@ -517,38 +610,53 @@ func TestExampleObjectSchemas(t *testing.T) {
"redis": {&api.Pod{}},
},
"policy": {
"baseline-psp": {&policy.PodSecurityPolicy{}},
"example-psp": {&policy.PodSecurityPolicy{}},
"privileged-psp": {&policy.PodSecurityPolicy{}},
"restricted-psp": {&policy.PodSecurityPolicy{}},
"example-psp": {&policy.PodSecurityPolicy{}},
"zookeeper-pod-disruption-budget-maxunavailable": {&policy.PodDisruptionBudget{}},
"zookeeper-pod-disruption-budget-minunavailable": {&policy.PodDisruptionBudget{}},
"zookeeper-pod-disruption-budget-minavailable": {&policy.PodDisruptionBudget{}},
},
"service": {
"nginx-service": {&api.Service{}},
"nginx-service": {&api.Service{}},
"load-balancer-example": {&apps.Deployment{}},
},
"service/access": {
"frontend": {&api.Service{}, &apps.Deployment{}},
"hello-service": {&api.Service{}},
"hello": {&apps.Deployment{}},
"frontend": {&api.Service{}, &apps.Deployment{}},
"hello-application": {&apps.Deployment{}},
"hello-service": {&api.Service{}},
"hello": {&apps.Deployment{}},
},
"service/networking": {
"curlpod": {&apps.Deployment{}},
"custom-dns": {&api.Pod{}},
"hostaliases-pod": {&api.Pod{}},
"ingress": {&extensions.Ingress{}},
"nginx-secure-app": {&api.Service{}, &apps.Deployment{}},
"nginx-svc": {&api.Service{}},
"run-my-nginx": {&apps.Deployment{}},
"curlpod": {&apps.Deployment{}},
"custom-dns": {&api.Pod{}},
"dual-stack-default-svc": {&api.Service{}},
"dual-stack-ipv4-svc": {&api.Service{}},
"dual-stack-ipv6-lb-svc": {&api.Service{}},
"dual-stack-ipv6-svc": {&api.Service{}},
"hostaliases-pod": {&api.Pod{}},
"ingress": {&networking.Ingress{}},
"network-policy-allow-all-egress": {&networking.NetworkPolicy{}},
"network-policy-allow-all-ingress": {&networking.NetworkPolicy{}},
"network-policy-default-deny-egress": {&networking.NetworkPolicy{}},
"network-policy-default-deny-ingress": {&networking.NetworkPolicy{}},
"network-policy-default-deny-all": {&networking.NetworkPolicy{}},
"nginx-policy": {&networking.NetworkPolicy{}},
"nginx-secure-app": {&api.Service{}, &apps.Deployment{}},
"nginx-svc": {&api.Service{}},
"run-my-nginx": {&apps.Deployment{}},
},
"windows": {
"configmap-pod": {&api.ConfigMap{}, &api.Pod{}},
"daemonset": {&apps.DaemonSet{}},
"deploy-hyperv": {&apps.Deployment{}},
"deploy-resource": {&apps.Deployment{}},
"emptydir-pod": {&api.Pod{}},
"hostpath-volume-pod": {&api.Pod{}},
"secret-pod": {&api.Secret{}, &api.Pod{}},
"simple-pod": {&api.Pod{}},
"configmap-pod": {&api.ConfigMap{}, &api.Pod{}},
"daemonset": {&apps.DaemonSet{}},
"deploy-hyperv": {&apps.Deployment{}},
"deploy-resource": {&apps.Deployment{}},
"emptydir-pod": {&api.Pod{}},
"hostpath-volume-pod": {&api.Pod{}},
"run-as-username-container": {&api.Pod{}},
"run-as-username-pod": {&api.Pod{}},
"secret-pod": {&api.Secret{}, &api.Pod{}},
"simple-pod": {&api.Pod{}},
},
}
content/zh/examples/policy/baseline-psp.yaml
+74
View File
@@ -0,0 +1,74 @@
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: baseline
annotations:
# Optional: Allow the default AppArmor profile, requires setting the default.
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
# Optional: Allow the default seccomp profile, requires setting the default.
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default,unconfined'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'unconfined'
spec:
privileged: false
# The moby default capability set, defined here:
# https://github.com/moby/moby/blob/0a5cec2833f82a6ad797d70acbf9cbbaf8956017/oci/caps/defaults.go#L6-L19
allowedCapabilities:
- 'CHOWN'
- 'DAC_OVERRIDE'
- 'FSETID'
- 'FOWNER'
- 'MKNOD'
- 'NET_RAW'
- 'SETGID'
- 'SETUID'
- 'SETFCAP'
- 'SETPCAP'
- 'NET_BIND_SERVICE'
- 'SYS_CHROOT'
- 'KILL'
- 'AUDIT_WRITE'
# Allow all volume types except hostpath
volumes:
# 'core' volume types
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
# Allow all other non-hostpath volume types.
- 'awsElasticBlockStore'
- 'azureDisk'
- 'azureFile'
- 'cephFS'
- 'cinder'
- 'csi'
- 'fc'
- 'flexVolume'
- 'flocker'
- 'gcePersistentDisk'
- 'gitRepo'
- 'glusterfs'
- 'iscsi'
- 'nfs'
- 'photonPersistentDisk'
- 'portworxVolume'
- 'quobyte'
- 'rbd'
- 'scaleIO'
- 'storageos'
- 'vsphereVolume'
hostNetwork: false
hostIPC: false
hostPID: false
readOnlyRootFilesystem: false
runAsUser:
rule: 'RunAsAny'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'RunAsAny'
fsGroup:
rule: 'RunAsAny'
content/zh/examples/service/networking/network-policy-allow-all-egress.yaml
-1
View File
@@ -1,4 +1,3 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
content/zh/examples/service/networking/network-policy-allow-all-ingress.yaml
-1
View File
@@ -1,4 +1,3 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
content/zh/examples/service/networking/network-policy-default-deny-all.yaml
-1
View File
@@ -1,4 +1,3 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
content/zh/examples/service/networking/network-policy-default-deny-egress.yaml
-1
View File
@@ -1,4 +1,3 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
content/zh/examples/service/networking/network-policy-default-deny-ingress.yaml
-1
View File
@@ -1,4 +1,3 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: