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.
2016.04.15
如何在AWS上部署安全，可审计，可复现的k8s集群
今天的客座文章是由Colin Hom撰写，CoreOS的基础架构工程师。CoreOS致力于推广谷歌的基础架构模式（Google’s Infrastructure for Everyone Else， #GIFEE），让全世界的容器都能在CoreOS Linux, Tectonic 和 Quay上安全运行。
加入到我们的柏林CoreOS盛宴，这是一个开源分布式系统主题的会议，在这里可以了解到更多关于CoreOS和Kubernetes的信息。
在CoreOS, 我们一直都是在生产环境中大规模部署Kubernetes。今天我们非常兴奋地想分享一款工具，它能让你的Kubernetes生产环境大规模部署更加的轻松。Kube-aws这个工具可以用来在AWS上部署可审计，可复现的k8s集群，而CoreOS本身就在生产环境中使用它。
也许今天，你更多的可能是用手工的方式来拼接Kubernetes组件。但有了这个工具之后，Kubernetes可以流水化地打包、交付，节省时间，减少了相互间的依赖，更加快捷地实现生产环境的部署。
借助于一个简单的模板系统，来生成集群配置，这么做是因为一套声明式的配置模板可以版本控制，审计以及重复部署。而且，由于整个创建过程只用到了AWS CloudFormation 和 cloud-init，你也就不需要额外用到其它的配置管理工具。开箱即用！
如果要跳过演讲，直接了解这个项目，可以看看kube-aws的最新发布，支持Kubernetes 1.2.x。如果要部署集群，可以参考[文档]](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html).
为什么是kube-aws？安全，可审计，可复现
Kube-aws设计初衷有三个目标。
安全 : TLS 资源在嵌入到CloudFormation JSON之前，通过AWS 秘钥管理服务加密。通过单独管理KMS密钥的IAM 策略，可以将CloudFormation栈的访问与TLS秘钥的访问分离开。
可审计 : kube-aws是围绕集群资产的概念来创建。这些配置和账户资产是对集群的完全描述。由于KMS被用来加密TLS资产，因而可以无所顾忌地将未加密的CloudFormation栈 JSON签入到版本控制服务中。
可重复 : –export 选项将参数化的集群定义打包成一整个JSON文件，对应一个CloudFormation栈。这个文件可以版本控制，然后，如果需要的话，通过现有的部署工具直接提交给CloudFormation API。
如何开始用kube-aws
在此基础之上，kube-aws也实现了一些功能，使得在AWS上部署Kubernetes集群更加容易，灵活。下面是一些例子。
Route53集成 : Kube-aws 可以管理你的集群DNS记录，作为配置过程的一部分。
cluster.yaml
externalDNSName: my-cluster.kubernetes.coreos.com
createRecordSet: true
hostedZone: kubernetes.coreos.com
recordSetTTL: 300
现有VPC支持 : 将集群部署到现有的VPC上。
cluster.yaml
vpcId: vpc-xxxxx
routeTableId: rtb-xxxxx
验证 : kube-aws 支持验证 cloud-init 和 CloudFormation定义，以及集群栈会集成用到的外部资源。例如，下面就是一个cloud-config，外带一个拼写错误的参数：
userdata/cloud-config-worker
#cloud-config
coreos:
flannel:
interrface: $private\_ipv4
etcd\_endpoints: {{ .ETCDEndpoints }}
$ kube-aws validate
> Validating UserData… Error: cloud-config validation errors: UserDataWorker: line 4: warning: unrecognized key “interrface”
考虑如何起步？看看kube-aws 文档！
未来的工作
一如既往，kube-aws的目标是让生产环境部署更加的简单。尽管我们现在在AWS下使用kube-aws进行生产环境部署，但是这个项目还是pre-1.0，所以还有很多的地方，kube-aws需要考虑、扩展。
容错 : CoreOS坚信 Kubernetes on AWS是强健的平台，适于容错、自恢复部署。在接下来的几个星期，kube-aws将会迎接新的考验：混世猴子（Chaos Monkey）测试 - 控制平面以及全部！
零停机更新 : 更新CoreOS节点和Kubernetes组件不需要停机，也不需要考虑实例更新策略（instance replacement strategy）的影响。
有一个github issue来追踪这些工作进展。我们期待你的参与，提交issue，或是直接贡献。
想要更多地了解Kubernetes，来柏林CoreOS盛宴看看，- 五月 9-10, 2016
– Colin Hom, 基础架构工程师, CoreOS