Thursday, November 08, 2018
Kubernetes Docs Updates, International Edition
Author: Zach Corleissen (Linux Foundation)
As a co-chair of SIG Docs, I’m excited to share that Kubernetes docs have a fully mature workflow for localization (l10n).
Abbreviations galore
L10n is an abbreviation for localization.
I18n is an abbreviation for internationalization.
I18n is what you do to make l10n easier. L10n is a fuller, more comprehensive process than translation (t9n).
Why localization matters
The goal of SIG Docs is to make Kubernetes easier to use for as many people as possible.
One year ago, we looked at whether it was possible to host the output of a Chinese team working independently to translate the Kubernetes docs. After many conversations (including experts on OpenStack l10n), much transformation, and renewed commitment to easier localization, we realized that open source documentation is, like open source software, an ongoing exercise at the edges of what’s possible.
Consolidating workflows, language labels, and team-level ownership may seem like simple improvements, but these features make l10n scalable for increasing numbers of l10n teams. While SIG Docs continues to iterate improvements, we’ve paid off a significant amount of technical debt and streamlined l10n in a single workflow. That’s great for the future as well as the present.
Consolidated workflow
Localization is now consolidated in the kubernetes/website repository. We’ve configured the Kubernetes CI/CD system, Prow, to handle automatic language label assignment as well as team-level PR review and approval.
Language labels
Prow automatically applies language labels based on file path. Thanks to SIG Docs contributor June Yi, folks can also manually assign language labels in pull request (PR) comments. For example, when left as a comment on an issue or PR, this command assigns the label language/ko (Korean).
/language ko
These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for PRs with Chinese content.
Team review
L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are assigned in an OWNERS file in the top subfolder for English content.
Adding OWNERS files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency.
What’s next
We’re looking forward to the doc sprint in Shanghai to serve as a resource for the Chinese l10n team.
We’re excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress.
If you’re interested in localizing Kubernetes for your own language or region, check out our guide to localizing Kubernetes docs and reach out to a SIG Docs chair for support.
Get involved with SIG Docs
If you’re interested in Kubernetes documentation, come to a SIG Docs weekly meeting, or join #sig-docs in Kubernetes Slack.
2018.03.15
Principles of Container-based Application Design
现如今，几乎所有的的应用程序都可以在容器中运行。但创建云原生应用，通过诸如 Kubernetes 的云原生平台更有效地自动化运行、管理容器化的应用却需要额外的工作。 云原生应用需要考虑故障；即使是在底层架构发生故障时也需要可靠地运行。 为了提供这样的功能，像 Kubernetes 这样的云原生平台需要向运行的应用程序强加一些契约和约束。 这些契约确保应用可以在符合某些约束的条件下运行，从而使得平台可以自动化应用管理。
我已经为容器化应用如何之为云原生应用概括出了七项原则。
| —– |
| 
这里所述的七项原则涉及到构建时和运行时，两类关注点。
构建时
- 单一关注点： 每个容器只解决一个关注点，并且完成的很好。
- 自包含： 一个容器只依赖Linux内核。额外的库要求可以在构建容器时加入。
- 镜像不变性： 容器化的应用意味着不变性，一旦构建完成，不需要根据环境的不同而重新构建。
运行时
- 高可观测性： 每个容器必须实现所有必要的 API 来帮助平台以最好的方式来观测、管理应用。
- 生命周期一致性： 一个容器必须要能从平台中获取事件信息，并作出相应的反应。
- 进程易处理性： 容器化应用的寿命一定要尽可能的短暂，这样，可以随时被另一个容器所替换。
- 运行时限制： 每个容器都必须要声明自己的资源需求，并将资源使用限制在所需要的范围之内。
编译时原则保证了容器拥有合适的粒度，一致性以及结构。运行时原则明确了容器化必须要实现那些功能才能成为云原生函数。遵循这些原则可以帮助你的应用适应 Kubernetes 上的自动化。
白皮书可以免费下载：
想要了解更多关于如何面向 Kubernetes 设计云原生应用，可以看看我的 Kubernetes 模式 一书。
— Bilgin Ibryam, 首席架构师, Red Hat
Twitter: Blog: http://www.ofbizian.com Linkedin:
Bilgin Ibryam (@bibryam) 是 Red Hat 的一名首席架构师， ASF 的开源贡献者，博主，作者以及演讲者。 他是 Camel 设计模式、 Kubernetes 模式的作者。在他的日常生活中，他非常享受指导、培训以及帮助各个团队更加成功地使用分布式系统、微服务、容器，以及云原生应用。