diff --git a/content/zh/_common-resources/images/blocks.png b/content/zh/_common-resources/images/blocks.png new file mode 100644 index 0000000000..3bf6083421 Binary files /dev/null and b/content/zh/_common-resources/images/blocks.png differ diff --git a/content/zh/_common-resources/images/flower.png b/content/zh/_common-resources/images/flower.png new file mode 100755 index 0000000000..adc99f5df5 Binary files /dev/null and b/content/zh/_common-resources/images/flower.png differ diff --git a/content/zh/_common-resources/images/kub_video_banner_homepage.jpg b/content/zh/_common-resources/images/kub_video_banner_homepage.jpg new file mode 100644 index 0000000000..57582e4938 Binary files /dev/null and b/content/zh/_common-resources/images/kub_video_banner_homepage.jpg differ diff --git a/content/zh/_common-resources/images/scalable.png b/content/zh/_common-resources/images/scalable.png new file mode 100644 index 0000000000..21bdb0393c Binary files /dev/null and b/content/zh/_common-resources/images/scalable.png differ diff --git a/content/zh/_common-resources/images/suitcase.png b/content/zh/_common-resources/images/suitcase.png new file mode 100644 index 0000000000..59e070f64a Binary files /dev/null and b/content/zh/_common-resources/images/suitcase.png differ diff --git a/content/zh/_common-resources/index.md b/content/zh/_common-resources/index.md new file mode 100644 index 0000000000..ca03031f1e --- /dev/null +++ b/content/zh/_common-resources/index.md @@ -0,0 +1,3 @@ +--- +headless: true +--- diff --git a/content/zh/_index.html b/content/zh/_index.html index 99fa14482e..f48220d79d 100644 --- a/content/zh/_index.html +++ b/content/zh/_index.html @@ -1,14 +1,14 @@ --- title: "生产级别的容器编排系统" abstract: "自动化的容器部署、扩展和管理" -cid: "home" +cid: home ---
images/flower.png
- +

Kubernetes 是用于自动部署,扩展和管理容器化应用程序的开源系统。

它将组成应用程序的容器组合成逻辑单元,以便于管理和服务发现,Kubernetes 构建在 Google 15 年生产环境经验基础之上,并结合来自社区的最佳创意和实践。

@@ -16,7 +16,7 @@ cid: "home"
images/scalable.png
- +

全球规模

基于允许 Google 每周运行数十亿个容器的原则进行设计,Kubernetes 可以在不增加您的运维团队的情况下进行弹性扩展。

@@ -24,7 +24,7 @@ cid: "home"
images/blocks.png
- +

永不过时

无论您应用运行在本地还是运行于全球任何地域,Kubernetes 的灵活性都可以随着您的需求复杂度不断增加,还可以持续、轻松地对外提供服务。

@@ -32,7 +32,7 @@ cid: "home"
images/suitcase.png
- +

随处运行

Kubernetes 是开源的,可以让您自由地部署在企业内部,私有云、混合云或公有云基础架构,使您轻松将应用迁移至任何位置。

@@ -40,7 +40,7 @@ cid: "home"
- +

Kubernetes: 最后… 它是真正的云平台

Box 的联合创始人和服务架构师 Sam Ghods 发表了热情洋溢的演讲,随着使用 Kubernetes,我们首次有一个通用接口,可以建立真正的部署工具。

@@ -49,35 +49,35 @@ cid: "home"
- +

Kubernetes 特性

- +

自动包装

根据资源需求和其他约束自动放置容器,同时不会牺牲可用性,混合关键和最大努力的工作负载,以提高资源利用率并节省更多资源。

- +

自我修复

重新启动失败的容器,在节点不可用时,替换和重新调度节点上的容器,对用户定义的健康检查不响应的容器会被中止,并且在容器准备好服务之前不会把其向客户端广播。

- +

横向缩放

使用简单的命令或 UI,或者根据 CPU 的使用情况自动调整应用程序副本数。

- +

服务发现和负载均衡

不需要修改您的应用程序来使用不熟悉的服务发现机制,Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称,并可以在它们之间进行负载均衡。

- +

自动部署和回滚

Kubernetes 逐渐部署对应用程序或其配置的更改,同时监视应用程序运行状况,以确保它不会同时终止所有实例。 如果出现问题,Kubernetes会为您恢复更改,利用日益增长的部署解决方案的生态系统。

@@ -101,7 +101,7 @@ cid: "home"
- +

实例探究

@@ -121,29 +121,29 @@ cid: "home" 观看视频
- - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
探究所有的案例
diff --git a/content/zh/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md b/content/zh/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md new file mode 100644 index 0000000000..2576296c64 --- /dev/null +++ b/content/zh/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md @@ -0,0 +1,27 @@ +--- + +title: " Kubernetes 采集视频 " +date: 2015-03-23 +slug: kubernetes-gathering-videos +url: /blog/2015/03/Kubernetes-Gathering-Videos +--- + + + + + +如果你错过了上个月在旧金山举行的 Kubernetes 大会,不要害怕!以下是在 YouTube 上组织成播放列表的晚间演示文稿中的视频。 + +[![Kubernetes Gathering](https://img.youtube.com/vi/q8lGZCKktYo/0.jpg)](https://www.youtube.com/playlist?list=PL69nYSiGNLP2FBVvSLHpJE8_6hRHW8Kxe) diff --git a/content/zh/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md new file mode 100644 index 0000000000..6a345d4950 --- /dev/null +++ b/content/zh/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md @@ -0,0 +1,186 @@ +--- +title: " Kubernetes 社区每周聚会笔记 - 2015年3月27日 " +date: 2015-03-28 +slug: weekly-kubernetes-community-hangout +url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout +--- + + + + +每个星期,Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 + + +日程安排: + + + +\- Andy - 演示远程执行和端口转发 + +\- Quinton - 联邦集群 - 延迟 + +\- Clayton - 围绕 Kubernetes 的 UI 代码共享和协作 + + +从会议指出: + + + +1\. Andy 从 RedHat: + + + +* 演示远程执行 + + + + * kubectl exec -p $POD -- $CMD + + * 作为代理与主机建立连接,找出 pod 所在的节点,代理与 kubelet 的连接,这一点很有趣。通过 nsenter。 + + * 使用 SPDY 通过 HTTP 进行多路复用流式传输 + + * 还有互动模式: + + * 假设第一个容器,可以使用 -c $CONTAINER 一个特定的。 + + * 如果在容器中预先安装了 gdb,则可以交互地将其附加到正在运行的进程中 + + * backtrace、symbol tbles、print 等。 使用gdb可以做的大多数事情。 + + * 也可以用精心制作的参数在上面运行 rsync 或者在容器内设置 sshd。 + + * 一些聊天反馈: + + + +* Andy 还演示了端口转发 +* nnsenter 与 docker exec + + + + * 想要在主机的控制下注入二进制文件,类似于预启动钩子 + + * socat、nsenter,任何预启动钩子需要的 + + + +* 如果能在博客上发表这方面的文章就太好了 +* wheezy 中的 nginx 版本太旧,无法支持所需的主代理功能 + + + +2\. Clayton: 我们的社区组织在哪里,例如 kubernetes UI 组件? + +* google-containers-ui IRC 频道,邮件列表。 +* Tim: google-containers 前缀是历史的,应该只做 "kubernetes-ui" +* 也希望将设计资源投入使用,并且 bower 期望自己的仓库。 +* 通用协议 + + + +3\. Brian Grant: + +* 测试 v1beta3,准备进入。 +* Paul 力于改变命令行的内容。 +* 下周初至中旬,尝试默认启用v1beta3 ? +* 对于任何其他更改,请发出文件并抄送 thockin。 + + + +4\. 一般认为30分钟比60分钟好 + + + +* 不应该为了填满时间而人为地延长。 diff --git a/content/zh/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md b/content/zh/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md new file mode 100644 index 0000000000..3e3b5f6d3d --- /dev/null +++ b/content/zh/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md @@ -0,0 +1,62 @@ +--- +title: 欢迎来到 Kubernetes 博客! +date: 2015-03-20 +slug: welcome-to-kubernetes-blog +url: /blog/2015/03/Welcome-To-Kubernetes-Blog +--- + + + + +欢迎来到新的 Kubernetes 博客。关注此博客,了解 Kubernetes 开源项目。我们计划不时发布发布说明,操作方法文章,活动,甚至一些非常有趣的话题。 + + +如果您正在使用 Kubernetes 或为该项目做出贡献并想要发帖子,[请告诉我](mailto:kitm@google.com)。 + + +首先,以下是 Kubernetes 最近在其他网站上发布的文章摘要: + + + +- [使用 Vitess 和 Kubernetes 在云中扩展 MySQL](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html) +- [虚拟机上的容器群集](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html) +- [想知道的关于 kubernetes 的一切,却又不敢问](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html) +- [什么构成容器集群?](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html) +- [将 OpenStack 和 Kubernetes 与 Murano 集成](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/) +- [容器介绍,Kubernetes 以及现代云计算的发展轨迹](http://googlecloudplatform.blogspot.com/2015/01/in-coming-weeks-we-will-be-publishing.html) +- [什么是 Kubernetes 以及如何使用它?](http://www.centurylinklabs.com/what-is-kubernetes-and-how-to-use-it/) +- [OpenShift V3,Docker 和 Kubernetes 策略](https://blog.openshift.com/v3-docker-kubernetes-interview/) +- [Kubernetes 简介](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes) + + +快乐的云计算! + + + - Kit Merker - Google 云平台产品经理 diff --git a/content/zh/blog/_posts/2015-04-00-Kubernetes-Release-0150.md b/content/zh/blog/_posts/2015-04-00-Kubernetes-Release-0150.md new file mode 100644 index 0000000000..d7071e2377 --- /dev/null +++ b/content/zh/blog/_posts/2015-04-00-Kubernetes-Release-0150.md @@ -0,0 +1,176 @@ +--- +title: " Kubernetes Release: 0.15.0 " +date: 2015-04-16 +slug: kubernetes-release-0150 +url: /blog/2015/04/Kubernetes-Release-0150 +--- + + + +Release 说明: + + + +* 启用 1beta3 API 并将其设置为默认 API 版本 ([#6098][1]) +* 增加了多端口服务([#6182][2]) + * 新入门指南 + * 多节点本地启动指南 ([#6505][3]) + * Google 云平台上的 Mesos ([#5442][4]) + * Ansible 安装说明 ([#6237][5]) +* 添加了一个控制器框架 ([#5270][6], [#5473][7]) +* Kubelet 现在监听一个安全的 HTTPS 端口 ([#6380][8]) +* 使 kubectl 错误更加友好 ([#6338][9]) +* apiserver 现在支持客户端 cert 身份验证 ([#6190][10]) +* apiserver 现在限制了它处理的并发请求的数量 ([#6207][11]) +* 添加速度限制删除 pod ([#6355][12]) +* 将平衡资源分配算法作为优先级函数实现在调度程序包中 ([#6150][13]) +* 从主服务器启用日志收集功能 ([#6396][14]) +* 添加了一个 api 端口来从 Pod 中提取日志 ([#6497][15]) +* 为调度程序添加了延迟指标 ([#6368][16]) +* 为 REST 客户端添加了延迟指标 ([#6409][17]) + + + +* etcd 现在在 master 上的一个 pod 中运行 ([#6221][18]) +* nginx 现在在 master上的容器中运行 ([#6334][19]) +* 开始为主组件构建 Docker 镜像 ([#6326][20]) +* 更新了 GCE 程序以使用 gcloud 0.9.54 ([#6270][21]) +* 更新了 AWS 程序来修复区域与区域语义 ([#6011][22]) +* 记录镜像 GC 失败时的事件 ([#6091][23]) +* 为 kubernetes 客户端添加 QPS 限制器 ([#6203][24]) +* 减少运行 make release 所需的时间 ([#6196][25]) +* 新卷的支持 + * 添加 iscsi 卷插件 ([#5506][26]) + * 添加 glusterfs 卷插件 ([#6174][27]) + * AWS EBS 卷支持 ([#5138][28]) +* 更新到 heapster 版本到 v0.10.0 ([#6331][29]) +* 更新到 etcd 2.0.9 ([#6544][30]) +* 更新到 Kibana 到 v1.2 ([#6426][31]) +* 漏洞修复 + * 如果服务的公共 IP 发生变化,Kube-proxy现在会更新iptables规则 ([#6123][32]) + * 如果初始创建失败,则重试 kube-addons 创建 ([#6200][33]) + * 使 kube-proxy 对耗尽文件描述符更具弹性 ([#6727][34]) + + +要下载,请访问 https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0 + + +[1]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6098 "在 master 中默认启用 v1beta3 api 版本" +[2]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6182 "实现多端口服务" +[3]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6505 "Docker 多节点" +[4]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5442 "谷歌云平台上 Mesos 入门指南" +[5]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6237 "示例 ansible 设置仓库" +[6]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5270 "控制器框架" +[7]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5473 "添加 DeltaFIFO(控制器框架块)" +[8]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6380 "将 kubelet 配置为使用 HTTPS (获得 2)" +[9]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6338 "返回用于配置验证的类型化错误,并简化错误" +[10]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6190 "添加客户端证书认证" +[11]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6207 "为服务器处理的正在运行的请求数量添加一个限制。" +[12]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6355 "添加速度限制删除 pod" +[13]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6150 "将均衡资源分配算法作为优先级函数实现在调度程序包中。" +[14]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6396 "启用主服务器收集日志。" +[15]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6497 "pod 子日志资源" +[16]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6368 "将基本延迟指标添加到调度程序。" +[17]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6409 "向 REST 客户端添加延迟指标" +[18]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6221 "在 pod 中运行 etcd 2.0.5" +[19]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6334 "添加一个 nginx docker 镜像用于主程序。" +[20]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6326 "为主组件创建 Docker 镜像" +[21]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6270 "gcloud 0.9.54 的更新" + + +[22]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6011 "修复 AWS 区域 与 zone" +[23]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6091 "记录镜像 GC 失败时的事件。" +[24]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6203 "向 kubernetes 客户端添加 QPS 限制器。" +[25]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6196 "在 `make release` 的构建和打包阶段并行化架构" +[26]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5506 "添加 iscsi 卷插件" +[27]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6174 "实现 glusterfs 卷插件" +[28]: https://github.com/GoogleCloudPlatform/kubernetes/pull/5138 "AWS EBS 卷支持" +[29]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6331 "将 heapster 版本更新到 v0.10.0" +[30]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6544 "构建 etcd 镜像(版本 2.0.9),并将 kubernetes 集群升级到新版本" +[31]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6426 "更新 Kibana 到 v1.2,它对 Elasticsearch 的位置进行了参数化" +[32]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6123 "修复了 kube-proxy 中的一个错误,如果一个服务的公共 ip 发生变化,它不会更新 iptables 规则" +[33]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6200 "如果 kube-addons 创建失败,请重试 kube-addons 创建。" +[34]: https://github.com/GoogleCloudPlatform/kubernetes/pull/6727 "pkg/proxy: fd 用完后引起恐慌" + diff --git a/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md b/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md new file mode 100644 index 0000000000..e71b8d17be --- /dev/null +++ b/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md @@ -0,0 +1,287 @@ +--- +title: " Kubernetes 社区每周聚会笔记- 2015年4月17日 " +date: 2015-04-17 +slug: weekly-kubernetes-community-hangout_17 +url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17 +--- + + + + +每个星期,Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 + + +议程 + +* Mesos 集成 +* 高可用性(HA) +* 向 e2e 添加性能和分析详细信息以跟踪回归 +* 客户端版本化 + + +笔记 + + + +* Mesos 集成 + + * Mesos 集成提案: + + * 没有阻塞集成的因素。 + + * 文档需要更新。 + + + +* HA + + * 提案今天应该会提交。 + + * Etcd 集群。 + + * apiserver 负载均衡。 + + * 控制器管理器和其他主组件的冷备用。 + + + +* 向 e2e 添加性能和分析详细信息以跟踪回归 + + * 希望红色为性能回归 + + * 需要公共数据库才能发布数据 + + * 查看 + + * Justin 致力于多平台 e2e 仪表盘 + + + +* 客户端版本化 + + * + + * + + * 客户端库当前使用内部 API 对象。 + + * 尽管没有人反映频繁修改 `types.go` 有多痛苦,但我们很为此担心。 + + * 结构化类型在客户端中很有用。版本化的结构就可以了。 + + * 如果从 json/yaml (kubectl) 开始,则不应转换为结构化类型。使用 swagger。 + + + +* Security context + + * + + * 管理员可以限制谁可以运行特权容器或需要特定的 unix uid + + * kubelet 将能够从 apiserver 获取证书 + + * 政策提案将于下周左右出台 + + + +* 讨论用户的上游,等等进入Kubernetes,至少是可选的 +* 1.0 路线图 + + * 重点是性能,稳定性,集群升级 + + * TJ 一直在对[roadmap.md][4]进行一些编辑,但尚未发布PR +* Kubernetes UI + + * 依赖关系分解为第三方 + + * @lavalamp 是评论家 + + +[1]: http://kubernetes.io/images/nav_logo.svg +[2]: http://kubernetes.io/docs/ +[3]: https://kubernetes.io/blog/ +[4]: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/roadmap.md +[5]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17 "permanent link" +[6]: https://resources.blogblog.com/img/icon18_edit_allbkg.gif +[7]: https://www.blogger.com/post-edit.g?blogID=112706738355446097&postID=630924463010638300&from=pencil "Edit Post" +[8]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=email "Email This" +[9]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=blog "BlogThis!" +[10]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=twitter "Share to Twitter" +[11]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=facebook "Share to Facebook" +[12]: https://www.blogger.com/share-post.g?blogID=112706738355446097&postID=630924463010638300&target=pinterest "Share to Pinterest" +[13]: https://kubernetes.io/blog/search/label/community%20meetings +[14]: https://kubernetes.io/blog/search/label/containers +[15]: https://kubernetes.io/blog/search/label/docker +[16]: https://kubernetes.io/blog/search/label/k8s +[17]: https://kubernetes.io/blog/search/label/kubernetes +[18]: https://kubernetes.io/blog/search/label/open%20source +[19]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos "Newer Post" +[20]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3 "Older Post" +[21]: https://kubernetes.io/blog/feeds/630924463010638300/comments/default +[22]: https://img2.blogblog.com/img/widgets/arrow_dropdown.gif +[23]: https://img1.blogblog.com/img/icon_feed12.png +[24]: https://img1.blogblog.com/img/widgets/subscribe-netvibes.png +[25]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault +[26]: https://img1.blogblog.com/img/widgets/subscribe-yahoo.png +[27]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2Fposts%2Fdefault +[28]: https://kubernetes.io/blog/feeds/posts/default +[29]: https://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault +[30]: https://add.my.yahoo.com/content?url=http%3A%2F%2Fblog.kubernetes.io%2Ffeeds%2F630924463010638300%2Fcomments%2Fdefault +[31]: https://resources.blogblog.com/img/icon18_wrench_allbkg.png +[32]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Subscribe&widgetId=Subscribe1&action=editWidget§ionId=sidebar-right-1 "Edit" +[33]: https://twitter.com/kubernetesio +[34]: https://github.com/kubernetes/kubernetes +[35]: http://slack.k8s.io/ +[36]: http://stackoverflow.com/questions/tagged/kubernetes +[37]: http://get.k8s.io/ +[38]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML2&action=editWidget§ionId=sidebar-right-1 "Edit" +[39]: javascript:void(0) +[40]: https://kubernetes.io/blog/2018/ +[41]: https://kubernetes.io/blog/2018/01/ +[42]: https://kubernetes.io/blog/2017/ +[43]: https://kubernetes.io/blog/2017/12/ +[44]: https://kubernetes.io/blog/2017/11/ +[45]: https://kubernetes.io/blog/2017/10/ +[46]: https://kubernetes.io/blog/2017/09/ +[47]: https://kubernetes.io/blog/2017/08/ +[48]: https://kubernetes.io/blog/2017/07/ +[49]: https://kubernetes.io/blog/2017/06/ +[50]: https://kubernetes.io/blog/2017/05/ +[51]: https://kubernetes.io/blog/2017/04/ +[52]: https://kubernetes.io/blog/2017/03/ +[53]: https://kubernetes.io/blog/2017/02/ +[54]: https://kubernetes.io/blog/2017/01/ +[55]: https://kubernetes.io/blog/2016/ +[56]: https://kubernetes.io/blog/2016/12/ +[57]: https://kubernetes.io/blog/2016/11/ +[58]: https://kubernetes.io/blog/2016/10/ +[59]: https://kubernetes.io/blog/2016/09/ +[60]: https://kubernetes.io/blog/2016/08/ +[61]: https://kubernetes.io/blog/2016/07/ +[62]: https://kubernetes.io/blog/2016/06/ +[63]: https://kubernetes.io/blog/2016/05/ +[64]: https://kubernetes.io/blog/2016/04/ +[65]: https://kubernetes.io/blog/2016/03/ +[66]: https://kubernetes.io/blog/2016/02/ +[67]: https://kubernetes.io/blog/2016/01/ +[68]: https://kubernetes.io/blog/2015/ +[69]: https://kubernetes.io/blog/2015/12/ +[70]: https://kubernetes.io/blog/2015/11/ +[71]: https://kubernetes.io/blog/2015/10/ +[72]: https://kubernetes.io/blog/2015/09/ +[73]: https://kubernetes.io/blog/2015/08/ +[74]: https://kubernetes.io/blog/2015/07/ +[75]: https://kubernetes.io/blog/2015/06/ +[76]: https://kubernetes.io/blog/2015/05/ +[77]: https://kubernetes.io/blog/2015/04/ +[78]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_29 +[79]: https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes +[80]: https://kubernetes.io/blog/2015/04/kubernetes-and-mesosphere-dcos +[81]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_17 +[82]: https://kubernetes.io/blog/2015/04/introducing-kubernetes-v1beta3 +[83]: https://kubernetes.io/blog/2015/04/kubernetes-release-0150 +[84]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout_11 +[85]: https://kubernetes.io/blog/2015/04/faster-than-speeding-latte +[86]: https://kubernetes.io/blog/2015/04/weekly-kubernetes-community-hangout +[87]: https://kubernetes.io/blog/2015/03/ +[88]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=BlogArchive&widgetId=BlogArchive1&action=editWidget§ionId=sidebar-right-1 "Edit" +[89]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=HTML&widgetId=HTML1&action=editWidget§ionId=sidebar-right-1 "Edit" +[90]: https://www.blogger.com +[91]: //www.blogger.com/rearrange?blogID=112706738355446097&widgetType=Attribution&widgetId=Attribution1&action=editWidget§ionId=footer-3 "Edit" + + [*[3:27 PM]: 2015-04-17T15:27:00-07:00 diff --git a/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md b/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md new file mode 100644 index 0000000000..c451022671 --- /dev/null +++ b/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md @@ -0,0 +1,143 @@ +--- +title: " Kubernetes 社区每周聚会笔记- 2015年4月24日 " +date: 2015-04-30 +slug: weekly-kubernetes-community-hangout_29 +url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29 +--- + + + + +每个星期,Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 + + +日程安排: + +* Flocker 和 Kubernetes 集成演示 + + +笔记: + +* flocker 和 kubernetes 集成演示 +* * Flocker Q/A + + * 迁移后文件是否仍存在于node1上? + + * Brendan: 有没有计划把它做成一本书?我们不需要 powerstrip? + + * Luke: 需要找出感兴趣的来决定我们是否想让它成为 kube 中的一个一流的持久性磁盘提供商。 + + * Brendan: 删除对 powerstrip 的需求会使其易于使用。完全去做。 + + * Tim: 将它添加到 kubernetes 应该不超过45分钟:) + + + + * Derek: 持久卷和请求相比呢? + + * Luke: 除了基于 ZFS 的新后端之外,差别不大。使工作负载真正可移植。 + + * Tim: 与基于网络的卷非常不同。有趣的是,它是唯一允许升级媒体的产品。 + + * Brendan: 请求,它如何查找重复请求?Cassandra 希望在底层复制数据。向上和向下扩缩是有效的。根据负载动态地创建存储。它的步骤不仅仅是快照——通过编程使用预分配创建副本。 + + * Tim: 帮助自动配置。 + + + + * Brian: flocker 是否需要其他组件? + + * Kai: Flocker 控制服务与主服务器位于同一位置。(dia 在博客上)。Powerstrip + Powerstrip Flocker。对在 etcd 中持久化状态非常有趣。它保存关于每个卷的元数据。 + + * Brendan: 在未来,flocker 可以是一个插件,我们将负责持久性。发布 v1.0。 + + * Brian: 有兴趣为 flocker 等服务添加通用插件。 + + * Luke: 当扩展到单个节点上的许多容器时,Zfs 会变得非常有价值。 + + + + * Alex: flocker 服务可以作为 pod 运行吗? + + * Kai: 是的,唯一的要求是 flocker 控制服务应该能够与 zfs 代理对话。需要在主机上安装 zfs 代理,并且需要访问 zfs 二进制文件。 + + * Brendan: 从理论上讲,所有 zfs 位都可以与设备一起放入容器中。 + + * Luke: 是的,仍然在处理跨容器安装问题。 + + * Tim: pmorie 正在通过它使 kubelet 在容器中工作。可能重复使用。 + + * Kai: Cinder 支持即将到来。几天之后。 +* Bob: 向 GKE 推送 kube 的过程是怎样的?需要更多的可见度。 + + diff --git a/content/zh/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/zh/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md new file mode 100644 index 0000000000..0a4ac17ef5 --- /dev/null +++ b/content/zh/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md @@ -0,0 +1,112 @@ +--- +title: " OpenStack 上的 Kubernetes " +date: 2015-05-19 +slug: kubernetes-on-openstack +url: /blog/2015/05/Kubernetes-On-Openstack +--- + + + +[![](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s400/Untitled%2Bdrawing.jpg)](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s1600/Untitled%2Bdrawing.jpg) + + + +今天,[OpenStack 基金会](https://www.openstack.org/foundation/)通过在其[社区应用程序目录](http://apps.openstack.org/)中包含 Kubernetes,使您更容易在 OpenStack 云上部署和管理 Docker 容器集群。 +今天在温哥华 OpenStack 峰会上的主题演讲中,OpenStack 基金会的首席运营官:Mark Collier 和 [Mirantis](https://www.mirantis.com/) 产品线经理 Craig Peters 通过利用 OpenStack 云中已经存在的计算、存储、网络和标识系统,在几秒钟内启动了 Kubernetes 集群,展示了社区应用程序目录的工作流。 + + +目录中的条目不仅包括[启动 Kubernetes 集群](http://apps.openstack.org/#tab=murano-apps&asset=Kubernetes%20Cluster)的功能,还包括部署在 Kubernetes 管理的 Docker 容器中的一系列应用程序。这些应用包括: + + + + +- +Apache web 服务器 +- +Nginx web 服务器 +- +Crate - Docker的分布式数据库 +- +GlassFish - Java EE 7 应用服务器 +- +Tomcat - 一个开源的 web 服务器和 servlet 容器 +- +InfluxDB - 一个开源的、分布式的、时间序列数据库 +- +Grafana - InfluxDB 的度量仪表板 +- +Jenkins - 一个可扩展的开放源码持续集成服务器 +- +MariaDB 数据库 +- +MySql 数据库 +- +Redis - 键-值缓存和存储 +- +PostgreSQL 数据库 +- +MongoDB NoSQL 数据库 +- +Zend 服务器 - 完整的 PHP 应用程序平台 + + +此列表将会增长,并在[此处](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes)进行策划。您可以检查(并参与)YAML 文件,该文件告诉 Murano 如何根据[此处](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)定义来安装和启动 ...apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml)安装和启动 Kubernetes 集群。 + + +[Kubernetes 开源项目](https://github.com/GoogleCloudPlatform/kubernetes)继续受到社区的欢迎,并且势头越来越好,GitHub 上有超过 11000 个提交和 7648 颗星。从 Red Hat 和 Intel 到 CoreOS 和 Box.net,它已经代表了从企业 IT 到前沿创业企业的一系列客户。我们鼓励您尝试一下,给我们您的反馈,并参与到我们不断增长的社区中来。 + + + + +- Martin Buhr, Kubernetes 开源项目产品经理 + diff --git a/content/zh/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md new file mode 100644 index 0000000000..8f60d7916b --- /dev/null +++ b/content/zh/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md @@ -0,0 +1,121 @@ +--- +title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 " +date: 2015-05-11 +slug: weekly-kubernetes-community-hangout +url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout +--- + + + + +每个星期,Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。 + + + +* 简单的滚动更新 - Brendan + + * 滚动更新 = RCs和Pods很好的例子。 + + * ...pause… (Brendan 需要 Kelsey 的演示恢复技巧) + + * 滚动更新具有恢复功能:取消更新并重新启动,更新从停止的地方继续。 + + * 新控制器获取旧控制器的名称,因此外观是纯粹的更新。 + + * 还可以在 update 中命名版本(最后不会重命名)。 + + + +* Rocket 演示 - CoreOS 的伙计们 + + * Rocket 和 docker 之间的主要区别: Rocket 是无守护进程和以 pod 为中心。。 + + * Rocket 具有原生的 AppContainer 格式,但也支持 docker 镜像格式。 + + * 可以在同一个 pod 中运行 AppContainer 和 docker 容器。 + + * 变更接近于合并。 + + + +* 演示 service accounts 和 secrets 被添加到 pod - Jordan + + * 问题:很难获得与API通信的令牌。 + + * 新的API对象:"ServiceAccount" + + * ServiceAccount 是命名空间,控制器确保命名空间中至少存在一个个默认 service account。 + + * 键入 "ServiceAccountToken",控制器确保至少有一个默认令牌。 + + * 演示 + + * * 可以使用 ServiceAccountToken 创建新的 service account。控制器将为它创建令牌。 + + * 可以创建一个带有 service account 的 pod, pod 将在 /var/run/secrets/kubernets.io/… + + + +* Kubelet 在容器中运行 - Paul + + * Kubelet 成功地运行了带有 secret 的 pod。 + diff --git a/content/zh/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md b/content/zh/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md new file mode 100644 index 0000000000..8e1c001d65 --- /dev/null +++ b/content/zh/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md @@ -0,0 +1,25 @@ +--- +title: "幻灯片:Kubernetes 集群管理,爱丁堡大学演讲" +date: 2015-06-26 +slug: slides-cluster-management-with +url: /blog/2015/06/Slides-Cluster-Management-With +--- + + + + + +2015年6月5日星期五,我在爱丁堡大学给普通听众做了一个演讲,题目是[使用 Kubernetes 进行集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。这次演讲包括一个带有 Kibana 前端 UI 的音乐存储系统的例子,以及一个基于 Elasticsearch 的后端,该后端有助于生成具体的概念,如 pods、复制控制器和服务。 + +[Kubernetes 集群管理](https://docs.google.com/presentation/d/1H4ywDb4vAJeg8KEjpYfhNqFSig0Q8e_X5I36kM9S6q0/pub?start=false&loop=false&delayms=3000)。 diff --git a/content/zh/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md b/content/zh/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md new file mode 100644 index 0000000000..d4ee22a2b1 --- /dev/null +++ b/content/zh/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md @@ -0,0 +1,84 @@ +--- +title: " KubeCon EU 2016:伦敦 Kubernetes 社区 " +date: 2016-02-24 +slug: kubecon-eu-2016-kubernetes-community-in +url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In +--- + + + + +KubeCon EU 2016 是首届[欧洲 Kubernetes](http://kubernetes.io/) 社区会议,紧随 2015 年 11 月召开的北美会议。KubeCon 致力于为 [Kubernetes](http://kubernetes.io/) 爱好者、产品用户和周围的生态系统提供教育和社区参与。 + + +快来加入我们在伦敦,与 Kubernetes 社区的数百人一起出去,体验各种深入的技术专家讲座和用例。 + + +不要错过这些优质的演讲: + + + +* “Kubernetes 硬件黑客:通过旋钮、推杆和滑块探索 Kubernetes API” 演讲者 Ian Lewis 和 Brian Dorsey,谷歌开发布道师* [http://sched.co/6Bl3](http://sched.co/6Bl3) + +* “rktnetes: 容器运行时和 Kubernetes 的新功能” 演讲者 Jonathan Boulle, CoreOS 的主程 -* [http://sched.co/6BY7](http://sched.co/6BY7) + +* “Kubernetes 文档:贡献、修复问题、收集奖金” 作者:John Mulhausen,首席技术作家,谷歌 -* [http://sched.co/6BUP](http://sched.co/6BUP)  +* “[OpenStack 在 Kubernetes 的世界中扮演什么角色?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者:Thierry carez, OpenStack 基金会工程总监 -* http://sched.co/6BYC +* “容器调度的实用指南” 作者:Mandy Waite,开发者倡导者,谷歌 -* [http://sched.co/6BZa](http://sched.co/6BZa) + +* “[《纽约时报》编辑部正在制作 Kubernetes](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis,《纽约时报》网站开发人员 -* [http://sched.co/67f2](http://sched.co/67f2) +* “[使用 NGINX 为 Kubernetes 创建一个高级负载均衡解决方案](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” 作者:Andrew Hutchings, NGINX 技术产品经理 -* http://sched.co/6Bc9 +* 还有更多 http://kubeconeurope2016.sched.org/ + + +[在这里](https://ti.to/kubecon/kubecon-eu-2016)获取您的 KubeCon EU 门票。 + + +会场地址:CodeNode * 英国伦敦南广场 10 号 +酒店住宿:[酒店](https://skillsmatter.com/contact-us) +网站:[kubecon.io] (https://www.kubecon.io/) +推特:[@KubeConio] (https://twitter.com/kubeconio) +谷歌是 KubeCon EU 2016 的钻石赞助商。下个月 3 月 10 - 11 号来伦敦,参观 13 号展位,了解 Kubernetes,Google Container Engine(GKE),Google Cloud Platform 的所有信息! + + + +_KubeCon 是由 KubeAcademy、LLC 组织的,这是一个由社区驱动的开发者团体,专注于开发人员的教育和 kubernet.com 的推广 +-* Sarah Novotny, 谷歌的 Kubernetes 社区经理 + diff --git a/content/zh/blog/_posts/2016-04-Kubernetes-Network-Policy-APIs.md b/content/zh/blog/_posts/2016-04-Kubernetes-Network-Policy-APIs.md index 072ec679f3..e9b6e2f084 100644 --- a/content/zh/blog/_posts/2016-04-Kubernetes-Network-Policy-APIs.md +++ b/content/zh/blog/_posts/2016-04-Kubernetes-Network-Policy-APIs.md @@ -1,3 +1,10 @@ +--- +title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 " +date: 2016-04-18 +slug: kubernetes-network-policy-apis +url: /blog/2016/04/Kubernetes-Network-Policy-APIs +--- + ---- -title: "SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 " -date: 2016-04-18 -slug: kubernetes-network-policy-apis -url: /blog/2016/04/Kubernetes-Network-Policy-APIs ---- - 编者按:这一周,我们的封面主题是 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs));今天的文章由网络兴趣小组撰写,来谈谈 1.3 版本中即将出现的网络策略 API - 针对安全,隔离和多租户的策略。 diff --git a/content/zh/blog/_posts/2016-04-Kubernetes-On-Aws_15.md b/content/zh/blog/_posts/2016-04-Kubernetes-On-Aws_15.md index c5de9e6a12..a12060b915 100644 --- a/content/zh/blog/_posts/2016-04-Kubernetes-On-Aws_15.md +++ b/content/zh/blog/_posts/2016-04-Kubernetes-On-Aws_15.md @@ -1,10 +1,3 @@ - - --- title: " 如何在AWS上部署安全,可审计,可复现的k8s集群 " date: 2016-04-15 @@ -12,6 +5,13 @@ slug: kubernetes-on-aws_15 url: /blog/2016/04/Kubernetes-On-Aws_15 --- + + diff --git a/content/zh/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md b/content/zh/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md new file mode 100644 index 0000000000..6915b8482a --- /dev/null +++ b/content/zh/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md @@ -0,0 +1,72 @@ +--- +title: " Citrix + Kubernetes = 全垒打 " +date: 2016-07-14 +slug: citrix-netscaler-and-kubernetes +url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes +--- + + + + +编者按:今天的客座文章来自 Citrix Systems 的产品管理总监 Mikko Disini,他分享了他们在 Kubernetes 集成上的合作经验。 _ + + +技术合作就像体育运动。如果你能像一个团队一样合作,你就能在最后关头取得胜利。这就是我们对谷歌云平台团队的经验。 + + +最近,我们与 Google 云平台(GCP)联系,代表 Citrix 客户以及更广泛的企业市场,希望就工作负载的迁移进行协作。此迁移需要将 [NetScaler Docker 负载均衡器]https://www.citrix.com/blogs/2016/06/20/the-best-docker-load-balancer-at-dockercon-in-seattle-this-week/) CPX 包含到 Kubernetes 节点中,并解决将流量引入 CPX 代理的任何问题。 + + + +**为什么是 NetScaler 和 Kubernetes** + + + +1. Citrix 的客户希望他们开始使用 Kubernetes 部署他们的容器和微服务体系结构时,能够像当初迁移到云计算时一样,享有 NetScaler 所提供的第 4 层到第 7 层能力  +2. Kubernetes 提供了一套经过验证的基础设施,可用来运行容器和虚拟机,并自动交付工作负载; +3. NetScaler CPX 提供第 4 层到第 7 层的服务,并为日志和分析平台 [NetScaler 管理和分析系统](https://www.citrix.com/blogs/2016/05/24/introducing-the-next-generation-netscaler-management-and-analytics-system/) 提供高效的度量数据。 + + +我希望我们所有与技术合作伙伴一起工作的经验都能像与 GCP 一起工作一样好。我们有一个列表,包含支持我们的用例所需要解决的问题。我们能够快速协作形成解决方案。为了解决这些问题,GCP 团队提供了深入的技术支持,与 Citrix 合作,从而使得 NetScaler CPX 能够在每台主机上作为客户端代理启动运行。 + + +接下来,需要在 GCP 入口负载均衡器的数据路径中插入 NetScaler CPX,使 NetScaler CPX 能够将流量分散到前端 web 服务器。NetScaler 团队进行了修改,以便 NetScaler CPX 监听 API 服务器事件,并配置自己来创建 VIP、IP 表规则和服务器规则,以便跨前端应用程序接收流量和负载均衡。谷歌云平台团队提供反馈和帮助,验证为克服技术障碍所做的修改。完成了! + + +NetScaler CPX 用例在 [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernets-1.3 - bridge -cloud-native-and-enterprise-workload) 中提供支持。Citrix 的客户和更广泛的企业市场将有机会基于 Kubernetes 享用 NetScaler 服务,从而降低将工作负载转移到云平台的阻力。  + + +您可以在[此处](https://www.citrix.com/networking/microservices.html)了解有关 NetScaler CPX 的更多信息。 + + +_ -- Mikko Disini,Citrix Systems NetScaler 产品管理总监 + diff --git a/content/zh/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md b/content/zh/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md new file mode 100644 index 0000000000..8fb8d01ef9 --- /dev/null +++ b/content/zh/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md @@ -0,0 +1,72 @@ +--- +title: " Kubernetes 1.8 的五天 " +date: 2017-10-24 +slug: five-days-of-kubernetes-18 +url: /blog/2017/10/Five-Days-Of-Kubernetes-18 +--- + + + + +Kubernetes 1.8 是现场直播,数百名贡献者在这个最新版本中推出了成千上万的提交。 + + +社区已经有超过 66,000 个提交在主仓库,并在主仓库之外继续快速增长,这标志着该项目日益成熟和稳定。仅 v1.7.0 到 v1.8.0,社区就记录了所有仓库的超过 120,000 次提交和 17839 次提交。 + + +在拥有 1400 多名贡献者,并且不断发展壮大的社区的帮助下,我们合并了 3000 多个 PR,并发布了 5000 多个提交,最后的 Kubernetes 1.8 在安全和工作负载方面添加了很多的更新。 +这一切都表明稳定性的提高,这是我们整个项目关注成熟[流程](https://github.com/kubernetes/sig-release)、形式化[架构](https://github.com/kubernetes/community/tree/master/sig-architecture)和加强 Kubernetes 的[治理模型](https://github.com/kubernetes/community/tree/master/community/elections/2017)的结果。 + + +虽然有很多改进,但我们在下面列出的这一系列深度文章中突出了一些关键特性。[跟随](https://twitter.com/kubernetesio)并了解存储,安全等方面的新功能和改进功能。 + + + +**第一天:** [Kubernetes 1.8 的五天](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18) +**第二天:** [kubeadm v1.8 为 Kubernetes 集群引入了简单的升级](https://kubernetes.io/blog/2017/10/kubeadm-v18-released) +**第三天:** [Kubernetes v1.8 回顾:提升一个 Kubernetes 需要一个 Village](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes) +**第四天:** [使用 RBAC,一般在 Kubernetes v1.8 中提供](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18) +**第五天:** [在 Kubernetes 执行网络策略](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes) + + + +**链接** + + + +- 在 [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) 上发布问题(或回答问题) +- 加入 [K8sPort](http://k8sport.org/) 布道师的社区门户网站 +- 在 Twitter [@Kubernetesio](https://twitter.com/kubernetesio) 关注我们以获取最新更新 +- 与 [Slack](http://slack.k8s.io/) 上的社区联系 +- 参与 [GitHub](https://github.com/kubernetes/kubernetes) 上的 Kubernetes 项目 + + diff --git a/content/zh/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md b/content/zh/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md new file mode 100644 index 0000000000..87c9ccd74b --- /dev/null +++ b/content/zh/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md @@ -0,0 +1,32 @@ +--- +title: " Kubernetes 中自动缩放 " +date: 2017-11-17 +slug: autoscaling-in-kubernetes +url: /blog/2017/11/Autoscaling-In-Kubernetes +--- + + + + +Kubernetes 允许开发人员根据当前的流量和负载自动调整集群大小和 pod 副本的数量。这些调整减少了未使用节点的数量,节省了资金和资源。 +在这次演讲中,谷歌的 Marcin Wielgus 将带领您了解 Kubernetes 中 pod 和 node 自动调焦的当前状态:它是如何工作的,以及如何使用它,包括在生产应用程序中部署的最佳实践。 + + +喜欢这个演讲吗? 12 月 6 日至 8 日,在 Austin 参加 KubeCon 关于扩展和自动化您的 Kubernetes 集群的更令人兴奋的会议。[现在注册](https://www.eventbrite.com/e/kubecon-cloudnativecon-north-america-registration-37824050754?_ga=2.9666039.317115486.1510003873-1623727562.1496428006)。 + + +一定要查看由 Ron Lipke, Gannet/USA Today Network, 平台即服务高级开发人员,在[公共云中自动化和测试产品就绪的 Kubernetes 集群](http://sched.co/CU64)。 + diff --git a/content/zh/blog/_posts/2018-05-01-developing-on-kubernetes.md b/content/zh/blog/_posts/2018-05-01-developing-on-kubernetes.md new file mode 100644 index 0000000000..5d31031ec7 --- /dev/null +++ b/content/zh/blog/_posts/2018-05-01-developing-on-kubernetes.md @@ -0,0 +1,728 @@ +--- +title: 在 Kubernetes 上开发 +date: 2018-05-01 +slug: developing-on-kubernetes +--- + + + + +**作者**: [Michael Hausenblas](https://twitter.com/mhausenblas) (Red Hat), [Ilya Dmitrichenko](https://twitter.com/errordeveloper) (Weaveworks) + + + +您将如何开发一个 Kubernates 应用?也就是说,您如何编写并测试一个要在 Kubernates 上运行的应用程序?本文将重点介绍在独自开发或者团队协作中,您可能希望了解到的为了成功编写 Kubernetes 应用程序而需面临的挑战,工具和方法。 + + + +我们假定您是一位开发人员,有您钟爱的编程语言,编辑器/IDE(集成开发环境),以及可用的测试框架。在针对 Kubernates 开发应用时,最重要的目标是减少对当前工作流程的影响,改变越少越好,尽量做到最小。举个例子,如果您是 Node.js 开发人员,习惯于那种热重载的环境 - 也就是说您在编辑器里一做保存,正在运行的程序就会自动更新 - 那么跟容器、容器镜像或者镜像仓库打交道,又或是跟 Kubernetes 部署、triggers 以及更多头疼东西打交道,不仅会让人难以招架也真的会让开发过程完全失去乐趣。 + + + +在下文中,我们将首先讨论 Kubernetes 总体开发环境,然后回顾常用工具,最后进行三个示例性工具的实践演练。这些工具允许针对 Kubernetes 进行本地应用程序的开发和迭代。 + + + +## 您的集群运行在哪里? + + + +作为开发人员,您既需要考虑所针对开发的 Kubernetes 集群运行在哪里,也需要思考开发环境如何配置。概念上,有四种开发模式: + +![Dev Modes](/images/blog/2018-05-01-developing-on-kubernetes/dok-devmodes_preview.png) + + + +许多工具支持纯 offline 开发,包括 Minikube、Docker(Mac 版/Windows 版)、Minishift 以及下文中我们将详细讨论的几种。有时,比如说在一个微服务系统中,已经有若干微服务在运行,proxied 模式(通过转发把数据流传进传出集群)就非常合适,Telepresence 就是此类工具的一个实例。live 模式,本质上是您基于一个远程集群进行构建和部署。最后,纯 online 模式意味着您的开发环境和运行集群都是远程的,典型的例子是 [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) 或者 [Cloud 9](https://github.com/errordeveloper/k9c)。现在让我们仔细看看离线开发的基础:在本地运行 Kubernetes。 + + + +[Minikube](/docs/getting-started-guides/minikube/) 在更加喜欢于本地 VM 上运行 Kubernetes 的开发人员中,非常受欢迎。不久前,Docker 的 [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) 版和 [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) 版,都试验性地开始自带 Kubernetes(需要下载 “edge” 安装包)。在两者之间,以下原因也许会促使您选择 Minikube 而不是 Docker 桌面版: + + + +* 您已经安装了 Minikube 并且它运行良好 +* 您想等到 Docker 出稳定版本 +* 您是 Linux 桌面用户 +* 您是 Windows 用户,但是没有配有 Hyper-V 的 Windows 10 Pro + + + +运行一个本地集群,开发人员可以离线工作,不用支付云服务。云服务收费一般不会太高,并且免费的等级也有,但是一些开发人员不喜欢为了使用云服务而必须得到经理的批准,也不愿意支付意想不到的费用,比如说忘了下线而集群在周末也在运转。 + + + +有些开发人员却更喜欢远程的 Kubernetes 集群,这样他们通常可以获得更大的计算能力和存储容量,也简化了协同工作流程。您可以更容易的拉上一个同事来帮您调试,或者在团队内共享一个应用的使用。再者,对某些开发人员来说,尽可能的让开发环境类似生产环境至关重要,尤其是您依赖外部厂商的云服务时,如:专有数据库、云对象存储、消息队列、外商的负载均衡器或者邮件投递系统。 + + + +总之,无论您选择本地或者远程集群,理由都足够多。这很大程度上取决于您所处的阶段:从早期的原型设计/单人开发到后期面对一批稳定微服务的集成。 + + + +既然您已经了解到运行环境的基本选项,那么我们就接着讨论如何迭代式的开发并部署您的应用。 + + + +## 常用工具 + + + +我们现在回顾既可以允许您可以在 Kubernetes 上开发应用程序又尽可能最小地改变您现有的工作流程的一些工具。我们致力于提供一份不偏不倚的描述,也会提及使用某个工具将会意味着什么。 + + + +请注意这很棘手,因为即使在成熟定型的技术中做选择,比如说在 JSON、YAML、XML、REST、gRPC 或者 SOAP 之间做选择,很大程度也取决于您的背景、喜好以及公司环境。在 Kubernetes 生态系统内比较各种工具就更加困难,因为技术发展太快,几乎每周都有新工具面市;举个例子,仅在准备这篇博客的期间,[Gitkube](https://gitkube.sh/) 和 [Watchpod](https://github.com/MinikubeAddon/watchpod) 相继出品。为了进一步覆盖到这些新的,以及一些相关的已推出的工具,例如 [Weave Flux](https://github.com/weaveworks/flux) 和 OpenShift 的 [S2I](https://docs.openshift.com/container-platform/3.9/creating_images/s2i.html),我们计划再写一篇跟进的博客。 + +### Draft + + + + +[Draft](https://github.com/Azure/draft) 旨在帮助您将任何应用程序部署到 Kubernetes。它能够检测到您的应用所使用的编程语言,并且生成一份 Dockerfile 和 Helm 图表。然后它替您启动构建并且依照 Helm 图表把所生产的镜像部署到目标集群。它也可以让您很容易地设置到 localhost 的端口映射。 + + + +这意味着: + + +* 用户可以任意地自定义 Helm 图表和 Dockerfile 模版,或者甚至创建一个 [custom pack](https://github.com/Azure/draft/blob/master/docs/reference/dep-003.md)(使用 Dockerfile、Helm 图表以及其他)以备后用 + + +* 要想理解一个应用应该怎么构建并不容易,在某些情况下,用户也许需要修改 Draft 生成的 Dockerfile 和 Heml 图表 + + +* 如果使用 [Draft version 0.12.0](https://github.com/Azure/draft/releases/tag/v0.12.0)1 或者更老版本,每一次用户想要测试一个改动,他们需要等 Draft 把代码拷贝到集群,运行构建,推送镜像并且发布更新后的图表;这些步骤可能进行得很快,但是每一次用户的改动都会产生一个镜像(无论是否提交到 git ) + + +* 在 Draft 0.12.0版本,构建是本地进行的 +* 用户不能选择 Helm 以外的工具进行部署 +* 它可以监控本地的改动并且触发部署,但是这个功能默认是关闭的 + + +* 它允许开发人员使用本地或者远程的 Kubernates 集群 +* 如何部署到生产环境取决于用户, Draft 的作者推荐了他们的另一个项目 - Brigade +* 可以代替 Skaffold, 并且可以和 Squash 一起使用 + + + +更多信息: + +* [Draft: Kubernetes container development made easy](https://kubernetes.io/blog/2017/05/draft-kubernetes-container-development) +* [Getting Started Guide](https://github.com/Azure/draft/blob/master/docs/getting-started.md) + +【1】:此处疑为 0.11.0,因为 0.12.0 已经支持本地构建,见下一条 + +### Skaffold + + + +[Skaffold](https://github.com/GoogleCloudPlatform/skaffold) 让 CI 集成具有可移植性的,它允许用户采用不同的构建系统,镜像仓库和部署工具。它不同于 Draft,同时也具有一定的可比性。它具有生成系统清单的基本能力,但那不是一个重要功能。Skaffold 易于扩展,允许用户在构建和部署应用的每一步选取相应的工具。 + + + +这意味着: + + +* 模块化设计 +* 不依赖于 CI,用户不需要 Docker 或者 Kubernetes 插件 +* 没有 CI 也可以工作,也就是说,可以在开发人员的电脑上工作 +* 它可以监控本地的改动并且触发部署 + + +* 它允许开发人员使用本地或者远程的 Kubernetes 集群 +* 它可以用于部署生产环境,用户可以精确配置,也可以为每一套目标环境提供不同的生产线 +* 可以代替 Draft,并且和其他工具一起使用 + + + +更多信息: + +* [Introducing Skaffold: Easy and repeatable Kubernetes development](https://cloudplatform.googleblog.com/2018/03/introducing-Skaffold-Easy-and-repeatable-Kubernetes-development.html) +* [Getting Started Guide](https://github.com/GoogleCloudPlatform/skaffold#getting-started-with-local-tooling) + +### Squash + + +[Squash](https://github.com/solo-io/squash) 包含一个与 Kubernetes 全面集成的调试服务器,以及一个 IDE 插件。它允许您插入断点和所有的调试操作,就像您所习惯的使用 IDE 调试一个程序一般。它允许您将调试器应用到 Kubernetes 集群中运行的 pod 上,从而让您可以使用 IDE 调试 Kubernetes 集群。 + + + +这意味着: + + +* 不依赖您选择的其它工具 +* 需要一组特权 DaemonSet +* 可以和流行 IDE 集成 +* 支持 Go、Python、Node.js、Java 和 gdb + + +* 用户必须确保容器中的应用程序使编译时使用了调试符号 +* 可与此处描述的任何其他工具结合使用 +* 它可以与本地或远程 Kubernetes 集群一起使用 + + + +更多信息: + +* [Squash: A Debugger for Kubernetes Apps](https://www.youtube.com/watch?v=5TrV3qzXlgI) +* [Getting Started Guide](https://github.com/solo-io/squash/blob/master/docs/getting-started.md) + +### Telepresence + + +[Telepresence](https://www.telepresence.io/) 使用双向代理将开发人员工作站上运行的容器与远程 Kubernetes 集群连接起来,并模拟集群内环境以及提供对配置映射和机密的访问。它消除了将应用部署到集群的需要,并利用本地容器抽象出网络和文件系统接口,以使其看起来应用好像就在集群中运行,从而改进容器应用程序开发的迭代时间。 + + + +这意味着: + + +* 它不依赖于其它您选取的工具 +* 可以同 Squash 一起使用,但是 Squash 必须用于调试集群中的 pods,而传统/本地调试器需要用于调试通过 Telepresence 连接到集群的本地容器 +* Telepresence 会产生一些网络延迟 + + +* 它通过辅助进程提供连接 - sshuttle,基于SSH的一个工具 +* 还提供了使用 LD_PRELOAD/DYLD_INSERT_LIBRARIES 的更具侵入性的依赖注入模式 +* 它最常用于远程 Kubernetes 集群,但也可以与本地集群一起使用 + + + +更多信息: + +* [Telepresence: fast, realistic local development for Kubernetes microservices](https://www.telepresence.io/) +* [Getting Started Guide](https://www.telepresence.io/tutorials/docker) +* [How It Works](https://www.telepresence.io/discussion/how-it-works) + +### Ksync + + + + +[Ksync](https://github.com/vapor-ware/ksync) 在本地计算机和运行在 Kubernetes 中的容器之间同步应用程序代码(和配置),类似于 [oc rsync](https://docs.openshift.com/container-platform/3.9/dev_guide/copy_files_to_container.html) 在 OpenShift 中的角色。它旨在通过消除构建和部署步骤来缩短应用程序开发的迭代时间。 + + + + +这意味着: + + +* 它绕过容器图像构建和修订控制 +* 使用编译语言的用户必须在 pod(TBC)内运行构建 +* 双向同步 - 远程文件会复制到本地目录 +* 每次更新远程文件系统时都会重启容器 +* 无安全功能 - 仅限开发 + + +* 使用 [Syncthing](https://github.com/syncthing/syncthing),一个用于点对点同步的 Go 语言库 +* 需要一个在集群中运行的特权 DaemonSet +* Node 必须使用带有 overlayfs2 的 Docker - 在写作本文时,尚不支持其他 CRI 实现 + + + +更多信息: + +* [Getting Started Guide](https://github.com/vapor-ware/ksync#getting-started) +* [How It Works](https://github.com/vapor-ware/ksync/blob/master/docs/architecture.md) +* [Katacoda scenario to try out ksync in your browser](https://www.katacoda.com/vaporio/scenarios/ksync) +* [Syncthing Specification](https://docs.syncthing.net/specs/) + + + +## 实践演练 + + + + +我们接下来用于练习使用工具的应用是一个简单的[股市模拟器](https://github.com/kubernauts/dok-example-us),包含两个微服务: + + + +* `stock-gen`(股市数据生成器)微服务是用 Go 编写的,随机生成股票数据并通过 HTTP 端点 `/ stockdata` 公开 +* 第二个微服务,`stock-con`(股市数据消费者)是一个 Node.js 应用程序,它使用来自 `stock-gen` 的股票数据流,并通过 HTTP 端点 `/average/$SYMBOL` 提供股价移动平均线,也提供一个健康检查端点 `/healthz`。 + + + +总体上,此应用的默认配置如下图所示: + +![Default Setup](/images/blog/2018-05-01-developing-on-kubernetes/dok-architecture_preview.png) + + + +在下文中,我们将选取以上讨论的代表性工具进行实践演练:ksync,具有本地构建的 Minikube 以及 Skaffold。对于每个工具,我们执行以下操作: + + + +* 设置相应的工具,包括部署准备和 `stock-con` 微服务数据的本地读取 +* 执行代码更新,即更改 `stock-con` 微服务的 `/healthz` 端点的源代码并观察网页刷新 + + + +请注意,我们一直使用 Minikube 的本地 Kubernetes 集群,但是您也可以使用 ksync 和 Skaffold 的远程集群跟随练习。 + + + +### 实践演练:ksync + + + +作为准备,安装 [ksync](https://vapor-ware.github.io/ksync/#installation),然后执行以下步骤配置开发环境: + +``` +$ mkdir -p $(pwd)/ksync +$ kubectl create namespace dok +$ ksync init -n dok +``` + + + +完成基本设置后,我们可以告诉 ksync 的本地客户端监控 Kubernetes 的某个命名空间,然后我们创建一个规范来定义我们想要同步的文件夹(本地的 `$(pwd)/ksync` 和容器中的 `/ app` )。请注意,目标 pod 是用 selector 参数指定: + +``` +$ ksync watch -n dok +$ ksync create -n dok --selector=app=stock-con $(pwd)/ksync /app +$ ksync get -n dok +``` + + + +现在我们部署股价数据生成器和股价数据消费者微服务: + +``` +$ kubectl -n=dok apply \ + -f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-gen/app.yaml +$ kubectl -n=dok apply \ + -f https://raw.githubusercontent.com/kubernauts/dok-example-us/master/stock-con/app.yaml +``` + + + +一旦两个部署建好并且 pod 开始运行,我们转发 `stock-con` 服务以供本地读取(另开一个终端窗口): + +``` +$ kubectl get -n dok po --selector=app=stock-con \ + -o=custom-columns=:metadata.name --no-headers | \ + xargs -IPOD kubectl -n dok port-forward POD 9898:9898 +``` + + + +这样,通过定期查询 `healthz` 端点,我们就应该能够从本地机器上读取 `stock-con` 服务,查询命令如下(在一个单独的终端窗口): + +``` +$ watch curl localhost:9898/healthz +``` + + + +现在,改动 `ksync/stock-con` 目录中的代码,例如改动 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52),在其 JSON 形式的响应中新添一个字段并观察 pod 如何更新以及 `curl localhost:9898/healthz` 命令的输出发生何种变化。总的来说,您最后应该看到类似的内容: + + +![Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-ksync_preview.png) + + + + +### 实践演练:带本地构建的 Minikube + + + + +对于以下内容,您需要启动并运行 Minikube,我们将利用 Minikube 自带的 Docker daemon 在本地构建镜像。作为准备,请执行以下操作 + +``` +$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us +$ eval $(minikube docker-env) +$ kubectl create namespace dok +``` + + + +现在我们部署股价数据生成器和股价数据消费者微服务: + + +``` +$ kubectl -n=dok apply -f stock-gen/app.yaml +$ kubectl -n=dok apply -f stock-con/app.yaml +``` + + + +一旦两个部署建好并且 pod 开始运行,我们转发 `stock-con` 服务以供本地读取(另开一个终端窗口): + +``` +$ kubectl get -n dok po --selector=app=stock-con \ + -o=custom-columns=:metadata.name --no-headers | \ + xargs -IPOD kubectl -n dok port-forward POD 9898:9898 & +$ watch curl localhost:9898/healthz +``` + + +现在,改一下 `ksync/stock-con` 目录中的代码,例如修改 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52),在其 JSON 形式的响应中添加一个字段。在您更新完代码后,最后一步是构建新的容器镜像并启动新部署,如下所示: + + +``` +$ docker build -t stock-con:dev -f Dockerfile . +$ kubectl -n dok set image deployment/stock-con *=stock-con:dev +``` + + +总的来说,您最后应该看到类似的内容: + +![Local Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-minikube-localdev_preview.png) + + + +### 实践演练:Skaffold + + + +要进行此演练,首先需要安装 [Skaffold](https://github.com/GoogleContainerTools/skaffold#installation)。完成后,您可以执行以下步骤来配置开发环境: + +``` +$ git clone https://github.com/kubernauts/dok-example-us.git && cd dok-example-us +$ kubectl create namespace dok +``` + + +现在我们部署股价数据生成器(但是暂不部署股价数据消费者,此服务将使用 Skaffold 完成): + +``` +$ kubectl -n=dok apply -f stock-gen/app.yaml +``` + + + + +请注意,最初我们在执行 `skaffold dev` 时发生身份验证错误,为避免此错误需要安装[问题322](https://github.com/GoogleContainerTools/skaffold/issues/322) 中所述的修复。本质上,需要将 `〜/.docker/config.json` 的内容改为: + + +``` +{ + "auths": {} +} +``` + + + +接下来,我们需要略微改动 `stock-con/app.yaml`,这样 Skaffold 才能正常使用此文件: + + + +在 `stock-con` 部署和服务中添加一个 `namespace` 字段,其值为 `dok` + +将容器规范的 `image` 字段更改为 `quay.io/mhausenblas/stock-con`,因为 Skaffold 可以即时管理容器镜像标签。 + + +最终的 stock-con 的 `app.yaml` 文件看起来如下: + + +``` +apiVersion: apps/v1beta1 +kind: Deployment +metadata: + labels: + app: stock-con + name: stock-con + namespace: dok +spec: + replicas: 1 + template: + metadata: + labels: + app: stock-con + spec: + containers: + - name: stock-con + image: quay.io/mhausenblas/stock-con + env: + - name: DOK_STOCKGEN_HOSTNAME + value: stock-gen + - name: DOK_STOCKGEN_PORT + value: "9999" + ports: + - containerPort: 9898 + protocol: TCP + livenessProbe: + initialDelaySeconds: 2 + periodSeconds: 5 + httpGet: + path: /healthz + port: 9898 + readinessProbe: + initialDelaySeconds: 2 + periodSeconds: 5 + httpGet: + path: /healthz + port: 9898 +--- +apiVersion: v1 +kind: Service +metadata: + labels: + app: stock-con + name: stock-con + namespace: dok +spec: + type: ClusterIP + ports: + - name: http + port: 80 + protocol: TCP + targetPort: 9898 + selector: + app: stock-con +``` + + +我们能够开始开发之前的最后一步是配置 Skaffold。因此,在 `stock-con/` 目录中创建文件 `skaffold.yaml`,其中包含以下内容: + +``` +apiVersion: skaffold/v1alpha2 +kind: Config +build: + artifacts: + - imageName: quay.io/mhausenblas/stock-con + workspace: . + docker: {} + local: {} +deploy: + kubectl: + manifests: + - app.yaml +``` + + +现在我们准备好开始开发了。为此,在 `stock-con/` 目录中执行以下命令: + +``` +$ skaffold dev +``` + + + +上面的命令将触发 `stock-con` 图像的构建和部署。一旦 `stock-con` 部署的 pod 开始运行,我们再次转发 `stock-con` 服务以供本地读取(在单独的终端窗口中)并检查 `healthz` 端点的响应: + +```bash +$ kubectl get -n dok po --selector=app=stock-con \ + -o=custom-columns=:metadata.name --no-headers | \ + xargs -IPOD kubectl -n dok port-forward POD 9898:9898 & +$ watch curl localhost:9898/healthz +``` + + +现在,如果您修改一下 `stock-con` 目录中的代码,例如 [`service.js` 中定义的 `/healthz` 端点代码](https://github.com/kubernauts/dok-example-us/blob/2334ee8fb11f8813370122bd46285cf45bdd4c48/stock-con/service.js#L52),在其 JSON 形式的响应中添加一个字段,您应该看到 Skaffold 可以检测到代码改动并创建新图像以及部署它。您的屏幕看起来应该类似这样: + + +![Skaffold Preview](/images/blog/2018-05-01-developing-on-kubernetes/dok-skaffold_preview.png) + + +至此,您应该对不同的工具如何帮您在 Kubernetes 上开发应用程序有了一定的概念,如果您有兴趣了解有关工具和/或方法的更多信息,请查看以下资源: + +* Blog post by Shahidh K Muhammed on [Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold](https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs-ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948) (03/2018) +* Blog post by Gergely Nemeth on [Using Kubernetes for Local Development](https://nemethgergely.com/using-kubernetes-for-local-development/index.html), with a focus on Skaffold (03/2018) +* Blog post by Richard Li on [Locally developing Kubernetes services (without waiting for a deploy)](https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99), with a focus on Telepresence +* Blog post by Abhishek Tiwari on [Local Development Environment for Kubernetes using Minikube](https://abhishek-tiwari.com/local-development-environment-for-kubernetes-using-minikube/) (09/2017) +* Blog post by Aymen El Amri on [Using Kubernetes for Local Development — Minikube](https://medium.com/devopslinks/using-kubernetes-minikube-for-local-development-c37c6e56e3db) (08/2017) +* Blog post by Alexis Richardson on [​GitOps - Operations by Pull Request](https://www.weave.works/blog/gitops-operations-by-pull-request) (08/2017) +* Slide deck [GitOps: Drive operations through git](https://docs.google.com/presentation/d/1d3PigRVt_m5rO89Ob2XZ16bW8lRSkHHH5k816-oMzZo/), with a focus on Gitkube by Tirumarai Selvan (03/2018) +* Slide deck [Developing apps on Kubernetes](https://speakerdeck.com/mhausenblas/developing-apps-on-kubernetes), a talk Michael Hausenblas gave at a CNCF Paris meetup (04/2018) +* YouTube videos: + * [TGI Kubernetes 029: Developing Apps with Ksync](https://www.youtube.com/watch?v=QW85Y0Ug3KY ) + * [TGI Kubernetes 030: Exploring Skaffold](https://www.youtube.com/watch?v=McwwWhCXMxc) + * [TGI Kubernetes 031: Connecting with Telepresence](https://www.youtube.com/watch?v=zezeBAJ_3w8) + * [TGI Kubernetes 033: Developing with Draft](https://www.youtube.com/watch?v=8B1D7cTMPgA) +* Raw responses to the [Kubernetes Application Survey](https://docs.google.com/spreadsheets/d/12ilRCly2eHKPuicv1P_BD6z__PXAqpiaR-tDYe2eudE/edit) 2018 by SIG Apps + + + +有了这些,我们这篇关于如何在 Kubernetes 上开发应用程序的博客就可以收尾了,希望您有所收获,如果您有反馈和/或想要指出您认为有用的工具,请通过 Twitter 告诉我们:[Ilya](https://twitter.com/errordeveloper) 和 [Michael](https://twitter.com/mhausenblas) diff --git a/content/zh/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md b/content/zh/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md new file mode 100644 index 0000000000..eb1aba85d2 --- /dev/null +++ b/content/zh/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md @@ -0,0 +1,67 @@ +--- +title: 'Kubernetes 1 11:向 discuss kubernetes 问好' +layout: blog +date: 2018-05-30 +--- + + + + + +作者: Jorge Castro (Heptio) + + + +就一个超过 35,000 人的全球性社区而言,参与其中时沟通是非常关键的。 跟踪 Kubernetes 社区中的所有内容可能是一项艰巨的任务。 一方面,我们有官方资源,如 Stack Overflow,GitHub 和邮件列表,另一方面,我们有更多瞬时性的资源,如 Slack,你可以加入进去、与某人聊天然后各走各路。 + + + + +Slack 非常适合随意和及时的对话,并与其他社区成员保持联系,但未来很难轻易引用通信。此外,在35,000名参与者中提问并得到回答很难。邮件列表在有问题尝试联系特定人群并且想要跟踪大家的回应时非常有用,但是对于大量人员来说可能是麻烦的。 Stack Overflow 和 GitHub 非常适合在涉及代码的项目或问题上进行协作,并且如果在将来要进行搜索也很有用,但某些主题如“你最喜欢的 CI/CD 工具是什么”或“[Kubectl提示和技巧](http://discuss.kubernetes.io/t/kubectl-tips-and-tricks/192)“在那里是没有意义的。 + +虽然我们目前的各种沟通渠道对他们自己来说都很有价值,但我们发现电子邮件和实时聊天之间仍然存在差距。在网络的其他部分,许多其他开源项目,如 Docker、Mozilla、Swift、Ghost 和 Chef,已经成功地在[Discourse](http://www.discourse.org/features)之上构建社区,一个开放的讨论平台。那么,如果我们可以使用这个工具将我们的讨论结合在一个平台下,使用开放的API,或许也不会让我们的大部分信息消失在网络中呢?只有一种方法可以找到:欢迎来到[discuss.kubernetes.io](http://discuss.kubernetes.io) + + + +马上,我们有用户可以浏览的类别。检查和发布这些类别允许用户参与他们可能感兴趣的事情,而无需订阅列表。精细的通知控件允许用户只订阅他们想要的类别或标签,并允许通过电子邮件回复主题。 + +生态系统合作伙伴和开发人员现在有一个地方可以[宣布项目](http://discuss.kubernetes.io/c/announcements),他们正在为用户工作,而不会想知道它是否会在官方列表中脱离主题。我们可以让这个地方不仅仅是关于核心 Kubernetes,而是关于我们社区正在建设的数百个精彩工具。 + +这个新的社区论坛为人们提供了一个可以讨论 Kubernetes 的地方,也是开发人员在 Kubernetes 周围发布事件的声音板,同时可以搜索并且更容易被更广泛的用户访问。 + +进来看看。我们刚刚开始,所以,您可能希望从[自我介绍](http://discuss.kubernetes.io/t/introduce-yourself-here/56)开始,到处浏览。也有 [Android](http://play.google.com/store/apps/details?id=com.discourse&hl=en_US&rdid=com.discourse&pli=1) 和 [iOS](http://itunes.apple.com/us/app/discourse-app/id1173672076?mt=8) 应用下载。 + diff --git a/content/zh/blog/_posts/2018-06-06-4-years-of-k8s.md b/content/zh/blog/_posts/2018-06-06-4-years-of-k8s.md new file mode 100644 index 0000000000..b4e118b584 --- /dev/null +++ b/content/zh/blog/_posts/2018-06-06-4-years-of-k8s.md @@ -0,0 +1,42 @@ +--- +title: Kubernetes 这四年 +approvers: +cn-approvers: +- congfairy +layout: blog +date: 2018-06-06 +--- + + + **作者**:Joe Beda( Heptio 首席技术官兼创始人) + 2014 年 6 月 6 日,我检查了 Kubernetes 公共代码库的[第一次 commit](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) 。许多人会认为这是故事开始的地方。这难道不是一切开始的地方吗?但这的确不能把整个过程说清楚。 + + ![k8s_first_commit](/images/blog/2018-06-06-4-years-of-k8s/k8s-first-commit.png) + + + + 第一次 commit 涉及的人员众多,自那以后 Kubernetes 的成功归功于更大的开发者阵容。 + Kubernetes 建立在过去十年曾经在 Google 的 Borg 集群管理系统中验证过的思路之上。而 Borg 本身也是 Google 和其他公司早期努力的结果。 + 具体而言,Kubernetes 最初是从 Brendan Burns 的一些原型开始,结合我和 Craig McLuckie 正在进行的工作,以更好地将 Google 内部实践与 Google Cloud 的经验相结合。 Brendan,Craig 和我真的希望人们使用它,所以我们建议将这个原型构建为一个开源项目,将 Borg 的最佳创意带给大家。 +在我们所有人同意后,就开始着手构建这个系统了。我们采用了 Brendan 的原型(Java 语言),用 Go 语言重写了它,并且以上述核心思想去构建该系统。到这个时候,团队已经成长为包括 Ville Aikas,Tim Hockin,Brian Grant,Dawn Chen 和 Daniel Smith。一旦我们有了一些工作需求,有人必须承担一些脱敏的工作,以便为公开发布做好准备。这个角色最终由我承担。当时,我不知道这件事情的重要性,我创建了一个新的仓库,把代码搬过来,然后进行了检查。所以在我第一次提交 public commit 之前,就有工作已经启动了。 +那时 Kubernetes 的版本只是现在版本的简单雏形。核心概念已经有了,但非常原始。例如,Pods 被称为 Tasks,这在我们推广前一天就被替换。2014年6月10日 Eric Brewe 在第一届 DockerCon 上的演讲中正式发布了 Kubernetes 。您可以在此处观看该视频: + + +
+ + + + 但是,无论多么原始,这小小的一步足以激起一个开始强大而且变得更强大的社区的兴趣。在过去的四年里,Kubernetes 已经超出了我们所有人的期望。我们对 Kubernetes 社区的所有人员表示感谢。该项目所取得的成功不仅基于代码和技术,还基于一群出色的人聚集在一起所做的有意义的事情。Sarah Novotny 策划的一套 [Kubernetes 价值观](https://github.com/kubernetes/steering/blob/master/values.md)是以上最好的表现形式。 + 让我们一起期待下一个4年!🎉🎉🎉 diff --git a/content/zh/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md b/content/zh/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md new file mode 100644 index 0000000000..bb8d7d848c --- /dev/null +++ b/content/zh/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md @@ -0,0 +1,129 @@ +--- +title: 'Kubernetes 内的动态 Ingress' +layout: blog +--- + + + +作者: Richard Li (Datawire) + + + +Kubernetes 可以轻松部署由许多微服务组成的应用程序,但这种架构的关键挑战之一是动态地将流量路由到这些服务中的每一个。 +一种方法是使用 [Ambassador](https://www.getambassador.io), +一个基于 [Envoy Proxy](https://www.envoyproxy.io) 构建的 Kubernetes 原生开源 API 网关。 +Ambassador 专为动态环境而设计,这类环境中的服务可能被频繁添加或删除。 + +Ambassador 使用 Kubernetes 注解进行配置。 +注解用于配置从给定 Kubernetes 服务到特定 URL 的具体映射关系。 +每个映射中可以包括多个注解,用于配置路由。 +注解的例子有速率限制、协议、跨源请求共享(CORS)、流量影射和路由规则等。 + + + +## 一个简单的 Ambassador 示例 + +Ambassador 通常作为 Kubernetes Deployment 来安装,也可以作为 Helm Chart 使用。 +配置 Ambassador 时,请使用 Ambassador 注解创建 Kubernetes 服务。 +下面是一个例子,用来配置 Ambassador,将针对 /httpbin/ 的请求路由到公共的 httpbin.org 服务: + +``` +apiVersion: v1 +kind: Service +metadata: + name: httpbin + annotations: + getambassador.io/config: | + --- + apiVersion: ambassador/v0 + kind: Mapping + name: httpbin_mapping + prefix: /httpbin/ + service: httpbin.org:80 + host_rewrite: httpbin.org +spec: + type: ClusterIP + ports: + - port: 80 +``` + + + +例子中创建了一个 Mapping 对象,其 prefix 设置为 /httpbin/,service 名称为 httpbin.org。 +其中的 host_rewrite 注解指定 HTTP 的 host 头部字段应设置为 httpbin.org。 + + + +## Kubeflow + +[Kubeflow](https://github.com/kubeflow/kubeflow) 提供了一种简单的方法,用于在 Kubernetes 上轻松部署机器学习基础设施。 +Kubeflow 团队需要一个代理,为 Kubeflow 中所使用的各种服务提供集中化的认证和路由能力;Kubeflow 中许多服务本质上都是生命期很短的。 + +
Kubeflow architecture, pre-Ambassador
+ + + +## 服务配置 + +有了 Ambassador,Kubeflow 可以使用分布式模型进行配置。 +Ambassador 不使用集中的配置文件,而是允许每个服务通过 Kubernetes 注解在 Ambassador 中配置其路由。 +下面是一个简化的配置示例: + +``` +--- +apiVersion: ambassador/v0 +kind: Mapping +name: tfserving-mapping-test-post +prefix: /models/test/ +rewrite: /model/test/:predict +method: POST +service: test.kubeflow:8000 +``` + + + +示例中,“test” 服务使用 Ambassador 注解来为服务动态配置路由。 +所配置的路由仅在 HTTP 方法是 POST 时触发;注解中同时还给出了一条重写规则。 + + + +## Kubeflow 和 Ambassador + +通过 Ambassador,Kubeflow 可以使用 Kubernetes 注解轻松管理路由。 +Kubeflow 配置同一个 Ingress 对象,将流量定向到 Ambassador,然后根据需要创建具有 Ambassador 注解的服务,以将流量定向到特定后端。 +例如,在部署 TensorFlow 服务时,Kubeflow 会创建 Kubernetes 服务并为其添加注解, +以便用户能够在 `https:///models/<模型名称>/` 处访问到模型本身。 +Kubeflow 还可以使用 Envoy Proxy 来进行实际的 L7 路由。 +通过 Ambassador,Kubeflow 能够更充分地利用 URL 重写和基于方法的路由等额外的路由配置能力。 + +如果您对在 Kubeflow 中使用 Ambassador 感兴趣,标准的 Kubeflow 安装会自动安装和配置 Ambassador。 + +如果您有兴趣将 Ambassador 用作 API 网关或 Kubernetes 的 Ingress 解决方案, +请参阅 [Ambassador 入门指南](https://www.getambassador.io/user-guide/getting-started)。 + diff --git a/content/zh/blog/_posts/2018-10-03-kubedirector.md b/content/zh/blog/_posts/2018-10-03-kubedirector.md new file mode 100644 index 0000000000..e07f1bb35f --- /dev/null +++ b/content/zh/blog/_posts/2018-10-03-kubedirector.md @@ -0,0 +1,306 @@ +--- +layout: blog +title: 'KubeDirector:在 Kubernetes 上运行复杂状态应用程序的简单方法' +date: 2018-10-03 +--- + + + + + +**作者**:Thomas Phelan(BlueData) + + +KubeDirector 是一个开源项目,旨在简化在 Kubernetes 上运行复杂的有状态扩展应用程序集群。KubeDirector 使用自定义资源定义(CRD) +框架构建,并利用了本地 Kubernetes API 扩展和设计哲学。这支持与 Kubernetes 用户/资源 管理以及现有客户端和工具的透明集成。 + + +我们最近[介绍了 KubeDirector 项目](https://medium.com/@thomas_phelan/operation-stateful-introducing-bluek8s-and-kubernetes-director-aa204952f619/),作为我们称为 BlueK8s 的更广泛的 Kubernetes 开源项目的一部分。我很高兴地宣布 [KubeDirector](https://github.com/bluek8s/kubedirector/) 的 +pre-alpha 代码现在已经可用。在这篇博客文章中,我将展示它是如何工作的。 + + +KubeDirector 提供以下功能: + + + +* 无需修改代码即可在 Kubernetes 上运行非云原生有状态应用程序。换句话说,不需要分解这些现有的应用程序来适应微服务设计模式。 +* 本机支持保存特定于应用程序的配置和状态。 +* 与应用程序无关的部署模式,最大限度地减少将新的有状态应用程序装载到 Kubernetes 的时间。 + + +KubeDirector 使熟悉数据密集型分布式应用程序(如 Hadoop、Spark、Cassandra、TensorFlow、Caffe2 等)的数据科学家能够在 Kubernetes 上运行这些应用程序 -- 只需极少的学习曲线,无需编写 GO 代码。由 KubeDirector 控制的应用程序由一些基本元数据和相关的配置工件包定义。应用程序元数据称为 KubeDirectorApp 资源。 + + +要了解 KubeDirector 的组件,请使用类似于以下的命令在 [GitHub](https://github.com/bluek8s/kubedirector/) 上克隆存储库: + +``` +git clone http://@github.com/bluek8s/kubedirector. +``` + + +Spark 2.2.1 应用程序的 KubeDirectorApp 定义位于文件 `kubedirector/deploy/example_catalog/cr-app-spark221e2.json` 中。 + + ``` + ~> cat kubedirector/deploy/example_catalog/cr-app-spark221e2.json + { + "apiVersion": "kubedirector.bluedata.io/v1alpha1", + "kind": "KubeDirectorApp", + "metadata": { + "name" : "spark221e2" + }, + "spec" : { + "systemctlMounts": true, + "config": { + "node_services": [ + { + "service_ids": [ + "ssh", + "spark", + "spark_master", + "spark_worker" + ], +… +``` + + +应用程序集群的配置称为 KubeDirectorCluster 资源。示例 Spark 2.2.1 集群的 KubeDirectorCluster 定义位于文件 +`kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml` 中。 + +``` +~> cat kubedirector/deploy/example_clusters/cr-cluster-spark221.e1.yaml +apiVersion: "kubedirector.bluedata.io/v1alpha1" +kind: "KubeDirectorCluster" +metadata: + name: "spark221e2" +spec: + app: spark221e2 + roles: + - name: controller + replicas: 1 + resources: + requests: + memory: "4Gi" + cpu: "2" + limits: + memory: "4Gi" + cpu: "2" + - name: worker + replicas: 2 + resources: + requests: + memory: "4Gi" + cpu: "2" + limits: + memory: "4Gi" + cpu: "2" + - name: jupyter +… +``` + + + +## 使用 KubeDirector 在 Kubernetes 上运行 Spark + + +使用 KubeDirector,可以轻松在 Kubernetes 上运行 Spark 集群。 + + +首先,使用命令 `kubectl version` 验证 Kubernetes(版本 1.9 或更高)是否正在运行 + +``` +~> kubectl version +Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} +Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} +``` + + +使用以下命令部署 KubeDirector 服务和示例 KubeDirectorApp 资源定义: + +``` +cd kubedirector +make deploy +``` + + +这些将启动 KubeDirector pod: + +``` +~> kubectl get pods +NAME READY STATUS RESTARTS AGE +kubedirector-58cf59869-qd9hb 1/1 Running 0 1m +``` + + +`kubectl get KubeDirectorApp` 列出中已安装的 KubeDirector 应用程序 + +``` +~> kubectl get KubeDirectorApp +NAME AGE +cassandra311 30m +spark211up 30m +spark221e2 30m +``` + + +现在,您可以使用示例 KubeDirectorCluster 文件和 `kubectl create -f deploy/example_clusters/cr-cluster-spark211up.yaml` 命令 +启动 Spark 2.2.1 集群。验证 Spark 集群已经启动: + +``` +~> kubectl get pods +NAME READY STATUS RESTARTS AGE +kubedirector-58cf59869-djdwl 1/1 Running 0 19m +spark221e2-controller-zbg4d-0 1/1 Running 0 23m +spark221e2-jupyter-2km7q-0 1/1 Running 0 23m +spark221e2-worker-4gzbz-0 1/1 Running 0 23m +spark221e2-worker-4gzbz-1 1/1 Running 0 23m +``` + + +现在运行的服务包括 Spark 服务: + +``` +~> kubectl get service +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +kubedirector ClusterIP 10.98.234.194 60000/TCP 1d +kubernetes ClusterIP 10.96.0.1 443/TCP 1d +svc-spark221e2-5tg48 ClusterIP None 8888/TCP 21s +svc-spark221e2-controller-tq8d6-0 NodePort 10.104.181.123 22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP 20s +svc-spark221e2-jupyter-6989v-0 NodePort 10.105.227.249 22:30632/TCP,8888:30355/TCP 20s +svc-spark221e2-worker-d9892-0 NodePort 10.107.131.165 22:30358/TCP,8081:32144/TCP 20s +svc-spark221e2-worker-d9892-1 NodePort 10.110.88.221 22:30294/TCP,8081:31436/TCP 20s +``` + + +将浏览器指向端口 31533 连接到 Spark 主节点 UI: + +![kubedirector](/images/blog/2018-10-03-kubedirector/kubedirector.png) + + +就是这样! +事实上,在上面的例子中,我们还部署了一个 Jupyter notebook 和 Spark 集群。 + + +要启动另一个应用程序(例如 Cassandra),只需指定另一个 KubeDirectorApp 文件: + +``` +kubectl create -f deploy/example_clusters/cr-cluster-cassandra311.yaml +``` + + +查看正在运行的 Cassandra 集群: + +``` +~> kubectl get pods +NAME READY STATUS RESTARTS AGE +cassandra311-seed-v24r6-0 1/1 Running 0 1m +cassandra311-seed-v24r6-1 1/1 Running 0 1m +cassandra311-worker-rqrhl-0 1/1 Running 0 1m +cassandra311-worker-rqrhl-1 1/1 Running 0 1m +kubedirector-58cf59869-djdwl 1/1 Running 0 1d +spark221e2-controller-tq8d6-0 1/1 Running 0 22m +spark221e2-jupyter-6989v-0 1/1 Running 0 22m +spark221e2-worker-d9892-0 1/1 Running 0 22m +spark221e2-worker-d9892-1 1/1 Running 0 22m +``` + + +现在,您有一个 Spark 集群(带有 Jupyter notebook )和一个运行在 Kubernetes 上的 Cassandra 集群。 +使用 `kubectl get service` 查看服务集。 + +``` +~> kubectl get service +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +kubedirector ClusterIP 10.98.234.194 60000/TCP 1d +kubernetes ClusterIP 10.96.0.1 443/TCP 1d +svc-cassandra311-seed-v24r6-0 NodePort 10.96.94.204 22:31131/TCP,9042:30739/TCP 3m +svc-cassandra311-seed-v24r6-1 NodePort 10.106.144.52 22:30373/TCP,9042:32662/TCP 3m +svc-cassandra311-vhh29 ClusterIP None 8888/TCP 3m +svc-cassandra311-worker-rqrhl-0 NodePort 10.109.61.194 22:31832/TCP,9042:31962/TCP 3m +svc-cassandra311-worker-rqrhl-1 NodePort 10.97.147.131 22:31454/TCP,9042:31170/TCP 3m +svc-spark221e2-5tg48 ClusterIP None 8888/TCP 24m +svc-spark221e2-controller-tq8d6-0 NodePort 10.104.181.123 22:30534/TCP,8080:31533/TCP,7077:32506/TCP,8081:32099/TCP 24m +svc-spark221e2-jupyter-6989v-0 NodePort 10.105.227.249 22:30632/TCP,8888:30355/TCP 24m +svc-spark221e2-worker-d9892-0 NodePort 10.107.131.165 22:30358/TCP,8081:32144/TCP 24m +svc-spark221e2-worker-d9892-1 NodePort 10.110.88.221 22:30294/TCP,8081:31436/TCP 24m +``` + + + +## 参与其中 + + +KubeDirector 是一个完全开放源码的 Apache v2 授权项目 – 在我们称为 BlueK8s 的更广泛的计划中,它是多个开放源码项目中的第一个。 +KubeDirector 的 pre-alpha 代码刚刚发布,我们希望您加入到不断增长的开发人员、贡献者和使用者社区。 +在 Twitter 上关注 [@BlueK8s](https://twitter.com/BlueK8s/),并通过以下渠道参与: + + + +* KubeDirector [Slack 聊天室](https://join.slack.com/t/bluek8s/shared_invite/enQtNDUwMzkwODY5OTM4LTRhYmRmZmE4YzY3OGUzMjA1NDg0MDVhNDQ2MGNkYjRhM2RlMDNjMTI1NDQyMjAzZGVlMDFkNThkNGFjZGZjMGY/) +* KubeDirector [GitHub 仓库](https://github.com/bluek8s/kubedirector/) diff --git a/content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md b/content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md new file mode 100644 index 0000000000..3aefd018ab --- /dev/null +++ b/content/zh/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md @@ -0,0 +1,268 @@ +--- +layout: blog +title: 'Kubernetes 中的拓扑感知数据卷供应' +date: 2018-10-11 +--- + + + +**作者**: Michelle Au(谷歌) + + +通过提供拓扑感知动态卷供应功能,具有持久卷的多区域集群体验在 Kubernetes 1.12 中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策,方法是从调度器获得为 Pod 提供数据卷的最佳位置。在多区域集群环境,这意味着数据卷能够在满足你的 Pod 运行需要的合适的区域被供应,从而允许您跨故障域轻松部署和扩展有状态工作负载,从而提供高可用性和容错能力。 + + +## 以前的挑战 + + +在此功能被提供之前,在多区域集群中使用区域化的持久磁盘(例如 AWS ElasticBlockStore,Azure Disk,GCE PersistentDisk)运行有状态工作负载存在许多挑战。动态供应独立于 Pod 调度处理,这意味着只要您创建了一个 PersistentVolumeClaim(PVC),一个卷就会被供应。这也意味着供应者不知道哪些 Pod 正在使用该卷,也不清楚任何可能影响调度的 Pod 约束。 + + +这导致了不可调度的 Pod,因为在以下区域中配置了卷: + + +* 没有足够的 CPU 或内存资源来运行 Pod +* 与节点选择器、Pod 亲和或反亲和策略冲突 +* 由于污点(taint)不能运行 Pod + + +另一个常见问题是,使用多个持久卷的非有状态 Pod 可能会在不同的区域中配置每个卷,从而导致一个不可调度的 Pod。 + + +次优的解决方法包括节点超配,或在正确的区域中手动创建卷,但这会造成难以动态部署和扩展有状态工作负载的问题。 + + +拓扑感知动态供应功能解决了上述所有问题。 + + +## 支持的卷类型 + + +在 1.12 中,以下驱动程序支持拓扑感知动态供应: + + +* AWS EBS +* Azure Disk +* GCE PD (包括 Regional PD) +* CSI(alpha) - 目前只有 GCE PD CSI 驱动实现了拓扑支持 + + +## 设计原则 + + +虽然最初支持的插件集都是基于区域的,但我们设计此功能时遵循 Kubernetes 跨环境可移植性的原则。 +拓扑规范是通用的,并使用类似于基于标签的规范,如 Pod nodeSelectors 和 nodeAffinity。 +该机制允许您定义自己的拓扑边界,例如内部部署集群中的机架,而无需修改调度程序以了解这些自定义拓扑。 + + +此外,拓扑信息是从 Pod 规范中抽象出来的,因此 Pod 不需要了解底层存储系统的拓扑特征。 +这意味着您可以在多个集群、环境和存储系统中使用相同的 Pod 规范。 + + +## 入门 + + +要启用此功能,您需要做的就是创建一个将 `volumeBindingMode` 设置为 `WaitForFirstConsumer` 的 StorageClass: + +``` +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: topology-aware-standard +provisioner: kubernetes.io/gce-pd +volumeBindingMode: WaitForFirstConsumer +parameters: + type: pd-standard +``` + + +这个新设置表明卷配置器不立即创建卷,而是等待使用关联的 PVC 的 Pod 通过调度运行。 +请注意,不再需要指定以前的 StorageClass `zone` 和 `zones` 参数,因为现在在哪个区域中配置卷由 Pod 策略决定。 + + +接下来,使用此 StorageClass 创建一个 Pod 和 PVC。 +此过程与之前相同,但在 PVC 中指定了不同的 StorageClass。 +以下是一个假设示例,通过指定许多 Pod 约束和调度策略来演示新功能特性: + + +* 一个 Pod 多个 PVC +* 跨子区域的节点亲和 +* 同一区域 Pod 反亲和 + +``` +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + serviceName: "nginx" + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-f + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - nginx + topologyKey: failure-domain.beta.kubernetes.io/zone + containers: + - name: nginx + image: gcr.io/google_containers/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + - name: logs + mountPath: /logs + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: topology-aware-standard + resources: + requests: + storage: 10Gi + - metadata: + name: logs + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: topology-aware-standard + resources: + requests: + storage: 1Gi +``` + + +之后,您可以看到根据 Pod 设置的策略在区域中配置卷: + +``` +$ kubectl get pv -o=jsonpath='{range .items[*]}{.spec.claimRef.name}{"\t"}{.metadata.labels.failure\-domain\.beta\.kubernetes\.io/zone}{"\n"}{end}' +www-web-0 us-central1-f +logs-web-0 us-central1-f +www-web-1 us-central1-a +logs-web-1 us-central1-a +``` + + +## 我怎样才能了解更多? + + +有关拓扑感知动态供应功能的官方文档可在此处获取:https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode + + +有关 CSI 驱动程序的文档,请访问:https://kubernetes-csi.github.io/docs/ + + +## 下一步是什么? + + +我们正积极致力于改进此功能以支持: + + +* 更多卷类型,包括本地卷的动态供应 +* 动态容量可附加计数和每个节点的容量限制 + + +## 我如何参与? + + +如果您对此功能有反馈意见或有兴趣参与设计和开发,请加入 [Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)(SIG)。我们正在快速成长,并始终欢迎新的贡献者。 + + +特别感谢帮助推出此功能的所有贡献者,包括 Cheng Xing ([verult](https://github.com/verult))、Chuqiang Li ([lichuqiang](https://github.com/lichuqiang))、David Zhu ([davidz627](https://github.com/davidz627))、Deep Debroy ([ddebroy](https://github.com/ddebroy))、Jan Šafránek ([jsafrane](https://github.com/jsafrane))、Jordan Liggitt ([liggitt](https://github.com/liggitt))、Michelle Au ([msau42](https://github.com/msau42))、Pengfei Ni ([feiskyer](https://github.com/feiskyer))、Saad Ali ([saad-ali](https://github.com/saad-ali))、Tim Hockin ([thockin](https://github.com/thockin)),以及 Yecheng Fu ([cofyc](https://github.com/cofyc))。 diff --git a/content/zh/blog/_posts/2018-10-15-steering-election-results.md b/content/zh/blog/_posts/2018-10-15-steering-election-results.md new file mode 100644 index 0000000000..8e7d5edf7e --- /dev/null +++ b/content/zh/blog/_posts/2018-10-15-steering-election-results.md @@ -0,0 +1,73 @@ +--- +layout: blog +title: '2018 年督导委员会选举结果' +date: 2018-10-15 +--- + + + +**作者**: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google) + + +## 结果 + +[Kubernetes 督导委员会选举](https://kubernetes.io/blog/2018/09/06/2018-steering-committee-election-cycle-kicks-off/)现已完成,以下候选人获得了立即开始的两年任期: + +* Aaron Crickenberger, Google, [@spiffxp](https://github.com/spiffxp) +* Davanum Srinivas, Huawei, [@dims](https://github.com/dims) +* Tim St. Clair, Heptio, [@timothysc](https://github.com/timothysc) + + +## 十分感谢! + + +* 督导委员会荣誉退休成员 [Quinton Hoole](https://github.com/quinton-hoole),表扬他在过去一年为社区所作的贡献。我们期待着 +* 参加竞选的候选人。愿我们永远拥有一群强大的人,他们希望在每一次选举中都能像你们一样推动社区向前发展。 +* 共计 307 名选民参与投票。 +* 本次选举由康奈尔大学主办 [CIVS](https://civs.cs.cornell.edu/)! + + +## 加入督导委员会 + +你可以关注督导委员会的[任务清单](https://git.k8s.io/steering/backlog.md),并通过向他们的[代码仓库](https://github.com/kubernetes/steering)提交 issue 或 PR 的方式来参与。他们也会在[UTC 时间每周三晚 8 点](https://github.com/kubernetes/steering)举行会议,并定期与我们的贡献者见面。 + + +督导委员会会议: + +* [YouTube 播放列表](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM) + + +与我们的贡献者会面: + + + +* [2018 年 10 月 3 日](https://youtu.be/x6Jm8p0K-IQ) +* [2018 年 7 月 5 日](https://youtu.be/UbxWV12Or58) diff --git a/content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md b/content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md new file mode 100644 index 0000000000..b504a5c6b6 --- /dev/null +++ b/content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md @@ -0,0 +1,118 @@ +--- +layout: "Blog" +title: "Kubernetes 2018 年北美贡献者峰会" +date: 2018-10-16 +--- + + +**作者:** + +[Bob Killen][bob](密歇根大学) +[Sahdev Zala][sahdev](IBM), +[Ihor Dvoretskyi][ihor](CNCF) + + +2018 年北美 Kubernetes 贡献者峰会将在西雅图 [KubeCon + CloudNativeCon][kubecon] 会议之前举办,这将是迄今为止规模最大的一次盛会。 + +这是一个将新老贡献者聚集在一起,面对面交流和分享的活动;并为现有的贡献者提供一个机会,帮助塑造社区发展的未来。它为新的社区成员提供了一个学习、探索和实践贡献工作流程的良好空间。 + + +与之前的贡献者峰会不同,本次活动为期两天,有一个更为轻松的行程安排,一般贡献者将于 12 月 9 日(周日)下午 5 点至 8 点在距离会议中心仅几步远的 [Garage Lounge and Gaming Hall][garage] 举办峰会。在那里,贡献者也可以进行台球、保龄球等娱乐活动,而且还有各种食品和饮料。 + + +接下来的一天,也就是 10 号星期一,有三个独立的会议你可以选择参与: + + +### 新贡献者研讨会: + +为期半天的研讨会旨在让新贡献者加入社区,并营造一个良好的 Kubernetes 社区工作环境。 +请在开会期间保持在场,该讨论会不允许随意进出。 + + +### 当前贡献者追踪: + +保留给那些积极参与项目开发的贡献者;目前的贡献者追踪包括讲座、研讨会、聚会、Unconferences 会议、指导委员会会议等等! +请留意 [GitHub 中的时间表][时间表],因为内容经常更新。 + + +### Docs 冲刺: + +SIG-Docs 将在活动日期临近的时候列出一个需要处理的问题和挑战列表。 + + +## 注册: + +要注册贡献者峰会,请参阅 Git Hub 上的[活动详情注册部分][注册]。请注意报名正在审核中。 +如果您选择了 “当前贡献者追踪”,而您却不是一个活跃的贡献者,您将被要求参加新贡献者研讨会,或者被要求进入候补名单。 +成千上万的贡献者只有 300 个位置,我们需要确保正确的人被安排席位。 + + +如果您有任何问题或疑虑,请随时通过 community@kubernetes.io 联系贡献者峰会组织团队。 + + +期待在那里看到每个人! + +[bob]: https://twitter.com/mrbobbytables +[sahdev]: https://twitter.com/sp_zala +[ihor]: https://twitter.com/idvoretskyi +[kubecon]: https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/ +[garage]: https://www.garagebilliards.com/ +[时间表]: https://git.k8s.io/community/events/2018/12-contributor-summit#agenda +[注册]: https://git.k8s.io/community/events/2018/12-contributor-summit#registration diff --git a/content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md new file mode 100644 index 0000000000..cf6d5e58cb --- /dev/null +++ b/content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md @@ -0,0 +1,89 @@ +--- +layout: blog +title: 'Kubernetes 文档更新,国际版' +date: 2018-11-08 +--- + + + +**作者**:Zach Corleissen (Linux 基金会) + + +作为文档特别兴趣小组(SIG Docs)的联合主席,我很高兴能与大家分享 Kubernetes 文档在本地化(l10n)方面所拥有的一个完全成熟的工作流。 + + +## 丰富的缩写 + + +L10n 是 _localization_ 的缩写。 + + +I18n 是 _internationalization_ 的缩写。 + + +I18n 定义了[做什么](https://www.w3.org/International/questions/qa-i18n) 能让 l10n 更容易。而 L10n 更全面,相比翻译( _t9n_ )具备更完善的流程。 + + +## 为什么本地化很重要 + + +SIG Docs 的目标是让 Kubernetes 更容易为尽可能多的人使用。 + + +一年前,我们研究了是否有可能由一个独立翻译 Kubernetes 文档的中国团队来主持文档输出。经过多次交谈(包括 OpenStack l10n 的专家),[多次转变](https://kubernetes.io/blog/2018/05/05/hugo-migration/),以及[重新致力于更轻松的本地化](https://github.com/kubernetes/website/pull/10485),我们意识到,开源文档就像开源软件一样,是在可能的边缘不断进行实践。 + + +整合工作流程、语言标签和团队级所有权可能看起来像是十分简单的改进,但是这些功能使 l10n 可以扩展到规模越来越大的 l10n 团队。随着 SIG Docs 不断改进,我们已经在单一工作流程中偿还了大量技术债务并简化了 l10n。这对未来和现在都很有益。 + + +## 整合的工作流程 + + +现在,本地化已整合到 [kubernetes/website](https://github.com/kubernetes/website) 存储库。我们已经配置了 Kubernetes CI/CD 系统,[Prow](https://github.com/kubernetes/test-infra/tree/master/prow) 来处理自动语言标签分配以及团队级 PR 审查和批准。 + + +### 语言标签 + + +Prow 根据文件路径自动添加语言标签。感谢 SIG Docs 贡献者 [June Yi](https://github.com/kubernetes/test-infra/pull/9835),他让人们还可以在 pull request(PR)注释中手动分配语言标签。例如,当为 issue 或 PR 留下下述注释时,将为之分配标签 `language/ko`(Korean)。 + +``` +/language ko +``` + + + +这些存储库标签允许审阅者按语言过滤 PR 和 issue。例如,您现在可以过滤 kubernetes/website 面板中[具有中文内容的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh)。 + + +### 团队审核 + + +L10n 团队现在可以审查和批准他们自己的 PR。例如,英语的审核和批准权限在位于用于显示英语内容的顶级子文件夹中的 [OWNERS 文件中指定](https://github.com/kubernetes/website/blob/master/content/en/OWNERS)。 + + +将 `OWNERS` 文件添加到子目录可以让本地化团队审查和批准更改,而无需由可能并不擅长该门语言的审阅者进行批准。 + + +## 下一步是什么 + + +我们期待着[上海的 doc sprint](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) 能作为中国 l10n 团队的资源。 + + +我们很高兴继续支持正在取得良好进展的日本和韩国 l10n 队伍。 + + +如果您有兴趣将 Kubernetes 本地化为您自己的语言或地区,请查看我们的[本地化 Kubernetes 文档指南](https://kubernetes.io/docs/contribute/localization/),并联系 [SIG Docs 主席团](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)获取支持。 + + +### 加入SIG Docs + + +如果您对 Kubernetes 文档感兴趣,请参加 SIG Docs [每周会议](https://github.com/kubernetes/community/tree/master/sig-docs#meetings),或在 [Kubernetes Slack 加入 #sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/details/)。 diff --git a/content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md b/content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md index 4ad2391ace..442942754f 100644 --- a/content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md +++ b/content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md @@ -3,8 +3,7 @@ layout: blog title: '新贡献者工作坊上海站' date: 2018-12-05 --- - - - **作者**: Josh Berkus (红帽), Yang Li (The Plant), Puja Abbassi (Giant Swarm), XiangPeng Zhao (中兴通讯) - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/attendees.png" caption="KubeCon 上海站新贡献者峰会与会者,摄影:Jerry Zhang" >}} - 最近,在中国的首次 KubeCon 上,我们完成了在中国的首次新贡献者峰会。看到所有中国和亚洲的开发者(以及来自世界各地的一些人)有兴趣成为贡献者,这令人非常兴奋。在长达一天的课程中,他们了解了如何、为什么以及在何处为 Kubernetes 作出贡献,创建了 PR,参加了贡献者圆桌讨论,并签署了他们的 CLA。 - 这是我们的第二届新贡献者工作坊(NCW),它由前一次贡献者体验 SIG 成员创建和领导的哥本哈根研讨会延伸而来。根据受众情况,本次活动采用了中英文两种语言,充分利用了 CNCF 赞助的一流的同声传译服务。同样,NCW 团队由社区成员组成,既有说英语的,也有说汉语的:Yang Li、XiangPeng Zhao、Puja Abbassi、Noah Abrahams、Tim Pepper、Zach Corleissen、Sen Lu 和 Josh Berkus。除了演讲和帮助学员外,团队的双语成员还将所有幻灯片翻译成了中文。共有五十一名学员参加。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/noahabrahams.png" caption="Noah Abrahams 讲解 Kubernetes 沟通渠道。摄影:Jerry Zhang" >}} - NCW 让参与者完成了为 Kubernetes 作出贡献的各个阶段,从决定在哪里作出贡献开始,接着介绍了 SIG 系统和我们的代码仓库结构。我们还有来自文档和测试基础设施领域的「客座讲者」,他们负责讲解有关的贡献。最后,我们在创建 issue、提交并批准 PR 的实践练习后,结束了工作坊。 - 这些实践练习使用一个名为[贡献者游乐场](https://github.com/kubernetes-sigs/contributor-playground)的代码仓库,由贡献者体验 SIG 创建,让新贡献者尝试在一个 Kubernetes 仓库中执行各种操作。它修改了 Prow 和 Tide 自动化,使用与真实代码仓库类似的 Owners 文件。这可以让学员了解为我们的仓库做出贡献的有关机制,同时又不妨碍正常的开发流程。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/yangli.png" caption="Yang Li 讲到如何让你的 PR 通过评审。摄影:Josh Berkus" >}} - 「防火长城」和语言障碍都使得在中国为 Kubernetes 作出贡献变得困难。而且,中国的开源商业模式并不成熟,员工在开源项目上工作的时间有限。 - 中国工程师渴望参与 Kubernetes 的研发,但他们中的许多人不知道从何处开始,因为 Kubernetes 是一个如此庞大的项目。通过本次工作坊,我们希望帮助那些想要参与贡献的人,不论他们希望修复他们遇到的一些错误、改进或本地化文档,或者他们需要在工作中用到 Kubernetes。我们很高兴看到越来越多的中国贡献者在过去几年里加入社区,我们也希望将来可以看到更多。 - 「我已经参与了 Kubernetes 社区大约三年」,XiangPeng Zhao 说,「在社区,我注意到越来越多的中国开发者表现出对 Kubernetes 贡献的兴趣。但是,开始为这样一个项目做贡献并不容易。我尽力帮助那些我在社区遇到的人,但是,我认为可能仍有一些新的贡献者离开社区,因为他们在遇到麻烦时不知道从哪里获得帮助。幸运的是,社区在 KubeCon 哥本哈根站发起了 NCW,并在 KubeCon 上海站举办了第二届。我很高兴受到 Josh Berkus 的邀请,帮助组织这个工作坊。在工作坊期间,我当面见到了社区里的朋友,在练习中指导了与会者,等等。所有这些对我来说都是难忘的经历。作为有着多年贡献者经验的我,也学习到了很多。我希望几年前我开始为 Kubernetes 做贡献时参加过这样的工作坊」。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/panel.png" caption="贡献者圆桌讨论。摄影:Jerry Zhang" >}} - 工作坊以现有贡献者圆桌讨论结束,嘉宾包括 Lucas Käldström、Janet Kuo、Da Ma、Pengfei Ni、Zefeng Wang 和 Chao Xu。这场圆桌讨论旨在让新的和现有的贡献者了解一些最活跃的贡献者和维护者的幕后日常工作,不论他们来自中国还是世界各地。嘉宾们讨论了从哪里开始贡献者的旅程,以及如何与评审者和维护者进行互动。他们进一步探讨了在中国参与贡献的主要问题,并向与会者预告了在 Kubernetes 的未来版本中可以期待的令人兴奋的功能。 - 工作坊结束后,XiangPeng Zhao 和一些与会者就他们的经历在微信和 Twitter 上进行了交谈。他们很高兴参加了 NCW,并就改进工作坊提出了一些建议。一位名叫 Mohammad 的与会者说:「我在工作坊上玩得很开心,学习了参与 k8s 贡献的整个过程。」另一位与会者 Jie Jia 说:「工作坊非常精彩。它系统地解释了如何为 Kubernetes 做出贡献。即使参与者之前对此一无所知,他(她)也可以理解这个过程。对于那些已经是贡献者的人,他们也可以学习到新东西。此外,我还可以在工作坊上结识来自国内外的新朋友。真是棒极了!」 - 贡献者体验 SIG 将继续在未来的 KubeCon 上举办新贡献者工作坊,包括西雅图站、巴塞罗那站,然后在 2019 年六月回到上海。如果你今年未能参加,请在未来的 KubeCon 上注册。并且,如果你遇到工作坊的与会者,请务必欢迎他们加入社区。 - 链接: - +--- +title: 案例分析 +linkTitle: 案例分析 +bigheader: Kubernetes 用户案例分析 +abstract: 在生产环境下使用 Kubernetes 的案例集 +layout: basic +class: gridPage +cid: caseStudies +--- + + diff --git a/content/zh/case-studies/ccp-games/ccp_logo.png b/content/zh/case-studies/ccp-games/ccp_logo.png new file mode 100644 index 0000000000..cbf3d267ba Binary files /dev/null and b/content/zh/case-studies/ccp-games/ccp_logo.png differ diff --git a/content/zh/case-studies/ccp-games/index.html b/content/zh/case-studies/ccp-games/index.html new file mode 100644 index 0000000000..8867cbb323 --- /dev/null +++ b/content/zh/case-studies/ccp-games/index.html @@ -0,0 +1,4 @@ +--- +title: CCP Games +content_url: https://cloud.google.com/customers/ccp-games/ +--- \ No newline at end of file diff --git a/content/zh/case-studies/goldman-sachs/gs_logo.png b/content/zh/case-studies/goldman-sachs/gs_logo.png new file mode 100644 index 0000000000..5cc8c14566 Binary files /dev/null and b/content/zh/case-studies/goldman-sachs/gs_logo.png differ diff --git a/content/zh/case-studies/goldman-sachs/index.html b/content/zh/case-studies/goldman-sachs/index.html new file mode 100644 index 0000000000..93d3022d12 --- /dev/null +++ b/content/zh/case-studies/goldman-sachs/index.html @@ -0,0 +1,4 @@ +--- +title: Goldman Sachs +content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/ +--- \ No newline at end of file diff --git a/content/zh/case-studies/huawei/huawei_featured.png b/content/zh/case-studies/huawei/huawei_featured.png new file mode 100644 index 0000000000..22071b4691 Binary files /dev/null and b/content/zh/case-studies/huawei/huawei_featured.png differ diff --git a/content/zh/case-studies/huawei/huawei_logo.png b/content/zh/case-studies/huawei/huawei_logo.png new file mode 100644 index 0000000000..94361a27eb Binary files /dev/null and b/content/zh/case-studies/huawei/huawei_logo.png differ diff --git a/content/zh/case-studies/huawei/index.html b/content/zh/case-studies/huawei/index.html new file mode 100644 index 0000000000..cfd2f562b6 --- /dev/null +++ b/content/zh/case-studies/huawei/index.html @@ -0,0 +1,433 @@ +--- +title: 华为案例分析 + +case_study_styles: true +cid: caseStudies +css: /css/style_huawei.css +--- + + + +
+

案例分析:
以用户和供应商身份拥抱云原生

+ +
+ +
+ 公司  华为     地点  中国深圳     产业  通信设备 + +
+ +
+ +
+ +
+
+

挑战

+ + 华为是世界上最大的电信设备制造商,拥有超过 18 万名员工。 + + + 为了支持华为在全球的快速业务发展,华为内部 IT 部门有 8 个数据中心, + 这些数据中心在 100K+ VMs 上运行了 800 多个应用程序,服务于这 18 万用户。 + + + 随着新应用程序的快速增长,基于 VM 的应用程序的管理和部署的成本和效率都成为业务敏捷性的关键挑战。 + + + 该公司首席软件架构师、开源社区总监侯培新表示: + “这是一个超大的分布式系统,因此我们发现,以更一致的方式管理所有任务始终是一个挑战。 + 我们希望进入一种更敏捷、更得体的实践”。 + + +
+ +
+

解决方案

+ + 在决定使用容器技术后,华为开始将内部 IT 部门的应用程序迁移到 Kubernetes 上运行。 + 到目前为止,大约 30% 的应用程序已经转移为云原生程序。 + +
+
+

影响

+ + “到 2016 年底,华为的内部 IT 部门使用基于 Kubernetes 的平台即服务(PaaS)解决方案管理了 4000 多个节点和数万个容器。 + 全局部署周期从一周缩短到几分钟,应用程序交付效率提高了 10 倍”。 + + + 对于底线,侯培新表示,“我们还看到运营开支大幅削减,在某些情况下可削减 20% 到 30%,我们认为这对我们的业务非常有帮助”。 + + + 这里给出一些华为内部结果资料、外部需求,也是公司的技术包装产品 FusionStage™ , + 它被作为一套 PaaS 解决方案提供给其客户。 + +
+ +
+ +
+ +
+
+ “如果你是一个供应商,为了说服你的客户,你应该自己使用它。 + 幸运的是,因为华为有很多员工,我们可以利用这种技术来展示我们所能构建的云的规模。” + + +
+ +
- 侯培新,首席软件架构师、开源社区总监 + +
+
+
+ +
+ +
+ 华为的 Kubernetes 之旅始于一位开发者。 + + + 两年前,这家网络和电信巨头雇佣的一名工程师对 Kubernetes + 这一跨主机集群的管理应用程序容器的技术产生了兴趣,并开始为其开源社区作出贡献。 + + + 随着技术和社区的发展,他不断地将这门技术告诉他的经理们。

+ + + 与此同时,华为也在为其内部的企业 IT 部门寻找更好的编排系统,该系统应该支持每一个业务的流程处理。 + + + 华为首席软件架构师、开源社区总监侯培新表示, + “我们在全球拥有逾 18 万名员工,内部流程复杂,所以这个部门可能每周都需要开发一些新的应用程序。 + + + 我们的 IT 部门经常需要启动数万个容器,任务要跨越全球数千个节点。 + 这是一个超大的分布式的系统,所以我们发现以更一致的方式管理所有的任务总是一个挑战”。

+ + + 过去,华为曾使用虚拟机来封装应用程序,但是,“每次我们启动虚拟机时”,侯培新说, + “无论是因为它是一项新服务,还是因为它是一项由于节点功能异常而被关闭的服务,都需要花费大量时间”。 + + + 华为转向了容器化,所以是时候尝试 Kubernetes 了。 + 采纳了这位工程师的建议花费了一年的时间,这个过程“不是一蹴而就的”,侯说, + + + 但一旦投入使用,“Kubernetes 基本上解决了我们的大部分问题。 + 以前,部署时间大约需要一周,现在只需几分钟。 + + + 开发人员非常高兴。使用 Kubernetes 的那个部门也十分高兴”。

+ + + 侯培新看到了使用这项技术给公司带来的巨大好处, + “Kubernetes 为基于云的应用程序带来了敏捷性、扩展能力和 DevOps 实践”,他说, + + + “它为我们提供了自定义调度体系结构的能力,这使得容器任务之间的关联性成为可能,从而提高了效率。 + 它支持多种容器格式,同时广泛支持各种容器网络解决方案和容器存储方案”。 + +
+
+ +
+
+ “Kubernetes 基本上解决了我们的大部分问题。 + 以前,部署时间大约需要一周,现在只需几分钟。 + 开发人员很高兴。使用 Kubernetes 的部门也很高兴。” + +
+
+ +
+
+ 最重要的是,这对底线有影响。侯培新说, + “我们还看到,在某些情况下,运营开支会大幅削减 20% 到 30%,这对我们的业务非常有帮助”。

+ + + 华为对这些初步结果感到满意,并看到客户对云原生技术的需求,因此加大了 Kubernetes 的投入。 + 2016 年春,公司不仅成为用户,而且成为了供应商。

+ + + “我们构建了 Kubernetes 技术解决方案”,侯培新说, + 指的是华为的 FusionStage™ PaaS 输出。 + + + “我们的客户,从非常大的电信运营商到银行,都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。 + 但是他们需要花费大量的时间来分解他们的应用程序,将它们转换为微服务体系结构。 + 作为解决方案提供者,我们帮助他们。 + + + 我们已经开始与一些中国银行合作,我们看到中国移动(China Mobile)和德国电信(Deutsche Telekom)等客户对我们很感兴趣”。

+ + + “如果你是一个用户,你就仅仅是个用户”,侯培新补充道,“但如果你是一个供应商,为了说服你的客户,你应该自己使用它。 + + + 幸运的是,因为华为有很多员工,我们可以利用这种技术来展示我们所能构建的云的规模,向客户提供智慧服务”。 + + + 尽管华为拥有自己的私有云,但其许多客户使用华为的解决方案运行跨云应用程序。 + 这是一个很大的卖点,大多数公共云提供商现在都支持 Kubernetes。 + 侯培新说,“这使得跨云转换比其他解决方案更容易”。

+ +
+
+ +
+
+ “我们的客户,从非常大的电信运营商到银行,都喜欢云原生的想法。他们喜欢 Kubernetes 的技术。 + 但是他们需要花很多时间来分解他们的应用程序,把它们变成微服务体系结构,作为一个解决方案提供商,我们帮助他们。” + +
+
+ +
+
+ + 在华为内部,一旦他的团队完成内部业务流程部门向 Kubernetes 的转型,侯培新希望说服更多部门转向云原生开发和实践。 + + + “我们有很多软件开发人员,所以我们将为他们提供我们的平台作为服务解决方案,我们自己的产品”, + 他说,“我们希望在他们的迭代周期中看到显著的成本削减”。

+ + + 在见证了华为最开始的向 Kubernetes 的转型之后,侯培新为其他考虑该技术的公司提供了建议, + “当你开始设计应用程序的架构时,首先考虑云原生,然后再考虑微服务架构”,他说,“我想你会从中受益”。

+ + + 但是如果您已经有了遗留应用程序,“首先从这些应用程序中一些对微服务友好的部分开始, + 这些部分相对容易分解成更简单的部分,并且相对轻量级”,侯培新说, + + + “不要从一开始就认为我想在几天内将整个架构或所有东西都迁移到微服务中。 + 不要把它当作目标。你应该循序渐进地做这件事。 + 我想说的是,对于遗留应用程序,并不是每个部分都适合微服务架构”。

+ + + 毕竟,尽管侯培新对华为的 Kubernetes 充满热情,但他估计, + “未来 10 年,或许 80% 的工作负载可以分布式地在云原生环境中运行,但仍然有 20% 不是,但是没关系。 + 如果我们能够让 80% 的工作负载真正是云原生的、敏捷的,那么最终会有一个更好的世界”。 + +
+
+ +
+
+ “未来 10 年,可能 80% 的工作负载可以分布式地在云原生环境中运行,但仍然有 20% 不是,不过没关系。 + 如果我们能够让 80% 的工作负载真正是云原生的、敏捷的,那么最终会有一个更好的世界。” + +
+
+
+
+ 在不久的将来,侯培新期待着围绕着 Kubernetes 开发的新功能,尤其是华为正在开发的那些功能。 + + + 华为的工程师已经在为联邦功能(将多个 Kubernetes 集群放在一个框架中进行无缝管理)、调度、容器网络和存储,以及刚刚发布的一项名为 + Container Ops 的技术工作,这是一个 DevOps 管道引擎。 + + + “这将把每个 DevOps 作业放到一个容器中”,他解释说,“这种容器机制使用 Kubernetes 运行,也用于测试 Kubernetes。 + 有了这种机制,我们可以比以前更容易地创建、共享和管理容器化 DevOps 作业”。

+ + + 尽管如此,侯培新认为这项技术只是实现其全部潜力的一半。 + 首先,也是最重要的,他想要扩大它可以协调的规模, + 这对于华为这样的超大规模公司以及它的一些客户来说非常重要。

+ + + 侯培新自豪地指出,在华为第一位工程师成为 Kubernetes 的贡献者和传道者两年后,华为现在是这个社区的最大贡献者。 + 他说,“我们发现,你对社区的贡献越大,你得到的回报也就越多”。 + +
+
diff --git a/content/zh/case-studies/liveperson/index.html b/content/zh/case-studies/liveperson/index.html new file mode 100644 index 0000000000..0cadb0f274 --- /dev/null +++ b/content/zh/case-studies/liveperson/index.html @@ -0,0 +1,4 @@ +--- +title: LivePerson +content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson +--- \ No newline at end of file diff --git a/content/zh/case-studies/liveperson/liveperson_logo.png b/content/zh/case-studies/liveperson/liveperson_logo.png new file mode 100644 index 0000000000..b7e63d94f7 Binary files /dev/null and b/content/zh/case-studies/liveperson/liveperson_logo.png differ diff --git a/content/zh/case-studies/monzo/index.html b/content/zh/case-studies/monzo/index.html new file mode 100644 index 0000000000..99d4f35934 --- /dev/null +++ b/content/zh/case-studies/monzo/index.html @@ -0,0 +1,4 @@ +--- +title: Monzo +content_url: https://youtu.be/YkOY7DgXKyw +--- \ No newline at end of file diff --git a/content/zh/case-studies/monzo/monzo_logo.png b/content/zh/case-studies/monzo/monzo_logo.png new file mode 100644 index 0000000000..854409d17e Binary files /dev/null and b/content/zh/case-studies/monzo/monzo_logo.png differ diff --git a/content/zh/case-studies/philips/index.html b/content/zh/case-studies/philips/index.html new file mode 100644 index 0000000000..e45d41a776 --- /dev/null +++ b/content/zh/case-studies/philips/index.html @@ -0,0 +1,4 @@ +--- +title: Philips +content_url: https://cloud.google.com/customers/philips/ +--- \ No newline at end of file diff --git a/content/zh/case-studies/philips/philips_logo.png b/content/zh/case-studies/philips/philips_logo.png new file mode 100644 index 0000000000..9ba3421a61 Binary files /dev/null and b/content/zh/case-studies/philips/philips_logo.png differ diff --git a/content/zh/case-studies/pokemon-go/index.html b/content/zh/case-studies/pokemon-go/index.html new file mode 100644 index 0000000000..ed4e168019 --- /dev/null +++ b/content/zh/case-studies/pokemon-go/index.html @@ -0,0 +1,4 @@ +--- +title: Pokemon GO +content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html +--- \ No newline at end of file diff --git a/content/zh/case-studies/pokemon-go/pokemon_go_logo.png b/content/zh/case-studies/pokemon-go/pokemon_go_logo.png new file mode 100644 index 0000000000..3cf2b5c7ef Binary files /dev/null and b/content/zh/case-studies/pokemon-go/pokemon_go_logo.png differ diff --git a/content/zh/case-studies/samsung-sds/index.html b/content/zh/case-studies/samsung-sds/index.html new file mode 100644 index 0000000000..db4aa479ab --- /dev/null +++ b/content/zh/case-studies/samsung-sds/index.html @@ -0,0 +1,4 @@ +--- +title: Samsung SDS +content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/ +--- \ No newline at end of file diff --git a/content/zh/case-studies/samsung-sds/sds_logo.png b/content/zh/case-studies/samsung-sds/sds_logo.png new file mode 100644 index 0000000000..0a172df65d Binary files /dev/null and b/content/zh/case-studies/samsung-sds/sds_logo.png differ diff --git a/content/zh/case-studies/soundcloud/index.html b/content/zh/case-studies/soundcloud/index.html new file mode 100644 index 0000000000..c3c99ba715 --- /dev/null +++ b/content/zh/case-studies/soundcloud/index.html @@ -0,0 +1,4 @@ +--- +title: SoundCloud +content_url: https://www.youtube.com/watch?v=5378N5iLb2Q +--- diff --git a/content/zh/case-studies/soundcloud/soundcloud_logo.png b/content/zh/case-studies/soundcloud/soundcloud_logo.png new file mode 100644 index 0000000000..f8c12f05b5 Binary files /dev/null and b/content/zh/case-studies/soundcloud/soundcloud_logo.png differ diff --git a/content/zh/case-studies/squarespace/index.html b/content/zh/case-studies/squarespace/index.html new file mode 100644 index 0000000000..b78180f52c --- /dev/null +++ b/content/zh/case-studies/squarespace/index.html @@ -0,0 +1,224 @@ +--- +title: Squarespace 案例分析 +case_study_styles: true +cid: caseStudies +css: /css/style_case_studies.css +--- + + + + + +
+

案例分析:
+
Squarespace: 借力 Kubernetes 提升效率和可靠性
+

+
+ + + +
+ 公司名  Squarespace     地址  纽约市,纽约州     行业  软件服务,网站构建平台 +
+ +
+
+
+
+ +

挑战

+ 自从 2014 年,我们从 monolith 架构移植到微服务架构, + “虽然解决了开发端的问题,但却带来了架构组的问题”,Squarespace 网站可靠性组的主任工程师 Kevin Lynch 说道。 + “5000 个 VM 主机上的部署过程,让每个人都举步维艰。” + +
+ +

解决方案

+ 网站可靠性组开始尝试使用不同的容器编排平台,然后发现 Kubernetes “解决了我们所有的既有问题”,Lynch 说道。于是整个公司在 2016 年开始在自己的数据中心中运行 Kubernetes 集群。 +
+ +
+ + + +

影响

+自从 Squarespace 开始全面使用 Kubernetes,伴随着网络技术栈的革新,部署时间大幅减少85%。 +以前,他们的 VM 部署需要耗费半个小时;现在,Lynch 提到,“一个人可以生成一个模板应用,在五分钟内部署,并将实例容器化,并在模拟环境下运行。”正因为如此,“开发效率节省了大量的成本。” +他又补充道,“当我们开始用 Kubernetes 时,我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。” +Kubernetes 也同样提升了可靠性:“如果一个节点宕掉,马上会重新调度一个新的节点,没有任何性能上的影响。” + +
+ +
+
+
+
+ +

“一旦你验证了 Kubernetes 可以解决一个问题,每个人都会立即着手解决其它的问题,无需你的布道。” +

— Kevin Lynch,Squarespace 网站可靠性组的主任工程师
+
+
+
+
+ +

从 2003 年宿舍起步, Squarespace 已经为数百万人提供了网站构建服务。

+ + + + 但在幕后,公司的单体应用却让开发人员在平台创新上举步维艰。所以在 2014 年,公司决定”走微服务之路”,Kevin Lynch 提到,Squarespace 网站稳定性组的主任工程师。 + “但是我们还是一直在自己的 vCenter VMware 虚拟机[我们自己的数据中心]上部署应用。微服务解决了开发端的问题,但是让问题转变到了基础架构组这一边。我们在5000个虚拟机主机上的部署流程让每个人的开发效率都提高不起来。” + + + + 在尝试过另外一个容器编排平台,“非常痛苦地拆解它”,Lynch 说道,我们组开始在 2016 年年中尝试 Kubernetes,发现它“能解决我们所有的问题”。 + 将 Kubernetes 部署在数据中心,而非公有云上是我们最大的挑战,但在当时,并没有很多其它的公司会这么做。 + “我们必须要自己摸索出如何在自己的基础架构中部署它,我们也必须要将其和我们其它的应用做集成,”Lynch补充道。

+ + + + 与此同时,Squarespace 的网络工程组也正在革新它们的网络技术栈,从传统的 L2 网络转变为 L3 脊叶网络架构。 + “” Lynch 说道,“它给了我们服务器直接通过架顶交换机通信的能力。我们使用 Calico 作为 + Kubernetes 的 CNI 网络插件”, + 因而,我们可以为每个 Kubernetes pod 分配 IP 地址,并将它们和其它仍在虚拟机中创建的服务无缝衔接。 + +
+
+ +
+ +
+ 在尝试过另外一个容器编排平台,“非常痛苦地拆解它”,Lynch 说道,我们组开始在 2016 年年中尝试 Kubernetes,发现它“能解决我们所有的问题”。 +
+
+ +
+
+ + + 几个月的时间,它们就有了一个稳定的集群供内部使用,并开始在生产环境下使用 Kubernetes。 + 他们同时还在自己的云原生技术栈中用到了 Zipkin 和 CNCF 项目 Prometheus and fluentd 。 + “我们换到 Kubernetes,就像进入了一个新世界,我们也同时改进了其它的工具,” Lynch 说道。“它让我们简化了流程,因而,我们才能更加方便地从模板中创建整个微服务项目,生成代码和部署管道,生成 Docker 文件, + 并迅速地将可用的、可部署的项目发布到 Kubernetes 集群上。”在 Dev/QA/Stage/Prod 不同环境间的部署也变得 “异常的简单,” Lynch 补充道。 + “现在,环境间的配置差异变得很小。” + +

+ + + 而且整个部署过程只需要五分钟,和虚拟机部署相比,几乎节约了 85% 的时间。 + “从端到端可能要半个小时,这还没有考虑可能需要基础架构工程师来做这方面的工作,因而,也还有一些业务上的延时。” +

+ + + 部署变快之后,“开发效率节省了大量的成本,” Lynch 提到,“我们有个组想要实现新的文件存储服务,他们就径直和我们的存储后来做了集成,而不需要我们的参与”,这在采用 Kubernetes 之前是不可想象的。 + 他又补充道:“在我们开始 Kubernetes 项目时,我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。” + + + +
+
+
+
+ + + “我们换到 Kubernetes,就像进入了一个新世界....它让我们简化了流程,因而,我们才能更加方便地从模板中创建整个微服务项目,” + Lynch 说道。整个部署过程只需要五分钟,和虚拟机部署相比,几乎节约了 85% 的时间。 +
+
+ +
+
+ + + 同样在应用程序的可靠性方面也有积极的影响。“当我们在部署虚拟机时,我们需要工具来保障服务散布在机架间,可以承受失败,”他说道,“Kubernetes 正好可以做到这一点。如果节点宕掉,可以马上重新调度,没有性能影响。” +

+ + + 另一个很大的好处就是扩缩容。“按照我们使用 VMware 的方式,扩缩容好像不可能实现,”Lynch 说道,“但现在,我们可以直接通过 Kubernetes 加入合适的扩缩容功能,然后,随着需求的增加而扩容。开箱即用!” +

+ + + 针对刚开始使用 Kubernetes 的人,Lynch 说他最后的建议就是“快速失败”:“一旦计划后,马上执行。Kubernetes 真的是非常适合快速实验,看看是否可行。” + +
+ +
+
+ + + “当我们在部署虚拟机时,我们需要工具来保障服务散布在机架间,可以承受失败,”他说道,“Kubernetes 正好可以做到这一点。如果节点宕掉,可以马上重新调度,没有性能影响。” + +
+
+ +
+ + + Lynch 和他的小组正准备开源一些他们的工具,这些工具用来延展 Kubernetes,将其作为 API 使用。 + 第一个工具在 pod 将依赖应用作为容器注入。 + “当你在发布应用时,常常需要一系列的依赖应用,例如,日志用的 fluentd,” 他解释道。 + 有了这个工具,开发人员就不需要担心配置了。 + +

+ + + 自此之后,Squarespace 所有新的微服务都将直接部署到 Kubernetes 上,而最终的目标是要扩大到所有的服务上。 + 现在已经有四分之一的服务已经移植完。“我的单体应用将是最后一个被移植的,仅仅是以为它太大、太复杂,”Lynch 说道。 + “但现在我已经看到其它的服务已经被移植到 Kubernetes 上,例如文件存储服务。有人解决了,而且并不复杂。 + 所以我坚信如果我们着手解决它,很可能回避我们所担心的要轻松许多。也许我应该接受自己的建议,“快速失败”!” + +
+ +
diff --git a/content/zh/case-studies/squarespace/squarespace_featured_logo.png b/content/zh/case-studies/squarespace/squarespace_featured_logo.png new file mode 100644 index 0000000000..551b6da321 Binary files /dev/null and b/content/zh/case-studies/squarespace/squarespace_featured_logo.png differ diff --git a/content/zh/case-studies/wepay/index.html b/content/zh/case-studies/wepay/index.html new file mode 100644 index 0000000000..b8ce8201d5 --- /dev/null +++ b/content/zh/case-studies/wepay/index.html @@ -0,0 +1,4 @@ +--- +title: WePay +content_url: http://thenewstack.io/wepay-kubernetes-changed-business/ +--- \ No newline at end of file diff --git a/content/zh/case-studies/wepay/wepay_logo.png b/content/zh/case-studies/wepay/wepay_logo.png new file mode 100644 index 0000000000..4e35dd8fd6 Binary files /dev/null and b/content/zh/case-studies/wepay/wepay_logo.png differ diff --git a/content/zh/case-studies/yahoo-japan/index.html b/content/zh/case-studies/yahoo-japan/index.html new file mode 100644 index 0000000000..724a41ae01 --- /dev/null +++ b/content/zh/case-studies/yahoo-japan/index.html @@ -0,0 +1,4 @@ +--- +title: Yahoo! Japan +content_url: https://kubernetes.io/blog/2016/10/kubernetes-and-openstack-at-yahoo-japan +--- \ No newline at end of file diff --git a/content/zh/case-studies/yahoo-japan/yahooJapan_logo.png b/content/zh/case-studies/yahoo-japan/yahooJapan_logo.png new file mode 100644 index 0000000000..3cbea39598 Binary files /dev/null and b/content/zh/case-studies/yahoo-japan/yahooJapan_logo.png differ diff --git a/content/zh/case-studies/zulily/index.html b/content/zh/case-studies/zulily/index.html index d41671470f..d5caf422aa 100644 --- a/content/zh/case-studies/zulily/index.html +++ b/content/zh/case-studies/zulily/index.html @@ -1,4 +1,4 @@ ---- -title: Zulily -content_url: https://www.youtube.com/embed/of45hYbkIZs ---- +--- +title: Zulily +content_url: https://www.youtube.com/embed/of45hYbkIZs +--- diff --git a/content/zh/community/_index.html b/content/zh/community/_index.html new file mode 100644 index 0000000000..53cbbd0682 --- /dev/null +++ b/content/zh/community/_index.html @@ -0,0 +1,133 @@ +--- +title: 社区 +layout: basic +cid: community +--- + + + +
+
+ + +
+

保证 Kubernetes 到处都适用,每个人都喜欢。

+

在我们的Slack channel, + 讨论版, 或者 + Kubernetes-dev Google 群主上和 Kubernetes 互动。 + 同时,每周我们也有社区视频会议,讨论最新进展。参见 + 这些指导了解如何参与其中。

+

你也可以在世界各地通过我们的 + Kubernetes Meetup 社区 以及 + Kubernetes Cloud Native Meetup 社区来参与。

+
+ + + +
+

特殊兴趣小组 (Special Interest Groups,SIGs)

+

对于 Kubernetes 是如何和另外的技术协作感兴趣?了解下我们不停发展的 + SIGs 群组, + 从 AWS 和 Openstack 到 大数据和可扩展性,总会有一个适合你,如果你所关注的不在其列,也有指导帮助你成立新的 SIG。

+ +

作为 Kubernetes 社区的一员,你可以随意加入任何你感兴趣的 SIG 会议。不需要额外注册。

+
+ + + +
+

行为规范

+

Kubernetes 社区重视尊重和包容,并要求在所有场合都遵循 + 行为规范。 + 如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为,请联系 + Kubernetes 行为规范委员会 + conduct@kubernetes.io. + 我们会确保您的匿名性。

+
+
+
+ + + +
+
+

与我们联系!

+

我们很希望听到你的声音,你是如何使用 Kubernetes 的,
以及我们可以将 Kubernetes 变得更美好。

+
+
+ @kubernetesio +

获取更多的资讯和更新。

+
+
+ Github 项目 +

了解项目,作出贡献。

+
+
+ #kubernetes-users +

Slack channel 是联系工程师,分享想法的最佳方法。

+
+
+ Stack Overflow +

我们的论坛是获得社区支持的最佳地点。

+
+
+
+
diff --git a/content/zh/community/code-of-conduct.md b/content/zh/community/code-of-conduct.md new file mode 100644 index 0000000000..848c58832e --- /dev/null +++ b/content/zh/community/code-of-conduct.md @@ -0,0 +1,44 @@ +--- +title: 社区 +layout: basic +cid: community +css: /css/community.css +--- + + + +
+ +

Kubernetes 社区行为规范

+ + + +Kubernetes 遵循 +CNCF 行为规范。 +CNCF 社区规范文本如下链接 +commit 0ce4694。 +如果您发现这个 CNCF 社区规范文本已经过时,请 +提交 issue。 + + + +如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为,请联系[Kubernetes 行为规范委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。 +我们会确保您的匿名性。 + +
+{{< include "/static/cncf-code-of-conduct.md" >}} +
+
diff --git a/content/zh/community/static/README.md b/content/zh/community/static/README.md new file mode 100644 index 0000000000..6d65182dcc --- /dev/null +++ b/content/zh/community/static/README.md @@ -0,0 +1,5 @@ + + +本路径下的文件从其它地方导入。 +除了版本更新,不要直接修改。 diff --git a/content/zh/community/static/cncf-code-of-conduct.md b/content/zh/community/static/cncf-code-of-conduct.md new file mode 100644 index 0000000000..3ee025ba34 --- /dev/null +++ b/content/zh/community/static/cncf-code-of-conduct.md @@ -0,0 +1,46 @@ + +## CNCF Community Code of Conduct v1.0 + +### Contributor Code of Conduct + +As contributors and maintainers of this project, and in the interest of fostering +an open and welcoming community, we pledge to respect all people who contribute +through reporting issues, posting feature requests, updating documentation, +submitting pull requests or patches, and other activities. + +We are committed to making participation in this project a harassment-free experience for +everyone, regardless of level of experience, gender, gender identity and expression, +sexual orientation, disability, personal appearance, body size, race, ethnicity, age, +religion, or nationality. + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery +* Personal attacks +* Trolling or insulting/derogatory comments +* Public or private harassment +* Publishing other's private information, such as physical or electronic addresses, + without explicit permission +* Other unethical or unprofessional conduct. + +Project maintainers have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are not +aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers +commit themselves to fairly and consistently applying these principles to every aspect +of managing this project. Project maintainers who do not follow or enforce the Code of +Conduct may be permanently removed from the project team. + +This code of conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting +the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) . + +This Code of Conduct is adapted from the Contributor Covenant +(http://contributor-covenant.org), version 1.2.0, available at +http://contributor-covenant.org/version/1/2/0/ + +### CNCF Events Code of Conduct + +CNCF events are governed by the Linux Foundation [Code of Conduct](http://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents. diff --git a/content/zh/docs/_index.md b/content/zh/docs/_index.md index e31ea1aea7..3c22824d43 100644 --- a/content/zh/docs/_index.md +++ b/content/zh/docs/_index.md @@ -1,3 +1,8 @@ --- title: 文档 --- + + diff --git a/content/zh/docs/admin/accessing-the-api.md b/content/zh/docs/admin/accessing-the-api.md index 930cf620fd..27540879b7 100644 --- a/content/zh/docs/admin/accessing-the-api.md +++ b/content/zh/docs/admin/accessing-the-api.md @@ -3,40 +3,40 @@ approvers: - bgrant0607 - erictune - lavalamp -title: Kubernetes API访问控制 +title: Kubernetes API 访问控制 --- -用户通过 `kubectl`、客户端库或者通过发送REST请求[访问API](/docs/user-guide/accessing-the-cluster)。 用户(自然人)和[Kubernetes服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行API访问。 -请求到达API服务器后会经过几个阶段,具体说明如图: +用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户(自然人)和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 +请求到达 API 服务器后会经过几个阶段,具体说明如图: ![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) ## 传输层安全 -在典型的Kubernetes集群中,API通过443端口提供服务。 -API服务器会提供一份证书。 该证书一般是自签名的, 所以用户机器上的 `$USER/.kube/config` 目录通常 -包含该API服务器证书的根证书,用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时,该证书通常会被自动写入用户的`$USER/.kube/config`。 如果集群中存在多个用户,则创建者需要与其他用户共享证书。 +在典型的 Kubernetes 集群中,API 通过 443 端口提供服务。 +API 服务器会提供一份证书。 该证书一般是自签名的, 所以用户机器上的 `$USER/.kube/config` 目录通常 +包含该 API 服务器证书的根证书,用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时,该证书通常会被自动写入用户的 `$USER/.kube/config`。 如果集群中存在多个用户,则创建者需要与其他用户共享证书。 ## 认证 -一旦 TLS 连接建立,HTTP请求就进入到了认证的步骤。即图中的步骤 **1** 。 -集群创建脚本或集群管理员会为API服务器配置一个或多个认证模块。 -更具体的认证相关的描述详见 [这里](/docs/admin/authentication/)。 +一旦 TLS 连接建立,HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。 +集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。 +更具体的认证相关的描述详见[这里](/docs/admin/authentication/)。 -认证步骤的输入是整个HTTP请求,但这里通常只是检查请求头和/或客户端证书。 +认证步骤的输入是整个 HTTP 请求,但这里通常只是检查请求头和 / 或客户端证书。 -认证模块支持客户端证书,密码和Plain Tokens, -Bootstrap Tokens,以及JWT Tokens (用于服务账户)。 +认证模块支持客户端证书,密码和 Plain Tokens, +Bootstrap Tokens,以及 JWT Tokens(用于服务账户)。 (管理员)可以同时设置多种认证模块,在设置了多个认证模块的情况下,每个模块会依次尝试认证, 直到其中一个认证成功。 -在 GCE 平台中,客户端证书,密码和Plain Tokens,Bootstrap Tokens,以及JWT Tokens同时被启用。 +在 GCE 平台中,客户端证书,密码和 Plain Tokens,Bootstrap Tokens,以及 JWT Tokens 同时被启用。 -如果请求认证失败,则请求被拒绝,返回401状态码。 +如果请求认证失败,则请求被拒绝,返回 401 状态码。 如果认证成功,则被认证为具体的 `username`,该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系,另一些则没有。 -尽管Kubernetes使用 "用户名" 来进行访问控制和请求记录,但它实际上并没有 `user` 对象,也不存储用户名称或其他相关信息。 +尽管 Kubernetes 使用“用户名”来进行访问控制和请求记录,但它实际上并没有 `user` 对象,也不存储用户名称或其他相关信息。 ## 授权 @@ -44,7 +44,7 @@ Bootstrap Tokens,以及JWT Tokens (用于服务账户)。 请求须包含请求者的用户名,请求动作,以及该动作影响的对象。 如果存在相应策略,声明该用户具有进行相应操作的权限,则该请求会被授权。 -例如,如果Bob有如下策略,那么他只能够读取`projectCaribou`命名空间下的pod资源: +例如,如果 Bob 有如下策略,那么他只能够读取 `projectCaribou` 命名空间下的 pod 资源: ```json { @@ -58,7 +58,7 @@ Bootstrap Tokens,以及JWT Tokens (用于服务账户)。 } } ``` -如果Bob发起以下请求,那么请求能够通过授权,因为Bob被允许访问 `projectCaribou` 命名空间下的对象: +如果 Bob 发起以下请求,那么请求能够通过授权,因为 Bob 被允许访问 `projectCaribou` 命名空间下的对象: ```json { @@ -74,20 +74,20 @@ Bootstrap Tokens,以及JWT Tokens (用于服务账户)。 } } ``` -如果Bob对 `projectCaribou` 命名空间下的对象发起一个写(`create` 或者 `update`)请求,那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间,例如 `projectFish`下的对象,其授权也会被拒绝。 +如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写(`create` 或者 `update`)请求,那么它的授权会被拒绝。 如果 Bob 请求读取 (`get`)其他命名空间,例如 `projectFish` 下的对象,其授权也会被拒绝。 -Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的,因为除Kubernetes外,这些访问控制系统还可能与其他的API进行交互。 +Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的,因为除 Kubernetes 外,这些访问控制系统还可能与其他的 API 进行交互。 -Kubernetes 支持多种授权模块,例如ABAC模式,RBAC模式和 Webhook模式。 管理员创建集群时,会配置API服务器应用的授权模块。 如果多种授权模式同时被启用,Kubernetes将检查所有模块,如果其中一种通过授权,则请求授权通过。 如果所有的模块全部拒绝,则请求被拒绝(HTTP状态码403)。 +Kubernetes 支持多种授权模块,例如 ABAC 模式,RBAC 模式和 Webhook 模式。 管理员创建集群时,会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用,Kubernetes 将检查所有模块,如果其中一种通过授权,则请求授权通过。 如果所有的模块全部拒绝,则请求被拒绝(HTTP 状态码 403)。 -要了解更多的Kubernetes授权相关信息,包括使用授权模块创建策略的具体说明等,可参考[授权概述](/docs/admin/authorization)。 +要了解更多的 Kubernetes 授权相关信息,包括使用授权模块创建策略的具体说明等,可参考[授权概述](/docs/admin/authorization)。 ## 准入控制 准入控制模块是能够修改或拒绝请求的软件模块。 作为授权模块的补充,准入控制模块会访问被创建或更新的对象的内容。 -它们作用于对象的创建,删除,更新和连接 (proxy)阶段,但不包括对象的读取。 +它们作用于对象的创建,删除,更新和连接(proxy)阶段,但不包括对象的读取。 可以同时配置多个准入控制器,它们会按顺序依次被调用。 @@ -99,23 +99,23 @@ Kubernetes 支持多种授权模块,例如ABAC模式,RBAC模式和 Webhook 可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。 -一旦请求通过所有准入控制器,将使用对应API对象的验证流程对其进行验证,然后写入对象存储 (如步骤 **4**)。 +一旦请求通过所有准入控制器,将使用对应 API 对象的验证流程对其进行验证,然后写入对象存储 (如步骤 **4**)。 -## API的端口和IP +## API 的端口和 IP -上述讨论适用于发送请求到API服务器的安全端口(典型情况)。 -实际上API服务器可以通过两个端口提供服务: +上述讨论适用于发送请求到 API 服务器的安全端口(典型情况)。 +实际上 API 服务器可以通过两个端口提供服务: -默认情况下,API服务器在2个端口上提供HTTP服务: +默认情况下,API 服务器在 2 个端口上提供 HTTP 服务: 1. `Localhost Port`: - 用于测试和启动,以及管理节点的其他组件 - (scheduler, controller-manager)与API的交互 - - 没有TLS - - 默认值为8080,可以通过 `--insecure-port` 标记来修改。 - - 默认的IP地址为localhost, 可以通过 `--insecure-bind-address`标记来修改。 + (scheduler, controller-manager)与 API 的交互 + - 没有 TLS + - 默认值为 8080,可以通过 `--insecure-port` 标记来修改。 + - 默认的 IP 地址为 localhost, 可以通过 `--insecure-bind-address` 标记来修改。 - 请求会 **绕过** 认证和鉴权模块。 - 请求会被准入控制模块处理。 - 其访问需要主机访问的权限。 @@ -124,12 +124,12 @@ Kubernetes 支持多种授权模块,例如ABAC模式,RBAC模式和 Webhook - 尽可能使用该端口访问 - 应用 TLS。 可以通过 `--tls-cert-file` 设置证书, 通过 `--tls-private-key-file` 设置私钥。 - - 默认值为6443,可以通过 `--secure-port` 标记来修改。 - - 默认IP是首个非本地的网络接口地址,可以通过 `--bind-address` 标记来修改。 + - 默认值为 6443,可以通过 `--secure-port` 标记来修改。 + - 默认 IP 是首个非本地的网络接口地址,可以通过 `--bind-address` 标记来修改。 - 请求会经过认证和鉴权模块处理。 - 请求会被准入控制模块处理。 - 要求认证和授权模块正常运行。 -通过 `kube-up.sh`创建集群时, 对 Google Compute Engine (GCE) -和一些其他的云供应商来说, API通过443端口提供服务。 对 -GCE而言,项目上配置了防火墙规则,允许外部的HTTPS请求访问API,其他(厂商的)集群设置方法各不相同。 +通过 `kube-up.sh` 创建集群时, 对 Google Compute Engine(GCE) +和一些其他的云供应商来说, API 通过 443 端口提供服务。 对 +GCE 而言,项目上配置了防火墙规则,允许外部的 HTTPS 请求访问 API,其他(厂商的)集群设置方法各不相同。 diff --git a/content/zh/docs/admin/authorization/_index.md b/content/zh/docs/admin/authorization/_index.md index 92c3d2174d..7941c2705f 100644 --- a/content/zh/docs/admin/authorization/_index.md +++ b/content/zh/docs/admin/authorization/_index.md @@ -16,63 +16,62 @@ content_template: templates/concept {{% capture body %}} -在 Kubernetes 里,您必须经过身份验证(登录),才能授权您的请求(授予访问权限).。有关认证的信息,请参阅[访问控制概述](/docs/admin/access-the-api/)。 +在 Kubernetes 里,您必须经过身份验证 ( 登录 ),才能授权您的请求 ( 授予访问权限 ).。有关认证的信息,请参阅[访问控制概述](/docs/admin/access-the-api/)。 Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用,该系统可以处理除 Kubernetes API 之外的其他 API。 ## 确定请求是允许还是被拒绝 -Kubernetes 使用 API​​ 服务器授权 API 请求。它根据所有策略评估所有请求属性,并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行,这意味着默认情况下是拒绝权限。 +Kubernetes 使用 API ​​ 服务器授权 API 请求。它根据所有策略评估所有请求属性,并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行,这意味着默认情况下是拒绝权限。 -(虽然 Kubernetes 使用 API ​​服务器,访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。) +( 虽然 Kubernetes 使用 API ​​服务器,访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。) -当配置多个授权模块时,按顺序检查每个模块,如果有任何模块授权请求,则可以继续执行该请求。如果所有模块拒绝请求,则拒绝该请求(HTTP状态代码403)。 +当配置多个授权模块时,按顺序检查每个模块,如果有任何模块授权请求,则可以继续执行该请求。如果所有模块拒绝请求,则拒绝该请求 (HTTP 状态代码 403)。 ## 查看您的请求属性 -Kubernetes 仅查看以下API请求属性: +Kubernetes 仅查看以下 API 请求属性 : * **user** - 验证期间提供的 `user` 字符串 * **group** - 认证用户所属的组名列表 -* **“extra"** - 由认证层提供的任意字符串键到字符串值的映射 -* **API** - 指示请求是否用于API资源 -* **Request path** - 诸如`/api`或`/healthz`的其他非资源端点的路径(请参阅[kubectl](#kubectl)). -* **API request verb** - API 动词 `get`,`list`,`create`,`update`,`patch`,`watch`,`proxy`,`redirect`,`delete`和`deletecollection`用于资源请求。要确定资源 API 端点的请求动词,请参阅**确定下面的请求动词**. -* **HTTP request verb** - HTTP动词`get`,`post`,`put`和`delete`用于非资源请求 -* **Resource** - 正在访问的资源的ID或名称(仅适用于资源请求) - --* 对于使用`get`, `update`, `patch`, 和 `delete`动词的资源请求,您必须提供资源名称。 -* **Subresource** - 正在访问的子资源(仅用于资源请求) -* **Namespace** - 正在被访问的对象的命名空间(仅针对命名空间的资源请求) -* **API group** - 正在访问的API组(仅用于资源请求). 一个空字符串指定[核心 API 组](/docs/api/). +* **extra** - 由认证层提供的任意字符串键到字符串值的映射 +* **API** - 指示请求是否用于 API 资源 +* **Request path** - 诸如 `/api` 或 `/healthz` 的其他非资源端点的路径 ( 请参阅[kubectl](#kubectl)). +* **API request verb** - API 动词 `get`,`list`,`create`,`update`,`patch`,`watch`,`proxy`,`redirect`,`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词,请参阅**确定下面的请求动词**. +* **HTTP request verb** - HTTP 动词 `get`,`post`,`put` 和 `delete` 用于非资源请求 +* **Resource** - 正在访问的资源的 ID 或名称 ( 仅适用于资源请求 ),对于使用 `get`, `update`, `patch`, 和 `delete` 动词的资源请求,您必须提供资源名称。 +* **Subresource** - 正在访问的子资源 ( 仅用于资源请求 ) +* **Namespace** - 正在被访问的对象的命名空间 ( 仅针对命名空间的资源请求 ) +* **API group** - 正在访问的 API 组 ( 仅用于资源请求 ). 一个空字符串指定[核心 API 组](/docs/api/). ## 确定请求动词 -要确定资源 API 端点的请求动词,请查看所使用的HTTP动词以及请求是否对单个资源或资源集合进行操作: +要确定资源 API 端点的请求动词,请查看所使用的 HTTP 动词以及请求是否对单个资源或资源集合进行操作 : -HTTP动词| 请求动词 +HTTP 动词 | 请求动词 ---------- | --------------- POST | 创建 -GET,HEAD | 获取(个人资源),列表(集合) +GET,HEAD | 获取 ( 个人资源 ),列表 ( 集合 ) PUT | 更新 PATCH | 补丁 -DELETE| 删除(个人资源),删除(收藏) +DELETE| 删除 ( 个人资源 ),删除 ( 收藏 ) -Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如: +Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如 : -* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)在`extensions` API组中的`podsecuritypolicies`资源上检查`use`动词的授权。 -* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在`rbac.authorization.k8s.io` API组中的`roles`和`clusterroles`资源上检查`bind`动词的授权。 -* [认证](/docs/admin/authentication/) 在核心API组中的`users`,`groups`和`serviceaccounts`上的`impersonate`动词的授权以及`authentication.k8s.io` API组中的`userextras`进行层次检查。 +* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) 在 `extensions` API 组中的 `podsecuritypolicies` 资源上检查 `use` 动词的授权。 +* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在 `rbac.authorization.k8s.io` API 组中的 `roles` 和 `clusterroles` 资源上检查 `bind` 动词的授权。 +* [认证](/docs/admin/authentication/) 在核心 API 组中的 `users`,`groups` 和 `serviceaccounts` 上的 `impersonate` 动词的授权以及 `authentication.k8s.io` API 组中的 `userextras` 进行层次检查。 ## 授权模块 -* **ABAC模式** - 基于属性的访问控制(ABAC)定义了访问控制范例,通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性(用户属性,资源属性,对象,环境属性等)。要了解有关使用ABAC模式的更多信息,请参阅[ABAC模式](/docs/admin/authorization/abac/) -* **RBAC模式** - 基于角色的访问控制(RBAC)是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下,访问是单个用户执行特定任务(例如查看,创建或修改文件)的能力。要了解有关使用RBAC模式的更多信息,请参阅[RBAC模式](/docs/admin/authorization/rbac/) -*当指定 "RBAC"(基于角色的访问控制)使用 "rbac.authorization.k8s.io" API组来驱动授权决定时,允许管理员通过Kubernetes API动态配置权限策略. -.. *截至1.6 RBAC模式是测试版. -.. *要启用RBAC,请使用 `--authorization-mode=RBAC` 启动 apiserver. -* **Webhook模式** - WebHook 是HTTP回调:发生事件时发生的HTTP POST; 通过HTTP POST简单的事件通知. 实施 WebHooks 的 Web 应用程序将在某些事情发生时向URL发送消息. 要了解有关使用Webhook模式的更多信息,请参阅[Webhook模式](/docs/admin/authorization/webhook/) -* **自定义模块** - 您可以创建使用Kubernetes的自定义模块. 要了解更多信息,请参阅下面的**自定义模块**。 +* **ABAC 模式** - 基于属性的访问控制 (ABAC) 定义了访问控制范例,通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性 ( 用户属性,资源属性,对象,环境属性等 )。要了解有关使用 ABAC 模式的更多信息,请参阅 [ABAC 模式](/docs/admin/authorization/abac/) +* **RBAC 模式** - 基于角色的访问控制 (RBAC) 是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下,访问是单个用户执行特定任务 ( 例如查看,创建或修改文件 ) 的能力。要了解有关使用 RBAC 模式的更多信息,请参阅 [RBAC 模式](/docs/admin/authorization/rbac/) +*当指定 "RBAC"( 基于角色的访问控制 ) 使用 "rbac.authorization.k8s.io" API 组来驱动授权决定时,允许管理员通过 Kubernetes API 动态配置权限策略 . +.. *截至 1.6 RBAC 模式是测试版 . +.. *要启用 RBAC,请使用 `--authorization-mode=RBAC` 启动 apiserver. +* **Webhook 模式** - WebHook 是 HTTP 回调 : 发生事件时发生的 HTTP POST; 通过 HTTP POST 简单的事件通知 . 实施 WebHooks 的 Web 应用程序将在某些事情发生时向 URL 发送消息 . 要了解有关使用 Webhook 模式的更多信息,请参阅[Webhook 模式](/docs/admin/authorization/webhook/) +* **自定义模块** - 您可以创建使用 Kubernetes 的自定义模块 . 要了解更多信息,请参阅下面的**自定义模块**。 ### 自定义模块 -可以相当容易地开发其他实现,APIserver 调用 Authorizer 接口: +可以相当容易地开发其他实现 ,APIserver 调用 Authorizer 接口: ```go type Authorizer interface { @@ -80,15 +79,15 @@ type Authorizer interface { } ``` -以确定是否允许每个API操作. +以确定是否允许每个 API 操作 . -授权插件是实现此接口的模块.授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。 +授权插件是实现此接口的模块 . 授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。 授权模块可以完全实现,也可以拨出远程授权服务。 授权模块可以实现自己的缓存,以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。 -#### 检查API访问 +#### 检查 API 访问 -Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问API授权者决策的普通资源。 无论您选择使用哪个授权器,您都可以使用`SubjectAccessReview`发出一个`POST`,就像webhook授权器的`apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样,并回复一个响应。 例如: +Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问 API 授权者决策的普通资源。 无论您选择使用哪个授权器,您都可以使用 `SubjectAccessReview` 发出一个 `POST`,就像 webhook 授权器的 `apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样,并回复一个响应。 例如: ```bash @@ -128,16 +127,16 @@ subjectaccessreview "" created ## 为您的授权模块使用标志 -您的策略中必须包含一个标志,以指出您的策略包含哪个授权模块: +您的策略中必须包含一个标志,以指出您的策略包含哪个授权模块 : -可以使用以下标志: - - `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。 - - `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用Kubernetes API创建和存储策略. - - `--authorization-mode=Webhook` WebHook是一种HTTP回调模式,允许您使用远程REST管理授权。 - - `--authorization-mode=AlwaysDeny` 此标志阻止所有请求. 仅使用此标志进行测试。 - - `--authorization-mode=AlwaysAllow` 此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志。 +可以使用以下标志 : + - `--authorization-mode=ABAC` 基于属性的访问控制 (ABAC) 模式允许您使用本地文件配置策略。 + - `--authorization-mode=RBAC` 基于角色的访问控制 (RBAC) 模式允许您使用 Kubernetes API 创建和存储策略 . + - `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式,允许您使用远程 REST 管理授权。 + - `--authorization-mode=AlwaysDeny` 此标志阻止所有请求 . 仅使用此标志进行测试。 + - `--authorization-mode=AlwaysAllow` 此标志允许所有请求 . 只有在您不需要 API 请求授权的情况下才能使用此标志。 -您可以选择多个授权模块. 如果其中一种模式为 `AlwaysAllow`,则覆盖其他模式,并允许所有API请求。 +您可以选择多个授权模块,如果其中一种模式为 `AlwaysAllow`,则覆盖其他模式,并允许所有 API 请求。 ## 版本控制 diff --git a/content/zh/docs/admin/authorization/abac.md b/content/zh/docs/admin/authorization/abac.md index 4c3715e495..196e541660 100644 --- a/content/zh/docs/admin/authorization/abac.md +++ b/content/zh/docs/admin/authorization/abac.md @@ -20,36 +20,36 @@ content_template: templates/concept 基于 `ABAC` 模式,可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。 -此文件是 JSON 格式[每行都是一个JSON对象](http://jsonlines.org/),不应存在封闭的列表或映射,每行只有一个映射。 +此文件是 JSON 格式[每行都是一个 JSON 对象](http://jsonlines.org/),不应存在封闭的列表或映射,每行只有一个映射。 -每一行都是一个 "策略对象",策略对象是具有以下映射的属性: +每一行都是一个 " 策略对象 ",策略对象是具有以下映射的属性 : - - 版本控制属性: - - `apiVersion`,字符串类型: 有效值为"abac.authorization.kubernetes.io/v1beta1",允许版本控制和转换策略格式。 - - `kind`,字符串类型: 有效值为 "Policy",允许版本控制和转换策略格式。 - - `spec` 配置为具有以下映射的属性: - - 匹配属性: - - `user`,字符串类型; 来自 `--token-auth-file` 的用户字符串,如果你指定`user`,它必须与验证用户的用户名匹配。 - - `group`,字符串类型; 如果指定`group`,它必须与经过身份验证的用户的一个组匹配,`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。 - - 资源匹配属性: - - `apiGroup`,字符串类型; 一个 API 组。 - - 例: `extensions` - - 通配符: `*`匹配所有 API 组。 - - `namespace`,字符串类型; 一个命名空间。 - - 例如: `kube-system` - - 通配符: `*` 匹配所有资源请求。 - - `resource`,字符串类型; 资源类型。 - - 例:`pods` - - 通配符: `*`匹配所有资源请求。 - - 非资源匹配属性: - - `nonResourcePath`,字符串类型; 非资源请求路径。 - - 例如:`/version`或`/apis` - - 通配符: + - 版本控制属性 : + - `apiVersion`,字符串类型 : 有效值为 "abac.authorization.kubernetes.io/v1beta1",允许版本控制和转换策略格式。 + - `kind`,字符串类型 : 有效值为 "Policy",允许版本控制和转换策略格式。 + - `spec` 配置为具有以下映射的属性 : + - 匹配属性 : + - `user`,字符串类型 ; 来自 `--token-auth-file` 的用户字符串,如果你指定 `user`,它必须与验证用户的用户名匹配。 + - `group`,字符串类型 ; 如果指定 `group`,它必须与经过身份验证的用户的一个组匹配,`system:authenticated` 匹配所有经过身份验证的请求。`system:unauthenticated` 匹配所有未经过身份验证的请求。 + - 资源匹配属性 : + - `apiGroup`,字符串类型 ; 一个 API 组。 + - 例 : `extensions` + - 通配符 : `*` 匹配所有 API 组。 + - `namespace`,字符串类型 ; 一个命名空间。 + - 例如 : `kube-system` + - 通配符 : `*` 匹配所有资源请求。 + - `resource`,字符串类型 ; 资源类型。 + - 例 :`pods` + - 通配符 : `*` 匹配所有资源请求。 + - 非资源匹配属性 : + - `nonResourcePath`,字符串类型 ; 非资源请求路径。 + - 例如 :`/version` 或 `/apis` + - 通配符 : - `*` 匹配所有非资源请求。 - - `/foo/*` 匹配`/foo/`的所有子路径。 + - `/foo/*` 匹配 `/foo/` 的所有子路径。 - `readonly`,键入 boolean,如果为 true,则表示该策略仅适用于 get,list 和 watch 操作。 -**注意:** 未设置的属性与类型设置为零值的属性相同(例如空字符串,0、false),然而未知的应该可读性优先。 +**注意 :** 未设置的属性与类型设置为零值的属性相同 ( 例如空字符串,0、false),然而未知的应该可读性优先。 在将来,策略可能以 JSON 格式表示,并通过 REST 界面进行管理。 @@ -57,58 +57,58 @@ content_template: templates/concept 请求具有与策略对象的属性对应的属性。 -当接收到请求时,确定属性。 未知属性设置为其类型的零值(例如: 空字符串,0,false)。 +当接收到请求时,确定属性。 未知属性设置为其类型的零值(例如 : 空字符串,0,false)。 -设置为`“*"`的属性将匹配相应属性的任何值。 +设置为 `"*"` 的属性将匹配相应属性的任何值。 检查属性的元组,以匹配策略文件中的每个策略。 如果至少有一行匹配请求属性,则请求被授权(但可能会在稍后验证失败)。 -要允许任何经过身份验证的用户执行某些操作,请将策略组属性设置为 `"system:authenticated“`。 +要允许任何经过身份验证的用户执行某些操作,请将策略组属性设置为 `"system:authenticated"`。 -要允许任何未经身份验证的用户执行某些操作,请将策略组属性设置为`"system:authentication“`。 +要允许任何未经身份验证的用户执行某些操作,请将策略组属性设置为 `"system:authentication"`。 要允许用户执行任何操作,请使用 apiGroup,命名空间, -资源和 nonResourcePath 属性设置为 `“*"`的策略. +资源和 nonResourcePath 属性设置为 `"*"` 的策略。 -要允许用户执行任何操作,请使用设置为`“*”` 的 apiGroup,namespace,resource 和 nonResourcePath 属性编写策略。 +要允许用户执行任何操作,请使用设置为 `"*"` 的 apiGroup,namespace,resource 和 nonResourcePath 属性编写策略。 ## Kubectl -Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服务器版本。 通过创建/更新来验证发送到API的对象操作,kubectl 查询某些 swagger 资源。 对于API版本"v1", 那就是`/swaggerapi/api/v1` & `/swaggerapi/ experimental/v1`。 +Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端 / 服务器版本。 通过创建 / 更新来验证发送到 API 的对象操作,kubectl 查询某些 swagger 资源。 对于 API 版本 "v1", 那就是 `/swaggerapi/api/v1` & `/swaggerapi/ experimental/v1`。 -当使用 ABAC 授权时,这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来(参见下面的[例子](#examples)): +当使用 ABAC 授权时,这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来 ( 参见下面的[例子](#examples)): -* `/api`,`/api/*`,`/apis`和`/apis/*` 用于 API 版本协商. -* `/version` 通过 `kubectl version` 检索服务器版本. -* `/swaggerapi/*` 用于创建/更新操作. +* `/api`,`/api/*`,`/apis` 和 `/apis/*` 用于 API 版本协商。 +* `/version` 通过 `kubectl version` 检索服务器版本。 +* `/swaggerapi/*` 用于创建 / 更新操作。 -要检查涉及到特定kubectl操作的HTTP调用,您可以调整详细程度: +要检查涉及到特定 kubectl 操作的 HTTP 调用,您可以调整详细程度: kubectl --v=8 version ## 例子 -1. Alice 可以对所有资源做任何事情: +1. Alice 可以对所有资源做任何事情 : ```json {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}} ``` -2. Kubelet 可以读取任何pod: +2. Kubelet 可以读取任何 pod: ```json {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}} ``` -3. Kubelet 可以读写事件: +3. Kubelet 可以读写事件 : ```json {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}} ``` -4. Bob 可以在命名空间“projectCaribou"中读取 pod: +4. Bob 可以在命名空间 “projectCaribou” 中读取 pod: ```json {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}} ``` -5. 任何人都可以对所有非资源路径进行只读请求: +5. 任何人都可以对所有非资源路径进行只读请求: ```json {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}} @@ -119,7 +119,7 @@ Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服 ## 服务帐户的快速说明 -服务帐户自动生成用户。 用户名是根据命名约定生成的: +服务帐户自动生成用户。 用户名是根据命名约定生成的: ```shell system:serviceaccount:: @@ -130,13 +130,13 @@ system:serviceaccount:: system:serviceaccount::default ``` -例如,如果要将 API 的 kube-system 完整权限中的默认服务帐户授予,则可以将此行添加到策略文件中: +例如,如果要将 API 的 kube-system 完整权限中的默认服务帐户授予,则可以将此行添加到策略文件中 : ```json {"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}} ``` -需要重新启动 apiserver 以获取新的策略行. +需要重新启动 apiserver 以获取新的策略行。 {{% /capture %}} diff --git a/content/zh/docs/admin/authorization/webhook.md b/content/zh/docs/admin/authorization/webhook.md index e80fed7dc2..c82049f8d3 100644 --- a/content/zh/docs/admin/authorization/webhook.md +++ b/content/zh/docs/admin/authorization/webhook.md @@ -29,10 +29,10 @@ WebHook 是一种 HTTP 回调:某些条件下触发的 HTTP POST 请求;通 clusters: - name: name-of-remote-authz-service cluster: - certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的CA。 + certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的 CA。 server: https://authz.example.com/authorize # 远程服务的查询 URL. 必须使用 'https'。 -# users 代表 API 服务器的 webhook 配置. +# users 代表 API 服务器的 webhook 配置 . users: - name: name-of-api-server user: @@ -55,7 +55,7 @@ contexts: 需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从 [版本兼容规则](/docs/api/) 。 实施人员应该了解 beta 对象的更宽松的兼容性承诺,同时确认请求的 "apiVersion" 字段以确保能被正确地反序列化。 -此外,API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组(`--runtime-config=authorization.k8s.io/v1beta1=true`)。 +此外,API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 一个请求内容的例子: diff --git a/content/zh/docs/admin/bootstrap-tokens.md b/content/zh/docs/admin/bootstrap-tokens.md index ced000932d..77ca6f32d5 100644 --- a/content/zh/docs/admin/bootstrap-tokens.md +++ b/content/zh/docs/admin/bootstrap-tokens.md @@ -15,8 +15,8 @@ Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。 启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`),并存在于 `kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。 -控制器管理器中的控制器TokenCleaner能够删除过期的令牌。在节点发现的过程中Kubernetes会使用特殊的ConfigMap对象。 -控制器管理器中的BootstrapSigner控制器也会使用启动引导令牌为这类对象生成签名信息。 +控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。在节点发现的过程中 Kubernetes 会使用特殊的 ConfigMap 对象。 +控制器管理器中的 BootstrapSigner 控制器也会使用启动引导令牌为这类对象生成签名信息。 目前,启动引导令牌处于 **alpha** 阶段,但是预期也不会有大的突破性变化。 @@ -26,7 +26,7 @@ Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。 更加规范地说,它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。 令牌的第一部分是 "Token ID" ,它是公共信息。用于引用某个令牌,并确保不会泄露认证所使用的秘密信息。 -第二部分是 "令牌秘密(Token Secret)",它应该被共享给收信的第三方。 +第二部分是“令牌秘密(Token Secret)”,它应该被共享给收信的第三方。 ## 启用启动引导令牌 @@ -82,19 +82,19 @@ TokenCleaner 控制器会删除过期的令牌。 ## 使用 `kubeadm` 管理令牌 -你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群(`/etc/kubernetes/admin.conf`) +你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群(`/etc/kubernetes/admin.conf`) 自动抓取默认管理员密码。你可以通过参数 `--kubeconfig` 对下面命令指定一个另外的 kubeconfig 文件抓取密码。 * `kubeadm token list` 列举了令牌,同时显示了它们的过期时间和用途。 * `kubeadm token create` 创建一个新令牌。 * `--description` 设置新令牌的描述。 - * `--ttl duration` 设置令牌从 "现在" 起到过期时间的差值。 + * `--ttl duration` 设置令牌从“现在”起到过期时间的差值。 默认是 0 ,也就是不过期。 * `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。 * `kubeadm token delete |.` 删除令牌。 令牌可以只用 ID 来确认,也可以用整个令牌的值。如果只用 ID 的情况下,密文不匹配的令牌也会被删除。 -### ConfigMap签名 +### ConfigMap 签名 除了认证之外,令牌可以用于签名 ConfigMap。这在集群启动过程的早期,在客户端信任 API 服务器之前被使用。 被签名的 ConfigMap 可以通过共享令牌被认证。 @@ -131,6 +131,6 @@ ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件 这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。 签名是一个 JWS 签名,使用了 "detached" 模式。为了检验签名,用户应该按照 JWS 规则 -(base64 编码而忽略结尾的 `=`)对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间 +(base64 编码而忽略结尾的 `=`)对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间 ,用于形成一个完整的 JWS。可以使用令牌的完整信息(比如 `07401b.f395accd246ae52d`)作为共享密钥, 通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。 diff --git a/content/zh/docs/admin/cluster-large.md b/content/zh/docs/admin/cluster-large.md index b84e2477d4..c8ebad97ef 100644 --- a/content/zh/docs/admin/cluster-large.md +++ b/content/zh/docs/admin/cluster-large.md @@ -7,12 +7,12 @@ title: 创建大规模集群 ## 支持规格 -在 {{< param "version" >}},Kubernetes支持最多5000节点规模的集群。 更具体地说,我们支持满足以下 *所有* 标准的配置: +在 {{< param "version" >}},Kubernetes 支持最多 5000 节点规模的集群。 更具体地说,我们支持满足以下 *所有* 标准的配置: -* 不超过5000节点 -* 总共不超过15000个pod -* 总共不超过300000个容器 -* 每个节点不超过100个pod +* 不超过 5000 节点 +* 总共不超过 15000 个 pod +* 总共不超过 300000 个容器 +* 每个节点不超过 100 个 pod
@@ -21,64 +21,64 @@ title: 创建大规模集群 ## 创建 -集群是一组运行Kubernetes代理组件的节点(物理或虚拟机),它们被 "master" (集群管理平面)所管理。 +集群是一组运行 Kubernetes 代理组件的节点(物理或虚拟机),它们被 `master`(集群管理平面)所管理。 -一般来说,集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制,(例如,详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。 +一般来说,集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制,(例如,详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。 -对很多云提供商来说,单纯地修改`NUM_NODES` 为一个非常大的值,可能会导致集群的创建脚本失败。 例如,在GCE中部署时,会因配额不足,导致集群启动失败。 +对很多云提供商来说,单纯地修改 `NUM_NODES` 为一个非常大的值,可能会导致集群的创建脚本失败。 例如,在 GCE 中部署时,会因配额不足,导致集群启动失败。 -当建立一个大型的Kubernetes集群,以下几个问题必须考虑。 +当建立一个大型的 Kubernetes 集群,以下几个问题必须考虑。 ### 配额问题 为了避免出现配额问题,当创建包含大量节点的集群时,考虑: -* 提高相关配额,如CPU,IP等。 - * 如,在 [GCE](https://cloud.google.com/compute/docs/resource-quotas)中,你可能需要提高以下资源的配额: +* 提高相关配额,如 CPU,IP 等。 + * 如,在 [GCE](https://cloud.google.com/compute/docs/resource-quotas) 中,你可能需要提高以下资源的配额: * CPU * 虚机实例 * 磁盘 - * 使用的IP地址 + * 使用的 IP 地址 * 防火墙规则 * 转发规则 * 路由 * 对象池 * 设置创建脚本,使其以较小的规模分批次拉起新的节点,并在其间设置一定的等待时间,因为一些云供应商可能对虚机的创建速率进行了限制。 -### Etcd存储 +### Etcd 存储 -为了提升大规模集群的性能,我们将事件对象存储到独立的etcd实例中。 +为了提升大规模集群的性能,我们将事件对象存储到独立的 etcd 实例中。 -创建集群时,当前的salt脚本: +创建集群时,当前的 salt 脚本: -* 启动并配置额外的etcd实例 -* 配置api-server,将该etcd实例用于事件对象的存储 +* 启动并配置额外的 etcd 实例 +* 配置 api-server,将该 etcd 实例用于事件对象的存储 ### 管理节点和组件的规格 -在 GCE/Google Kubernetes Engine 或 AWS平台中, `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上,用户需要手动配置。 作为参考,GCE使用的规格为: +在 GCE/Google Kubernetes Engine 或 AWS 平台中, `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上,用户需要手动配置。 作为参考,GCE 使用的规格为: * 1-5 节点: n1-standard-1 * 6-10 节点: n1-standard-2 * 11-100 节点: n1-standard-4 * 101-250 节点: n1-standard-8 * 251-500 节点: n1-standard-16 -* 500节点以上: n1-standard-32 +* 500 节点以上: n1-standard-32 -AWS使用的规格为: +AWS 使用的规格为: * 1-5 节点: m3.medium * 6-10 节点: m3.large * 11-100 节点: m3.xlarge * 101-250 节点: m3.2xlarge * 251-500 节点: c4.4xlarge -* 500节点以上: c4.8xlarge +* 500 节点以上: c4.8xlarge -注意,管理节点的规格只会在集群创建时进行设置,后续集群规模发生变化 (如 手动增删节点或集群自动扩缩容)后不会再调整。 +注意,管理节点的规格只会在集群创建时进行设置,后续集群规模发生变化(如手动增删节点或集群自动扩缩容)后不会再调整。 ### 插件的资源占用 -为防止 [集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) 耗尽节点资源引起内存泄漏或其他资源问题, Kubernetes 设置了插件容器资源的上限,来限制其对CPU和内存资源的占用 (参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files))。 +为防止[集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)耗尽节点资源引起内存泄漏或其他资源问题, Kubernetes 设置了插件容器资源的上限,来限制其对 CPU 和内存资源的占用(参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files))。 例如: @@ -92,31 +92,31 @@ AWS使用的规格为: memory: 200Mi ``` -除 Heapster 外,这些限制是静态的,基于4个节点规模的集群上运行的插件所采集的数据 (详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多 (详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整,插件可能会因为资源占用达到上限而不断被杀死。 +除 Heapster 外,这些限制是静态的,基于 4 个节点规模的集群上运行的插件所采集的数据(详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多(详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整,插件可能会因为资源占用达到上限而不断被杀死。 为了避免集群插件的资源问题,创建多节点的集群时,考虑以下几点: -* 当扩大集群规模时,如果涉及,相应扩大以下插件的内存和CPU限制 (通过一个实例处理整个集群,因此其内存和CPU使用量往往与集群的大小/负载成比例增长): +* 当扩大集群规模时,如果涉及,相应扩大以下插件的内存和 CPU 限制(通过一个实例处理整个集群,因此其内存和 CPU 使用量往往与集群的大小/负载成比例增长): * [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) * [kubedns, dnsmasq, 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kubedns-controller.yaml.in) * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml) -* 当扩大集群规模时,如果涉及,相应扩大以下插件副本数 (每个组件有多个副本,因此增加副本将有助于处理增加的负载,但是,由于每个副本的负载也略有增加,也应考虑提高CPU /内存上限): +* 当扩大集群规模时,如果涉及,相应扩大以下插件副本数(每个组件有多个副本,因此增加副本将有助于处理增加的负载,但是,由于每个副本的负载也略有增加,也应考虑提高 CPU / 内存上限): * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml) -* 当扩大集群规模时,如果涉及,略微扩大以下插件的内存和CPU限制 (每个节点一个副本, 但是CPU/内存使用随集群的大小/负载增长变化不明显): +* 当扩大集群规模时,如果涉及,略微扩大以下插件的内存和 CPU 限制(每个节点一个副本, 但是 CPU / 内存使用随集群的大小/负载增长变化不明显): * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) -Heapster的资源限制是基于集群的初始规模动态设置的 (参考 [#16185](http://issue.k8s.io/16185) -和 [#22940](http://issue.k8s.io/22940))。 当发现Heapster资源耗尽,应考虑调整计算Heapster内存请求的公式 (参考上述PR)。 +Heapster 的资源限制是基于集群的初始规模动态设置的 ( 参考 [#16185](http://issue.k8s.io/16185) +和 [#22940](http://issue.k8s.io/22940))。 当发现 Heapster 资源耗尽,应考虑调整计算 Heapster 内存请求的公式(参考上述 PR)。 关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。 [将来](http://issue.k8s.io/13048),我们期望基于集群规模来设置集群插件的资源限制,并且在集群规模增长或缩小时能够动态调整。 -欢迎提出PR来实现这些特性。 +欢迎提出 PR 来实现这些特性。 ### 启动时允许部分失败 -因为种种原因 (详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969)),在 `NUM_NODES` 值很大的情况下执行 +因为种种原因(详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969)),在 `NUM_NODES` 值很大的情况下执行 `kube-up.sh`, 可能因为其中一小部分节点没有正常启动而失败。 -这时我们有两种选择:重启集群 (`kube-down.sh` 然后再 `kube-up.sh`),或者在执行 `kube-up.sh`之前, +这时我们有两种选择:重启集群(`kube-down.sh` 然后再 `kube-up.sh`),或者在执行 `kube-up.sh` 之前, 将环境变量 `ALLOWED_NOTREADY_NODES` 设置为合适的值。 这将允许 `kube-up.sh` 以少于 `NUM_NODES` 的节点数量启动集群。 依据失败的具体原因,另外的节点可能在后面加入集群,或者集群节点数量将保持在 `NUM_NODES - ALLOWED_NOTREADY_NODES`。 diff --git a/content/zh/docs/admin/high-availability/_index.md b/content/zh/docs/admin/high-availability/_index.md index d0f624c812..4d854b8daf 100644 --- a/content/zh/docs/admin/high-availability/_index.md +++ b/content/zh/docs/admin/high-availability/_index.md @@ -6,12 +6,12 @@ title: 构建高可用集群 ## 简介 -本文描述了如何构建一个高可用(high-availability, HA)的Kubernetes集群。这是一个非常高级的主题。 +本文描述了如何构建一个高可用(high-availability, HA)的 Kubernetes 集群。这是一个非常高级的主题。 -对于仅希望使用Kubernetes进行试验的用户,推荐使用更简单的配置工具进行搭建,例如: -[Minikube](/docs/getting-started-guides/minikube/),或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行Kubernetes。 +对于仅希望使用 Kubernetes 进行试验的用户,推荐使用更简单的配置工具进行搭建,例如: +[Minikube](/docs/getting-started-guides/minikube/),或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行 Kubernetes。 -此外,当前在我们的端到端(e2e)测试环境中,没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项,但当前对单节点master的安装测试得更加严格。 +此外,当前在我们的端到端(e2e)测试环境中,没有对 Kubernetes 高可用的支持进行连续测试。我们将会增加这个连续测试项,但当前对单节点 master 的安装测试得更加严格。 {{< toc >}} @@ -23,10 +23,10 @@ title: 构建高可用集群 相关步骤如下: - * [创建可靠的组成节点,共同形成我们的高可用主节点实现。](#可靠的节点) - * [使用etcd集群,搭建一个冗余的,可靠的存储层。](#建立一个冗余的,可靠的存储层) - * [启动具有备份和负载均衡能力的Kubernetes API 服务](#复制的API服务) - * [搭建运行master选举的Kubernetes scheduler和controller-manager守护程序](#进行master选举的组件) + * [创建可靠的组成节点,共同形成我们的高可用主节点实现。](# 可靠的节点 ) + * [使用 etcd 集群,搭建一个冗余的,可靠的存储层。](# 建立一个冗余的,可靠的存储层 ) + * [启动具有备份和负载均衡能力的 Kubernetes API 服务](# 复制的 API 服务 ) + * [搭建运行 master 选举的 Kubernetes scheduler 和 controller-manager 守护程序](# 进行 master 选举的组件 ) 系统完成时看起来应该像这样: @@ -36,28 +36,28 @@ title: 构建高可用集群 ## 初始配置 -本文假设你正在搭建一个3节点的主节点集群,每个节点上都运行者某种Linux系统。 +本文假设你正在搭建一个 3 节点的主节点集群,每个节点上都运行者某种 Linux 系统。 -指南中的示例使用Debian发行版,但它们应该可以被轻松移植到其他发行版上。 +指南中的示例使用 Debian 发行版,但它们应该可以被轻松移植到其他发行版上。 同样的,不管在公有云还是私有云亦或是裸机上,这个配置都应该可以运行。 -从一个现成的单主节点集群开始是实现一个高可用Kubernetes集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。 +从一个现成的单主节点集群开始是实现一个高可用 Kubernetes 集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。 ## 可靠的节点 -我们在每个主节点上都将运行数个实现Kubernetes API的进程。使他们可靠的第一步是保证在发生故障时,每一个进程都可以自动重启。为了实现这个目标,我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的`kubelet`进程。这会带来便利性,因为我们使用了容器来分发我们的二进制文件,所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然,我们也需要一些手段来监控kubelete本身(在此监测监控者本身是一个有趣的话题)。对于Debian系统我们选择了monit,但也有许多可替代的工具。例如在基于systemd的系统上(如RHEL, CentOS),你可以运行 'systemctl enable kubelet'。 +我们在每个主节点上都将运行数个实现 Kubernetes API 的进程。使他们可靠的第一步是保证在发生故障时,每一个进程都可以自动重启。为了实现这个目标,我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的 `kubelet` 进程。这会带来便利性,因为我们使用了容器来分发我们的二进制文件,所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然,我们也需要一些手段来监控 kubelete 本身(在此监测监控者本身是一个有趣的话题)。对于 Debian 系统我们选择了 monit,但也有许多可替代的工具。例如在基于 systemd 的系统上(如 RHEL, CentOS),你可以运行 'systemctl enable kubelet'。 -如果你是从标准的Kubernetes安装扩展而来,那么`kubelet`二进制文件应该已经存在于你的系统中。你可以运行`which kubelet`来判断是否确实安装了这个二进制文件。如果没有安装的话,你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), -[kubelet init file](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet)脚本。 +如果你是从标准的 Kubernetes 安装扩展而来,那么 `kubelet` 二进制文件应该已经存在于你的系统中。你可以运行 `which kubelet` 来判断是否确实安装了这个二进制文件。如果没有安装的话,你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), +[kubelet init file](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet) 脚本。 -如果使用monit,你还需要安装monit守护程序(`apt-get install monit`)以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和 +如果使用 monit,你还需要安装 monit 守护程序(`apt-get install monit`)以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和 [monit-docker](/docs/admin/high-availability/monit-docker) 配置。 -在使用systemd的系统上,你可以执行 `systemctl enable kubelet` 和 `systemctl enable docker`。 +在使用 systemd 的系统上,你可以执行 `systemctl enable kubelet` 和 `systemctl enable docker`。 ## 建立一个冗余的,可靠的存储层 @@ -66,35 +66,35 @@ title: 构建高可用集群 高可用方案的中心基础是一个冗余的,可靠的存储层。高可用的头条规则是保护数据。不管发生了什么,不管什么着了火,只要还有数据,你就可以重建。如果丢掉了数据,你就完了。 -集群化的etcd已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据,三个节点的物理(或虚拟)硬盘需要全部同时故障。这种情况发生的概率是比较低的,所以对于许多人来说,运行一个复制的etcd集群可能已经足够的可靠了。你可以将集群数量从3个增大到5个来增加集群的可靠性。如果那样还不够,你可以添加[更多的可靠性到你的存储层](#更加可靠的存储)。 +集群化的 etcd 已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据,三个节点的物理(或虚拟)硬盘需要全部同时故障。这种情况发生的概率是比较低的,所以对于许多人来说,运行一个复制的 etcd 集群可能已经足够的可靠了。你可以将集群数量从 3 个增大到 5 个来增加集群的可靠性。如果那样还不够,你可以添加[更多的可靠性到你的存储层](# 更加可靠的存储 )。 -### 集群化etcd +### 集群化 etcd -集群化etcd的完整细节超出了本文范围,你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md)找到许多详细内容。这个例子仅走查一个简单的集群建立过程,使用etcd内置的发现功能来构建我们的集群。 +集群化 etcd 的完整细节超出了本文范围,你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md) 找到许多详细内容。这个例子仅走查一个简单的集群建立过程,使用 etcd 内置的发现功能来构建我们的集群。 -首先,调用etcd发现服务来创建一个新令牌: +首先,调用 etcd 发现服务来创建一个新令牌 : ```shell curl https://discovery.etcd.io/new?size=3 ``` -在每个节点上,拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到`/etc/kubernetes/manifests/etcd.yaml`。 +在每个节点上,拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到 `/etc/kubernetes/manifests/etcd.yaml`。 -每个节点上的kubelet会动态的监控这个文件夹的内容,并且会按照`etcd.yaml`里对pod的定义创建一个`etcd`服务的实例。 +每个节点上的 kubelet 会动态的监控这个文件夹的内容,并且会按照 `etcd.yaml` 里对 pod 的定义创建一个 `etcd` 服务的实例。 -请注意,你应该使用上文中获取的令牌URL替换全部三个节点上`etcd.yaml`中的`${DISCOVERY_TOKEN}`项。同时还应该将每个节点上的 `${NODE_NAME}`替换为一个不同的名字(例如:`node-1`),并将 `${NODE_IP}`替换为正确的IP地址。 +请注意,你应该使用上文中获取的令牌 URL 替换全部三个节点上 `etcd.yaml` 中的 `${DISCOVERY_TOKEN}` 项。同时还应该将每个节点上的 `${NODE_NAME}` 替换为一个不同的名字(例如:`node-1`),并将 `${NODE_IP}` 替换为正确的 IP 地址。 #### 验证你的集群 -如果已经将这个文件拷贝到所有三个节点,你应该已经搭建起了一个集群化的etcd。你可以在主节点上进行验证: +如果已经将这个文件拷贝到所有三个节点,你应该已经搭建起了一个集群化的 etcd。你可以在主节点上进行验证: ```shell kubectl exec < pod_name > etcdctl member list ``` @@ -106,43 +106,43 @@ kubectl exec < pod_name > etcdctl cluster-health ``` -你也可以在一个节点上运行 `etcdctl set foo bar`,在另一个节点上运行`etcdctl get foo`来验证集群是否工作正常。 +你也可以在一个节点上运行 `etcdctl set foo bar`,在另一个节点上运行 `etcdctl get foo` 来验证集群是否工作正常。 ### 更加可靠的存储 -当然,如果你对增加数据的可靠性感兴趣,这里还有一些更深入的选项可以使etcd把它的数据存放在比常规硬盘更可靠的地方(裤带和背带,ftw!)。 +当然,如果你对增加数据的可靠性感兴趣,这里还有一些更深入的选项可以使 etcd 把它的数据存放在比常规硬盘更可靠的地方(裤带和背带,ftw!)。 -如果你使用云服务,那么你的提供商通常会为你提供这个特性,例如Google Cloud Platform上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。 +如果你使用云服务,那么你的提供商通常会为你提供这个特性,例如 Google Cloud Platform 上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。 -如果运行于物理机之上,你仍然可以使用iSCSI或者NFS接口通过网络来连接冗余存储。 -此外,你还可以运行一个集群文件系统,比如Gluster或者Ceph。最后,你还可以在你的每个物理机器上运行RAID矩阵。 +如果运行于物理机之上,你仍然可以使用 iSCSI 或者 NFS 接口通过网络来连接冗余存储。 +此外,你还可以运行一个集群文件系统,比如 Gluster 或者 Ceph。最后,你还可以在你的每个物理机器上运行 RAID 矩阵。 -不管你选择如何实现,如果已经选择了使用其中的一个选项,那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享,那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导,我们都假设这个存储被挂载到你机器上的`/var/etcd/data`路径。 +不管你选择如何实现,如果已经选择了使用其中的一个选项,那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享,那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导,我们都假设这个存储被挂载到你机器上的 `/var/etcd/data` 路径。 -## 复制的API服务 +## 复制的 API 服务 -在正确搭建复制的etcd之后,我们还需要使用kubelet安装apiserver。 +在正确搭建复制的 etcd 之后,我们还需要使用 kubelet 安装 apiserver。 -首先,你需要创建初始的日志文件,这样Docker才会挂载一个文件而不是一个文件夹: +首先,你需要创建初始的日志文件,这样 Docker 才会挂载一个文件而不是一个文件夹: ```shell touch /var/log/kube-apiserver.log ``` -接下来,你需要在每个节点上创建一个`/srv/kubernetes/`文件夹。这个文件夹包含: +接下来,你需要在每个节点上创建一个 `/srv/kubernetes/` 文件夹。这个文件夹包含: * basic_auth.csv - 基本认证的用户名和密码 - * ca.crt - CA证书 - * known_tokens.csv - 实体(例如kubelet)用来和apiserver通信的令牌 + * ca.crt - CA 证书 + * known_tokens.csv - 实体(例如 kubelet)用来和 apiserver 通信的令牌 * kubecfg.crt - 客户端证书,公钥 * kubecfg.key - 客户端证书,私钥 * server.cert - 服务端证书,公钥 @@ -152,46 +152,46 @@ touch /var/log/kube-apiserver.log 创建这个文件夹最简单的方法可以是从一个工作正常的集群的主节点拷贝,或者你也可以手动生成它们。 -### 启动API服务 +### 启动 API 服务 -一旦这些文件已经存在了,拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/`文件夹。 +一旦这些文件已经存在了,拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/` 文件夹。 -kubelet会监控这个文件夹,并且会按照文件里对pod的定义创建一个`kube-apiserver`容器。 +kubelet 会监控这个文件夹,并且会按照文件里对 pod 的定义创建一个 `kube-apiserver` 容器。 ### 负载均衡 -现在,你应该有3个全部正常工作的apiserver了。如果搭建了网络负载均衡器,你应该能够通过那个负载均衡器访问你的集群,并且看到负载在apiserver实例间分发。设置负载均衡器依赖于你的平台的实际情况,例如对于Google Cloud Platform的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/)找到。 +现在,你应该有 3 个全部正常工作的 apiserver 了。如果搭建了网络负载均衡器,你应该能够通过那个负载均衡器访问你的集群,并且看到负载在 apiserver 实例间分发。设置负载均衡器依赖于你的平台的实际情况,例如对于 Google Cloud Platform 的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/) 找到。 -请注意,如果使用了身份认证,你可能需要重新生成你的证书,除每个节点的IP地址外额外包含负载均衡器的IP地址。 +请注意,如果使用了身份认证,你可能需要重新生成你的证书,除每个节点的 IP 地址外额外包含负载均衡器的 IP 地址。 -对于部署在集群中的pods, `kubernetes`服务/dns名称应该自动的为主节点提供了负载均衡的endpoint。 +对于部署在集群中的 pods, `kubernetes` 服务 /dns 名称应该自动的为主节点提供了负载均衡的 endpoint。 -对于使用API的外部用户(如命令行运行的`kubectl`,持续集成管道或其他客户端)你会希望将他们配置成为访问外部负载均衡器的地址。 +对于使用 API 的外部用户(如命令行运行的 `kubectl`,持续集成管道或其他客户端)你会希望将他们配置成为访问外部负载均衡器的地址。 -## 进行Master选举的组件 +## 进行 Master 选举的组件 -到目前为止,我们已经搭建了状态存储,也搭建好了API服务,但我们还没有运行任何真正改变集群状态的服务,比如controller manager和scheduler。为了可靠的实现这个目标,我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点,我们打算在API中使用一个lease-lock来执行master选举。我们会对每一个scheduler和controller-manager使用`--leader-elect`标志,从而在API中使用一个租约来保证同一时间只有一个scheduler和controller-manager的实例正在运行。 +到目前为止,我们已经搭建了状态存储,也搭建好了 API 服务,但我们还没有运行任何真正改变集群状态的服务,比如 controller manager 和 scheduler。为了可靠的实现这个目标,我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点,我们打算在 API 中使用一个 lease-lock 来执行 master 选举。我们会对每一个 scheduler 和 controller-manager 使用 `--leader-elect` 标志,从而在 API 中使用一个租约来保证同一时间只有一个 scheduler 和 controller-manager 的实例正在运行。 -scheduler和controller-manager可以配置为只和位于它们相同节点(即127.0.0.1)上的API服务通信,也可以配置为使用API服务的负载均衡器的IP地址。不管它们如何配置,当使用`--leader-elect` 时scheduler和controller-manager都将完成上文提到的leader选举过程。 +scheduler 和 controller-manager 可以配置为只和位于它们相同节点(即 127.0.0.1)上的 API 服务通信,也可以配置为使用 API 服务的负载均衡器的 IP 地址。不管它们如何配置,当使用 `--leader-elect` 时 scheduler 和 controller-manager 都将完成上文提到的 leader 选举过程。 -为了防止访问API服务失败,选举出的leader不能通过更新租约来选举一个新的leader。当scheduler和controller-manager通过127.0.0.1访问API服务,而相同节点上的API服务不可用时,这一点相当重要。 +为了防止访问 API 服务失败,选举出的 leader 不能通过更新租约来选举一个新的 leader。当 scheduler 和 controller-manager 通过 127.0.0.1 访问 API 服务,而相同节点上的 API 服务不可用时,这一点相当重要。 ### 安装配置文件 -首先,在每个节点上创建空白日志文件,这样Docker就会挂载这些文件而不是创建一个新文件夹: +首先,在每个节点上创建空白日志文件,这样 Docker 就会挂载这些文件而不是创建一个新文件夹: ```shell touch /var/log/kube-scheduler.log @@ -199,16 +199,16 @@ touch /var/log/kube-controller-manager.log ``` -接下来,在每个节点上配置scheduler和controller manager pods的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到`/etc/kubernetes/manifests/` 文件夹。 +接下来,在每个节点上配置 scheduler 和 controller manager pods 的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到 `/etc/kubernetes/manifests/` 文件夹。 ## 结尾 -此时,你已经完成了master组件的配置(耶!),但你还需要添加工作者节点(噗!)。 +此时,你已经完成了 master 组件的配置(耶!),但你还需要添加工作者节点(噗!)。 -如果你有一个现成的集群,你只需要在每个节点上简单的重新配置你的kubeletes连接到负载均衡的endpoint并重启它们。 +如果你有一个现成的集群,你只需要在每个节点上简单的重新配置你的 kubeletes 连接到负载均衡的 endpoint 并重启它们。 -如果你搭建的是一个全新的集群,你将需要在每个工作节点上安装kubelet和kube-proxy,并设置 `--apiserver`指向复制的endpoint。 \ No newline at end of file +如果你搭建的是一个全新的集群,你将需要在每个工作节点上安装 kubelet 和 kube-proxy,并设置 `--apiserver` 指向复制的 endpoint。 \ No newline at end of file diff --git a/content/zh/docs/admin/kube-apiserver.md b/content/zh/docs/admin/kube-apiserver.md index 53b9836812..f24899755f 100644 --- a/content/zh/docs/admin/kube-apiserver.md +++ b/content/zh/docs/admin/kube-apiserver.md @@ -9,7 +9,7 @@ notitle: true ### 概要 -Kubernetes API server 为 api 对象验证并配置数据,包括 pods、 services、 replicationcontrollers和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端,所有其他组件通过它进行交互。 +Kubernetes API server 为 api 对象验证并配置数据,包括 pods、 services、 replicationcontrollers 和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端,所有其他组件通过它进行交互。 ``` kube-apiserver @@ -18,99 +18,99 @@ kube-apiserver ### 选项 ``` - --admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的NamespaceLifecycle列表。(默认值[AlwaysAdmit]) + --admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的 NamespaceLifecycle 列表。(默认值 [AlwaysAdmit]) --admission-control-config-file string 包含准入控制配置的文件。 - --advertise-address ip 向集群成员通知apiserver消息的IP地址。这个地址必须能够被集群中其他成员访问。如果IP地址为空,将会使用--bind-address,如果未指定--bind-address,将会使用主机的默认接口地址。 + --advertise-address ip 向集群成员通知 apiserver 消息的 IP 地址。这个地址必须能够被集群中其他成员访问。如果 IP 地址为空,将会使用 --bind-address,如果未指定 --bind-address,将会使用主机的默认接口地址。 - --allow-privileged 如果为true, 将允许特权容器. + --allow-privileged 如果为 true, 将允许特权容器。 - --anonymous-auth 启用到API server的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为system:anonymous,用户组名为system:unauthenticated。(默认值true) + --anonymous-auth 启用到 API server 的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为 system:anonymous,用户组名为 system:unauthenticated。(默认值 true) - --apiserver-count int 集群中运行的apiserver数量,必须为正数。(默认值1) + --apiserver-count int 集群中运行的 apiserver 数量,必须为正数。(默认值 1) --audit-log-maxage int 基于文件名中的时间戳,旧审计日志文件的最长保留天数。 - --audit-log-maxbackup int 旧审计日志文件的最大保留个数. + --audit-log-maxbackup int 旧审计日志文件的最大保留个数。 --audit-log-maxsize int 审计日志被轮转前的最大兆字节数。 - --audit-log-path string 如果设置该值,所有到apiserver的请求都将会被记录到这个文件。'-'表示记录到标准输出。 + --audit-log-path string 如果设置该值,所有到 apiserver 的请求都将会被记录到这个文件。'-' 表示记录到标准输出。 - --audit-policy-file string 定义审计策略配置的文件的路径。需要打开'AdvancedAuditing'特性开关。AdvancedAuditing需要一个配置来启用审计功能。 + --audit-policy-file string 定义审计策略配置的文件的路径。需要打开 'AdvancedAuditing' 特性开关。AdvancedAuditing 需要一个配置来启用审计功能。 - --audit-webhook-config-file string 一个具有kubeconfig格式文件的路径,该文件定义了审计的webhook配置。需要打开'AdvancedAuditing'特性开关。 + --audit-webhook-config-file string 一个具有 kubeconfig 格式文件的路径,该文件定义了审计的 webhook 配置。需要打开 'AdvancedAuditing' 特性开关。 - --audit-webhook-mode string 发送审计事件的策略。 Blocking模式表示正在发送事件时应该阻塞服务器的响应。 Batch模式使webhook异步缓存和发送事件。 Known模式为batch,blocking。 (默认值"batch") + --audit-webhook-mode string 发送审计事件的策略。 Blocking 模式表示正在发送事件时应该阻塞服务器的响应。 Batch 模式使 webhook 异步缓存和发送事件。 Known 模式为 batch,blocking。(默认值 "batch") - --authentication-token-webhook-cache-ttl duration 从webhook令牌认证者获取的响应的缓存时长。(默认值2m0s) + --authentication-token-webhook-cache-ttl duration 从 webhook 令牌认证者获取的响应的缓存时长。( 默认值 2m0s) - --authentication-token-webhook-config-file string 包含webhook配置的文件,用于令牌认证,具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。 + --authentication-token-webhook-config-file string 包含 webhook 配置的文件,用于令牌认证,具有 kubeconfig 格式。API server 将查询远程服务来决定对 bearer 令牌的认证。 - --authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表,包括:AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.(默认值"AlwaysAllow") + --authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表,包括:AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.(默认值 "AlwaysAllow") - --authorization-policy-file string 包含权限验证策略的csv文件,和--authorization-mode=ABAC一起使用,作用在安全端口上。 + --authorization-policy-file string 包含权限验证策略的 csv 文件,和 --authorization-mode=ABAC 一起使用,作用在安全端口上。 - --authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。(默认值5m0s) + --authorization-webhook-cache-authorized-ttl duration 从 webhook 授权者获得的 'authorized' 响应的缓存时长。(默认值 5m0s) - --authorization-webhook-cache-unauthorized-ttl duration 从webhook授权者获得的'unauthorized'响应的缓存时长。(默认值30s) + --authorization-webhook-cache-unauthorized-ttl duration 从 webhook 授权者获得的 'unauthorized' 响应的缓存时长。(默认值 30s) - --authorization-webhook-config-file string 包含webhook配置的kubeconfig格式文件,和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。 + --authorization-webhook-config-file string 包含 webhook 配置的 kubeconfig 格式文件,和 --authorization-mode=Webhook 一起使用。API server 将查询远程服务来决定对 API server 安全端口的访问。 - --azure-container-registry-config string 包含Azure容器注册表配置信息的文件的路径。 + --azure-container-registry-config string 包含 Azure 容器注册表配置信息的文件的路径。 - --basic-auth-file string 如果设置该值,这个文件将会被用于准许通过http基本认证到API server安全端口的请求。 + --basic-auth-file string 如果设置该值,这个文件将会被用于准许通过 http 基本认证到 API server 安全端口的请求。 - --bind-address ip 监听--seure-port的IP地址。被关联的接口必须能够被集群其它节点和CLI/web客户端访问。如果为空,则将使用所有接口(0.0.0.0)。(默认值0.0.0.0) + --bind-address ip 监听 --seure-port 的 IP 地址。被关联的接口必须能够被集群其它节点和 CLI/web 客户端访问。如果为空,则将使用所有接口(0.0.0.0)。(默认值 0.0.0.0) - --cert-dir string 存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项,该标志将被忽略。(默认值 "/var/run/kubernetes") + --cert-dir string 存放 TLS 证书的目录。如果提供了 --tls-cert-file 和 --tls-private-key-file 选项,该标志将被忽略。(默认值 "/var/run/kubernetes") - --client-ca-file string 如果设置此标志,对于任何请求,如果存包含client-ca-file中的authorities签名的客户端证书,将会使用客户端证书中的CommonName对应的身份进行认证。 + --client-ca-file string 如果设置此标志,对于任何请求,如果存包含 client-ca-file 中的 authorities 签名的客户端证书,将会使用客户端证书中的 CommonName 对应的身份进行认证。 - --cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件. + --cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件 . --cloud-provider string 云服务提供商,空字符串表示无提供商。 - --contention-profiling 如果已经启用profiling,则启用锁竞争profiling。 + --contention-profiling 如果已经启用 profiling,则启用锁竞争 profiling。 - --cors-allowed-origins stringSlice CORS的域列表,以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS. + --cors-allowed-origins stringSlice CORS 的域列表,以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用 CORS. - --delete-collection-workers int 用于DeleteCollection调用的工作者数量。这被用于加速namespace的清理。(默认值1) + --delete-collection-workers int 用于 DeleteCollection 调用的工作者数量。这被用于加速 namespace 的清理。( 默认值 1) - --deserialization-cache-size int 在内存中缓存的反序列化json对象的数量。 + --deserialization-cache-size int 在内存中缓存的反序列化 json 对象的数量。 - --enable-aggregator-routing 打开到endpoints IP的aggregator路由请求,替换cluster IP。 + --enable-aggregator-routing 打开到 endpoints IP 的 aggregator 路由请求,替换 cluster IP。 - --enable-garbage-collector 启用通用垃圾回收器. 必须与kube-controller-manager对应的标志保持同步。 (默认值true) + --enable-garbage-collector 启用通用垃圾回收器 . 必须与 kube-controller-manager 对应的标志保持同步。 (默认值 true) - --enable-logs-handler 如果为true,则为apiserver日志功能安装一个/logs处理器。(默认值true) + --enable-logs-handler 如果为 true,则为 apiserver 日志功能安装一个 /logs 处理器。(默认值 true) - --enable-swagger-ui 在apiserver的/swagger-ui路径启用swagger ui。 + --enable-swagger-ui 在 apiserver 的 /swagger-ui 路径启用 swagger ui。 - --etcd-cafile string 用于保护etcd通信的SSL CA文件。 + --etcd-cafile string 用于保护 etcd 通信的 SSL CA 文件。 - --etcd-certfile string 用于保护etcd通信的的SSL证书文件。 + --etcd-certfile string 用于保护 etcd 通信的的 SSL 证书文件。 - --etcd-keyfile string 用于保护etcd通信的SSL密钥文件. + --etcd-keyfile string 用于保护 etcd 通信的 SSL 密钥文件 . - --etcd-prefix string 附加到所有etcd中资源路径的前缀。 (默认值"/registry") + --etcd-prefix string 附加到所有 etcd 中资源路径的前缀。 (默认值 "/registry") - --etcd-quorum-read 如果为true, 启用quorum读。 + --etcd-quorum-read 如果为 true, 启用 quorum 读。 - --etcd-servers stringSlice 连接的etcd服务器列表,形式为(scheme://ip:port),使用逗号分隔。 + --etcd-servers stringSlice 连接的 etcd 服务器列表 , 形式为(scheme://ip:port),使用逗号分隔。 - --etcd-servers-overrides stringSlice 针对单个资源的etcd服务器覆盖配置, 以逗号分隔。 单个配置覆盖格式为: group/resource#servers, 其中servers形式为http://ip:port, 以分号分隔。 + --etcd-servers-overrides stringSlice 针对单个资源的 etcd 服务器覆盖配置 , 以逗号分隔。 单个配置覆盖格式为 : group/resource#servers, 其中 servers 形式为 http://ip:port, 以分号分隔。 - --event-ttl duration 事件驻留时间。(默认值1h0m0s) + --event-ttl duration 事件驻留时间。(默认值 1h0m0s) - --enable-bootstrap-token-auth 启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。 + --enable-bootstrap-token-auth 启用此选项以允许 'kube-system' 命名空间中的 'bootstrap.kubernetes.io/token' 类型密钥可以被用于 TLS 的启动认证。 - --experimental-encryption-provider-config string 包含加密提供程序的配置的文件,该加密提供程序被用于在etcd中保存密钥。 + --experimental-encryption-provider-config string 包含加密提供程序的配置的文件,该加密提供程序被用于在 etcd 中保存密钥。 - --external-hostname string 为此master生成外部URL时使用的主机名(例如Swagger API文档)。 + --external-hostname string 为此 master 生成外部 URL 时使用的主机名 ( 例如 Swagger API 文档 )。 - --feature-gates mapStringBool 一个描述alpha/experimental特性开关的键值对列表。 选项包括: + --feature-gates mapStringBool 一个描述 alpha/experimental 特性开关的键值对列表。 选项包括 : Accelerators=true|false (ALPHA - default=false) AdvancedAuditing=true|false (ALPHA - default=false) AffinityInAnnotations=true|false (ALPHA - default=false) @@ -128,102 +128,102 @@ RotateKubeletServerCertificate=true|false (ALPHA - default=false) StreamingProxyRedirects=true|false (BETA - default=true) TaintBasedEvictions=true|false (ALPHA - default=false) - --google-json-key string 用于认证的Google Cloud Platform服务账号的JSON密钥。 + --google-json-key string 用于认证的 Google Cloud Platform 服务账号的 JSON 密钥。 - --insecure-allow-any-token username/group1,group2 如果设置该值, 你的服务将处于非安全状态。任何令牌都将会被允许,并将从令牌中把用户信息解析成为username/group1,group2。 + --insecure-allow-any-token username/group1,group2 如果设置该值 , 你的服务将处于非安全状态。任何令牌都将会被允许,并将从令牌中把用户信息解析成为 username/group1,group2。 - --insecure-bind-address ip 用于监听--insecure-port的IP地址 (设置成0.0.0.0表示监听所有接口)。(默认值127.0.0.1) + --insecure-bind-address ip 用于监听 --insecure-port 的 IP 地址 ( 设置成 0.0.0.0 表示监听所有接口 )。(默认值 127.0.0.1) - --insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则,使得这个端口不能从集群外访问。对集群的公共地址的443端口的访问将被代理到这个端口。默认设置中使用nginx实现。(默认值8080) + --insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则,使得这个端口不能从集群外访问。对集群的公共地址的 443 端口的访问将被代理到这个端口。默认设置中使用 nginx 实现。(默认值 8080) - --kubelet-certificate-authority string 证书authority的文件路径。 + --kubelet-certificate-authority string 证书 authority 的文件路径。 - --kubelet-client-certificate string 用于TLS的客户端证书文件路径。 + --kubelet-client-certificate string 用于 TLS 的客户端证书文件路径。 - --kubelet-client-key string 用于TLS的客户端证书密钥文件路径. + --kubelet-client-key string 用于 TLS 的客户端证书密钥文件路径 . - --kubelet-https 为kubelet启用https。 (默认值true) + --kubelet-https 为 kubelet 启用 https。 (默认值 true) - --kubelet-preferred-address-types stringSlice 用于kubelet连接的首选NodeAddressTypes列表。 (默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP]) + --kubelet-preferred-address-types stringSlice 用于 kubelet 连接的首选 NodeAddressTypes 列表。 ( 默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP]) - --kubelet-read-only-port uint 已废弃: kubelet端口. (默认值10255) + --kubelet-read-only-port uint 已废弃 : kubelet 端口 . (默认值 10255) - --kubelet-timeout duration kubelet操作超时时间。(默认值 + --kubelet-timeout duration kubelet 操作超时时间。(默认值 5s) - --kubernetes-service-node-port int 如果不为0,Kubernetes master服务(用于创建/管理apiserver)将会使用NodePort类型,并将这个值作为端口号。如果为0,Kubernetes master服务将会使用ClusterIP类型。 + --kubernetes-service-node-port int 如果不为 0,Kubernetes master 服务(用于创建 / 管理 apiserver)将会使用 NodePort 类型,并将这个值作为端口号。如果为 0,Kubernetes master 服务将会使用 ClusterIP 类型。 - --master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。(默认值"default") + --master-service-namespace string 已废弃 : 注入到 pod 中的 kubernetes master 服务的命名空间。(默认值 "default") - --max-connection-bytes-per-sec int 如果不为0,每个用户连接将会被限速为该值(bytes/sec)。当前只应用于长时间运行的请求。 + --max-connection-bytes-per-sec int 如果不为 0,每个用户连接将会被限速为该值(bytes/sec)。当前只应用于长时间运行的请求。 - --max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0值表示没有限制。(默认值200) + --max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0 值表示没有限制。(默认值 200) - --max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0值表示没有限制。(默认值400) + --max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时,服务将拒绝所有请求。0 值表示没有限制。(默认值 400) - --min-request-timeout int 一个可选字段,表示一个handler在一个请求超时前,必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效,它基于这个值选择一个随机数作为连接超时值,以达到分散负载的目的(默认值1800)。 + --min-request-timeout int 一个可选字段,表示一个 handler 在一个请求超时前,必须保持它处于打开状态的最小秒数。当前只对监听请求 handler 有效,它基于这个值选择一个随机数作为连接超时值,以达到分散负载的目的(默认值 1800)。 - --oidc-ca-file string 如果设置该值,将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证,否则将会使用主机的根CA对其进行验证。 + --oidc-ca-file string 如果设置该值,将会使用 oidc-ca-file 中的任意一个 authority 对 OpenID 服务的证书进行验证,否则将会使用主机的根 CA 对其进行验证。 - --oidc-client-id string 使用OpenID连接的客户端的ID,如果设置了oidc-issuer-url,则必须设置这个值。 + --oidc-client-id string 使用 OpenID 连接的客户端的 ID,如果设置了 oidc-issuer-url,则必须设置这个值。 - --oidc-groups-claim string 如果提供该值,这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。 + --oidc-groups-claim string 如果提供该值,这个自定义 OpenID 连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。 - --oidc-issuer-url string OpenID颁发者URL,只接受HTTPS方案。如果设置该值,它将被用于验证OIDC JSON Web Token(JWT)。 + --oidc-issuer-url string OpenID 颁发者 URL,只接受 HTTPS 方案。如果设置该值,它将被用于验证 OIDC JSON Web Token(JWT)。 - --oidc-username-claim string 用作用户名的OpenID声明值。注意,不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。 + --oidc-username-claim string 用作用户名的 OpenID 声明值。注意,不保证除默认 ('sub') 外的其他声明值的唯一性和不变性。此标志为实验性的,请查阅验证相关文档进一步了解详细信息。 - --profiling 在web接口host:port/debug/pprof/上启用profiling。(默认值true) + --profiling 在 web 接口 host:port/debug/pprof/ 上启用 profiling。(默认值 true) - --proxy-client-cert-file string 当必须调用外部程序时,用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。 + --proxy-client-cert-file string 当必须调用外部程序时,用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。它期望这个证书包含一个来自于 CA 中的 --requestheader-client-ca-file 标记的签名。该 CA 在 kube-system 命名空间的 'extension-apiserver-authentication' configmap 中发布。从 Kube-aggregator 收到调用的组件应该使用该 CA 进行他们部分的双向 TLS 验证。 - --proxy-client-key-file string 当必须调用外部程序时,用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。 + --proxy-client-key-file string 当必须调用外部程序时,用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书密钥。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。 - --repair-malformed-updates 如果为true,服务将会尽力修复更新请求以通过验证,例如:将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后,可以关闭这个标志。 + --repair-malformed-updates 如果为 true,服务将会尽力修复更新请求以通过验证,例如:将更新请求 UID 的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后,可以关闭这个标志。 - --requestheader-allowed-names stringSlice 使用--requestheader-username-headers指定的,允许在头部提供用户名的客户端证书通用名称列表。如果为空,任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。 + --requestheader-allowed-names stringSlice 使用 --requestheader-username-headers 指定的,允许在头部提供用户名的客户端证书通用名称列表。如果为空,任何通过 --requestheader-client-ca-file 中 authorities 验证的客户端证书都是被允许的。 - --requestheader-client-ca-file string 在信任请求头中以--requestheader-username-headers指示的用户名之前,用于验证接入请求中客户端证书的根证书捆绑。 + --requestheader-client-ca-file string 在信任请求头中以 --requestheader-username-headers 指示的用户名之前,用于验证接入请求中客户端证书的根证书捆绑。 - --requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。 + --requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用 X-Remote-Extra-。 - --requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用X-Remote-Group. + --requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用 X-Remote-Group. - --requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用X-Remote-User。 + --requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用 X-Remote-User。 - --runtime-config mapStringString 传递给apiserver用于描述运行时配置的键值对集合。 apis/键可以被用来打开/关闭特定的api版本。apis//键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本. + --runtime-config mapStringString 传递给 apiserver 用于描述运行时配置的键值对集合。 apis/ 键可以被用来打开 / 关闭特定的 api 版本。apis// 键被用来打开 / 关闭特定的资源 . api/all 和 api/legacy 键分别用于控制所有的和遗留的 api 版本 . - --secure-port int 用于监听具有认证授权功能的HTTPS协议的端口。如果为0,则不会监听HTTPS协议。 (默认值6443) + --secure-port int 用于监听具有认证授权功能的 HTTPS 协议的端口。如果为 0,则不会监听 HTTPS 协议。 (默认值 6443) - --service-account-key-file stringArray 包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件,用于验证ServiceAccount令牌。如果设置该值,--tls-private-key-file将会被使用。指定的文件可以包含多个密钥,并且这个标志可以和不同的文件一起多次使用。 + --service-account-key-file stringArray 包含 PEM 加密的 x509 RSA 或 ECDSA 私钥或公钥的文件,用于验证 ServiceAccount 令牌。如果设置该值,--tls-private-key-file 将会被使用。指定的文件可以包含多个密钥,并且这个标志可以和不同的文件一起多次使用。 - --service-cluster-ip-range ipNet CIDR表示的IP范围,服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。 + --service-cluster-ip-range ipNet CIDR 表示的 IP 范围,服务的 cluster ip 将从中分配。 一定不要和分配给 nodes 和 pods 的 IP 范围产生重叠。 - --ssh-keyfile string 如果不为空,在使用安全的SSH代理访问节点时,将这个文件作为用户密钥文件。 + --ssh-keyfile string 如果不为空,在使用安全的 SSH 代理访问节点时,将这个文件作为用户密钥文件。 - --storage-backend string 持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'. + --storage-backend string 持久化存储后端。 选项为 : 'etcd3' ( 默认 ), 'etcd2'. --storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型,并且忽略该配置项。(默认值 "application/vnd.kubernetes.protobuf") - --storage-versions string 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来,所有注册组的首选版本列表。 (默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1") + --storage-versions string 按组划分资源存储的版本。 以 "group1/version1,group2/version2,..." 的格式指定。当对象从一组移动到另一组时 , 你可以指定 "group1=group2/v1beta1,group3/v1beta1,..." 的格式。你只需要传入你希望从结果中改变的组的列表。默认为从 KUBE_API_VERSIONS 环境变量集成而来,所有注册组的首选版本列表。 (默认值 "admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1") - --target-ram-mb int apiserver内存限制,单位为MB(用于配置缓存大小等)。 + --target-ram-mb int apiserver 内存限制,单位为 MB( 用于配置缓存大小等 )。 - --tls-ca-file string 如果设置该值,这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中. + --tls-ca-file string 如果设置该值,这个证书 authority 将会被用于从 Admission Controllers 过来的安全访问。它必须是一个 PEM 加密的合法 CA 捆绑包。此外 , 该证书 authority 可以被添加到以 --tls-cert-file 提供的证书文件中 . - --tls-cert-file string 包含用于HTTPS的默认x509证书的文件。(如果有CA证书,则附加于server证书之后)。如果启用了HTTPS服务,并且没有提供--tls-cert-file和--tls-private-key-file,则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。 + --tls-cert-file string 包含用于 HTTPS 的默认 x509 证书的文件。(如果有 CA 证书,则附加于 server 证书之后)。如果启用了 HTTPS 服务,并且没有提供 --tls-cert-file 和 --tls-private-key-file,则将为公共地址生成一个自签名的证书和密钥并保存于 /var/run/kubernetes 目录。 - --tls-private-key-file string 包含匹配--tls-cert-file的x509证书私钥的文件。 + --tls-private-key-file string 包含匹配 --tls-cert-file 的 x509 证书私钥的文件。 - --tls-sni-cert-key namedCertKey 一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (默认值[]) + --tls-sni-cert-key namedCertKey 一对 x509 证书和私钥的文件路径 , 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀 , 则将提取证书名。 非通配符版本优先于通配符版本 , 显示的域形式优先于证书中提取的名字。 对于多个密钥 / 证书对, 请多次使用 --tls-sni-cert-key。例如 : "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (默认值[]) - --token-auth-file string 如果设置该值,这个文件将被用于通过令牌认证来保护API服务的安全端口。 + --token-auth-file string 如果设置该值,这个文件将被用于通过令牌认证来保护 API 服务的安全端口。 --version version[=true] 打印版本信息并退出。 - --watch-cache 启用apiserver的监视缓存。(默认值true) + --watch-cache 启用 apiserver 的监视缓存。(默认值 true) - --watch-cache-sizes stringSlice 每种资源(pods, nodes等)的监视缓存大小列表,以逗号分隔。每个缓存配置的形式为:resource#size,size是一个数字。在watch-cache启用时生效。 + --watch-cache-sizes stringSlice 每种资源(pods, nodes 等)的监视缓存大小列表,以逗号分隔。每个缓存配置的形式为:resource#size,size 是一个数字。在 watch-cache 启用时生效。 ``` ###### Auto generated by spf13/cobra on 11-Jul-2017 diff --git a/content/zh/docs/admin/multiple-zones.md b/content/zh/docs/admin/multiple-zones.md index 5b01b9bf3b..27bd5289ce 100644 --- a/content/zh/docs/admin/multiple-zones.md +++ b/content/zh/docs/admin/multiple-zones.md @@ -8,58 +8,58 @@ title: 多区域运行 ## 介绍 -Kubernetes 从v1.2开始支持将集群运行在多个故障域中。 -(GCE 中称其为 "区(Zones)", AWS 中称其为 "可用区(Availability Zones)",这里我们也称其为 "区")。 -它是广泛意义上的集群联邦特性的轻量级版本 (之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。 +Kubernetes 从 v1.2 开始支持将集群运行在多个故障域中。 +(GCE 中称其为 " 区(Zones)", AWS 中称其为 " 可用区(Availability Zones)",这里我们也称其为 " 区 ")。 +它是广泛意义上的集群联邦特性的轻量级版本 ( 之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。 完整的集群联邦能够将多个分别运行在不同区或云供应商(或本地数据中心)的集群集中管理。 -然而,很多用户只是希望通过将单一云供应商上的Kubernetes集群运行在多个区域,来提高集群的可用性, -这就是1.2版本中提供的对多区域的支持。 -(之前被称为 "Ubernetes Lite")。 +然而,很多用户只是希望通过将单一云供应商上的 Kubernetes 集群运行在多个区域,来提高集群的可用性, +这就是 1.2 版本中提供的对多区域的支持。 +( 之前被称为 "Ubernetes Lite")。 -多区域的支持是有明确限制的: Kubernetes集群能够运行在多个区,但必须在同一个地域内 (云供应商也须一致)。 -目前只有GCE和AWS自动支持 (尽管在其他云甚至裸机上,也很容易通过为节点和卷添加合适的标签来实现类似的支持)。 +多区域的支持是有明确限制的: Kubernetes 集群能够运行在多个区,但必须在同一个地域内 ( 云供应商也须一致 )。 +目前只有 GCE 和 AWS 自动支持 ( 尽管在其他云甚至裸机上,也很容易通过为节点和卷添加合适的标签来实现类似的支持 )。 {{< toc >}} ## 功能 -节点启动时,Kubelet自动为其添加区信息的标签。 +节点启动时,Kubelet 自动为其添加区信息的标签。 -在单一区域的集群中,Kubernetes 会自动将副本管理器或服务的pod分布到各节点上 (以减轻单实例故障的影响)。 +在单一区域的集群中,Kubernetes 会自动将副本管理器或服务的 pod 分布到各节点上 ( 以减轻单实例故障的影响 )。 在多区域的集群中,这种分布的行为扩展到了区域级别 -(以减少区域故障对整体的影响)。 (通过 `SelectorSpreadPriority` 来实现)。 +( 以减少区域故障对整体的影响 )。 ( 通过 `SelectorSpreadPriority` 来实现 )。 这种分发是尽力而为(best-effort)的,所以如果集群在各个区之间是异构的 -(比如,各区间的节点数量不同、节点类型不同、pod的资源需求不同等)可能导致pod无法完全均匀地分布。 -如果需要的话,用户可以使用同质的区(节点数量和节点类型相同)来减少区域之间分配不均匀的可能。 +( 比如,各区间的节点数量不同、节点类型不同、pod 的资源需求不同等 ) 可能导致 pod 无法完全均匀地分布。 +如果需要的话,用户可以使用同质的区 ( 节点数量和节点类型相同 ) 来减少区域之间分配不均匀的可能。 -当卷被创建时, `PersistentVolumeLabel`准入控制器会自动为其添加区域的标签。 -调度器 (通过 `VolumeZonePredicate` 断言) 会确申领该卷的pod被调度到该卷对应的区域, +当卷被创建时, `PersistentVolumeLabel` 准入控制器会自动为其添加区域的标签。 +调度器 ( 通过 `VolumeZonePredicate` 断言 ) 会确申领该卷的 pod 被调度到该卷对应的区域, 因为卷是不支持跨区挂载的。 ## 限制 对多区的支持有一些重要的限制: -* 我们假设不同的区域间在网络上离得很近,所以我们不做任何的区域感知路由。 特别是,通过服务的网络访问可能跨区域 (即使该服务后端pod的其中一些运行在与客户端相同的区域中),这可能导致额外的延迟和损耗。 +* 我们假设不同的区域间在网络上离得很近,所以我们不做任何的区域感知路由。 特别是,通过服务的网络访问可能跨区域 ( 即使该服务后端 pod 的其中一些运行在与客户端相同的区域中 ),这可能导致额外的延迟和损耗。 -* 卷的区域亲和性只对 `PersistentVolume`有效。 例如,如果你在pod的spec中直接指定一个EBS的卷,则不会生效。 +* 卷的区域亲和性只对 `PersistentVolume` 有效。 例如,如果你在 pod 的 spec 中直接指定一个 EBS 的卷,则不会生效。 -* 集群不支持跨云平台或地域 (这些功能需要完整的集群联邦特性支持)。 +* 集群不支持跨云平台或地域 ( 这些功能需要完整的集群联邦特性支持 )。 * 尽管节点位于多区域,目前默认情况下 kube-up 创建的管理节点是单实例的。 所以尽管服务是高可用的,并且能够容忍跨区域的性能损耗,管理平面还是单区域的。 需要高可用的管理平面的用户可以按照 [高可用](/docs/admin/high-availability) 指导来操作。 -* 目前StatefulSet的卷动态创建时的跨区域分配,与pod的亲和性/反亲和性不兼容。 +* 目前 StatefulSet 的卷动态创建时的跨区域分配,与 pod 的亲和性 / 反亲和性不兼容。 -* StatefulSet的名称包含破折号 ("-")时,可能影响到卷在区域间的均匀分布。 +* StatefulSet 的名称包含破折号 ("-") 时,可能影响到卷在区域间的均匀分布。 -* 为deployment或pod指定多个PVC时,要求其StorageClass处于同一区域内,否则,相应的PV卷需要在一个区域中静态配置。 另一种方式是使用StatefulSet,这可以确保同一副本所挂载的卷位于同一区内。 +* 为 deployment 或 pod 指定多个 PVC 时,要求其 StorageClass 处于同一区域内,否则,相应的 PV 卷需要在一个区域中静态配置。 另一种方式是使用 StatefulSet,这可以确保同一副本所挂载的卷位于同一区内。 ## 演练 接下来我们将介绍如何同时在 GCE 和 AWS 上创建和使用多区域的集群。 为此,你需要创建一个完整的集群 -(指定 `MULTIZONE=true`),然后再次执行 `kube-up`(指定 `KUBE_USE_EXISTING_MASTER=true`)来添加其他区域的节点。 +( 指定 `MULTIZONE=true`),然后再次执行 `kube-up`(指定 `KUBE_USE_EXISTING_MASTER=true`)来添加其他区域的节点。 ### 创建集群 @@ -99,7 +99,7 @@ kubernetes-minion-a12q Ready 6m v1.6.0+fff5156 beta. ### 添加其它区中的节点 -接下来我们复用已有的管理节点,添加运行于其它区域 (us-central1-b或us-west-2b)中的节点。 +接下来我们复用已有的管理节点,添加运行于其它区域 (us-central1-b 或 us-west-2b)中的节点。 再次执行 kube-up, 通过指定 `KUBE_USE_EXISTING_MASTER=true`, kube-up 不会创建新的管理节点,而是会复用之前创建的。 @@ -109,14 +109,14 @@ GCE: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh ``` -在 AWS 中我们还需要为新增的子网指定网络CIDR,还有管理节点的内部IP地址。 +在 AWS 中我们还需要为新增的子网指定网络 CIDR,还有管理节点的内部 IP 地址。 ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -再次查看节点,3个新增的节点已经启动,并被标记为us-central1-b: +再次查看节点,3 个新增的节点已经启动,并被标记为 us-central1-b: ```shell > kubectl get nodes --show-labels @@ -133,7 +133,7 @@ kubernetes-minion-wf8i Ready 2m v1.6.0+fff5156 beta ### 卷的亲和性 -使用动态创建卷的功能创建一个卷 (只有PV持久卷才支持区域亲和性): +使用动态创建卷的功能创建一个卷 ( 只有 PV 持久卷才支持区域亲和性 ): ```json kubectl create -f - < kubectl get pv --show-labels @@ -172,9 +172,9 @@ NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE pv-gce-mj4gm 5Gi RWO Bound default/claim1 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` -现在我们将创建使用这些PVC的pod。 -因为 GCE 的PD存储 / AWS 的EBS 卷 不支持跨区域挂载, -这意味着相应的pod只能创建在卷所在的区域中。 +现在我们将创建使用这些 PVC 的 pod。 +因为 GCE 的 PD 存储 / AWS 的 EBS 卷 不支持跨区域挂载, +这意味着相应的 pod 只能创建在卷所在的区域中。 ```yaml kubectl create -f - < kubectl describe pod mypod | grep Node @@ -206,9 +206,9 @@ NAME STATUS AGE VERSION LABELS kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv ``` -### Pod的跨区域分布 +### Pod 的跨区域分布 -副本管理器或服务的pod被自动创建在了不同的区域。 首先,在第三个区域内启动节点: +副本管理器或服务的 pod 被自动创建在了不同的区域。 首先,在第三个区域内启动节点: GCE: @@ -222,19 +222,19 @@ AWS: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -验证你现在在3个区域内拥有节点: +验证你现在在 3 个区域内拥有节点 : ```shell kubectl get nodes --show-labels ``` -创建 guestbook-go 示例应用, 它包含一个副本数为3的RC,运行一个简单的网络应用: +创建 guestbook-go 示例应用, 它包含一个副本数为 3 的 RC,运行一个简单的网络应用: ```shell find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {} ``` -Pod应该分布在全部3个区域上: +Pod 应该分布在全部 3 个区域上: ```shell > kubectl describe pod -l app=guestbook | grep Node @@ -268,7 +268,7 @@ LoadBalancer Ingress: 130.211.126.21 "HOSTNAME": "guestbook-ppm40", ``` -负载平衡器正确指向了所有的pod,即使它们位于不同的区域内。 +负载均衡器正确指向了所有的 pod,即使它们位于不同的区域内。 ### 停止集群 diff --git a/content/zh/docs/admin/node-conformance.md b/content/zh/docs/admin/node-conformance.md index 1aa9be2412..1e43ee2d43 100644 --- a/content/zh/docs/admin/node-conformance.md +++ b/content/zh/docs/admin/node-conformance.md @@ -13,7 +13,7 @@ title: 节点设置校验 ## 限制 -在 Kubernetes 1.5版本中,节点合规性测试存在以下限制: +在 Kubernetes 1.5 版本中,节点合规性测试存在以下限制: * 节点合规性测试只支持 Docker 作为容器运行时环境。 @@ -60,7 +60,7 @@ Kubernetes 也为其他硬件体系结构的系统提供了节点合规性测试 ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e FOCUS=MirrorPod \ # 只运行MirrorPod测试 + -e FOCUS=MirrorPod \ # 只运行 MirrorPod 测试 k8s.gcr.io/node-test:0.2 ``` @@ -69,7 +69,7 @@ sudo docker run -it --rm --privileged --net=host \ ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e SKIP=MirrorPod \ # 运行除MirrorPod外的所有测试 + -e SKIP=MirrorPod \ # 运行除 MirrorPod 外的所有测试 k8s.gcr.io/node-test:0.2 ``` @@ -80,5 +80,5 @@ sudo docker run -it --rm --privileged --net=host \ ## 注意事项 -* 测试会在节点上遗留一些Docker镜像, 包括节点合规性测试本身的镜像,和功能测试相关的镜像。 +* 测试会在节点上遗留一些 Docker 镜像, 包括节点合规性测试本身的镜像和功能测试相关的镜像。 * 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。 diff --git a/content/zh/docs/admin/ovs-networking.md b/content/zh/docs/admin/ovs-networking.md index 5b4fe7f5f8..856148c0d8 100644 --- a/content/zh/docs/admin/ovs-networking.md +++ b/content/zh/docs/admin/ovs-networking.md @@ -4,18 +4,18 @@ approvers: title: Kubernetes OpenVSwitch GRE/VxLAN 网络 --- -本文档介绍了如何使用OpenVSwitch,在跨nodes的pods之间设置网络。 -隧道类型可以是GRE或者是VxLAN。如需在网络内执行大规模隔离时,最好使用VxLAN。 +本文档介绍了如何使用 OpenVSwitch,在跨 nodes 的 pods 之间设置网络。 +隧道类型可以是 GRE 或者是 VxLAN。如需在网络内执行大规模隔离时,最好使用 VxLAN。 ![OVS Networking](/images/docs/ovs-networking.png) -Kubernetes中Vagrant的设置如下: +Kubernetes 中 Vagrant 的设置如下: -docker网桥被brctl生成的Linux网桥(kbr0)所代替,kbr0是具有256个地址空间的子网。总的来说,node会得到10.244.x.0/24的子网,docker上配置使用的网桥会代替默认docker0的网桥。 +docker 网桥被 brctl 生成的 Linux 网桥(kbr0) 所代替,kbr0 是具有 256 个地址空间的子网。总的来说,node 会得到 10.244.x.0/24 的子网,docker 上配置使用的网桥会代替默认 docker0 的网桥。 -另外,OVS网桥创建(obr0),并将其作为端口添加到kbr0的网桥中。所有OVS网桥通过GRE隧道连接所有的nodes。因此,每个node都有一个到其他nodes的出站GRE隧道。这个隧道没有必要是一个完整的网状物,但是越像网状结构越好。在网桥上开启STP(生成树)模式以防止环路的发生。 +另外,OVS 网桥创建(obr0),并将其作为端口添加到 kbr0 的网桥中。所有 OVS 网桥通过 GRE 隧道连接所有的 nodes。因此,每个 node 都有一个到其他 nodes 的出站 GRE 隧道。这个隧道没有必要是一个完整的网状物,但是越像网状结构越好。在网桥上开启 STP (生成树)模式以防止环路的发生。 -路由规则允许任何10.244.0.0/16通过与隧道相连的OVS网桥到达目标。 +路由规则允许任何 10.244.0.0/16 通过与隧道相连的 OVS 网桥到达目标。 diff --git a/content/zh/docs/admin/service-accounts-admin.md b/content/zh/docs/admin/service-accounts-admin.md index bf3e0783f9..65d9aeeb53 100644 --- a/content/zh/docs/admin/service-accounts-admin.md +++ b/content/zh/docs/admin/service-accounts-admin.md @@ -4,58 +4,58 @@ approvers: - davidopp - lavalamp - liggitt -title: 管理Service Accounts +title: 管理 Service Accounts --- -*这是一篇针对service accounts(服务账户)的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。* +*这是一篇针对 service accounts(服务账户)的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts) 中的信息。* -*对授权和用户账户的支持已在规划中,当前并不完备,为了更好地描述service accounts,有时这些不完善的特性也会被提及。* +*对授权和用户账户的支持已在规划中,当前并不完备,为了更好地描述 service accounts,有时这些不完善的特性也会被提及。* ## 用户账户与服务账户 Kubernetes 区分用户账户和服务账户的概念主要基于以下原因: - - 用户账户是针对人而言的。 服务账户是针对运行在pod中的进程而言的。 - - 用户账户是全局性的。 其名称在集群各namespace中都是全局唯一的,未来的用户资源不会做namespace隔离, - 服务账户是namespace隔离的。 - - 通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 (即权限最小化原则)。 + - 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。 + - 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的,未来的用户资源不会做 namespace 隔离, + 服务账户是 namespace 隔离的。 + - 通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。 - 对人员和服务账户审计所考虑的因素可能不同。 - - 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建,并且有namespace级别的名称,这种配置是很轻量的。 + - 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建,并且有 namespace 级别的名称,这种配置是很轻量的。 ## 服务账户的自动化 -三个独立组件协作完成服务账户相关的自动化: +三个独立组件协作完成服务账户相关的自动化 : - 服务账户准入控制器(Service account admission controller) - - Token控制器(Token controller) + - Token 控制器(Token controller) - 服务账户控制器(Service account controller) ### 服务账户准入控制器 -对pod的改动通过一个被称为[Admission Controller](/docs/admin/admission-controllers)的插件来实现。它是apiserver的一部分。 -当pod被创建或更新时,它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的),当pod被创建或更新时它会进行以下动作: +对 pod 的改动通过一个被称为 [Admission Controller](/docs/admin/admission-controllers) 的插件来实现。它是 apiserver 的一部分。 +当 pod 被创建或更新时,它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 ),当 pod 被创建或更新时它会进行以下动作: - 1. 如果该pod没有 `ServiceAccount` 设置,将其 `ServiceAccount` 设为 `default`。 - 2. 保证pod所关联的 `ServiceAccount` 存在,否则拒绝该pod。 - 4. 如果pod不包含 `ImagePullSecrets`设置,那么 将 `ServiceAccount`中的`ImagePullSecrets` 信息添加到pod中。 - 5. 将一个包含用于API访问的token的 `volume` 添加到pod中。 - 6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount` 的 `volumeSource`添加到pod下的每个容器中。 + 1. 如果该 pod 没有 `ServiceAccount` 设置,将其 `ServiceAccount` 设为 `default`。 + 2. 保证 pod 所关联的 `ServiceAccount` 存在,否则拒绝该 pod。 + 4. 如果 pod 不包含 `ImagePullSecrets` 设置,那么 将 `ServiceAccount` 中的 `ImagePullSecrets` 信息添加到 pod 中。 + 5. 将一个包含用于 API 访问的 token 的 `volume` 添加到 pod 中。 + 6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount` 的 `volumeSource` 添加到 pod 下的每个容器中。 -### Token管理器 +### Token 管理器 -Token管理器是controller-manager的一部分。 以异步的形式工作: +Token 管理器是 controller-manager 的一部分。 以异步的形式工作: -- 检测服务账户的创建,并且创建相应的Secret以支持API访问。 -- 检测服务账户的删除,并且删除所有相应的服务账户Token Secret。 -- 检测Secret的增加,保证相应的服务账户存在,如有需要,为Secret增加token。 -- 检测Secret的删除,如有需要,从相应的服务账户中移除引用。 +- 检测服务账户的创建,并且创建相应的 Secret 以支持 API 访问。 +- 检测服务账户的删除,并且删除所有相应的服务账户 Token Secret。 +- 检测 Secret 的增加,保证相应的服务账户存在,如有需要,为 Secret 增加 token。 +- 检测 Secret 的删除,如有需要,从相应的服务账户中移除引用。 -你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至Token管理器。 私钥用于为生成的服务账户token签名。 -同样地,你需要通过 `--service-account-key-file` 参数将对应的公钥传入kube-apiserver。 公钥用于认证过程中的token校验。 +你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至 Token 管理器。 私钥用于为生成的服务账户 token 签名。 +同样地,你需要通过 `--service-account-key-file` 参数将对应的公钥传入 kube-apiserver。 公钥用于认证过程中的 token 校验。 #### 创建额外的 API tokens -控制器中有专门的循环来保证每个服务账户中都存在API token对应的Secret。 当需要为服务账户创建额外的API token时,创建一个类型为 `ServiceAccountToken` 的Secret,并在annotation中引用服务账户,控制器会生成token并更新: +控制器中有专门的循环来保证每个服务账户中都存在 API token 对应的 Secret。 当需要为服务账户创建额外的 API token 时,创建一个类型为 `ServiceAccountToken` 的 Secret,并在 annotation 中引用服务账户,控制器会生成 token 并更新 : secret.json: @@ -78,7 +78,7 @@ kubectl create -f ./secret.json kubectl describe secret mysecretname ``` -#### 删除/失效 服务账户token +#### 删除 / 失效 服务账户 token ```shell kubectl delete secret mysecretname diff --git a/content/zh/docs/concepts/_index.md b/content/zh/docs/concepts/_index.md index 6059a0544e..e900d5c307 100644 --- a/content/zh/docs/concepts/_index.md +++ b/content/zh/docs/concepts/_index.md @@ -39,7 +39,7 @@ weight: 40 * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master. * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. --> -* **Kubernetes 主控组件(Master)** 包含三个进程,都运行在集群中的某个节上,通常这个节点被称为 master 节点。这些进程包括:[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)和[kube-scheduler](/docs/admin/kube-scheduler/)。 +* **Kubernetes 主控组件(Master)** 包含三个进程,都运行在集群中的某个节上,通常这个节点被称为 master 节点。这些进程包括:[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。 * 集群中的每个非 master 节点都运行两个进程: * **[kubelet](/docs/admin/kubelet/)**,和 master 节点进行通信。 * **[kube-proxy](/docs/admin/kube-proxy/)**,一种网络代理,将 Kubernetes 的网络服务代理到每个节点上。 @@ -50,7 +50,7 @@ weight: 40 -Kubernetes 包含若干抽象用来表示系统状态,包括:已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。 +Kubernetes 包含若干抽象用来表示系统状态,包括:已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。 @@ -77,7 +77,7 @@ Kubernetes 包含若干抽象用来表示系统状态,包括:已部署的容 -关于 Kubernetes 控制平面的各个部分,(如 Kubernetes 主控组件和 kubelet 进程,管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录,并且通过连续的控制循环来管理这些对象的状态。在任一的给定时间点,控制面的控制环都能响应集群中的变化,并且让系统中所有对象的实际状态与你提供的预期状态相匹配。 +关于 Kubernetes 控制平面的各个部分,(如 Kubernetes 主控组件和 kubelet 进程),管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录,并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点,控制面的控制环都能响应集群中的变化,并且让系统中所有对象的实际状态与你提供的预期状态相匹配。 @@ -93,7 +93,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne -> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上,并且这个节点被称为 master 节点。master 节点也可以扩展副本数,来获取更好的性能及冗余。 +> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上,并且这个节点被称为 master 节点。master 节点也可以扩展副本数,来获取更好的可用性及冗余。 @@ -108,7 +108,7 @@ Kubernetes master 节点负责维护集群的目标状态。当你要与 Kuberne #### 对象元数据 -* [注释](/docs/concepts/overview/working-with-objects/annotations/) +* [注解](/docs/concepts/overview/working-with-objects/annotations/) {{% /capture %}} diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..93d61ea5ff --- /dev/null +++ b/content/zh/docs/concepts/architecture/_index.md @@ -0,0 +1,11 @@ +--- +title: "Kubernetes 架构" +weight: 30 +--- + + \ No newline at end of file diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index dd95033892..86cb44bec7 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -1,175 +1,458 @@ -title: 云控制器管理器的基本概念 +--- +title: 云控制器管理器的基础概念 +content_template: templates/concept +weight: 30 +--- -## 云控制器管理器 + -云控制器管理器(CCM)这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器,API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动,这种情况下,CCM运行在Kubernetes系统之上。 -云控制器管理器基于插件机制设计,允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划,并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。 +{{% capture overview %}} + + + +云控制器管理器(cloud controller manager,CCM)这个概念 (不要与二进制文件混淆)创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件(如 Kubernetes 控制器管理器,API 服务器和调度程序)一起运行。它也可以作为 Kubernetes 的插件启动,在这种情况下,它会运行在 Kubernetes 之上。 + + + +云控制器管理器基于插件机制设计,允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划,并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。 + + 本文讨论了云控制器管理器背后的概念,并提供了相关功能的详细信息。 -下面这张图描述了没有云控制器管理器的Kubernetes集群架构: + + +这是没有云控制器管理器的 Kubernetes 集群的架构: + + + +![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png) + +{{% /capture %}} + + +{{% capture body %}} + + -![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png) ## 设计 -在上图中,Kubernetes和云服务供应商通过几个不同的组件进行了集成,分别是: + + +在上图中,Kubernetes 和云服务供应商通过几个不同的组件进行了集成,分别是: + + * Kubelet * Kubernetes 控制管理器 -* Kubernetes API服务器 +* Kubernetes API 服务器 -而CCM整合了前三个组件中的所有依赖于云的逻辑,用来创建与云的单点集成。新架构如下图所示: + -![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png) +CCM 整合了前三个组件中的所有依赖于云的逻辑,以创建与云的单一集成点。CCM 的新架构如下所示: -## CCM的组件 + -CCM突破了Kubernetes控制器管理器(KCM)的一些功能,并将其作为一个独立的进程运行。具体而言,它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎: +![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png) + + +## CCM 的组成部分 + + + +CCM 打破了 Kubernetes 控制器管理器(KCM)的一些功能,并将其作为一个单独的进程运行。具体来说,它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器: + + * 节点控制器 * 卷控制器 * 路由控制器 * 服务控制器 + -在1.8版本中,当前运行中的CCM从上面的列表中运行以下控制器: +在 1.9 版本中,CCM 运行前述列表中的以下控制器: + + * 节点控制器 * 路由控制器 * 服务控制器 -另外,它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域(Zone)和区(Region)标签进行设置。 + -**注意**:卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象,因此决定了卷控制器不会被移动到CCM之中。 +此外,它还运行另一个名为 PersistentVolumeLabels Controller 的控制器,这个控制器负责在 GCP 和 AWS 云中创建的 PersistentVolumes 的域(zone)和区(region)标签进行设置。 -原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而,官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。 +{{< note >}} + -考虑到这些正在进行中的变化,我们决定暂时停止当前工作直至CSI准备就绪。 +注意卷控制器不属于 CCM,由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象,因此决定了卷控制器不会被移动到 CCM 之中。 -云服务供应商工作组(wg-cloud-provider)正在开展相关工作,以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes#52371](https://github.com/kubernetes/kubernetes/pull/52371)。 +{{< /note >}} -## CCM功能 + -CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。 +使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷,但是现在正在计划一项名为 CSI 的项目以取代 Flex。 + + + +考虑到这些正在进行中的变化,在 CSI 准备就绪之前,我们决定停止当前的工作。 + + + +## CCM 的功能 + + + +CCM 从依赖于云提供商的 Kubernetes 组件继承其功能,本节基于这些组件组织。 + + ### 1. Kubernetes 控制器管理器 -CCM的大部分功能都来自KCM。 如上一节所述,CCM运行以下控制引擎: + + +CCM 的大多数功能都来自 KCM,如上一节所述,CCM 运行以下控制器。 + + * 节点控制器 * 路由控制器 * 服务控制器 -* PersistentVolumeLabels控制器 +* PersistentVolumeLabels 控制器 + + #### 节点控制器 -节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能: + -1.使用云特定域(Zone)/区(Region)标签初始化节点。 +节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点,节点控制器执行以下功能: -1.使用特定于云的实例详细信息初始化节点,例如类型和大小。 + -1.获取节点的网络地址和主机名。 +1. 使用特定于云的域(zone)/区(region)标签初始化节点; +2. 使用特定于云的实例详细信息初始化节点,例如,类型和大小; +3. 获取节点的网络地址和主机名; +4. 如果节点无响应,请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点,请删除 Kubernetes 节点对象。 -1.如果节点无响应,检查该节点是否已从云中删除。如果该节点已从云中删除,则删除Kubernetes节点对象。 + #### 路由控制器 -路由控制器负责为云配置正确的路由,以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。 + + +Route 控制器负责适当地配置云中的路由,以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。 + + #### 服务控制器 -服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态,它将配置云负载平衡器(如ELB或Google LB)以反映Kubernetes中的服务状态。此外,它还确保云负载均衡器的服务后端保持最新。 + + +服务控制器负责监听服务的创建、更新和删除事件。根据 Kubernetes 中各个服务的当前状态,它配置云负载均衡器(如 ELB 或 Google LB)以反映 Kubernetes 中的服务状态。此外,它还确保云负载均衡器的服务后端是最新的。 + + #### PersistentVolumeLabels 控制器 -PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签,这使得用户不再需要手动设置这些卷标签。 + -这些标签对于pod的调度工作是非常重要的,因为这些卷只能在它们所在的域(Zone)/区(Region)内工作,因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。 +PersistentVolumeLabels 控制器在创建 AWS EBS/GCE PD 卷时应用标签,这样就无需用户手动设置这些卷上的标签。 -PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说,在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器(它是一个许可控制器)中的PV标签逻辑移动到CCM。 它不在KCM上运行。 + + +这些标签对于 pod 的调度至关重要,因为这些卷仅限于在它们所在的域(zone)/区(region)内工作,使用这些卷的任何 Pod 都需要在同一域(zone)/区(region)中进行调度。 + + + +PersistentVolumeLabels 控制器专门为 CCM 创建; 也就是说,在创建 CCM 之前它不存在。这样做是为了将 Kubernetes API 服务器(它是一个准入控制器)中的 PV 标记逻辑移动到 CCM,它不在 KCM 上运行。 + + ### 2. Kubelet -Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前,是由kubelet采用包含云特定信息的方式对节点进行初始化,如IP地址、区(Region)/域(Zone)标签和实例类型信息;引入CCM之后,这部分的初始化操作就从kubelet转移到了CCM中。 + -在引入CCM后的新的模型中,kubelet采用不包含云特定信息的方式初始化一个节点。但是,它会为新创建的节点添加一个污点,使得该节点不可被立即调度,直到CCM使用包含云的特定信息初始化节点后,才会删除该污点,使得该节点可被调度。 +节点控制器包含 kubelet 中依赖于云的功能,在引入 CCM 之前,kubelet 负责使用特定于云的详细信息(如 IP 地址,域/区标签和实例类型信息)初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 -### 3. Kubernetes API服务器 + + +在这个新模型中,kubelet 初始化一个没有特定于云的信息的节点。但是,它会为新创建的节点添加污点,使节点不可调度,直到 CCM 使用特定于云的信息初始化节点后,才会清除这种污点,便得该节点可被调度。 + + + +### 3. Kubernetes API 服务器 + + + +PersistentVolumeLabels 控制器将 Kubernetes API 服务器的依赖于云的功能移至 CCM,如前面部分所述。 + + -PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM,如前面部分所述。 ## 插件机制 -云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说,它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。 + -上面强调的四个共享控制器的实现,以及一些辅助设施(scaffolding)和共享的云服务供应商接口,将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外,并实现核心中定义的接口。 +云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说,它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。 -有关开发插件的更多信息,请参阅 -[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。 + + + +上面强调的四个共享控制器的实现,以及一些辅助设施(scaffolding)和共享的 cloudprovider 接口,将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建,并实现核心中定义的接口。 + + + +有关开发插件的更多信息,请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。 + + ## 授权 -本节分解了CCM对各种API对象的访问,以执行其操作。 + + +本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。 + + ### 节点控制器 -节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。 + + +Node 控制器仅适用于 Node 对象,它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。 + + + +v1/Node: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + + ### 路由控制器 -路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。 + + +路由控制器侦听 Node 对象创建并适当地配置路由,它需要访问 Node 对象。 + +v1/Node: -v1/Node: - Get + + ### 服务控制器 -服务控制器侦听服务对象创建、更新和删除事件,然后对这些服务的端点进行恰当的配置。 + -要访问服务,它需要罗列和监控权限。要更新服务,它需要修补和更新权限。 +服务控制器侦听 Service 对象创建、更新和删除事件,然后适当地为这些服务配置端点。 -要为服务设置端点,需要访问创建、列表、获取、监视和更新。 + + +要访问服务,它需要列表和监视访问权限。要更新服务,它需要修补和更新访问权限。 + + + +要为服务设置端点,需要访问 create、list、get、watch 和 update。 v1/Service: + - List - Get - Watch - Patch - Update + + ### PersistentVolumeLabels 控制器 -PersistentVolumeLabels控制器监听PersistentVolume(PV)创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。 + + +PersistentVolumeLabels 控制器侦听 PersistentVolume(PV)创建事件并更新它们,该控制器需要访问以获取和更新 PV。 v1/PersistentVolume: + - Get - List - Watch - Update + + ### 其它 -CCM核心的实现需要创建事件的权限,为了确保安全操作,需要创建ServiceAccounts的权限。 + + +CCM 核心的实现需要访问权限以创建事件,并且为了确保安全操作,它需要访问权限以创建服务账户。 v1/Event: + - Create - Patch - Update v1/ServiceAccount: + - Create -针对CCM的RBAC ClusterRole如下所示: + + + +针对 CCM 的 RBAC ClusterRole 看起来像这样: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -233,9 +516,18 @@ rules: - update ``` + + + ## 供应商实施 -以下云服务供应商为自己的云部署了CCM。 + + +以下云服务提供商已实现了 CCM: * [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) @@ -246,4 +538,10 @@ rules: ## 群集管理 -[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。 + + +[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/architecture/master-node-communication.md b/content/zh/docs/concepts/architecture/master-node-communication.md index 45b2d08d59..9c117c2185 100644 --- a/content/zh/docs/concepts/architecture/master-node-communication.md +++ b/content/zh/docs/concepts/architecture/master-node-communication.md @@ -40,7 +40,7 @@ Master 组件通过非安全(没有加密或认证)端口和集群的 apiser 从 master(apiserver)到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。 -### apiserver -> kubelet +## apiserver -> kubelet 从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接(通过 kubectl)运行中的 pods,以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。 @@ -52,19 +52,19 @@ Master 组件通过非安全(没有加密或认证)端口和集群的 apiser 为了对这个连接进行认证,请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑,用于 kubelet 的服务证书。 -如果这样不可能,又要求避免在不可信的或公共的网络上进行连接,请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)。 +如果这样不可能,又要求避免在不可信的或公共的网络上进行连接,请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 -最后,应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 +最后,应该启用 [Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 -### apiserver -> nodes, pods, and services +## apiserver -> nodes, pods, and services -从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式,因此既没有认证,也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书,也不会提供客户端证书。这样虽然连接是加密的,但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。 +从 apiserver 到 node、pod 或者 service 的连接默认为纯 HTTP 方式,因此既没有认证,也没有加密。他们能够通过给 API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书,也不会提供客户端证书。这样虽然连接是加密的,但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。 -### SSH 隧道 +## SSH 隧道 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下,apiserver 发起一个到集群中每个节点的 SSH 隧道(连接到在 22 端口监听的 ssh 服务)并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 954e5b3c6b..67105b94e7 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -61,8 +61,8 @@ redirect_from: | ---------------- | ---------------------------------------- | | `OutOfDisk` | `True` 表示 node 的空闲空间不足以用于添加新 pods, 否则为 `False` | | `Ready` | `True` 表示 node 是健康的并已经准备好接受 pods;`False` 表示 node 不健康而且不能接受 pods;`Unknown` 表示 node 控制器在最近 40 秒内没有收到 node 的消息 | -| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低, 否则为 `False` | -| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低, 否则为 `False` | +| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低,否则为 `False` | +| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低,否则为 `False` | Node 条件使用一个 JSON 对象表示。例如,下面的响应描述了一个健康的 node。 @@ -77,10 +77,10 @@ Node 条件使用一个 JSON 对象表示。例如,下面的响应描述了一 ``` -如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数),node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5分钟**。某些情况下,当 node 不可访问时,apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet,直到它重新建立和 apiserver 的连接为止。与此同时,被计划删除的 pods 可能会继续在分区 node 上运行。 +如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数),node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下,当 node 不可访问时,apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet,直到它重新建立和 apiserver 的连接为止。与此同时,被计划删除的 pods 可能会继续在分区 node 上运行。 -在 1.5 版本之前的 Kubernetes 里,node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里,在node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群,集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。 +在 1.5 版本之前的 Kubernetes 里,node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里,在 node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群,集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。 ### 容量 @@ -117,7 +117,7 @@ Node 条件使用一个 JSON 对象表示。例如,下面的响应描述了一 Kubernetes 会在内部创一个 node 对象(象征 node),并基于 `metadata.name` 字段(我们假设 `metadata.name` 能够被解析)通过健康检查来验证 node。如果 node 可用,意即所有必要服务都已运行,它就符合了运行一个 pod 的条件;否则它将被所有的集群动作忽略直到变为可用。请注意,Kubernetes 将保存不可用 node 的对象,除非它被客户端显式的删除。Kubernetes 将持续检查 node 是否变的可用。 -当前,有3个组件同 Kubernetes node 接口交互:node 控制器、kubelet 和 kubectl。 +当前,有 3 个组件同 Kubernetes node 接口交互:node 控制器、kubelet 和 kubectl。 ### Node 控制器 @@ -141,13 +141,13 @@ Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当 大部分情况下, node 控制器把删除频率限制在每秒 `--node-eviction-rate` 个(默认为 0.1)。这表示它在 10 秒钟内不会从超过一个 node 上删除 pods。 -当一个 availability zone 中的 node 变为不健康时,它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康(NodeReady 状态为 ConditionUnknown 或 ConditionFalse)的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` (默认为 0.55),删除速率将会减小:如果集群较小(意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为50),删除将会停止,否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个(默认为 0.01)。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones,那就只有一个 availability zone(整个集群)。 +当一个 availability zone 中的 node 变为不健康时,它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康(NodeReady 状态为 ConditionUnknown 或 ConditionFalse)的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` (默认为 0.55),删除速率将会减小:如果集群较小(意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为 50),删除将会停止,否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个(默认为 0.01)。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones,那就只有一个 availability zone(整个集群)。 在多个 availability zones 分布你的 nodes 的一个关键原因是当整个 zone 故障时,工作负载可以转移到健康的 zones。因此,如果一个 zone 中的所有 nodes 都不健康时,node 控制器会以正常的速率 `--node-eviction-rate` 删除。在所有的 zones 都不健康(也即集群中没有健康 node)的极端情况下,node 控制器将假设 master 的连接出了某些问题,它将停止所有删除动作直到一些连接恢复。 -从 Kubernetes 1.6 开始,NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods,如果这些 pods 没有 tolerate 这些 taints。此外,作为一个默认禁用的 alpha 特性,NodeController 还负责根据 node 故障(例如 node 不可访问或没有 ready)添加 taints。请查看 [这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。 +从 Kubernetes 1.6 开始,NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods,如果这些 pods 没有 tolerate 这些 taints。此外,作为一个默认禁用的 alpha 特性,NodeController 还负责根据 node 故障(例如 node 不可访问或没有 ready)添加 taints。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。 ### Nodes 自注册 @@ -180,7 +180,7 @@ Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当 如果管理员希望手动创建 node 对象,请设置 kubelet 标记 `--register-node=false`。 -管理员可以修改 node 资源(忽略 `--register-node` 设置)。修改包括在 node 上设置 labels及标记它为不可调度。 +管理员可以修改 node 资源(忽略 `--register-node` 设置)。修改包括在 node 上设置 labels 及标记它为不可调度。 Nodes 上的 labels 可以和 pods 的 node selectors 一起使用来控制调度,例如限制一个 pod 只能在一个符合要求的 nodes 子集上运行。 diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md new file mode 100644 index 0000000000..9ec54aaf96 --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,11 @@ +--- +title: "计算、存储和网络扩展" +weight: 30 +--- + + \ No newline at end of file diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index 1ddac950f1..659f287447 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -24,7 +24,7 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件, 能够透明的实施 HTTP/API/L7 策略。 同时支持路由(routing)和叠加/封装( overlay/encapsulation)模式。 * [Contiv](http://contiv.github.io) 为多种用例提供可配置网络(使用 BGP 的原生 L3,使用 vxlan 的 overlay,经典 L2 和 Cisco-SDN/ACI)和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。 -* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案,并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 +* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案,并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略,并且不需要额外的数据库。 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件,例如:Flannel、Calico、Canal、Romana 或者 Weave。 @@ -33,7 +33,7 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。 -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具,用于查看你的 containers、 pods、services等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用,或者自己运行 UI。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具,用于查看你的 containers、 pods、services 等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用,或者自己运行 UI。 ## 遗留 Add-ons diff --git a/content/zh/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md index c70f17b743..b8347a49be 100644 --- a/content/zh/docs/concepts/cluster-administration/certificates.md +++ b/content/zh/docs/concepts/cluster-administration/certificates.md @@ -17,7 +17,7 @@ title: 证书 `cluster/saltbase/salt/generate-cert/make-ca-cert.sh`。 执行该脚本时需传入两个参数。 第一个参数为 API 服务器的 IP 地址,第二个参数为对象的候补名称列表, -形如 `IP: 或 DNS:`。 +形如 `IP: 或 DNS:`。 脚本生成三个文件: `ca.crt`、`server.crt` 和 `server.key`。 @@ -44,7 +44,7 @@ title: 证书 ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass 1. 生成服务器证书和密钥。 参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP` - 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址,`--service-cluster-ip-range`同时用于 + 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址,`--service-cluster-ip-range` 同时用于 API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。 下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。 @@ -78,7 +78,7 @@ title: 证书 openssl genrsa -out server.key 2048 1. 创建用于生成证书签名请求(CSR)的配置文件。 - 确保在将其保存至文件(如`csr.conf`)之前将尖括号标记的值(如``) + 确保在将其保存至文件(如 `csr.conf`)之前将尖括号标记的值(如 ``) 替换为你想使用的真实值。 注意:`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 diff --git a/content/zh/docs/concepts/cluster-administration/cloud-providers.md b/content/zh/docs/concepts/cluster-administration/cloud-providers.md index 2b9721d3fe..71545ed669 100644 --- a/content/zh/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/zh/docs/concepts/cluster-administration/cloud-providers.md @@ -105,5 +105,3 @@ Kubernetes 利用 OpenStack 服务目录对它知道如何使用的服务进行 bs-version=v2 ``` {{% /capture %}} - - diff --git a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md index 49c30bb7ce..6ca19ef403 100644 --- a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -9,7 +9,7 @@ content_template: templates/concept {{% capture overview %}} -集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。 +集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对[用户指南](/docs/user-guide/)中的概念有一些熟悉。 {{% /capture %}} {{% capture body %}} @@ -24,7 +24,7 @@ content_template: templates/concept - 你是打算在你的电脑上尝试 Kubernetes,还是要构建一个高可用的多节点集群?请选择最适合你需求的发行版。 - **如果你正在设计一个高可用集群**,请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。 - - 你的集群是在**本地**还是**云(IaaS)**上?Kubernetes 不能直接支持混合集群。作为代替,你可以建立多个集群。 + - 你的集群是在**本地**还是**云(IaaS)**上? Kubernetes 不能直接支持混合集群。作为代替,你可以建立多个集群。 - **如果你在本地配置 Kubernetes**,需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/),它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。 - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机(VMs)**上运行? - 你**只想运行一个集群**,还是打算**活动开发 Kubernetes 项目代码**?如果是后者,请选择一个活动开发的发行版。某些发行版只提供二进制发布版,但提供更多的选择。 @@ -49,10 +49,10 @@ content_template: templates/concept * [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可. +* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api)描述了如何为用户和 service accounts 建立权限许可。 -* [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能,包括许多认证选项。 +* [用户认证](/docs/admin/authentication)阐述了 Kubernetes 中的认证功能,包括许多认证选项。 * [授权](/docs/admin/authorization)从认证中分离出来,用于控制如何处理 HTTP 请求。 @@ -64,7 +64,7 @@ content_template: templates/concept * [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 +* [审计](/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 ### 保护 kubelet @@ -77,11 +77,9 @@ content_template: templates/concept ## 可选集群服务 -* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。 +* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 -* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。 +* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 {{% /capture %}} - - diff --git a/content/zh/docs/concepts/cluster-administration/controller-metrics.md b/content/zh/docs/concepts/cluster-administration/controller-metrics.md new file mode 100644 index 0000000000..85a46101ff --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/controller-metrics.md @@ -0,0 +1,82 @@ +--- +title: 控制器管理器指标 +content_template: templates/concept +weight: 100 +--- + + + +{{% capture overview %}} + + + +控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 什么是控制器管理器度量 + +控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。 +这些度量包括常见的 Go 语言运行时度量,比如 go_routine 计数,以及控制器特定的度量,比如 etcd 请求延迟或 云提供商(AWS、GCE、OpenStack)的 API 延迟,这些参数可以用来测量集群的健康状况。 + +从 Kubernetes 1.7 版本开始,详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。 +这些度量可用于监视持久卷操作的健康状况。 + +例如,在 GCE 中这些指标叫做: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + + + +## 配置 + +在集群中,控制器管理器指标可从它所在的主机上的 `http://localhost:10252/metrics` 中获得。 + +这些指标是以 [prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) 发出的,是人类可读的。 + +在生产环境中,您可能想配置 prometheus 或其他一些指标收集工具,以定期收集这些指标数据,并将它们应用到某种时间序列数据库中。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md new file mode 100644 index 0000000000..6947c16f7d --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -0,0 +1,261 @@ +--- +title: 配置 kubelet 垃圾回收策略 +content_template: templates/concept +weight: 70 +--- + + + +{{% capture overview %}} + +垃圾回收是 kubelet 的一个有用功能,它将清理未使用的镜像和容器。 + + + +Kubelet 将每分钟对容器执行一次垃圾回收,每五分钟对镜像执行一次垃圾回收。 + + + +不建议使用外部垃圾收集工具,因为这些工具可能会删除原本期望存在的容器进而破坏 kubelet 的行为。 + + + +{{% /capture %}} + + +{{% capture body %}} + +## 镜像回收 + + + +Kubernetes 借助于 cadvisor 通过 imageManager 来管理所有镜像的生命周期。 + + + +镜像垃圾回收策略只考虑两个因素:`HighThresholdPercent` 和 `LowThresholdPercent`。 + + + +磁盘使用率超过上限阈值(HighThresholdPercent)将触发垃圾回收。 + + + +垃圾回收将删除最近最少使用的镜像,直到磁盘使用率满足下限阈值(LowThresholdPercent)。 + + + +## 容器回收 + + + +容器垃圾回收策略考虑三个用户定义变量。 + + + +`MinAge` 是容器可以被执行垃圾回收的最小年龄。 + + + +`MaxPerPodContainer` 是每个 pod 内允许存在的死亡容器的最大数量。 + + + +`MaxContainers` 是全部死亡容器的最大数量。 + + + +可以分别独立地通过将 `MinAge` 设置为 0,以及将 `MaxPerPodContainer` 和 `MaxContainers` 设置为小于 0 来禁用这些变量。 + + + +Kubelet 将处理无法辨识的、已删除的以及超出前面提到的参数所设置范围的容器。最老的容器通常会先被移除。 + + + +`MaxPerPodContainer` 和 `MaxContainer` 在某些场景下可能会存在冲突,例如在保证每个 pod 内死亡容器的最大数量(`MaxPerPodContainer`)的条件下可能会超过允许存在的全部死亡容器的最大数量(`MaxContainer`)。 + + + +`MaxPerPodContainer` 在这种情况下会被进行调整:最坏的情况是将 `MaxPerPodContainer` 降级为 1,并驱逐最老的容器。 + + + +此外,pod 内已经被删除的容器一旦年龄超过 `MinAge` 就会被清理。 + + + +不被 kubelet 管理的容器不受容器垃圾回收的约束。 + + + +## 用户配置 + + + +用户可以使用以下 kubelet 参数调整相关阈值来优化镜像垃圾回收: + + + + + +1. `image-gc-high-threshold`,触发镜像垃圾回收的磁盘使用率百分比。默认值为 85%。 + +2. `image-gc-low-threshold`,镜像垃圾回收试图释放资源后达到的磁盘使用率百分比。默认值为 80%。 + +我们还允许用户通过以下 kubelet 参数自定义垃圾收集策略: + + + + + +1. `minimum-container-ttl-duration`,完成的容器在被垃圾回收之前的最小年龄,默认是 0 分钟,这意味着每个完成的容器都会被执行垃圾回收。 + +2. `maximum-dead-containers-per-container`,每个容器要保留的旧实例的最大数量。默认值为 1。 + +3. `maximum-dead-containers`,要全局保留的旧容器实例的最大数量。默认值是 -1,这意味着没有全局限制。 + +容器可能会在其效用过期之前被垃圾回收。这些容器可能包含日志和其他对故障诊断有用的数据。 + + + +强烈建议为 `maximum-dead-containers-per-container` 设置一个足够大的值,以便每个预期容器至少保留一个死亡容器。 + + + +由于同样的原因,`maximum-dead-containers` 也建议使用一个足够大的值。 + + + +查阅 [这个问题](https://github.com/kubernetes/kubernetes/issues/13287) 获取更多细节。 + + + +## 弃用 + + + +这篇文档中的一些 kubelet 垃圾收集(Garbage Collection)功能将在未来被 kubelet 驱逐回收(eviction)所替代。 + + + +包括: + +| 现存参数 | 新参数 | 解释 | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现存的驱逐回收信号可以触发镜像垃圾回收 | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收实现相同行为 | +| `--maximum-dead-containers` | | 一旦旧日志存储在容器上下文之外,就会被弃用 | +| `--maximum-dead-containers-per-container` | | 一旦旧日志存储在容器上下文之外,就会被弃用 | +| `--minimum-container-ttl-duration` | | 一旦旧日志存储在容器上下文之外,就会被弃用 | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 驱逐回收将磁盘阈值泛化到其他资源 | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 驱逐回收将磁盘压力转换到其他资源 | + + + +{{% /capture %}} + +{{% capture whatsnext %}} + +查阅 [配置驱逐回收资源的策略](/docs/tasks/administer-cluster/out-of-resource/) 获取更多细节。 + + + +{{% /capture %}} diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md new file mode 100755 index 0000000000..be577dfb78 --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/logging.md @@ -0,0 +1,460 @@ +--- +reviewers: +- piosz +- x13n +title: 日志架构 +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + + +应用和系统日志可以让您了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制;同样地,大多数容器引擎也被设计成支持某种日志记录机制。针对容器化应用,最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。 + + +但是,由容器引擎或 runtime 提供的原生功能通常不足以满足完整的日志记录方案。例如,如果发生容器崩溃、pod 被逐出或节点宕机等情况,您仍然想访问到应用日志。因此,日志应该具有独立的存储和生命周期,与节点、pod 或容器的生命周期相独立。这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。Kubernetes 没有为日志数据提供原生存储方案,但是您可以集成许多现有的日志解决方案到 Kubernetes 集群中。 + +{{% /capture %}} + +{{% capture body %}} + + +集群级日志架构假定在集群内部或者外部有一个日志后台。如果您对集群级日志不感兴趣,您仍会发现关于如何在节点上存储和处理日志的描述对您是有用的。 + + +## Kubernetes 中的基本日志记录 + +本节,您会看到一个kubernetes 中生成基本日志的例子,该例子中数据被写入到标准输出。 +这里通过一个特定的 [pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器,并令该容器每秒钟向标准输出写入数据。 + +{{< codenew file="debug/counter-pod.yaml" >}} + + +用下面的命令运行 pod: + +```shell +$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml +pod/counter created +``` + + +使用 `kubectl logs` 命令获取日志: + +```shell +$ kubectl logs counter +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + + +一旦发生容器崩溃,您可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。 +如果 pod 中有多个容器,您应该向该命令附加一个容器名以访问对应容器的日志。 +详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。 + + +## 节点级日志记录 + +![Node level logging](/images/docs/user-guide/logging/logging-node-level.png) + + +容器化应用写入 `stdout` 和 `stderr` 的任何数据,都会被容器引擎捕获并被重定向到某个位置。 +例如,Docker 容器引擎将这两个输出流重定向到某个 [日志驱动](https://docs.docker.com/engine/admin/logging/overview) , +该日志驱动在 Kubernetes 中配置为以 json 格式写入文件。 + + +{{< note >}} +Docker json 日志驱动将日志的每一行当作一条独立的消息。该日志驱动不直接支持多行消息。您需要在日志代理级别或更高级别处理多行消息。 +{{< /note >}} + + +默认情况下,如果容器重启,kubelet 会保留被终止的容器日志。 +如果 pod 在工作节点被驱逐,该 pod 中所有的容器也会被驱逐,包括容器日志。 + + +节点级日志记录中,需要重点考虑实现日志的轮转,以此来保证日志不会消耗节点上所有的可用空间。 +Kubernetes 当前并不负责轮转日志,而是通过部署工具建立一个解决问题的方案。 +例如,在 Kubernetes 集群中,用 `kube-up.sh` 部署一个每小时运行的工具 [`logrotate`](https://linux.die.net/man/8/logrotate)。 +您也可以设置容器 runtime 来自动地轮转应用日志,比如使用 Docker 的 `log-opt` 选项。 +在 `kube-up.sh` 脚本中,使用后一种方式来处理 GCP 上的 COS 镜像,而使用前一种方式来处理其他环境。 +这两种方式,默认日志超过 10MB 大小时都会触发日志轮转。 + + +例如,您可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息, +相应的脚本在 [这里][cosConfigureHelper]。 + + +当运行 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) 时, +节点上的 kubelet 处理该请求并直接读取日志文件,同时在响应中返回日志文件内容。 + +{{< note >}} + +当前,如果有其他系统机制执行日志轮转,那么 `kubectl logs` 仅可查询到最新的日志内容。 +比如,一个 10MB 大小的文件,通过`logrotate` 执行轮转后生成两个文件,一个 10MB 大小,一个为空,所以 `kubectl logs` 将返回空。 + +[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch">}}/cluster/gce/gci/configure-helper.sh +{{< /note >}} + + +### 系统组件日志 + +有两种类型的系统组件,运行在容器中的和未运行在容器中的。例如: + + +* 运行在容器中的 Kubernetes 调度器和 kube-proxy。 +* 未运行在容器中的 kubelet 和容器 runtime,比如 Docker。 + + +在使用 systemd 机制的服务器上,kubelet 和容器 runtime 写入日志到 journald。 +如果没有 systemd,他们写入日志到 `/var/log` 目录的 `.log` 文件。 +容器中的系统组件通常将日志写到 `/var/log` 目录,绕过了默认的日志机制。他们使用 [glog][glog] 日志库。 +您可以在[日志开发文档](https://git.k8s.io/community/contributors/devel/logging.md)找到这些组件的日志告警级别协议。 + + +和容器日志类似,`/var/log` 目录中的系统组件日志也应该被轮转。 +通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中,日志被工具 `logrotate` 执行每日轮转,或者日志大小超过 100MB 时触发轮转。 + +[glog]: https://godoc.org/github.com/golang/glog + + +## 集群级别日志架构 + + +虽然 Kubernetes 并未提供原生的集群级记录日志方案,但是您可以考虑几种常见的方式。以下是一些选项: + +* 使用运行在各个节点上的节点级日志代理。 +* 在应用程序的 pod 中,包含专门记录日志的 sidecar 容器。 +* 在应用程序中将日志直接推送到后台。 + + +### 使用节点级日志代理 + +![Using a node level logging agent](/images/docs/user-guide/logging/logging-with-node-agent.png) + + +您可以在每个节点上使用 _节点级的日志代理_ 来实现集群级日志记录。 +日志代理是专门的工具,它会暴露出日志或将日志推送到后台。 +通常来说,日志代理是一个容器,这个容器可以访问这个节点上所有应用容器的日志目录。 + + +因为日志代理必须在每个节点上运行,所以通常的实现方式为,DaemonSet 副本、manifest pod 或者专用于本地的进程。 +但是后两种方式已被弃用并且不被推荐。 + + +对于 Kubernetes 集群来说,使用节点级的日志代理是最常用和被推荐的方式,因为在每个节点上仅创建一个代理,并且不需要对节点上的应用做修改。 +但是,节点级的日志 _仅适用于应用程序的标准输出和标准错误输出_。 + + +Kubernetes 并不指定日志代理,但是有两个可选的日志代理与 Kubernetes 发行版一起发布。 +[Stackdriver 日志](/docs/user-guide/logging/stackdriver) 适用于 Google Cloud Platform,和 [Elasticsearch](/docs/user-guide/logging/elasticsearch)。 +您可以在专门的文档中找到更多的信息和说明。两者都使用 [fluentd](http://www.fluentd.org/) 与自定义配置作为节点上的代理。 + + +### 使用 sidecar 容器和日志代理 + + +您可以通过以下方式之一使用 sidecar 容器: + + +* sidecar 容器将应用程序日志传送到自己的标准输出。 +* sidecar 容器运行一个日志代理,配置该日志代理以便从应用容器收集日志。 + + +#### 传输数据流的 sidecar 容器 + + +利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式,您就可以利用每个节点上的 kubelet 和日志代理来处理日志。 +sidecar 容器从文件,socket 或 journald 读取日志。每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。 + + +这种方式允许您分离出不同的日志流,这些日志流来自您应用的不同功能,其中一些可能缺乏对写入 `stdout` 和 `stderr` 的支持。 +重定向背后的逻辑很小,所以不会是很严重的开销。 +除此之外,因为 kubelet 处理 `stdout` 和 `stderr`,所以您照样可以使用 `kubectl logs` 工具。 + + +考虑接下来的例子。pod 的容器向两个文件写不同格式的日志,下面是这个 pod 的配置文件: + +{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} + + +在同一个日志流中有两种不同格式的日志条目,这有点混乱,即使您试图重定向它们到容器的 `stdout` 流。 +取而代之的是,您可以引入两个 sidecar 容器。 +每一个 sidecar 容器可以从共享卷跟踪特定的日志文件,并重定向文件内容到各自的 `stdout` 流。 + + +这是运行两个 sidecar 容器的 pod 文件。 + +{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}} + + +现在当您运行这个 pod 时,您可以分别地访问每一个日志流,运行如下命令: + +```shell +$ kubectl logs counter count-log-1 +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +```shell +$ kubectl logs counter count-log-2 +Mon Jan 1 00:00:00 UTC 2001 INFO 0 +Mon Jan 1 00:00:01 UTC 2001 INFO 1 +Mon Jan 1 00:00:02 UTC 2001 INFO 2 +... +``` + + +无需深入配置,集群中的节点级代理即可自动地收集流日志。如果您愿意,您可以配置代理程序来解析源容器的日志行。 + + +注意,尽管 CPU 和内存使用率都很低(以多个 cpu millicores 指标排序或者按 memory 的兆字节排序), +向文件写日志然后输出到 `stdout` 流仍然会成倍地增加磁盘使用率。 +如果您的应用向单一文件写日志,通常最好设置 `/dev/stdout` 作为目标路径,而不是使用流式的 sidecar 容器方式。 + + +应用本身如果不具备轮转日志文件的功能,可以通过 sidecar 容器实现。 +该方式的 [例子](https://github.com/samsung-cnct/logrotate) 是运行一个定期轮转日志的容器。 +然而,还是推荐直接使用 `stdout` 和 `stderr`,将日志的轮转和保留策略交给 kubelet。 + + +### 具有日志代理功能的 sidecar 容器 + +![Sidecar container with a logging agent](/images/docs/user-guide/logging/logging-with-sidecar-agent.png) + + +如果节点级的日志代理对您的环境来说不够灵活,您可以在 sidecar 容器中创建一个独立的、专门为您的应用而配置的日志代理。 + + +{{< note >}} +在 sidecar 容器中使用日志代理会导致严重的资源损耗。此外,您不能使用 `kubectl logs` 命令访问日志,因为日志并没有被 kubelet 管理。 +{{< /note >}} + + +例如,您可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),它用 fluentd 作为日志代理。 +这是实现此种方式的两个配置文件。 +第一个文件包含配置 fluentd 的 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。 + +{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} + + +{{< note >}} +fluentd 的配置文件已经超出了本文的讨论范畴。 +有关配置 fluentd 的更多信息,请见 [官方 fluentd 文档](http://docs.fluentd.org/)。 +{{< /note >}} + + +第二个文件描述了运行 fluentd sidecar 容器的 pod 。flutend 通过 pod 的挂载卷获取它的配置数据。 + +{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} + + +一段时间后,您可以在 Stackdriver 界面看到日志消息。 + + +记住,这只是一个例子,事实上您可以用任何一个日志代理替换 fluentd ,并从应用容器中读取任何资源。 + + + +### 从应用中直接暴露日志目录 + +![Exposing logs directly from the application](/images/docs/user-guide/logging/logging-from-application.png) + + +通过暴露或推送每个应用的日志,您可以实现集群级日志记录;然而,这种日志记录机制的实现已超出 Kubernetes 的范围。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/cluster-administration/manage-deployment.md b/content/zh/docs/concepts/cluster-administration/manage-deployment.md new file mode 100644 index 0000000000..c8589e45f8 --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/manage-deployment.md @@ -0,0 +1,629 @@ +--- +reviewers: +- bgrant0607 +- janetkuo +- mikedanese +title: 管理资源 +content_template: templates/concept +weight: 40 +--- + + +{{% capture overview %}} + + +您已经部署了应用并通过服务暴露它。然后呢?Kubernetes 提供了一些工具来帮助管理您的应用部署,包括缩扩容和更新。我们将更深入讨论的特性包括[配置文件](/docs/concepts/configuration/overview/)和[标签](/docs/concepts/overview/working-with-objects/labels/)。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 组织资源配置 + +许多应用需要创建多个资源,例如 Deployment 和 Service。可以通过将多个资源组合在同一个文件中(在 YAML 中以 `---` 分隔)来简化对它们的管理。例如: + +{{< codenew file="application/nginx-app.yaml" >}} + + +可以用创建单个资源相同的方式来创建多个资源: + +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx-app.yaml +service/my-nginx-svc created +deployment.apps/my-nginx created +``` + + +资源将按照它们在文件中的顺序创建。因此,最好先指定服务,这样在控制器(例如 Deployment)创建 Pod 时能够确保调度器可以将与服务关联的多个 Pod 分散到不同节点。 + + +`kubectl create` 也接受多个 `-f` 参数: + +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + + +还可以指定目录路径,而不用添加多个单独的文件: + +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx/ +``` + + +`kubectl` 将读取任何后缀为 `.yaml`,`.yml` 或者 `.json` 的文件。 + +建议的做法是,将同一个微服务或同一应用层相关的资源放到同一个文件中,将同一个应用相关的所有文件按组存放到同一个目录中。如果应用的各层使用 DNS 相互绑定,那么您可以简单地将堆栈的所有组件一起部署。 + +还可以使用 URL 作为配置源,便于直接使用已经提交到 Github 上的配置文件进行部署: + +```shell +$ kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml +deployment.apps/my-nginx created +``` + + +## kubectl 中的批量操作 + +资源创建并不是 `kubectl` 可以批量执行的唯一操作。`kubectl` 还可以从配置文件中提取资源名,以便执行其他操作,特别是删除您之前创建的资源: + +```shell +$ kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + + +在仅有两种资源的情况下,可以使用"资源类型/资源名"的语法在命令行中同时指定这两个资源: + +```shell +$ kubectl delete deployments/my-nginx services/my-nginx-svc +``` + + +对于资源数目较大的情况,您会发现使用 `-l` 或 `--selector` 指定的筛选器(标签查询)能很容易根据标签筛选资源: + +```shell +$ kubectl delete deployment,services -l app=nginx +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + + +由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同,所以很容易使用 `$()` 或 `xargs` 进行链式操作: + +```shell +$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s +``` + + +上面的命令中,我们首先使用 `examples/application/nginx/` 下的配置文件创建资源,并使用 `-o name` 的输出格式(以"资源/名称"的形式打印每个资源)打印所创建的资源。然后,我们通过 `grep` 来过滤 "service",最后再打印 `kubectl get` 的内容。 + + +如果您碰巧在某个路径下的多个子路径中组织资源,那么也可以递归地在所有子路径上执行操作,方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。 + + +例如,假设有一个目录路径为 `project/k8s/development`,它保存开发环境所需的所有清单,并按资源类型组织: + +``` +project/k8s/development +├── configmap +│   └── my-configmap.yaml +├── deployment +│   └── my-deployment.yaml +└── pvc + └── my-pvc.yaml +``` + + +默认情况下,对 `project/k8s/development` 执行的批量操作将停止在目录的第一级,而不是处理所有子目录。 +如果我们试图使用以下命令在此目录中创建资源,则会遇到一个错误: + +```shell +$ kubectl create -f project/k8s/development +error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) +``` + + +然而,在 `--filename,-f` 后面标明 `--recursive` 或者 `-R` 之后: + +```shell +$ kubectl create -f project/k8s/development --recursive +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + + +`--recursive` 可以用于接受 `--filename,-f` 参数的任何操作,例如:`kubectl {create,get,delete,describe,rollout}` 等。 + +有多个 `-f` 参数出现的时候,`--recursive` 参数也能正常工作: + +```shell +$ kubectl create -f project/k8s/namespaces -f project/k8s/development --recursive +namespace/development created +namespace/staging created +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + + +如果您有兴趣学习更多关于 `kubectl` 的内容,请阅读 [kubectl 概述](/docs/reference/kubectl/overview/)。 + + +## 有效地使用标签 + +到目前为止我们使用的示例中的资源最多使用了一个标签。在许多情况下,应使用多个标签来区分集合。 + + +例如,不同的应用可能会为 `app` 标签设置不同的值。 +但是,类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 这样的多层应用,还需要区分每一层。前端可以带以下标签: + +```yaml + labels: + app: guestbook + tier: frontend +``` + + +Redis 的主节点和从节点会有不同的 `tier` 标签,甚至还有一个额外的 `role` 标签: + +```yaml + labels: + app: guestbook + tier: backend + role: master +``` + + +以及 + +```yaml + labels: + app: guestbook + tier: backend + role: slave +``` + + +标签允许我们按照标签指定的任何维度对我们的资源进行切片和切块: + +```shell +$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml +$ kubectl get pods -Lapp -Ltier -Lrole +NAME READY STATUS RESTARTS AGE APP TIER ROLE +guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend +guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend +guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend +guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master +guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave +guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave +my-nginx-divi2 1/1 Running 0 29m nginx +my-nginx-o0ef1 1/1 Running 0 29m nginx +$ kubectl get pods -lapp=guestbook,role=slave +NAME READY STATUS RESTARTS AGE +guestbook-redis-slave-2q2yf 1/1 Running 0 3m +guestbook-redis-slave-qgazl 1/1 Running 0 3m +``` + + +## 金丝雀部署 + + +另一个需要多标签的场景是用来区分同一组件的不同版本或者不同配置的多个部署。常见的做法是部署一个使用*金丝雀发布*来部署新应用版本(在 pod 模板中通过镜像标签指定),保持新旧版本应用同时运行,这样,新版本在完全发布之前也可以接收实时的生产流量。 + + +例如,您可以使用 `track` 标签来区分不同的版本。 + +主要稳定的发行版将有一个 `track` 标签,其值为 `stable`: + +```yaml + name: frontend + replicas: 3 + ... + labels: + app: guestbook + tier: frontend + track: stable + ... + image: gb-frontend:v3 +``` + + +然后,您可以创建 guestbook 前端的新版本,让这些版本的 `track` 标签带有不同的值(即 `canary`),以便两组 pod 不会重叠: + +```yaml + name: frontend-canary + replicas: 1 + ... + labels: + app: guestbook + tier: frontend + track: canary + ... + image: gb-frontend:v4 +``` + + +前端服务通过选择标签的公共子集(即忽略 `track` 标签)来覆盖两组副本,以便流量可以转发到两个应用: + +```yaml + selector: + app: guestbook + tier: frontend +``` + + +您可以调整 `stable` 和 `canary` 版本的副本数量,以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心,您就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`,并且将老版本应用删除。 + + +想要了解更具体的示例,请查看 [Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。 + + +## 更新标签 + +有时,现有的 pod 和其它资源需要在创建新资源之前重新标记。这可以用 `kubectl label` 完成。 +例如,如果想要将所有 nginx pod 标记为前端层,只需运行: + +```shell +$ kubectl label pods -l app=nginx tier=fe +pod/my-nginx-2035384211-j5fhi labeled +pod/my-nginx-2035384211-u2c7e labeled +pod/my-nginx-2035384211-u3t6x labeled +``` + + +首先用标签 "app=nginx" 过滤所有的 pod,然后用 "tier=fe" 标记它们。想要查看您刚才标记的 pod,请运行: + +```shell +$ kubectl get pods -l app=nginx -L tier +NAME READY STATUS RESTARTS AGE TIER +my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe +my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe +my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe +``` + + +这将输出所有 "app=nginx" 的 pod,并有一个额外的描述 pod 的 tier 的标签列(用参数 `-L` 或者 `--label-columns` 标明)。 + +想要了解更多信息,请参考 [标签](/docs/concepts/overview/working-with-objects/labels/) 和 [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)。 + + +## 更新注解 + +有时,您可能希望将注解附加到资源中。注解是 API 客户端(如工具、库等)用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如: + +```shell +$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' +$ kubectl get pods my-nginx-v4-9gw19 -o yaml +apiversion: v1 +kind: pod +metadata: + annotations: + description: my frontend running nginx +... +``` + + +想要了解更多信息,请参考 [注解](/docs/concepts/overview/working-with-objects/annotations/) 和 [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 文档。 + + +## 缩扩您的应用 + +当应用上的负载增长或收缩时,使用 `kubectl` 能够轻松实现规模的缩扩。例如,要将 nginx 副本的数量从 3 减少到 1,请执行以下操作: + +```shell +$ kubectl scale deployment/my-nginx --replicas=1 +deployment.extensions/my-nginx scaled +``` + + +现在,您的 deployment 管理的 pod 只有一个了。 + +```shell +$ kubectl get pods -l app=nginx +NAME READY STATUS RESTARTS AGE +my-nginx-2035384211-j5fhi 1/1 Running 0 30m +``` + + +想要让系统自动选择需要 nginx 副本的数量,范围从 1 到 3,请执行以下操作: + +```shell +$ kubectl autoscale deployment/my-nginx --min=1 --max=3 +horizontalpodautoscaler.autoscaling/my-nginx autoscaled +``` + + +现在,您的 nginx 副本将根据需要自动地增加或者减少。 + +想要了解更多信息,请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 和 [pod 水平自动伸缩](/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 + + +## 就地更新资源 + +有时,有必要对您所创建的资源进行小范围、无干扰地更新。 + +### kubectl apply + + +建议在源代码管理中维护一组配置文件(参见[配置即代码](http://martinfowler.com/bliki/InfrastructureAsCode.html)),这样,它们就可以和应用代码一样进行维护和版本管理。然后,您可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。 + + +这个命令将会把推送的版本与以前的版本进行比较,并应用您所做的更改,但是不会自动覆盖任何你没有指定更改的属性。 + +```shell +$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +deployment.apps/my-nginx configured +``` + + +注意,`kubectl apply` 将为资源增加一个额外的注解,以确定自上次调用以来对配置的更改。当调用它时,`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间找出三方差异,以确定如何修改资源。 + + +目前,新创建的资源是没有这个注解的,所以,第一次调用 `kubectl apply` 将使用提供的输入和资源的当前配置双方之间差异进行比较。在第一次调用期间,它无法检测资源创建时属性集的删除情况。因此,不会删除它们。 + + +所有后续调用 `kubectl apply` 以及其它修改配置的命令,如 `kubectl replace` 和 `kubectl edit`,都将更新注解,并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。 + + +{{< note >}} +想要使用 apply,请始终使用 `kubectl apply` 或 `kubectl create --save-config` 创建资源。 +{{< /note >}} + +### kubectl edit + + +或者,您也可以使用 `kubectl edit` 更新资源: + +```shell +$ kubectl edit deployment/my-nginx +``` + + +这相当于首先 `get` 资源,在文本编辑器中编辑它,然后用更新的版本 `apply` 资源: + +```shell +$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml +$ vi /tmp/nginx.yaml +# do some edit, and then save the file +$ kubectl apply -f /tmp/nginx.yaml +deployment.apps/my-nginx configured +$ rm /tmp/nginx.yaml +``` + + +这使您可以更加容易地进行更重大的更改。请注意,可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。 + +想要了解更多信息,请参考 [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。 + +### kubectl patch + + +您可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch,JSON merge patch,以及 strategic merge patch。 请参考 +[使用 kubectl patch 更新 API 对象](/docs/tasks/run-application/update-api-object-kubectl-patch/) +和 +[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). + + +## 破坏性的更新 + +在某些情况下,您可能需要更新某些初始化后无法更新的资源字段,或者您可能只想立即进行递归更改,例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段,请使用 `replace --force`,它将删除并重新创建资源。在这种情况下,您可以简单地修改原始配置文件: + +```shell +$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force +deployment.apps/my-nginx deleted +deployment.apps/my-nginx replaced +``` + + +## 在不中断服务的情况下更新应用 + + +在某些时候,您最终需要更新已部署的应用,通常都是通过指定新的镜像或镜像标签,如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作,每种更新操作都适用于不同的场景。 + + +我们将指导您通过 Deployment 如何创建和更新应用。如果部署的应用由 `ReplicationController` 管理,那么您应该阅读 [怎么样使用 `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/)。 + + +假设您正运行的是 1.7.9 版本的 nginx: + +```shell +$ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3 +deployment.apps/my-nginx created +``` + + +要更新到 1.9.1 版本,只需使用我们前面学到的 kubectl 命令将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 修改为 `nginx:1.9.1`。 + +```shell +$ kubectl edit deployment/my-nginx +``` + + +没错,就是这样!Deployment 将在后台逐步更新已经部署的 nginx 应用。它确保在更新过程中,只有一定数量的旧副本被开闭,并且只有一定基于所需 pod 数量的新副本被创建。想要了解更多细节,请参考 [Deployment](/docs/concepts/workloads/controllers/deployment/)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +- [学习怎么样使用 `kubectl` 观察和调试应用](/docs/tasks/debug-application-cluster/debug-application-introspection/) +- [配置最佳实践和技巧](/docs/concepts/configuration/overview/) + +{{% /capture %}} diff --git a/content/zh/docs/concepts/configuration/_index.md b/content/zh/docs/concepts/configuration/_index.md new file mode 100644 index 0000000000..5bf9c6c138 --- /dev/null +++ b/content/zh/docs/concepts/configuration/_index.md @@ -0,0 +1,11 @@ +--- +title: "配置" +weight: 70 +--- + + \ No newline at end of file diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md index 0d798d058b..b92823614d 100644 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md @@ -1,22 +1,74 @@ --- +title: 为容器管理计算资源 +content_template: templates/concept +weight: 20 +feature: + title: 自动装箱 + description: > + 根据资源需求和其他约束自动放置容器,同时不会牺牲可用性,将任务关键工作负载和尽力服务工作负载进行混合放置,以提高资源利用率并节省更多资源。 +--- + + {{% capture overview %}} -当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存(RAM)大小。当为容器指定了资源请求后,调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制,节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 + +当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存(RAM)大小。当为容器指定了资源请求后,调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制,Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 {{% /capture %}} {{% capture body %}} + + ## 资源类型 -*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是 core,内存的单位是 byte。 +*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是核心数,内存的单位是字节。 -CPU和内存统称为*计算资源* ,也可以称为*资源* 。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源(如 Pod 和 [Service](/docs/user-guide/services))是可通过 Kubernetes API server 读取和修改的对象。 +CPU和内存统称为*计算资源*,也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源(如 Pod 和 [Service](/docs/concepts/services-networking/service/))是可通过 Kubernetes API server 读取和修改的对象。 + + ## Pod 和 容器的资源请求和限制 @@ -29,6 +81,27 @@ Pod 中的每个容器都可以指定以下的一个或者多个值: 尽管只能在个别容器上指定请求和限制,但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 + + ## CPU 的含义 CPU 资源的限制和请求以 *cpu* 为单位。 @@ -44,6 +117,14 @@ Kubernetes 中的一个 cpu 等于: CPU 总是要用绝对数量,不可以使用相对数量;0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 + + ## 内存的含义 内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存:E,P,T,G,M,K。您还可以使用两个字母的等效的幂数:Ei,Pi,Ti ,Gi,Mi,Ki。例如,以下代表大致相同的值: @@ -52,6 +133,14 @@ CPU 总是要用绝对数量,不可以使用相对数量;0.1 的 CPU 在单 128974848, 129e6, 129M, 123Mi ``` + + 下面是个例子。 以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB(226 字节)内存,每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存,限制为 1 cpu 和 256MiB 的内存。 @@ -83,27 +172,91 @@ spec: cpu: "500m" ``` + + ## 具有资源请求的 Pod 如何调度 当您创建一个 Pod 时,Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量:可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型,调度的容器的资源请求的总和小于节点的容量。请注意,尽管节点上的实际内存或 CPU 资源使用量非常低,但如果容量检查失败,则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时,例如在请求率的每日峰值期间,这可以防止节点上的资源短缺。 + + ## 具有资源限制的 Pod 如何运行 当 kubelet 启动一个 Pod 的容器时,它会将 CPU 和内存限制传递到容器运行时。 当使用 Docker 时: -- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值,这是个浮点数,并乘以1024,这个数字中的较大者或2用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 + + +- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值,这是个浮点数,并乘以 1024,这个数字中的较大者或 2 用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 + - `spec.containers[].resources.limits.cpu` 被转换成 millicore 值。被乘以 100000 然后 除以 1000。这个数字用作 `docker run` 命令中的 [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) 标志的值。[`--cpu-quota` ] 标志被设置成了 100000,表示测量配额使用的默认100ms 周期。如果 [`--cpu-cfs-quota`] 标志设置为 true,则 kubelet 会强制执行 cpu 限制。从 Kubernetes 1.2 版本起,此标志默认为 true。 + + + + {{< note >}} + 默认配额限制为 100 毫秒。 CPU配额的最小单位为 1 毫秒。 + {{}} + - `spec.containers[].resources.limits.memory` 被转换为整型,作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。 + + 如果容器超过其内存限制,则可能会被终止。如果可重新启动,则与所有其他类型的运行时故障一样,kubelet 将重新启动它。 如果一个容器超过其内存请求,那么当节点内存不足时,它的 Pod 可能被逐出。 容器可能被允许也可能不被允许超过其 CPU 限制时间。但是,由于 CPU 使用率过高,不会被杀死。 -要确定容器是否由于资源限制而无法安排或被杀死,请参阅 [疑难解答](#troubleshooting) 部分。 +要确定容器是否由于资源限制而无法安排或被杀死,请参阅[疑难解答](#troubleshooting) 部分。 + + ## 监控计算资源使用 @@ -111,6 +264,14 @@ Pod 的资源使用情况被报告为 Pod 状态的一部分。 如果为集群配置了 [可选监控](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md),则可以从监控系统检索 Pod 资源的使用情况。 + + ## 疑难解答 ### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling @@ -124,8 +285,29 @@ Events: 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others ``` + + 在上述示例中,由于节点上的 CPU 资源不足,名为 “frontend” 的 Pod 将无法调度。由于内存不足(PodExceedsFreeMemory),类似的错误消息也可能会导致失败。一般来说,如果有这种类型的消息而处于 pending 状态,您可以尝试如下几件事情: +- 向集群添加更多节点。 +- 终止不需要的 Pod,为待处理的 Pod 腾出空间。 +- 检查 Pod 所需的资源是否大于所有节点的资源。 例如,如果全部节点的容量为`cpu:1`,那么一个请求为 `cpu:1.1`的 Pod 永远不会被调度。 + +您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如: + + ```shell $ kubectl describe nodes e2e-test-minion-group-4lw4 Name: e2e-test-minion-group-4lw4 @@ -156,6 +338,21 @@ Allocated resources: 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) ``` + + 在上面的输出中,您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存,节点将无法满足。 通过查看 `Pods` 部分,您将看到哪些 Pod 占用的节点上的资源。 @@ -164,6 +361,13 @@ Pod 可用的资源量小于节点容量,因为系统守护程序使用一部 可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用,就可以防止一个团队占用所有资源。 + + ## 我的容器被终止了 您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死,请在相关的 Pod 上调用 `kubectl describe pod`: @@ -210,6 +414,13 @@ Events: 您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 + + ```shell [13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-60xbc Container Name: simmemleak @@ -218,6 +429,10 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 您可以看到容器因为 `reason:OOM killed` 被终止,`OOM` 表示 Out Of Memory。 + + ## 不透明整型资源(Alpha功能) Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源允许集群运维人员发布新的节点级资源,否则系统将不了解这些资源。 @@ -275,6 +490,26 @@ spec: pod.alpha.kubernetes.io/opaque-int-resource-foo: 1 ``` + + ## 计划改进 在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量,如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。 @@ -288,12 +523,15 @@ Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168 {{% /capture %}} {{% capture whatsnext %}} + - 获取将 [CPU 和内存资源分配给容器](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) 的实践经验 - [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core) - [ResourceRequirements](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core) {{% /capture %}} - - - diff --git a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md new file mode 100644 index 0000000000..ac311a8e46 --- /dev/null +++ b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -0,0 +1,280 @@ +--- +title: 使用 kubeconfig 文件组织集群访问 +content_template: templates/concept +weight: 60 +--- + + +{{% capture overview %}} + + +使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息,并与集群的 API 服务器进行通信。 + + +{{< note >}} +注意:用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件 +{{< /note >}} + + +默认情况下,`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。您可以通过设置 `KUBECONFIG` 环境变量或者设置[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。 + + +有关创建和指定 kubeconfig 文件的分步说明,请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 支持多集群、用户和身份认证机制 + + +假设您有多个集群,并且您的用户和组件以多种方式进行身份认证。比如: + + +- 正在运行的 kubelet 可能使用证书在进行认证。 +- 用户可能通过令牌进行认证。 +- 管理员可能拥有多个证书集合提供给各用户。 + + +使用 kubeconfig 文件,您可以组织集群、用户和命名空间。您还可以定义上下文,以便在集群和命名空间之间快速轻松地切换。 + + +## 上下文(Context) + + +通过 kubeconfig 文件中的 *context* 元素,使用简便的名称来对访问参数进行分组。每个上下文都有三个参数:cluster、namespace 和 user。默认情况下,`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。 + + +选择当前上下文 +``` +kubectl config use-context +``` + + +## KUBECONFIG 环境变量 + + +`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。对于 Linux 和 Mac,列表以冒号分隔。对于 Windows,列表以分号分隔。`KUBECONFIG` 环境变量不是必要的。如果 `KUBECONFIG` 环境变量不存在,`kubectl` 使用默认的 kubeconfig 文件,`$HOME/.kube/config`。 + + +如果 `KUBECONFIG` 环境变量存在,`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。 + + +## 合并 kubeconfig 文件 + + +要查看配置,输入以下命令: +```shell +kubectl config view +``` + + +如前所述,输出可能来自 kubeconfig 文件,也可能是合并多个 kubeconfig 文件的结果。 + + +以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。 + + +1. 如果设置了 `--kubeconfig` 参数,则仅使用指定的文件。不进行合并。此参数只能使用一次。 + + 否则,如果设置了 `KUBECONFIG` 环境变量,将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件: + + * 忽略空文件名。 + * 对于内容无法反序列化的文件,产生错误信息。 + * 第一个设置特定值或者映射键的文件将生效。 + * 永远不会更改值或者映射键。示例:保留第一个文件的上下文以设置 `current-context`。示例:如果两个文件都指定了 `red-user`,则仅使用第一个文件的 `red-user` 中的值。即使第二个文件在 `red-user` 下有非冲突条目,也要丢弃它们。 + + + 有关设置 `KUBECONFIG` 环境变量的示例,请参阅[设置 KUBECONFIG 环境变量](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 + + + 否则,使用默认的 kubeconfig 文件, `$HOME/.kube/config`,不进行合并。 + + +1. 根据此链中的第一个匹配确定要使用的上下文。 + + 1. 如果存在,使用 `--context` 命令行参数。 + 2. 使用合并的 kubeconfig 文件中的 `current-context`。 + + + 这种场景下允许空上下文。 + + +1. 确定集群和用户。此时,可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户,这将运行两次:一次用于用户,一次用于集群。 + + 1. 如果存在,使用命令行参数:`--user` 或者 `--cluster`。 + 2. 如果上下文非空,从上下文中获取用户或集群。 + + + 这种场景下用户和集群可以为空。 + + +1. 确定要使用的实际集群信息。此时,可能有也可能没有集群信息。基于此链构建每个集群信息;第一个匹配项会被采用: + + 1. 如果存在:`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`,使用命令行参数。 + 2. 如果合并的 kubeconfig 文件中存在集群信息属性,则使用它们。 + 3. 如果没有 server 配置,则配置无效。 + + +2. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息,但每个用户只允许一种身份认证技术: + + 1. 如果存在:`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`,使用命令行参数。 + 2. 使用合并的 kubeconfig 文件中的 `user` 字段。 + 3. 如果存在两种冲突技术,则配置无效。 + + +3. 对于仍然缺失的任何信息,使用其对应的默认值,并可能提示输入身份认证信息。 + + +## 文件引用 + + +kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中,相对路径按相对路径存储,绝对路径按绝对路径存储。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + + +* [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) +{{% /capture %}} + + diff --git a/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md b/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md new file mode 100644 index 0000000000..3ca2c81c8d --- /dev/null +++ b/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md @@ -0,0 +1,175 @@ +--- +reviewers: +- bsalamat +title: 调度器性能调优 +content_template: templates/concept +weight: 70 +--- + + + +{{% capture overview %}} + +{{< feature-state for_k8s_version="1.12" >}} + + + +Kube-scheduler 是 Kubernetes 的默认调度器。负责将 Pods 安排到集群中的节点上。 +集群中达到 Pod 调度要求的节点也被称为这个 Pod 的“可行性”节点。 +调度器首先找出 Pod 的可行性节点,然后运行一套打分函数来为可行性节点打分, +最后挑选出分数最高的可行性节点来运行 Pod。随后,调度器将这个决定通知给 API 服务器, +这个通知流程叫做“绑定”("Binding")。 + +{{% /capture %}} + +{{% capture body %}} + + +## 可行性打分的节点比例 + + + +在 Kubernetes 1.12 之前, Kube-scheduler 曾经是检查集群中所有节点的可行性,并为它们依次打分。 +而在 Kubernetes 1.12 中加入了一项新的功能,允许调度器在找到足够合适的可行性节点之后,停止搜索。 +这项功能将提高调度器在大型集群应用中的性能。这是一个比例参数,通过一个名为 `percentageOfNodesToScore` 的配置选项, +指明了集群大小中的比例。参数值范围在 1 到 100 之间。其它的数值将被认为是 100%。 +选项的默认值为 50%。集群管理员也可以在调度器的配置文件中,提供不同数值来做修改。 +但可能也并不需要修改这个值。 + +```yaml +apiVersion: componentconfig/v1alpha1 +kind: KubeSchedulerConfiguration +algorithmSource: + provider: DefaultProvider + +... + +percentageOfNodesToScore: 50 +``` + +{{< note >}} + + + +**注意**:如果集群中可行性节点的数量为 0 或者小于 50 个,调度器还是会检查所有的节点, +仅仅是因为没有足够多的可行性节点让调度器终止搜索。 + +{{< /note >}} + + + + +可以将 `percentageOfNodesToScore` 设置为 100 来**禁止这项功能**。 + + +### 调优 `percentageOfNodesToScore` + + + +`percentageOfNodesToScore` 的数值必须在 1 到 100 之间,默认值为 50。 +在内部设计里面,还存在有硬编码的至少 50 个节点的要求。无论 `percentageOfNodesToScore` 设置如何, +调度器都至少会搜索 50 个节点。换言之,在只有数百个节点的集群中调低这个参数,并不会对调度器搜索可行性节点有影响。 +这样设计是经过考虑的,因为在较小的集群中,这个参数并不会显著提升性能。 +而在超过 1000 个节点的大型集群中调低这个参数,将会有显著的性能提升。 + + + +在设置这个数值时,需要注意一点,如果集群中只有较少的一部分节点进行了可行性检查, +有些节点将不会被作可行性打分。 +因而,有运行 Pod 可行性分数更高的节点甚至可能不会到达打分阶段。这会造成一个并不十分理想的安排结果。 +正因为如此,这个数值不应该设置得非常低。 +一个重要原则就是这个数值不应该小于 30。 +更小的数值只应该在应用对调度器的吞吐量十分敏感,而节点的可行性打分相对不重要的前提下使用。 +换言之,只要节点适合运行 Pod 就可以安排到该节点上运行。 + + + +如果集群只有数百个节点,我们不建议将参数值调到比默认值低。因为这并不能显著提升调度器的性能。 + + +### 调度器是如何遍历节点的 + + + +这一节是为那些希望了解这项功能内部细节的人准备的。 + + + +为了让集群中所有的节点都有平等的机会被考虑运行 Pods,调度器需要以轮转的方式遍历所有的节点。 +你可以这样理解:所有节点都在记录在某数组之中,调度器从数组的一端开始检查节点的可行性,直到找到 `percentageOfNodesToScore` +指明的、足够多的节点。对于下一个 pod,调度器将从前一个 Pod 的结束节点开始,继续开始搜索。 + + + +如果节点在不同的区域,调度器也将遍历不同区域的所有节点,保证不同区域的节点都会被考虑在列。 +例如,如果六个节点分布在两个区域: + +``` +Zone 1: Node 1, Node 2, Node 3, Node 4 +Zone 2: Node 5, Node 6 +``` + + + +调度器将会按照下面的顺序来对所有的节点进行可行性检查: + +``` +Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 +``` + + + +当遍历完所有的节点后,会重新从 Node 1 开始搜索。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md index fd1a9d0377..09f05c46cc 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh/docs/concepts/configuration/secret.md @@ -548,13 +548,13 @@ spec: ### 客户端使用 Secret API -当部署与 secret API 交互的应用程序时,应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。 +当部署与 secret API 交互的应用程序时,应使用诸如 [RBAC](/docs/admin/authorization/rbac/) 之类的 [授权策略](/docs/admin/authorization/) 来限制访问。 Secret 中的值对于不同的环境来说重要性可能不同,例如对于 Kubernetes 集群内部(例如 service account 令牌)和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力,但是同一命名空间中的其他应用程序却可能不这样认为。 由于这些原因,在命名空间中 `watch` 和 `list` secret 的请求是非常强大的功能,应该避免这样的行为,因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中`watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。 -需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问,同时设置 [白名单访问](https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。 +需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问,同时设置 [白名单访问](/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。 为了提高循环获取的性能,客户端可以设计引用 secret 的资源,然后 `watch` 资源,在引用更改时重新请求 secret。此外,还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源,该功能可能会在将来的 Kubernetes 版本中提供。 diff --git a/content/zh/docs/concepts/containers/_index.md b/content/zh/docs/concepts/containers/_index.md new file mode 100644 index 0000000000..b17230af3a --- /dev/null +++ b/content/zh/docs/concepts/containers/_index.md @@ -0,0 +1,11 @@ +--- +title: "容器" +weight: 50 +--- + + \ No newline at end of file diff --git a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000..1a7c51db72 --- /dev/null +++ b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,229 @@ +--- +reviewers: +- mikedanese +- thockin +title: 容器生命周期钩子 +content_template: templates/concept +weight: 30 +--- + + + + +{{% capture overview %}} + + +这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 概述 + + +类似于许多具有生命周期钩子组件的编程语言框架,例如Angular,Kubernetes为容器提供了生命周期钩子。 +钩子使容器能够了解其管理生命周期中的事件,并在执行相应的生命周期钩子时运行在处理程序中实现的代码。 + + + +## 容器钩子 + + +有两个钩子暴露在容器中: + +`PostStart` + + +这个钩子在创建容器之后立即执行。 +但是,不能保证钩子会在容器入口点之前执行。 +没有参数传递给处理程序。 + +`PreStop` + + +在容器终止之前立即调用此钩子。 +它是阻塞的,同时也是同步的,因此它必须在删除容器的调用之前完成。 +没有参数传递给处理程序。 + + +有关终止行为的更详细描述,请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。 + + + +### 钩子处理程序的实现 + + +容器可以通过实现和注册该钩子的处理程序来访问该钩子。 +针对容器,有两种类型的钩子处理程序可供实现: + + + +* Exec - 执行一个特定的命令,例如 `pre-stop.sh`,在容器的 cgroups 和名称空间中。 +命令所消耗的资源根据容器进行计算。 +* HTTP - 对容器上的特定端点执行 HTTP 请求。 + + + +### 钩子处理程序执行 + + +当调用容器生命周期管理钩子时,Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。 + + +钩子处理程序调用在包含容器的 Pod 上下文中是同步的。 +这意味着对于 `PostStart` 钩子,容器入口点和钩子异步触发。 +但是,如果钩子运行或挂起的时间太长,则容器无法达到 `running` 状态。 + + +行为与 `PreStop` 钩子的行为类似。 +如果钩子在执行过程中挂起,Pod 阶段将保持在 `Terminating` 状态,并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。 +如果 `PostStart` 或 `PreStop` 钩子失败,它会杀死容器。 + + +用户应该使他们的钩子处理程序尽可能的轻量级。 +但也需要考虑长时间运行的命令也很有用的情况,比如在停止容器之前保存状态。 + + + +### 钩子寄送保证 + + +钩子的寄送应该是*至少一次*,这意味着对于任何给定的事件,例如 `PostStart` 或 `PreStop`,钩子可以被调用多次。 +如何正确处理,是钩子实现所要考虑的问题。 + + +通常情况下,只会进行单次寄送。 +例如,如果 HTTP 钩子接收器宕机,无法接收流量,则不会尝试重新发送。 +然而,偶尔也会发生重复寄送的可能。 +例如,如果 kubelet 在发送钩子的过程中重新启动,钩子可能会在 kubelet 恢复后重新发送。 + + + +### 调试钩子处理程序 + + +钩子处理程序的日志不会在 Pod 事件中公开。 +如果处理程序由于某种原因失败,它将播放一个事件。 +对于 `PostStart`,这是 `FailedPostStartHook` 事件,对于 `PreStop`,这是 `FailedPreStopHook` 事件。 +您可以通过运行 `kubectl describe pod ` 命令来查看这些事件。 +下面是运行这个命令的一些事件输出示例: + +``` +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。 +* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md index cc123251be..09d7fed735 100644 --- a/content/zh/docs/concepts/containers/images.md +++ b/content/zh/docs/concepts/containers/images.md @@ -124,13 +124,13 @@ Docker将私有仓库的密钥存放在`$HOME/.dockercfg`或`$HOME/.docker/confi 推荐如下步骤来为node配置私有仓库。以下示例在PC或笔记本电脑中操作 - 1.对于想要使用的每一种凭证,运行 `docker login [server]`,它会更新`$HOME/.docker/config.json`。 - 1.使用编辑器查看`$HOME/.docker/config.json`,保证文件中包含了想要使用的凭证 - 1.获取node列表,例如 - - 如果使用node名称,`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - - 如果使用node IP ,`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` - 1.将本地的`.docker/config.json`拷贝到每个节点root用户目录下 - - 例如: `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done` + 1. 对于想要使用的每一种凭证,运行 `docker login [server]`,它会更新`$HOME/.docker/config.json`。 + 1. 使用编辑器查看`$HOME/.docker/config.json`,保证文件中包含了想要使用的凭证 + 1. 获取node列表,例如 + - 如果使用node名称,`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` + - 如果使用node IP ,`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + 1. 将本地的`.docker/config.json`拷贝到每个节点root用户目录下 + - 例如: `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done` 创建使用私有仓库的pod来验证,例如: diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000..4029826901 --- /dev/null +++ b/content/zh/docs/concepts/containers/runtime-class.md @@ -0,0 +1,197 @@ +--- +reviewers: +- tallclair +- dchen1107 +title: RuntimeClass +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + + +本页面讨论了 RuntimeClass 资源和运行时的选择机制。 + +{{% /capture %}} + +{{< toc >}} + +{{% capture body %}} + +## RuntimeClass + + +RuntimeClass 是一个 alpha 功能,用来选择运行 pod 中容器的容器运行时配置。 + + +### 设置 + + +作为一个处于早期状态的 alpha 特性,必须要完成以下步骤才能使用 RuntimeClass 功能: + + +1. 开启 RuntimeClass 特性门控(在 apiservers & kubelets 上,需要 1.12 及以上版本) +2. 安装 RuntimeClass CRD +3. 在节点上配置 CRI 的实现(取决于所选的运行时) +4. 创建相应的 RuntimeClass 资源 + + +#### 1. 开启 RuntimeClass 特性门控 + + +参见[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)文档了解如何开启特定的特性门控。 +`RuntimeClass` 特性门控必须在 apiservers _和_ kubelets 上同时开启,才能使用。 + + +#### 2. 安装 RuntimeClass CRD + + +可以在 Kubernetes git 仓库的 addons 目录中找到 +RuntimeClass [CustomResourceDefinition (CRD)](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) 的定义: + +https://github.com/kubernetes/kubernetes/tree/release-1.12/cluster/addons/runtimeclass/runtimeclass_crd.yaml + + + +使用 `kubectl apply -f runtimeclass_crd.yaml` 命令安装 CRD。 + + +#### 3. 在节点上配置 CRI 实现 + + +各 RuntimeClass 所支持的配置选项取决于 CRI 的实现本身。 +请参阅 CRI 实现的相应文档了解具体如何配置。 +由于这是一个 alpha 特性功能,并非所有 CRI 都支持多个 RuntimeClass。 + + +{{< note >}} +RuntimeClass 当前假设的是集群中的节点配置是同构的(换言之,所有的节点在容器运行时方面的配置是相同的)。 +任何异构性(不同的配置)必须通过调度功能在 RuntimeClass 之外单独管理(请参阅[在节点上分配 Pods](/docs/concepts/configuration/assign-pod-node/))。 +{{< /note >}} + + +所有这些配置都具有相应的 `RuntimeHandler` 名,并被 RuntimeClass 引用。 +RuntimeHandler 必须是有效的 DNS-1123 子域(字母数字字符、`-` 或 `.`)。 + + + +#### 4. 创建相应的 RuntimeClass 资源 + + +步骤 3 中的配置设置应该有相应的 `RuntimeHandler` 名,用于标识配置。 +对应每个 RuntimeHandler(以及 `""` 所代表的空处理程序),都创建相应的 RuntimeClass 对象。 + + +RuntimeClass 资源当前只有两个重要的字段:RuntimeClass 名 (`metadata.name`) 和 RuntimeHandler (`spec.runtimeHandler`)。 +对象定义如下所示: + +```yaml +apiVersion: node.k8s.io/v1alpha1 # 在 node.k8s.io API 中对 RuntimeClass 进行定义 +kind: RuntimeClass +metadata: + name: myclass # 引用 RuntimeClass + # RuntimeClass 是不属于任何名字空间的资源 +spec: + runtimeHandler: myconfiguration # 给出 CRI 配置的名称 +``` + + + +{{< note >}} +建议将 RuntimeClass 写操作(create、update、patch 和 delete)限定于集群管理员使用。 +通常这是默认配置。参阅[授权概述](/docs/reference/access-authn-authz/authorization/)了解更多信息。 +{{< /note >}} + + + +### 使用说明 + +一旦完成集群中 RuntimeClasses 的配置,使用起来非常简便。 +在 Pod spec 中指定 `runtimeClassName` 即可。例如: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + + + +这一设置会告诉 Kubelet 使用所指的 RuntimeClass 来运行该 pod。 +如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler,那么 pod 将会进入 `Failed` 终止[阶段](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +你可以查看相应的[事件](/docs/tasks/debug-application-cluster/debug-application-introspection/),获取出错信息。 + + +如果未指定 `runtimeClassName` ,则将使用默认的 RuntimeHandler,相当于禁用 RuntimeClass 功能特性。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000..9eef5fffc5 --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,11 @@ +--- +title: 扩展 Kubernetes +weight: 40 +--- + + diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md new file mode 100644 index 0000000000..51c5bdcc7a --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -0,0 +1,11 @@ +--- +title: 扩展 Kubernetes API +weight: 20 +--- + + diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md new file mode 100644 index 0000000000..11dc1e423a --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -0,0 +1,73 @@ + + +--- +title: 通过聚合层扩展 Kubernetes API +reviewers: +- lavalamp +- cheftako +- chenopis +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + + + +聚合层允许 Kubernetes 通过额外的 API 进行扩展,而不局限于 Kubernetes 核心 API 提供的功能。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 概述 + +聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。 + + + +1.7 版本中,聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前,聚合层不做任何事情。要注册 API,用户必须添加一个 APIService 对象,用它来申领 Kubernetes API 中的 URL 路径。自此以后,聚合层将会把发给该 API 路径的所有内容(例如 /apis/myextension.mycompany.io/v1/…)代理到已注册的 APIService。 + + + +正常情况下,APIService 会实现为运行于集群中某 Pod 内的 extension-apiserver。如果需要对增加的资源进行动态管理,extension-apiserver 经常需要和一个或多个控制器一起使用。因此,apiserver-builder 同时提供用来管理新资源的 API 框架和控制器框架。另外一个例子,当安装了 service-catalog 时,它会为自己提供的服务提供 extension-apiserver 和控制器。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 阅读[配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 文档,了解如何在自己的环境中启用聚合器(aggregator)。 +* 然后[安装扩展的 api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 来开始使用聚合层。 +* 也可以学习怎样 [使用客户资源定义扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 + +{{% /capture %}} + + diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md new file mode 100644 index 0000000000..1b46b18dd2 --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md @@ -0,0 +1,11 @@ +--- +title: 计算、存储和网络扩展 +weight: 30 +--- + + diff --git a/content/zh/docs/concepts/overview/_index.md b/content/zh/docs/concepts/overview/_index.md new file mode 100644 index 0000000000..87550923ff --- /dev/null +++ b/content/zh/docs/concepts/overview/_index.md @@ -0,0 +1,11 @@ +--- +title: 概述 +weight: 20 +--- + + diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index d164080b4e..3937cb01be 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/content/zh/docs/concepts/overview/kubernetes-api.md @@ -2,11 +2,11 @@ [API协议文档](https://git.k8s.io/community/contributors/devel/api-conventions.md)描述了主系统和API概念。 -[API参考文档](https://kubernetes.io/docs/reference)描述了API整体规范。 +[API参考文档](/docs/reference)描述了API整体规范。 -[访问文档](https://kubernetes.io/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。 +[访问文档](/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。 -Kubernetes API是系统描述性配置的基础。 [Kubectl](https://kubernetes.io/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。 +Kubernetes API是系统描述性配置的基础。 [Kubectl](/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。 Kubernetes 通过API资源存储自己序列化状态(现在存储在[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/))。 @@ -77,11 +77,11 @@ Kubernetes实现了另一种基于Protobuf的序列化格式,该格式主要 1. 核心组(通常被称为遗留组)位于REST路径 **`/api/v1`** 并使用 **`apiVersion:v1`**。 -1. 指定的组位于REST路径 **`/apis/$GROUP_NAME/$VERSION`**,并使用 **`apiVersion:$GROUP_NAME/$VERSION`**(例如 **`apiVersion:batch/v1`**)。 在[Kubernetes API参考](https://kubernetes.io/docs/reference/)中可以看到支持的API组的完整列表。 +1. 指定的组位于REST路径 **`/apis/$GROUP_NAME/$VERSION`**,并使用 **`apiVersion:$GROUP_NAME/$VERSION`**(例如 **`apiVersion:batch/v1`**)。 在[Kubernetes API参考](/docs/reference/)中可以看到支持的API组的完整列表。 -社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/): +社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](/docs/concepts/api-extension/custom-resources/): -1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)适用于具有非常基本的CRUD需求的用户。 +1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)适用于具有非常基本的CRUD需求的用户。 1. 即将推出:需要全套Kubernetes API语义的用户可以实现自己的apiserver,并使用[聚合器](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)为客户提供无缝的服务。 diff --git a/content/zh/docs/concepts/overview/object-management-kubectl/_index.md b/content/zh/docs/concepts/overview/object-management-kubectl/_index.md new file mode 100644 index 0000000000..3ee775f5a6 --- /dev/null +++ b/content/zh/docs/concepts/overview/object-management-kubectl/_index.md @@ -0,0 +1,11 @@ +--- +title: "用 kubectl 管理对象" +weight: 50 +--- + + diff --git a/content/zh/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/zh/docs/concepts/overview/object-management-kubectl/imperative-config.md new file mode 100644 index 0000000000..ac923edef9 --- /dev/null +++ b/content/zh/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -0,0 +1,262 @@ +--- +title: 使用配置文件指令式管理 Kubernetes 对象 +content_template: templates/concept +weight: 30 +--- + + + +{{% capture overview %}} + +通过使用 `kubectl` 命令行工具和 yaml 或 json 格式编写的对象配置文件,用户可以创建、更新和删除 Kubernetes 对象。 +本文档介绍如何使用配置文件定义和管理对象。 +{{% /capture %}} + +{{% capture body %}} + + +## 取舍权衡 + + + +`kubectl` 工具支持三种对象管理: + + +* 指令性命令 +* 指令性对象配置 +* 声明式对象配置 + + +请参阅[Kubernetes 对象管理](/docs/concepts/overview/object-management-kubectl/overview/) 以了解每种对象管理的优缺点。 + + +## 怎样创建对象 + + + +可以使用 `kubectl create -f` 从配置文件创建对象。 +有关详细信息,请参阅[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 + +- `kubectl create -f ` + + +## 怎样更新对象 + +{{< warning >}} + +使用 `replace` 命令更新对象时,系统将会删除配置文件的 spec 中未指定的所有内容。 +对于部分上由集群来管理的对象而言,不要使用这种对象管理方式。 + +例如,对于 `LoadBalancer` 类型的服务而言,其 `externalIPs` 字段值是独立于配置文件进行管理的。 +独立管理的字段必须复制到配置文件中,以防止被 `replace` 操作删除。 +{{< /warning >}} + + +您可以使用 `kubectl replace -f` 命令基于配置文件来更新活跃状态的对象。 + +- `kubectl replace -f ` + + +## 怎样删除对象 + + + +您可以使用 `kubectl delete -f` 命令来删除配置文件中描述的对象。 + +- `kubectl delete -f ` + + +## 怎样查看对象 + + + +您可以使用 `kubectl get -f` 命令来查看配置文件中描述的对象的信息。 + +- `kubectl get -f -o yaml` + + + +指定了 `-o yaml` 参数将会打印完整的对象配置。 +使用 `kubectl get -h` 命令查看选项列表。 + + +## 限制 + + +当每个对象的配置都完整的定义和记录在它的配置文件中时,`create`、`replace` 和 `delete` 命令就能正常使用。 +然而,当一个存活态的对象被更新、并且更新的内容没有被合入该对象的配置文件时,下次再执行 `replace` 命令将导致更新的内容丢失。 +如果控制器(如 HorizontalPodAutoscaler)直接更新存活态的对象,就会发生上面的情况。 +下面是个例子: + + + +1. 从配置文件创建对象。 +1. 另外一个资源更新这个对象的一些字段。 +1. 从配置文件中替换(replace)该对象。第二步中另外的资源对该对象所做的更新将丢失。 + + +如果您需要对同一对象支持多个写者,那么可以使用 `kubectl apply` 命令管理该对象。 + + +## 通过 URL 创建和编辑对象而不保存配置 + + + +假设您知道一个对象配置文件的 URL。 +您可以在对象被创建之前使用 `kubectl create --edit` 命令来更改它的配置。 +这对于指向那些读者可修改配置文件的教程和任务特别有用。 + +```sh +kubectl create -f --edit +``` + + +## 从指令性命令迁移到指令性对象配置 + + +从指令性命令迁移到指令性对象配置包括几个手动步骤。 + + +1. 将存活态的对象导出为本地对象配置文件: +```sh +kubectl get / -o yaml --export > _.yaml +``` +1. 手动从对象配置文件中移除状态信息。 +1. 对于后续的对象管理,只使用 `replace`。 +```sh +kubectl replace -f _.yaml +``` + + +## 定义控制器选择器和 PodTemplate 标签 + +{{< warning >}} + +强烈不建议更新控制器的选择器。 +{{< /warning >}} + + +建议的方法是定义一个单一的、不变的 PodTemplate 标签,该标签仅由控制器选择器使用,没有其他语义意义。 + + +标签示例: + +```yaml +selector: + matchLabels: + controller-selector: "extensions/v1beta1/deployment/nginx" +template: + metadata: + labels: + controller-selector: "extensions/v1beta1/deployment/nginx" +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + +- [使用指令性命令管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [使用对象配置文件(声明式)管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl/) +- [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +{{% /capture %}} + + diff --git a/content/zh/docs/concepts/overview/working-with-objects/_index.md b/content/zh/docs/concepts/overview/working-with-objects/_index.md new file mode 100644 index 0000000000..477bdc5b18 --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/_index.md @@ -0,0 +1,11 @@ +--- +title: "使用 Kubernetes 对象" +weight: 40 +--- + + diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000..91bd7064e1 --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,129 @@ +--- +title: 注解 +content_template: templates/concept +weight: 50 +--- + + + +{{% capture overview %}} + +你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序(例如工具和库)能够获取这些元数据信息。 + +{{% /capture %}} + +{{% capture body %}} +## 为对象附加元数据 + + +您可以使用标签或注解将元数据附加到 Kubernetes 对象。标签可以用来选择对象和查找满足某些条件的对象集合。 + + +相反,注解不用于标识和选择对象。 +注解中的元数据,可以很小,也可以很大,可以是结构化的,也可以是非结构化的,能够包含标签不允许的字符。 + + +注解和标签一样,是键/值对: + + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +以下是一些例子,用来说明哪些信息可以使用注解来记录: + + +* 由声明性配置所管理的字段。 + 将这些字段附加为注解,能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。 + + + +* 构建、发布或镜像信息(如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址)。 + + + +* 指向日志记录、监控、分析或审计仓库的指针。 + + + +* 可用于调试目的的客户端库或工具信息:例如,名称、版本和构建信息。 + + + +* 用户或者工具/系统的来源信息,例如来自其他生态系统组件的相关对象的 URL。 + + + +* 推出的轻量级工具的元数据信息:例如,配置或检查点。 + + + +* 负责人员的电话或呼机号码,或指定在何处可以找到该信息的目录条目,如团队网站。 + + + +您可以将这类信息存储在外部数据库或目录中而不使用注解,但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。 + + +{{% /capture %}} + +{{% capture whatsnext %}} +进一步了解[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000..b00442633c --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,106 @@ +--- +title: 字段选择器 +weight: 60 +--- + + + +字段选择器允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +下面是一些使用字段选择器查询的例子: + + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +下面这个 `kubectl` 命令将筛选出[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)字段值为 `Running` 的所有 Pod: + + +```shell +$ kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} + +字段选择器本质上是资源*过滤器*。默认情况下,字段选择器/过滤器是未被应用的,这意味着指定类型的所有资源都会被筛选出来。 +这使得以下的两个 `kubectl` 查询是等价的: + + +```shell +$ kubectl get pods +$ kubectl get pods --field-selector "" +``` +{{< /note >}} + +## 支持的字段 + + +不同的 Kubernetes 资源类型支持不同的字段选择器。 +所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。 +使用不被支持的字段选择器会产生错误,例如: + + +```shell +$ kubectl get ingress --field-selector foo.bar=baz +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +## 支持的运算符 + + +您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算(`=` 和 `==` 的意义是相同的)。 +例如,下面这个 `kubectl` 命令将筛选所有不属于 `default` 名称空间的 Kubernetes Service: + + +```shell +$ kubectl get services --field-selector metadata.namespace!=default +``` + +## 链式选择器 + + +同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样,字段选择器可以通过使用逗号分隔的列表组成一个选择链。 +下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod: + + +```shell +$ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## 多种资源类型 + + +您能够跨多种资源类型来使用字段选择器。 +下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service: + + +```shell +$ kubectl get statefulsets,services --field-selector metadata.namespace!=default +``` diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..3bc5554c5e --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,378 @@ +--- +title: 标签和选择器 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + + +_标签_ 是附加到 Kubernetes 对象(比如 Pods)上的键值对。 +标签旨在用于指定对用户有意义且相关的对象的标识属性,但不直接对核心系统有语义含义。 +标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象,随后可以随时添加和修改。 +每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。 + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + + + +我们最终将标签索引和反向索引,用于高效查询和监视,使用它们在 UI 和 CLI 中进行排序和分组等。我们不希望将非标识性的、尤其是大型或结构化数据用作标签,给后者带来污染。应使用 [注解](/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 动机 + + +标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象,而无需客户端存储这些映射。 + + +服务部署和批处理流水线通常是多维实体(例如,多个分区或部署、多个发行序列、多个层,每层多个微服务)。管理通常需要交叉操作,这打破了严格的层次表示的封装,特别是由基础设施而不是用户确定的严格的层次结构。 + + +示例标签: + + * `"release" : "stable"`, `"release" : "canary"` + * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` + * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` + * `"partition" : "customerA"`, `"partition" : "customerB"` + * `"track" : "daily"`, `"track" : "weekly"` + + +这些只是常用标签的例子; 您可以任意制定自己的约定。请记住,对于给定对象标签的键必须是唯一的。 + + +## 语法和字符集 + + + +_标签_ 是键值对。有效的标签键有两个段:可选的前缀和名称,用斜杠(`/`)分隔。名称段是必需的,必须小于等于 63 个字符,以字母数字字符(`[a-z0-9A-Z]`)开头和结尾,带有破折号(`-`),下划线(`_`),点( `.`)和之间的字母数字。前缀是可选的。如果指定,前缀必须是 DNS 子域:由点(`.`)分隔的一系列 DNS 标签,总共不超过 253 个字符,后跟斜杠(`/`)。 +如果省略前缀,则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件(例如 `kube-scheduler`,`kube-controller-manager`,`kube-apiserver`,`kubectl` 或其他第三方自动化)必须指定前缀。`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。 + + +有效标签值必须为 63 个字符或更少,并且必须为空或以字母数字字符(`[a-z0-9A-Z]`)开头和结尾,中间可以包含破折号(`-`)、下划线(`_`)、点(`.`)和字母或数字。 + + +## 标签选择器 + + +与 [名称和 UID](/docs/user-guide/identifiers) 不同,标签不提供唯一性。通常,我们希望许多对象携带相同的标签。 + + +通过 _标签选择器_,客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。 + + +API 目前支持两种类型的选择器:_基于相等性的_ 和 _基于集合的_。 +标签选择器可以由逗号分隔的多个 _需求_ 组成。在多个需求的情况下,必须满足所有要求,因此逗号分隔符充当逻辑 _与_(`&&`)运算符。 + + +空标签选择器(即,需求为零的选择器)选择集合中的每个对象。 + + +null 值的标签选择器(仅可用于可选选择器字段)不选择任何对象 +{{< note >}} + +**注意**:两个控制器的标签选择器不得在命名空间内重叠,否则它们将互相冲突。 +{{< /note >}} + + +### _基于相等性的_ 需求 + + + +_基于相等性_ 或 _不相等_ 的需求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束,尽管它们也可能具有其他标签。 +可接受的运算符有`=`、`==` 和 `!=` 三种。 前两个表示 _相等_(并且只是同义词),而后者表示 _不相等_。 例如: + +``` +environment = production +tier != frontend +``` + + +前者选择所有资源,其键名等于 `environment`,值等于 `production`。 +后者选择所有资源,其键名等于 `tier`,值不同于 `frontend`,所有资源都没有带有 `tier` 键的标签。 +可以使用逗号运算符来过滤 `production` 环境中的非 `frontend` 层资源:`environment=production,tier!=frontend`。 + + +基于相等性的标签要求的一种使用场景是 Pods 要指定节点选择标准。例如,下面的示例 Pod 选择带有标签 "`accelerator=nvidia-tesla-p100`"。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + + +### _基于集合_ 的需求 + + +_基于集合_ 的标签需求允许您通过一组值来过滤键。支持三种操作符:`in`,`notin` and `exists` (只可以用在键标识符上)。例如: + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + + + +第一个示例选择了所有键等于 `environment` 并且值等于 `production` 或者 `qa` 的资源。 + + + +第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源,以及所有没有 `tier` 键标签的资源。 + + + +第三个示例选择了所有包含了有 `partition` 标签的资源;没有校验它的值。 + + + +第三个示例选择了所有没有 `partition` 标签的资源;没有校验它的值。 + + +类似地,逗号分隔符充当 _AND_ 运算符。因此,使用 `partition` 键(无论为何值)和 `environment` 不同于 `qa` 来过滤资源可以使用 `partition,environment notin(qa)` 来实现。 + + + +_基于集合_ 的标签选择器是相等标签选择器的一般形式,因为 `environment = production` 等同于 `environment in(production)`;`!=` 和 `notin` 也是类似的。 + + +_基于集合_ 的要求可以与基于 _相等_ 的要求混合使用。例如:`partition in (customerA, customerB),environment!=qa`。 + +## API + + +### LIST 和 WATCH 过滤 + + +LIST and WATCH 操作可以使用查询参数指定标签选择器过滤一组对象。两种需求都是允许的。(这里显示的是它们出现在 URL 查询字符串中) + + + * _基于相等性_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + + +两种标签选择器都可以通过 REST 客户端用于 list 或者 watch 资源。例如,使用 `kubectl` 定位 `apiserver`,可以使用 _基于相等性_ 的标签选择器可以这么写: + + +```shell +$ kubectl get pods -l environment=production,tier=frontend +``` + + +或者使用 _基于集合的_ 需求: + +```shell +$ kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + + +正如刚才提到的,_基于集合_ 的需求更具有表达力。例如,它们可以实现值的 _或_ 操作: + +```shell +$ kubectl get pods -l 'environment in (production, qa)' +``` + + +或者通过 _exists_ 运算符限制不匹配: + +```shell +$ kubectl get pods -l 'environment,environment notin (frontend)' +``` + + +### 在 API 对象上设置引用 + +一些 Kubernetes 对象,例如 [`services`](/docs/user-guide/services) 和 [`replicationcontrollers`](/docs/user-guide/replication-controller) ,也使用了标签选择器去指定了其他资源的集合,例如 [pods](/docs/user-guide/pods)。 + + +#### Service 和 ReplicationController + +一个 `Service` 指向的一组 pods 是由标签选择器定义的。同样,一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择器定义的。 + +两个对象的标签选择器都是在 `json` 或者 `yaml` 文件中使用映射定义的,并且只支持 _基于相等性_ 需求的选择器: + +```json +"selector": { + "component" : "redis", +} +``` + + +或者 + +```yaml +selector: + component: redis +``` + + +这个选择器(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。 + + +#### 支持基于集合需求的资源 + +比较新的资源,例如 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)、[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`Replica Set`](/docs/concepts/workloads/controllers/replicaset/) 和[`Daemon Set`](/docs/concepts/workloads/controllers/daemonset/) ,也支持 _基于集合的_ 需求。 + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - {key: tier, operator: In, values: [cache]} + - {key: environment, operator: NotIn, values: [dev]} +``` + + + +`matchLabels` 是由 `{key,value}` 对组成的映射。`matchLabels` 映射中的单个 `{key,value }` 等同于 `matchExpressions` 的元素,其 `key`字段为 "key",`operator` 为 "In",而 `values` 数组仅包含 "value"。`matchExpressions` 是 pod 选择器要求的列表。有效的运算符包括 In,NotIn,Exists 和 DoesNotExist。在 In 和 NotIn 的情况下,设置的值必须是非空的。来自 `matchLabels` 和 `matchExpressions` 的所有要求都是合在一起 -- 它们必须都满足才能匹配。 + + +#### 选择节点集 + + +通过标签进行选择的一个用例是确定节点集,方便 pod 调度。 +有关更多信息,请参阅 [选择节点](/docs/concepts/configuration/assign-pod-node/) 上的文档。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000..4645df7e15 --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,66 @@ +--- +title: 名称 +content_template: templates/concept +weight: 20 +--- + + + +{{% capture overview %}} + +Kubernetes REST API 中的所有对象都通过名称和 UID 明确标识。 + + + +对于用户提供的非惟一属性,Kubernetes 提供 [标签](/docs/user-guide/labels) 和 +[注解](/docs/concepts/overview/working-with-objects/annotations/)。 + + + +查看 [标识设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 获取名称和 UID 的精确语法规则。 + + + +{{% /capture %}} + + +{{% capture body %}} + +## 名称 + + + +{{< glossary_definition term_id="name" length="all" >}} + +按照惯例,Kubernetes 资源的名称最长可达 253 个字符,并由小写字母、数字、 “-” 和 “.” 组成,但某些资源可能有更具体的限制。 + + + +## UID + + + +{{< glossary_definition term_id="uid" length="all" >}} + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000..59c8849170 --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,219 @@ +--- +title: 命名空间 +content_template: templates/concept +weight: 30 +--- + + +{{% capture overview %}} + +Kubernetes 支持多个虚拟集群,它们底层依赖于同一个物理集群。 +这些虚拟集群被称为命名空间。 + + +{{% /capture %}} + +{{% capture body %}} + +## 何时使用多个命名空间 + + +命名空间适用于存在很多跨多个团队或项目的用户的场景。 +对于只有几到几十个用户的集群,根本不需要创建或考虑命名空间。 + + +当您需要命名空间提供的特性时,请开始使用它们。 + + +命名空间为名称提供了一个范围。 +资源的名称需要在命名空间内是惟一的,但不能跨命名空间。 + + +命名空间是在多个用户之间划分集群资源的一种方法(通过[资源配额](/docs/concepts/policy/resource-quotas/))。 + + +在 Kubernetes 未来版本中,相同命名空间中的对象默认将具有相同的访问控制策略。 + + +不需要使用多个命名空间来分隔轻微不同的资源,例如同一软件的不同版本: +使用[标签](/docs/user-guide/labels)来区分同一命名空间中的不同资源。 + + +## 使用命名空间 + + +命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。 + + +### 查看命名空间 + + +您可以使用以下命令列出集群中现存的命名空间: + + +```shell +$ kubectl get namespaces +NAME STATUS AGE +default Active 1d +kube-system Active 1d +kube-public Active 1d +``` + +Kubernetes 会创建三个初始命名空间: + + + * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间 + + * `default` The default namespace for objects with no other namespace + --> + * `kube-system` Kubernetes 系统创建对象所使用的命名空间 + + * `kube-system` The namespace for objects created by the Kubernetes system + --> + * `kube-public` 这个命名空间是自动创建的,所有用户(包括未经过身份验证的用户)都可以读取它。这个命名空间主要用于集群使用,以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定,而不是要求。 + + * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. + --> + +### 为请求设置命名空间 + + +要临时设置请求的命名空间,请使用 `--namespace` 参数。 + + +例如: + + +```shell +$ kubectl --namespace= run nginx --image=nginx +$ kubectl --namespace= get pods +``` + +### 设置命名空间首选项 + + +您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。 + + +```shell +$ kubectl config set-context $(kubectl config current-context) --namespace= +# Validate it +$ kubectl config view | grep namespace: +``` + +## 命名空间和 DNS + + +当您创建一个[服务](/docs/user-guide/services)时,Kubernetes 会创建一个相应的[DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。 + + +该条目的形式是 `..svc.cluster.local`, +这意味着如果容器只使用 ``,它将被解析到本地命名空间的服务。 + + +这对于跨多个命名空间(如开发、分级和生产)使用相同的配置非常有用。 + +This is useful for using the same configuration across +multiple namespaces such as Development, Staging and Production. +--> +如果您希望跨命名空间访问,则需要使用完全限定域名(FQDN)。 + + +## 并非所有对象都在命名空间中 + + +大多数 kubernetes 资源(例如 Pod、服务、副本控制器等)都位于某些命名空间中。 +但是命名空间资源本身并不在命名空间中。 + + +而且底层资源,例如[节点](/docs/admin/node)和持久化卷不属于任何命名空间。 + + +查看哪些 Kubernetes 资源在命名空间中,哪些不在命名空间中: + + +```shell +# In a namespace +$ kubectl api-resources --namespaced=true + +# Not in a namespace +$ kubectl api-resources --namespaced=false +``` + +{{% /capture %}} diff --git a/content/zh/docs/concepts/policy/_index.md b/content/zh/docs/concepts/policy/_index.md new file mode 100644 index 0000000000..a724a7dd47 --- /dev/null +++ b/content/zh/docs/concepts/policy/_index.md @@ -0,0 +1,11 @@ +--- +title: "策略" +weight: 160 +--- + + diff --git a/content/zh/docs/concepts/services-networking/_index.md b/content/zh/docs/concepts/services-networking/_index.md new file mode 100644 index 0000000000..905f25af01 --- /dev/null +++ b/content/zh/docs/concepts/services-networking/_index.md @@ -0,0 +1,11 @@ +--- +title: "服务、负载均衡和联网" +weight: 80 +--- + + diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md new file mode 100644 index 0000000000..6fdb5df8c8 --- /dev/null +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -0,0 +1,674 @@ +--- +reviewers: +- bprashanth +title: Ingress +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +{{< glossary_definition term_id="ingress" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + + + +## 专用术语 + +在本文档中,您将看到一些有时在其他地方可互换使用的术语,这些术语可能会引起混淆。 本节试图澄清它们 + +* 节点:Kubernetes 集群中的单个虚拟或物理机器。 +* 集群:互联网防火墙保护下的一组节点,它们是 Kubernetes 管理的主要计算资源。 +* 边缘路由器:为集群强制执行防火墙策略的路由器。这可以是由云提供商管理的网关或物理硬件。 +* 集群网络:一组逻辑或物理的链接,根据 [Kubernetes 网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。集群网络的例子包括 覆盖网络,例如 [flannel](https://github.com/coreos/flannel#flannel);或者SDN,例如 [OVS](https://www.openvswitch.org/)。 +* 服务:Kubernetes [服务](/docs/concepts/services-networking/service/) 使用标签选择器标识一组 Pod。除非另有说明,否则假定服务只具有在集群网络中可路由的虚拟 IP。 + + + +## Ingress 是什么? + +通常,服务 和 Pod 具有仅能在集群网络内路由的 IP 地址。在边缘路由器结束的所有流量都被丢弃或转发到别处。从概念上讲,这可能看起来像: + +```none + internet + | + ------------ + [ Services ] +``` + + + +Ingress 是允许连接到集群 Service 的规则集合。 + +``` + 互联网 + | + [ Ingress ] + --|-----|-- + [ Services ] +``` + + + +它可以被配置为提供外部可访问的URL、负载均衡流量、终止SSL、提供基于名称的虚拟托管等等。 +用户通过向 API 服务器 POST Ingress 资源来请求 Ingress。 +[Ingress 控制器](#ingress-controllers) 负责实现 Ingress,它通常使用负载均衡器,不过它也可以配置边缘路由器或其他前端,从而帮助用户以 HA 方式处理流量。 + + + +## 环境准备 + +在开始使用 Ingress 资源之前,有一些事情您应该了解。 +Ingress 是 beta 资源,在 1.1 之前的任何 Kubernetes 版本中都不可用。 +您需要一个 Ingress 控制器来满足 Ingress,否则简单地创建资源将不起作用。 + +GCE/Google Kubernetes Engine 是在主节点上部署 Ingress 控制器。 +您可以在 Pod 中部署任意数量的自定义 Ingress 控制器。 +您必须使用适当的类来注释每个 Ingress,如[这里](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) 和 [这里](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class) 所示。 + +一定要检查一下这个控制器的 [beta 限制](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)。 +在 GCE/Google Kubernetes Engine 之外的环境中,需要将[控制器部署](https://git.k8s.io/ingress-nginx/README.md) 为 Pod。 + + + +## Ingress 资源 + +最小的 Ingress 可能看起来像这样: + +```yaml +apiVersion: extensions/v1beta1 +kind: Ingress +metadata: + name: test-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - http: + paths: + - path: /testpath + backend: + serviceName: test + servicePort: 80 +``` + + + +*如果尚未配置 [Ingress 控制器](#ingress-controllers),则向 API 服务器 POST 操作将没有任何效果。* + + +__1-6 行__: 与其他 Kubernetes 对象配置一样,Ingress 需要 `apiVersion`、`kind`、和 `metadata` 字段。 +有关使用配置文件的一般信息,请参见 +[部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)、 +[配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/)、 +[管理资源](/docs/concepts/cluster-administration/manage-deployment/) +和 [ingress 配置重写](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 + + +__7-9 行__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 具有配置负载均衡器或代理服务器所需的所有信息。 +最重要的是,它包含与所有传入请求相匹配的规则列表。目前,Ingress 资源仅支持 HTTP 规则。 + + + +__10-11 行__: 每个 HTTP 规则都包含以下信息:主机(例如:foo.bar.com,在本例中默认为 * ),路径列表(例如:/testpath),每个路径都有一个关联的后端(test:80)。 +在负载均衡器将流量路由到后端之前,主机和路径都必须与传入请求的规则匹配。 + +__12-14 行__: 如[services doc](/docs/concepts/services-net./service/)中所述,后端(endpoint)是 “Service:port” 的组合。 +Ingress 流量通常被直接发送到与后端相匹配的端点。 + +__全局参数__: 为了简单起见,Ingress 示例没有全局参数,有关资源的完整定义请参见 [API引用](https://releases.k8s.io/{{< param "githubbranch" >}}/staging/src/k8s.io/api/extensions/v1beta1/types.go)。 +您可以指定全局默认的后端,这样的话,当请求与 spec 中的路径不匹配时,就会被转发到 Ingress 控制器的默认后端。 + + + +## Ingress 控制器 + +为了使 Ingress 资源正常工作,集群必须有 Ingress 控制器运行。 +这不同于其他类型的控制器,它们通常作为 `kube-controller-manager` 二进制文件的一部分运行,并且通常作为集群创建的一部分自动启动。 +请选择最适合您的集群的 Ingress 控制器,或者实现一个新的 Ingress 控制器。 + + + +* Kubernetes 当前支持并维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 +* F5 Networks 为 [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest) 提供[支持和维护](https://support.f5.com/csp/article/K86859508)。 +* [Kong](https://konghq.com/) 为 [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/) 提供 [社区版](https://discuss.konghq.com/c/kubernetes) 或 [商业版](https://konghq.com/api-customer-success/) 支持和维护。 +* [Traefik](https://github.com/containous/traefik) 是个全功能的 Ingress 控制器。 +([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), 它也伴随着 [Containous](https://containo.us/services) 的商业支持。 +* [NGINX, Inc.](https://www.nginx.com/) 为 [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) 提供支持和维护。 +* [HAProxy](http://www.haproxy.org/) 是 Ingress 控制器 [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) 的基础, 在这个博客中有提到它 [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)。 +* [Istio](https://istio.io/) 是 Ingress 控制器 [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/) 的基础。 + +{{< note >}} +**注意:** 请检查你的控制器的文档以找到其特定的支持策略。 +{{< /note >}} + + + +## 在您开始之前 + +下面的文档描述了通过Ingress资源公开的一组跨平台特性。 +理想情况下,所有 Ingress 控制器都应该满足这个规范,但是我们还没有。 +我们现在支持并维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 +如果您使用 F5 BIG-IP 控制器,请参考 [使用 BIG-IP 控制器作为 Kubernetes Ingress 控制器](http://clouddocs.f5.com/containers/latest/kubernetes/kctlr-k8s-ingress-ctlr.html)。 + + + +{{< note >}} +**注意:** 请您一定要查看您的控制器的特定文档,以便您能理解这些警告。 +{{< /note >}} + + + +## Ingress 的类型 + +### 单服务 Ingress + +现有的 Kubernetes 概念允许您暴露单个 Service (查看 [替代方案](#alternatives)),同样您也可以使用 Ingress 来实现,具体方法是指定一个没有规则的 *默认后端(default backend)*。 + + +{{< codenew file="service/networking/ingress.yaml" >}} + + + +如果您用 `kubectl create -f`创建它,你应该看到: + + +```shell +kubectl get ingress test-ingress +``` + +```shell +NAME HOSTS ADDRESS PORTS AGE +test-ingress * 107.178.254.228 80 59s +``` + + + +其中 `107.178.254.228` 是 Ingress 控制器为该 Ingress 分配的 IP 该。 + + + +### 简单分列 + +如前所述,Kubernetes 中 Pod 的 IP 仅在集群网络上可见,所以我们需要在集群网络的边缘接收下行流量并将其代理到正确的端点。 +这个组件通常是一个高可用的负载均衡器。Ingress 允许您将负载均衡器的数量降至最低。例如,这样的设置: + +```shell +foo.bar.com -> 178.91.123.132 -> / foo s1:80 + / bar s2:80 +``` + + + +可能需要一个 Ingress 就像: + +```yaml +apiVersion: extensions/v1beta1 +kind: Ingress +metadata: + name: test + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - host: foo.bar.com + http: + paths: + - path: /foo + backend: + serviceName: s1 + servicePort: 80 + - path: /bar + backend: + serviceName: s2 + servicePort: 80 +``` + + + +当您使用 `kubectl create -f` 创建 Ingress 时: + +```shell +kubectl describe ingress test +``` + +```shell +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo s1:80 (10.8.0.90:80) + /bar s2:80 (10.8.0.91:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 22s loadbalancer-controller default/test +``` + + + +Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress,只要 Service (`s1`,`s2`) 存在。 +当它这样做了,你会在地址栏看到负载平衡器的地址。 + +{{< note >}} + +**注意:** 如果需要,你需要创建一个默认的 HTTP 后端 [Service](/docs/concepts/services-networking/service/)。 +{{< /note >}} + + + + +### 基于名称的虚拟托管 + +基于名称的虚拟主机为同一个 IP 地址使用多个主机名。 + +```none +foo.bar.com --| |-> foo.bar.com s1:80 + | 178.91.123.132 | +bar.foo.com --| |-> bar.foo.com s2:80 +``` + + + +下面的 Ingress 让后台的负载均衡器基于 [Host header](https://tools.ietf.org/html/rfc7230#section-5.4) 路由请求。 + +```yaml +apiVersion: extensions/v1beta1 +kind: Ingress +metadata: + name: test +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: s1 + servicePort: 80 + - host: bar.foo.com + http: + paths: + - backend: + serviceName: s2 + servicePort: 80 +``` + + + +__默认后端__: 一个没有规则的 Ingress,如前面部分所示,它将所有流量发送到单个默认后端。 +通过指定一组规则*和*默认后端,您可以使用相同的技术来告诉负载均衡器在哪里找到网站的 404 页面。 +如果 Ingress 中的主机与请求头中的主机不匹配,和/或没有路径与请求的 URL 匹配,则流量被路由到默认后端。 + + + +### TLS + +您可以通过指定包含TLS私钥和证书的 [secret](/docs/concepts/configuration/secret) 来加密 Ingress。 +目前,Ingress 只支持单个 TLS 端口,443,并假定 TLS 终止。 +如果 Ingress 中的 TLS 配置部分指定了不同的主机,那么它们将根据通过 SNI TLS 扩展指定的主机名(如果 Ingress 控制器支持 SNI)在同一端口上进行复用。 +TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的密钥,这些密钥包含用于 TLS 的证书和私钥,例如: + +```yaml +apiVersion: v1 +data: + tls.crt: base64 encoded cert + tls.key: base64 encoded key +kind: Secret +metadata: + name: testsecret + namespace: default +type: Opaque +``` + + + +在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道: + +```yaml +apiVersion: extensions/v1beta1 +kind: Ingress +metadata: + name: no-rules-map +spec: + tls: + - secretName: testsecret + backend: + serviceName: s1 + servicePort: 80 +``` + + + +注意,各种 Ingress 控制器所支持的 TLS 功能之间存在间隙。请参阅有关文件 +[nginx](https://git.k8s.io/ingress-nginx/README.md#https), +[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), +或任何其他平台特定的 Ingress 控制器,以了解 TLS 如何在您的环境中工作。 + + + +### 负载均衡 + +Ingress控制器使用一些适用于所有 Ingress 的负载均衡策略设置进行自举,例如负载平衡算法、后端权重方案等。 +更高级的负载平衡概念(例如,持久会话、动态权重)尚未通过Ingress公开。 +您仍然可以通过 [Service 负载均衡器](https://github.com/kubernetes/ingress-nginx) 获得这些特性。 +随着时间的推移,我们计划将跨平台应用的负载平衡模式提取到 Ingress 资源中。 + + + +值得注意的是,即使健康检查不是通过 Ingress 直接暴露的,但是在 Kubernetes 中存在并行概念,比如 [就绪检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/),它允许您实现相同的最终结果。 +请检查控制器说明文档,以了解他们是怎样实现健康检查的 ( +[nginx](https://git.k8s.io/ingress-nginx/README.md), +[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 + + + + +## 更新 Ingress + +假设您想向现有的 Ingress 中添加新主机,可以通过编辑资源来更新它: + +```shell +kubectl describe ingress test +``` + +```shell +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo s1:80 (10.8.0.90:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 35s loadbalancer-controller default/test +``` + +```shell +kubectl edit ingress test +``` + + + +这应该弹出一个编辑器与现有的 yaml,修改它来增加新的主机: + +```yaml +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: s1 + servicePort: 80 + path: /foo + - host: bar.baz.com + http: + paths: + - backend: + serviceName: s2 + servicePort: 80 + path: /foo +.. +``` + + + +保存 yaml 将更新 API 服务器中的资源,这应该会告诉 Ingress 控制器来重新配置负载均衡器。 + +```shell +kubectl describe ingress test +``` + +```shell +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo s1:80 (10.8.0.90:80) + bar.baz.com + /foo s2:80 (10.8.0.91:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 45s loadbalancer-controller default/test +``` + + + +您可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。 + + + +## 跨可用区失败 + +用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。 +有关在联邦集群中部署 Ingress 的详细信息,请参阅联邦 [文档](/docs/concepts/cluster-administration/federation/)。 + + + + +## 未来的工作 + +*各种 HTTPS/TLS 模式的支持(例如:SNI、重加密) +*通过声明请求IP或主机名 +*合并 L4 和 L7 Ingress +*更多 Ingress 控制器 + +请跟踪 [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827)以了解关于资源演化的更多细节,以及 [Ingress repository](https://github.com/kubernetes/ingress/tree/master) 以了解关于各种 Ingress 控制器演进的更多细节。 + + + +## 替代方案 + +不直接使用 Ingress 资源,也有多种方法暴露 Service: + +* 使用 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) +* 使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) +* 使用 [端口代理](https://git.k8s.io/contrib/for-demos/proxy-to-service) + +{{% /capture %}} + +{{% capture whatsnext %}} + +{{% /capture %}} + diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index 6e9705b221..e1f96c7bb7 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -1,47 +1,104 @@ --- -approvers: +reviewers: - bprashanth -title: Service -redirect_from: -- "/docs/user-guide/services/" -- "/docs/user-guide/services/index.html" +title: Services +feature: + title: 服务发现与负载均衡 + description: > + 无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称,并且可以在它们之间实现负载平衡。 + +content_template: templates/concept +weight: 10 --- + + + +{{% capture overview %}} + + Kubernetes [`Pod`](/docs/user-guide/pods) 是有生命周期的,它们可以被创建,也可以被销毁,然而一旦被销毁生命就永远结束。 通过 [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) 能够动态地创建和销毁 `Pod`(例如,需要进行扩缩容,或者执行 [滚动升级](/docs/user-guide/kubectl/v1.7/#rolling-update))。 每个 `Pod` 都会获取它自己的 IP 地址,即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题:在 Kubernetes 集群中,如果一组 `Pod`(称为 backend)为其它 `Pod` (称为 frontend)提供服务,那么那些 frontend 该如何发现,并连接到这组 `Pod` 中的哪些 backend 呢? + +关于 `Services` -关于 `Service` - - + Kubernetes `Service` 定义了这样一种抽象:逻辑上的一组 `Pod`,一种可以访问它们的策略 —— 通常称为微服务。 这一组 `Pod` 能够被 `Service` 访问到,通常是通过 [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)(查看下面了解,为什么可能需要没有 selector 的 `Service`)实现的。 - + 举个例子,考虑一个图片处理 backend,它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。 然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化,frontend 客户端不应该也没必要知道,而且也不需要跟踪这一组 backend 的状态。 `Service` 定义的抽象能够解耦这种关联。 - + 对 Kubernetes 集群中的应用,Kubernetes 提供了简单的 `Endpoints` API,只要 `Service` 中的一组 `Pod` 发生变更,应用程序就会被更新。 对非 Kubernetes 集群中的应用,Kubernetes 提供了基于 VIP 的网桥的方式访问 `Service`,再由 `Service` 重定向到 backend `Pod`。 -{{< toc >}} +{{% /capture %}} +{{% capture body %}} + + ## 定义 Service - - 一个 `Service` 在 Kubernetes 中是一个 REST 对象,和 `Pod` 类似。 像所有的 REST 对象一样, `Service` 定义可以基于 POST 方式,请求 apiserver 创建新的实例。 例如,假定有一组 `Pod`,它们对外暴露了 9376 端口,同时还被打上 `"app=MyApp"` 标签。 @@ -60,13 +117,29 @@ spec: targetPort: 9376 ``` - + 上述配置将创建一个名称为 “my-service” 的 `Service` 对象,它会将请求代理到使用 TCP 端口 9376,并且具有标签 `"app=MyApp"` 的 `Pod` 上。 这个 `Service` 将被指派一个 IP 地址(通常称为 “Cluster IP”),它会被服务的代理使用(见下面)。 该 `Service` 的 selector 将会持续评估,处理结果将被 POST 到一个名称为 “my-service” 的 `Endpoints` 对象上。 - + 需要注意的是, `Service` 能够将一个接收端口映射到任意的 `targetPort`。 默认情况下,`targetPort` 将被设置为与 `port` 字段相同的值。 @@ -75,16 +148,32 @@ spec: 对于部署和设计 `Service` ,这种方式会提供更大的灵活性。 例如,可以在 backend 软件下一个版本中,修改 Pod 暴露的端口,并不会中断客户端的调用。 - + Kubernetes `Service` 能够支持 `TCP` 和 `UDP` 协议,默认 `TCP` 协议。 +{{< note >}} +自 Kubernetes 1.12 以来,SCTP 的支持是 alpha 功能。 +{{< /note >}} + ### 没有 selector 的 Service - - Servcie 抽象了该如何访问 Kubernetes `Pod`,但也能够抽象其它类型的 backend,例如: * 希望在生产环境中使用外部的数据库集群,但测试环境使用自己的数据库。 @@ -105,6 +194,10 @@ spec: targetPort: 9376 ``` + 由于这个 `Service` 没有 selector,就不会创建相关的 `Endpoints` 对象。可以手动将 `Service` 映射到指定的 `Endpoints`: @@ -120,57 +213,76 @@ subsets: - port: 9376 ``` + +{{< note >}} +注意:Endpoint IP 地址不能是 loopback(127.0.0.0/8)、 link-local(169.254.0.0/16)、或者 link-local 多播(224.0.0.0/24)。它们不能是其他 Kubernetes 服务的集群 IP,因为 `kube-proxy` 组件不支持虚拟 IP 作为目的地。 +{{< /note >}} -注意:Endpoint IP 地址不能是 loopback(127.0.0.0/8)、 link-local(169.254.0.0/16)、或者 link-local 多播(224.0.0.0/24)。 - - + 访问没有 selector 的 `Service`,与有 selector 的 `Service` 的原理相同。请求将被路由到用户定义的 Endpoint(该示例中为 `1.2.3.4:9376`)。 + +ExternalName `Service` 是 `Service` 的特例,它没有 selector,也没有使用 DNS 名称代替。 +有关更多信息,请参阅本文档后面的[`ExternalName`](#externalname)。 -ExternalName `Service` 是 `Service` 的特例,它没有 selector,也没有定义任何的端口和 Endpoint。 -相反地,对于运行在集群外部的服务,它通过返回该外部服务的别名这种方式来提供服务。 - -```yaml -kind: Service -apiVersion: v1 -metadata: - name: my-service - namespace: prod -spec: - type: ExternalName - externalName: my.database.example.com -``` - - - -当查询主机 `my-service.prod.svc.CLUSTER`时,集群的 DNS 服务将返回一个值为 `my.database.example.com` 的 `CNAME` 记录。 -访问这个服务的工作方式与其它的相同,唯一不同的是重定向发生在 DNS 层,而且不会进行代理或转发。 -如果后续决定要将数据库迁移到 Kubernetes 集群中,可以启动对应的 Pod,增加合适的 Selector 或 Endpoint,修改 `Service` 的 `type`。 - - + ## VIP 和 Service 代理 +在 Kubernetes 集群中,每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP(虚拟 IP)的形式,而不是 [`ExternalName`](#externalname) 的形式。 - -在 Kubernetes 集群中,每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP(虚拟 IP)的形式,而不是 `ExternalName` 的形式。 -在 Kubernetes v1.0 版本,代理完全在 userspace。在 Kubernetes v1.1 版本,新增了 iptables 代理,但并不是默认的运行模式。 -从 Kubernetes v1.2 起,默认就是 iptables 代理。 +在 Kubernetes v1.0 版本,`Services` 是 "L4" (IP 层上的 TCP/UDP) 构造,代理完全在 userspace。在 Kubernetes v1.1 版本,新增了 `Ingress` API (beta) "L 7"(HTTP) 服务与 iptables 代理,自 Kubernetes v1.2 以来成为默认的操作模式。 +在 Kubernetes v1.8.0-beta.0 中,添加了 ipvs 代理。 在 Kubernetes v1.0 版本,`Service` 是 “4层”(TCP/UDP over IP)概念。 在 Kubernetes v1.1 版本,新增了 `Ingress` API(beta 版),用来表示 “7层”(HTTP)服务。 - + ### userspace 代理模式 - - 这种模式,kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。 对每个 `Service`,它会在本地 Node 上打开一个端口(随机选择)。 任何连接到“代理端口”的请求,都会被代理到 `Service` 的backend `Pods` 中的某个上面(如 `Endpoints` 所报告的一样)。 @@ -190,12 +302,24 @@ spec: ![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg) - + ### iptables 代理模式 - - 这种模式,kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。 对每个 `Service`,它会安装 iptables 规则,从而捕获到达该 `Service` 的 `clusterIP`(虚拟 IP)和端口的请求,进而将请求重定向到 `Service` 的一组 backend 中的某个上面。 对于每个 `Endpoints` 对象,它也会安装 iptables 规则,这个规则会选择一个 backend `Pod`。 @@ -214,7 +338,68 @@ spec: ![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg) + + ## 多端口 Service @@ -242,23 +427,43 @@ spec: targetPort: 9377 ``` - + ## 选择自己的 IP 地址 - - 在 `Service` 创建的请求中,可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。 比如,希望替换一个已经已存在的 DNS 条目,或者遗留系统已经配置了一个固定的 IP 且很难重新配置。 用户选择的 IP 地址必须合法,并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内,这对 API Server 来说是通过一个标识来指定的。 如果 IP 地址不合法,API Server 会返回 HTTP 状态码 422,表示值不合法。 + ### 为何不使用 round-robin DNS? - 一个不时出现的问题是,为什么我们都使用 VIP 的方式,而不使用标准的 round-robin DNS,有如下几个原因: * 长久以来,DNS 库都没能认真对待 DNS TTL、缓存域名查询结果 @@ -267,20 +472,42 @@ spec: 我们尽力阻止用户做那些对他们没有好处的事情,如果很多人都来问这个问题,我们可能会选择实现它。 - + ## 服务发现 - - Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。 - - + ### 环境变量 - - 当 `Pod` 运行在 `Node` 上,kubelet 会为每个活跃的 `Service` 添加一组环境变量。 它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量(查看 [makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49))、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量,这里 `Service` 的名称需大写,横线被转换成下划线。 @@ -301,9 +528,29 @@ REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11 *这意味着需要有顺序的要求* —— `Pod` 想要访问的任何 `Service` 必须在 `Pod` 自己之前被创建,否则这些环境变量就不会被赋值。DNS 并没有这个限制。 + - +### DNS 一个可选(尽管强烈推荐)[集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md) 是 DNS 服务器。 DNS 服务器监视着创建新 `Service` 的 Kubernetes API,从而为每一个 `Service` 创建一组 DNS 记录。 @@ -326,7 +573,20 @@ Kubernetes 也支持对端口名称的 DNS SRV(Service)记录。 Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。 更多信息可以查看[DNS Pod 和 Service](/docs/concepts/services-networking/dns-pod-service/)。 - + ## Headless Service @@ -345,7 +605,12 @@ Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 对这类 `Service` 并不会分配 Cluster IP,kube-proxy 不会处理它们,而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置,依赖于 `Service` 是否定义了 selector。 - + ### 配置 Selector @@ -353,7 +618,15 @@ DNS 如何实现自动配置,依赖于 `Service` 是否定义了 selector。 对定义了 selector 的 Headless Service,Endpoint 控制器在 API 中创建了 `Endpoints` 记录,并且修改 DNS 配置返回 A 记录(地址),通过这个地址直接到达 `Service` 的后端 `Pod` 上。 - + ### 不配置 Selector @@ -365,7 +638,29 @@ DNS 如何实现自动配置,依赖于 `Service` 是否定义了 selector。 * `ExternalName` 类型 Service 的 CNAME 记录 * 记录:与 Service 共享一个名称的任何 `Endpoints`,以及所有其它类型 - + ## 发布服务 —— 服务类型 @@ -383,7 +678,23 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service,默认 * `ExternalName`:通过返回 `CNAME` 和它的值,可以将服务映射到 `externalName` 字段的内容(例如, `foo.bar.example.com`)。 没有任何类型代理被创建,这只有 Kubernetes 1.7 或更高版本的 `kube-dns` 才支持。 - + ### NodePort 类型 @@ -402,12 +713,51 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service,默认 需要注意的是,Service 将能够通过 `:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。 - + ### LoadBalancer 类型 - - 使用支持外部负载均衡器的云提供商的服务,设置 `type` 的值为 `"LoadBalancer"`,将为 `Service` 提供负载均衡器。 负载均衡器是异步创建的,关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。 @@ -439,7 +789,59 @@ status: 某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`,将会给负载均衡器指派一个临时 IP。 如果设置了 `loadBalancerIP`,但云提供商并不支持这种特性,那么设置的 `loadBalancerIP` 值将会被忽略掉。 - + ### AWS 内部负载均衡器 在混合云环境中,有时从虚拟私有云(VPC)环境中的服务路由流量是非常有必要的。 @@ -457,7 +859,61 @@ metadata: 在水平分割的 DNS 环境中,需要两个 `Service` 来将外部和内部的流量路由到 Endpoint 上。 - + ### AWS SSL 支持 对运行在 AWS 上部分支持 SSL 的集群,从 1.3 版本开始,可以为 `LoadBalancer` 类型的 `Service` 增加两个 annotation: @@ -490,7 +946,31 @@ HTTP 和 HTTPS 将选择7层代理:ELB 将中断与用户的连接,当转发 TCP 和 SSL 将选择4层代理:ELB 将转发流量,并不修改 Header 信息。 - + ### 外部 IP @@ -518,7 +998,20 @@ spec: - 80.11.12.10 ``` - + ## 不足之处 @@ -536,7 +1029,20 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址,但却要求 `Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。 不会严格要求所有云提供商(例如,GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`,但是 AWS 需要 ),但当前 API 是强制要求的。 - + ## 未来工作 @@ -549,14 +1055,37 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址,但却要求 我们打算为 `Service` 实现更加灵活的请求进入模式,这些 `Service` 包含当前 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式,或者更多。 - + ## VIP 的那些骇人听闻的细节 对很多想使用 `Service` 的人来说,前面的信息应该足够了。 然而,有很多内部原理性的内容,还是值去理解的。 - + ### 避免冲突 @@ -575,7 +1104,18 @@ Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致 为了使 `Service` 能够获取到 IP,这个映射表对象必须在注册中心存在,否则创建 `Service` 将会失败,指示一个 IP 不能被分配。 一个后台 Controller 的职责是创建映射表(从 Kubernetes 的旧版本迁移过来,旧版本中是通过在内存中加锁的方式实现),并检查由于管理员干预和清除任意 IP 造成的不合理分配,这些 IP 被分配了但当前没有 `Service` 使用它们。 - + ### IP 和 VIP @@ -584,7 +1124,22 @@ Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致 当客户端连接到 VIP 时,它们的流量会自动地传输到一个合适的 Endpoint。 环境变量和 DNS,实际上会根据 `Service` 的 VIP 和端口来进行填充。 - + #### Userspace @@ -601,7 +1156,23 @@ Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致 这意味着 `Service` 的所有者能够选择任何他们想使用的端口,而不存在冲突的风险。 客户端可以简单地连接到一个 IP 和端口,而不需要知道实际访问了哪些 `Pod`。 - + #### Iptables @@ -617,7 +1188,12 @@ Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致 不像 userspace 代理,数据包从来不拷贝到用户空间,kube-proxy 不是必须为该 VIP 工作而运行,并且客户端 IP 是不可更改的。 当流量打到 Node 的端口上,或通过负载均衡器,会执行相同的基本流程,但是在那些案例中客户端 IP 是可以更改的。 - + ## API 对象 diff --git a/content/zh/docs/concepts/storage/_index.md b/content/zh/docs/concepts/storage/_index.md index 3f2371fcb4..1880a0aef7 100644 --- a/content/zh/docs/concepts/storage/_index.md +++ b/content/zh/docs/concepts/storage/_index.md @@ -8,4 +8,4 @@ weight: 70 title: "Storage" weight: 70 --- ---> \ No newline at end of file +--> diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..f9f642bfda --- /dev/null +++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,220 @@ +--- +title: 动态卷供应 +content_template: templates/concept +weight: 40 +--- + + +{{% capture overview %}} + + +动态卷供应允许按需创建存储卷。 +如果没有动态供应,集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷, +然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。 +动态供应功能消除了集群管理员预先配置存储的需要。 相反,它在用户请求时自动供应存储。 + +{{% /capture %}} + +{{% capture body %}} + + +## 背景 + + +动态卷供应的实现基于 `storage.k8s.io` API 组中的 `StorageClass` API 对象。 +集群管理员可以根据需要定义多个 `StorageClass` 对象,每个对象指定一个*卷插件*(又名 *provisioner*), +卷插件向卷供应商提供在创建卷时需要的数据卷信息及相关参数。 + + +集群管理员可以在集群中定义和公开多种存储(来自相同或不同的存储系统),每种都具有自定义参数集。 +该设计也确保终端用户不必担心存储供应的复杂性和细微差别,但仍然能够从多个存储选项中进行选择。 + + +点击[这里](/docs/concepts/storage/persistent-volumes/#storageclasses)查阅有关存储类的更多信息。 + + +## 启用动态卷供应 + + +要启用动态供应功能,集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。 +`StorageClass` 对象定义在进行动态卷供应时应使用哪个卷供应商,以及应该将哪些参数传递给该供应商。 +以下清单创建了一个存储类 "slow",它提供类似标准磁盘的永久磁盘。 + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + + +以下清单创建了一个 "fast" 存储类,它提供类似 SSD 的永久磁盘。 + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + + +## 使用动态卷供应 + + +用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态供应的存储。 +在 Kubernetes v1.6 之前,这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。 + + +然而,这个注解自 v1.6 起就不被推荐使用了。 +用户现在能够而且应该使用 `PersistentVolumeClaim` 对象的 `storageClassName` 字段。 +这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称(见[下面](#enabling-dynamic-provisioning))。 + + +例如,要选择 "fast" 存储类,用户将创建如下的 `PersistentVolumeClaim`: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + + +该声明会自动供应一块类似 SSD 的永久磁盘。 +在删除该声明后,这个卷也会被销毁。 + + +## 默认行为 + + +可以在群集上启用动态卷供应,以便在未指定存储类的情况下动态设置所有声明。 +集群管理员可以通过以下方式启用此行为: + + +- 标记一个 `StorageClass` 为 *默认*; +- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 + + +管理员可以通过向其添加 `storageclass.kubernetes.io/is-default-class` 注解来将特定的 `StorageClass` 标记为默认。 +当集群中存在默认的 `StorageClass` 并且用户创建了一个未指定 `storageClassName` 的 `PersistentVolumeClaim` 时, +`DefaultStorageClass` 准入控制器会自动向其中添加指向默认存储类的 `storageClassName` 字段。 + + +请注意,群集上最多只能有一个 *默认* 存储类,否则无法创建没有明确指定 `storageClassName` 的 `PersistentVolumeClaim`。 + + +## 拓扑感知 + + +在[多区域](/docs/setup/multiple-zones)集群中,Pod 可以被分散到多个区域。 +单区域存储后端应该被供应到 Pod 被调度到的区域。 +这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md new file mode 100644 index 0000000000..d15c48fad5 --- /dev/null +++ b/content/zh/docs/concepts/storage/storage-classes.md @@ -0,0 +1,1152 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +title: Storage Classes +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + + +本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/docs/concepts/storage/volumes/) 和 +[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。 + +{{% /capture %}} + +{{% capture body %}} + + +## 介绍 + +`StorageClass` 为管理员提供了描述存储 `"类"` 的方法。 +不同的`类型`可能会映射到不同的服务质量等级或备份策略,或是由群集管理员制定的任意策略。 +Kubernetes 本身并不清楚各种`类`代表的什么。这个`类`的概念在其他存储系统中有时被称为"配置文件"。 + + +## StorageClass 资源 + +每个 `StorageClass` 都包含 `provisioner`、`parameters` 和 `reclaimPolicy` 字段, +这些字段会在`StorageClass`需要动态分配 `PersistentVolume` 时会使用到。 + + +`StorageClass` 对象的命名很重要,用户使用这个命名来请求生成一个特定的类。 +当创建 `StorageClass` 对象时,管理员设置 StorageClass 对象的命名和其他参数,一旦创建了对象就不能再对其更新。 + + +管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的`类` : +更多详情请参阅 [`PersistentVolumeClaim` 章节](#persistentvolumeclaims)。 + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: standard +provisioner: kubernetes.io/aws-ebs +parameters: + type: gp2 +reclaimPolicy: Retain +mountOptions: + - debug +volumeBindingMode: Immediate +``` + + +### 存储分配器 + +`StorageClass` 有一个分配器,用来决定使用哪个`卷插件`分配`持久化卷申领`。该字段必须指定。 + +| 卷插件 | 提供厂商 | 配置例子 | +| :--- | :---: | :---: | +| AWSElasticBlockStore | ✓ | [AWS EBS](#aws-ebs) | +| AzureFile | ✓ | [Azure File](#azure-file) | +| AzureDisk | ✓ | [Azure Disk](#azure-disk) | +| CephFS | - | - | +| Cinder | ✓ | [OpenStack Cinder](#openstack-cinder)| +| FC | - | - | +| Flexvolume | - | - | +| Flocker | ✓ | - | +| GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | +| Glusterfs | ✓ | [Glusterfs](#glusterfs) | +| iSCSI | - | - | +| Quobyte | ✓ | [Quobyte](#quobyte) | +| NFS | - | - | +| RBD | ✓ | [Ceph RBD](#ceph-rbd) | +| VsphereVolume | ✓ | [vSphere](#vsphere) | +| PortworxVolume | ✓ | [Portworx Volume](#portworx-volume) | +| ScaleIO | ✓ | [ScaleIO](#scaleio) | +| StorageOS | ✓ | [StorageOS](#storageos) | +| Local | - | [Local](#local) | + + +您不限于指定此处列出的"内置"分配器(其名称前缀为 kubernetes.io 并打包在 Kubernetes 中)。 +您还可以运行和指定外部分配器,这些独立的程序遵循由 Kubernetes 定义的 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 +外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件(包括 Flex)等。 +代码仓库 [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) +包含一个用于为外部分配器编写功能实现的类库,以及各种社区维护的外部分配器。 + + +例如,NFS 没有内部分配器,但可以使用外部分配器。一些外部分配器在代码仓库 [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) 中。 +也有第三方存储供应商提供自己的外部分配器。 + + +### 回收策略 + +由 `StorageClass` 动态创建的持久化卷会在的 `reclaimPolicy` 字段中指定回收策略,可以是 +`Delete` 或者 `Retain`。如果 `StorageClass` 对象被创建时没有指定 `reclaimPolicy` ,它将默认为 `Delete`。 + +通过 `StorageClass` 手动创建并管理的 Persistent Volume 会使用它们被创建时指定的回收政策。 + + +### 挂载选项 + +由 `StorageClass` 动态创建的 Persistent Volume 将使用`类`中 `mountOption` 字段指定的挂载选项。 + +如果卷插件不支持挂载选项,却指定了该选项,则分配操作会失败。 +挂载选项在 `StorageClass` 和持久卷上都不会做验证,所以如果挂载选项无效,那么这个 PV 就会失败。 + + +### 卷绑定模式 + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + + +**注意:** 这个功能特性需要启用 `VolumeScheduling` 参数才能使用。 + + +`volumeBindingMode` 字段控制了 [卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning) +应该发生在什么时候。 + + +默认情况下,`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态分配。 +对于由于拓扑限制而非集群所有节点可达的存储后端,PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者分配。 + + +集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。 +该模式将延迟 PersistentVolume 的绑定和分配,直到使用该 PersistentVolumeClaim 的 Pod 被创建。 +PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 [资源需求](/docs/concepts/configuration/manage-compute-resources-container), +[节点筛选器](/docs/concepts/configuration/assign-pod-node/#nodeselector), +[pod 亲和性和互斥性](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), +以及 [污点和容忍度](/docs/concepts/configuration/taint-and-toleration). + + +以下插件支持动态分配的 `WaitForFirstConsumer` 模式: + +* [AWSElasticBlockStore](#aws-ebs) +* [GCEPersistentDisk](#gce-pd) +* [AzureDisk](#azure-disk) + + +以下插件支持预创建绑定 PersistentVolume 的 `WaitForFirstConsumer` 模式: + +* All of the above +* [Local](#local) + + +### 允许的拓扑结构 +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + + +**注意:** 这个特性需要开启 `VolumeScheduling` 特性开关。 + + +当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式,在大部分情况下就没有必要将配置限制为特定的拓扑结构。 +然而,如果还有需要的话,可以使用 `allowedTopologies`。 + + +这个例子描述了如何将分配卷限的拓扑限制在特定的区域,在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。 + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: standard +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +volumeBindingMode: WaitForFirstConsumer +allowedTopologies: +- matchLabelExpressions: + - key: failure-domain.beta.kubernetes.io/zone + values: + - us-central1-a + - us-central1-b +``` + + +## 参数 + +Storage class 具有描述属于卷的参数。取决于分配器,可以接受不同的参数。 +例如,参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时,会使用默认值。 + +### AWS EBS + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: slow +provisioner: kubernetes.io/aws-ebs +parameters: + type: io1 + iopsPerGB: "10" + fsType: ext4 +``` + + +* `type`:`io1`,`gp2`,`sc1`,`st1`。详细信息参见 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值:`gp2`。 +* `zone`(弃用):AWS 区域。如果没有指定 `zone` 和 `zones`,通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用):以逗号分隔的 AWS 区域列表。如果没有指定 `zone` 和 `zones`,通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。 +* `iopsPerGB`:只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量,并将其限制在 20 000 IOPS(AWS 支持的最高值,请参阅 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 + 这里需要输入一个字符串,即 `"10"`,而不是 `10`。 +* `fsType`:受 Kubernetes 支持的文件类型。默认值:`"ext4"`。 +* `encrypted`:指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。这里需要输入字符串,即 `"true"`, 而非 `true`。 +* `kmsKeyId`:可选。加密卷时使用密钥的完整 Amazon 资源名称。如果没有提供,但 `encrypted` 值为 true,AWS 生成一个密钥。关于有效的 ARN 值,请参阅 AWS 文档。 + +**注意:** `zone` 和 `zones` 已被弃用并被 [允许的拓扑结构](#allowed-topologies) 取代。 + +### GCE PD + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard + replication-type: none +``` + +* `type`:`pd-standard` 或者 `pd-ssd`。默认:`pd-standard` +* `zone`(弃用):GCE 区域。如果没有指定 `zone` 和 `zones`,通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 +* `zones`(弃用):逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`,通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度(round-robin)分配。`zone` 和 `zones` 参数不能同时使用。 +* `replication-type`:`none` 或者 `regional-pd`。默认值:`none`。 + + +如果 `replication-type` 设置为 `none`,会分配一个常规(当前区域内的)持久化磁盘。 + + +如果 `replication-type` 设置为 `regional-pd`,会分配一个 [区域性持久化磁盘(Regional Persistent Disk)](https://cloud.google.com/compute/docs/disks/#repds)。在这种情况下,用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域(zone)。如果指定来两个特定的区域,区域性持久化磁盘会在这两个区域里分配。如果指定了多于两个的区域,Kubernetes 会选择其中任意两个区域。如果省略了 `zones` 参数,Kubernetes 会在集群管理的区域中任意选择。 + + +**注意:** `zone` 和 `zones` 已被弃用并被 [allowedTopologies](#allowed-topologies) 取代。 + +### Glusterfs + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://127.0.0.1:8081" + clusterid: "630372ccdc720a92c681fb928f27b53f" + restauthenabled: "true" + restuser: "admin" + secretNamespace: "default" + secretName: "heketi-secret" + gidMin: "40000" + gidMax: "50000" + volumetype: "replicate:3" +``` + + +* `resturl`:分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。 + 通用格式应该是 `IPaddress:Port`,这是 GlusterFS 动态分配器的必需参数。 + 如果 Heketi 服务在 openshift/kubernetes 中安装并暴露为可路由服务,则可以使用类似于 + `http://heketi-storage-project.cloudapps.mystorage.com` 的格式,其中 fqdn 是可解析的 heketi 服务网址。 +* `restauthenabled`:Gluster REST 服务身份验证布尔值,用于启用对 REST 服务器的身份验证。如果此值为 'true',则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用,当在指定 `restuser`,`restuserkey`,`secretName` 或 `secretNamespace` 时,身份验证被启用。 +* `restuser`:在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。 +* `restuserkey`:Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用,取而代之的是 `secretNamespace` + `secretName`。 + +* `secretNamespace`,`secretName`:Secret 实例的标识,包含与 Gluster REST 服务交互时使用的用户密码。 + 这些参数是可选的,`secretNamespace` 和 `secretName` 都省略时使用空密码。所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs",例如以这种方式创建: + + ``` + kubectl create secret generic heketi-secret \ + --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \ + --namespace=default + ``` + + secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。 + +* `clusterid`:`630372ccdc720a92c681fb928f27b53f` 是集群的 ID,当分配卷时,Heketi 将会使用这个文件。它也可以是一个 clusterid 列表,例如: + `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。 +* `gidMin`,`gidMax`:storage class GID 范围的最小值和最大值。在此范围(gidMin-gidMax)内的唯一值(GID)将用于动态分配卷。这些是可选的值。如果不指定,卷将被分配一个 2000-2147483647 之间的值,这是 gidMin 和 gidMax 的默认值。 + +* `volumetype`:卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型,则由分配器决定卷的类型。 + + 例如: + 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量. + 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据,'2' 是冗余数量. + 'Distribute volume': `volumetype: none` + + 有关可用的卷类型和管理选项,请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。 + + 更多相关的参考信息,请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。 + + 当动态分配持久卷时,Gluster 插件自动创建名为 `gluster-dynamic-` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。 + +### OpenStack Cinder + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: gold +provisioner: kubernetes.io/cinder +parameters: + availability: nova +``` + + +* `availability`:可用区域。如果没有指定,通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 + + +{{< note >}} +{{< feature-state state="deprecated" for_k8s_version="1.11" >}} +OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部驱动程序](https://github.com/kubernetes/cloud-provider-openstack)。 +{{< /note >}} + +### vSphere + + +1. 使用用户指定的磁盘格式创建一个 StorageClass。 + + ```yaml + kind: StorageClass + apiVersion: storage.k8s.io/v1 + metadata: + name: fast + provisioner: kubernetes.io/vsphere-volume + parameters: + diskformat: zeroedthick + ``` + + + `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。 + + +2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。 + + ```yaml + kind: StorageClass + apiVersion: storage.k8s.io/v1 + metadata: + name: fast + provisioner: kubernetes.io/vsphere-volume + parameters: + diskformat: zeroedthick + datastore: VSANDatastore + ``` + + + `datastore`:用户也可以在 StorageClass 中指定数据存储。卷将在 storage class 中指定的数据存储上创建,在这种情况下是 `VSANDatastore`。该字段是可选的。如果未指定数据存储,则将在用于初始化 vSphere Cloud Provider 的 vSphere 配置文件中指定的数据存储上创建该卷。 + + +3. Kubernetes 中的存储策略管理 + + + * 使用现有的 vCenter SPBM 策略 + + vSphere 用于存储管理的最重要特性之一是基于策略的管理。基于存储策略的管理(SPBM)是一个存储策略框架,提供单一的统一控制平面的跨越广泛的数据服务和存储解决方案。 SPBM 使能 vSphere 管理员克服先期的存储配置挑战,如容量规划,差异化服务等级和管理容量空间。 + + SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。 + + + * Kubernetes 内的 Virtual SAN 策略支持 + + Vsphere Infrastructure(VI)管理员将能够在动态卷配置期间指定自定义 Virtual SAN 存储功能。您现在可以定义存储需求,例如性能和可用性,当动态卷供分配时会以存储功能的形式提供。存储功能需求会转换为 Virtual SAN 策略,然后当 persistent volume(虚拟磁盘)在创建时,会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。 + + 更多有关 persistent volume 管理的存储策略的详细信息, + 您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。 + + +有几个 [vSphere 例子](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) +供您在 Kubernetes for vSphere 中尝试进行 persistent volume 管理。 + +### Ceph RBD + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: kubernetes.io/rbd +parameters: + monitors: 10.16.153.105:6789 + adminId: kube + adminSecretName: ceph-secret + adminSecretNamespace: kube-system + pool: kube + userId: kube + userSecretName: ceph-secret-user + userSecretNamespace: default + fsType: ext4 + imageFormat: "2" + imageFeatures: "layering" +``` + + +* `monitors`:Ceph monitor,逗号分隔。该参数是必需的。 +* `adminId`:Ceph 客户端 ID,用于在池 ceph 池中创建映像。默认是 "admin"。 +* `adminSecret`:`adminId` 的 Secret 名称。该参数是必需的。 + 提供的 secret 必须有值为 "kubernetes.io/rbd" 的 type 参数。 +* `adminSecretNamespace`:`adminSecret` 的命名空间。默认是 "default"。 +* `pool`: Ceph RBD 池. 默认是 "rbd"。 +* `userId`:Ceph 客户端 ID,用于映射 RBD 镜像。默认与 `adminId` 相同。 + +* `userSecretName`:用于映射 RBD 镜像的 `userId` 的 Ceph Secret 的名字。 + 它必须与 PVC 存在于相同的 namespace 中。该参数是必需的。 + 提供的 secret 必须具有值为 "kubernetes.io/rbd" 的 type 参数,例如以这样的方式创建: + + ```shell + kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \ + --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \ + --namespace=kube-system + ``` + + +* `userSecretNamespace`:`userSecretName` 的命名空间。 +* `fsType`:Kubernetes 支持的 fsType。默认:`"ext4"`。 +* `imageFormat`:Ceph RBD 镜像格式,"1" 或者 "2"。默认值是 "1"。 +* `imageFeatures`:这个参数是可选的,只能在你将 `imageFormat` 设置为 "2" 才使用。 + 目前支持的功能只是 `layering`。默认是 "",没有功能打开。 + +### Quobyte + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/quobyte +parameters: + quobyteAPIServer: "http://138.68.74.142:7860" + registry: "138.68.74.142:7861" + adminSecretName: "quobyte-admin-secret" + adminSecretNamespace: "kube-system" + user: "root" + group: "root" + quobyteConfig: "BASE" + quobyteTenant: "DEFAULT" +``` + + +* `quobyteAPIServer`:Quobyte API 服务器的格式是 + `"http(s)://api-server:7860"` +* `registry`:用于挂载卷的 Quobyte registry。你可以指定 registry 为 ``:`` + 或者如果你想指定多个 registry,你只需要在他们之间添加逗号,例如 + ``:,:,:``。 + 主机可以是一个 IP 地址,或者如果您有正在运行的 DNS,您也可以提供 DNS 名称。 +* `adminSecretNamespace`:`adminSecretName`的 namespace。 + 默认值是 "default"。 + +* `adminSecretName`:保存关于 Quobyte 用户和密码的 secret,用于对 API 服务器进行身份验证。 + 提供的 secret 必须有值为 "kubernetes.io/quobyte" 的 type 参数,例如以这种方式创建: + + ```shell + kubectl create secret generic quobyte-admin-secret \ + --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \ + --namespace=kube-system + ``` + +* `user`:对这个用户映射的所有访问权限。默认是 "root"。 +* `group`:对这个组映射的所有访问权限。默认是 "nfsnobody"。 +* `quobyteConfig`:使用指定的配置来创建卷。您可以创建一个新的配置,或者,可以修改 Web console 或 + quobyte CLI 中现有的配置。默认是 "BASE"。 +* `quobyteTenant`:使用指定的租户 ID 创建/删除卷。这个 Quobyte 租户必须已经于 Quobyte。 + 默认是 "DEFAULT"。 + + +### Azure 磁盘 + + +#### Azure Unmanaged Disk Storage Class(非托管磁盘存储类) + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: slow +provisioner: kubernetes.io/azure-disk +parameters: + skuName: Standard_LRS + location: eastus + storageAccount: azure_storage_account_name +``` + + +* `skuName`:Azure 存储帐户 Sku 层。默认为空。 +* `location`:Azure 存储帐户位置。默认为空。 +* `storageAccount`:Azure 存储帐户名称。如果提供存储帐户,它必须位于与集群相同的资源组中,并且 `location` 是被忽略的。如果未提供存储帐户,则会在与群集相同的资源组中创建新的存储帐户。 + + +#### 新的 Azure 磁盘 Storage Class(从 v1.7.2 开始) + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: slow +provisioner: kubernetes.io/azure-disk +parameters: + storageaccounttype: Standard_LRS + kind: Shared +``` + + +* `storageaccounttype`:Azure 存储帐户 Sku 层。默认为空。 +* `kind`:可能的值是 `shared`(默认)、`dedicated` 和 `managed`。 + 当 `kind` 的值是 `shared` 时,所有非托管磁盘都在集群的同一个资源组中的几个共享存储帐户中创建。 + 当 `kind` 的值是 `dedicated` 时,将为在集群的同一个资源组中新的非托管磁盘创建新的专用存储帐户。 + + +- Premium VM 可以同时添加 Standard_LRS 和 Premium_LRS 磁盘,而 Standard 虚拟机只能添加 Standard_LRS 磁盘。 +- 托管虚拟机只能连接托管磁盘,非托管虚拟机只能连接非托管磁盘。 + + +### Azure 文件 + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: azurefile +provisioner: kubernetes.io/azure-file +parameters: + skuName: Standard_LRS + location: eastus + storageAccount: azure_storage_account_name +``` + + +* `skuName`:Azure 存储帐户 Sku 层。默认为空。 +* `location`:Azure 存储帐户位置。默认为空。 +* `storageAccount`:Azure 存储帐户名称。默认为空。 + 如果不提供存储帐户,会搜索所有与资源相关的存储帐户,以找到一个匹配 `skuName` 和 `location` 的账号。 + 如果提供存储帐户,它必须存在于与集群相同的资源组中,`skuName` 和 `location` 会被忽略。 + + +在分配期间,为挂载凭证创建一个 secret。如果集群同时启用了 [RBAC](/docs/admin/authorization/rbac/) 和 [Controller Roles](/docs/admin/authorization/rbac/#controller-roles), +为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。 + + +### Portworx 卷 + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: portworx-io-priority-high +provisioner: kubernetes.io/portworx-volume +parameters: + repl: "1" + snap_interval: "70" + io_priority: "high" + +``` + + +* `fs`:选择的文件系统:[none/xfs/ext4](默认:`ext4`)。 +* `block_size`:以 Kbytes 为单位的块大小(默认值:`32`)。 +* `repl`:同步副本数量,以复制因子 [1..3](默认值:`1`)的形式提供。 + 这里需要填写字符串,即,`"1"` 而不是 `1`。 +* `io_priority`:决定是否从更高性能或者较低优先级存储创建卷 [high/medium/low](默认值:`low`)。 +* `snap_interval`:触发快照的时钟/时间间隔(分钟)。快照是基于与先前快照的增量变化,0 是禁用快照(默认:`0`)。 + 这里需要填写字符串,即,是 `"70"` 而不是 `70`。 +* `aggregation_level`:指定卷分配到的块数量,0 表示一个非聚合卷(默认:`0`)。 + 这里需要填写字符串,即,是 `"0"` 而不是 `0`。 +* `ephemeral`:指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true , + `persistent volumes` 的使用场景可以将这个值设置为 false(例如 Cassandra 这样的数据库)[true/false](默认为 `false`)。这里需要填写字符串,即,是 `"true"` 而不是 `true`。 + +### ScaleIO + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: slow +provisioner: kubernetes.io/scaleio +parameters: + gateway: https://192.168.99.200:443/api + system: scaleio + protectionDomain: pd0 + storagePool: sp1 + storageMode: ThinProvisioned + secretRef: sio-secret + readOnly: false + fsType: xfs +``` + + +* `provisioner`:属性设置为 `kubernetes.io/scaleio` +* `gateway` 到 ScaleIO API 网关的地址(必需) +* `system`:ScaleIO 系统的名称(必需) +* `protectionDomain`:ScaleIO 保护域的名称(必需) +* `storagePool`:卷存储池的名称(必需) +* `storageMode`:存储提供模式:`ThinProvisioned`(默认)或 `ThickProvisioned` +* `secretRef`:对已配置的 Secret 对象的引用(必需) +* `readOnly`:指定挂载卷的访问模式(默认为 false) +* `fsType`:卷的文件系统(默认是 ext4) + + +ScaleIO Kubernetes 卷插件需要配置一个 Secret 对象。 +secret 必须用 `kubernetes.io/scaleio` 类型创建,并与引用它的 PVC 所属的名称空间使用相同的值 +如下面的命令所示: + +```shell +kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \ +--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \ +--namespace=default +``` + +### StorageOS + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: kubernetes.io/storageos +parameters: + pool: default + description: Kubernetes volume + fsType: ext4 + adminSecretNamespace: default + adminSecretName: storageos-secret +``` + + +* `pool`:分配卷的 StorageOS 分布式容量池的名称。如果未指定,则使用通常存在的 `default` 池。 +* `description`:分配给动态创建的卷的描述。所有卷描述对于 storage class 都是相同的, + 但不同的 storage class 可以使用不同的描述,以区分不同的使用场景。 + 默认为 `Kubernetas volume`。 +* `fsType`:请求的默认文件系统类型。请注意,在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4` +* `adminSecretNamespace`:API 配置 secret 所在的命名空间。如果设置了 adminSecretName,则是必需的。 +* `adminSecretName`:用于获取 StorageOS API 凭证的 secret 名称。如果未指定,则将尝试默认值。 + + +StorageOS Kubernetes 卷插件可以使 Secret 对象来指定用于访问 StorageOS API 的端点和凭据。 +只有当默认值已被更改时,这才是必须的。 +secret 必须使用 `kubernetes.io/storageos` 类型创建,如以下命令: + +```shell +kubectl create secret generic storageos-secret \ +--type="kubernetes.io/storageos" \ +--from-literal=apiAddress=tcp://localhost:5705 \ +--from-literal=apiUsername=storageos \ +--from-literal=apiPassword=storageos \ +--namespace=default +``` + + +用于动态分配卷的 Secret 可以在任何名称空间中创建,并通过 `adminSecretNamespace` 参数引用。 +预先配置的卷使用的 Secret 必须在与引用它的 PVC 在相同的名称空间中。 + + +### 本地 + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: local-storage +provisioner: kubernetes.io/no-provisioner +volumeBindingMode: WaitForFirstConsumer +``` + + +本地卷还不支持动态分配,然而还是需要创建 StorageClass 以延迟卷绑定,直到完成 pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。 + + +延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的 PersistentVolume 时能考虑到所有 pod 的调度限制。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/storage/storage-limits.md b/content/zh/docs/concepts/storage/storage-limits.md new file mode 100644 index 0000000000..832c6b5c9e --- /dev/null +++ b/content/zh/docs/concepts/storage/storage-limits.md @@ -0,0 +1,140 @@ +--- +title: 特定于节点的卷数限制 +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +此页面描述了各个云供应商可关联至一个节点的最大卷数。 + + + +谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 +Kubernetes 需要尊重这些限制。 否则,在节点上调度的 Pod 可能会卡住去等待卷的关联。 + + + +{{% /capture %}} + +{{% capture body %}} + + + +## Kubernetes 的默认限制 + +The Kubernetes 调度器对关联于一个节点的卷数有默认限制: + + + + + + +
云服务每节点最大卷数
Amazon Elastic Block Store (EBS)39
Google Persistent Disk16
Microsoft Azure Disk Storage16
+ + + +## 自定义限制 + +您可以通过设置 `KUBE_MAX_PD_VOLS` 环境变量的值来设置这些限制,然后再启动调度器。 + +如果设置的限制高于默认限制,请谨慎使用。请参阅云提供商的文档以确保节点可支持您设置的限制。 + +此限制应用于整个集群,所以它会影响所有节点。 + + + +## 动态卷限制 + +{{< feature-state state="beta" for_k8s_version="v1.12" >}} + + + +Kubernetes 1.11 引入了基于节点类型的动态卷限制的支持作为 Alpha 功能。 +在 Kubernetes 1.12 中,此功能升级到 Beta 版,将默认开启。 + +以下卷类型支持动态卷限制。 + +- Amazon EBS +- Google Persistent Disk +- Azure Disk +- CSI + + + +启用动态卷限制功能后,Kubernetes 会自动确定节点类型并确保节点上可关联的卷数目合规。 例如: + + + +* 在 +Google Compute Engine环境中, +[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将128个卷关联到节点。 + +* 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘,Kubernetes 仅允许 25 个卷关联到节点。 +对于 ec2 上的其他实例类型 +Amazon Elastic Compute Cloud (EC2), +Kubernetes 允许 39 个卷关联至节点。 + +* 在 Azure 环境中, 根据节点类型,最多 64 个磁盘可以关联至一个节点。 +更多详细信息,请参阅[Azure 虚拟机的数量大小](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes)。 + +* 对于 CSI,任何符合 CSI 规范中卷关联限制的驱动都将这些限制作为 Node 的 allocatable 属性。调度器不会往已经达到其容量限制的任何节点上调度具有卷的Pod。 参考 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) 获取更多详细信息。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/storage/volume-snapshot-classes.md b/content/zh/docs/concepts/storage/volume-snapshot-classes.md new file mode 100644 index 0000000000..17ea4de413 --- /dev/null +++ b/content/zh/docs/concepts/storage/volume-snapshot-classes.md @@ -0,0 +1,84 @@ +--- +title: 卷快照类 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + + + + +本文档描述了 Kubernetes 中 `VolumeSnapshotClass` 的概念。 建议熟悉[卷快照(Volume Snapshots)](/docs/concepts/storage/volume-snapshots/)和[存储类(Storage Class)](/docs/concepts/storage/storage-classes)。 +{{% /capture %}} + + +{{% capture body %}} + + + +## 介绍 + +就像 `StorageClass` 为管理员提供了一种在配置卷时描述存储“类”的方法,`VolumeSnapshotClass` 提供了一种在配置卷快照时描述存储“类”的方法。 + + + +## VolumeSnapshotClass 资源 + +每个 `VolumeSnapshotClass` 都包含 `snapshotter` 和 `parameters` 字段,当需要动态配置属于该类的 `VolumeSnapshot` 时使用。 + +`VolumeSnapshotClass` 对象的名称很重要,是用户可以请求特定类的方式。 +管理员在首次创建 `VolumeSnapshotClass` 对象时设置类的名称和其他参数,对象一旦创建就无法更新。 + +管理员可以为不请求任何特定类绑定的 VolumeSnapshots 指定默认的 `VolumeSnapshotClass`。 + + +```yaml +apiVersion: snapshot.storage.k8s.io/v1alpha1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +snapshotter: csi-hostpath +parameters: +``` + + +### 快照生成器(Snapshotter) + +卷快照类具有一个快照生成器,用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。 + + + +## 参数 + +卷快照类具有描述属于卷快照类的卷快照参数。 可根据 `snapshotter` 接受不同的参数。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..7288ac10a1 --- /dev/null +++ b/content/zh/docs/concepts/storage/volumes.md @@ -0,0 +1,2093 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +title: Volumes +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + + + +容器中的文件在磁盘上是临时存放的,这给容器中运行的特殊应用程序带来一些问题。 +首先,当容器崩溃时,kubelet 将重新启动容器,容器中的文件将会丢失——因为容器会以干净的状态重建。 +其次,当在一个 `Pod` 中同时运行多个容器时,常常需要在这些容器之间共享文件。 +Kubernetes 抽象出 `Volume` 对象来解决这两个问题。 + + + +阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 背景 + +Docker 也有 [Volume](https://docs.docker.com/engine/admin/volumes/) 的概念,但对它只有少量且松散的管理。 +在 Docker 中,Volume 是磁盘上或者另外一个容器内的一个目录。 +直到最近,Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。 +虽然 Docker 现在也能提供 Volume 驱动程序,但是目前功能还非常有限(例如,截至 Docker 1.7,每个容器只允许有一个 Volume 驱动程序,并且无法将参数传递给卷)。 + + + +另一方面,Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 +因此,卷比 Pod 中运行的任何容器的存活期都长,在容器重新启动时数据也会得到保留。 +当然,当一个 Pod 不再存在时,卷也将不再存在。也许更重要的是,Kubernetes 可以支持许多类型的卷,Pod 也能同时使用任意数量的卷。 + + + +卷的核心是包含一些数据的目录,Pod 中的容器可以访问该目录。 +特定的卷类型可以决定这个目录如何形成的,并能决定它支持何种介质,以及目录中存放什么内容。 + + + + +使用卷时, Pod 声明中需要提供卷的类型 (`.spec.volumes` 字段)和卷挂载的位置 (`.spec.containers.volumeMounts` 字段). + + + +容器中的进程能看到由它们的 Docker 镜像和卷组成的文件系统视图。 +[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) 位于文件系统层次结构的根部,并且任何 Volume 都挂载在镜像内的指定路径上。 +卷不能挂载到其他卷,也不能与其他卷有硬链接。 +Pod 中的每个容器必须独立地指定每个卷的挂载位置。 + + + +## Volume 的类型 + +Kubernetes 支持下列类型的卷: + + + * [awsElasticBlockStore](#awselasticblockstore) + * [azureDisk](#azuredisk) + * [azureFile](#azurefile) + * [cephfs](#cephfs) + * [configMap](#configmap) + * [csi](#csi) + * [downwardAPI](#downwardapi) + * [emptyDir](#emptydir) + * [fc (fibre channel)](#fc) + * [flocker](#flocker) + * [gcePersistentDisk](#gcepersistentdisk) + * [gitRepo (deprecated)](#gitrepo) + * [glusterfs](#glusterfs) + * [hostPath](#hostpath) + * [iscsi](#iscsi) + * [local](#local) + * [nfs](#nfs) + * [persistentVolumeClaim](#persistentvolumeclaim) + * [projected](#projected) + * [portworxVolume](#portworxvolume) + * [quobyte](#quobyte) + * [rbd](#rbd) + * [scaleIO](#scaleio) + * [secret](#secret) + * [storageos](#storageos) + * [vsphereVolume](#vspherevolume) + + + +我们欢迎大家贡献其他的卷类型支持。 + +### awsElasticBlockStore {#awselasticblockstore} + + + +`awsElasticBlockStore` 卷将 Amazon Web服务(AWS)[EBS 卷](http://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 +与 `emptyDir` 在删除 Pod 时会被删除不同,EBS 卷的内容在删除 Pod 时会被保留,卷只是被卸载掉了。 +这意味着 EBS 卷可以预先填充数据,并且可以在 Pod 之间传递数据。 + +{{< caution >}} + +您在使用 EBS 卷之前必须先创建它,可以使用 `aws ec2 create-volume` 命令进行创建;也可以使用 AWS API 进行创建。 +{{< /caution >}} + + + +使用 `awsElasticBlockStore` 卷时有一些限制: + +* Pod 正在运行的节点必须是 AWS EC2 实例。 +* 这些实例需要与 EBS 卷在相同的地域(region)和可用区(availability-zone)。 +* EBS 卷只支持被挂载到单个 EC2 实例上。 + + + +#### 创建 EBS 卷 + +在将 EBS 卷用到 Pod 上之前,您首先要创建它。 + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + + + +确保该区域与您的群集所在的区域相匹配。(也要检查卷的大小和 EBS 卷类型都适合您的用途!) + + + +#### AWS EBS 配置示例 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # This AWS EBS volume must already exist. + awsElasticBlockStore: + volumeID: + fsType: ext4 +``` + +### azureDisk {#azuredisk} + + + +`azureDisk` 用来在 Pod 上挂载 Microsoft Azure [数据盘(Data Disk)](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) . +更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)。 + +### azureFile {#azurefile} + + + +`azureFile` 用来在 Pod 上挂载 Microsoft Azure 文件卷(File Volume) (SMB 2.1 和 3.0)。 +更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 + +### cephfs {#cephfs} + + + +`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,`cephfs` 卷的内容在删除 Pod 时会被保留,卷只是被卸载掉了。 +这意味着 CephFS 卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。 + + +{{< caution >}} + +在您使用 Ceph 卷之前,您的 Ceph 服务器必须正常运行并且要使用的 share 被导出(exported)。 +{{< /caution >}} + + + +更多信息请参考 [CephFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/cephfs/)。 + +### configMap {#configmap} + + + +[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 +`ConfigMap` 对象中存储的数据可以被 `configMap` 类型的卷引用,然后被应用到 Pod 中运行的容器化应用。 + + + +当引用 `configMap` 对象时,你可以简单的在 Volume 中通过它名称来引用。 +还可以自定义 ConfigMap 中特定条目所要使用的路径。 +例如,要将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` 的 Pod 中,您可以使用下面的 YAML: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + + + +`log-config` ConfigMap 是以卷的形式挂载的, +存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 "`/etc/config/log_level`" 路径下。 +请注意,这个路径来源于 Volume 的 `mountPath` 和 `log_level` 键对应的 `path`。 + +{{< caution >}} + +在使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 +{{< /caution >}} + +{{< note >}} + +容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时,将无法接收 ConfigMap 的更新。 +{{< /note >}} + +### downwardAPI {#downwardapi} + + + +`downwardAPI` 卷用于使 downward API 数据对应用程序可用。 +这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 + +{{< note >}} + +容器以挂载 [subPath](#using-subpath) 卷的方式使用 downwardAPI 时,将不能接收到它的更新。 +{{< /note >}} + + +更多详细信息请参考 [`downwardAPI` 卷示例](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 + +### emptyDir {#emptydir} + + + +当 Pod 指定到某个节点上时,首先创建的是一个 `emptyDir` 卷,并且只要 Pod 在该节点上运行,卷就一直存在。 +就像它的名称表示的那样,卷最初是空的。 +尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同,但是这些容器都可以读写 `emptyDir` 卷中相同的文件。 +当 Pod 因为某些原因被从节点上删除时,`emptyDir` 卷中的数据也会永久删除。 + +{{< note >}} + +容器崩溃并不会导致 Pod 被从节点上移除,因此容器崩溃时 `emptyDir` 卷中的数据是安全的。 +{{< /note >}} + + + +`emptyDir` 的一些用途: + +* 缓存空间,例如基于磁盘的归并排序。 +* 为耗时较长的计算任务提供检查点,以便任务能方便地从崩溃前状态恢复执行。 +* 在 Web 服务器容器服务数据时,保存内容管理器容器获取的文件。 + + + + +默认情况下, `emptyDir` 卷存储在支持该节点所使用的介质上;这里的介质可以是磁盘或 SSD 或网络存储,这取决于您的环境。 +但是,您可以将 `emptyDir.medium` 字段设置为 `"Memory"`,以告诉 Kubernetes 为您安装 tmpfs(基于 RAM 的文件系统)。 +虽然 tmpfs 速度非常快,但是要注意它与磁盘不同。 +tmpfs 在节点重启时会被清除,并且您所写入的所有文件都会计入容器的内存消耗,受容器内存限制约束。 + + + +#### Pod 示例 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + + + +### fc (光纤通道) {#fc} + +`fc` 卷允许将现有的光纤通道卷挂载到 Pod 中。 +可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN。 +如果指定多个 WWN,targetWWNs 期望这些 WWN 来自多路径连接。 + +{{< caution >}} + +您必须配置 FC SAN Zoning,以便预先向目标 WWN 分配和屏蔽这些 LUN(卷),这样 Kubernetes 主机才可以访问它们。 +{{< /caution >}} + + + +更多详情请参考 [FC 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)。 + + + +### flocker {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker) 是一个开源的、集群化的容器数据卷管理器。 +Flocker 提供了由各种存储后备支持的数据卷的管理和编排。 + + + +`flocker` 卷允许将一个 Flocker 数据集挂载到 Pod 中。 +如果数据集在 Flocker 中不存在,则需要首先使用 Flocker CLI 或 Flocker API 创建数据集。 +如果数据集已经存在,那么 Flocker 将把它重新附加到 Pod 被调度的节点。 +这意味着数据可以根据需要在 Pod 之间 "传递"。 + + +{{< caution >}} + +您在使用 Flocker 之前必须先安装运行自己的 Flocker。 +{{< /caution >}} + + + +更多详情请参考 [Flocker 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)。 + + + +### gcePersistentDisk {#gcepersistentdisk} + +`gcePersistentDisk` 卷能将谷歌计算引擎 (GCE) [持久盘(PD)](http://cloud.google.com/compute/docs/disks) 挂载到您的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,持久盘卷的内容在删除 Pod 时会被保留,卷只是被卸载掉了。 +这意味着持久盘卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。 + +{{< caution >}} + +您在使用 PD 前,必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 +{{< /caution >}} + + + +使用 `gcePersistentDisk` 时有一些限制: + +* 运行 Pod 的节点必须是 GCE VM +* 那些 VM 必须和持久盘属于相同的 GCE 项目和区域(zone) + + + +PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 +这意味着您可以用数据集预先填充 PD,然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 +不幸的是,PD 只能由单个使用者以读写模式挂载——即不允许同时写入。 + + + +在由 ReplicationController 所管理的 Pod 上使用 PD 将会失败,除非 PD 是只读模式或者副本的数量是 0 或 1。 + + + +#### 创建持久盘(PD) + +在 Pod 中使用 GCE 持久盘之前,您首先要创建它。 + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + + + +#### Pod 示例 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # This GCE PD must already exist. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + + +#### 区域持久盘(Regional Persistent Disks) + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + + + +[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许您创建能在同一区域的两个可用区中使用的持久盘。 +要使用这个功能,必须以持久盘的方式提供卷;Pod 不支持直接引用这种卷。 + + + +#### 手动供应基于区域 PD 的 PersistentVolume + +使用 [为 GCE PD 定义的存储类](/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 +在创建 PersistentVolume 之前,您首先要创建 PD。 + +```shell +gcloud beta compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` + + + +PersistentVolume 示例: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume + labels: + failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + + + +### gitRepo (已弃用) + +{{< warning >}} + +gitRepo 卷类型已经被废弃。如果需要在容器中提供 git 仓库,请将一个 [EmptyDir](#emptydir) 卷挂载到 InitContainer 中,使用 git 命令完成仓库的克隆操作,然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 +{{< /warning >}} + + + +`gitRepo` 卷是一个卷插件的例子。 +该卷类型挂载了一个空目录,并将一个 Git 代码仓库克隆到这个目录中供您使用。 +将来,这种卷可能被移动到一个更加解耦的模型中,而不是针对每个应用案例扩展 Kubernetes API。 + +下面给出一个 gitRepo 卷的示例: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs {#glusterfs} + + + +`glusterfs` 卷能将 [Glusterfs](http://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,`glusterfs` 卷的内容在删除 Pod 时会被保存,卷只是被卸载掉了。 +这意味着 `glusterfs` 卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。GlusterFS 可以被多个写者同时挂载。 + +{{< caution >}} + +在使用前您必须先安装运行自己的 GlusterFS。 +{{< /caution >}} + + + +更多详情请参考 [GlusterFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/glusterfs)。 + +### hostPath {#hostpath} + + + +`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 +虽然这不是大多数 Pod 需要的,但是它为一些应用程序提供了强大的逃生舱。 + + + +例如,`hostPath` 的一些用法有: + +* 运行一个需要访问 Docker 引擎内部机制的容器;请使用 `hostPath` 挂载 `/var/lib/docker` 路径。 +* 在容器中运行 cAdvisor 时,以 `hostPath` 方式挂载 `/sys`。 +* 允许 Pod 指定给定的 `hostPath` 在运行 Pod 之前是否应该存在,是否应该创建以及应该以什么方式存在。 + + + +除了必需的 `path` 属性之外,用户可以选择性地为 `hostPath` 卷指定 `type`。 + +支持的 `type` 值如下: + + + + +| 取值 | 行为 | +|:------|:---------| +| | 空字符串(默认)用于向后兼容,这意味着在安装 hostPath 卷之前不会执行任何检查。 | +| `DirectoryOrCreate` | 如果在给定路径上什么都不存在,那么将根据需要创建空目录,权限设置为 0755,具有与 Kubelet 相同的组和所有权。 | +| `Directory` | 在给定路径上必须存在的目录。| +| `FileOrCreate` | 如果在给定路径上什么都不存在,那么将在那里根据需要创建空文件,权限设置为 0644,具有与 Kubelet 相同的组和所有权。| +| `File` | 在给定路径上必须存在的文件。| +| `Socket` | 在给定路径上必须存在的 UNIX 套接字。| +| `CharDevice` | 在给定路径上必须存在的字符设备。| +| `BlockDevice` | 在给定路径上必须存在的块设备。| + + + +当使用这种类型的卷时要小心,因为: + +* 具有相同配置(例如从 podTemplate 创建)的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 +* 当 Kubernetes 按照计划添加资源感知的调度时,这类调度机制将无法考虑由 `hostPath` 使用的资源。 +* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 [特权容器](/docs/user-guide/security-context) 中以 root 身份运行进程,或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 + + + +#### Pod 示例 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # directory location on host + path: /data + # this field is optional + type: Directory +``` + +### iscsi {#iscsi} + + + +`iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 挂载到您的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,持久盘 卷的内容在删除 Pod 时会被保存,卷只是被卸载掉了。 +这意味着 `iscsi` 卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。 + +{{< caution >}} + +在您使用 iSCSI 卷之前,您必须拥有自己的 iSCSI 服务器,并在上面创建卷。 +{{< /caution >}} + + + +iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 +这意味着您可以用数据集预先填充卷,然后根据需要在尽可能多的 Pod 上提供它。不幸的是,iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。 + + + +更多详情请参考 [iSCSI 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/iscsi)。 + + + +### local {#local} + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +{{< note >}} + +alpha 版本的 PersistentVolume NodeAffinity 注释已被取消,将在将来的版本中废弃。 +用户必须更新现有的使用该注解的 PersistentVolume,以使用新的 PersistentVolume `NodeAffinity` 字段。 +{{< /note >}} + + + +`local` 卷指的是所挂载的某个本地存储设备,例如磁盘、分区或者目录。 + +`local` 卷只能用作静态创建的持久卷。尚不支持动态配置。 + + + +相比 `hostPath` 卷,`local` 卷可以以持久和可移植的方式使用,而无需手动将 Pod 调度到节点,因为系统通过查看 PersistentVolume 所属节点的亲和性配置,就能了解卷的节点约束。 + + + +然而,`local` 卷仍然取决于底层节点的可用性,并不是适合所有应用程序。 +如果节点变得不健康,那么`local` 卷也将变得不可访问,并且使用它的 Pod 将不能运行。 +使用 `local` 卷的应用程序必须能够容忍这种可用性的降低,以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 + +下面是一个使用 `local` 卷和 `nodeAffinity` 的持久卷示例: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + # volumeMode field requires BlockVolume Alpha feature gate to be enabled. + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + + + +使用 `local` 卷时,需要使用 PersistentVolume 对象的 `nodeAffinity` 字段。 +它使 Kubernetes 调度器能够将使用 `local` 卷的 Pod 正确地调度到合适的节点。 + + + +现在,可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block"(而不是默认值 "Filesystem"),以将 `local` 卷作为原始块设备暴露出来。 +`volumeMode` 字段需要启用 Alpha 功能 `BlockVolume`。 + + + +当使用 `local` 卷时,建议创建一个 StorageClass,将 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。 +请参考 [示例](/docs/concepts/storage/storage-classes/#local)。 +延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时,会评估 Pod 可能具有的其他节点约束,例如:如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 + + + +您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 +请注意,此驱动不支持动态配置。 +有关如何运行外部 `local` 卷驱动的示例,请参考 [local 卷驱动用户指南](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)。 + +{{< note >}} + +如果不使用外部静态驱动来管理卷的生命周期,则用户需要手动清理和删除 local 类型的持久卷。 +{{< /note >}} + +### nfs {#nfs} + + + +`nfs` 卷能将 NFS (网络文件系统) 挂载到您的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,`nfs` 卷的内容在删除 Pod 时会被保存,卷只是被卸载掉了。 +这意味着 `nfs` 卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。 + +{{< caution >}} + +在您使用 NFS 卷之前,必须运行自己的 NFS 服务器并将目标 share 导出备用。 +{{< /caution >}} + + + +要了解更多详情请参考 [NFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)。 + +### persistentVolumeClaim {#persistentvolumeclaim} + + +`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)(PersistentVolume)挂载到 Pod 中。 +持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储(例如 GCE PersistentDisk 或者 iSCSI 卷)的一种方法。 + + + +更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/) + +### projected {#projected} + + + +`projected` 卷类型能将若干现有的卷来源映射到同一目录上。 + +目前,可以映射的卷来源类型如下: + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + + + +所有的卷来源需要和 Pod 处于相同的命名空间。 +更多详情请参考[一体化卷设计文档](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)。 + + + +服务帐户令牌的映射是 Kubernetes 1.11 版本中引入的一个功能,并在 1.12 版本中被提升为 Beta 功能。 +若要在 1.11 版本中启用此特性,需要显式设置 `TokenRequestProjection` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 + + + +#### 包含 secret、downwardAPI 和 configmap 的 Pod 示例如下: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + + + +带有非默认许可模式设置的多个 secret 的 Pod 示例如下: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + + +每个被投射的卷来源都在 spec 中的 `sources` 内列出。 +参数几乎相同,除了两处例外: + +* 对于 secret,`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 +* `defaultMode` 只能根据投射级别指定,而不是针对每个卷来源指定。不过,如上所述,您可以显式地为每个投射项设置 `mode` 值。 + + + +当开启 `TokenRequestProjection` 功能时,可以将当前 [服务帐户](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的令牌注入 Pod 中的指定路径。 +下面是一个例子: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + + + +示例 Pod 具有包含注入服务帐户令牌的映射卷。 +例如,这个令牌可以被 Pod 容器用来访问 Kubernetes API服务器。 +`audience` 字段包含令牌的预期受众。 +令牌的接收者必须使用令牌的受众中指定的标识符来标识自己,否则应拒绝令牌。 +此字段是可选的,默认值是 API 服务器的标识符。 + + + +`expirationSeconds` 是服务帐户令牌的有效期。 +默认值为 1 小时,必须至少 10 分钟(600 秒)。 +管理员还可以通过指定 API 服务器的 `--service-account-max-token-expiration` 选项来限制其最大值。 +`path` 字段指定相对于映射卷的挂载点的相对路径。 + +{{< note >}} + +使用投射卷源作为 [subPath](#using-subpath) 卷挂载的容器将不会接收这些卷源的更新。 +{{< /note >}} + +### portworxVolume {#portworxvolume} + + + +`portworxVolume` 是一个可伸缩的块存储层,能够以超聚合(hyperconverged)的方式与 Kubernetes 一起运行。 +Portworx 支持对服务器上存储的指纹处理、基于存储能力进行分层以及跨多个服务器整合存储容量。 +Portworx 可以以 in-guest 方式在虚拟机中运行,也可以在裸金属 Linux 节点上运行。 + + + +`portworxVolume` 类型的卷可以通过 Kubernetes 动态创建,也可以在 Kubernetes Pod 内预先供应和引用。 +下面是一个引用预先配置的 PortworxVolume 的示例 Pod: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # This Portworx volume must already exist. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< caution >}} + +在 Pod 中使用 portworxVolume 之前,请确保有一个名为 `pxvol` 的 PortworxVolume 存在。 +{{< /caution >}} + + + +更多详情和示例可以在[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)找到。 + +### quobyte {#quobyte} + + + +`quobyte` 卷允许将现有的 [Quobyte](http://www.quobyte.com) 卷挂载到您的 Pod 中。 + +{{< caution >}} + +在使用 Quobyte 卷之前,您首先要进行安装并创建好卷。 + +{{< /caution >}} + + + +更多详情请参考 [Quobyte 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/quobyte)。 + +### rbd {#rbd} + + + +`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,`rbd` 卷的内容在删除 Pod 时会被保存,卷只是被卸载掉了。 +这意味着 `rbd` 卷可以被预先填充数据,并且这些数据可以在 Pod 之间"传递"。 + + +{{< caution >}} + +在使用 RBD 之前,您必须安装运行 Ceph。 +{{< /caution >}} + + + +RBD 的一个特点是它可以同时被多个用户以只读方式挂载。 +这意味着您可以用数据集预先填充卷,然后根据需要从尽可能多的 Pod 中并行地提供卷。 +不幸的是,RBD 卷只能由单个使用者以读写模式安装——不允许同时写入。 + +更多详情请参考 [RBD 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/rbd)。 + +### scaleIO {#scaleio} + + + +ScaleIO 是基于软件的存储平台,可以使用现有硬件来创建可伸缩的、共享的而且是网络化的块存储集群。 +`scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷(或者它可以动态地为持久卷申领提供新的卷,参见[ScaleIO 持久卷](/docs/concepts/storage/persistent-volumes/#scaleio))。 + +{{< caution >}} + +在使用前,您必须有个安装完毕且运行正常的 ScaleIO 集群,并且创建好了存储卷。 +{{< /caution >}} + + + +下面是配置了 ScaleIO 的 Pod 示例: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + + + +更多详情,请参考 [ScaleIO 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)。 + +### secret {#secret} + + + +`secret` 卷用来给 Pod 传递敏感信息,例如密码。您可以将 secret 存储在 Kubernetes API 服务器上,然后以文件的形式挂在到 Pod 中,无需直接与 Kubernetes 耦合。 +`secret` 卷由 tmpfs(基于 RAM 的文件系统)提供存储,因此它们永远不会被写入非易失性(持久化的)存储器。 + +{{< caution >}} + +使用前您必须在 Kubernetes API 中创建 secret。 +{{< /caution >}} + +{{< note >}} + +容器以 [subPath](#using-subpath) 卷的方式挂载 Secret 时,它将感知不到 Secret 的更新。 +{{< /note >}} + + + +Secret 的更多详情请参考[这里](/docs/user-guide/secrets)。 + +### storageOS {#storageos} + + + +`storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到您的 Pod 中。 + + + +StorageOS 在 Kubernetes 环境中以容器的形式运行,这使得应用能够从 Kubernetes 集群中的任何节点访问本地或关联的存储。 +为应对节点失效状况,可以复制数据。 +若需提高利用率和降低成本,可以考虑瘦配置(Thin Provisioning)和数据压缩。 + + + +作为其核心能力之一,StorageOS 为容器提供了可以通过文件系统访问的块存储。 + +StorageOS 容器需要 64 位的 Linux,并且没有其他的依赖关系。 +StorageOS 提供免费的开发者授权许可。 + +{{< caution >}} + + +您必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 StorageOS 容器。 +有关安装说明,请参阅 [StorageOS 文档](https://docs.storageos.com)。 + +{{< /caution >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace. + volumeName: redis-vol01 + fsType: ext4 +``` + + + +更多关于动态供应和持久卷申领的信息请参考 [StorageOS 示例](https://github.com/kubernetes/examples/blob/master/staging/volumes/storageos)。 + +### vsphereVolume {#vspherevolume} + +{{< note >}} + +前提条件:配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 [vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 +{{< /note >}} + + + +`vsphereVolume` 用来将 vSphere VMDK 卷挂载到您的 Pod 中。 +在卸载卷时,卷的内容会被保留。 +vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 + +{{< caution >}} + +在挂载到 Pod 之前,您必须用下列方式之一创建 VMDK。 +{{< /caution >}} + + + +#### 创建 VMDK 卷 + +选择下列方式之一创建 VMDK。 + +{{< tabs name="tabs_volumes" >}} +{{% tab name="使用 vmkfstools 创建" %}} + + + + +首先 ssh 到 ESX,然后使用下面的命令来创建 VMDK: + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` +{{% /tab %}} +{{% tab name="使用 vmware-vdiskmanager 创建" %}} + + + + +使用下面的命令创建 VMDK: + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` +{{% /tab %}} + +{{< /tabs >}} + + + + +#### vSphere VMDK 配置示例 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # This VMDK volume must already exist. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + + + +更多示例可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)找到。 + + + +## 使用 subPath + +有时,在单个 Pod 中共享卷以供多方使用是很有用的。 +`volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径,而不是其根路径。 + + + +下面是一个使用同一共享卷的、内含 LAMP 栈(Linux Apache Mysql PHP)的 Pod 的示例。 +HTML 内容被映射到卷的 `html` 文件夹,数据库将被存储在卷的 `mysql` 文件夹中: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + + + +### 使用带有扩展环境变量的 subPath + +{{< feature-state for_k8s_version="v1.11" state="alpha" >}} + + + +`subPath` 的目录名也可以由 Downward API 环境变量构造。 +在使用此特性之前,必须启用 `VolumeSubpathEnvExpansion` 功能开关。 + + + +在这个示例中,Pod 基于 Downward API 中的 Pod 名称,使用 `subPath` 在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 +主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 中。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPath: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + + + +## 资源 + +`emptyDir` 卷的存储介质(磁盘、SSD 等)是由保存 kubelet 根目录(通常是 `/var/lib/kubelet`)的文件系统的介质确定。 +`emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制,容器之间或 Pod 之间也没有隔离。 + + + +将来,我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 [resource](/docs/user-guide/computeresources) 规范来请求一定量的空间,并且能够为具有多种介质类型的集群选择要使用的介质类型。 + + + +## Out-of-Tree 卷插件 + +Out-of-Tree 卷插件包括容器存储接口(CSI)和 Flexvolume。 +它们使存储供应商能够创建自定义存储插件,而无需将它们添加到 Kubernetes 代码仓库。 + + + +在引入 CSI 和 Flexvolume 之前,所有卷插件(如上面列出的卷类型)都是 "in-tree" 的,这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的,并且这些插件都扩展了 Kubernetes 的核心 API。 +这意味着向 Kubernetes 添加新的存储系统(卷插件)需要将代码合并到 Kubernetes 核心代码库中。 + + + +CSI 和 Flexvolume 都允许独立于 Kubernetes 代码库开发卷插件,并作为扩展部署(安装)在 Kubernetes 集群上。 + +对于希望创建 out-of-tree 卷插件的存储供应商,请参考[这个 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。 + +### CSI + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + + + +[容器存储接口](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) +为容器编排系统(如 Kubernetes)定义标准接口,以将任意存储系统暴露给它们的容器工作负载。 + + + +更多详情请阅读 [CSI 设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)。 + +CSI 的支持在 Kubernetes v1.9 中作为 alpha 特性引入,并在 Kubernetes v1.10 中转为 beta 特性。 + + + +一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序,用户就可以使用 `csi` 卷类型来关联、挂载 CSI 驱动程序暴露出来的卷。 + +`csi` 卷类型不支持来自 Pod 的直接引用,只能通过 `PersistentVolumeClaim` 对象在 Pod 中引用。 + +存储管理员可以使用以下字段来配置 CSI 持久卷: + + +- + + `driver`:指定要使用的卷驱动程序名称的字符串值。 + 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应;该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。 + Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序;CSI 驱动程序也使用该值来辨识哪些 PV 对象属于该 CSI 驱动程序。 + +- + + `volumeHandle`:唯一标识卷的字符串值。 + 该值必须与CSI 驱动程序在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应;接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 + 在所有对 CSI 卷驱动程序的调用中,引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 + +- + + `readOnly`:一个可选的布尔值,指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。 + 默认值是 false。 + 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动程序。 + + +- + + `fsType`:如果 PV 的 `VolumeMode` 为 `Filesystem`,那么此字段指定挂载卷时应该使用的文件系统。 + 如果卷尚未格式化,并且支持格式化,此值将用于格式化卷。 + 此值可以通过 `ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和 + `NodePublishVolumeRequest` 的 `VolumeCapability` 字段传递给 CSI 驱动。 + + +- + + `volumeAttributes`:一个字符串到字符串的映射表,用来设置卷的静态属性。 + 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应;[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 + 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 + +- + + `controllerPublishSecretRef`:对包含敏感信息的 secret 对象的引用;该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 + 此字段是可选的;在不需要 secret 时可以是空的。 + 如果 secret 对象包含多个 secret,则所有的 secret 都会被传递。 + +- + + `nodeStageSecretRef`:对包含敏感信息的 secret 对象的引用,以传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 + 此字段是可选的,如果不需要 secret,则可能是空的。 + 如果 secret 对象包含多个 secret,则传递所有 secret。 + +- + + `nodePublishSecretRef`:对包含敏感信息的 secret 对象的引用,以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 + 此字段是可选的,如果不需要 secret,则可能是空的。 + 如果 secret 对象包含多个 secret,则传递所有 secret。 + + +#### CSI 原始块卷支持 + +{{< feature-state for_k8s_version="v1.11" state="alpha" >}} + + + +从 1.11 版本开始,CSI 引入了对原始块卷的支持。该特性依赖于在 Kubernetes 的之前版本中引入的原始块卷(Raw Block Volume)功能。 +该特性将使具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 + + + +CSI 块卷支持是可选功能,并且默认关闭。 +为了在启用块卷支持的情况下运行 CSI,集群管理员必须使用以下特性开关参数为每个 Kubernetes 组件启用该特性: + +``` +--feature-gates=BlockVolume=true,CSIBlockVolume=true +``` + +学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 + + +### Flexvolume + + +Flexvolume 是一个自 1.2 版本(在 CSI 之前)以来在 Kubernetes 中一直存在的 out-of-tree 插件接口。 +它使用基于 exec 的模型来与驱动程序对接。 +用户必须在每个节点(在某些情况下是主节点)上的预定义卷插件路径中安装 Flexvolume 驱动程序可执行文件。 + +Pod 通过 `flexvolume` in-tree 插件与 Flexvolume 驱动程序交互。 +更多详情请参考[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)。 + + + +## 挂载卷的传播 + +挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器,甚至共享到同一节点上的其他 Pod。 + +卷的挂载传播特性由 Container.volumeMounts 中的 `mountPropagation` 字段控制。 +它的值包括: + + * + `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 + 类似的,容器所创建的卷挂载在主机上是不可见的。这是默认模式。 + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)中描述的 `private` 挂载传播选项。 + + * + `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 + + 换句话说,如果主机在此挂载卷中挂载任何内容,容器将能看到它被挂载在那里。 + + 类似的,配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容,挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rslave` 挂载传播选项。 + + * + --`Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 + + 另外,容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rshared` 挂载传播选项。 + + +{{< caution >}} + + +`Bidirectional` 形式的挂载传播可能比较危险。 +它可以破坏主机操作系统,因此它只被允许在特权容器中使用。 +强烈建议您熟悉 Linux 内核行为。 +此外,由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁(卸载)。 + +{{< /caution >}} + + +### 配置 + +在某些部署环境中,挂载传播正常工作前,必须在 Docker 中正确配置挂载共享(mount share),如下所示。 + + +编辑您的 Docker `systemd` 服务文件,按下面的方法设置 `MountFlags`: + +```shell +MountFlags=shared +``` + +或者,如果存在 `MountFlags=slave` 就删除掉。然后重启 Docker 守护进程: + +```shell +$ sudo systemctl daemon-reload +$ sudo systemctl restart docker +``` + +{{% capture whatsnext %}} + +参考[使用持久卷部署 WordPress 和 MySQL](/docs/tutorials/stateful-application/mysqlwordpress-persistent-volume/) 示例。 +{{% /capture %}} diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh/docs/concepts/workloads/_index.md index 4e1e785585..850d6b64bd 100644 --- a/content/zh/docs/concepts/workloads/_index.md +++ b/content/zh/docs/concepts/workloads/_index.md @@ -8,4 +8,4 @@ weight: 50 title: "Workloads" weight: 50 --- ---> \ No newline at end of file +--> diff --git a/content/zh/docs/concepts/workloads/controllers/_index.md b/content/zh/docs/concepts/workloads/controllers/_index.md index 87407c0336..21c6b5b903 100644 --- a/content/zh/docs/concepts/workloads/controllers/_index.md +++ b/content/zh/docs/concepts/workloads/controllers/_index.md @@ -1,11 +1,11 @@ +--- +title: "控制器" +weight: 20 +--- + - ---- -title: "控制器" -weight: 20 ---- diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index a409a24a9a..b3c1ca794f 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,212 +1,104 @@ --- -approvers: +reviewers: - erictune - soltysh - janetkuo -title: Cron Job -redirect_from: -- "/docs/concepts/jobs/cron-jobs/" -- "/docs/concepts/jobs/cron-jobs.html" -- "/docs/user-guide/cron-jobs/" -- "/docs/user-guide/cron-jobs.html" +title: CronJob +content_template: templates/concept +weight: 80 --- -{{< toc >}} +{{% capture overview %}} + -## Cron Job 是什么? +_Cron Job_ 创建基于时间调度的 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 -_Cron Job_ 管理基于时间的 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/),即: +一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写,并周期性的在给定的调度时间执行 Job。 -* 在给定时间点只运行一次 -* 在给定时间点周期性地运行 +{{< note >}} + +所有 **CronJob** 的 `schedule:` 时间都是用 UTC 表示。 +{{< /note >}} -一个 CronJob 对象类似于 _crontab_ (cron table)文件中的一行。它根据指定的预定计划周期性地运行一个 Job,格式可以参考 [Cron](https://en.wikipedia.org/wiki/Cron) 。 + +有关创建和使用 CronJob 的说明及规范文件的示例,请参见 [使用 CronJob 运行自动任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。 -**注意:** 在预定计划中,问号(`?`)和星号(`*`)的意义是相同的,表示给定字段的取值是任意可用值。 +{{% /capture %}} -**注意:** 在 Kubernetes 1.4 版本引入了 ScheduledJob 资源,但从 1.5 版本开始改成了 CronJob。 -典型的用法如下所示: +{{% capture body %}} + -* 在给定的时间点调度 Job 运行 -* 创建周期性运行的 Job,例如:数据库备份、发送邮件。 +## CronJob 限制 -### 前提条件 +CronJob 创建 Job 对象,每个 Job 的执行次数大约为一次。 +我们之所以说 "大约",是因为在某些情况下,可能会创建两个 Job,或者不会创建任何 Job。 +我们试图使这些情况尽量少发生,但不能完全杜绝。因此,Job 应该是 _幂等的_。 + +如果 `startingDeadlineSeconds` 设置为很大的数值或未设置(默认),并且 `concurrencyPolicy` 设置为 `Allow`,则作业将始终至少运行一次。 -当使用的 Kubernetes 集群,版本 >= 1.4(对 ScheduledJob),>= 1.5(对 CronJob),当启动 API Server(参考 [为集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster) 获取更多信息)时,通过传递选项 `--runtime-config=batch/v2alpha1=true` 可以开启 batch/v2alpha1 API。 + -## 创建 Cron Job +对于每个 CronJob,CronJob 控制器检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次,那么它就不会启动这个任务,并记录这个错误: -下面是一个 Cron Job 的例子。它会每分钟运行一个 Job,打印出当前时间并输出问候语 hello。 +```` +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. -% include code.html language="yaml" file="cronjob.yaml" ghlink="/docs/concepts/workloads/controllers/cronjob.yaml" %} +```` -下载并运行该示例 Cron Job,然后执行如下命令: + -```shell -$ kubectl create -f ./cronjob.yaml -cronjob "hello" created -``` +需要注意的是,如果设置 `startingDeadlineSeconds` 字段非空,则控制器会统计从 `startingDeadlineSeconds` 的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如,如果 `startingDeadlineSeconds` 是 `200`,则控制器会统计在过去 200 秒中错过了多少次 Job。 + +如果未能在调度时间内创建 CronJob,则计为错过。例如,如果 `concurrencyPolicy` 被设置为 `Forbid`,并且当前有一个调度仍在运行的情况下,试图调度的 CronJob 将被计算为错过。 -可选地,使用 `kubectl run` 创建一个 Cron Job,不需要写完整的配置: + -```shell -$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster" -cronjob "hello" created -``` +例如,假设一个 CronJob 被设置为`08:30:00` 准时开始,它的 `startingDeadlineSeconds` 属性被设置为10,如果在`08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`,Job 将不会启动。 +如果觉得晚些开始比没有启动好,那请设置一个较长的 `startingDeadlineSeconds`。 + +CronJob 只负责创建与其时间表相匹配的 Job,相应的 Job 又会负责管理它所代表的Pod。 -创建该 Cron Job 之后,通过如下命令获取它的状态信息: - -```shell -$ kubectl get cronjob hello -NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE -hello */1 * * * * False 0 -``` - - - -如上所示,既没有 active 的 Job,也没有被调度的 Job。 - -等待并观察创建的 Job,大约一分钟时间: - -```shell -$ kubectl get jobs --watch -NAME DESIRED SUCCESSFUL AGE -hello-4111706356 1 1 2s -``` - - - -现在能看到一个名称为 hello 的 Job 在运行。我们可以停止观察,并再次获取该 Job 的状态信息: - -```shell -$ kubectl get cronjob hello -NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE -hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700 -``` - - -应该能够看到名称为 “hello” 的 Job 在 `LAST-SCHEDULE` 指定的时间点被调度了。当前存在 0 个活跃(Active)的 Job,说明该 Job 已经被调度运行完成或失败。 - -现在,找到最近一次被调度的 Job 创建的 Pod,能够看到其中一个 Pod 的标准输出。注意,Job 名称和 Pod 名称是不一样的。 - -```shell -# Replace "hello-4111706356" with the job name in your system -$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name}) - -$ echo $pods -hello-4111706356-o9qcm - -$ kubectl logs $pods -Mon Aug 29 21:34:09 UTC 2016 -Hello from the Kubernetes cluster -``` - - -## 删除 Cron Job - -一旦不再需要 Cron Job,简单地可以使用 `kubectl` 命令删除它: - -```shell -$ kubectl delete cronjob hello -cronjob "hello" deleted -``` - - - -这将会终止正在创建的 Job。然而,运行中的 Job 将不会被终止,不会删除 Job 或 它们的 Pod。为了清理那些 Job 和 Pod,需要列出该 Cron Job 创建的全部 Job,然后删除它们: - -```shell -$ kubectl get jobs -NAME DESIRED SUCCESSFUL AGE -hello-1201907962 1 1 11m -hello-1202039034 1 1 8m -... - -$ kubectl delete jobs hello-1201907962 hello-1202039034 ... -job "hello-1201907962" deleted -job "hello-1202039034" deleted -... -``` - - - -一旦 Job 被删除,由 Job 创建的 Pod 也会被删除。注意,所有由名称为 “hello” 的 Cron Job 创建的 Job 会以前缀字符串 “hello-” 进行命名。如果想要删除当前 Namespace 中的所有 Job,可以通过命令 `kubectl delete jobs --all` 立刻删除它们。 - - - -## Cron Job 限制 - -Cron Job 在每次调度运行时间内 _大概_ 会创建一个 Job 对象。我们之所以说 _大概_ ,是因为在特定的环境下可能会创建两个 Job,或者一个 Job 都没创建。我们尝试少发生这种情况,但却不能完全避免。因此,创建 Job 操作应该是 _幂等的_。 - -Job 根据它所创建的 Pod 的并行度,负责重试创建 Pod,并就决定这一组 Pod 的成功或失败。Cron Job 根本不会去检查 Pod。 - - - -## 编写 Cron Job 规约 - -和其它 Kubernetes 配置一样,Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。 -关于如何实现一个配置文件的更新信息,参考文档 [部署应用](/docs/user-guide/deploying-applications)、 -[配置容器](/docs/user-guide/configuring-containers) 和 -[使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。 - -Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)。 - -**注意:** 对一个 Cron Job 的所有修改,尤其是对其 `.spec` 的修改,仅会在下一次运行的时候生效。 - - -### 调度 - - `.spec.schedule` 是 `.spec` 中必需的字段,它的值是 [Cron](https://en.wikipedia.org/wiki/Cron) 格式字的符串,例如:`0 * * * *`,或者 `@hourly`,根据指定的调度时间 Job 会被创建和执行。 - - - -### Job 模板 - -`.spec.jobTemplate` 是另一个 `.spec` 中必需的字段。它是 Job 的模板。 -除了它可以是嵌套的,并且不具有 `apiVersion` 或 `kind` 字段之外,它和 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 一样具有完全相同的模式(schema)。 -参考 [编写 Job 规格](/docs/concepts/jobs/run-to-completion-finite-workloads/#writing-a-job-spec)。 - - - -### 启动 Job 的期限(秒级别) - -`.spec.startingDeadlineSeconds` 字段是可选的。它表示启动 Job 的期限(秒级别),如果因为任何原因而错过了被调度的时间,那么错过执行时间的 Job 将被认为是失败的。如果没有指定,则没有期限。 - - - -### 并发策略 - -`.spec.concurrencyPolicy` 字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种: - -* `Allow`(默认):允许并发运行 Job -* `Forbid`:禁止并发运行,如果前一个还没有完成,则直接跳过下一个 -* `Replace`:取消当前正在运行的 Job,用一个新的来替换 - -注意,当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job,它们创建的 Job 之间总是允许并发运行。 - - - -### 挂起 - -`.spec.suspend` 字段也是可选的。如果设置为 `true`,后续所有执行都将被挂起。它对已经开始执行的 Job 不起作用。默认值为 `false`。 - - - -### Job 历史限制 - -`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 这两个字段是可选的。它们指定了可以保留完成和失败 Job 数量的限制。 - -默认没有限制,所有成功和失败的 Job 都会被保留。然而,当运行一个 Cron Job 时,很快就会堆积很多 Job,推荐设置这两个字段的值。设置限制值为 `0`,相关类型的 Job 完成后将不会被保留。 +{{% /capture %}} diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index f2662bd0d3..7468ae1b57 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -22,7 +22,7 @@ redirect_from: - 运行集群存储 daemon,例如在每个节点上运行 `glusterd`、`ceph`。 - 在每个节点上运行日志收集 daemon,例如`fluentd`、`logstash`。 -- 在每个节点上运行监控 daemon,例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理,或 Ganglia `gmond`。 +- 在每个节点上运行监控 daemon,例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理, Ganglia `gmond`, 或 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。 一个简单的用法是在所有的节点上都启动一个 DaemonSet,将被作为每种类型的 daemon 使用。 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet,但具有不同的标志,和/或对不同硬件类型具有不同的内存、CPU要求。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..8fc47968cb --- /dev/null +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,416 @@ +--- +reviewers: +- Kashomon +- bprashanth +- madhusudancs +title: ReplicaSet +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + + + +ReplicaSet 是下一代的 Replication Controller。 _ReplicaSet_ 和 [_Replication Controller_](/docs/concepts/workloads/controllers/replicationcontroller/) 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求,这在[标签用户指南](/docs/concepts/overview/working-with-objects/labels/#label-selectors)中有描述。而 Replication Controller 仅支持基于相等选择器的需求。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 怎样使用 ReplicaSet + +大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的,而 Deployment 是声明性的,因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。 + +虽然 ReplicaSets 可以独立使用,但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。 +当您使用 Deployment 时,您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。 + + + +## 什么时候使用 ReplicaSet + +ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 +然而,Deployment 是一个更高级的概念,它管理 ReplicaSet,并向 Pod 提供声明式的更新以及许多其他有用的功能。 +因此,我们建议使用 Deployment 而不是直接使用 ReplicaSet,除非您需要自定义更新业务流程或根本不需要更新。 + +这实际上意味着,您可能永远不需要操作 ReplicaSet 对象:而是使用 Deployment,并在 spec 部分定义您的应用。 + + +## 示例 + +{{< codenew file="controllers/frontend.yaml" >}} + + + +将此清单保存到 `frontend.yaml` 中,并将其提交到 Kubernetes 集群,应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 + +```shell +$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml +replicaset.apps/frontend created +$ kubectl describe rs/frontend +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +$ kubectl get pods +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + + + +## 编写 ReplicaSet Spec + +与所有其他 Kubernetes API 对象一样,ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息,请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。 + +ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。 + + + +### Pod 模版 + +`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/) 的语法几乎完全一样,除了它是嵌套的并没有 `apiVersion` 和 `kind`。 + +除了所需的 Pod 字段之外,ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。 + +对于标签,请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。 + +对于 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy),`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`,这也是默认值. + +对于本地容器重新启动,ReplicaSet 委托给了节点上的代理去执行,例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。 + + + +### Pod 选择器 + +`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。 + +`.spec.template.metadata.labels` 必须匹配 `.spec.selector`,否则它将被 API 拒绝。 + +Kubernetes 1.9 版本中,API 版本 `apps/v1` 中的 ReplicaSet 类型的版本是当前版本并默认开启。API 版本 `apps/v1beta2` 被弃用。 + + + +另外,通常您不应该创建标签与此选择器匹配的任何 Pod,或者直接与另一个 ReplicaSet 或另一个控制器(如 Deployment)标签匹配的任何 Pod。 +如果你这样做,ReplicaSet 会认为它创造了其他 Pod。Kubernetes 并不会阻止您这样做。 + +如果您最终使用了多个具有重叠选择器的控制器,则必须自己负责删除。 + + + +### Replicas + +通过设置 `.spec.replicas` 您可以指定要同时运行多少个 Pod。 +在任何时间运行的 Pod 数量可能高于或低于 `.spec.replicas` 指定的数量,例如在副本刚刚被增加或减少后、或者 Pod 正在被优雅地关闭、以及替换提前开始。 + +如果您没有指定 `.spec.replicas`, 那么默认值为 1。 + + + +## 使用 ReplicaSets 的具体方法 + +### 删除 ReplicaSet 和它的 Pod + +要删除 ReplicaSet 和它的所有 Pod,使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。 +默认情况下,[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。 + +当使用 REST API 或 `client-go` 库时,您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如: + +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + + + +### 只删除 ReplicaSet + +您可以只删除 ReplicaSet 而不影响它的 Pod,方法是使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令并设置 `--cascade=false` 选项。 + +当使用 REST API 或 `client-go` 库时,您必须将 `propagationPolicy` 设置为 `Orphan`。例如: + +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + + + +一旦删除了原来的 ReplicaSet,就可以创建一个新的来替换它。 +由于新旧 ReplicaSet 的 `.spec.selector` 是相同的,新的 ReplicaSet 将接管老的 Pod。 +但是,它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。 +若想要以可控的方式将 Pod 更新到新的 spec,就要使用 [滚动更新](#rolling-updates)的方式。 + + + + +### 将 Pod 从 ReplicaSet 中隔离 + +可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。这种技术可以用来从服务中去除 Pod,以便进行排错、数据恢复等。 +以这种方式移除的 Pod 将被自动替换(假设副本的数量没有改变)。 + + + +### 缩放 RepliaSet + +通过更新 `.spec.replicas` 字段,ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。 + + + +### ReplicaSet 作为水平的 Pod 自动缩放器目标 + +ReplicaSet 也可以作为 [水平的 Pod 缩放器 (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/) 的目标。也就是说,ReplicaSet 可以被 HPA 自动缩放。 +以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。 + + +{{< codenew file="controllers/hpa-rs.yaml" >}} + + + +将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群,就能创建它所定义的 HPA,进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。 + +```shell +kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + + + +或者,可以使用 `kubectl autoscale` 命令完成相同的操作。 +(而且它更简单!) + +```shell +kubectl autoscale rs frontend +``` + + + +## ReplicaSet 的替代方案 + +### Deployment (推荐) + +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象,它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。 +如果您需要滚动更新功能,建议使用 Deployment,因为 Deployment 与 `kubectl rolling-update` 不同的是:它是声明式的、服务器端的、并且具有其他特性。 +有关使用 Deployment 来运行无状态应用的更多信息,请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。 + + + +### 裸 Pod + +与用户直接创建 Pod 的情况不同,ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod,例如在节点故障或破坏性的节点维护(如内核升级)的情况下。 +因为这个好处,我们建议您使用 ReplicaSet,即使应用程序只需要一个 Pod。 +想像一下,ReplicaSet 类似于进程监视器,只不过它在多个节点上监视多个 Pod,而不是在单个节点上监视单个进程。 +ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理(例如,Kubelet 或 Docker)去完成。 + + + +### Job + +使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet,可以用于那些期望自行终止的 Pod。 + + + +### DaemonSet + +对于管理那些提供主机级别功能(如主机监控和主机日志)的容器,就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。 +这些 Pod 的寿命与主机寿命有关:这些 Pod 需要先于主机上的其他 Pod 运行,并且在机器准备重新启动/关闭时安全地终止。 + +{{% /capture %}} + diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md new file mode 100644 index 0000000000..3ecf219dc4 --- /dev/null +++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md @@ -0,0 +1,417 @@ +--- +reviewers: +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +- smarterclayton +title: StatefulSets +content_template: templates/concept +weight: 40 +--- + + + +{{% capture overview %}} + + + +StatefulSet 是用来管理有状态应用的工作负载 API 对象。 + +{{< note >}} + +**注意:** StatefulSets 是在 1.9 版本中正式发布的。 +{{< /note >}} + +{{< glossary_definition term_id="statefulset" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + + + +## 使用 StatefulSets + +StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值: + +* 稳定的、唯一的网络标识符。 +* 稳定的、持久的存储。 +* 有序的、优雅的部署和缩放。 +* 有序的、自动的滚动更新。 + +在上面,稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩,则应该使用一组无状态的副本控制器来部署应用程序,比如 [Deployment](/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态需要。 + + + +## 限制 + +* StatefulSet 在 1.9 版本之前属于 beta 资源,在 1.5 版本之前的任何 Kubernetes 版本中都不可用。 +* 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供,或者由管理员预先提供。 +* 删除和/或收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全,它通常比自动清除 StatefulSet 所有相关的资源更有价值。 +* StatefulSet 当前需要 [无头服务](/docs/concepts/services-networking/service/#headless-services) 来负责Pod 的网络标识。您需要负责创建此服务。 +* 当删除 StatefulSets 时,StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止,可以在删除之前将 StatefulSet 缩放为0。 + + + +## 组件 +下面的示例演示了 StatefulSet 的组件。 + +* 名为 nginx 的无头服务用来控制网络域。 +* 名为 web 的 StatefulSet 有一个Spec,它表明将在单个 Pod 中启动 nginx 容器的3个副本。 +* volumeClaimTemplates 将通过 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 驱动提供的 PersistentVolume 来提供稳定的存储。 + + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + selector: + matchLabels: + app: nginx # has to match .spec.template.metadata.labels + serviceName: "nginx" + replicas: 3 # by default is 1 + template: + metadata: + labels: + app: nginx # has to match .spec.selector.matchLabels + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "my-storage-class" + resources: + requests: + storage: 1Gi +``` + + + +## Pod 选择器 +您必须设置 StatefulSet 的 `.spec.selector` 字段来匹配它的`.spec.template.metadata.labels`标签。在 Kubernetes 1.8 版本之前,忽略`.spec.selector` 字段会提供默认设置。在 1.8 和以后的版本中,指定的 Pod 选择器匹配失败将在创建 StatefulSet 期间导致验证错误。 + + + +## Pod 的身份 + +StatefulSet Pod 具有唯一的标识,该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的,不管它被调度在哪个节点上。 + + + +### 序号索引 + +对于具有N个副本的 StatefulSet,StatefulSet 中的每个 Pod 将被分配一个整数序号,从 0 到 N-1,该序号在 StatefulSet 上是唯一的。 + + + +### 稳定的网络 ID + +StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为 `$(statefulset name)-$(ordinal)`。上例将会创建三个名称为 `web-0,web-1,web-2` 的三个 Pod。 +StatefulSet 可以使用 [无头服务](/docs/concepts/services-networking/service/#headless-services) 控制它的 Pod 的网络域。管理域的这个服务的格式为: +`$(service name).$(namespace).svc.cluster.local`, 其中 "cluster.local" 是集群域。 + 一旦每个 Pod 创建成功,就会得到一个匹配的 DNS 子域,格式为:`$(podname).$(governing service domain)`,其中管理服务由 StatefulSet 的 `serviceName` 域来定义。 + + + + +下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例: + +Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname | +-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | + +{{< note >}} + +**注意** 集群域会被设置为 `cluster.local` 除非有[其他配置](/docs/concepts/services-networking/dns-pod-service/#how-it-works)。 +{{< /note >}} + + + +### 稳定的存储 + +Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/docs/concepts/storage/persistent-volumes/)。在上面的 nginx 示例中,每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass,就会使用默认的 StorageClass。当一个 Pod 被安排到节点上时,它的 `volumeMounts` 挂载了与其 PersistentVolumeClaims 相关联的 PersistentVolume。请注意,当 Pod 或者 StatefulSet 被删除时,与PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。 + + + + +### Pod 名称标签 + +当 StatefulSet 创建 Pod 时,它会添加一个标签 `statefulset.kubernetes.io/pod-name`,该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。 + + + +## 部署和伸缩保证 + +* 对于包含 N 个 副本的 StatefulSet,当部署 Pod 时,它们是依次创建的,顺序为 {0..N-1}。 +* 当删除 Pod 时,它们是逆序终止的,顺序为 {N-1..0}。 +* 在将缩放操作应用到 Pod 之前,它前面的所有 Pod 必须是 Running 和 Ready 状态。 +* 在 Pod 终止之前,所有的继任者必须完全关闭。 + + + +StatefulSet 不应该声明 `pod.Spec.TerminationGracePeriodSeconds` 为 0。这种做法是不安全的,要强烈阻止。更多的解释请参考 [强制删除 StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)。 + + + +在上面的 nginx 示例被创建后,会按照 web-0、web-1、web-2 的顺序部署三个 Pod。在 web-0 进入[Running 和 Ready](/docs/user-guide/pod-states/)状态前不会部署 web-1。在 web-1 进入Running 和 Ready 状态前不会部署 web-2。如果 web-1 已经处于 Running 和 Ready 状态,而 web-2 尚未部署,在此期间发生了 web-0 运行失败,那么 web-2 将不会被部署,要等到 web-0 部署完成并进入 Running 和 Ready 状态后,才会部署 web-2。 + + + + 如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`,首先被终止的是 web-2。在 web-2 没有被完全停止和删除前,web-1 不会被终止。当 web-2 已被终止和删除、web-1尚未被终止,如果在此期间发生 web-0 运行失败,那么就不会终止 web-1,必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 + + + +### Pod 管理策略 +在 Kubernetes 1.7及以后的版本中,StatefulSet 允许您放松其排序保证,同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 + +#### 有序的 Pod 管理 + +`有序的` Pod 管理是 StatefulSet 的默认功能。它实现了 [上面](#deployment-and-scaling-guarantees)描述的行为。 + +#### 并行的 Pod 管理 + +`并行` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod,启动或者终止其他 Pod 前,无需等待 Pod 进入 Running 和 ready 或者完全停止状态。 + + + +## 更新策略 + +在 Kubernetes 1.7 及以后的版本中,StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求/限制、以及注解。 + + + + +### On Delete + +`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时,它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod,以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。 + + + + +### 滚动更新(Rolling Updates) + +`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明`.spec.updateStrategy`时,`RollingUpdate` 是默认配置。 +当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时,StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 +它将按照与 Pod 终止相同的顺序(从最大序号到最小序号)进行,每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready状态,然后再更新其前身。 + + + +#### 分区 + +通过声明 `.spec.updateStrategy.rollingUpdate.partition`的方式,`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区,当 StatefulSet 的`.spec.template` 被更新时,所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新,并且,即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`,对它的 `.spec.template` 的更新将不会传递到它的 Pod。 +在大多数情况下,您不需要使用分区,但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开,则这些分区会非常有用。 + + +{{% /capture %}} +{{% capture whatsnext %}} + + + +* 示例一: [部署有状态应用](/docs/tutorials/stateful-application/basic-stateful-set/)。 +* 示例二: [使用 StatefulSet 部署 Cassandra](/docs/tutorials/stateful-application/cassandra/)。 + + +{{% /capture %}} + diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index 3b714c7ff5..1c35becca5 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -1,12 +1,11 @@ +--- +title: "Pods" +weight: 10 +--- + - ---- -title: "Pods" -weight: 10 ---- - diff --git a/content/zh/docs/concepts/workloads/pods/pod-overview.md b/content/zh/docs/concepts/workloads/pods/pod-overview.md new file mode 100644 index 0000000000..d96799b121 --- /dev/null +++ b/content/zh/docs/concepts/workloads/pods/pod-overview.md @@ -0,0 +1,256 @@ +--- +reviewers: +- erictune +title: Pod 概览 +content_template: templates/concept +weight: 10 +--- + + + +{{% capture overview %}} + +本节提供了 `Pod` 的概览信息,`Pod` 是最小可部署的 Kubernetes 对象模型。 +{{% /capture %}} + + +{{% capture body %}} + + + +## 理解 Pod + +*Pod* 是 Kubernetes 的基本构建块,它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。 +Pod 表示集群上正在运行的进程。 + + + +Pod 封装了应用程序容器(或者在某些情况下封装多个容器)、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。 +Pod 表示部署单元:*Kubernetes 中应用程序的单个实例*,它可能由单个容器或少量紧密耦合并共享资源的容器组成。 + + +[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时,但 Pod 也能支持其他的容器运行时。 + +Kubernetes 集群中的 Pod 可被用于以下两个主要用途: + + + +* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例;在这种情况下,可以将 Pod 看作单个容器的包装器,并且 Kubernetes 直接管理 Pod,而不是容器。 +* **运行多个协同工作的容器的 Pod**。 +Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 +这些位于同一位置的容器可能形成单个内聚的服务单元——一个容器将文件从共享卷提供给公众,而另一个单独的“挂斗”容器则刷新或更新这些文件。 +Pod 将这些容器和存储资源打包为一个可管理的实体。 + + + +[Kubernetes 博客](http://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考: + +* [分布式系统工具包:复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) +* [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns) + + + +每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序(例如,运行多个实例),则应该使用多个 Pod,每个实例使用一个。 +在 Kubernetes 中,这通常被称为 _副本_。 +通常使用一个称为控制器的抽象来创建和管理一组被复制的 Pod。 +更多信息请参见 [POD 和控制器](#pods-and-controllers)。 + + + +### Pod 怎样管理多个容器 + +Pod 被设计成支持形成内聚服务单元的多个协作过程(作为容器)。 +Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上,并可以一起进行调度。 +容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。 + + + +注意,在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。 +只在容器紧密耦合的特定实例中使用此模式。 +例如,您可能有个充当共享卷中文件的 Web 服务器的容器,以及从远程源更新这些文件的单独的"挂斗"容器,如下图所示: + + +{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}} + + + +Pod 为其组成容器提供了两种共享资源:*网络* 和 *存储*。 + + + +#### 联网 + +每个 Pod 分配一个唯一的 IP 地址。 +Pod 中的每个容器共享网络命名空间,包括 IP 地址和网络端口。 +*Pod 内的容器* 可以使用 `localhost` 互相通信。 +当 Pod 中的容器与 *Pod 之外* 的实体通信时,它们必须协调如何使用共享的网络资源(例如端口)。 + + + +#### 存储 + +一个 Pod 可以指定一组共享存储 *卷*。 +Pod 中的所有容器都可以访问共享卷,允许这些容器共享数据。 +卷还允许 Pod 中的持久数据在重启 Pod 中的某个容器时存活。 +有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息,请参考 [卷](/docs/concepts/storage/volumes/)。 + + + +## 使用 Pod + +你很少在 Kubernetes 中直接创建单独的 Pod,甚至是单个存在的 Pod。 +这是因为 Pod 被设计成了相对短暂的一次性的实体。 +当 Pod 由您创建或者间接地由控制器创建时,它被调度在集群中的节点上运行。 +Pod 会保持在该节点上运行,直到进程被终止、Pod 对象被删除、Pod 因资源不足而被 *驱逐* 或者节点失效为止。 +{{< note >}} + +重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行,而是作为容器运行的环境,并且一直保持到被删除为止。 +{{< /note >}} + + + +Pod 本身并不能自愈。 +如果 Pod 被调度到失败的节点,或者如果调度操作本身失败,则删除该 Pod;同样,由于缺乏资源或进行节点维护,Pod 在被驱逐后将不再生存。 +Kubernetes 使用了一个更高级的称为 *控制器* 的抽象,由它处理相对可丢弃的 Pod 实例的管理工作。 +因此,虽然可以直接使用 Pod,但在 Kubernetes 中,更为常见的是使用控制器管理 Pod。 +有关 Kubernetes 如何使用控制器实现 Pod 伸缩和愈合的更多信息,请参考 [Pod 和控制器](#pods-and-controllers)。 + + + +### Pod 和控制器 + +控制器可以为您创建和管理多个 Pod,管理副本和上线,并在集群范围内提供自修复能力。 +例如,如果一个节点失败,控制器可以在不同的节点上调度一样的替身来自动替换 Pod。 + + + +包含一个或多个 Pod 的控制器一些示例包括: + +* [Deployment](/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) + +控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。 + + + +## Pod 模板 + +Pod 模板是包含在其他对象中的 Pod 规范,例如 +[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/)、和 +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。 +控制器使用 Pod 模板来制作实际使用的 Pod。 +下面的示例是一个简单的 Pod 清单,它包含一个打印消息的容器。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] +``` + + + +Pod 模板就像饼干切割器,而不是指定所有副本的当前期望状态。 +一旦饼干被切掉,饼干就与切割器没有关系。 +没有“量子纠缠”。 +随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。 +类似地,由副本控制器创建的 Pod 随后可以被直接更新。 +这与 Pod 形成有意的对比,Pod 指定了属于 Pod 的所有容器的当前期望状态。 +这种方法从根本上简化了系统语义,增加了原语的灵活性。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 进一步了解 Pod 的行为: + * [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods) + * 其他 Pod 话题 +{{% /capture %}} diff --git a/content/zh/docs/concepts/workloads/pods/pod.md b/content/zh/docs/concepts/workloads/pods/pod.md new file mode 100644 index 0000000000..3b35674cca --- /dev/null +++ b/content/zh/docs/concepts/workloads/pods/pod.md @@ -0,0 +1,399 @@ +--- +reviewers: +title: Pods +content_template: templates/concept +weight: 20 +--- + + + +{{% capture overview %}} + + + +_Pods_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## Pod 是什么? + +_pod_ (就像在鲸鱼荚或者豌豆荚中)是一组(一个或多个)容器(例如 Docker 容器),这些容器有共享存储、网络、以及怎样运行这些容器的声明。Pod 的内容总是共同定位和共同调度,并且在共享的上下文中运行。 +Pod 以特定于应用的“逻辑主机”为模型,它包含一个或多个应用容器,这些容器是相对紧密的耦合在一起;在容器出现之前,在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。 + + + +虽然 Kubernetes 支持多种容器运行时,但 Docker 是最常见的一种运行时,它有助于描述 Docker 术语中的 Pod。 + +Pod 的共享上下文是一组 Linux 命名空间、cgroups、以及其他潜在的资源隔离相关的因素,这些相同的东西也隔离了 Docker 容器。在 Pod 的上下文中,单个应用程序可能还会应用进一步的子隔离。 + + + +Pod 中的所有容器共享一个 IP 地址和端口空间,并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信(如 SystemV 信号量或 POSIX 共享内存)方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同,没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。 + +Pod 中的应用也能访问共享卷,共享卷是 Pod 定义的一部分,可被用来挂载到每个应用的文件系统上。 + + + +在 [Docker](https://www.docker.com/) 体系的术语中,Pod 被建模为一组具有共享命名空间和共享 [卷](/docs/concepts/storage/volumes/) 的 Docker 容器。 + +与单个应用程序容器一样,Pod被认为是相对短暂的(而不是持久的)实体。如 [Pod 的生命](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样:Pod 被创建、给它指定一个唯一 ID (UID)、被调度到节点、在节点上存续直到终止(取决于重启策略)或被删除。如果节点宕机,调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod (由 UID 定义)不会重新调度到新节点;相反,它会被一个完全相同的 Pod 替换掉,如果需要甚至连 Pod 名称都可以一样,除了 UID 是新的(更多信息请查阅 [副本控制器(replication +controller)](/docs/concepts/workloads/controllers/replicationcontroller/))。 + + + +当某些东西被说成与 Pod(如卷)具有相同的生存期时,这意味着只要pod(具有该UID)存在,它就存在。如果那个 Pod 因为某种原因被删除了,即使创建了相同的 Pod 做替换,Pod 的相关的资源(如卷等)也会被销毁进行重新创建。 + +{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}} + + + +包含多个容器的 Pod 包含文件拉取器和 web 服务器,使用了持久卷在容器之间进行存储共享。 + +{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}} + + + + +## Pod 的动机 + +### 管理 + +Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象,从而简化了应用的部署和管理。Pod 可以用作部署单元、水平缩放和复制。在 Pod中,多个容器的共同定位(协同调度)、共享命运(例如,终止)、协调复制、资源共享和依赖项管理都是自动处理的。 + + + + +### 资源共享和通信 + +Pod 使它的组成容器间能够进行数据共享和通信。 + +Pod 中的应用都使用相同的网络命名空间(相同 IP 和 端口空间),而且能够互相“发现”并使用 `localhost` 进行通信。因此,在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个IP地址,该空间能与整个网络上的其他物理机或虚拟机进行完全通信。 + + + +主机名被设置为 Pod 内的应用程序容器的 Pod 名称。请参考[组网的更多信息](/docs/concepts/cluster-administration/networking/)。 + +Pod 除了定义了 Pod 中运行的应用程序容器之外,Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留,并能在 Pod 内的应用程序之间共享。 + + + +## 使用 Pod + +Pod 可以用于托管垂直集成的应用程序栈(例如,LAMP),但最主要的动机是支持位于同一位置的、共同管理的帮助程序,例如: + +* 内容管理系统、文件和数据加载器、本地缓存管理器等。 +* 日志和检查点备份、压缩、旋转、快照等。 +* 数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。 +* 代理、桥接器和适配器 +* 控制器、管理器、配置器和更新器 + + + + +通常,单个 Pod 并不打算运行同一应用程序的多个实例。 + +更多解释,请参考 [分布式系统工具包:复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) + + + +## 备选方案的思考 + +_为什么不在单个(Docker)容器中运行多个程序?_ + +1. 透明度。Pod 内的容器对基础设施可见,使得基础设施能够向这些容器提供服务,例如流程管理和资源监控。这为用户提供了许多便利。 +1. 解耦软件依赖关系。可以独立地对单个容器进行版本控制、重新构建和重新部署。Kubernetes 有一天甚至可能支持单个容器的实时更新。 +1. 易用性。用户不需要运行他们自己的进程管理器、也不用担心信号和退出代码传播等。 +1. 效率。因为基础结构承担了更多的责任,所以容器可以变得更加轻量化。 + + + +_为什么不支持基于亲和性的容器联合调度?_ + +这种处理方法尽管可以提供同址,但不能提供 Pod 的大部分好处,如资源共享、IPC、有保证的命运共享和简化的管理。 + + + +## Pod 的持久性(或稀缺性) + +Pod 并没想被视为持久的实体。它们无法在调度失败、节点故障或其他驱逐策略(例如由于缺乏资源或在节点维护的情况下)中生存。 + +一般来说,用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建,即使对于单例的创建也一样使用控制器,例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。 +控制器提供集群范围的自修复以及复制和滚动管理。 +像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。 + + + +在集群调度系统中,使用 API 合集作为面向用户的主要原语是比较常见的,包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、和 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。 + + + +Pod 暴露为原语是为了便于: + +* 调度器和控制器可插拔性 +* 支持 Pod 级别的操作,而不需要通过控制器 API "代理" 它们 +* Pod 生命与控制器生命的解耦,如自举 +* 控制器和服务的解耦;端点控制器只监视 Pod +* Kubelet 级别的功能与集群级别功能的清晰组合;Kubelet 实际上是 "Pod 控制器" +* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod,例如在计划驱逐或镜像预先提取的情况下。 + + + +## Pod 的终止 + +因为 Pod 代表在集群中的节点上运行的进程,所以当不再需要这些进程时(与被 KILL 信号粗暴地杀死并且没有机会清理相比),允许这些进程优雅地终止是非常重要的。 +用户应该能够请求删除并且知道进程何时终止,但是也能够确保删除最终完成。当用户请求删除 Pod 时,系统会记录在允许强制删除 Pod 之前所期望的宽限期,并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期,KILL 信号就发送到这些进程,然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启,则终止操作将以完整的宽限期进行重试。 + + + + +流程示例: + +1. 用户发送命令删除 Pod,使用的是默认的宽限期(30秒) +2. API 服务器中的 Pod 会随着宽限期规定的时间进行更新,过了这个时间 Pod 就会被认为已 "死亡"。 +3. 当使用客户端命令查询 Pod 状态时,Pod 显示为 "Terminating"。 +4. (和第3步同步进行)当 Kubelet 看到 Pod 由于步骤2中设置的时间而被标记为 terminating 状态时,它就开始执行关闭 Pod 流程。 + 1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details),就在 Pod 内部调用它。如果宽限期结束了 `preStop` 钩子还在运行,那么就用小的(2秒)扩展宽限期调用步骤2。 + + 2. 给 Pod 内的进程发送 TERM 信号。 +5. (和第3步同步进行)从服务的端点列表中删除 Pod,Pod也不再被视为副本控制器的运行状态的 Pod 集的一部分。当负载平衡器(如服务代理)将 Pod 从轮换中移除时,关闭迟缓的 Pod 将不能继续为流量服务。 +6. 当宽限期结束后,Pod 中运行的任何进程都将被用 SIGKILL 杀死。 +7. Kubelet 将通过设置宽限期为0(立即删除)来完成删除 API 服务器上的 Pod。Pod 从 API 中消失,从客户端也不再可见。 + + + + +默认情况下,所有删除在30秒内都是优雅的。`kubectl delete` 命令支持 `--grace-period=` 选项,允许用户覆盖默认值并声明他们自己的宽限期。设置为 ‘0’ 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。在 kubectl 1.5以后的版本(含1.5版本)中,为了执行强制删除,您还必须为 `--grace-period=0` 声明一个额外的 `--force` 标志。 + + + +### Pod 的强制删除 + +强制删除pod定义为从集群状态和 etcd 中立即删除 Pod。当执行强制删除时,apiserver 并不会等待 kubelet 的确认信息,该 Pod 已在所运行的节点上被终止了。强制删除操作从 API 中立即清除了 Pod, 因此可以用相同的名称创建一个新的 Pod。在节点上,设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。 + +强制删除对某些 Pod 可能具有潜在危险,因此应该谨慎地执行。对于 StatefulSet 管理的 Pod,请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/)的任务文档。 + + + +## Pod 容器的特权模式 + +从 Kubernetes v1.1 开始,Pod 内的任何容器都可以开启特权模式,开启的方法是在容器声明中的 `SecurityContext` 域使用 `privileged` 标志。这对于希望使用linux功能(如操作网络堆栈和访问设备)的容器非常有用。容器内的进程获得的特权与容器外的进程几乎相同。使用特权模式,将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。 + +如果主节点的 Kubernetes 版本是 v1.1 或更高,而工作节点的版本低于 v1.1,新的特权 Pod 将被 API 服务器接受,但不会被启动。它们将处于 pending 状态。如果用户使用命令 `kubectl describe pod FooPodName`,就可以看到 Pod 处于 pending 状态的原因。`describe` 命令的输出事件列表将显示: +`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` + + + +如果主节点的版本低于 v1.1,那么特权 Pod 就不能被创建。如果用户尝试创建有特权容器的 Pod,将会得到下面的错误信息: +`The Pod "FooPodName" is invalid. +spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` + + + +## API 对象 + +Pod 是 Kubernetes REST API 中的顶级资源。关于该 API 对象的更详细信息请参考 [Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。 diff --git a/content/zh/docs/concepts/workloads/pods/podpreset.md b/content/zh/docs/concepts/workloads/pods/podpreset.md index 81b9f5d4db..23106c2d66 100644 --- a/content/zh/docs/concepts/workloads/pods/podpreset.md +++ b/content/zh/docs/concepts/workloads/pods/podpreset.md @@ -1,72 +1,151 @@ --- -approvers: +reviewers: - jessfraz title: Pod Preset content_template: templates/concept +weight: 50 --- {{% capture overview %}} -本文提供了 PodPreset 的概述。 在 pod 创建时,用户可以使用 `podpreset` 对象将特定信息注入 -pod 中,这些信息可以包括 secret、 卷、卷挂载和环境变量。 + +本文提供了 PodPreset 的概述。 在 Pod 创建时,用户可以使用 PodPreset 对象将特定信息注入 Pod 中,这些信息可以包括 secret、 卷、卷挂载和环境变量。 {{% /capture %}} -{{< toc >}} {{% capture body %}} + + + ## 理解 Pod Preset -`Pod Preset` 是一种 API 资源,在 pod 创建时,用户可以用它将额外的运行时需求信息注入 pod。 -使用[标签选择器(label selector)](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 pod。 +`Pod Preset` 是一种 API 资源,在 Pod 创建时,用户可以用它将额外的运行时需求信息注入 Pod。 +使用[标签选择器(label selector)](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 Pod。 -使用 Pod Preset 使得 pod 模板编写者不必显式地为每个 pod 设置信息。 -这样,使用特定服务的 pod 模板编写者不需要了解该服务的所有细节。 + + +使用 Pod Preset 使得 Pod 模板编写者不必显式地为每个 Pod 设置信息。 +这样,使用特定服务的 Pod 模板编写者不需要了解该服务的所有细节。 + + 了解更多的相关背景信息,请参考 [ PodPreset 设计提案](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)。 + + ## PodPreset 如何工作 Kubernetes 提供了准入控制器 (`PodPreset`),该控制器被启用时,会将 Pod Preset -应用于接收到的 pod 创建请求中。 -当出现 pod 创建请求时,系统会执行以下操作: +应用于接收到的 Pod 创建请求中。 +当出现 Pod 创建请求时,系统会执行以下操作: + + 1. 检索所有可用 `PodPresets` 。 -1. 检查 `PodPreset` 的标签选择器与要创建的 pod 的标签是否匹配。 -1. 尝试合并 `PodPreset` 中定义的各种资源,并注入要创建的 pod。 -1. 发生错误时抛出事件,该事件记录了 pod 信息合并错误,同时在 _不注入_ `PodPreset` 信息的情况下创建 pod。 -1. 为改动的 pod spec 添加注解,来表明它被 `PodPreset` 所修改。 注解形如: +1. 检查 `PodPreset` 的标签选择器与要创建的 Pod 的标签是否匹配。 +1. 尝试合并 `PodPreset` 中定义的各种资源,并注入要创建的 Pod。 +1. 发生错误时抛出事件,该事件记录了 pod 信息合并错误,同时在 _不注入_ `PodPreset` 信息的情况下创建 Pod。 +1. 为改动的 Pod spec 添加注解,来表明它被 `PodPreset` 所修改。 注解形如: `podpreset.admission.kubernetes.io/podpreset-": ""`。 + + 一个 Pod 可能不与任何 Pod Preset 匹配,也可能匹配多个 Pod Preset。 同时,一个 `PodPreset` 可能不应用于任何 Pod,也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时,Kubernetes 修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动, Kubernetes 修改 pod 中所有容器的规格,对于卷的改动,Kubernetes 修改 Pod spec。 + {{< note >}} -**注意:** Pod Preset 能够在适当的时候修改 Pod spec 的 `spec.containers` 字段, -但是不会应用于 `initContainers` 字段。 + + +Pod Preset 能够在适当的时候修改 Pod spec 的 `spec.containers` 字段,但是不会应用于 `initContainers` 字段。 {{< /note >}} + + ### 为特定 Pod 禁用 Pod Preset -在一些情况下,用户不希望 pod 被 pod preset 所改动,这时,用户可以在 pod spec 中添加形如 - `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。 +在一些情况下,用户不希望 Pod 被 Pod Preset 所改动,这时,用户可以在 Pod spec 中添加形如 `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。 + + ## 启用 Pod Preset 为了在集群中使用 Pod Preset,必须确保以下几点: -1. 已启用 api 类型 `settings.k8s.io/v1alpha1/podpreset`。 这可以通过在 API 服务器的 - `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。 -1. 已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--admission-control` - 配置项中包含 `PodPreset` 。 -1. 已经通过在相应的名字空间中创建 `PodPreset` 对象,定义了 Pod preset。 + + +1. 已启用 API 类型 `settings.k8s.io/v1alpha1/podpreset`。 这可以通过在 API 服务器的 `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。 +1. 已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--admission-control` 配置项中包含 `PodPreset` 。 +1. 已经通过在相应的命名空间中创建 `PodPreset` 对象,定义了 Pod Preset。 + {{% /capture %}} {{% capture whatsnext %}} - -* [使用 PodPreset 将信息注入 Pods](/docs/tasks/inject-data-application/podpreset/) - + +* [使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset/) {{% /capture %}} - - diff --git a/content/zh/docs/contribute/_index.md b/content/zh/docs/contribute/_index.md new file mode 100644 index 0000000000..a3ec22713b --- /dev/null +++ b/content/zh/docs/contribute/_index.md @@ -0,0 +1,173 @@ +--- +content_template: templates/concept +title: 为 Kubernetes 文档做贡献 +linktitle: 贡献 +main_menu: true +weight: 80 +--- + + + +{{% capture overview %}} + + + +如果你想帮助对 Kubernetes 文档或网站做出贡献,我们很高兴得到你的帮助! +任何人都可以做出贡献,无论你刚参与项目还是参与了很长时间,无论你是开发人员还是用户,或是无法忍受看到拼写错误的人。 + + + +更多途径参与 Kubernetes 社区或了解我们,请访问 [Kubernetes 社区网站](/community/)。 + + + +查找 [样式指南](/docs/contribute/style/style-guide/) 或者 [Kubernetes 社区网站](/community/)? + +{{% /capture %}} + +{{% capture body %}} + + + +## 贡献者类型 + + + +- [签署了 CLA](/docs/contribute/start#sign-the-cla)并为项目贡献了时间和精力的 Kubernetes 组织的_成员_。 + 参见 [社区成员](https://github.com/kubernetes/community/blob/master/community-membership.md) 中对于成员资格的具体标准。 + + + +- SIG Docs 的_评审者_是对评审文档 PR 感兴趣,并被 SIG Docs 审批者添加到 Github 群组并在 Github 仓库中 `OWNERS` 文件的 Kubernetes 组织的成员。 + + + +- SIG Docs 的_审批者_是对项目持续贡献,并被授予合并 PR 权限和代表 Kubernetes 组织发布内容的成员。 + 批准人也可以在更广泛的 Kubernetes 社区中代表 SIG Docs 团队。 + SIG Docs审批者的一些职责,如协调发布版本,需要大量的时间投入。 + + + +## 贡献途径 + + + +以下列表将工作分成了:任何人都可以做的工作、Kubernetes 组织成员可以做的工作,和熟悉 SIG Docs 流程并且有更高访问权限才能做的工作。 +持续的贡献可以帮助你理解已有的工具和组织决策。 + + + +你对 Kubernetes 文档可以做出的贡献不仅限于列表列出的条目,但它可以帮助你开动起来。 + + + +- [任何人](/docs/contribute/start/) + - 登记记录可修正的错误 + + + +- [成员](/docs/contribute/start/) + - 完善已有文档 + - 在 Slack 或 SIG Docs 邮件列表中提出改进意见 + - 提升文档的易用性 + - 对 PR 提出无约束的反馈 + - 编写博文和案例分析 + + + +- [评审者](/docs/contribute/intermediate/) + - 为新功能特性编写文档 + - 对 issue 进行筛选和分类 + - 评审 PR + - 创建图表、图形分析和嵌入式的屏幕/视频 + - 本地化 + - 作为 docs 小组的代表为其他项目仓库做贡献 + - 在代码中编辑面向用户的字符串 + - 改进代码注释和 Godoc + + + +- [审批者](/docs/contribute/advanced/) + - 通过批准和合并 PR 发布贡献成果 + - 作为 docs 团队的代表参与 Kubernetes 发布团队 + - 对样式指南提出改进建议 + - 对文档测试提出改进建议 + - 对 Kubernetes 网站或其他工具提出改进建议 + +{{% /capture %}} diff --git a/content/zh/docs/contribute/advanced.md b/content/zh/docs/contribute/advanced.md new file mode 100644 index 0000000000..7df7d280f3 --- /dev/null +++ b/content/zh/docs/contribute/advanced.md @@ -0,0 +1,232 @@ +--- +title: 高级贡献 +slug: advanced +content_template: templates/concept +weight: 30 +--- + + + +{{% capture overview %}} + + + +如果你已经阅读并掌握[开始贡献](/docs/contribute/start/)和[中级贡献](/docs/contribute/intermediate/),并准备了解更多贡献的途径,请阅读此文。 +您需要使用 Git 命令行工具和其他工具做这些工作。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 做一周的 PR 管理者 + + + +SIG Docs 的[审批者](/docs/contribute/participating/#approvers)可以成为 PR 管理者。 + + + +SIG Docs 的审批者会每周轮换地加入到 [PR 管理者轮换日程](https://github.com/kubernetes/website/wiki/PR-Wranglers)中。 +PR 管理者的工作职责包括: + + + +- 每天评审新增的 PR + - 指导新的贡献者签署 CLA,关闭两周都没有签署 CLA 的提交人的 PR。 + PR 提交人在签署 CLA 之后可以重启 PR,所以 PR 管理者需要保证这段时间内相关文件没有合入。 + - 对改进建议的更新提供反馈信息,包括促成其他 SIG 成员的技术性评审。 + - 合入符合要求的 PR,关闭不符合要求的 PR。 +- 每天筛选和标记新增的 issue。参见[中级贡献](/docs/contribute/intermediate/)中有关 SIG Docs 成员使用 metadata 的指南。 + + + +## 提出改进建议 + + + +SIG Docs 的[成员](/docs/contribute/participating/#members)可以提出改进建议。 + + + +在对 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` 聊天群组。 + + + +在进行了讨论并且 SIG 就期望的结果达成一致之后,你就能以最合理的方式处理改进建议了。例如,样式指南或网站功能的更新可能涉及 PR 的新增,而与文档测试相关的更改可能涉及 sig-testing。 + + + +## 为 Kubernetes 版本发布协调文档 + + + +SIG Docs 的[审批者](/docs/contribute/participating/#approvers)可以为 Kubernetes 版本发布协调文档。 + + + +每一个 Kubernetes 版本都是由参与 sig-release 的 SIG(特别兴趣小组)的一个团队协调的。指定版本的发布团队中还包括总体发布牵头人,以及来自 sig-pm、sig-testing 的代表等。了解更多关于 Kubernetes 版本发布的流程,请参考 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。 + + + +SIG Docs 团队的代表需要为一个指定的版本协调以下工作: + + + +- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备,那么该功能特性不允许进入发布版本。 + + + +- 定期参加 sig-release 会议并对文档状态进行更新。 + + + +- 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。 + + + +- 合入版本发布相关的 PR,并为对应发布版本维护 Git 特性分支。 + + + +- 指导那些想学习并有意愿担当该角色的 SIG Docs 贡献者。这就是我们常说的“实习”。 + + + +- 发布版本的制品发布时,相关的文档更新也需要发布。 + + + +协调一个版本发布通常需要 3-4 个月的时间投入,该任务由 SIG Docs 审批者轮流承担。 + + + +## 保荐新的贡献者 + + + +SIG Docs 的[评审者](/docs/contribute/participating/#reviewers)可以保荐新的贡献者。 + + + +新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后,就有资格申请 Kubernetes 组织[成员](/docs/contribute/participating#members)。贡献者的成员资格需要同时得到两位评审者的保荐。 + + + +新的文档贡献者可以通过咨询 [Kubernetes Slack instance](https://kubernetes.slack.com) 上的 #sig-docs 或 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 来请求评审者保荐。如果你对申请人的工作充满信心,你自愿保荐他们。当他们提交成员资格申请时,回复“+1”并详细说明为什么你认为申请人适合加入 Kubernetes 组织。 + +{{% /capture %}} + diff --git a/content/zh/docs/contribute/generate-ref-docs/_index.md b/content/zh/docs/contribute/generate-ref-docs/_index.md new file mode 100644 index 0000000000..ac5f61a40f --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/_index.md @@ -0,0 +1,21 @@ +--- +title: 参考文档概述 +main_menu: true +weight: 80 +--- + + + + + +许多 Kubernetes 参考文档都是使用脚本从 Kubernetes 源代码生成的。本节的主题是如何生成这种类型的文档。 diff --git a/content/zh/docs/contribute/generate-ref-docs/federation-api.md b/content/zh/docs/contribute/generate-ref-docs/federation-api.md new file mode 100644 index 0000000000..c4023ab8a4 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/federation-api.md @@ -0,0 +1,152 @@ +--- +title: 为 Kubernetes 联邦 API 生成参考文档 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本节介绍如何为 Kubernetes 联邦 API 自动生成参考文档。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + + + +* 你需要安装 [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 + + + +* 你需要安装 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install),并在环境变量中设置你的 `$GOPATH`。 + + + +* 你需要安装 [Docker](https://docs.docker.com/engine/installation/)。 + + + +* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说,这涉及到创建仓库的一个分支。想了解更多信息,请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/)。 + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 运行 update-federation-api-docs.sh 脚本 + + + +如果你还没有 Kubernetes 联邦的源码,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/federation +``` + + + +确定本地 [kubernetes/federation](https://github.com/kubernetes/federation) 仓库的主目录。 +例如,如果按照前面的步骤获取联邦的源码,则主目录是 `$GOPATH/src/github.com/kubernetes/federation`。 +下文将该目录称为 ``。 + + + +运行文档生成脚本: + +```shell +cd +hack/update-federation-api-reference-docs.sh +``` + + + +脚本运行 [k8s.gcr.io/gen-swagger-docs](https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/gen-swagger-docs?gcrImageListquery=%255B%255D&gcrImageListpage=%257B%2522t%2522%253A%2522%2522%252C%2522i%2522%253A0%257D&gcrImageListsize=50&gcrImageListsort=%255B%257B%2522p%2522%253A%2522uploaded%2522%252C%2522s%2522%253Afalse%257D%255D) 镜像来生成以下参考文档: + +* /docs/api-reference/extensions/v1beta1/operations.html +* /docs/api-reference/extensions/v1beta1/definitions.html +* /docs/api-reference/v1/operations.html +* /docs/api-reference/v1/definitions.html + + + +生成的文件不会被自动发布。你必须手工将它们复制到 [kubernetes/website](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/generated) 仓库。 + + + +以下文件发布在 [kubernetes.io/docs/reference](/docs/reference/): + +* [Federation API v1 Operations](/docs/reference/federation/v1/operations/) +* [Federation API v1 Definitions](/docs/reference/federation/v1/definitions/) +* [Federation API extensions/v1beta1 Operations](/docs/reference/federation/extensions/v1beta1/operations/) +* [Federation API extensions/v1beta1 Definitions](/docs/reference/federation/extensions/v1beta1/definitions/) + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) +* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) +* [为 Kubernetes 组件和工具生成参考页](/docs/home/contribute/generated-reference/kubernetes-components/) + +{{% /capture %}} diff --git a/content/zh/docs/contribute/generate-ref-docs/kubectl.md b/content/zh/docs/contribute/generate-ref-docs/kubectl.md new file mode 100644 index 0000000000..ae64df1dc2 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/kubectl.md @@ -0,0 +1,473 @@ +--- +title: 为 kubectl 命令集生成参考文档 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +该页面显示了如何自动生成 `kubectl` 工具提供的命令的参考页面。 + +{{< note >}} + + +本主题展示了如何为 [kubectl 命令集](/docs/reference/generated/kubectl/kubectl-commands) 生成参考文档,如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 + + + +本主题没有展示如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件的参考页面。相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。 +{{< /note >}} + +{{% /capture %}} + + +{{% capture prerequisites %}} + + + +* 你需要安装 [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 + + + +* 你需要安装 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install), 并在环境变量中设置 `$GOPATH`。 + + + +* 你需要安装 [Docker](https://docs.docker.com/engine/installation/)。 + + + +* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说,这涉及到创建仓库的一个分支。想了解更多信息,请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/) 和 [GitHub 标准 Fork&PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 下载三个仓库 + + + +如果你还没有下载过 kubernetes/kubernetes 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/kubernetes +``` + + + +确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 ``。 + + + +如果你还没有下载过 kubernetes/website 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/website +``` + + + +确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 ``。 + + + +如果你还没有下载过 kubernetes-incubator/reference-docs 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes-incubator/reference-docs +``` + + + +确定 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。下文将该目录称为 ``。 + + + +进入 kubernetes/kubernetes 仓库的本地目录,检出感兴趣的分支,并确保它是最新的。例如,如果希望为 Kubernetes 1.9 生成文档,可以使用以下命令: + +```shell +cd +git checkout release-1.9 +git pull https://github.com/kubernetes/kubernetes release-1.9 +``` + + + +## 编辑 kubectl 源码 + + + +kubectl 命令集的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档,可以从修改 kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改,然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 + + + +[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl 源码中的笔误进行修复的 PR 示例。 + + + +跟踪你的 PR,并回应评审人的评论。继续跟踪你的 PR,直到它合入到 kubernetes/kubernetes 仓库的 master 分支中。 + + + +## 以 cherry-pick 方式将你的修改合入已发布分支 + + + +你的修改已合入 master 分支中,该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中,则需要提议将它们以 cherry-pick 方式合入已发布分支。 + + + +例如,假设 master 分支正用于开发 Kubernetes 1.10 版本,而你希望将修改合入到已发布的 1.9 版本分支。相关的操作指南,请参见 [提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。 + + + +跟踪你的 cherry-pick PR,直到它合入到已发布分支中。 + +{{< note >}} + + +提议一个 cherry-pick 合入,需要你有在 PR 中设置标签和里程碑的权限。如果你没有,你需要与有权限为你设置标签和里程碑的人合作完成。 +{{< /note >}} + + + +## 编辑 Makefile + + + +进入 `` 目录, 打开 `Makefile` 进行编辑: + + + +将 `K8SROOT` 设置为 kubernetes/kubernetes 仓库的本地主目录。将 `WEBROOT` 设置为 kubernetes/website 仓库的本地主目录。将 `MINOR_VERSION` 设置为要构建的文档的副版本号。例如,如果要为 Kubernetes 1.9 版本构建文档,请将 `MINOR_VERSION` 设置为 9。保存并关闭 `Makefile`。 + + + +## 制作 brodocs 镜像 + + + +文档生成代码需要 `pwittrock/brodocs` Docker 镜像。 + + + +该命令用于创建 `pwittrock/brodocs` Docker 镜像。它还尝试将镜像推送到 DockerHub,但是如果该步骤失败也没关系。只要镜像在本地,就可以成功生成代码。 + + +```shell +make brodocs +``` + + + +确认 brodocs 镜像是否存在: + +```shell +docker images +``` + + + +输出显示 `pwittrock/brodocs` 是可用镜像之一: + +```shell +REPOSITORY TAG IMAGE ID CREATED SIZE +pwittrock/brodocs latest 999d34a50d56 5 weeks ago 714MB +``` + + + +## 创建版本目录 + + + +在 `gen-kubectldocs/generators` 目录中,如果你还没有一个名为 `v1_MINOR_VERSION` 的目录,那么现在通过复制前一版本的目录来创建一个。例如,假设你想要为 Kubernetes 1.9 版本生成文档,但是还没有 `v1_9` 目录,这时可以通过运行以下命令来创建并填充 `v1_9` 目录: + +```shell +mkdir gen-kubectldocs/generators/v1_9 +cp -r gen-kubectldocs/generators/v1_8/* gen-kubectldocs/generators/v1_9 +``` + + + +## 从 kubernetes/kubernetes 检出一个分支 + + + +在本地 kubernetes/kubernetes 仓库中,检出你想要生成文档的、包含 Kubernetes 版本的分支。例如,如果希望为 Kubernetes 1.9 版本生成文档,请检出 1.9 分支。确保本地分支是最新的。 + + + +## 运行文档生成代码 + + + +在 kubernetes-incubator/reference-docs 仓库的本地目录中,构建并运行文档生成代码。你可能需要以 root 用户运行命令: + +```shell +cd +make cli +``` + + + +## 找到生成的文件 + + + +这两个文件是成功构建的主要产物。验证它们是否存在: + +* `/gen-kubectldocs/generators/build/index.html` +* `/gen-kubectldocs/generators/build/navData.js` + + + +## 将文件复制到 kubernetes/website 仓库 + + + +将生成的文件从 kubernetes-incubator/reference-docs 仓库的本地目录复制到 kubernetes/website 仓库的本地目录。 + +```shell +cd +make copycli +``` + + + +## 在 kubernetes/website 中添加和提交修改 + + + +列出生成并准备合入到 `kubernetes/website` 仓库中的文件: + +``` +cd +git status +``` + + + +输出展示了新增和修改的文件。例如,输出可能如下所示: + +```shell +modified: docs/reference/generated/kubectl/kubectl-commands.html +modified: docs/reference/generated/kubectl/navData.js +``` + + + +运行 `git add` 和 `git commit` 将提交上述文件。 + + + +## 创建 PR + + + +对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR,并根据需要回应评审人的评论。继续跟踪你的 PR,直到它被合入。 + + + +在 PR 合入的几分钟后,你更新的参考主题将出现在[已发布文档](/docs/home/)中。 + + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) +* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) +* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) + +{{% /capture %}} + + + diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md new file mode 100644 index 0000000000..ccacc307d1 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -0,0 +1,685 @@ +--- +title: 为 Kubernetes API 生成参考文档 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本页面展示了如何为 Kubernetes API 更新自动生成的参考文档。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + + + +你需要安装以下软件: + + + +* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) +* 1.9 或更高版本的 [Golang](https://golang.org/doc/install) +* [Docker](https://docs.docker.com/engine/installation/) +* [etcd](https://github.com/coreos/etcd/) + + + +在环境变量中设置 $GOPATH,并且 etcd 的路径必须配置在 $PATH 环境变量中。 + + + +你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说,这涉及到创建仓库的一个分支。想了解更多信息,请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/) 和 [GitHub 标准 Fork&PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 概述 + + + +更新 Kubernetes API 参考文档有两个步骤: + + + +1. 从 kubernetes 源码生成 OpenAPI 规范。本步骤的工具在 [kubernetes/kubernetes/hack](https://github.com/kubernetes/kubernetes/tree/master/hack)。 + + + +1. 从 OpenAPI 规范生成 HTML 文件。本步骤的工具在 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs)。 + + + +## 下载三个仓库 + + + +If you don't already have the kubernetes/kubernetes repository, get it now: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/kubernetes +``` + + + +确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 ``。 + + + +如果你还没有下载过 `kubernetes/website` 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/website +``` + + + +确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 ``。 + + + +如果你还没有下载过 kubernetes-incubator/reference-docs 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes-incubator/reference-docs +``` + + + +确定 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。下文将该目录称为 ``。 + + + +## 编辑 Kubernetes 源码 + + + +Kubernetes API 参考文档是基于 OpenAPI 规范自动生成的,而该规范是从 Kubernetes 源码生成的。如果想要修改参考文档,可以从修改 Kubernetes 源码中的一个或多个注释开始。 + + + +### 修改源码中的注释 + +{{< note >}} + + +以下步骤是一个示例,而不是通用步骤。在你操作过程中,细节会有所不同。 +{{< /note >}} + + + +下面是在 Kubernetes 源码中编辑注释的示例。 + + + +进入 kubernetes/kubernetes 仓库的本地目录,检出 master 分支,并确保它是最新的: + +```shell +cd +git checkout master +git pull https://github.com/kubernetes/kubernetes master +``` + + + +假设 master 分支中的这个源文件有一个拼写错误 "atmost": + +[kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go) + + + +在本地环境中,打开 `types.go` 文件,然后将 "atmost" 修改为 "at most"。 + + + +确认文件已修改: + +```shell +git status +``` + + + +输出展示了在 master 分支上,`types.go` 文件已被修改: + +```shell +On branch master +... + modified: staging/src/k8s.io/api/apps/v1/types.go +``` + + + +### 提交已编辑的文件 + + + +运行 `git add` 和 `git commit` 提交到目前为止所做的修改。在下一步中,你将进行第二次提交。将修改拆分为两个提交是很重要的。 + + + +### 生成 OpenAPI 规范和相关文件 + + + +进入 `` 目录运行以下脚本: + +```shell +hack/update-generated-swagger-docs.sh +hack/update-swagger-spec.sh +hack/update-openapi-spec.sh +hack/update-generated-protobuf.sh +hack/update-api-reference-docs.sh +``` + + + +运行 `git status` 查看生成的文件。 + +```shell +On branch master +... + modified: api/openapi-spec/swagger.json + modified: api/swagger-spec/apps_v1.json + modified: docs/api-reference/apps/v1/definitions.html + modified: staging/src/k8s.io/api/apps/v1/generated.proto + modified: staging/src/k8s.io/api/apps/v1/types.go + modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go +``` + + + +检查 `api/openapi-spec/swagger.json` 的内容确认拼写错误是否被修复。例如,你可以运行 `git diff -a api/openapi-spec/swagger.json`。这个步骤很重要,因为 `swagger.json` 是文档生成过程的第二个步骤的输入。 + + + +运行 `git add` 和 `git commit` 提交修改。现在你有两个提交:一个是已编辑的 `types.go` 文件,另一个是已生成的 OpenAPI 规范和相关文件。把这两个提交分开。也就是说,不要将它们合并提交。 + + + +将你的修改以 [pull request](https://help.github.com/articles/creating-a-pull-request/) 提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的 master 分支。跟踪你的 PR,并根据需要回应评审人的评论。继续跟踪你的 PR,直到它被合入。 + + + +[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是一个对 Kubernetes 源码中的拼写错误进行修复的 PR 示例。 + +{{< note >}} + + +定位要修改的具体源文件可能很困难。在前面的示例中,正确的源文件位于 `kubernetes/kubernetes` 仓库的 `staging` 目录下。但在你的情况下,`staging` 目录可能不是查找正确源的位置。有关指导,请查看 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) 仓库的 `README` 文件和相关仓库 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)。 +{{< /note >}} + + + +### 以 cherry-pick 方式将你的提交合入已发布分支 + + + +在上文中,你在 master 分支中编辑了一个文件,然后运行脚本来生成 OpenAPI 规范和相关文件。然后你在一个 PR 中向 kubernetes/kubernetes 仓库的 master 分支提交了修改。现在假设你想要将你的修改合入到一个发布分支中。例如,假设 master 分支用于开发 Kubernetes 1.10 版本,而你希望将你的修改合入到 release-1.9 分支中。 + + + +回想一下 PR 中有两个提交:一个用于编辑 `types.go`,另一个用于脚本生成的文件。下一步是对你在 release-1.9 分支的第一次提交提议一个 cherry-pick 合入。其目的是挑出对 `types.go` 的编辑的那次提交,而不是对运行脚本结果的提交。有关说明,请参见[提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。 + +{{< note >}} + + +提议一个 cherry-pick 合入,需要你有在 PR 中设置标签和里程碑的权限。如果你没有,你需要与有权限为你设置标签和里程碑的人合作完成。 +{{< /note >}} + + + +当你有一个对 release-1.9 分支进行 cherry-pick 合入的 PR 时,下一步是在 release-1.9 分支的本地环境中运行这些脚本。 + +```shell +hack/update-generated-swagger-docs.sh +hack/update-swagger-spec.sh +hack/update-openapi-spec.sh +hack/update-generated-protobuf.sh +hack/update-api-reference-docs.sh +``` + + + +现在向 cherry pick 的 PR 添加一个提交,该 PR 包含最近生成的 OpenAPI 规范和相关文件。跟踪你的 PR,直到它合入到 release-1.9 分支中。 + + + +此时,master 和 release-1.9 分支都更新了 `types.go` 文件和一组生成的文件,这些反映了你对 `types.go` 做的修改。注意,在 release-1.9 分支中生成的 OpenAPI 规范和其他文件不一定与在 master 分支中生成的文件相同。在 release-1.9 分支中生成的文件只包含 Kubernetes 1.9 版本的 API 元素。master 分支中生成的文件可能包含正在 1.10 版本中开发的 API 元素,而这些元素却不在 1.9 版本中。 + + + +## 生成已发布的参考文档 + + + +前一章节展示了如何编辑源文件,然后生成几个文件,包括 `kubernetes/kubernetes` 仓库中的 `api/openapi-spec/swagger.json`。 + + + +本章节介绍如何生成[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/),该文档由 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 中的工具生成。这些工具以 `api/openapi-spec/swagger.json` 文件作为输入。 + + + +### 在 kubernetes-incubator/reference-docs 仓库中编辑 Makefile 文件 + + + +进入 `` 目录, 打开 `Makefile` 进行编辑: + + + +将 `K8SROOT` 设置为 kubernetes/kubernetes 仓库的本地主目录。将 `WEBROOT` 设置为 kubernetes/website 仓库的本地主目录。将 `MINOR_VERSION` 设置为要构建的文档的副版本号。例如,如果要为 Kubernetes 1.9 版本构建文档,请将 `MINOR_VERSION` 设置为 9。保存并关闭 `Makefile`。 + + + +### 复制 OpenAPI 规范 + + + +文档生成代码需要 Kubernetes API 的 OpenAPI 规范的本地副本。进入 `` 目录,检出有你想要使用的 OpenAPI 规范的分支。例如,如果要为 Kubernetes 1.9 版本生成文档,请检出 release-1.9 分支。 + + + +返回 `` 目录。输入以下命令将 OpenAPI 规范从 `kubernetes/kubernetes` 仓库复制到本地目录: + +```shell +make updateapispec +``` + + + +输出显示文件已被复制: + +```shell +cp ~/src/github.com/kubernetes/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json +``` + + + +### 制作 brodocs 镜像 + + + +文档生成代码需要 [pwittrock/brodocs](https://github.com/pwittrock/brodocs) Docker 镜像。 + + + +该命令用于创建 `pwittrock/brodocs` Docker 镜像。它还尝试将镜像推送到 DockerHub,但是如果该步骤失败也没关系。只要镜像在本地,就可以成功生成代码。 + +```shell +make brodocs +``` + + + +确认 brodocs 镜像是否存在: + +```shell +docker images +``` + + + +输出显示 `pwittrock/brodocs` 是可用镜像之一: + +```shell +REPOSITORY TAG IMAGE ID CREATED SIZE +pwittrock/brodocs latest 999d34a50d56 5 weeks ago 714MB +``` + + + +## 运行文档生成代码 + + + +构建并运行文档生成代码。你可能需要以 root 用户运行命令: + +```shell +cd +make api +``` + + + +### 找到生成的文件 + + + +这两个文件是成功构建的产物。验证它们是否存在: + +* `/gen-apidocs/generators/build/index.html` +* `/gen-apidocs/generators/build/navData.js` + + + +## 将生成的文档复制到 kubernetes/website 仓库 + + + +前面的章节展示了如何编辑 Kubernetes 源文件,生成 OpenAPI 规范,然后生成用于发布的参考文档。 + + + +本章节介绍如何将生成的文档复制到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。`kubernetes/website` 仓库中的文件发布在 [kubernetes.io](https://kubernetes.io) 网站上。特别是,生成的 `index.html` 文件发布在[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 + + + +输入以下命令将生成的文件复制到 kubernetes/website 仓库的本地目录: + +```shell +make copyapi +``` + + + +进入 kubernetes/kubernetes 仓库的本地主目录,查看哪些文件已被修改: + +```shell +cd +git status +``` + + + +输出显示修改后的文件: + +```shell +On branch master +... + modified: docs/reference/generated/kubernetes-api/v1.9/index.html +``` + + + +在本例中,只修改了一个文件。回想一下,你生成了 `index.html` 和 `navData.js`。但显然生成的 `navata.js` 与 kubernetes/website` 仓库中已有的 `navData.js` 没有什么不同。 + + + +在 `` 目录下运行 `git add` 和 `git commit` 将提交修改。 + + + +将你的修改作为 [pull request](/docs/home/contribute/create-pull-request/) 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。跟踪你的 PR,并根据需要回应评审人的评论。继续跟踪你的 PR,直到它被合入。 + + + +在 PR 合入的几分钟后,你的修改将出现在[已发布的参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) +* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) +* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) + +{{% /capture %}} + + + diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md new file mode 100644 index 0000000000..8df429632c --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -0,0 +1,412 @@ +--- +title: 为 Kubernetes 组件和工具生成参考页面 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本页面展示了如何使用 `update-imported-docs` 工具来为 [Kubernetes](https://github.com/kubernetes/kubernetes) 和 [Federation](https://github.com/kubernetes/federation) 仓库中的工具和组件生成参考文档。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +* 你需要一个运行着 Linux 或 macOS 操作系统的机器。 + + + +* 你需要安装以下软件: + + * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + + * 1.9或更高版本的 [Golang](https://golang.org/doc/install) + + * [make](https://www.gnu.org/software/make/) + + * [gcc compiler/linker](https://gcc.gnu.org/) + + + +* 在环境变量中设置 `$GOPATH`。 + + + +* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说,这涉及到创建仓库的一个分支。想了解更多信息,请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/)。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 下载两个仓库 + + + +如果你还没有下载过 `kubernetes/website` 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/website +``` + + + +确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 ``。 + + + +如果你想对参考文档进行修改,但是你还没下载过 `kubernetes/kubernetes` 仓库,现在下载: + +```shell +mkdir $GOPATH/src +cd $GOPATH/src +go get github.com/kubernetes/kubernetes +``` + + + +确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如,如果按照前面的步骤来获取该仓库,则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 ``。 + +{{< note >}} + + +如果你只想生成参考文档,而不需要修改,则不需要手动下载 `kubernetes/kubernetes` 仓库。当你运行 `update-imported-docs` 工具时,它会自动克隆 `kubernetes/kubernetes` 仓库。 +{{< /note >}} + + + +## 编辑 Kubernetes 源码 + + + +Kubernetes 组件和工具的参考文档是基于 Kubernetes 源码自动生成的。如果想要修改参考文档,可以从修改 Kubernetes 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改,然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 + + + +[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942) 是一个对 Kubernetes 源码中的注释进行修改的 PR 示例。 + + + +跟踪你的 PR,并回应评审人的评论。继续跟踪你的 PR,直到它合入到 `kubernetes/kubernetes` 仓库的 master 分支中。 + + + +## 以 cherry-pick 方式将你的修改合入已发布分支 + + + +你的修改已合入 master 分支中,该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中,则需要提议将它们以 cherry-pick 方式合入已发布分支。 + + + +例如,假设 master 分支正用于开发 Kubernetes 1.10 版本,而你希望将修改合入到已发布的 1.9 版本分支。相关的操作指南,请参见 [提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。 + + + +跟踪你的 cherry-pick PR,直到它合入到已发布分支中。 + +{{< note >}} + + +提议一个 cherry-pick 合入,需要你有在 PR 中设置标签和里程碑的权限。如果你没有,你需要与有权限为你设置标签和里程碑的人合作完成。 +{{< /note >}} + + + +## update-imported-docs 概述 + + + +`update-imported-docs` 工具在 `kubernetes/website/update-imported-docs/` 目录下。它执行以下步骤: + + + +1. 克隆配置文件中指定的相关仓库。为了生成参考文档,默认情况下克隆的仓库是 `kubernetes-incubator/reference-docs` 和 `kubernetes/federation`。 +1. 在克隆出的仓库下运行命令来准备文档生成器,然后生成 Markdown 文件。 +1. 将生成的 Markdown 文件复制到配置文件中指定的 `kubernetes/website` 仓库的本地目录中。 + + + +当 Markdown 文件放入 `kubernetes/website` 仓库的本地目录中后,你就可以创建 [PR](/docs/home/contribute/create-pull-request/) 将它们提交到 `kubernetes/website`。 + + + +## 自定义配置文件 + + + +打开 `/update-imported-docs/reference.yml` 进行编辑。不要修改 `generate-command` 条目的内容,除非你了解它的作用,并且需要修改指定的已发布分支。 + +```shell +repos: +- name: reference-docs + remote: https://github.com/kubernetes-incubator/reference-docs.git + # This and the generate-command below needs a change when reference-docs has + # branches properly defined + branch: master + generate-command: | + cd $GOPATH + git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes + cd src/k8s.io/kubernetes + git checkout release-1.11 + make generated_files + cp -L -R vendor $GOPATH/src + rm -r vendor + cd $GOPATH + go get -v github.com/kubernetes-incubator/reference-docs/gen-compdocs + cd src/github.com/kubernetes-incubator/reference-docs/ + make comp +``` + + + +在 reference.yml 中,`files` 字段是 `src` 和 `dst` 字段的列表。`src` 字段指定生成的 Markdown 文件的位置,而 `dst` 字段指定将此文件复制到 `kubernetes/website` 仓库的本地目录的哪个位置。例如: + +```yaml +repos: +- name: reference-docs + remote: https://github.com/kubernetes-incubator/reference-docs.git + files: + - src: gen-compdocs/build/kube-apiserver.md + dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md + ... +``` + + + +注意,当有许多文件要从同一个源目录复制到同一个目标目录时,可以使用通配符给 `src` 赋值,而使用目录名给 `dst` 赋值。例如: + +```shell + files: + - src: gen-compdocs/build/kubeadm*.md + dst: content/en/docs/reference/setup-tools/kubeadm/generated/ +``` + + + +## 运行 update-imported-docs 工具 + + + +在检查与或自定义 `reference.yaml` 文件后,运行 `update-imported-docs` 工具: + +```shell +cd /update-imported-docs +./update-imported-docs reference.yml +``` + + + +## 在 kubernetes/website 中添加和提交修改 + + + +列出生成并准备合入到 `kubernetes/website` 仓库中的文件: + +``` +cd +git status +``` + + + +输出展示了新增和修改的文件。例如,输出可能如下所示: + +```shell +... + + modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md + modified: content/en/docs/reference/command-line-tools-reference/federation-apiserver.md + modified: content/en/docs/reference/command-line-tools-reference/federation-controller-manager.md + modified: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md + modified: content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md + modified: content/en/docs/reference/command-line-tools-reference/kube-proxy.md + modified: content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +... +``` + + + +运行 `git add` 和 `git commit` 将提交上述文件。 + + + +## 创建 PR + + + +对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR,并根据需要回应评审人的评论。继续跟踪你的 PR,直到它被合入。 + + + +在 PR 合入的几分钟后,你更新的参考主题将出现在[已发布文档](/docs/home/)中。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) +* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) +* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) + +{{% /capture %}} \ No newline at end of file diff --git a/content/zh/docs/contribute/localization.md b/content/zh/docs/contribute/localization.md new file mode 100644 index 0000000000..18cb554611 --- /dev/null +++ b/content/zh/docs/contribute/localization.md @@ -0,0 +1,528 @@ +--- +title: 本地化 Kubernetes 文档 +content_template: templates/concept +approvers: +- chenopis +- zacharysarah +- zparnold +--- + + + +{{% capture overview %}} + + + +Kubernetes 文档库有多种语言: + + + +- 英语 +- 中文 +- 日语 +- 韩语 + + + +我们鼓励你添加新的[本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)! + +{{% /capture %}} + + +{{% capture body %}} + + + +## 入门 + + + +本地化必须满足工作流(*如何*本地化)和输出(本地化*内容*)的一些要求。 + + + +要添加 Kubernetes 文档库的新的本地化,你需要修改[网站配置](#modify-the-site-configuration) 和[目录结构](#add-a-new-localization-directory)来更新网站。然后你就可以开始[翻译文档](#translating-documents)了! + +{{< note >}} + + +本地化相关的[拉取请求](../create-pull-request) 示例,请参见向 Kubernetes 文档库 [Kubernetes website 仓库](https://github.com/kubernetes/website) 合入韩语本地化的[这个拉取请求](https://github.com/kubernetes/website/pull/8636)。 +{{< /note >}} + + + +让 Kubernetes SIG Docs 知道你对创建本地化感兴趣!加入 [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/)。我们很乐意帮助你快速上手并回答你的任何问题。 + + + +所有本地化团队必须使用自身的资源独立工作。我们很高兴支持你的工作,但无法为你翻译。 + + + +### 克隆仓库并创建分支 + + + +首先,在 [kubernetes/website](https://github.com/kubernetes/website) 中[创建你自己的分支](https://help.github.com/articles/fork-a-repo/)。 + + + +然后,克隆 website 仓库并通过 `cd` 命令进入 website 目录: + +```shell +git clone https://github.com/kubernetes/website +cd website +``` + +{{< note >}} + + +`k/website` 的贡献者必须[创建一个分支](/docs/contribute/start/#improve-existing-content),从创建拉取请求。对于本地化,我们还要求: + + + +1. 团队审批者直接从 https://github.com/kubernetes/website 新建开发分支。 +2. 本地化贡献者创建分支进行工作,其分支基于当前的开发分支。 + + + +这是因为本地化项目是在长期进行的分支上的协同工作,类似于 Kubernetes 发布周期的开发分支。有关本地化拉取请求,请参见[“分支策略”](#branching-strategy)。 +{{< /note >}} + + + +### 找到两个字母的语言代码 + + + +有关本地化的两个字母的国家代码,请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。例如,德语的两个字母代码是 `de`。 + +{{< note >}} + + +这些说明遵循 [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) 语言代码标准,以德语(`de`)为例。 + + + +目前没有针对德语的 Kubernetes 本地化,但欢迎你创建一个! +{{< /note >}} + + + +### 修改网站配置 + + + +Kubernetes 网站使用 Hugo 作为其 web 框架。网站的 Hugo 配置位于 [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml) 文件中。要支持新的本地化,你需要修改 `config.toml`。 + + + +将新语言的配置块添加到 `config.toml` 中现有的 `[languages]` 块下。例如,德语块如下所示: + +```toml +[languages.de] +title = "Kubernetes" +description = "Produktionsreife Container-Verwaltung" +languageName = "Deutsch" +contentDir = "content/de" +weight = 3 +``` + + + +为块分配 `weight` 参数时,请查找权重最大的语言块,并对该值加 1。 + + + +有关 Hugo 多语言支持的更多信息,请参见 “[多语言模式](https://gohugo.io/content-management/multilingual/)”。 + + + +### 创建新的本地化目录 + + + +将特定语言的子目录添加到仓库中的 [`content`](https://github.com/kubernetes/website/tree/master/content) 目录中。例如,德语的两个字母代码是 `de`: + +```shell +mkdir content/de +``` + + + +### 添加本地化自述文件 + + + +要指导其他本地化贡献者,请将新的 [`README-**.md`](https://help.github.com/articles/about-readmes/) 添加到 k/website 的顶层,其中 `**` 是两个字母的语言代码。例如,德语的自述文件是 `README-de.md`。 + + + +在本地化的 `README-**.md` 文件中为本地化贡献者提供指导。包括 `README.md` 中包含的相同信息以及: + + + +- 本地化项目的联系人 +- 任何特定于本地化的信息 + + + +创建本地化的自述文件后,请在主英文文件中添加指向该文件的链接,[`README.md`'s Localizing Kubernetes Documentation],并以英文包含联系信息。你可以提供 GitHub ID、电子邮箱、[Slack channel](https://slack.com/) 或其他联系方式。 + + + +## 翻译文档 + + + +本地化*所有* Kubernetes 文档是一项艰巨的任务。从小做起,循序渐进。 + + + +所有本地化至少必须包括: + + + +描述 | 网址 +-----|----- +主页 | [所有标题和副标题网址](/docs/home/) +安装 | [所有标题和副标题网址](/docs/setup/) +教程 | [Kubernetes 基础](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) +网站字符串 | [新的本地化 TOML 文件中的所有网站字符串](https://github.com/kubernetes/website/tree/master/i18n) + + + +翻译后的文档必须保存在自己的 `content/**/` 子目录中,否则将遵循与英文源相同的 URL 路径。例如,要准备将 [Kubernetes 基础](/docs/tutorials/kubernetes-basics/) 教程翻译为德语,请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源: + +```shell +mkdir -p content/de/docs/tutorials +cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md +``` + + + +本地化相关的[拉取请求](../create-pull-request) 示例,请参见向 Kubernetes 文档库 [Kubernetes website 仓库](https://github.com/kubernetes/website) 合入韩语本地化的[这个拉取请求](https://github.com/kubernetes/website/pull/10471)。 + + + +### 源文件 + + + +本地化必须使用最新版本的英文文件作为其源。最新版本是 **{{< latest-version >}}**。 + + + +要查找最新版本的源文件,请执行以下操作: + + + +1. 导航到 Kubernetes website 仓库,网址为 https://github.com/kubernetes/website。 +2. 选择 `release-1.X` 分支作为最新版本。 + + + +最新版本是 **{{< latest-version >}}**,所以最新的发布分支是 [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})。 + + + +### i18n 中的网站字符串/ + + + +本地化必须在新的语言特定文件中包含 [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) 的内容。以德语为例:`i18n/de.toml`。 + + + +将新的本地化文件添加到 `i18n/`。例如德语 (`de`): + +```shell +cp i18n/en.toml i18n/de.toml +``` + + + +然后转换每个字符串的值: + +```TOML +[docs_label_i_am] +other = "ICH BIN..." +``` + + + +本地化网站字符串允许你自定义网站范围的文本和特性:例如,每个页面页脚中的合法版权文本。 + + + +## 项目组织 + + + +### 联系 SIG Docs 主席 + + + +开始新的本地化时,请联系 Kubernetes [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs#chairs) 中的主席之一。 + + + +### 维护者 + + + +每个本地化存储库必须提供自己的维护人员。维护人员可以来自单个组织或多个组织。只要可能,本地化的拉取请求应该由来自不同组织的评审者批准,而不是由翻译人员批准。 + + + +本地化必须至少提供两个维护人员。(不能评审和批准自己的工作。) + + + +### 分支策略 + + + +因为本地化项目是高度协同的工作,所以我们鼓励团队基于共享的开发分支工作。 + + + +在开发分支上协作: + + + +1. 团队成员新建一个开发分支,通常通过在 https://github.com/kubernetes/website 上针对源分支新建一个拉取请求。 + + + + 我们推荐以下分支命名方案: + + `dev--.` + + + + 例如,一个德语本地化团队的审批者基于 Kubernetes v1.12 版本的源分支直接新建了 k/website 仓库的开发分支 `dev-1.12-de.1`。 + + + +2. 个人贡献者基于开发分支新建特性分支。 + + + + 例如,一个德国贡献者新建了一个拉取请求,并从 `username:local-branch-name` 更改了 `kubernetes:dev-1.12-de.1`。 + + + +3. 审批者审批功能分支并将其合入到开发分支中。 + + + +4. 审批者定期将开发分支合并到其源分支。 + + + +根据需要重复步骤 1-4,直到完成本地化工作。例如,随后的德语开发分支将是:`dev-1.12-de.2`、`dev-1.12-de.3`,等等。 + + + +团队必须将本地化内容合入到发布分支中,该发布分支也正是内容的来源。例如,源于 {{< release-branch >}} 的开发分支必须基于 {{< release-branch >}}。 + + + +审批者必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。开发分支的存在时间越长,通常需要的维护工作就越多。考虑定期合并开发分支并新建分支,而不是维护一个运行非常长的开发分支。 + + + +虽然只有审批者可以合入拉取请求,但任何人都可以为新的开发分支新建拉取请求。不需要特殊权限。 + + + +有关基于克隆或直接从仓库开展工作的更多信息,请参见 ["fork and clone the repo"](#fork-and-clone-the-repo)。 + + + +### 上游贡献 + + + +Sig Docs 欢迎[上游贡献和更正](/docs/contribute/intermediate#localize-content) 到英文源。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +一旦 l10n 满足工作流和最小输出的要求,SIG docs 将: + + + +- 在网站上启用语言选择 +- 通过[云原生计算基金会](https://www.cncf.io/) (CNCF) 渠道,包括 [Kubernetes blog](https://kubernetes.io/blog/),来宣传本地化的可用性。 + +{{% /capture %}} diff --git a/content/zh/docs/contribute/start.md b/content/zh/docs/contribute/start.md new file mode 100644 index 0000000000..a2ca496cee --- /dev/null +++ b/content/zh/docs/contribute/start.md @@ -0,0 +1,684 @@ +--- +title: 开始贡献 +slug: start +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 10 +--- + + + +{{% capture overview %}} + + +如果您想要为 Kubernetes 文档做贡献,本页面的内容和链接的主题能够给您帮助。您不必是一位开发者或者技术作者,也同样可以为 Kubernetes 文档及其用户体验带来巨大的影响!您只需要有一个 [Github 账号](https://github.com/join) 和一个浏览器。 + + +如果您在寻找有关如何开始向 Kubernetes 仓库贡献代码的信息,请参考 [Kubernetes 社区指南](https://github.com/kubernetes/community/blob/master/governance.md)。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 关于我们文档的基础知识 + + +Kubernetes 文档是以 Markdown 形式编写的,使用 Hugo 进行部署。源码位于 Github 的 [https://github.com/kubernetes/website](https://github.com/kubernetes/website)。 +大部分文档源码位于 `/content/en/docs/`。有些参考文档是由 `update-imported-docs/` 目录内的脚本自动生产的。 + + +您可以查找 issue、编辑内容或者对其他人的提交内容进行复审,这些都可以在 Github 网站上完成。您也可以使用 Github 内置的历史功能和查询工具。 + + +并非所有的任务都可以通过 Github UI 完成,这些任务会在[中级](/docs/contribute/intermediate/)和[高级](/docs/contribute/advanced/)文档贡献指南中讨论。 + + +### 参与文档特别兴趣小组(SIG Docs) + + +Kubernetes 文档是由特别兴趣小组(SIG)维护的,该小组名为 SIG Docs。我们通过 Slack 频道、邮件列表和网络视频周会进行交流。 +欢迎新的参与者加入。更多信息,请参考[参与 SIG Docs](/docs/contribute/participating/)。 + + +### 风格指南 + + +我们维护了一个[风格指南](/docs/contribute/style/style-guide/)页面,上面有关于 SIG Docs 社区对于语法、句法、源格式和排版的约定。 +在您做首次贡献前或者在有疑问的时候请先查阅风格指南。 + + +风格的变化是由 SIG Docs 组共同决定的。如您想提交变更或增加内容,请将内容[添加到议题](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit#)并参与会议讨论。 +更多信息,参见[进阶贡献](/docs/contribute/advanced/)主题。 + + +### 页面模板 + + +我们使用页面模板来控制文档页面。需要确保您理解这些模版是如何工作的,请阅读[使用页面模板](/docs/contribute/style/page-templates/)。 + + +### Hugo 短代码 + + +Kubernetes 文档使用 Hugo 将 Markdown 转换成 HTML。我们使用标准的 Hugo 短代码,同时也会有部分为 Kubernetes 定制化的代码。 +有关如何使用短代码的信息,请参见[自定义 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。 + + +### 多语言 + + +在 `/content/` 目录中有文档源码的多语言版本。每个语言拥有其自己的目录,采用 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php) 的两位编码命名。例如,英文文档源码位于 `/content/en/docs/` 目录。 + + +更多关于对多语言文档做贡献的信息,请参考中级贡献指南中的["本地化内容"](/docs/contribute/intermediate#localize-content)。 + + +如果您有兴趣开始一个新的本地化语言项目,请参考["本地化"](/docs/contribute/localization/)。 + + +## 登记文档可操作问题 + + +任何拥有 Github 账号的人都能对于 Kubernetes 文档登记一个问题(或者 bug 报告)。 +如果看到有东西坏了,即便您不知道如何修复它,请[登记一个问题](#how-to-file-an-issue)。 +除了您发现微小的错误的情况,例如发现了一个拼写错误,您想自己进行修复。在这种情况下, +您可以[修复它](#improve-existing-content),而不用先登记一个 bug。 + + +### 如何记录问题 + + +- **对于已有页面** + + + 如果您在已有的 [Kubernetes 文档](/docs/)页面,在页面底部直接点击 **创建问题** 按钮。 + 如果您当前未登录 Github,那么请登录。Github 文档表单会带着预填的信息出现。 + + + 使用 Markdown 格式,填写尽可能多的详细信息。在方括号 (`[ ]`) 中,使用 `x` 代码选择了该选项。 + 如果您提交了修复问题的方法,也填在里面。 + + +- **请求创建一个新页面** + + + 如果认为有些内容应该存在,但您不知道应该将这些内容存放在哪里,或者任何不适合放在现有页面中, + 那么也可以记录一个问题。您可以选择通过内容相近的页面创建问题,或者直接 + 在 [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) + 中记录问题。 + + +### 如何记录好的问题 + + +要确保我们能理解您的问题,并能付诸行动,请谨记如下指南: + + +- 使用问题模板,尽可能填写详细的信息。 +- 清楚地描述该问题对用户造成的具体影响。 +- 限制问题的范围,以提交给合理的工作组。如果问题范围很大,将其拆分成若干个小问题。 + + + 例如,“修复安全文档”就是一个不可执行的问题,但 “为'限制网络访问'主题添加详细信息”就是可执行的。 +- 如果问题与另一个问题或者拉取请求(PR)有关,您可以通过问题的完整 URL 或者 PR 的序号(以 `#` 为前缀)进行关联。例如 `源于 #987654`。 +- 保持尊重,避免发泄。例如,"这问题就是个垃圾"就是无用且不可执行的反馈。[行为准测](/community/code-of-conduct/) 也适用于 Kubernetes Github 仓库的交流。 + + +## 参与 SIG Docs 讨论 + + +SIG Docs 团队的交流采用如下机制: + + +- [加入 Kubernetes 的 Slack 工作组](http://slack.k8s.io/),然后加入 `#sig-docs` 频道,在那里我会实时讨论文档的问题。一定要做自我介绍! +- [加入 `kubernetes-sig-docs` 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),在这里会有广泛的讨论以及官方决策的记录。 +- 参与 [SIG Docs 视频周例会](https://github.com/kubernetes/community/tree/master/sig-docs),会通过 Slack 频道和邮件列表通知。 + 目前通过 Zoom 进行会议,所以您需要下载 [Zoom 客户端](https://zoom.us/download),或者通过手机拨入。 + + +{{< note >}} +您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。 +{{< /note >}} + + +## 改进现有内容 + + +要改进现有的内容,您可以在创建 _fork_ 之后起草一个 _拉取请求(PR)_ 。 +这两个术语是 [Github 专用的](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/)。 +出于本主题的目的,您无需了解有关它们的所有信息,因为您可以通过浏览器做所有的事情。 +当您继续阅读[贡献者中级指南](/docs/contribute/intermediate/),您会需要更多 Git 术语的背景知识。 + + +{{< note >}} +**Kubernetes 代码开发者**: 如果您在撰写 Kubernetes 新版本的新功能文档,流程会稍有不同。 +关于流程指南和最后期限的信息,请参阅[编写功能文档](/docs/contribute/intermediate/#sig-members-documenting-new-features)。 +{{< /note >}} + + +## 签署 CLA + + +在贡献 Kubernetes 的代码或文档前,您 **必须** 阅读[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md), +并[签署贡献者许可协议(CLA)](https://github.com/kubernetes/community/blob/master/CLA.md)。 +别担心 -- 不需要太多时间! + + +### 找些活干 + + +如果您发现了一些想要马上修复的东西,只需要遵循如下指南。您不需要[记录一个问题](#file-actionable-issues)(尽管你当然可以这么做)。 + + +如果您想从处理现有的问题开始,前往 [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) +找一些有 `good first issue` 标签的问题(您可以使用[这个](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) 捷径)。 +阅读评论,确保针对此问题没有打开的 PR,并且没有人留言说他们最近正在解决这个问题(3天是个很好的规则)。留言说您会去解决这个问题。 + + +## 选择使用的 Git 分支 + + +提交 PR 最重要的方面就是选择您工作所基于的基础分支。使用如下指南来做决定: + + +- 用 `master` 来解决以及发布的内容中的问题,或者对于已经存在的内容进行改进。 +- 使用 release 分支(比如 `dev-{{< release-branch >}}` 用于 {{< release-branch >}} 发布)来撰写新的特性或者下个版本还未发布的变更说明。 +- 使用 SIG Docs 已经同意的 feature 分支来协作对现有文档进行重大改进或更改,包括内容重组或网站外观的更改。 + + +如果您还不确定应该使用哪个分支,在 Slack 上询问 `#sig-docs` 或者参与 SIG Docs 周会来确认。 + + +### 提交 PR + + +按照如下步骤进行 PR 提交以改善 Kubernetes 文档。 + + +1. 在您发现问题的页面上,点击右上角的铅笔图标。新的页面就会出现,上面会有一些帮助信息。 +2. 如果您从未创建过 Kubernetes 文档仓库的 fork,会提示您需要创建。请在您的 Github 账号 + 下创建 fork,而不是在您所在的组织下创建。fork URL 通常是这样的 `https://github.com//website`, + 出发您已经有一个同名的仓库,那样会造成冲突。 + +3. Github Markdown 编辑器会载入着文档源码一起出现。根据实际情况撰写变化内容。在编辑器下方, + 填写 **Propose file change(建议修改文件)** 表格。第一个区域需要填写提交说明消息, + 不能超过 50 个字符。第二个区域是可选的,也能够填写更多详细信息。 + + + {{< note >}} +不要把 Github 问题或者 PR 的关联信息放在您的提交说明消息中。您可以之后把这些内容添加到 PR 的描述中。 +{{< /note >}} + + + 点击 **建议修改文件(Propose file change)** 按钮。 + 变更会保存为您 fork 新分支(通常会自动命名为 `patch-1`)中的一个提交内容。 + + +4. 接下来屏幕会总结您的变更,将您的新分支(**head fork** 和 **compare** 选择框) + 与 **base fork** 和 **base** 分支(默认是 `kubernetes/website` 的 `master` 分支) + 进行比较。您可以更改选择框,但现在请不要这么做。看一下屏幕底部显示的变化内容, + 如果看起来没问题,点击 **创建 PR(Create pull request)** 按钮。 + + + {{< note >}} +如果您现在还不想创建 PR,也可以稍后再做,通过浏览 Kubernetes 网站代码仓库或者您 fork 仓库的网站主页 URL。 +Github 网站会检查到您推送了一个新分支到 fork,并提示创建 PR。 +{{< /note >}} + + +5. **Open a pull request(打开一个 PR)** 屏幕出现了。PR 的主题和提交说明的内容一致, + 如有需要您也可以修改。主体内容会自动填充您的扩展提交消息(如果存在)和一些模板文本。 + 阅读模板文本并填写要求的详细信息,然后删除额外的模板文本。 + 保留选中 **Allow edits from maintainers(允许维护者编辑)** 复选框。 + 单击 **Create pull request(创建拉取请求)** 按钮。 + + + 祝贺您!您的 PR 就出现在了[拉取请求](https://github.com/kubernetes/website/pulls) 中。 + + + 几分钟后,您可以预览 PR 所带来的变化。前往您 PR 的 **Conversation(对话)** 标签页, + 点击 `deploy/netlify` 测试的 **Details(详细信息)** 链接,它在页面底部附件。 + 默认会在同一个浏览器窗口中打开。 + + +6. 等待复审。通常,复审人员会由 `k8s-ci-robot` 建议指定。如果复审人员建议您修改,您可以 + 前往 **Files changed(改变的文件内容)** 标签页,点击任意 PR 中改变的文件页面上的铅笔图标。 + 保存更改的文件时,将在 PR 监视的分支中创建新的提交。 + + +7. 如果修改被接受,复审人员会合并您的 PR,修改就会在几分钟后在 Kubernetes 网站上生效。 + + +这是提交 PR 的唯一方式。如果您已经是一名 Git 和 Github 的高级用户,您也可以使用本地 GUI 或者 +Git 命令行。关于使用 Git 客户端的基础会在[中级](/docs/contribute/intermediate/) 贡献者指南中讨论。 + + +## 复审文档 PR + + +就算不是批注者或者复审者,也同样可以复审 PR。复审人员并不是"固定"的,意味着您单独的评审并不会让 PR 合并。 +然而,这依然对我们是很有帮助的。即使您没有留下任何评审意见,您可以了解 PR 的规范和礼仪,并习惯工作流程。 + + +1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)。 + 请会看到一个列表,里面包含了所有对于 Kubernetes 网站和文档提的 PR。 + + +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. 前往 **Files changed(文件修改)** 标签页。查看 PR 中的变化部分,如果适用,也看一下关联的问题。 + 如果您发现问题或者可以改进的空间,将鼠标悬浮在那一行并点击前面出现的 `+` 加号。 + + + 你可以留下评论,选择 **Add single comment(仅添加评论)** 或者也可以 **Start a review(开始复审)**。 + 典型来说,开始复审更好,因为这样您就可以在多行下留下评论,并且只有在完成复审后统一提交并通知 PR 的作者, + 而不是每一条评论都发送通知。 + + +4. 完成后,点击页面顶端但 **Review changes(复审修改)** 按钮。您可以总结复审,并且可以选择 + comment(评论),approve(批准),或者 request changes(请求变更)。 + 新的贡献者应该选择 **Comment(评论)**。 + + +感谢您对于 PR 的复审工作!当您对于项目还是新人时,最好在拉取请求评论中征求反馈意见。 +Slack 的 `#sig-docs` 频道就是一个征求意见好去处。 + + +## 撰写一篇博客文章 + + +任何人都可以撰写博客并提交复审。博客文章不应具有商业性质,而应包含广泛适用于 Kubernetes 社区的内容。 + + +要提交博客文章,您可以选择使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform) +或者按如下步骤进行: + + +1. [签署 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. 博客复审人员会对您提交对内容进行复审,并与您一起完成反馈意见和最终的详细信息。 + 博客文章获得批准后,博客将会安排时间进行发布。 + + +## 提交一个案例研究 + + +案例研究强调组织如何使用 Kubernetes 解决实际问题。它们是由 Kubernetes 市场团队共同撰写的,由 CNCF 进行处理。 + + +看一下[现有案例研究](https://github.com/kubernetes/website/tree/master/content/en/case-studies)的源码。 +使用 [Kubernetes 案例研究提交表](https://www.cncf.io/people/end-user-community/)提交您的提案。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +当您对本主题中讨论的所有任务感到满意,并且您希望以更深入的方式与 Kubernetes 文档团队合作, +请阅读[中级贡献者指南](/docs/contribute/intermediate/)。 + +{{% /capture %}} diff --git a/content/zh/docs/contribute/style/_index.md b/content/zh/docs/contribute/style/_index.md new file mode 100644 index 0000000000..aacaf26575 --- /dev/null +++ b/content/zh/docs/contribute/style/_index.md @@ -0,0 +1,21 @@ +--- +title: 文档风格概述 +main_menu: true +weight: 80 +--- + + + + + +本节的主题是提供有关编写风格、内容格式和组织以及使用 Hugo 定制生成 Kubernetes 文档的指导。 diff --git a/content/zh/docs/contribute/style/content-organization.md b/content/zh/docs/contribute/style/content-organization.md new file mode 100644 index 0000000000..3ce7964655 --- /dev/null +++ b/content/zh/docs/contribute/style/content-organization.md @@ -0,0 +1,270 @@ +--- +title: 内容组织 +content_template: templates/concept +weight: 40 +--- + + + + +{{% capture overview %}} + + + +本网站使用了 Hugo。在 Hugo 中,[内容组织](https://gohugo.io/content-management/organization/) 是一个核心概念。 + +{{% /capture %}} + +{{% capture body %}} + +{{% note %}} + + +**Hugo 提示:** 用 `hugo server --navigateToChanged` 命令启动 Hugo 以进行内容编辑会话。 +{{% /note %}} + + + +## 页面列表 + + + +### 页面顺序 + + + +文档侧方菜单、文档页面浏览器等以 Hugo 的默认排序顺序列出,它按照权重(从1开始)、日期(最新的排第一个)排序,最后按链接标题排序。 + + + +如果你想提升一个页面或一个章节,请在页面头部设置一个较高的权重: + +```yaml +title: My Page +weight: 10 +``` + + +{{% note %}} + + +对于页面的权重,不建议使用连续的数值,比如1、2、3...,而是采用间隔的数值,比如10、20、30...,这样你可以将后续的页面插入到想要的位置。 +{{% /note %}} + + + + +### 文档主菜单 + + + +`Documentation` 主菜单是从 `docs/` 下面的章节构建的,它在 `_index.md` 章节内容文件的头部设置了 `main_menu` 标志: + + +```yaml +main_menu: true +``` + + + + +注意,链接标题是从页面的 `linkTitle` 中提取的,因此如果希望它与标题不同,请在内容文件中更改它: + + +```yaml +main_menu: true +title: Page Title +linkTitle: Title used in links +``` + + +{{% note %}} + + +以上每种语言都需要完成。如果在菜单中没有看到你的章节,这可能是因为它没有被 Hugo 标识为一个章节。请在章节对应的目录下创建 `_index.md` 内容文件。 +{{% /note %}} + + + +### 文档侧方菜单 + + + +文档侧方菜单是从 `docs/` 下面的 _current 章节的 tree_ 开始构建的。 + + + +它将显示所有的章节和它们的页面。 + + + +如果你不想列出某个章节或页面,请在页面头部将 `toc_hide` 标志设置为 `true`。 + +```yaml +toc_hide: true +``` + + + +当导航到具有内容的章节时,将显示出指定的章节或页面(例如 `_index.md`)。否则,将显示该章节里的第一个页面。 + + + +### 文档浏览器 + + + +文档主页上的页面浏览器是用 `docs section` 下一层的所有章节和页面构建的。 + + + +如果你不想列出某个章节或页面,请在页面头部将 `toc_hide` 标志设置为 `true`。 + +```yaml +toc_hide: true +``` + + + +### 主菜单 + + + +右上菜单中的网站链接(也在页脚中)是通过页面查找构建的。这是为了确保页面实际存在。因此,如果 `case-studies` 章节在网站中不存在(按语言),则它将链接不到。 + + + + +## 页面包 + + + +除了独立的内容页面(Markdown文件),Hugo 还支持 [页面包](https://gohugo.io/content-management/page-bundles/)。 + + + +一个例子是 [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/)。它被认为是 `leaf bundle`。目录下的所有内容,包括 `index.md`,都是包的一部分。这还包括页面相关的链接、可被处理的图像等: + +```bash +en/docs/home/contribute/includes +├── example1.md +├── example2.md +├── index.md +└── podtemplate.json +``` + + + +另一个广泛使用的例子是 `includes` 包。它在页面头部设置 `headless: true`,这意味着它没有得到自己的 URL。它只用于其他页面。 + +```bash +en/includes +├── default-storage-class-prereqs.md +├── federated-task-tutorial-prereqs.md +├── federation-content-moved.md +├── index.md +├── partner-script.js +├── partner-style.css +├── task-tutorial-prereqs.md +├── user-guide-content-moved.md +└── user-guide-migration-notice.md +``` + + + +包中文件的一些重要说明: + + + +* 对于已翻译的包,任何丢失的非内容文件将从上面的语言继承。这避免了重复。 +* 包中的所有文件都是 Hugo 所指的 `Resources`,你可以为每种语言提供元数据,例如参数和标题,即使它不支持头部设置(YAML 文件等)。参见[页面资源元数据](https://gohugo.io/content-management/page-resources/#page-resources-metadata)。 +* 从 `Resource` 的 `.RelPermalink` 中获得的值是页面相关的。参见 [Permalinks](https://gohugo.io/content-management/urls/#permalinks)。 + + + + +## 样式 + + + +本网站的样式表的 `SASS` 源存储在 `src/sass` 下面,可以用 `make sass` 构建(Hugo很快就会得到 `SASS` 的支持,参见https://github.com/gohugoio/hugo/issues/4243)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [定制 Hugo 短代码](/docs/contribute/style/hugo-shortcodes/) +* [样式指南](/docs/contribute/style/style-guide) + +{{% /capture %}} diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example1.md b/content/zh/docs/contribute/style/hugo-shortcodes/example1.md new file mode 100644 index 0000000000..0656ce4883 --- /dev/null +++ b/content/zh/docs/contribute/style/hugo-shortcodes/example1.md @@ -0,0 +1,23 @@ +--- +title: 例子 #1 +--- + + + + + +这是一个内容文件**示例**,位于一个**includes**叶子包中。 + +{{< note >}} + + +包含的内容文件也可以包含短代码。 +{{< /note >}} \ No newline at end of file diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example2.md b/content/zh/docs/contribute/style/hugo-shortcodes/example2.md new file mode 100644 index 0000000000..356983f3c0 --- /dev/null +++ b/content/zh/docs/contribute/style/hugo-shortcodes/example2.md @@ -0,0 +1,17 @@ +--- +title: 例子 #1 +--- + + + + + +这是另一个内容文件**示例**,位于一个**includes**叶子包中。 + + diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/index.md b/content/zh/docs/contribute/style/hugo-shortcodes/index.md new file mode 100644 index 0000000000..b9523c7217 --- /dev/null +++ b/content/zh/docs/contribute/style/hugo-shortcodes/index.md @@ -0,0 +1,272 @@ +--- +approvers: +- chenopis +title: 定制 Hugo 短代码 +content_template: templates/concept +--- + + + +{{% capture overview %}} + +本页面将介绍定制 Hugo 短代码,可以用于 Kubernetes markdown 文档书写。 + + +更多关于短代码参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。 +{{% /capture %}} + +{{% capture body %}} + +## 功能状态 + + +本站上面的 markdown 页面,你可以加入短代码来展示已经文档介绍的功能的版本和状态(state)。 + + +### 功能状态演示 + + +下面是一个功能状态代码段的演示,表明这个功能已经在 Kubernetes v1.10时就已经稳定了。 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state for_k8s_version="v1.10" state="stable" >}} + + +`state`的可选值如下: + +* alpha +* beta +* deprecated +* stable + + +### 功能状态代码 + + +下面是为每个现有的功能状态的模板代码。 + + + +显示的 Kubernetes 默认为该页或站点版本。 +这个可以通过修改 for_k8s_version 短代码参数来调整。 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state for_k8s_version="v1.10" state="stable" >}} + + +#### Alpha 功能 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state state="alpha" >}} + + + +#### Beta 功能 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state state="beta" >}} + + +#### 稳定功能 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state state="stable" >}} + + +#### 废弃功能 + +``` +{{}} +``` + + +会转换为: + +{{< feature-state state="deprecated" >}} + + +## 词汇 + + + +你可以通过加入术语词汇的短代码,来自动更新和替换相应链接中的内容([我们的词汇库](/docs/reference/glossary/)) +这样,在浏览在线文档,鼠标移到术语上时,术语解释就会显示在提示框中。 + + + +词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary),每个内容文件对应相应的术语解释。 + + +### 词汇演示 + + + +例如,下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`,然后在提示框中显示。 + +````liquid +{{}} +```` + + +## 标签页 + + +在本站的 markdown 页面(`.md` 文件)中,你可以加入一个标签页集来显示不同形式的解决方案。 + + +标签页的短代码包含以下参数: + + + +* `name`: 标签页上的名字。 +* `codelang`: 如果要在`tab`短代码中加入内部内容,需要告知 Hugo 使用的是什么代码语言,方便代码高亮。 +* `include`: 标签页中所要包含的文件。如果标签页是在 Hugo 的页面包([leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles))中,文件(可以是 Hugo 所支持的 MIME 类型文件)将会在包中查找。如果不是,所要包含的内容页面将会在当前路径的相关路径下查找。注意,在`include`属性部分,不能加入短代码内部内容,必须要使用自结束(self-closing)的语法。 +非内容文件将会被代码高亮。如果没有在`codelang`进行声明的话,所用的代码语言将会来自文件名。 + + + +* 如果内部内容是 markdown, 你必须要使用 `%` 分隔符来包装标签页,例如,`{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` +* 可以在标签页集中混合使用上面的各种变形。 + + +下面是演示标签页短代码。 + +{{< note >}} +The tab **name** in a `tabs` definition must be unique within a content page. +一个内容页面下的,标签页定义中的标签页 **名** 必须是唯一的。 +{{< /note >}} + + +### 标签页演示:代码高亮 + +```go-text-template +{{}} +{{{< tab name="Tab 1" codelang="bash" >}} +echo "This is tab 1." +{{< /tab >}} +{{< tab name="Tab 2" codelang="go" >}} +println "This is tab 2." +{{< /tab >}}} +{{< /tabs */>}} +``` + + +会转换为: + +{{< tabs name="tab_with_code" >}} +{{< tab name="Tab 1" codelang="bash" >}} +echo "This is tab 1." +{{< /tab >}} +{{< tab name="Tab 2" codelang="go" >}} +println "This is tab 2." +{{< /tab >}} +{{< /tabs >}} + +### Tabs demo: Inline Markdown and HTML + +```go-html-template +{{}} +{{% tab name="Markdown" %}} +This is **some markdown.** +{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}} +{{% /tab %}} +{{< tab name="HTML" >}} +
+

Plain HTML

+

This is some plain HTML.

+
+{{< /tab >}} +{{< /tabs */>}} +``` + + +会转换为: + +{{< tabs name="tab_with_md" >}} +{{% tab name="Markdown" %}} +This is **some markdown.** +{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}} +{{% /tab %}} +{{< tab name="HTML" >}} +
+

Plain HTML

+

This is some plain HTML.

+
+{{< /tab >}} +{{< /tabs >}} + + +### 标签页演示:文件嵌套 + +```go-text-template +{{}} +{{< tab name="Content File #1" include="example1" />}} +{{< tab name="Content File #2" include="example2" />}} +{{< tab name="JSON File" include="podtemplate" />}} +{{< /tabs */>}} +``` + + +会转换为: + +{{< tabs name="tab_with_file_include" >}} +{{< tab name="Content File #1" include="example1" />}} +{{< tab name="Content File #2" include="example2" />}} +{{< tab name="JSON File" include="podtemplate" />}} +{{< /tabs >}} + + +{{% /capture %}} + +{{% capture whatsnext %}} + + +* 了解 [Hugo](https://gohugo.io/)。 +* 了解 [撰写新的话题](/docs/home/contribute/write-new-topic/)。 +* 了解 [使用页面模板](/docs/home/contribute/page-templates/)。 +* 了解 [暂存修改](/docs/home/contribute/stage-documentation-changes/)。 +* 了解 [创建 pull request](/docs/home/contribute/create-pull-request/)。 +{{% /capture %}} diff --git a/content/zh/docs/contribute/style/page-templates.md b/content/zh/docs/contribute/style/page-templates.md new file mode 100644 index 0000000000..f1afdff427 --- /dev/null +++ b/content/zh/docs/contribute/style/page-templates.md @@ -0,0 +1,352 @@ +--- +title: 使用页面模板 +content_template: templates/concept +weight: 30 +--- + + + +{{% capture overview %}} + + + +当贡献新主题时,选择下列模板中的一种。 +这使指定页面的用户体验标准化。 + + + +页面模板在 [`kubernetes/website`](https://github.com/kubernetes/website) 仓库的 [`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) 目录中。 + +{{< note >}} + + +每个新主题都需要使用模板。如果你不确定新主题要使用哪个模板,请从[概念模板](#concept-template)开始。 +{{< /note >}} + + +{{% /capture %}} + + +{{% capture body %}} + + + +## 概念模板 + + + +每个概念页面负责解释 Kubernetes 的某方面。例如,概念页面可以描述 Kubernetes Deployment 对象,并解释当部署、扩展和更新时,它作为应用程序所扮演的角色。一般来说,概念页面不包括步骤序列,而是提供任务或教程的链接。 + + + + +要编写新的概念页面,请在 `/content/en/docs/concepts` 目录的子目录中创建一个 Markdown 文件,其特点如下: + + + +- 在页面的 YAML 头部,设置 `content_template: templates/concept`。 +- 在页面的 body 中,设置所需的 `capture` 变量和所有想要包含的变量: + + | 变量 | 必需? | + |---------------|-----------| + | overview | 是 | + | body | 是 | + | whatsnext | 否 | + + + + 页面的 body 看起来像这样(移除所有不想要的可选 `capture` 变量): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture body */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + + + +- 在每个章节中写下你的内容。请遵从以下规则: + - 使用不低于 H2 级别的标题(避免使用 H1 的标题,但 H3、H4 的标题是可以的)(以两个 `#` 字符开头)。这些章节本身是由模板自动命名的。 + - 在 `overview` 节,用一个段落的篇幅来为当前话题设定语境。 + - 在 `body` 节,使用自由形式的 Markdown 文件来解释概念。 + - 在 `whatsnext` 节,列出读者接下来可能感兴趣的最多 5 个主题。 + + + +使用概念模板的已发布主题的一个示例是[注解](/docs/concepts/overview/working-with-objects/annotations/)。你当前正在阅读的页面也使用概念模板。 + + + +## 任务模板 + + + +任务页面展示了如何完成单个任务,通常是通过给出一个简短的步骤序列。任务页面中解释性质的文字极少,但是通常会给出提供相关背景和知识的概念主题的链接。 + + + +要编写新的任务页面,请在 `/content/en/docs/tasks` 目录的子目录中创建一个 Markdown 文件,其特点如下: + + + +- 在页面的 YAML 头部,设置 `content_template: templates/task`。 +- 在页面的 body 中,设置所需的 `capture` 变量和所有想要包含的变量: + + | 变量 | 必需? | + |---------------|-----------| + | overview | 是 | + | prerequisites | 是 | + | steps | 否 | + | discussion | 否 | + | whatsnext | 否 | + + + + 页面的 body 看起来像这样(移除所有不想要的可选 `capture` 变量): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture prerequisites */%}} + + {{}} {{}} + + {{%/* /capture */%}} + + {{%/* capture steps */%}} + + {{%/* /capture */%}} + + {{%/* capture discussion */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + + + +- 在每个章节中写下你的内容。请遵从以下规则: + - 使用不低于 H2 级别的标题(避免使用 H1 的标题,但 H3、H4 的标题是可以的)(以两个 `#` 字符开头)。这些章节本身是由模板自动命名的。 + - 在 `overview` 节,用一个段落的篇幅来为当前话题设定语境。 + - 在 `prerequisites 节`,如果有可能,请使用列表。在 `include` 下开始添加额外的先决条件。默认的先决条件包括运行中的 Kubernetes 集群。 + - 在 `steps` 节,使用编号列表。 + - 在讨论部分,使用通常的内容来扩展 `steps` 中包含的信息。 + - 在 `whatsnext` 节,列出读者接下来可能感兴趣的最多 5 个主题。 + + + +使用任务模板的已发布主题的一个示例是[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api)。 + + + +## 教程模板 + + + +教程页面展示了如何完成比单个任务更大的目标。通常教程页有几个章节,每个章节都有步骤说明。例如,教程可以提供说明 Kubernetes 的特定特性的代码示例的演练。教程可以包括表层解释,但是应该链接到相关的概念主题以进行深入解释。 + + + +要编写新的教程页面,请在 `/content/en/docs/tutorials` 目录的子目录中创建一个 Markdown 文件,其特点如下: + + + +- 在页面的 YAML 头部,设置 `content_template: templates/tutorial`。 +- 在页面的 body 中,设置所需的 `capture` 变量和所有想要包含的变量: + + | 变量 | 必需? | + |---------------|-----------| + | overview | 是 | + | prerequisites | 是 | + | objectives | 是 | + | lessoncontent | 是 | + | cleanup | 否 | + | whatsnext | 否 | + + + + 页面的 body 看起来像这样(移除所有不想要的可选 `capture` 变量): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture prerequisites */%}} + + {{}} {{}} + + {{%/* /capture */%}} + + {{%/* capture objectives */%}} + + {{%/* /capture */%}} + + {{%/* capture lessoncontent */%}} + + {{%/* /capture */%}} + + {{%/* capture cleanup */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + + + +- 在每个章节中写下你的内容。请遵从以下规则: + - 使用不低于 H2 级别的标题(避免使用 H1 的标题,但 H3、H4 的标题是可以的)(以两个 `#` 字符开头)。这些章节本身是由模板自动命名的。 + - 在 `overview` 节,用一个段落的篇幅来为当前话题设定语境。 + - 在 `prerequisites` 节,如果有可能,请使用列表。在默认情况下添加额外的先决条件。 + - 在 `objectives` 节,使用列表。 + - 在 `lessoncontent` 节,适当地使用编号列表和叙述内容的组合。 + - 在 `cleanup` 节,使用编号列表描述完成任务后清理集群状态的步骤。 + - 在 `whatsnext` 节,列出读者接下来可能感兴趣的最多 5 个主题。 + + + +使用教程模板的已发布主题的一个示例是[使用部署运行无状态应用程序](/docs/tutorials/stateless-application/run-stateless-application-deployment/)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +- 学习[样式指南](/docs/contribute/style/style-guide/) +- 学习[内容组织](/docs/contribute/style/content-organization/) + +{{% /capture %}} diff --git a/content/zh/docs/contribute/style/write-new-topic.md b/content/zh/docs/contribute/style/write-new-topic.md new file mode 100644 index 0000000000..82378bf1be --- /dev/null +++ b/content/zh/docs/contribute/style/write-new-topic.md @@ -0,0 +1,346 @@ +--- +title: 撰写新主题 +content_template: templates/task +weight: 20 +--- + + + +{{% capture overview %}} + + +本页面展示如何为 Kubernetes 文档库创建新主题。 +{{% /capture %}} + +{{% capture prerequisites %}} + + +创建 Kubernetes 文档仓库的一个分支,如[开始贡献](/docs/contribute/start/)中所述。 +{{% /capture %}} + +{{% capture steps %}} + + + +## 选择页面类型 + + + +当你准备写一个新的主题时,考虑一下最适合你的内容的页面类型: + + + + + + + + + + + + + + + + + + + + +
概念每个概念页面负责解释 Kubernetes 的某方面。例如,概念页面可以描述 Kubernetes Deployment 对象,并解释当部署、扩展和更新时,它作为应用程序所扮演的角色。一般来说,概念页面不包括步骤序列,而是提供任务或教程的链接。一个概念主题的示例,请参见 节点.
任务任务页面展示了如何完成单个任务。这样做的目的是给读者一系列步骤,让他们在阅读时能够真正做到这一点。任务页面可长可短,前提是它始终聚焦在一个区域。在任务页面中,可以将简短的解释与要执行的步骤混合在一起,但如果需要提供冗长的解释,则应在概念主题中进行。相关联的任务和概念主题可以相互链接。一个简短的任务页面的实例,请参见 配置一个使用卷进行存储的 Pod. 一个较长的任务页面的实例,请参见 配置活动性和就绪性探测器
教程教程页面展示了如何实现将几个 Kubernetes 特性联系在一起的目标。教程可能提供一些步骤序列,读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如,教程可以提供代码示例的演练。教程可以包括对 Kubernetes 几个关联特性的简要解释,但应该链接到相关概念主题,以便深入解释各个特性。
+ + + +为每个新页面使用模板。每种页面类型都有一个[模板](/docs/contribute/style/page-templates/)可以在编写主题时使用。使用模板有助于确保给定类型主题之间的一致性。 + + + +## 选择标题和文件名 + + + +选择一个标题,标题中包含了要通过搜索引擎要查找的关键字。创建一个文件名,使用标题中由连字符分隔的单词。例如,标题为[使用 HTTP 代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) 的主题的文件名为 `http-proxy-access-api.md`。你不需要在文件名中加上 "kubernetes",因为 "kubernetes" 已经在主题的 URL 中了,例如: + + /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + + + +## 在页面头部添加主题标题 + + + +在你的主题中,在[页面头部](https://jekyllrb.com/docs/frontmatter/)设置一个 `title` 字段。页面头部是位于页面顶部三条虚线之间的 YAML 块。下面是一个例子: + + + + --- + title: 使用 HTTP 代理访问 Kubernetes API + --- + + + +## 选择目录 + + + +根据页面类型,将新文件放入其中一个子目录中: + +* /content/en/docs/tasks/ +* /content/en/docs/tutorials/ +* /content/en/docs/concepts/ + + + +你可以将文件放在现有的子目录中,也可以创建一个新的子目录。 + + + +## 将主题放在目录中 + + + +目录是使用文档源的目录结构动态构建的。`/content/en/docs/` 下的顶层目录创建顶层导航,它和子目录在目录中都有条目。 + + + +每个子目录都有一个 `_index.md` 文件,它表示指定子目录内容的主页面。`_index.md` 文件不需要模板。它可以包含有关子目录中主题的概述内容。 + + + +默认情况下,目录中的其他文件按字母顺序排序。这几乎不是最好的顺序。要控制子目录中主题的相对排序,请将页面头部的键 `weight:` 设置为整数。通常我们使用10的倍数,添加后续主题时权重值递增。例如,权重为 `10` 的主题将位于权重为 `20` 的主题之前。 + + + +## 在主题中嵌入代码 + + + +如果你想在主题中包含一些代码,可以直接使用标记代码块语法将代码嵌入到文件中。建议用于以下情况(并非详尽列表): + + + +- 代码显示来自命令的输出,例如 `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 文件。 + + + +添加新的独立示例文件(如 YAML 文件)时,将代码放在 `/examples/` 的某个子目录中,其中 `` 是该主题的语言。在主题文件中使用 `codenew` 短代码: + +
{{< codenew file="<RELPATH>/my-example-yaml>" >}}
+ + + +`` 是要引用的文件的路径,相对于 `examples` 目录。以下 Hugo 短代码引用了位于 `/content/en/examples/pods/storage/gce-volume.yaml` 的 YAML 文件。 + +```none +{{}} +``` + +{{< note >}} + + +要展示上述示例中的原始 Hugo 短代码并避免 Hugo 对其进行解释,请直接在 `<` 字符之后和 `>` 字符之前使用 C 样式注释。请查看此页面的代码。 +{{< /note >}} + + + +## 显示如何从配置文件创建 API 对象 + + + +如果需要演示如何基于配置文件创建 API 对象,请将配置文件放在 `/examples` 下的某个子目录中。 + + + +在主题中展示以下命令: + +``` +kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml +``` + +{{< note >}} + + +将新的 YAML 文件添加到 `/examples` 目录时,请确保该文件也在 `/examples_test.go` 文件中被引用。当提交拉取请求时,网站的 Travis CI 会自动运行此测试用例,以确保所有示例都通过测试。 +{{< /note >}} + + + +有关使用此技术的主题的示例,请参见[运行单实例有状态的应用](/docs/tutorials/stateful-application/run-stateful-application/)。 + + + +## 向主题添加镜像 + + + +将镜像文件放入 `/images` 目录。首选的镜像格式是 SVG。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +* 学习[使用页面模板](/docs/home/contribute/page-templates/)。 +* 学习[展示你的修改](/docs/home/contribute/stage-documentation-changes/)。 +* 学习[创建一个拉取请求](/docs/home/contribute/create-pull-request/)。 +{{% /capture %}} diff --git a/content/zh/docs/doc-contributor-tools/README.md b/content/zh/docs/doc-contributor-tools/README.md new file mode 100644 index 0000000000..fe0e37a2c7 --- /dev/null +++ b/content/zh/docs/doc-contributor-tools/README.md @@ -0,0 +1,7 @@ +Kubernetes 文档贡献者的工具。 查看子目录内的 `README.md` 文件以获取更多信息。 + + + diff --git a/content/zh/docs/doc-contributor-tools/snippets/README.md b/content/zh/docs/doc-contributor-tools/snippets/README.md new file mode 100644 index 0000000000..4058cbd4b6 --- /dev/null +++ b/content/zh/docs/doc-contributor-tools/snippets/README.md @@ -0,0 +1,84 @@ + +# Atom 的代码段 + + + +代码段就是可以插入到编辑器中的一段文本,可以节省键入时间,减少语法错误。 +`atom-snippets.cson` 文件中所提供的代码段只用于在 Atom 中的 Markdown 文件。 + + +## 安装 + + + +将 `atom-snippets.cson` 文件中的内容复制到现有的`~/.atom/snippets.cson` 之中。 +**不要替换现有的文件。** + + +不需要重启 Atom。 + + +## 使用 + + + +浏览一遍 `atom-snippets.cson` 文件,记下代码段的标题和 `prefix`。 + + + +你可以使用以下任意一种方式来触发相应的代码段: +- 键入代码段的`prefix`,按下 `` 键 +- 在 **Packages / Snippets / Available** 中搜索代码段的标题 + + + +例如,打开一个 Markdown 文件,键入 `anote`,按下 ``。 +就会插入一段带有正确的 Hugo 短代码的空注释。 + + + +代码段可以插入一行或多行文本。一些代码行都设有预留值。想要切换到下一个预留值,再按一次`` 键即可。 + + + +一些代码段只会插入部分格式的 Markdown 或 Hugo 语法。 +例如,`coverview` 只会插入一个概念概览的开始标签,而`cclose`则会插入一个结束标签。 +这是因为每类 capture 都需要一个 capture-close 标签。 + + +## 使用代码段创建新的话题 + + +从空白文件中,创建一个新的概念,任务或者教程,使用以下的代码段: + +- `newconcept` +- `newtask` +- `newtutorial` + + +预设文本包含其中。 + + +## 提交新的代码段 + + + +1. 本地开发代码段,验证是否有效。 +2. 将代码单复制到 Github 的 `atom-snippets.cson` 文件中。 +提交 pull request,邀请 Kubernetes Slack `#sig-docs` 中的另外一名 Atom 用户进行审查。 diff --git a/content/zh/docs/getting-started-guides/_index.md b/content/zh/docs/getting-started-guides/_index.md new file mode 100755 index 0000000000..e2e9a092ea --- /dev/null +++ b/content/zh/docs/getting-started-guides/_index.md @@ -0,0 +1,11 @@ +--- +title: "独立解决方案" +weight: 50 +--- + + diff --git a/content/zh/docs/getting-started-guides/alternatives.md b/content/zh/docs/getting-started-guides/alternatives.md new file mode 100644 index 0000000000..36b4755d67 --- /dev/null +++ b/content/zh/docs/getting-started-guides/alternatives.md @@ -0,0 +1,22 @@ +--- +title: 弃用的替代品 +--- + + +# *停止。这些指南已被[Minikube](../minikube/)所取代,这里列出它们只是为了保持完整性。* + + +* [使用 Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md) +* *更高级的:* [直接使用 Kubernetes 原始二进制程序(仅限 Linux 系统)](https://git.k8s.io/community/contributors/devel/running-locally.md) + \ No newline at end of file diff --git a/content/zh/docs/getting-started-guides/fedora/fedora_manual_config.md b/content/zh/docs/getting-started-guides/fedora/fedora_manual_config.md new file mode 100644 index 0000000000..596c87f683 --- /dev/null +++ b/content/zh/docs/getting-started-guides/fedora/fedora_manual_config.md @@ -0,0 +1,345 @@ +--- +reviewers: +- aveshagarwal +- eparis +- thockin +title: Fedora (单节点) +--- + + + +{{< toc >}} + + + +## 前提条件 + + + +1. 您需要两台或更多机器安装 Fedora。这些机器可以是裸机,也可以是虚拟机。 + +## 说明 + +这是 Fedora 的入门指南。配置手工打造,因而需要了解所有底层软件包/服务/端口等等。 + +本指南只能使一个节点(以前的 minion)工作。多个节点需要在 Kubernetes 之外完成功能性网络配置。尽管额外的 Kubernetes 配置需求是显而易见的。 + +Kubernetes 包提供了一些服务:kube-apiserver、kube-scheduler、kube-control -manager、kubelet、kube-proxy。这些服务由 systemd 管理,配置位于中心位置:`/etc/kubernetes`。 +我们将打破主机之间的服务。第一个主机,fed-master,将是 Kubernetes 主节点。该主节点将运行 kube-apiserver、kube-control-manager 和 kube-scheduler。 +此外,主服务器还将运行 *etcd* (如果 *etcd* 运行在不同的主机上就不需要了,但是本指南假设 *etcd* 和 Kubernetes 主服务器在同一主机上运行)。剩下的主机,fed-node 将是节点并运行 kubelet、proxy 和 docker。 + + + + +**系统信息:** + +主机: + +```conf +fed-master = 192.168.121.9 +fed-node = 192.168.121.65 +``` + + + +**准备主机:** + +* 在所有主机(fed-{master,node})上安装 Kubernetes 。这同时也会安装 docker。接着在 fed-master 上安装 etcd。本指南已经通过 Kubernetes-0.18 及更高版本的测试。 +* 在使用 RHEL 7.2 的 AWS EC2 上运行时,您需要通过编辑 `/etc/yum.repos.d/redhat-rhui.repo` 和更改 `enable=0to` 为 `enable=1` 来为 yum 启用 “extras” 仓库。 + +```shell +dnf -y install kubernetes +``` + + + +* 安装 etcd + +```shell +dnf -y install etcd +``` + + +* 将主机和节点添加到所有机器上的 `/etc/hosts` (如果主机名已经在 DNS 中,则不需要)。通过使用 ping 等实用程序,确保 fed-master 和 fed-node 之间的通信工作正常。 + + +```shell +echo "192.168.121.9 fed-master +192.168.121.65 fed-node" >> /etc/hosts +``` + + + +* 编辑 `/etc/kubernetes/config` (在所有主机上应该是相同的)来设置主服务器的名称: + +```shell +# 逗号分隔的 etcd 群集中的节点列表 +KUBE_MASTER="--master=http://fed-master:8080" +``` + + + +* 禁用主节点和子节点上的防火墙,因为 Docker 与其他防火墙规则管理器不兼容。请注意,默认的 Fedora Server 安装中不存在 iptables.service。 + +```shell +systemctl mask firewalld.service +systemctl stop firewalld.service + +systemctl disable iptables.service +systemctl stop iptables.service +``` + + + +**在主服务器上配置 Kubernetes 服务。** + +* 编辑 `/etc/kubernetes/apiserver`,包含以下内容。`service-cluster-ip-range` 的 IP 地址必须是未使用的地址块,同时也不能在其他任何地方使用。它们不需要路由或分配给任何东西。 + + + +```shell +# 本地服务器上所要监听的地址。 +KUBE_API_ADDRESS="--address=0.0.0.0" + +# 逗号在 ETCD 集群分离节点列表 +KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379" + +# 地址范围内使用的服务 +KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" + +# 添加你自己的! +KUBE_API_ARGS="" +``` + + + +* 编辑 `/etc/etcd/etcd.conf` 让 etcd 监听所有可用的 IP 地址,而不仅仅是 127.0.0.1。如果没有这样做,您可能会看到一个错误,例如 "connection refused"。 + +```shell +ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" +``` + + + +* 在主节点上启动适当的服务: + +```shell +for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + + + +**在节点上配置 Kubernetes 服务** + +***我们需要在节点上配置 kubelet。*** + +* 编辑 `/etc/kubernetes/kubelet`,加入以下内容: + + + + + +```shell +### +# Kubernetes kubelet(节点)的配置 + +# info 服务器要服务的地址(设置为 0.0.0.0 或 "" 用于所有接口) +KUBELET_ADDRESS="--address=0.0.0.0" + +# 可以留空,使用实际主机名 +KUBELET_HOSTNAME="--hostname-override=fed-node" + +# api-server 的位置 +KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml" + +``` + + + +* 编辑 `/etc/kubernetes/master-kubeconfig.yaml` 文件,添加以下信息: + +```yaml +kind: Config +clusters: +- name: local + cluster: + server: http://fed-master:8080 +users: +- name: kubelet +contexts: +- context: + cluster: local + user: kubelet + name: kubelet-context +current-context: kubelet-context +``` + + + +* 在节点(fed-node)上启动适当的服务。 + +```shell +for SERVICES in kube-proxy kubelet docker; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + + +* 检查以确保集群在 fed-master 上可以看到 fed-node,并且它的状态更改为 _Ready_。 + +```shell +kubectl get nodes +NAME STATUS AGE VERSION +fed-node Ready 4h +``` + + + +* 删除节点: + +要从 Kubernetes 集群中删除 _fed-node_,应该在 fed-master 上运行以下命令(这只是演示用): + + +```shell +kubectl delete -f ./node.json +``` + + + +*到此为止!* + +**集群应该正在运行!创建测试 pod。** + +## 支持级别 + + + +IaaS 供应商 | 配置管理 | 操作系统| 网络 | 文档 | 合规 | 支持级别 + +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | custom | Fedora | _none_ | [文档](/docs/getting-started-guides/fedora/fedora_manual_config) | | 项目 + +有关所有解决方案的支持级别信息,请参见[解决方案表](/docs/getting-started-guides/#table-of-solutions)。 + + diff --git a/content/zh/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/content/zh/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md new file mode 100644 index 0000000000..634167ccc4 --- /dev/null +++ b/content/zh/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md @@ -0,0 +1,332 @@ +--- +reviewers: +- dchen1107 +- erictune +- thockin +title: Fedora (多节点) +--- + + + +{{< toc >}} + + +本文档描述了如何在多个主机上部署 Kubernetes 来建立一个多节点集群和 flannel 网络。遵循 fedora 入门指南设置 1 个主节点 (fed-master) + 和 2 个或更多节点。确保所有节点具有不同的名称(fed-node1、fed-node2 等等)和标签(fed-node1-label、fed-node2-label 等等),以避免 +任何冲突。还要确保 Kubernetes 主节点主机正在运行 etcd、kube-controller-manager、kube-scheduler 和 kube-apiserver 服务,节点正在 + 运行 docker、kube-proxy 和 kubelet 服务。现在在 Kubernetes 节点上安装 flannel。每个节点上的 flannel 配置 docker 使用的 overlay 网络。 + Flannel 在每个节点上运行,以设置一个唯一的 class-C 容器网络。 + + + +## 前提条件 + + +安装 Fedora 您需要两台或更多机器。 + + + +## 主节点设置 + + + +**在 Kubernetes 主节点上执行以下命令** + +* 在您当前的目录上的 fed-master 中通过创建一个 `flannel-config.json` 来配置 flannel。Flannel 在其他 overlay 网络后端选项中提供 udp 和 vxlan 。在本指南中,我们选择基于内核的 vxlan 后端。json 的内容为: + +```json +{ + "Network": "18.16.0.0/16", + "SubnetLen": 24, + "Backend": { + "Type": "vxlan", + "VNI": 1 + } +} +``` + +{{< note >}} + + +选择一个不在公共 IP 地址范围内的 IP 范围。 + +{{< /note >}} + + +将配置添加到 fed-master 上的 etcd 服务器。 + +```shell +etcdctl set /coreos.com/network/config < flannel-config.json +``` + + + +* 验证 fed-master 上的 etcd 服务器中是否存在该密钥。 + +```shell +etcdctl get /coreos.com/network/config +``` + + + +## 节点设置 + + + +**在所有 Kubernetes 节点上执行以下命令** + + + +安装 flannel 包 + +```shell +# dnf -y install flannel +``` + + + +编辑 flannel 配置文件 /etc/sysconfig/flanneld,如下所示: + + + +```shell +# Flanneld 配置选项 + +# etcd url 位置,将此指向 etcd 运行的服务器 +FLANNEL_ETCD="http://fed-master:2379" + +# etcd 配置的键。这是 flannel 查询的配置键 +# 用于地址范围分配 +FLANNEL_ETCD_KEY="/coreos.com/network" + +# 您想要传递的任何附加选项 +FLANNEL_OPTIONS="" +``` + +{{< note >}} + + +默认情况下,flannel 使用默认路由的接口。如果您有多个接口并且想要使用默认路由以外的接口,则可以将 "-iface=" 添加到 FLANNEL_OPTIONS。有关其他选项,请在命令行上运行 `flanneld --help`。 + +{{< /note >}} + + +启用 flannel 服务。 + +```shell +systemctl enable flanneld +``` + + +如果 docker 没有运行,那么启动 flannel 服务就足够了,跳过下一步。 + +```shell +systemctl start flanneld +``` + + +如果 docker 已经运行,则停止 docker,删除 docker bridge(docker0),启动 flanneld 并重新启动 docker,如下所示。另一种方法是重启系统(systemctl reboot)。 + +```shell +systemctl stop docker +ip link delete docker0 +systemctl start flanneld +systemctl start docker +``` + + + +## 测试集群和 flannel 配置 + + +现在检查节点上的接口。请注意,现在有一个 flannel.1 接口,docker0 和 flannel.1 接口的 ip 地址在同一个网络中。您会注意到 docker0 在上面配置的 IP 范围之外的每个 Kubernetes 节点上分配了一个子网(18.16.29.0/24,如下所示)。 正常运行的输出应如下所示: + + +```shell +# ip -4 a|grep inet + inet 127.0.0.1/8 scope host lo + inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0 + inet 18.16.29.0/16 scope global flannel.1 + inet 18.16.29.1/24 scope global docker0 +``` + + +从集群中的任何节点,通过 curl 向 etcd 服务器发出查询来检查集群成员(仅显示部分输出 `grep -E "\{|\}|key|value`)。如果您设置了 1 个主节点和 3 个节点集群,您应该会看到每个节点都有一个块,显示分配给它们的子网。您可以通过输出中列出的 MAC 地址(VtepMAC)和 IP 地址(公共 IP) 将这些子网关联到每个节点。 + +```shell +curl -s http://fed-master:2379/v2/keys/coreos.com/network/subnets | python -mjson.tool +``` + +```json +{ + "node": { + "key": "/coreos.com/network/subnets", + { + "key": "/coreos.com/network/subnets/18.16.29.0-24", + "value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}" + }, + { + "key": "/coreos.com/network/subnets/18.16.83.0-24", + "value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}" + }, + { + "key": "/coreos.com/network/subnets/18.16.90.0-24", + "value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}" + } + } +} +``` + + +从所有节点,查看 `/run/flannel/subnet.env` 文件。这个文件是由 flannel 自动生成的。 + +```shell +# cat /run/flannel/subnet.env +FLANNEL_SUBNET=18.16.29.1/24 +FLANNEL_MTU=1450 +FLANNEL_IPMASQ=false +``` + + +此时,我们在 Kubernetes 主节点上运行了 etcd,在 Kubernetes 节点上运行了 flannel / docker。接下来的步骤是测试跨主机容器通信,这将确认 docker 和 flannel 配置正确。 + + +在任意两个节点上发出以下命令: + +```shell +# docker run -it fedora:latest bash +bash-4.3# +``` + + +您将会进入容器中。安装 iproute 和 iputils 包来安装 ip 和 ping 实用程序。由于一个[错误](https://bugzilla.redhat.com/show_bug.cgi?id=1142311),需要修改 ping 二进制文件的功能来处理"操作不允许"错误。 + +```shell +bash-4.3# dnf -y install iproute iputils +bash-4.3# setcap cap_net_raw-ep /usr/bin/ping +``` + + +现在记下第一个节点上的 IP 地址: + +```shell +bash-4.3# ip -4 a l eth0 | grep inet + inet 18.16.29.4/24 scope global eth0 +``` + + +还要注意另一个节点上的 IP 地址: + +```shell +bash-4.3# ip a l eth0 | grep inet + inet 18.16.90.4/24 scope global eth0 +``` + + +现在从第一个节点 ping 到另一个节点: + +```shell +bash-4.3# ping 18.16.90.4 +PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data. +64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms +64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms +``` + + +现在,Kubernetes 多节点集群通过 flannel 设置 overlay 网络。 + + + +## 支持级别 + + + +IaaS 供应商 | 配置 管理 | 系统 | 网络 | 文档 | 标准 | 支持级别 +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) + + + diff --git a/content/zh/docs/getting-started-guides/ubuntu/_index.md b/content/zh/docs/getting-started-guides/ubuntu/_index.md new file mode 100644 index 0000000000..e3c8a54e9f --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/_index.md @@ -0,0 +1,140 @@ +--- +title: Ubuntu 上运行 Kubernetes +content_template: templates/concept +--- + + +{{% capture overview %}} + + +使用 Ubuntu 运行 Kubernetes 集群有多种方法。 这些页面阐释了如何在多种公共云、私有云和裸机的 Ubuntu 上部署 Kubernetes。 +{{% /capture %}} + +{{% capture body %}} + +## 官方 Ubuntu 指南 + +- [Kubernetes 的 Canonical 发行版](https://www.ubuntu.com/cloud/kubernetes) + +最新版 Kubernetes 上游二进制文件。 支持 AWS、GCE、Azure、Joyent、OpenStack、VMware、裸机和 localhost 部署。 + + +### 快速入门 + +[conjure-up](http://conjure-up.io/) 提供了在多种云和裸机的 Ubuntu 上部署 Kubernetes 的最快方法。它提供了用户友好的界面,提示您提供云凭据和配置选项 + +适用于 Ubuntu 16.04 及更高版本: + +``` +sudo snap install conjure-up --classic +# 如果您刚刚安装了 snap 工具,可能需要重新登录。 +conjure-up kubernetes +``` + + + +以及用于 macOS 的 Homebrew: + +``` +brew install conjure-up +conjure-up kubernetes +``` + + + +### 操作指南 + +这些是用户在生产中运行 Kubernetes 的更深入的指南: + + - [安装](/docs/getting-started-guides/ubuntu/installation/) + - [验证](/docs/getting-started-guides/ubuntu/validation/) + - [备份](/docs/getting-started-guides/ubuntu/backups/) + - [升级](/docs/getting-started-guides/ubuntu/upgrades/) + - [缩放](/docs/getting-started-guides/ubuntu/scaling/) + - [日志](/docs/getting-started-guides/ubuntu/logging/) + - [监控](/docs/getting-started-guides/ubuntu/monitoring/) + - [网络](/docs/getting-started-guides/ubuntu/networking/) + - [安全](/docs/getting-started-guides/ubuntu/security/) + - [存储](/docs/getting-started-guides/ubuntu/storage/) + - [故障排除](/docs/getting-started-guides/ubuntu/troubleshooting/) + - [退役](/docs/getting-started-guides/ubuntu/decommissioning/) + - [操作因素](/docs/getting-started-guides/ubuntu/operational-considerations/) + - [词汇表](/docs/getting-started-guides/ubuntu/glossary/) + + + + +## 第三方产品集成 + + - [Rancher](/docs/getting-started-guides/ubuntu/rancher/) + +## 开发者指南 + + - [Localhost 使用 LXD](/docs/getting-started-guides/ubuntu/local/) + + + +## 如何找到我们 + +我们通常关注以下 Slack 频道: + +- [kubernetes-users](https://kubernetes.slack.com/messages/kubernetes-users/) +- [kubernetes-novice](https://kubernetes.slack.com/messages/kubernetes-novice/) +- [sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/) +- [sig-cluster-ops](https://kubernetes.slack.com/messages/sig-cluster-ops/) +- [sig-onprem](https://kubernetes.slack.com/messages/sig-onprem/) + +而且我们会查看 Kubernetes 邮件列表。 +{{% /capture %}} + diff --git a/content/zh/docs/getting-started-guides/ubuntu/backups.md b/content/zh/docs/getting-started-guides/ubuntu/backups.md new file mode 100644 index 0000000000..7fa1213a5d --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/backups.md @@ -0,0 +1,189 @@ +--- +title: 备份 +content_template: templates/task +--- + +{{% capture overview %}} + + +Kubernetes 集群的状态信息保存在 etcd 数据库中。 +本文将要展示如何对 Canonical 发行版的 Kubernetes 中所带有的 etcd 进行备份和恢复。 +至于如何对通常保存在持久卷上的应用数据进行备份,超出了本文的讨论范围。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +本文假设您有一个 Juju 部署的集群。 +{{% /capture %}} + +{{% capture steps %}} + +## 快照 etcd 中的数据 + + + +etcd charm 的 `snapshot` 操作能够让操作员给正在运行的集群数据建立快照,快照数据可用于复制、备份或者迁移到一个新的集群中。 + + juju run-action etcd/0 snapshot + +这条命令会在 `/home/ubuntu/etcd-snapshots` 默认路径下建立一个快照。 + + +## 恢复 etcd 数据 + + + +etcd charm 能够通过 `restore` 操作从一个集群数据快照中恢复集群数据。 +这里有些注意事项,而且是恢复集群的唯一办法:集群当前只能有一个成员。 +所以最好是使用 etcd charm 来部署一个新的集群,而不必添加任何新的单元。 + +``` +juju deploy etcd new-etcd +``` + + +上面的命令将会部署一个单独的 etcd 单元,'new-etcd'。 + +``` +juju run-action etcd/0 restore target=/mnt/etcd-backups +``` + + + +当恢复操作完成后,评估一下集群的健康状态。如果集群运行良好,就可以按照您的需求来扩展应用程序规模。 + +- **参数** target: 保存现有数据的目的路径。 +- **参数** skip-backup: 不要备份任何现有的数据。 + + + + +## 迁移 etcd 集群 +通过使用上述的 `snapshot` 和 `restore` 操作,就能很容易地迁移 etcd 集群。 + + +**第一步:** 给现有的集群建立快照。这个已经封装在 `snapshot` 操作中。 + +``` +juju run-action etcd/0 snapshot +``` + + +结果: + +``` +Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580c +``` + + +**第二步:** 检查操作状态,以便您能抓取快照并且验证校验和。 +您可以直接使用 `copy.cmd` 中的结果来下载您刚刚创建的快照数据,`copy.cmd` 中的结果可以直接复制/粘贴使用。 + + +从节点上下载刚刚创建的快照数据并且验证 sha256sum 校验和 + +``` +juju show-action-output b46d5d6f-5625-4320-8cda-b611c6ae580c +``` + + +结果: + +``` +results: + copy: + cmd: juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz + . + snapshot: + path: /home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz + sha256: 1dea04627812397c51ee87e313433f3102f617a9cab1d1b79698323f6459953d + size: 68K +status: completed +``` + + +将数据快照拷到本地,然后检查 sha256sum。 + +``` +juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz . +sha256sum etcd-snapshot-2016-11-09-02.41.47.tar.gz +``` + + +**第三步:** 部署新的集群 leader 节点,并加载快照数据: + +``` +juju deploy etcd new-etcd --resource snapshot=./etcd-snapshot-2016-11-09-02.41.47.tar.gz +``` + + +**第四步:** 使用在第三步中的快照数据来重新初始化 master: + +``` +juju run-action new-etcd/0 restore +``` + +{{% /capture %}} + +{{% capture discussion %}} + +## 已知的局限 + + +#### 丢失 PKI 警告 + + + +如果销毁了 leader - 在状态栏通过 `*` 来标识,那么所有的 TLS pki 警告都将会丢失。 +在请求和注册证书的单元之外,将不会有 PKI 迁移发生。 + +{{< caution >}} + + +**警告:** 如果误管理这项配置,将会导致您无法从外部访问集群, +并且很可能会破坏现有的部署,出现 x509 证书验证相关的异常问题,这些都会对服务器和客户端造成影响。 + +{{< /caution >}} + + +#### 在一个已经扩展的集群上进行快照数据恢复 + + + +在一个已经扩展的集群上进行快照数据恢复,将会导致集群损坏。 +etcd 在节点启动时开始集群管理,并且将状态保存在 etcd 中。 +在快照数据的恢复阶段,会初始化一个新的集群 ID,并且丢弃其它 peer 节点以保证快照数据的恢复。 +请严格遵照上述集群迁移中的恢复操作来进行操作。 + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/decommissioning.md b/content/zh/docs/getting-started-guides/ubuntu/decommissioning.md new file mode 100644 index 0000000000..9956c0f84c --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/decommissioning.md @@ -0,0 +1,103 @@ +--- +title: 销毁 +content_template: templates/task +--- + + + + +{{% capture overview %}} + +本页将展示如何销毁一个集群。 +{{% /capture %}} + + +{{% capture prerequisites %}} + +本页假设有一个使用 Juju 部署的、正在运行的集群。 + +{{< warning >}} + +当您到达这一步时,您应该已经对集群的相关内容进行了备份;这部分将彻底销毁一个集群。 +{{< /warning >}} + +{{% /capture %}} + +{{% capture steps %}} + +## 破坏 Juju 模型 + + + +建议使用各自的模型来相应地部署 Kubernetes 集群, +以便各个环境之间能够界限分明。 +如果想要删除一个集群,首先需要通过 `juju list-models` 命令找到其对应的模型。 +控制器为其自身预留了 `admin` 这个模型。 +如果没有命名模型,则模型名可能会显示为 `default`。 + +``` +$ juju list-models +Controller: aws-us-east-2 + +Model Cloud/Region Status Machines Cores Access Last connection +controller aws/us-east-2 available 1 2 admin just now +my-kubernetes-cluster* aws/us-east-2 available 12 22 admin 2 minutes ago +``` + + +销毁模型,模型内的集群也随之被销毁: + + juju destroy-model my-kubernetes-cluster + +``` +$ juju destroy-model my-kubernetes-cluster +WARNING! This command will destroy the "my-kubernetes-cluster" model. +This includes all machines, applications, data and other resources. + +Continue [y/N]? y +Destroying model +Waiting on model to be removed, 12 machine(s), 10 application(s)... +Waiting on model to be removed, 12 machine(s), 9 application(s)... +Waiting on model to be removed, 12 machine(s), 8 application(s)... +Waiting on model to be removed, 12 machine(s), 7 application(s)... +Waiting on model to be removed, 12 machine(s)... +Waiting on model to be removed... +$ +``` + + +这将会彻底破坏并销毁所有节点。 +运行 `juju status` 命令可以确认所有节点是否已经被销毁。 + + +如果使用的是公有云,命令将会终止所有的实例。 +如果使用的是 MAAS 裸机,命令将会释放所有的节点,(可能)清空磁盘,关闭机器, +然后将节点资源返回到可用的机器池中。 + + +## 清理控制器 + + +如果控制器没有其它的用途,还需要删除控制器实例: + +``` +$ juju list-controllers +Use --refresh flag with this command to see the latest information. + +Controller Model User Access Cloud/Region Models Machines HA Version +aws-us-east-2* - admin superuser aws/us-east-2 2 1 none 2.0.1 + +$ juju destroy-controller aws-us-east-2 +WARNING! This command will destroy the "aws-us-east-2" controller. +This includes all machines, applications, data and other resources. + +Continue? (y/N):y +Destroying controller +Waiting for hosted model resources to be reclaimed +All hosted models reclaimed, cleaning up controller machines +$ +``` +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/glossary.md b/content/zh/docs/getting-started-guides/ubuntu/glossary.md new file mode 100644 index 0000000000..43528245ab --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/glossary.md @@ -0,0 +1,50 @@ +--- +title: 词汇与术语 +content_template: templates/concept +--- + + + + + +{{%capture overview%}} +本页介绍了用 Juju 部署 Kubernetes 时使用的一些术语。 +{{%/ capture%}} + +{{%capture body%}} + + + +**controller** - 云环境的管理节点。通常,每个域(Region)都有一个 controller,在高可用环境中有更多 controller。每个 controller 负责管理给定环境中的所有后续 model。Controller 中包含 Juju API 服务器及其底层数据库。 + +**model** - 定义 Deployments 的一系列 charms 及其关系的集合。model 之中包括 machine 和更小的 unit。每个 controller 可以托管多个 model。出于管理和隔离的原因,建议将 Kubernetes 集群分成独立的 model。 + +**charm** - 每个 charm 对应一个 Service 的定义,包括其元数据、与其他服务间的依赖关系、所需的包和应用管理逻辑。 +其中包含部署 Kubernetes 集群的所有操作知识。内置的 charms 例子有 `kubernetes-core`、`easyrsa`、`flannel` 和 `etcd` 等。 + +**unit** - 对应某 Service 的给定实例。每个 unit 可能会也可能不会耗尽某指定机器上的所有资源。多个 unit 可能部署在同一台机器上。例如,您可能在一台机器上运行 `kubernetes-worker` 和 `etcd` 以及 `easyrsa` unit,但它们是基于不同服务的三个独立的 unit。 + +**machine** - 物理节点,可以是裸机节点,也可以是云提供商提供的虚拟机。 +{{%/ capture%}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/installation.md b/content/zh/docs/getting-started-guides/ubuntu/installation.md new file mode 100644 index 0000000000..93d61d7424 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/installation.md @@ -0,0 +1,542 @@ +--- +reviewers: +- caesarxuchao +- erictune +title: 用 Juju 搭建 Kubernetes +content_template: templates/task +--- + + + + + +{% capture overview %} +Ubuntu 16.04 已公开 [Kubernetes 的 Canonical 发行版 ](https://www.ubuntu.com/cloud/kubernetes), 一套为生产环境设计的 Kubernetes 上游版本。本文将为您演示如何部署集群。 +{% endcapture %} + + + +{{% capture prerequisites %}} +- 一个可用的 [Juju 客户端](https://jujucharms.com/docs/2.3/reference-install);不一定要是 Linux 机器,也可以是 Windows 或 OSX。 +- 一个[受支持的云](#cloud-compatibility)。 + - 裸机部署可以通过 [MAAS](http://maas.io) 实现。 配置指南参见 [MAAS 文档](http://maas.io/docs/)。 + - OpenStack 部署目前只在 Icehouse 及更新版本上测试通过。 +- 下面任一一种选项: + - 可以网络访问以下站点 + - *.jujucharms.com + - gcr.io + - github.com + - 访问 Ubuntu 镜像源(公共的或私有的) + - 通过[这些](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Running-CDK-in-a-restricted-environment)步骤准备好离线部署。 +{{% /capture %}} + + + +{{% capture steps %}} +## 部署概述 + +开箱即用的部署由以下组件构成,部署在 9 台机器上: + +- Kubernetes (自动化部署,运营及伸缩) + - 具有一个主节点和三个工作节点的四节点 Kubernetes 集群。 + - 使用 TLS 实现组件间的安全通信。 + - Flannel 软件定义网络 (SDN) 插件 + - 一个负载均衡器以实现 kubernetes-master 的高可用 (实验阶段) + - 可选的 Ingress 控制器(在工作节点上) + - 可选的 Dashboard 插件(在主节点上),包含实现集群监控的 Heapster 插件 +- EasyRSA + - 扮演证书授权机构的角色,向集群中的组件提供自签名证书 +- ETCD (分布式键值存储) + - 三节点的集群达到高可靠性。 + + + +Juju Kubernetes 工作由 Canonical Ltd(https://www.canonical.com/) 的 Big Software 团队整理,欢迎对我们的工作给出反馈意见。 +如果发现任何问题,请提交相应的 [Issue 到跟踪系统](https://github.com/juju-solutions/bundle-canonical-kubernetes),以便我们解决。 + + + +## 支持级别 + +IaaS 提供商 | 配置管理 | 系统 | 网络 | 文档 | 符合 | 支持级别 +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Amazon Web Services (AWS) | Juju | Ubuntu | flannel, calico* | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +OpenStack | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +Microsoft Azure | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +Google Compute Engine (GCE) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +Joyent | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +Rackspace | Juju | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +VMWare vSphere | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) +Bare Metal (MAAS) | Juju | Ubuntu | flannel, calico | [docs](/docs/getting-started-guides/ubuntu) | | [Commercial](https://ubuntu.com/cloud/kubernetes), [Community](https://github.com/juju-solutions/bundle-kubernetes-core) + + + + +有关所有解决方案的支持级别信息,请参见[解决方案表](/docs/getting-started-guides/#table-of-solutions)。 + +## 安装选项 + +可以通过下面任一一种方式启动集群:[conjure-up](#conjure-up) or [juju 部署](#juju-deploy)。Conjure-up 只是一个对 juju 的简易封装,简化了安装的过程。正因为如此,这也是推荐的安装方法。 + +可以在 [众多不同的公有云](#cloud-compatibility),私有 OpenStack 云,或者是原始的裸机集群上部署集群软件。通过 [MAAS](http://maas.io) 实现裸机部署。 + +## Conjure-up + +通过 conjure-up 来安装 Kubernetes, 只需要运行下面的命令,然后根据提示做选择: + +``` +sudo snap install conjure-up --classic +conjure-up kubernetes +``` + +## Juju 部署 + +### 配置 Juju 使用您的云提供商 + +确定所要部署的云之后,按照[云安装界面](https://jujucharms.com/docs/devel/getting-started)来配置、部署到该云。 + +加载[云凭证](https://jujucharms.com/docs/2.3/credentials)来选择、使用相应的云。 + + + +在本例中 + +``` +juju add-credential aws +credential name: my_credentials +select auth-type [userpass, oauth, etc]: userpass +enter username: jorge +enter password: ******* +``` + +也可以通过 `juju autoload-credentials` 命令自动加载常用的云凭证,该命令将自动从每个云的默认文件和环境变量中导入凭据信息。 + + + +接下来,我们需要启动一个控制器来管理集群。您需要确定所要启动的云,地区以及控制器节点的名字: + +``` +juju update-clouds # 这个命令可以确保客户端上所有最新的区域是最新的 +juju bootstrap aws/us-east-2 +``` +或者,另外一个例子,这次是在 Azure 上: + +``` +juju bootstrap azure/westus2 +``` + + + +如果您看到下面的错误信息,很可能默认的 Azure VM (Standard D1 v2 [1 vcpu, 3.5 GB memory]) 并不在当前的 Azure 地区。 +``` +ERROR failed to bootstrap model: instance provisioning failed (Failed) +``` + + + + +您需要为部署到的每个云或区域分配一个控制器节点。更多信息参见[控制器文档](https://jujucharms.com/docs/2.3/controllers)。 + +请注意,每个控制器可以在给定的云或区域中管理多个 Kubernetes 集群。 + + + +## 启动 Kubernetes 集群 + +以下命令将部署 9-节点的初始集群。执行速度取决于您所要部署到的云的性能: + +``` +juju deploy canonical-kubernetes +``` + +执行完此命令后,云将启动实例并开始部署过程。 + + + +## 监控部署 + +`juju status` 命令提供集群中每个单元的信息。`watch -c juju status --color` 命令可以获取集群部署的实时状态。 +当所有的状态是绿色并且“空闲”时,表示集群处于待用状态: + + juju status + +输出结果: + +``` +Model Controller Cloud/Region Version SLA +conjure-canonical-kubern-f48 conjure-up-aws-650 aws/us-east-2 2.3.2 unsupported + +App Version Status Scale Charm Store Rev OS Notes +easyrsa 3.0.1 active 1 easyrsa jujucharms 27 ubuntu +etcd 2.3.8 active 3 etcd jujucharms 63 ubuntu +flannel 0.9.1 active 4 flannel jujucharms 40 ubuntu +kubeapi-load-balancer 1.10.3 active 1 kubeapi-load-balancer jujucharms 43 ubuntu exposed +kubernetes-master 1.9.3 active 1 kubernetes-master jujucharms 13 ubuntu +kubernetes-worker 1.9.3 active 3 kubernetes-worker jujucharms 81 ubuntu exposed + +Unit Workload Agent Machine Public address Ports Message +easyrsa/0* active idle 3 18.219.190.99 Certificate Authority connected. +etcd/0 active idle 5 18.219.56.23 2379/tcp Healthy with 3 known peers +etcd/1* active idle 0 18.219.212.151 2379/tcp Healthy with 3 known peers +etcd/2 active idle 6 13.59.240.210 2379/tcp Healthy with 3 known peers +kubeapi-load-balancer/0* active idle 1 18.222.61.65 443/tcp Loadbalancer ready. +kubernetes-master/0* active idle 4 18.219.105.220 6443/tcp Kubernetes master running. + flannel/3 active idle 18.219.105.220 Flannel subnet 10.1.78.1/24 +kubernetes-worker/0 active idle 2 18.219.221.98 80/tcp,443/tcp Kubernetes worker running. + flannel/1 active idle 18.219.221.98 Flannel subnet 10.1.38.1/24 +kubernetes-worker/1* active idle 7 18.219.249.103 80/tcp,443/tcp Kubernetes worker running. + flannel/2 active idle 18.219.249.103 Flannel subnet 10.1.68.1/24 +kubernetes-worker/2 active idle 8 52.15.89.16 80/tcp,443/tcp Kubernetes worker running. + flannel/0* active idle 52.15.89.16 Flannel subnet 10.1.73.1/24 + +Machine State DNS Inst id Series AZ Message +0 started 18.219.212.151 i-065eab4eabc691b25 xenial us-east-2a running +1 started 18.222.61.65 i-0b332955f028d6281 xenial us-east-2b running +2 started 18.219.221.98 i-0879ef1ed95b569bc xenial us-east-2a running +3 started 18.219.190.99 i-08a7b364fc008fc85 xenial us-east-2c running +4 started 18.219.105.220 i-0f92d3420b01085af xenial us-east-2a running +5 started 18.219.56.23 i-0271f6448cebae352 xenial us-east-2c running +6 started 13.59.240.210 i-0789ef5837e0669b3 xenial us-east-2b running +7 started 18.219.249.103 i-02f110b0ab042f7ac xenial us-east-2b running +8 started 52.15.89.16 i-086852bf1bee63d4e xenial us-east-2c running + +Relation provider Requirer Interface Type Message +easyrsa:client etcd:certificates tls-certificates regular +easyrsa:client kubeapi-load-balancer:certificates tls-certificates regular +easyrsa:client kubernetes-master:certificates tls-certificates regular +easyrsa:client kubernetes-worker:certificates tls-certificates regular +etcd:cluster etcd:cluster etcd peer +etcd:db flannel:etcd etcd regular +etcd:db kubernetes-master:etcd etcd regular +kubeapi-load-balancer:loadbalancer kubernetes-master:loadbalancer public-address regular +kubeapi-load-balancer:website kubernetes-worker:kube-api-endpoint http regular +kubernetes-master:cni flannel:cni kubernetes-cni subordinate +kubernetes-master:kube-api-endpoint kubeapi-load-balancer:apiserver http regular +kubernetes-master:kube-control kubernetes-worker:kube-control kube-control regular +kubernetes-worker:cni flannel:cni kubernetes-cni subordinate +``` + + + +## 与集群的交互 + +部署完集群后,您可以在任意一个 kubernetes-master 或 kubernetes-worker 节点取得集群的控制权。 + +如果您没有使用 conjure-up,那么您需要先将凭据和客户端程序下载到本地工作站上: + +创建 kubectl 配置信息目录。 + +``` +mkdir -p ~/.kube +``` + +将 kubeconfig 文件复制到默认位置。 + +``` +juju scp kubernetes-master/0:config ~/.kube/config +``` + + + +下一步是在本地机器上安装 kubectl 客户端。在 Ubuntu 上推荐的安装方式是使用 kubectl snap ([/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu](/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu))。 + +可以运行下面的命令便可以控制 kubernetes 集群了: + +``` +sudo snap install kubectl --classic +``` + +这条命令会安装和部署 kubectl 程序。安装完成后,您可能需要重启命令窗口(因为 $PATH 已经被更新)。 + + + +查询集群: + kubectl cluster-info + +输出结果: + +``` +Kubernetes master is running at https://52.15.104.227:443 +Heapster is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/heapster/proxy +KubeDNS is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/kube-dns/proxy +Grafana is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +InfluxDB is running at https://52.15.104.227:443/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy +``` + + + +## 为集群垂直扩容 + +需要更大的 Kubernetes 节点?通过使用 Juju 的**约束**,您可以轻松地请求到不同大小的云资源。 +通过 Juju 请求创建的任意系统,您都可以为它们增加 CPU 和内存(RAM)。 +这使您可以对 Kubernetes 集群进行调优以适应工作负载。 +藉由 bootstrap 命令的参数或使用独立的 `juju constraints` 命令都可以做到这点。详情参见[和机器相关的 Juju 文档](https://jujucharms.com/docs/2.3/charms-constraints) + + + +## 为集群集群水平扩容 + +需要更多的工作节点?只需添加一些 unit: + +```shell +juju add-unit kubernetes-worker +``` + +或者一次添加多个: + +```shell +juju add-unit -n3 kubernetes-worker +``` +您也可以为特定实例类型或者特定机器的设置约束。更多信息请参见[约束文档](https://jujucharms.com/docs/stable/reference-constraints)。 +接下来举一些例子。请注意,诸如 `cores` 和 `mem` 这样的通用约束在各云之间的可移植性是比较高的。 +在本例中,我们从 AWS 申请一个特定的实例类型: + +```shell +juju set-constraints kubernetes-worker instance-type=c4.large +juju add-unit kubernetes-worker +``` + +为提升键值存储的容错能力,您也可以扩展 etcd charm: + +```shell +juju add-unit -n3 etcd +``` + +强烈建议运行奇数个 unit 以支持法定人数票选。 + + + +## 销毁集群 + +如果您是使用 conjure-up 创建的集群,通过 `conjure-down` 便可以完成销毁过程。 +如果是直接使用的 juju,你可以通过销毁 juju 模型或控制器来销毁集群。 +使用 `juju switch` 命令获取当前控制器的名字: + +```shell +juju switch +juju destroy-controller $controllername --destroy-all-models +``` + +这将关闭并终止该云上所有正在运行的实例。 +{{% /capture %}} + +{{% capture discussion %}} + + + +{{% capture discussion %}} +## 更多信息 + +Ubuntu Kubernetes 的部署通过名为 charms 的开源运维工具实现,这类工具也称作运维即代码(Operations as Code)。 +这些 charms 以层的方式组装,从而使代码更小,更专注于 Kubernetes 及其组件的操作。 + +Kubernetes 的层和 Bundle 可以在 github.com 的 `kubernetes` 项目中找到: + +- [Bundle 的地址](https://git.k8s.io/kubernetes/cluster/juju/bundles) +- [Kubernetes charm 层的地址](https://git.k8s.io/kubernetes/cluster/juju/layers) +- [Canonical Kubernetes 主页](https://jujucharms.com/kubernetes) +- [主要的 issue tracker](https://github.com/juju-solutions/bundle-canonical-kubernetes) + +欢迎提供功能需求,错误报告,pull request和反馈意见。 +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/local.md b/content/zh/docs/getting-started-guides/ubuntu/local.md new file mode 100644 index 0000000000..1744114ae1 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/local.md @@ -0,0 +1,118 @@ +--- +title: 通过 LXD 实现 Kubernetes 本地开发 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +在本地运行 Kubernetes 比在公有云上部署和移除集群具有明显的开发优势,如更低的成本和更快的迭代。 +理想情况下,Kubernetes 开发人员可以在本地容器内产生所有必需的节点,并在提交新配置时测试它们。 +本文将展示如何将集群部署到本地机器的 LXD 容器上。 + +{{% /capture %}} + + + +在本地机器上使用 [LXD](https://linuxcontainers.org/lxd/) 的目的是为了模拟用户在云或裸机中部署的环境。每个节点都被视为一台机器,具有与生产环境相同的特性。 每个节点都是一个单独的容器,它在里面运行 Docker 容器和 `kubectl`(更多信息请参阅 [集群简介](/docs/tutorials/kubernetes-basics/cluster-intro/))。 + +{{% capture prerequisites %}} + + + +安装 [conjure-up](http://conjure-up.io/),这是一个用来部署大型软件的工具。 +将当前用户添加到 `lxd` 用户组中。 + +``` +sudo snap install conjure-up --classic +sudo usermod -a -G lxd $(whoami) +``` + + + +注意:如果 conjure-up 要求您在 LXD 上 "配置一个 ipv6 子网",请选择 NO。目前还不支持在 Juju/LXD 上使用 ipv6。 +{% endcapture %} + +{{% capture steps %}} + + + +## 部署 Kubernetes + + +通过以下命令启动部署: + + conjure-up kubernetes + + + +对于本教程,我们将会创建一个新的控制器 - 选择 `localhost` 云类型: + +![选择云类型](/images/docs/ubuntu/00-select-cloud.png) + + + +部署应用: + +![部署应用](/images/docs/ubuntu/01-deploy.png) + + + +等待 Juju 引导结束: + +![引导](/images/docs/ubuntu/02-bootstrap.png) + + + +等待应用被完全部署: + +![等待](/images/docs/ubuntu/03-waiting.png) + + + +执行最终的后处理步骤,来自动配置 Kubernetes 环境: + +![后处理](/images/docs/ubuntu/04-postprocessing.png) + + + +查看最终的摘要信息: + +![最终的摘要](/images/docs/ubuntu/05-final-summary.png) + + + +## 访问集群 + +您可以通过运行以下命令来访问 Kubernetes 集群: + + kubectl --kubeconfig=~/.kube/config + + +或者如果您已经运行过一次,它将创建一个新的配置文件,如摘要信息所示。 + + kubectl --kubeconfig=~/.kube/config.conjure-up + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/logging.md b/content/zh/docs/getting-started-guides/ubuntu/logging.md new file mode 100644 index 0000000000..3418820021 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/logging.md @@ -0,0 +1,79 @@ +--- +title: 日志 +content_template: templates/task +--- + + + +{{% capture overview %}} + +本文将说明日志在 Juju 部署的集群中是如何工作的。 +{{% /capture %}} + +{{% capture prerequisites %}} + +本文假设你已经有一个可用的 Juju 部署的集群。 +{{% /capture %}} + +{{% capture steps %}} + +## 代理日志 + + +`juju debug-log` 命令可以显示集群中每一个节点上运行的 Juju 代理所汇总的日志结果。 +它可以帮助确定为何某个节点没有被部署或者是处于错误的状态。这些代理日志被存放在每个节点的 `/var/lib/juju/agents` 路径下。 + + +更多信息参见[Juju 文档](https://jujucharms.com/docs/stable/troubleshooting-logs) + + + +## 管理日志级别 + + +Juju 中默认的日志级别是 model 级别。不过,你可以随时调整它: + +``` +juju add-model k8s-development --config logging-config='=DEBUG;unit=DEBUG' +``` + + +然后在你的生态环境下的 k8s 模型进行配置 + +``` +juju model-config -m k8s-production logging-config='=ERROR;unit=ERROR' +``` + + +另外,所有控制器上的 jujud 守护进程默认使用 debug 级别。如果想要移除这种行为,编辑控制器节点上的 ```/var/lib/juju/init/jujud-machine-0/exec-start.sh``` 文件并注释掉 ```--debug``` 选项。 + + +修改之后,如下所示: + +``` +#!/usr/bin/env bash + +# Set up logging. +touch '/var/log/juju/machine-0.log' +chown syslog:syslog '/var/log/juju/machine-0.log' +chmod 0600 '/var/log/juju/machine-0.log' +exec >> '/var/log/juju/machine-0.log' +exec 2>&1 + +# Run the script. +'/var/lib/juju/tools/machine-0/jujud' machine --data-dir '/var/lib/juju' --machine-id 0 # --debug +``` + + +然后运行下面的命令,重启服务: + +``` +sudo systemctl restart jujud-machine-0.service +``` + + +Juju 中更多和日志与其它模型设置相关的信息请参考[官方文档](https://jujucharms.com/docs/stable/models-config)。 +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/monitoring.md b/content/zh/docs/getting-started-guides/ubuntu/monitoring.md new file mode 100644 index 0000000000..8f437d55dd --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/monitoring.md @@ -0,0 +1,234 @@ +--- +title: 监控 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本文将介绍如何将不同的日志解决方案连到已经用 Juju 部署好的 Kubernetes 集群上。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +本文假设你有一个用 Juju 部署好了的 Kubernetes 集群。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 连接 Datadog + + + +Datadog 是一个 SaaS 方案,包含了对很多不同类型的应用集成的支持,例如,Kubernetes 和 etcd。 +在提供商业版本的同时,也支持通过如下方式免费使用。 +部署一个带有现成的 Databox 的 Kubernetes 集群: + +``` +juju deploy canonical-kubernetes-datadog +``` + + +### 安装 Datadog + + +首先, 从 Juju 的 Charm Store 下载部署最新版本的 Datadog : + +``` +juju deploy datadog +``` + + + +使用在 [Datadog dashboard]() 上的 api-key 来配置 Datadog。 +将 `XXXX` 配置为你的 API 密钥。 + +``` +juju configure datadog api-key=XXXX +``` + + + +最后, 将 `datadog` 绑定到需要监控的所有应用上。例如:kubernetes-master, kubernetes-worker, and etcd: + +``` +juju add-relation datadog kubernetes-worker +juju add-relation datadog kubernetes-master +juju add-relation datadog etcd +``` + + +## 连接 Elastic 栈 + + + +Elastic 栈,正规地说是 "ELK" 栈, 指的是 ElasticSearch 和日志收集,监控,dashboard 的套件. +部署带有现成的 elastic 栈的 Kubernetes 集群命令如下: + +``` +juju deploy canonical-kubernetes-elastic +``` + + +### 初装 ElasticSearch + + + +首先, 从 Juju 的 Charm store 下载、部署最新版本的 ElasticSearch, Kibana, Filebeat 和 Topbeat: + + + +命令行如下: + +``` +juju deploy beats-core +``` + + + +此外,如果你要定制部署,或手工安装,可使用以下命令: + +``` +juju deploy elasticsearch +juju deploy kibana +juju deploy filebeat +juju deploy topbeat + +juju add-relation elasticsearch kibana +juju add-relation elasticsearch topbeat +juju add-relation elasticsearch filebeat +``` + + + +最后将 filebeat 和 topbeat 连接到所要监控的应用上。 +例如:kubernetes-master 和 kubernetes-worker: + +``` +juju add-relation kubernetes-master topbeat +juju add-relation kubernetes-master filebeat +juju add-relation kubernetes-worker topbeat +juju add-relation kubernetes-worker filebeat +``` + + +### 已装 ElasticSearch 集群 + + + +如果已有一个 ElasticSearch 集群已经存在的情况下, +你可以使用下面的方式来连接和使用它而不是重新创建一个单独的新集群。 +首先部署 filebeat 和 topbeat 两个组件: + +``` +juju deploy filebeat +juju deploy topbeat +``` + + + +按照如下方式可配置 filebeat 和 topbeat 对接 ElasticSearch 集群, +将 `255.255.255.255` 替换成自己配置的IP。 + +``` +juju configure filebeat elasticsearch=255.255.255.255 +juju configure topbeat elasticsearch=255.255.255.255 +``` + + + +使用上面的命令,将 topbeat 和 filebeat 连接到需要监控的应用上。 + + + + +## 连接 Nagios + + + +Nagios 在每个节点上,使用 Nagions 远程执行插件协议 (NRPE 协议)作为代理 +来收集节点里和健康、应用相关的详细信息。 + + + +### 初装 Nagios + + + +首先, 从 Juju 的 Charm store 部署最新版本的 Nagois 和 NRPE: + +``` +juju deploy nagios +juju deploy nrpe +``` + + +将 Nagois 连接到 NRPE 上 + +``` +juju add-relation nagios nrpe +``` + + + +最后,将 NRPE 添加到所有需要部署的应用, +例如,`kubernetes-master`, `kubernetes-worker`, `etcd`, `easyrsa`, 和 `kubeapi-load-balancer`。 + +``` +juju add-relation nrpe kubernetes-master +juju add-relation nrpe kubernetes-worker +juju add-relation nrpe etcd +juju add-relation nrpe easyrsa +juju add-relation nrpe kubeapi-load-balancer +``` + + +### 已装 Nagios + + + +如果已经装有 Nagios,可以换用 `nrpe-external-master` charm 。 +这样可以提供配置选项将现有的、外部 Nagios 安装映射到 NRPE上。 +将 `255.255.255.255` 替换为 nagois 实例的 IP 地址。 + +``` +juju deploy nrpe-external-master +juju configure nrpe-external-master nagios_master=255.255.255.255 +``` + + + +配置完后,如上所示,连到 nrpe-external-master。 + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/networking.md b/content/zh/docs/getting-started-guides/ubuntu/networking.md new file mode 100644 index 0000000000..e713c53cd7 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/networking.md @@ -0,0 +1,92 @@ +--- +title: 网络 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +Kubernetes 支持[容器网络接口](https://github.com/containernetworking/cni)。 +这个网络插件架构允许你使用任何你喜欢的、对 Kubernetes 友好的 SDN。 +目前支持的插件是 Flannel 和 Canal。 + + +本页将展示集群中各个网络部分是如何工作,并且对它们进行相应的配置。 + +{{% /capture %}} +{{% capture prerequisites %}} + + +本页假设你有一个已经通过 Juju 部署、正在运行的集群。 + +{{< note >}} + +注意,如果你是通过 `conjure-up` 或者 CDK 软件包部署的集群,将不需要再手动部署 CNI 插件。 + +{{< /note >}} +{{% /capture %}} + + +{{% capture steps %}} + + + +CNI charms 在[子路径](https://jujucharms.com/docs/stable/authors-subordinate-applications)下。 +这些 charms 需要主 charm 实现 `kubernetes-cni` 接口,才能正常部署。 + +## Flannel + +``` +juju deploy flannel +juju add-relation flannel kubernetes-master +juju add-relation flannel kubernetes-worker +juju add-relation flannel etcd +``` + +## Canal + +``` +juju deploy canal +juju add-relation canal kubernetes-master +juju add-relation canal kubernetes-worker +juju add-relation canal etcd +``` + + +### 配置 + + + +**iface** 接口是用来配置 flannel 或 canal 的 SDN 绑定。 +如果属性为空字符串或未定义,程序将通过下面的命令行试图找出默认的网络适配器: + +```bash +$ route | grep default | head -n 1 | awk {'print $8'} +``` + + + +**cidr** 在用 etcd 进行网络设置时,用于配置 flannel 或 canal SDN 所要使用的网络地址范围。 +请确保这个网络地址范围在所要部署的 L2/L3 上不是在用状态, +因为如果没有选择一个好的 CIDR 范围来分配给 flannel,就会出现冲突或异常行为。 +同时也要保证 IP 地址范围足够大以支持未来可能会发生的集群扩容。 +A 类 IP 地址 `/24` 是一个不错的选择。 + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/operational-considerations.md b/content/zh/docs/getting-started-guides/ubuntu/operational-considerations.md new file mode 100644 index 0000000000..d738f09288 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/operational-considerations.md @@ -0,0 +1,262 @@ +--- +title: 运维注意事项 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本文为管理维护长期运行的集群的工程师提供一些建议和提示。 + +{{% /capture %}} +{{% capture prerequisites %}} + + +本文假定您对 Juju 和 Kubernetes 已经有了基本的了解。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 管理 Juju + + + +### 确定控制节点规模 + + + +Juju 控制器: + + + +* 运行需要大概 2 到 2.5 GB 的 RAM。 +* 用 MongoDB 数据库作为集群配置和状态的存储后端。这个数据库可能增长很快,也可能是实例中 CPU 周期的最大消费者。 +* 汇总和存储所有服务和单位的日志数据。因此,长期运行的模型需要大量的存储。如果您的目的是保持集群运行,请确保为日志配置至少 64 GB 的存储空间。 + + + +指定参数创建一个控制器(命令行如下): + +``` +juju bootstrap --constraints "mem=8GB cpu-cores=4 root-disk=128G" +``` + + + +Juju 将会选择与目标云上的约束匹配的最便宜的实例类型。 +还可以通过将 ```instance-type``` 与 ```root-disk``` 两个约束结合使用来进行严格控制。 +对于可用的约束信息,请参阅 [官方文档](https://jujucharms.com/docs/stable/reference-constraints) + + + + +关于日志记录的更多信息,请参阅 [日志章节](/docs/getting-started-guides/ubuntu/logging) + + + +### SSH 到控制节点上 + + + +默认情况下,Juju 将创建一对 SSH 密钥,用于自动化单元之间的连接。 +这对密钥保存在客户端节点的 ```~/.local/share/juju/ssh/``` 路径下。 + + + +部署完后,Juju 控制器是一个 "无声单元", +其充当客户端和已部署应用程序之间的代理。 +尽管如此,SSH 到控制器上还是很有用的。 + + + +首先,你需要了解你的运行环境,特别是如果你运行了几个 Juju 模型和控制器。 + +运行下面的命令行: + +``` +juju list-models --all +$ juju models --all +Controller: k8s + +Model Cloud/Region Status Machines Cores Access Last connection +admin/controller lxd/localhost available 1 - admin just now +admin/default lxd/localhost available 0 - admin 2017-01-23 +admin/whale* lxd/localhost available 6 - admin 3 minutes ago +``` + + + +第一行的 ```Controller: k8s``` 表明是如何引导创建的控制器。 + + + +接着可以看见下面列了 2 个,3 个或更多的类型。 + + + +* admin/controller 是托管 juju 所有控制器单元的默认模型 +* admin/default 默认情况下,作为托管用户应用程序的主要模型,例如 Kubernetes 集群 +* admin/whale 是一个额外的模型,如在 Juju 之上,叠加使用 conjure-up 的话 + + + +现在开始 ssh 到控制节点上,首先是让 Juju 切换上下文,然后是像一般单元那样 ssh 到控制节点上: + +``` +juju switch controller +``` + + + +在这个阶段,也可以查询控制器模型: + +``` +juju status +Model Controller Cloud/Region Version +controller k8s lxd/localhost 2.0.2 + +App Version Status Scale Charm Store Rev OS Notes + +Unit Workload Agent Machine Public address Ports Message + +Machine State DNS Inst id Series AZ +0 started 10.191.22.15 juju-2a5ed8-0 xenial +``` + + + +请注意,如果是在 HA 模式下进行的引导, +会在列表中看到几台机器。 + + + +现在 ssh 到控制器节点上,遵循和经典 Juju 命令相同的语义: + +``` +$ juju ssh 0 +Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.8.0-34-generic x86_64) + + * Documentation: https://help.ubuntu.com + * Management: https://landscape.canonical.com + * Support: https://ubuntu.com/advantage + + Get cloud support with Ubuntu Advantage Cloud Guest: + http://www.ubuntu.com/business/services/cloud + +0 packages can be updated. +0 updates are security updates. + + +Last login: Tue Jan 24 16:38:13 2017 from 10.191.22.1 +ubuntu@juju-2a5ed8-0:~$ +``` + + + +在结束完操作,想要返回到最初的模型,退出控制器即可。 + + + +如果,还想要切换回集群,ssh 到其他单元上,运行下面的命令行进行切换: + +``` +juju switch default +``` + + + +## 管理 Kubernetes 集群 + + + +### 运行特权容器 + + + +默认情况下,juju 部署的集群不支持在带有 GPU 的节点上运行特权容器。 +如果需要在其它节点上运行特权容器,只能是在 kubernetes-master 和 kubernetes-worker 节点上 +使能 ```allow-privileged``` 参数: + +``` +juju config kubernetes-master allow-privileged=true +juju config kubernetes-worker allow-privileged=true +``` + + + +### 私有仓库 + + + +通过 registry 操作,您可以很容易地创建一个使用 TLS 身份验证的私有 docker 仓库。 +但是请注意,通过这些功能部署的仓库不是高可用性的; +它使用的存储绑定到运行 pod 的 kubernetes 节点上。 +因此,如果仓库所在的 pod 从一个节点迁移到另一个节点上, +那么你需要重新发布镜像。 + + + +#### 使用示例 + + + +创建相关的身份验证文件。 +例如用户为 ```userA``` 密码为 ```passwordA``` 用来进行身份验证, +命令行如下: + +``` +echo "userA:passwordA" > htpasswd-plain +htpasswd -c -b -B htpasswd userA passwordA +``` + + + +(`htpasswd` 程序通过 ```apache2-utils``` 包获得) + + + +假设您的仓库可以通过 ```myregistry.company.com``` 访问, +您已经在 ```registry.key``` 文件中拥有了您的 TLS 密钥, +并且您的 TLS 身份验证(以 ```myregistry.company.com``` 作为 Common Name)在 +```registry.crt``` 文件中,那么您可以运行: + +``` +juju run-action kubernetes-worker/0 registry domain=myregistry.company.com htpasswd="$(base64 -w0 htpasswd)" htpasswd-plain="$(base64 -w0 htpasswd-plain)" tlscert="$(base64 -w0 registry.crt)" tlskey="$(base64 -w0 registry.key)" ingress=true +``` + + + +如果决定删除镜像仓库,命令行如下: + +``` +juju run-action kubernetes-worker/0 registry delete=true ingress=true +``` + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/rancher.md b/content/zh/docs/getting-started-guides/ubuntu/rancher.md new file mode 100644 index 0000000000..095b4c92fe --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/rancher.md @@ -0,0 +1,543 @@ +--- +title: Rancher 与 Ubuntu Kubernetes 集成 +cn-approvers: +- chentao1596 +--- + + + +{{% capture overview %}} + + + +本文将介绍如何在 Canonical Kubernetes 集群上部署 Rancher 2.0 alpha。 + + +这些步骤目前处于 alpha/testing 阶段,未来很可能会发生变化。 + + + +有关此集成的原始文档可以在 [https://github.com/CalvinHartwell/canonical-kubernetes-rancher/](https://github.com/CalvinHartwell/canonical-kubernetes-rancher/) 上找到。 + + +{{% /capture %}} +{{% capture prerequisites %}} + + +本文假设你有一个已经通过 Juju 部署、正在运行的集群。 + + + +有关使用 juju 部署 Kubernetes 集群的完整指导,请参考 [/docs/getting-started-guides/ubuntu/installation/](/docs/getting-started-guides/ubuntu/installation/)。 + +{{% /capture %}} + + +{{% capture steps %}} + + +## 部署 Rancher + + + +想要部署 Rancher,我们只需要在 Kubernetes 集群上运行 Rancher 容器工作负载即可。 +Rancher 通过 dockerhub([https://hub.docker.com/r/rancher/server/tags/](https://hub.docker.com/r/rancher/server/tags/)) +提供他们的容器镜像的免费下载。 + + + +如果您正在使用自己的镜像仓库,或进行离线部署, +那么,在开始部署之前,请先下载好这些容器镜像,将其推入私有镜像仓库中。 + + +### 使用 nodeport 部署 Rancher + + +首先创建一个 yaml 文件,该文件定义了如何在 kubernetes 上部署 Rancher。 +将该文件保存为 cdk-rancher-nodeport.yaml: + +``` +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: cluster-admin +subjects: + - kind: ServiceAccount + name: default + namespace: default +roleRef: + kind: ClusterRole + name: cluster-admin + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cluster-admin +rules: +- apiGroups: + - '*' + resources: + - '*' + verbs: + - '*' +- nonResourceURLs: + - '*' + verbs: + - '*' +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + creationTimestamp: null + labels: + app: rancher + name: rancher +spec: + replicas: 1 + selector: + matchLabels: + app: rancher + ima: pod + strategy: {} + template: + metadata: + creationTimestamp: null + labels: + app: rancher + ima: pod + spec: + containers: + - image: rancher/server:preview + imagePullPolicy: Always + name: rancher + ports: + - containerPort: 80 + - containerPort: 443 + livenessProbe: + httpGet: + path: / + port: 80 + initialDelaySeconds: 5 + timeoutSeconds: 30 + resources: {} + restartPolicy: Always + serviceAccountName: "" +status: {} +--- +apiVersion: v1 +kind: Service +metadata: + name: rancher + labels: + app: rancher +spec: + ports: + - port: 443 + protocol: TCP + targetPort: 443 + selector: + app: rancher +--- +apiVersion: v1 +kind: Service +metadata: + name: rancher-nodeport +spec: + type: NodePort + selector: + app: rancher + ports: + - name: rancher-api + protocol: TCP + nodePort: 30443 + port: 443 + targetPort: 443 +``` + + + +kubectl 开始正常运行后,执行下面的命令开始部署 Rancher: + +``` + kubectl apply -f cdk-rancher-nodeport.yaml +``` + + + +现在我们需要打开这个 nodeport,以供访问。 +为此,我们可以使用 juju。我们需要在集群中的每个工作节点上运行 open-port 命令。 +在 cdk-rancher-nodeport.yaml 文件中,nodeport 已设置为 30443。 +下面的命令行展示如何在每个工作节点上打开端口: + + + +``` + # 在集群的每个工作节点上运行下面的命令行 + juju run --unit kubernetes-worker/0 "open-port 30443" + juju run --unit kubernetes-worker/1 "open-port 30443" + juju run --unit kubernetes-worker/2 "open-port 30443" +``` + + + +现在便可以通过工作节点的 IP 或 DNS 记录(如果已经创建)在此端口上访问 Rancher。 +通常建议您为集群中的每个工作节点创建一条 DNS 记录。 +例如,如果有三个工作节点并且域名是 example.com,则可以创建三条 A 记录,集群中的每个工作节点各一条。 + + + +由于创建 DNS 记录超出了本文关注的范围, +我们将使用免费服务 xip.io 来获得和 IP 地址相对应的 A 记录,IP 地址将是域名的一部分。 +例如,如果有域名 rancher.35.178.130.245.xip.io, +则 xip.io 服务会自动将 IP 地址 35.178.130.245 作为 A 记录返回,这对测试相当有用。 +至于您的部署,IP 地址 35.178.130.245 应该替换为集群工作节点的 IP 地址,这个 IP 地址可以通过 Juju 或 AWS 得到: + + + +``` + calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status + +# ... 输出省略。 + +Unit Workload Agent Machine Public address Ports Message +easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected. +etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers +etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers +etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers +kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready. +kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running. + flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24 +kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24 +kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24 +kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/1 active idle 35.177.144.76 + +# 注意上面输出中 kubernetes-worker 的 IP 地址,可以选一个用作设置。 +``` + + + +尝试使用 nodeport 搭配域名或 IP 地址在浏览器中打开 Rancher: + + + +``` + # 将 IP 地址替换为某个 Kubernetes 工作节点的公共地址,通过 juju status 命令进行查找。 + wget https://35.178.130.245.xip.io:30443 --no-check-certificate + + # 这条命令也应该能工作 + wget https://35.178.130.245:30443 --no-check-certificate +``` + + + +如果需要对 kubernetes 配置文件进行任何更改,编辑 yaml 文件,再重新 apply 即可: + +``` + kubectl apply -f cdk-rancher-nodeport.yaml +``` + + +### 使用 ingress 规则部署 Rancher + + + +也可以使用 ingress 规则来部署 Rancher。 +这还有另外一个好处,就是不需要在 Kubernetes 集群上打开额外的端口。 +首先创建一个名为 cdk-rancher-ingress.yaml 的文件,内容如下: + +``` +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: cluster-admin +subjects: + - kind: ServiceAccount + name: default + namespace: default +roleRef: + kind: ClusterRole + name: cluster-admin + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cluster-admin +rules: +- apiGroups: + - '*' + resources: + - '*' + verbs: + - '*' +- nonResourceURLs: + - '*' + verbs: + - '*' +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + creationTimestamp: null + labels: + app: rancher + name: rancher +spec: + replicas: 1 + selector: + matchLabels: + app: rancher + strategy: {} + template: + metadata: + creationTimestamp: null + labels: + app: rancher + spec: + containers: + - image: rancher/server:preview + imagePullPolicy: Always + name: rancher + ports: + - containerPort: 443 + livenessProbe: + httpGet: + path: / + port: 80 + initialDelaySeconds: 5 + timeoutSeconds: 30 + resources: {} + restartPolicy: Always + serviceAccountName: "" +status: {} +--- +apiVersion: v1 +kind: Service +metadata: + name: rancher + labels: + app: rancher +spec: + ports: + - port: 443 + targetPort: 443 + protocol: TCP + selector: + app: rancher +--- +apiVersion: extensions/v1beta1 +kind: Ingress +metadata: + name: rancher + annotations: + kubernetes.io/tls-acme: "true" + ingress.kubernetes.io/secure-backends: "true" +spec: + tls: + - hosts: + - rancher.34.244.118.135.xip.io + rules: + - host: rancher.34.244.118.135.xip.io + http: + paths: + - path: / + backend: + serviceName: rancher + servicePort: 443 +``` + + + +通常建议您为集群中的每个工作节点创建一条 DNS 记录。 +例如,如果有三个工作节点并且域名是 example.com,则可以创建三条 A 记录,集群中的每个工作节点各一条。 + + + +由于创建 DNS 记录超出了本文关注的范围, +我们将使用免费服务 xip.io 来获得和 IP 地址相对应的 A 记录,IP 地址将是域名的一部分。 +例如,如果有域名 rancher.35.178.130.245.xip.io, +则 xip.io 服务会自动将 IP 地址 35.178.130.245 作为 A 记录返回,这对测试相当有用。 + + + +至于您的部署,IP 地址 35.178.130.245 应该替换为集群工作节点的 IP 地址,这个 IP 地址可以通过 Juju 或 AWS 得到: + + + +``` + calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status + +# ... 输出省略。 + +Unit Workload Agent Machine Public address Ports Message +easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected. +etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers +etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers +etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers +kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready. +kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running. + flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24 +kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24 +kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24 +kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running. + flannel/1 active idle 35.177.144.76 + +# 注意上面输出中 kubernetes-worker 的 IP 地址,可以选一个用作设置。 +``` + + + +查看上面 juju status 的命令输出,可以拿公共地址(35.178.130.245)来创建 xip.io DNS记录(rancher.35.178.130.245.xip.io),记录可以加到 cdk-rancher-ingress.yaml 文件中。 +你也同样可以创建自己的 DNS 记录,只要能解析到集群上的工作节点即可: + + + +``` + # xip.io 在文件中会出现两次,请都替换修改。 + cat cdk-rancher-ingress.yaml | grep xip.io + - host: rancher.35.178.130.245.xip.io +``` + + + +修改完 ingress 规则之后,可以运行 `kubectl apply -f cdk-rancher-ingress.yaml` 命令来更新 Kubernetes 集群: + +``` + kubectl apply -f cdk-rancher-ingress.yaml +``` + + + +现在可以通过工作节点 IP 或者 DNS 记录(如果已创建)在常规的 443 上访问 Rancher。 +尝试在浏览器中打开它: + + + +``` + # 将 IP 地址替换为某个 Kubernetes 工作节点的公共地址,通过 juju status 命令进行查找。 + wget https://35.178.130.245.xip.io:443 --no-check-certificate +``` + + + +如果需要对 kubernetes 配置文件进行任何更改,请编辑 yaml 文件,再 apply: + +``` + kubectl apply -f cdk-rancher-ingress.yaml +``` + + +### 删除 Rancher + + + +您可以使用 kubectl 从集群中删除 Rancher。 +在 Kubernetes 中删除对象与创建它们的过程一样简单: + + + +``` + # 使用 nodeport 示例(如果使用 ingress 示例,请修改文件名) + kubectl delete -f cdk-rancher-nodeport.yaml +``` + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/scaling.md b/content/zh/docs/getting-started-guides/ubuntu/scaling.md new file mode 100644 index 0000000000..a24c136eeb --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/scaling.md @@ -0,0 +1,147 @@ +--- +title: 扩缩 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本文将讨论如何在集群中扩缩主节点和工作节点。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +本文假设您已经有一个用 Juju 部署、正在运行的集群。 + + + +任何应用都可以在部署之后进行横向扩容。 +charms 将会不停地更新进度状态信息,建议运行如下命令。 + +``` +watch -c juju status --color +``` +{{% /capture %}} + +{{% capture steps %}} + + + +## Kubernetes 主节点 + + + +Kubernetes 主节点充当了集群中控制平面的角色。 +在设计上,这些主节点可以独立于工作节点进行扩缩容,从而带来运维上的灵活性。 +想要添加一个主节点,只需要执行以下命令: + + juju add-unit kubernetes-master + + + +这将会在控制平面中添加一个新的主节点。 +参见[构建高可用集群](/docs/admin/high-availability)文档,获取更多信息。 + + + +## Kubernetes 工作节点 + + + +kubernetes-worker 节点是 Kubernetes 集群中承担负载的部分。 + + + +默认情况下,pod 会自动均匀部署在 kubernetes-worker 节点上。 + + + +如果想要在集群中添加更多的 kubernetes-worker 节点,运行如下命令: + +``` +juju add-unit kubernetes-worker +``` + + + +或者修改机器限制,来创建更大的节点: + +``` +juju set-constraints kubernetes-worker "cpu-cores=8 mem=32G" +juju add-unit kubernetes-worker +``` + + + +参见[机器限制文档](https://jujucharms.com/docs/stable/charms-constraints), +了解其它机器约束,这些约束可能对 kubernetes-worker unit 有帮助。 + +## etcd + + + +Etcd 在 Kubernetes 集群中用作键值存储。 +集群默认使用一个存储实例。 + + + +由于仲裁机制的关系,推荐保有奇数个 etcd 节点。 +根据集群的大小,推荐使用3、5、7 或 9 个节点。 +CoreOS etcd 文档有一个关于[最佳集群大小](https://coreos.com/etcd/docs/latest/admin_guide.html#optimal-cluster-size)的图表, +可以参考确定最佳的容错设计。 + + +添加 etcd 单元: + +``` +juju add-unit etcd +``` + + +不建议在扩容 etcd 集群之后对其缩容。 + + +## Juju 控制器 + + + +一个负责协调每台机器上 Juju 代理(这些代理管理 Kubernetes 集群)的节点被称为控制器节点。 +对于生产环境下的部署,建议启用控制器节点的高可用性: + + juju enable-ha + + + +启用 HA 将会创建 3 个控制器节点,对于大多数情况而言应该是足够的。 +而对于超大型的部署,也同时支持 5 或 7 个控制器节点。 + + + +参见 [Juju HA 控制器文档](https://jujucharms.com/docs/2.2/controllers-ha) 获取更多信息. + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/storage.md b/content/zh/docs/getting-started-guides/ubuntu/storage.md new file mode 100644 index 0000000000..04aa262d9b --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/storage.md @@ -0,0 +1,138 @@ +--- +title: 存储 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本文解释了如何在集群中安装和配置持久化存储。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +本文假设您已经有一个用 Juju 部署、正在运行的集群。 + +{{% /capture %}} + +{{% capture steps %}} + + +## Ceph 持久卷 + + + +Canonical 的 Kubernetes 发行版允许添加持久化存储设备,例如 [Ceph](http://ceph.com)。 +配合 [Juju Storage](https://jujucharms.com/docs/2.0/charms-storage)功能, +可以跨云平台,添加持久化存储。 + + + +部署一个至少有三个 ceph-mon 和三个 ceph-osd 单元的存储池。 + +``` +juju deploy cs:ceph-mon -n 3 +juju deploy cs:ceph-osd -n 3 +``` + + +关联这些单元: + +``` +juju add-relation ceph-mon ceph-osd +``` + + +列出云上 Juju 可用的存储池: + + juju storage-pools + + +输出: + +``` +Name Provider Attrs +ebs ebs +ebs-ssd ebs volume-type=ssd +loop loop +rootfs rootfs +tmpfs tmpfs +``` + +{{< note >}} + + + +注意列表使用的是 AWS,不同的云有不同的存储池名称。 + +{{< /note >}} + + + +以 “名字,大小,数量”的格式往 ceph-osd charm 中添加存储池: + +``` +juju add-storage ceph-osd/0 osd-devices=ebs,10G,1 +juju add-storage ceph-osd/1 osd-devices=ebs,10G,1 +juju add-storage ceph-osd/2 osd-devices=ebs,10G,1 +``` + + +接下来将 Kubernetes 和存储集群相关联: + +``` +juju add-relation kubernetes-master ceph-mon +``` + + + + +现在我们可以在 Kubernetes 中列举可用的[持久卷](/docs/concepts/storage/persistent-volumes/), +集群中的负载可以通过 PVC 申领来使用这些持久卷。 + +``` +juju run-action kubernetes-master/0 create-rbd-pv name=test size=50 +``` + + + +本例中创建了 50 MB 大小的 “test” Rados 块设备 (rbd)。 + +在 Kubernetes 集群上使用如下所示的 watch 命令,可以看到 PV 加入列表,并被标记可用的过程: + + watch kubectl get pv + + +输出: + +``` +NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE + +test 50M RWO Available 10s +``` + + + +要使用这些持久卷,pods 需要关联一个持久卷申领,这超出了本文档的讨论范围。 +参见[持久卷](/docs/concepts/storage/persistent-volumes/)获取更多信息。 + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/troubleshooting.md b/content/zh/docs/getting-started-guides/ubuntu/troubleshooting.md new file mode 100644 index 0000000000..be76e9eb91 --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/troubleshooting.md @@ -0,0 +1,272 @@ +--- +title: 故障排除 +--- + + + +{{% capture overview %}} + + + +本文重点讨论如何解决 Kubernetes 集群部署过程中的问题, +而不会关心如何调试 Kubernetes 集群内的工作负载。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +本文假设您已经有一个用 Juju 部署、正在工作的集群。 + +{{% /capture %}} + +{{% capture steps %}} + + +## 了解集群状态 + + +使用 `juju status` 命令可以了解一些集群内的情况: + +``` +Model Controller Cloud/Region Version +kubes work-multi aws/us-east-2 2.0.2.1 + +App Version Status Scale Charm Store Rev OS Notes +easyrsa 3.0.1 active 1 easyrsa jujucharms 3 ubuntu +etcd 2.2.5 active 1 etcd jujucharms 17 ubuntu +flannel 0.6.1 active 2 flannel jujucharms 6 ubuntu +kubernetes-master 1.4.5 active 1 kubernetes-master jujucharms 8 ubuntu exposed +kubernetes-worker 1.4.5 active 1 kubernetes-worker jujucharms 11 ubuntu exposed + +Unit Workload Agent Machine Public address Ports Message +easyrsa/0* active idle 0/lxd/0 10.0.0.55 Certificate Authority connected. +etcd/0* active idle 0 52.15.47.228 2379/tcp Healthy with 1 known peers. +kubernetes-master/0* active idle 0 52.15.47.228 6443/tcp Kubernetes master services ready. + flannel/1 active idle 52.15.47.228 Flannel subnet 10.1.75.1/24 +kubernetes-worker/0* active idle 1 52.15.177.233 80/tcp,443/tcp Kubernetes worker running. + flannel/0* active idle 52.15.177.233 Flannel subnet 10.1.63.1/24 + +Machine State DNS Inst id Series AZ +0 started 52.15.47.228 i-0bb211a18be691473 xenial us-east-2a +0/lxd/0 started 10.0.0.55 juju-153b74-0-lxd-0 xenial +1 started 52.15.177.233 i-0502d7de733be31bb xenial us-east-2b +``` + + + +在这个例子中,我们可以获取一些信息。 `Workload` 列将显示给定服务的状态。 +`Message` 部分将显示集群中给定服务的健康状况。 在部署和维护期间, +这些工作负载状态将进行更新以反映给定节点正在执行的操作。例如, +Workload 可能显示为 `maintenance`,而 Message 则会相应显示为 `Installing docker`。 + + + +正常情况下,Workload 列应该为 `active`,Agent 列(用于反映 Juju 代理正在做什么)应该为 `idle`, +而 Message 要么是 `Ready` 或者其它描述性的术语。 +如果集群运行健康,`juju status --color` 返回的结果输出都将是绿色的。 + + + +对于大型集群而言,状态信息可能会太多,因此建议检查各个服务的状态,例如仅检查工作节点的状态: + + juju status kubernetes-worker + + +或者只检查 etcd 集群的状态: + + juju status etcd + +Errors will have an obvious message, and will return a red result when used with +`juju status --color`. Nodes that come up in this manner should be investigated. + +错误都会有明显的错误信息,使用 `juju status --color` 的返回结果也将是红色的。 +如果节点状态出现这种情况,需要相应地检查了解。 + + +## SSH 到各个单元上 + + + +按照 `juju ssh <服务名>/<单元#>` 的命令格式可以轻松地连接到各个单元上: + + juju ssh kubernetes-worker/3 + + +将会 ssh 到第 3 个工作单元上。 + + juju ssh easyrsa/0 + + +将会 ssh 到第 0 个 easyrsa 单元上。 + + +## 收集调试信息 + + + +有时候,从集群上收集所有的信息,并与开发人员共享,将有助于发现问题。 +这最好是通过 [CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent) 来完成。 + + + +在带有 Juju 客户端,而客户端配有指向相应的 CDK 部署的控制器的节点上, +下载并执行[CDK Field Agent](https://github.com/juju-solutions/cdk-field-agent)中的 collect.py 文件。 + + + +运行该脚本会生成一个 tar 包,包含系统信息以及诸如 systemctl 状态,Juju 日志,charm 单元数据等基本信息。 +额外和应用相关的信息可能也会包含其中。 + + + +## 常见问题 + + + +### 负载均衡器对 Helm 的影响 + + + +本节假定有一个用 Juju 部署的正在运行的 Kubernetes 集群,使用负载均衡器来代理 API,同时也用 Helm 来进行 chart 部署。 + + +Helm 初始化: + +``` +helm init +$HELM_HOME has been configured at /home/ubuntu/.helm +Tiller (the helm server side component) has been installed into your Kubernetes Cluster. +Happy Helming! +``` + + +随后使用 helm 时,可能会出现以下错误: + + +* Helm 不能从 Tiller 服务器获取版本号 + +``` +helm version +Client: &version.Version{SemVer:"v2.1.3", GitCommit:"5cbc48fb305ca4bf68c26eb8d2a7eb363227e973", GitTreeState:"clean"} +Error: cannot connect to Tiller +``` + + +* Helm 不能安装 chart + +``` +helm install --debug +Error: forwarding ports: error upgrading connection: Upgrade request required +``` + + + +这是因为 API 负载均衡器在 helm 客户端-服务端关系的上下文中不进行端口转发造成的。 +要使用 helm 进行部署,需要执行以下步骤: + + +1. 暴露 Kubernetes Master 服务 + + ``` + juju expose kubernetes-master + ``` + + +1. 确定其中一个主节点的公开 IP 地址 + + ``` + juju status kubernetes-master + Model Controller Cloud/Region Version + production k8s-admin aws/us-east-1 2.0.0 + + App Version Status Scale Charm Store Rev OS Notes + flannel 0.6.1 active 1 flannel jujucharms 7 ubuntu + kubernetes-master 1.5.1 active 1 kubernetes-master jujucharms 10 ubuntu exposed + + Unit Workload Agent Machine Public address Ports Message + kubernetes-master/0* active idle 5 54.210.100.102 6443/tcp Kubernetes master running. + flannel/0 active idle 54.210.100.102 Flannel subnet 10.1.50.1/24 + + Machine State DNS Inst id Series AZ + 5 started 54.210.100.102 i-002b7150639eb183b xenial us-east-1a + + Relation Provides Consumes Type + certificates easyrsa kubernetes-master regular + etcd etcd flannel regular + etcd etcd kubernetes-master regular + cni flannel kubernetes-master regular + loadbalancer kubeapi-load-balancer kubernetes-master regular + cni kubernetes-master flannel subordinate + cluster-dns kubernetes-master kubernetes-worker regular + cni kubernetes-worker flannel subordinate + ``` + + + + 本例中,公开 IP 地址为 54.210.100.102。 + 如果想编程访问得到这个值,可以使用 JSON 输出: + + ``` + juju show-status kubernetes-master --format json | jq --raw-output '.applications."kubernetes-master".units | keys[]' + 54.210.100.102 + ``` + + +1. 更新 kubeconfig 文件 + + + + 确定集群所使用的 kubeconfig 文件或配置部分,然后修改服务器配置。 + + 默认情况下,这个配置类似于 ```https://54.213.123.123:443```。将其替换为 Kubernetes Master 端点地址 + ```https://54.210.100.102:6443``` 并保存。 + + 注意,Kubernetes Master API 的 CDK 默认使用的端口为 6443,而负载均衡器暴露的端口是 443。 + + +1. 继续使用 helm! + + ``` + helm install --debug + Created tunnel using local port: '36749' + SERVER: "localhost:36749" + CHART PATH: /home/ubuntu/.helm/ + NAME: + ... + ... + ``` + + +## 日志和监控 + + + +默认情况下, Kubernetes 没有节点的日志聚合,每个节点都是本地保存日志。 +请参阅[日志](/docs/getting-started-guides/ubuntu/logging/)文档,获取更多信息。 + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/ubuntu/upgrades.md b/content/zh/docs/getting-started-guides/ubuntu/upgrades.md new file mode 100644 index 0000000000..9df7fb310a --- /dev/null +++ b/content/zh/docs/getting-started-guides/ubuntu/upgrades.md @@ -0,0 +1,273 @@ +--- +title: 升级 +content_template: templates/task +--- + + + +{{% capture overview %}} + +本页将展示如何进行 Kubernetes 集群升级。 +{{% /capture %}} + +{{% capture prerequisites %}} + +本页假定你有一个 juju 部署的集群。 + +{{< warning >}} + + + +在进行升级之前,你应当备份所有的数据。 +不要忘记对集群内的工作负载进行数据备份! +参见[备份文档](/docs/getting-started-guides/ubuntu/backups)。 + +{{< /warning >}} + +{{% /capture %}} + +{{% capture steps %}} + + +## 对集群进行补丁版本升级,例如,1.9.0 -> 1.9.1 + + + +集群透明地升级到最新的 Kubernetes 补丁版本。 +需要澄清的是,用 1.9/stable 通道部署的集群将会透明地、自动更新到 Kubernetes 1.9.X 最新版。 +升级的过程对集群的运行没有影响,也不需要集群维护人员的干预。 +每一个补丁版本都由 Canonical Kubernetes 发布小组审核评估。 +一旦补丁版本通过了内部测试,认为可以安全用于集群升级, +将会被打包成 snap 格式,发布到稳定版通道上。 + + +## 对集群进行次版本升级,例如,1.8.1 -> 1.9.0 + + + +Kubernetes charms 遵循的是 Kubernetes 发行版本。 +请咨询了解 support 计划在升级频率方面的相关信息。 +重要的运维考虑以及行为上的改变都会记录在发布通知里。 + + +### 升级 etcd + + + +备份 etcd 需要导出和快照操作,参见[备份文档](/docs/getting-started-guides/ubuntu/backups)了解如何创建快照。 +在做完快照后,用下面的命令升级 etcd 服务: + + juju upgrade-charm etcd + + + +命令将会负责 etcd 的次版本升级。 +在 [juju 解决方案的 wiki](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade) 里 +可以了解如何将 etcd 从 2.x 升级到 3.x。 + + +### 升级 kubeapi-load-balancer + + + +Kubernetes Charms 通常是同时更新、发布。 +Ubuntu 集群的核心部分是 kubeapi-load-balancer 组件。 +错误或遗失修改可能会导致 API 可用性和访问控制方面的问题。 +为了保证 API 服务在集群升级期间还能为主节点和工作节点服务,也需要对它们进行升级。 + + + +升级命令: + + juju upgrade-charm kubeapi-load-balancer + + +### 升级 Kubernetes + + + +Kubernetes Charms 使用 snap 通道来驱动负荷。 +这些通道定义的格式为 `X.Y/channel`,其中,`X.Y` 是 Kubernetes `主.次` 发行版(例如,1.9) +而 `channel` 的取值范围如下: + + + +| 通道名 | 描述 | +| ------------------- | ------------ | +| stable | Kubernetes 的最新稳定发行版 | +| candidate | Kubernetes 的发行候选版 | +| beta | Kubernetes 次发行版的最新 alpha 或 beta 版 | +| edge | Kubernetes 次发行版的每日构建版 | + + + + +如果发行版还不可用,就会使用下一个最高通道的版本。 +例如,1.9/beta 会根据发行版的可用性加载 `/candidate` 或 `/stable` 版本。 +Kubernetes 的开发版本会根据每个次版本,发布到 edge 通道上。 +但不会保证 edge snap 能够和当前的 charms 一起工作。 + + +### 主节点升级 + + + +首先需要对主节点进行升级: + + juju upgrade-charm kubernetes-master + +{{< note >}} + + + +永远在工作节点升级之前,升级主节点。 + +{{< /note >}} + + + +在部署完最新的 charm 之后,可以通过下面的命令行来选择通道: + + juju config kubernetes-master channel=1.x/stable + + + +其中,`x` 是 Kubernetes 的次版本号。例如,`1.9/stable`。 +参阅前面对通道的定义。 +将 kubernetes-master 配置到合适的通道上后, +再在每个主节点上运行下面的升级命令: + + juju run-action kubernetes-master/0 upgrade + juju run-action kubernetes-master/1 upgrade + ... + + +### 工作节点升级 + + + +现有所支持的升级工作节点的方法有两种,[蓝/绿部署](http://martinfowler.com/bliki/BlueGreenDeployment.html) +和就地升级。提供两种方法可以带来运维上的灵活性,而这两种方法也都被支持和测试。 +相比于就地升级,蓝/绿部署需要更多的硬件资源,但也更为安全可靠。 + + +#### 蓝/绿工作节点升级 + + + +假定一个部署里面所有的工作节点都叫 kubernetes-alpha。 + + + +部署新的工作节点: + + juju deploy kubernetes-alpha + + + +暂停旧的工作节点,然后迁移工作负载: + + juju run-action kubernetes-alpha/# pause + + + +验证所迁移的工作负载: + + kubectl get pod -o wide + + + +销毁就有的工作节点: + + juju remove-application kubernetes-alpha + + +#### 就地工作节点升级 + + juju upgrade-charm kubernetes-worker + juju config kubernetes-worker channel=1.x/stable + + + +其中,`x` 是 Kubernetes 的次版本号。例如,`1.9/stable`。 +参阅前面对通道的定义。将 kubernetes-worker 配置到合适的通道上后, +再在每个工作节点上运行下面的升级命令: + + juju run-action kubernetes-worker/0 upgrade + juju run-action kubernetes-worker/1 upgrade + ... + + +### 验证升级 + + + +`kubectl version` 将会返回新的版本号。 + + + +建议重新运行[集群验证](/docs/getting-started-guides/ubuntu/validation)确认集群升级成功完成。 + + +### 升级 Flannel + + + +可以在任何时候升级 flannel,它的升级可以和 Kubernetes 升级分开进行。 +需要注意的是,在升级过程中,网络会受到影响。 +可以通过下面的命令行发起升级: + + juju upgrade-charm flannel + + +### 升级 easyrsa + + + +可以在任何时候升级 easyrsa,它的升级可以和 Kubernetes 升级分开进行。 +升级 easyrsa 会有停机时间,因为不是运行服务: + + juju upgrade-charm easyrsa + +{{% /capture %}} diff --git a/content/zh/docs/getting-started-guides/windows/OVN_OVS_Windows_Installer.png b/content/zh/docs/getting-started-guides/windows/OVN_OVS_Windows_Installer.png new file mode 100644 index 0000000000..520f6ae9e6 Binary files /dev/null and b/content/zh/docs/getting-started-guides/windows/OVN_OVS_Windows_Installer.png differ diff --git a/content/zh/docs/getting-started-guides/windows/UpstreamRouting.png b/content/zh/docs/getting-started-guides/windows/UpstreamRouting.png new file mode 100644 index 0000000000..91189c36af Binary files /dev/null and b/content/zh/docs/getting-started-guides/windows/UpstreamRouting.png differ diff --git a/content/zh/docs/getting-started-guides/windows/_index.md b/content/zh/docs/getting-started-guides/windows/_index.md new file mode 100644 index 0000000000..343feaafcb --- /dev/null +++ b/content/zh/docs/getting-started-guides/windows/_index.md @@ -0,0 +1,892 @@ +--- +title: 在 Kubernetes 中使用 Windows Server 容器 +toc_hide: true +--- + + + +{{< note >}} +**Note:** 这些说明最近基于 Windows Server 平台增强和 Kubernetes v1.9 版本进行了更新 +{{< /note >}} + + + +Kubernetes 1.5 版本基于 Windows Server 2016 操作系统引入了对 Windows Server 容器 +的 Alpha 支持。随着 Windows Server 版本 1709 的发布和使用 Kubernetes v1.9,用户可以使用许多不同的 +网络拓扑和 CNI 插件在本地或私有/公共云中部署 Kubernetes 集群。Kubernetes 上的 Windows Server 容器的一些 +关键功能改进包括: + + + +- 改进了对 pod 的支持!具有多个 Windows Server 容器(共享内核)的共享网络命名空间(隔离专区) + + + +- 通过每个 pod 使用单个网络端点降低网络复杂性 + + + +- 使用虚拟过滤平台 (VFP)Hyper-v 交换机扩展(类似于 Linux iptables) 的基于内核的负载均衡 + + + +- 容器运行时接口(CRI) pod 和 节点级统计 + + + +- 支持 kubeadm 命令将 Windows Server 节点添加到 Kubernetes 环境中 + + + +Kubernetes 控制平面(API服务器,调度程序,控制器管理器等)继续在 Linux 上运行,而 kubelet 和 kube-proxy 可以在 Windows Server 2016 或更高版本上运行 + + + +{{< note >}} +**Note:** Kubernetes 上的 Windows Server 容器是 Kubernetes v1.9 中的一个 Beta 特性 +{{< /note >}} + + + +## 获取 Windows 二进制文件 + + + +我们建议使用可以在 [https://github.com/kubernetes/kubernetes/releases/latest](https://github.com/kubernetes/kubernetes/releases/latest) 上找到的发布的二进制文件。在更新日志下您可以找到 Windows-amd64 的节点二进制文件链接,其中包括 kubeadm,kubectl,kubelet 和 kube-proxy。 + + + +如果您希望自己构建代码,请参阅[此处](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/compiling-kubernetes-binaries)的详细构建说明。 + + + +## 环境准备 + +在 Kubernetes 1.9 或更高版本中,使用以下内容支持 Kubernetes 的 Windows Server 容器: + + +1. Kubernetes 控制平面在现有的 Linux 基础架构(1.9版本或更高版本)上运行。 + +2. Linux 的节点上的 Kubenet 网络插件设置。 + +3. Windows Server 2016 RTM 或更高版本,Windows Server 版本 1709 或更高版本是首选; 它解锁了共享网络命名空间等关键功能。 + +4. 适用于 Windows Server 节点的 Docker 版本 17.06.1-ee-2 或更高版本(Linux 节点和 Kubernetes 控制平面可以运行任何 Kubernetes 支持的 Docker 版本)。 + + +## 网络 + + + +Windows 上有几种支持 Kubernetes v1.9 的网络配置,包括使用第三方网络插件的第三层路由和覆盖拓扑。 + + +1. [上游 L3 路由](#upstream-l3-routing-topology) - 在上游 ToR 中配置的 IP 路由 + +2. [主机网关](#host-gateway-topology) - 在每台主机上配置的 IP 路由 + +3. [使用覆盖式 Open vSwitch(OVS) 和开放虚拟网络(OVN)](#using-ovn-with-ovs) - 覆盖网络(支持STT和Geneve隧道类型) + +4. [未来 - 评审中] 覆盖 - 使用 Flannel 的 VXLAN 或者 IP-in-IP 封装 + +5. [未来] 使用 BGP(Calico) 的第三层路由 + + +选择要部署的网络配置和拓扑取决于物理网络拓扑和用户配置路由的能力,封装的性能问题以及与第三方网络插件集成的要求。 + + +### 未来的 CNI 插件 +另外两个 CNI 插件 [win-l2bridge(主机网关)和 win-overlay(vxlan)] 正在进行 PR 审核。这两个 CNI 插件准备好后,既可以直接使用,也可以与 Flannel 一起使用。 + + + +### Linux +Linux 上已经使用桥接接口支持上述网络方法,桥接接口基本上创建了节点本地的专用网络。与 Windows 端类似,必须创建到所有其他 pod CIDR 的路由才能通过"公共" NIC 发送数据包。 + + + +### Windows +Windows 支持 CNI 网络模型,并使用插件与 Windows 主机网络服务(HNS)连接以配置主机网络和策略。在撰写本文时,Microsoft 唯一公开提供的 CNI 插件是从私人存储库构建的,可在此处获得[wincni.exe](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/cni/wincni.exe)。它使用由管理员在每个节点上使用 HNS PowerShell 命令通过 Windows 主机网络服务(HNS)创建的 l2bridge 网络,如下面的 [Windows 主机设置](#windows-host-setup)部分所述。未来CNI插件的源代码将公开发布 + + + +#### 上游 L3 路由拓扑 +在这种拓扑结构中,通过在机架 (ToR)交换机/路由器的上游顶部配置静态 IP 路由,使用L3路由实现网络连接。每个群集节点都通过主机 IP 连接到管理网络。此外,每个节点使用本地'l2bridge'网络,并分配了一个 pod CIDR。给定工作节点上的所有 pod 将连接到 pod CIDR 子网('l2bridge'网络)。为了在不同节点上运行的 pod 之间实现网络通信,上游路由器配置了静态路由 pod CIDR 前缀 => 主机 IP。 + + + +以下示例图说明了使用上游 L3 路由设置的 Kubernetes 的 Windows Server 网络设置: + + +![K8s 集群使用 ToR 的 L3 路由](UpstreamRouting.png) + + + +#### 主机网关拓扑 +这种拓扑与上游 L3 路由拓扑相似,惟一的区别是静态 IP 路由是直接在每个集群节点上配置的,而不是在上游 ToR 中配置的。每个节点使用本地的 'l2bridge' 网络,并像以前一样分配 pod CIDR,并为分配给远程集群节点的所有其他 pod CIDR 子网提供路由表条目。 + + + +#### OVN 和 OVS 一起使用 +下图概述了组件之间的体系结构和交互: + + + +![覆盖式使用 OVN 控制器和 OVS 开关扩展](ovn_kubernetes.png) + + + +(上图来自 [https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram](https://github.com/openvswitch/ovn-kubernetes#overlay-mode-architecture-diagram)) + + + +由于它的体系结构,OVN 有一个中央组件,它将您的网络意图存储在数据库中。其他组件如 kube-apiserver、kube-controller-manager、kube-scheduler 等也可以部署在该中心节点上。 + + +## 在 Kubernetes 上设置 Windows Server 容器 +要在 Kubernetes 上运行 Windows Server 容器,您需要为 Windows 设置主机和 Kubernetes 节点组件。根据您的网络拓扑,可能需要为不同节点上的 pod 通信设置路由。 + + + +### 主机设置 + + + +#### 1. 上游 L3 路由拓扑和 2. 主机网关拓扑 + + + +##### Linux 主机设置 + + + +1. Linux 主机应该根据它们各自的发行版文档和您将使用的 Kubernetes 版本的要求进行设置。 + +2. 使用步骤[此处](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/creating-a-linux-master.md)配置Linux主节点 + +3. [可选]安装CNI网络插件。 + + +##### Windows 主机设置 + + + +1. 运行所需 Windows Server 和 Docker 版本的 Windows Server 容器主机。请按照此帮助主题概述的安装说明进行操作:https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server。 + +2. 2. [获取 Windows 二进制文件](#get-windows-binaries) kubelet.exe, kube-proxy.exe, and kubectl.exe 使用说明 + +3. 使用 X.509 密钥从 Linux 主节点复制节点规范文件(kube config) + +4. 创建 HNS 网络,确保正确的 CNI 网络配置,并使用此脚本 [start-kubelet.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubelet.ps1) 启动 kubelet.exe + +5. 使用此脚本启动 [start-kubeproxy.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/start-kubeproxy.ps1) 启动 kube-proxy + +6. [仅限 #2 主机网关模式]使用此脚本 [AddRoutes.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/AddRoutes.ps1) 在Windows主机上添加静态路由 + +更详细的说明可以在[这里](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows.md)找到。 + + +**Windows CNI 配置示例** + + + +Windows CNI 插件基于 wincni.exe 的,配置文件,是基于上面显示的 ToR 示例图,指定了应用于 Windows node-1 的配置。特别有趣的是 Windows node-1 pod CIDR(10.10.187.64/26) 和 cbr0(10.10.187.66)的关联网关。异常列表指定服务 CIDR(11.0.0.0/8),集群 CIDR(10.10.0.0/16) 和管理(或主机) CIDR(10.127.132.128/25)。 + + +注意:此文件假设用户以前使用 -HNSNetworkcmdlet 在每个 Windows 节点上创建了'l2bridge' 主机网络,如上面链接的 start-kubelet.ps1 和 start-kubeproxy.ps1 脚本中所示 + + +```json +{ + "cniVersion": "0.2.0", + "name": "l2bridge", + "type": "wincni.exe", + "master": "Ethernet", + "ipam": { + "environment": "azure", + "subnet": "10.10.187.64/26", + "routes": [{ + "GW": "10.10.187.66" + }] + }, + "dns": { + "Nameservers": [ + "11.0.0.10" + ] + }, + "AdditionalArgs": [{ + "Name": "EndpointPolicy", + "Value": { + "Type": "OutBoundNAT", + "ExceptionList": [ + "11.0.0.0/8", + "10.10.0.0/16", + "10.127.132.128/25" + ] + } + }, + { + "Name": "EndpointPolicy", + "Value": { + "Type": "ROUTE", + "DestinationPrefix": "11.0.0.0/8", + "NeedEncap": true + } + }, + { + "Name": "EndpointPolicy", + "Value": { + "Type": "ROUTE", + "DestinationPrefix": "10.127.132.213/32", + "NeedEncap": true + } + } + ] +} +``` + +#### 3.使用覆盖方式打开 vSwitch(OVS) 和开放虚拟网络(OVN) + + + +{{< note >}} +**Note:** 通过 Ansible 剧本的全自动设置是[可用的](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)。 +{{< /note >}} + + + +对于手动设置,请继续以下步骤。 + + +##### Linux 主机设置 + + + +设置中心节点和所需组件超出了本文档的范围。您可以阅读[这些说明](https://github.com/openvswitch/ovn-kubernetes#k8s-master-node-initialization)。 + + +添加 Linux minion 也超出了范围,你可以在这里阅读:[Linux minion](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations)。 + + + +##### windows 主机设置 + + + +添加 Windows minion 需要您安装 OVS 和 OVN 二进制文件。运行所需 Windows Server 和 Docker 版本的 Windows Server 容器主机。请按照[此帮助主题](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server)概述的设置说明进行操作。从 Windows Server 2016 RTM 开始支持此类部署。 + + +编译 OVS 并生成安装程序不在本文中讨论。请访问[此链接](http://docs.openvswitch.org/en/latest/intro/install/windows/#open-vswitch-on-windows)。对于预构建的认证安装程序,请访问[此链接](https://cloudbase.it/openvswitch/#download)并下载最新版本 + + +以下指南使用预构建的认证安装程序。 + + +安装 OVS 既可以通过 GUI 对话框完成,也可以在无人看管的情况下完成。将 Windows 主机添加到您的设置需要您拥有`OVN主机`和默认安装特性。下面是需要安装的对话框图像: + + +![Windows 安装 OVN OVS](OVN_OVS_Windows_Installer.png) + + + +对于无人看管情况下的安装,请使用以下命令: + + +``` +cmd /c 'msiexec /i openvswitch.msi ADDLOCAL="OpenvSwitchCLI,OpenvSwitchDriver,OVNHost" /qn' +``` + +安装程序设置新的环境变量。请使用命令打开一个新的 shell 或注销/登录,以确保刷新了环境变量。 + + +对于叠加,Windows 上的 OVS 需要透明的 docker 网络才能正常运行。请使用以下命令创建一个透明的 docker 网络,OVS 将使用该网络。powershell: + + +``` +docker network create -d transparent --gateway $GATEWAY_IP --subnet $SUBNET ` + -o com.docker.network.windowsshim.interface="$INTERFACE_ALIAS" external +``` + +$SUBNET 是用于产生 pods 的 minion 子网(将由 kubernetes 使用的子网),$GATEWAY_IP 是 $SUBNET 的第一个 IP,$INTERFACE_ALIAS 是用于创建覆盖隧道的接口(必须与 OVN 主机的 rests 连接)。 +例: + + + +``` +docker network create -d transparent --gateway 10.0.1.1 --subnet 10.0.1.0/24 ` + -o com.docker.network.windowsshim.interface="Ethernet0" external +``` + +创建 docker 网络后,请从 powershell 运行下面的命令。(创建OVS桥接器,在桥接器下添加接口,并启用OVS转发交换机扩展名) + + +``` +$a = Get-NetAdapter | where Name -Match HNSTransparent +Rename-NetAdapter $a[0].Name -NewName HNSTransparent +Stop-Service ovs-vswitchd -force; Disable-VMSwitchExtension "Cloudbase Open vSwitch Extension"; +ovs-vsctl --no-wait del-br br-ex +ovs-vsctl --no-wait --may-exist add-br br-ex +ovs-vsctl --no-wait add-port br-ex HNSTransparent -- set interface HNSTransparent type=internal +ovs-vsctl --no-wait add-port br-ex $INTERFACE_ALIAS +Enable-VMSwitchExtension "Cloudbase Open vSwitch Extension"; sleep 2; Restart-Service ovs-vswitchd +``` + +除此之外,Windows主机的设置与Linux主机相同。从[这里](https://github.com/openvswitch/ovn-kubernetes#k8s-minion-node-initializations)开始执行以下步骤。 + + +**Windows CNI 设置** + + + +现在,Windows OVN&OVS CNI 插件是基于 ovn_cni.exe 可以从[此处](https://cloudbase.it/downloads/ovn_cni.exe)下载。CNI 配置文件示例如下: + + +``` +{ + "name": "net", + "type": "ovn_cni.exe", + "bridge": "br-int", + "isGateway": "true", + "ipMasq": "false", + "ipam": { + "type": "host-local", + "subnet": "$SUBNET" + } +} +``` + +$SUBNET 是上一个 ```docker network create``` 命令中使用的子网。 + + +有关谷歌云平台(GCP),即谷歌计算引擎(GCE)的完整指南,请访问[这里](https://github.com/apprenda/kubernetes-ovn-heterogeneous-cluster#heterogeneous-kubernetes-cluster-on-top-of-ovn)。 + + +有关亚马逊网络服务(AWS),请访问[这里](https://github.com/justeat/kubernetes-windows-aws-ovs#kubernetes-on-windows-in-aws-using-ovn)。 + + +## 启动群集 +要启动集群,您需要启动基于 Linux 的 Kubernetes 控制平面和基于 Windows Server 的 Kubernetes 节点组件(kubelet 和 kube-proxy)。对于 OVS 和 OVN,仅需要 kubelet。 + + + +## 启动基于 Linux-based 的控制平面 +使用您喜欢的方法在 Linux 上启动 Kubernetes 集群。请注意,集群 CIDR 可能需要更新。 + + + +## 支持kubeadm加入 + + + +如果您的群集是由[kubeadm](/docs/setup/independent/create-cluster-kubeadm/),创建的 +使用上面列出的方法之一正确地设置网络(网络是在 kubeadm 之外设置的),您可以使用 kubeadm 向集群添加 Windows 节点。在较高的级别上,首先必须使用 kubeadm(Linux) 初始化主节点,然后设置基于 CNI 的网络(在 kubeadm 之外),最后开始将 Windows 或 Linux 工作节点连接到集群。如需其他文件和参考资料,请访问上文的 kubeadm 链接。 + + + +kubeadm 二进制文件可以在 [Kubernetes 版本](https://github.com/kubernetes/kubernetes/release)的节点二进制文件归档中找到。添加 Windows 节点与添加 Linux 节点没有任何不同: + + + +`kubeadm.exe join --token : --discovery-token-ca-cert-hash sha256:` + +有关更多详细信息请参阅[加入您的节点](/docs/setup/independent/create-cluster-kubeadm/#joining-your-nodes)。 + + +## 支持的功能 + + + +下面列出的示例假设在 Windows Server 1709 上运行 Windows 节点。如果您正在运行 Windows Server 2016,示例将需要更新镜像以指定 `image: microsoft/windowsservercore:ltsc2016`。这是因为在使用进程隔离时,需要容器镜像匹配主机操作系统版本。不指定标记将隐式地使用 `:latest` 标记,这可能导致令人惊讶的行为。有关 Windows Service Core 镜像标记的更多信息,请与[https://hub.docker.com/r/microsoft/windowsservercore/](https://hub.docker.com/r/microsoft/windowsservercore/)联系。 + + + +### 在 Windows 上调度 Pod +由于您的群集同时具有 Linux 和 Windows 节点,因此必须明确设置 nodeSelector 约束以便能够将 pod 安排到 Windows 节点。必须将 nodeSelector 的标签 beta.kubernetes.io/os 设置为值 windows; 请参阅以下示例: + + + +{{< codenew file="windows/simple-pod.yaml" >}} + +{{< note >}} +**Note:** 本例假设您在 Windows Server 1709 上运行,因此使用镜像标记来支持它。如果使用不同的版本,则需要更新标记。例如,如果在 Windows Server 2016 上,更新为使用 `"image": "microsoft/iis"`,默认为该操作系统版本。 +{{< /note >}} + + + +### Secrets 和 ConfigMaps +secret和configmap可以在Windows Service 容器中使用,但是必须作为环境变量使用。有关更多细节,请参见下面的限制部分。 + + + +**例子:** + + + +Windows pod 与 secrets 映射到环境变量 + + +{{< codenew file="windows/secret-pod.yaml" >}} + +具有 configMap 值的 Windows Pod 映射到环境变量 + + +{{< codenew file="windows/configmap-pod.yaml" >}} + +### 卷 +一些受支持的卷挂载可以是本地卷,emptyDir 卷和主机路径卷。需要记住的一点是,路径必须转义,或者使用前斜杠,例如:`mountPath: "C:\\etc\\foo"` or `mountPath: "C:/etc/foo"`。 + + + +对于受支持的卷类型,支持持久卷的声明。 + + +**例子:** + + + +带有主机路径卷的 Windows pod + + +{{< codenew file="windows/hostpath-volume-pod.yaml" >}} + + +具有多个 emptyDir 卷的 Windows pod + + +{{< codenew file="windows/emptydir-pod.yaml" >}} + +### 守护线程集 + + + +支持守护线程集 + + +{{< codenew file="windows/daemonset.yaml" >}} + +### 指标 + + + +Windows Stats 使用混合模型:pod 和容器级别的统计数据来自 CRI(通过 dockershim),而节点级别的统计数据来自“winstats”包,该包使用特定于 Windows 的 perf 计数器导出 cadvisor 之类的数据结构。 + + +### 容器资源 + + + +现在可以为 v1.10 中的 windows 容器设置容器资源(CPU和内存)。 + + +{{< codenew file="windows/deploy-resource.yaml" >}} + +### Hyper-V 容器 + + + +Hyper-V 容器在 v1.10 中作为实验支持。要创建 Hyper-V 容器,kubelet 应该从特性 gates `HyperVContainer=true` 开始,Pod 应该包含注释 `experimental.windows.kubernetes.io/isolation-type=hyperv`。 + + +{{< codenew file="windows/deploy-hyperv.yaml" >}} + +### Kubelet 和 kube-proxy 现在可以作为 Windows 服务运行 + + + +从 kubernetes v1.11 开始,kubelet 和 kube-proxy 可以作为 Windows 服务运行。 + + +这意味着您现在可以通过 `sc` 命令将它们注册为 Windows 服务。有关如何使用 `sc` 创建 Windows 服务的更多细节,请参阅[此处](https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe)。 + + +**例子:** + + + +创建服务 + + +``` +PS > sc.exe create binPath= " --service " +CMD > sc create binPath= " --service " +``` + +请注意,如果参数包含空格,则必须对其进行转义。例: + + +``` +PS > sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " +CMD > sc create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " +``` + +启动服务: + + +``` +PS > Start-Service kubelet; Start-Service kube-proxy +CMD > net start kubelet && net start kube-proxy +``` + +停止服务 + + +``` +PS > Stop-Service kubelet (-Force); Stop-Service kube-proxy (-Force) +CMD > net stop kubelet && net stop kube-proxy +``` + +查询服务 + + +``` +PS > Get-Service kubelet; Get-Service kube-proxy; +CMD > sc.exe queryex kubelet && sc qc kubelet && sc.exe queryex kube-proxy && sc.exe qc kube-proxy +``` + +## Windows Server 容器与 v1.9 的已知限制 + + + +在未来的Kubernetes版本中,社区将解决其中一些限制: + + +- 共享网络名称空间(隔间)与多个 Windows Server 容器(共享内核)每个 pod 只支持在 Windows Server 1709 或更高 + + + +- 不支持使用 secret 和 configmap 作为卷装载 + + + +- Windows不支持挂载传播 + + + +- 不支持有状态应用程序的状态集功能 + + + +- Windows Server 容器 pod 的相同 pod 自动缩放尚未经过验证,pod 端之间无法工作。 + + + +- 不支持Hyper-V隔离容器。 + + + +- Windows 容器操作系统必须与主机操作系统匹配。如果它不这样做,pod 就会陷入崩溃循环。 + + + +- 在 L3 或主机 GW 的网络模型下,由于 Windows 问题,Windows 节点无法访问 + + + +- Windows kubelet.exe 在 VMware Fusion 下运行 Windows Server 时,可能无法启动[issue 57110](https://github.com/kubernetes/kubernetes/pull/57124) + + + +- Flannel 和 Weavenet 尚未得到支持 + + + +- 一些 .Net 核心应用程序希望环境变量的名称中带有冒号 (`:`)。Kubernetes 目前不允许这样做。根据[此处](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment)所述,用双下划线 (`__`) 替换冒号 (':') + + + +- 由于 cgroups 在 windows 上不受支持,kubelet.exe 应该以以下附加参数开始 `--cgroups-per-qos=false --enforce-node-allocatable=""` [issue 61716](https://github.com/kubernetes/kubernetes/issues/61716) + + + +## 后续步骤和资源 + + + +- 对Windows版本的支持从v1.9开始测试,欢迎您提供反馈。有关参与的信息,请访问[SIG-Windows](https://github.com/kubernetes/community/blob/master/sig-windows/README.md) +- 故障排除和常见问题:[链接](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/common-problems) + + diff --git a/content/zh/docs/getting-started-guides/windows/ovn_kubernetes.png b/content/zh/docs/getting-started-guides/windows/ovn_kubernetes.png new file mode 100644 index 0000000000..739d75aad7 Binary files /dev/null and b/content/zh/docs/getting-started-guides/windows/ovn_kubernetes.png differ diff --git a/content/zh/docs/getting-started-guides/windows/sample-l2bridge-wincni-config.json b/content/zh/docs/getting-started-guides/windows/sample-l2bridge-wincni-config.json new file mode 100644 index 0000000000..f3842026ce --- /dev/null +++ b/content/zh/docs/getting-started-guides/windows/sample-l2bridge-wincni-config.json @@ -0,0 +1,49 @@ +{ + "cniVersion": "0.2.0", + "name": "l2bridge", + "type": "wincni.exe", + "master": "Ethernet", + "ipam": { + "environment": "azure", + "subnet": "10.10.187.64/26", + "routes": [ + { + "GW": "10.10.187.66" + } + ] + }, + "dns": { + "Nameservers": [ + "11.0.0.10" + ] + }, + "AdditionalArgs": [ + { + "Name": "EndpointPolicy", + "Value": { + "Type": "OutBoundNAT", + "ExceptionList": [ + "11.0.0.0/8", + "10.10.0.0/16", + "10.127.132.128/25" + ] + } + }, + { + "Name": "EndpointPolicy", + "Value": { + "Type": "ROUTE", + "DestinationPrefix": "11.0.0.0/8", + "NeedEncap": true + } + }, + { + "Name": "EndpointPolicy", + "Value": { + "Type": "ROUTE", + "DestinationPrefix": "10.127.132.213/32", + "NeedEncap": true + } + } + ] +} diff --git a/content/zh/docs/getting-started-guides/windows/windows-setup.png b/content/zh/docs/getting-started-guides/windows/windows-setup.png new file mode 100644 index 0000000000..e11c58d596 Binary files /dev/null and b/content/zh/docs/getting-started-guides/windows/windows-setup.png differ diff --git a/content/zh/docs/home/supported-doc-versions.md b/content/zh/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000..94bc47b367 --- /dev/null +++ b/content/zh/docs/home/supported-doc-versions.md @@ -0,0 +1,55 @@ +--- +title: Kubernetes 文档支持的版本 +content_template: templates/concept +--- + +{{% capture overview %}} + +本网站包含当前版本和之前四个版本的 Kubernetes 文档。 + +{{% /capture %}} + +{{% capture body %}} + +## 当前版本 + +当前版本是 +[{{< param "version" >}}](/)。 + +## 之前的版本 + +{{< versions-other >}} + +{{% /capture %}} + + + + \ No newline at end of file diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md new file mode 100644 index 0000000000..25cc2d5334 --- /dev/null +++ b/content/zh/docs/reference/_index.md @@ -0,0 +1,130 @@ +--- +title: 参考 +approvers: +- chenopis +linkTitle: "参考" +main_menu: true +weight: 70 +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +这是 Kubernetes 文档的参考部分。 + +{{% /capture %}} + +{{% capture body %}} + +## API 参考 + +* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 +* Kubernetes API 版本 + * [1.12](/docs/reference/generated/kubernetes-api/v1.12/) + * [1.11](/docs/reference/generated/kubernetes-api/v1.11/) + * [1.10](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/) + * [1.9](https://v1-9.docs.kubernetes.io/docs/api-reference/v1.9/) + * [1.8](https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/) + * [1.7](https://v1-7.docs.kubernetes.io/docs/api-reference/v1.7/) + + + +## API 客户端库 + +如果您需要通过编程语言调用 Kubernetes API,您可以使用 +[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的 +客户端库: + +- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) +- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) +- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) + + + +## CLI 参考 + +* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具,用于运行命令和管理 Kubernetes 集群。 + * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 +* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 +* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 + + + +## 配置参考 + +* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 +* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API,用于验证和配置 API 对象(如 pod,服务,副本控制器)的数据。 +* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程,它嵌入到了 Kubernetes 的附带的核心控制循环。 +* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 +* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序,用于管理可用性、性能和容量。 +* [federation-apiserver](/docs/admin/federation-apiserver/) - 联邦集群的 API 服务器。 +* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 一个守护进程,它嵌入到了 Kubernetes 联邦的附带的核心控制循环。 + + + +## 设计文档 + +Kubernetes 功能的设计文档归档,不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 + + +{{% /capture %}} diff --git a/content/zh/docs/reference/access-authn-authz/_index.md b/content/zh/docs/reference/access-authn-authz/_index.md new file mode 100644 index 0000000000..502ee255b7 --- /dev/null +++ b/content/zh/docs/reference/access-authn-authz/_index.md @@ -0,0 +1,13 @@ +--- +title: 访问 API +weight: 20 +toc-hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md index 8ca313af01..4e13befdf9 100644 --- a/content/zh/docs/reference/access-authn-authz/authorization.md +++ b/content/zh/docs/reference/access-authn-authz/authorization.md @@ -28,12 +28,12 @@ that Kubernetes authorization works with existing organization-wide or cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API. --> -在Kubernetes中,您必须在授权(授予访问权限)之前进行身份验证(登录),有关身份验证的信息, +在 Kubernetes 中,您必须在授权(授予访问权限)之前进行身份验证(登录),有关身份验证的信息, 请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/). -Kubernetes期望REST API请求中常见的属性。 -这意味着Kubernetes授权适用于现有的组织范围或云提供商范围的访问控制系统, -除了Kubernetes API之外,它还可以处理其他API。 +Kubernetes 期望 REST API 请求中常见的属性。 +这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统, +除了 Kubernetes API 之外,它还可以处理其他 API。 ## 审查您的请求属性 -Kubernetes仅审查以下API请求属性: +Kubernetes 仅审查以下 API 请求属性: - * **user** - 身份验证期间提供的`user`字符串。 + * **user** - 身份验证期间提供的 `user` 字符串。 * **group** - 经过身份验证的用户所属的组名列表。 * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。 * **API** - 指示请求是否针对 API 资源。 - * **Request path** - 各种非资源端点的路径,如`/api`或`/healthz`。 - * **API request verb** - API 动词`get`,`list`,`create`,`update`,`patch`,`watch`,`proxy`,`redirect`,`delete`和`deletecollection`用于资源请求。要确定资源API端点的请求动词,请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。 - * **HTTP request verb** - HTTP 动词`get`,`post`,`put`和`delete`用于非资源请求。 - * **Resource** - 正在访问的资源的 ID 或名称(仅限资源请求) - 对于使用`get`,`update`,`patch`和`delete`动词的资源请求,您必须提供资源名称。 + * **Request path** - 各种非资源端点的路径,如 `/api` 或 `/healthz`。 + * **API request verb** - API 动词 `get`,`list`,`create`,`update`,`patch`,`watch`,`proxy`,`redirect`,`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词,请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。 + * **HTTP request verb** - HTTP 动词 `get`,`post`,`put` 和 `delete` 用于非资源请求。 + * **Resource** - 正在访问的资源的 ID 或名称(仅限资源请求) - 对于使用 `get`,`update`,`patch` 和 `delete` 动词的资源请求,您必须提供资源名称。 * **Subresource** - 正在访问的子资源(仅限资源请求)。 * **Namespace** - 正在访问的对象的名称空间(仅适用于命名空间资源请求)。 - * **API group** - 正在访问的 API 组(仅限资源请求)。空字符串表示[核心API组](/docs/concepts/overview/kubernetes-api/)。 + * **API group** - 正在访问的 API 组(仅限资源请求)。空字符串表示[核心 API 组](/docs/concepts/overview/kubernetes-api/)。 -#### 检查API访问 +#### 检查 API 访问 -`kubectl`提供`auth can-i`子命令,用于快速查询 API 授权层。 -该命令使用`SelfSubjectAccessReview` API来确定当前用户是否可以执行给定操作,并且无论使用何种授权模式都可以工作。 +`kubectl` 提供 `auth can-i` 子命令,用于快速查询 API 授权层。 +该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作,并且无论使用何种授权模式都可以工作。 ```bash $ kubectl auth can-i create deployments --namespace dev @@ -192,14 +192,14 @@ These APIs can be queried by creating normal Kubernetes resources, where the res field of the returned object is the result of the query. --> -`SelfSubjectAccessReview`是`authorization.k8s.io` API组的一部分,它将 API 服务器授权公开给外部服务。 +`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分,它将 API 服务器授权公开给外部服务。 该组中的其他资源包括: -* `SubjectAccessReview` - 访问任何用户的 Review ,而不仅仅是当前用户。用于将授权决策委派给API服务器。例如,kubelet 和扩展 API 服务器使用它来确定用户对自己的API的访问权限。 -* `LocalSubjectAccessReview` - 与`SubjectAccessReview`类似,但仅限于特定的命名空间。 -* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限,或者用于隐藏/显示操作的UI。 +* `SubjectAccessReview` - 访问任何用户的 Review ,而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如,kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。 +* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似,但仅限于特定的命名空间。 +* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限,或者用于 UI 中的隐藏/显示动作。 -可以通过创建普通 Kubernetes 资源来查询这些 API ,其中返回对象的响应“status”字段是查询的结果。 +可以通过创建普通 Kubernetes 资源来查询这些 API ,其中返回对象的响应 “status” 字段是查询的结果。 ```bash $ kubectl create -f - -o yaml << EOF @@ -247,20 +247,20 @@ You can choose more than one authorization module. Modules are checked in order so an earlier module has higher priority to allow or deny a request. --> -## 为您的授权模块使用标志 +## 为您的授权模块应用参数 -您必须在策略中包含一个标志,以指明您的策略包含哪个授权模块: +您必须在策略中包含一个参数标志,以指明您的策略包含哪个授权模块: -可以使用以下标志: +可以使用以下参数: * `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。 * `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用 Kubernetes API 创建和存储策略。 - * `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式,允许您使用远程REST端点管理授权。 - * `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式,专门授权由 kubelet 发出的API请求。 + * `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式,允许您使用远程 REST 端点管理授权。 + * `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式,专门授权由 kubelet 发出的 API 请求。 * `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。 * `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。 -您可以选择多个授权模块。按顺序检查模块,以便较早的模块具有更高的优先级来允许或拒绝请求。 +您可以选择多个授权模块。模块按顺序检查,以便较早的模块具有更高的优先级来允许或拒绝请求。 -## 通过pod创建权限升级 +## 通过 Pod 创建升级权限 -能够在命名空间中创建 pod 的用户可能会升级其在该命名空间内的权限。 -他们可以创建在该命名空间内访问其权限的 pod 。 -他们可以创建用户无法自己读取 secret 的 pod ,或者在具有不同/更高权限的服务帐户下运行的 pod 。 +能够在命名空间中创建 Pod 的用户可能会升级其在该命名空间内的权限。 +他们可以创建在该命名空间内访问其权限的 Pod 。 +他们可以创建用户无法自己读取 secret 的 Pod ,或者在具有不同/更高权限的服务帐户下运行的 Pod 。 {{< caution >}} -**注意:** 系统管理员在授予对 pod 创建的访问权限时要小心。 -授予在命名空间中创建 pod(或创建pod的控制器)的权限的用户可以: -读取命名空间中的所有秘密;读取命名空间中的所有配置映射; +**注意:** 系统管理员在授予对 Pod 创建的访问权限时要小心。 +授予在命名空间中创建 Pod(或创建 Pod 的控制器)的权限的用户可以: +读取命名空间中的所有 secret;读取命名空间中的所有 ConfigMap; 并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。 无论采用何种授权方式,这都适用。 {{< /caution >}} @@ -299,6 +299,6 @@ mode. * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/). * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). --> -* 要了解有关身份验证的更多信息,请参阅 **身份验证** [控制对Kubernetes API的访问](/docs/reference/access-authn-authz/controlling-access/). -* 要了解有关准入控制的更多信息,请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/). +* 要了解有关身份验证的更多信息,请参阅 **身份验证** [控制对 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)。 +* 要了解有关准入控制的更多信息,请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/)。 {{% /capture %}} \ No newline at end of file diff --git a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md new file mode 100644 index 0000000000..59f36285a4 --- /dev/null +++ b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -0,0 +1,296 @@ +--- +reviewers: +- jbeda +title: 使用 Bootstrap Token 进行鉴权 +content_template: templates/concept +weight: 20 +--- + + +{{% capture overview %}} + +Bootstrap token 是一种简单的 bearer token,用于创建新集群或将新节点连接到现有集群。它被用来支持 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/),但是对于那些希望在没有 `kubeadm` 的情况下创建集群的用户,也可以在其他环境中使用。它也可以通过 RBAC 策略用于 [Kubelet TLS +Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统。 +{{% /capture %}} + +{{% capture body %}} + +## Bootstrap Token 概览 + + +Bootstrap Token 在 `kube-system` 命名空间中使用特定类型 (`bootstrap.kubernetes.io/token`) 的 secret 来定义。 +然后,这些 Secret 被 API Server 中的 Bootstrap Authenticator 读取。过期的 token 被 Controller Manager 中的 TokenCleaner 控制器移除。 +这些 Token 也被 BootstrapSigner 控制器在一个"发现"的过程中用来为特定的 ConfigMap 创建签名。 + +{{< feature-state state="beta" >}} + + +## Token 格式 + + +Bootstrap Token 采用 `abcdef.0123456789abcdef` 的形式。为了更加正式,它们必须匹配正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。 + + +Token 的第一部分是 "Token ID" 并且被认为是公共信息。这部分会在引用一个 token 但是不想泄露那些用于鉴权的私密部分时被用到。第二部分则是 "Token Secret",应该仅与受信任方共享。 + + +## 启用 Bootstrap Token 鉴权 + + +Bootstrap Token authenticator 可以通过在 API server 上添加下列标志来启用。 + +``` +--enable-bootstrap-token-auth +``` + + +被启用时,Bootstrap Token 可以被用来作为针对 API server 鉴权请求的 bearer token 凭据。 + +```http +Authorization: Bearer 07401b.f395accd246ae52d +``` + + +Token 鉴权信息为:用户名 `system:bootstrap:` 且在 `system:bootstrappers` 组内。我们也可以在 token 的 Secret 中指定其它组信息。 + + +过期的 token 可以通过启用 controller manager 中的 `tokencleaner` 控制器来自动删除。 + +``` +--controllers=*,tokencleaner +``` + + +## Bootstrap Token Secret 格式 + + +每个有效的 token 都对应着 `kube-system` 命名空间中的一个 secret。您可以从 [这里](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md) 获得整个的设计文档。 + + +Secret 样例如下所示。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + # Name MUST be of form "bootstrap-token-" + name: bootstrap-token-07401b + namespace: kube-system + +# Type MUST be 'bootstrap.kubernetes.io/token' +type: bootstrap.kubernetes.io/token +stringData: + # Human readable description. Optional. + description: "The default bootstrap token generated by 'kubeadm init'." + + # Token ID and secret. Required. + token-id: 07401b + token-secret: f395accd246ae52d + + # Expiration. Optional. + expiration: 2017-03-10T03:22:11Z + + # Allowed usages. + usage-bootstrap-authentication: "true" + usage-bootstrap-signing: "true" + + # Extra groups to authenticate the token as. Must start with "system:bootstrappers:" + auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress +``` + + +Secret 的类型必须是 `bootstrap.kubernetes.io/token` 并且名字的格式必须是 `bootstrap-token-`。它必须被放在 `kube-system` 命名空间中。 + + +`usage-bootstrap-*` 的成员指出了这个 secret 的作用。值被设定为 `true` 时才会启用。 + + +* `usage-bootstrap-authentication` 表示这个 token 可以被用来作为针对 API server 鉴权请求的 bearer token 凭据。 + +* `usage-bootstrap-signing` 表示这个 token 可以被用来对 `cluster-info` ConfigMap 通过下述方式来签名。 + + +`expiration` 字段控制 token 的到期。过期的 token 会在用于身份验证时被拒绝,在 ConfigMap 签名时被忽略。 +使用 RFC3339 将过期时间编码为绝对 UTC 时间。启用 `tokencleaner` 控制器来自动删除过期的 token。 + + +## 使用 kubeadm 管理 token + + +您可以在集群中使用 `kubeadm` 工具来管理 token。查阅 [kubeadm token 文档](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 获取更多信息。 + + +## ConfigMap 签名 + + +除了身份验证之外,token 还可用于对 ConfigMap 进行签名。 +这个用于在客户端和 API Server 互信之前,在集群引导过程的前期使用。 +签名的 ConfigMap 可以通过共享 token 进行身份鉴权。 + + +通过启用 Controller Manager 中的 `bootstrapsigner` 控制器来启用 ConfigMap 签名选项。 + +``` +--controllers=*,bootstrapsigner +``` + + +被签名的 ConfigMap 作为 `kube-public` 命名空间中的 `cluster-info` 存在。 +典型的流程是客户端在未经身份验证和忽略 TLS 错误时读取此 ConfigMap。 +然后通过嵌入 ConfigMap 中的签名来校验 ConfigMap。 + + +ConfigMap 样例如下所示: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: cluster-info + namespace: kube-public +data: + jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U + kubeconfig: | + apiVersion: v1 + clusters: + - cluster: + certificate-authority-data: + server: https://10.138.0.2:6443 + name: "" + contexts: [] + current-context: "" + kind: Config + preferences: {} + users: [] +``` + + +ConfigMap 的 `kubeconfig` 成员是一个配置文件,里面只填写了集群信息。 +在通信过程中的关键是 `certificate-authority-data`。这部分可能在将来会扩展。 + + +签名是使用“分离”模式的 JWS 签名。 +为了验证签名,用户应该根据 JWS 规则加密 `kubeconfig`的信息(base64 编码,同时丢弃任何的 `=`)。 +然后将使用该编码的信息插入 2 个点之间来形成整个 JWS。 +您可以使用 `HS256` 方案(HMAC-SHA256)验证 JWS,并使用完整令牌(例如 `07401b.f395accd246ae52d`)作为共享密钥。 用户 _必须_ 验证 HS256 是否被使用。 + +{{< warning >}} + +**注意:** 拥有 bootstrapping token 任何一方都可以为该 token 创建有效签名。 +当使用 ConfigMap 签名时,不建议许多客户端共享相同的 token,因为受入侵的客户端可能会作为中间人为其它客户端来引导 TLS 信任。 +{{< /warning >}} + + +参阅 [kubeadm 安全模型](/docs/reference/generated/kubeadm/#security-model) 获取更多信息。 +{{% /capture %}} diff --git a/content/zh/docs/reference/access-authn-authz/node.md b/content/zh/docs/reference/access-authn-authz/node.md new file mode 100644 index 0000000000..255efffdc4 --- /dev/null +++ b/content/zh/docs/reference/access-authn-authz/node.md @@ -0,0 +1,201 @@ +--- +title: 使用 Node 鉴权 +content_template: templates/concept +weight: 90 +--- + + +{{% capture overview %}} +节点鉴权是一种特殊用途的鉴权模式,专门对 kubelet 发出的 API 请求进行鉴权。 + +{{% /capture %}} + +{{% capture body %}} +## 概述 + + +节点鉴权器允许 kubelet 执行 API 操作。包括: + + +读取操作: + + +* services +* endpoints +* nodes +* pods +* secrets、configmaps、以及绑定到 kubelet 的节点的 pod 的持久卷申领和持久卷 + + +写入操作: + + +* 节点和节点状态(启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点) +* Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod) +* 事件 + + +鉴权相关操作: + + +* 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限 +* 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力 + + +在将来的版本中,节点鉴权器可能会添加或删除权限,以确保 kubelet 具有正确操作所需的最小权限集。 + + +为了获得节点鉴权器的授权,kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中,用户名为 `system:node:`。 +上述的组名和用户名格式要与 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。 + + +要启用节点授权器,请使用 `--authorization-mode = Node` 启动 apiserver。 + + +要限制 kubelet 具有写入权限的 API 对象,请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver,从而启用 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。 + + +## 迁移考虑因素 + + +### 在 `system:nodes` 组之外的 Kubelet + + +`system:nodes` 组之外的 kubelet 不会被 `Node` 鉴权模式授权,并且需要继续通过当前授权它们的机制来授权。 +节点准入插件不会限制来自这些 kubelet 的请求。 + + +### 具有无差别用户名的 Kubelet + + +在一些部署中,kubelet 具有 `system:nodes` 组的凭证,但是无法给出它们所关联的节点的标识,因为它们没有 `system:node:...` 格式的用户名。 +这些 kubelet 不会被 `Node` 授权模式授权,并且需要继续通过当前授权它们的任何机制来授权。 + + +因为默认的节点标识符实现不会把它当作节点身份标识,`NodeRestriction` 准入插件会忽略来自这些 kubelet 的请求。 + + +### 相对于以前使用 RBAC 的版本的更新 + + +升级的 1.7 之前的使用 [RBAC](/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行,因为 `system:nodes` 组绑定已经存在。 + + +如果集群管理员希望开始使用 `Node` 鉴权器和 `NodeRestriction` 准入插件来限制节点对 API 的访问,这一需求可以通过下列操作来完成且不会影响已部署的应用: + + +1. 启用 `Node` 鉴权模式 (`--authorization-mode=Node,RBAC`) 和 `NodeRestriction` 准入插件 +2. 确保所有 kubelet 的凭据符合组/用户名要求 +3. 审核 apiserver 日志以确保 `Node` 鉴权器不会拒绝来自 kubelet 的请求(日志中没有持续的 `NODE DENY` 消息) +4. 删除 `system:node` 集群角色绑定 + + +### RBAC 节点权限 + + +在 1.6 版本中,当使用 [RBAC 鉴权模式](/docs/reference/access-authn-authz/rbac/) 时,`system:nodes` 集群角色会被自动绑定到 `system:node` 组。 + + +在 1.7 版本中,不再推荐将 `system:nodes` 组自动绑定到 `system:node` 角色,因为节点鉴权器通过对 secret 和 configmap 访问的额外限制完成了相同的任务。 +如果同时启用了 `Node` 和 `RBAC` 授权模式,1.7 版本则不会创建 `system:nodes` 组到 `system:node` 角色的自动绑定。 + + +在 1.8 版本中,绑定将根本不会被创建。 + + +使用 RBAC 时,将继续创建 `system:node` 集群角色,以便与将其他用户或组绑定到该角色的部署方法兼容。 + +{{% /capture %}} diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md new file mode 100644 index 0000000000..a962c5ddfb --- /dev/null +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -0,0 +1,220 @@ +--- +reviewers: +- bprashanth +- davidopp +- lavalamp +- liggitt +title: 管理 Service Accounts +content_template: templates/concept +weight: 50 +--- + + + +{{% capture overview %}} + + +这是一个关于 service accounts 的集群管理指南,它假设您了解 [Service Accounts 用户指南](/docs/user-guide/service-accounts)。 + + +计划支持授权和用户帐户,但并不完整。有时会引用不完整的功能以便更好地描述 service accounts。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 用户帐户与 service accounts + + +Kubernetes 区分用户帐户和 service account 的概念有以下几个原因: + + + + - 用户帐户是针对用户的。Service accounts 用于进程,这些进程在 pods 中运行。 + - 用户帐户应该是全局性的。名称必须在集群的所有命名空间中都是唯一的,未来的用户资源将不会使用命名空间。Service accounts 使用命名空间。 + - 通常,集群的用户帐户可能与企业数据库同步,在企业数据库中,新用户帐户的创建需要特殊的权限,并且与复杂的业务流程相关联。 + Service account 创建的目的是更加轻量级,允许集群用户为特定任务创建 Service account (即:最小特权原则)。 + - 对人员和 Service account 的审计考虑可能有所不同。 + - 复杂系统的配置包可能包括该系统组件的各种 Service account 的定义。由于 Service account 可以临时创建并具有命名空间名称,因此这种配置是可移植的。 + + + +## Service account 自动化 + + +三个独立的组件合作实现 service accounts 的自动化: + + + + - Service account 准入控制器 + - 令牌控制器 + - Service account 控制器 + + + +### Service Account 准入控制器 + + +pod 的修改是通过一个名为[准入控制器](/docs/reference/access-authn-authz/admission-controllers/)的插件实现的。它是 apiserver 的一部分。它可以同步操作,以便在创建或更新 pod 时对其进行修改。 +当此插件处于活动状态时(默认情况下在大多数发行版中),则在创建或修改 pod 时执行以下操作: + + + + 1. 如果 pod 没有设置 `ServiceAccount`,它将 `ServiceAccount` 设置为 `default`。 + 2. 它确保 pod 引用的 `ServiceAccount` 存在,否则拒绝它。 + 3. 如果 pod 不包含任何 `ImagePullSecrets`,则将 `ServiceAccount` 的 `ImagePullSecrets` 添加到 pod 中。 + 4. 它向包含 API 访问令牌的 pod 添加了一个 `volume`。 + 5. 它为 pod 内的每个容器添加一个 `volumeSource`,该 volume 被挂载到 `/var/run/secrets/kubernetes.io/serviceaccount`。 + + + +### 令牌控制器 + + +TokenController 作为控制器-管理器的一部分异步运行。它用于: + + + +- 观察 serviceAccount 创建并创建相应的 Secret 以允许 API 访问。 +- 观察 serviceAccount 删除并删除所有相应的 ServiceAccountToken Secrets。 +- 观察 secret 添加,并确保引用的 ServiceAccount 存在,并在需要时向该 secret 添加令牌。 +- 观察 secret 删除并在需要时从相应的 ServiceAccount 中删除引用。 + + +您必须使用 `--service-account-private-key-file` 选项将 service account 私钥文件传递给控制器-管理器中的令牌控制器。 +私钥将用于签署生成的 service account 令牌。同样,您必须使用 `--service-account-key-file` 选项将相应的公钥传递给 +kube-apiserver。公钥将用于在身份验证期间验证令牌。 + + + +#### 创建其他 API 令牌 + + +控制器循环确保每个 service account 都存在具有 API 令牌的 secret。要为 service account 创建其他 API 令牌, +请使用 ServiceAccountToken 引用 service account 的注解创建类型的 secret,控制器将使用生成的令牌更新它: + +secret.json: + +```json +{ + "kind": "Secret", + "apiVersion": "v1", + "metadata": { + "name": "mysecretname", + "annotations": { + "kubernetes.io/service-account.name": "myserviceaccount" + } + }, + "type": "kubernetes.io/service-account-token" +} +``` + +```shell +kubectl create -f ./secret.json +kubectl describe secret mysecretname +``` + + + +#### 删除/无效化 一个 service account 令牌 + +```shell +kubectl delete secret mysecretname +``` + + + +### Service Account 控制器 + + +Service Account 控制器在命名空间中管理 ServiceAccount,并确保每个活动命名空间中都存在一个名为 `default` 的 ServiceAccount。 + +{{% /capture %}} diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh/docs/reference/access-authn-authz/webhook.md new file mode 100644 index 0000000000..d9f4f10662 --- /dev/null +++ b/content/zh/docs/reference/access-authn-authz/webhook.md @@ -0,0 +1,239 @@ +--- +title: Webhook 模式 +content_template: templates/concept +weight: 95 +--- + + + +{{% capture overview %}} + +WebHook 是一种 HTTP 回调:一种当有事情发生时的 HTTP POST 请求;一种基于 HTTP POST 方式完成的事件通知。实现了 WebHook 的 Web 应用会在特定事件发生时通过 POST 向某 URL 发送消息。 +{{% /capture %}} + +{{% capture body %}} + +当 `Webhook` 模式被启用时,Kubernetes 会在需要确定用户权限时访问外部 REST 服务。 + + +## 配置文件格式 + + +`Webhook` 模式需要一个通过 `--authorization-webhook-config-file=SOME_FILENAME` 参数指定的 HTTP 配置文件。 + + +配置文件使用 [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文件格式。在文件中,"users" 对应 API 服务器 webhook,"clusters" 指远程服务。 + + +使用 HTTPS 客户端鉴权的配置文件示例: + + + +```yaml +# Kubernetes API 版本 +apiVersion: v1 +# API 对象类型 +kind: Config +# 远程服务对应的集群。 +clusters: + - name: name-of-remote-authz-service + cluster: + # 远程服务验证所需 CA + certificate-authority: /path/to/ca.pem + # 用来访问远程服务的 URL。必须使用 'https'。不可以包含参数。 + server: https://authz.example.com/authorize + +# API 服务器的 webhook 配置对应的用户 +users: + - name: name-of-api-server + user: + client-certificate: /path/to/cert.pem # webhook 插件所使用的证书 + client-key: /path/to/key.pem # 与证书对应的密钥 + +# kubeconfig 文件所需上下文。提供给 API 服务器使用。 +current-context: webhook +contexts: +- context: + cluster: name-of-remote-authz-service + user: name-of-api-server + name: webhook +``` + + +## 请求的载荷 + + +鉴权时,API 服务器使用 POST 方式发送一条 JSON-序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述操作。此对象包含了描述发出请求的用户的字段,还包含了将要被访问的资源信息或请求属性。 + + +请注意,webhook API 对象和其它 Kubernetes API 对象一样遵循[版本兼容性规则](/docs/concepts/overview/kubernetes-api/)。 +实现者应当注意 beta 版本对象的兼容性承诺是相当宽松的,并检查请求的 "apiVersion" 字段来保证正确的反序列化。此外,API服务器必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 + + +请求体示例: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "kittensandponies", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + }, + "user": "jane", + "group": [ + "group1", + "group2" + ] + } +} +``` + + +远程服务应当填写请求的 `status` 字段,并且返回是否允许访问的响应。响应体的 `spec` 字段应当被忽略,且可以被省略。允许访问的响应返回格式如下: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "status": { + "allowed": true + } +} +``` + + +远程服务拒绝访问的返回格式如下: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "status": { + "allowed": false, + "reason": "user does not have read access to the namespace" + } +} +``` + + +对非资源路径的请求格式如下: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "nonResourceAttributes": { + "path": "/debug", + "verb": "get" + }, + "user": "jane", + "group": [ + "group1", + "group2" + ] + } +} +``` + + +非资源路径包括: `/api`、`/apis`、`/metrics`、`/resetMetrics`、`/logs`、`/debug`、 +`/healthz`、`/swagger-ui/`、`/swaggerapi/`、`/ui` 和 `/version`。 +客户端需要访问 `/api`、`/api/*`、`/apis`、`/apis/*` 和 `/version` 来获取服务器上存在资源和版本列表。 +对其它非资源路径的访问可以被禁止;这样做并不会影响对 REST API 的访问。 + + +关于 Webhook 模式的更多信息可参阅 authorization.v1beta1 API 对象的参考指南和 [webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go) 文件。 + +{{% /capture %}} diff --git a/content/zh/docs/reference/command-line-tools-reference/_index.md b/content/zh/docs/reference/command-line-tools-reference/_index.md new file mode 100644 index 0000000000..32581e8181 --- /dev/null +++ b/content/zh/docs/reference/command-line-tools-reference/_index.md @@ -0,0 +1,13 @@ +--- +title: 命令行工具参考 +weight: 60 +toc-hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md new file mode 100644 index 0000000000..47a8ecbf47 --- /dev/null +++ b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -0,0 +1,1192 @@ +--- +title: kube-apiserver +notitle: true +--- +## kube-apiserver + + + + +### 概要 + + + +Kubernetes API 服务器验证并配置 api 对象的数据,包括 pods、services、replication controllers 和其他对象。API 服务器为 REST 操作提供服务,并为集群的共享状态提供前端。所有其他组件通过该状态进行交互。 + +``` +kube-apiserver [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--admission-control-config-file string
指定准入控制配置文件。
--advertise-address ip
指定服务器为集群中成员发布的 IP 地址。该地址必须能被其他机器访问。如果该参数留空,服务器会使用 --bind-address 所指定的地址。如果 --bind-address 也没有设定,则会使用该主机的默认网络接口。
--allow-privileged     Default: false
指定是否允许使用特权容器(默认值:false)。
--anonymous-auth     Default: true
指定是否允许 API 服务器的安全端口接受匿名请求(默认值:true)。匿名请求即没有被其他认证方法拒绝的请求,其用户名均为 system:anonymous,组名均为 system:unauthenticated。
--apiserver-count int     Default: 1
指定集群中运行的 API 服务器数量(默认值:1),值必须是正整数。该参数在 --endpoint-reconciler-type=master-count 时使用。
--audit-log-batch-buffer-size int     Default: 10000
指定存储批处理和写入事件的缓冲区字节数(默认值:10000)。只在批处理模式下使用。
--audit-log-batch-max-size int     Default: 1
指定一个批处理的最大长度(默认值:1)。只在批处理模式下使用。
--audit-log-batch-max-wait duration
指定尚未达到最大值的批处理的强制写入等待时间。只在批处理模式下使用。
--audit-log-batch-throttle-burst int
指定在未使用 ThrottleQPS 时同时发送请求的最大数量。只在批处理模式下使用。
--audit-log-batch-throttle-enable
指定是否启用 batching throttling。只在批处理模式下使用。
--audit-log-batch-throttle-qps float32
设定每秒内可执行的批处理的最大平均数。只在批处理模式下使用。
--audit-log-format string     Default: "json"
指定存储审计日志的格式。legacy 表示每个事件记录 1 行文本;json 表示以结构化 json 格式记录。目前仅支持 legacy 和 json(默认值:json)。
--audit-log-maxage int
指定历史审计日志的最大保存天数,以日志文件名中的时间戳为准。
--audit-log-maxbackup int
指定历史审计日志的最大保存数量。
--audit-log-maxsize int
指定审计日志流转前的最大大小(单位:MB)。
--audit-log-mode string     Default: "blocking"
指定发送审计事件的策略。blocking 表示发送事件时阻塞服务器响应;batch 表示在后端异步缓冲和写入事件。目前仅支持 batch 和 blocking(默认值:blocking)。
--audit-log-path string
如果指定该参数,则所有 API 服务器接受的请求都会记录到此文件。"-" 表示记录到标准输出。
--audit-log-truncate-enabled
指定是否允许截断事件和批处理。
--audit-log-truncate-max-batch-size int     Default: 10485760
指定发送到底层后端的批处理的最大字节数(默认值:10485760)。实际序列化时的大小会比设定值大几百字节。如果一个批处理超出该大小,它会被分为几个小的批处理。
--audit-log-truncate-max-event-size int     Default: 102400
指定发送到底层后端的审计事件的最大字节数(默认值:102400)。如果一个事件超出该大小,则第一个请求和回复会被删除,如果还没有减少到合适的大小,该事件将被丢弃。
--audit-log-version string     Default: "audit.k8s.io/v1beta1"
指定序列化审计日志的 API 组名和版本号(默认值:audit.k8s.io/v1beta1)。
--audit-policy-file string
指定审计策略配置文件的路径。
--audit-webhook-batch-buffer-size int     Default: 10000
指定存储批处理和写入事件的缓冲区字节数(默认值:10000)。只在批处理模式下使用。
--audit-webhook-batch-max-size int     Default: 400
指定一个批处理的最大长度(默认值:400)。只在批处理模式下使用。
--audit-webhook-batch-max-wait duration     Default: 30s
指定尚未达到最大值的批处理的强制写入等待时间(默认值:30s)。只在批处理模式下使用。
--audit-webhook-batch-throttle-burst int     Default: 15
指定在未使用 ThrottleQPS 时同时发送请求的最大数量(默认值:15)。只在批处理模式下使用。
--audit-webhook-batch-throttle-enable     Default: true
指定是否启用 batching throttling(默认值:true)。只在批处理模式下使用。
--audit-webhook-batch-throttle-qps float32     Default: 10
设定每秒内可执行的批处理的最大平均数(默认值:10)。只在批处理模式下使用。
--audit-webhook-config-file string
指定 kubeconfig 格式的配置文件的路径。该文件设定了审计 webhook 配置。
--audit-webhook-initial-backoff duration     Default: 10s
指定重试第一个失败请求之前等待的时间(默认值:10s)。
--audit-webhook-mode string     Default: "batch"
指定发送审计事件的策略。blocking 表示发送事件时阻塞服务器响应;batch 表示在后端异步缓冲和写入事件。目前仅支持 batch 和 blocking(默认值:batch)。
--audit-webhook-truncate-enabled
指定是否允许截断事件和批处理。
--audit-webhook-truncate-max-batch-size int     Default: 10485760
指定发送到底层后端的批处理的最大字节数(默认值:10485760)。实际序列化时的大小会比设定值大几百字节。如果一个批处理超出该大小,它会被分为几个小的批处理。
--audit-webhook-truncate-max-event-size int     Default: 102400
指定发送到底层后端的审计事件的最大字节数(默认值:102400)。如果一个事件超出该大小,则第一个请求和回复会被删除,如果还没有减少到合适的大小,该事件将被丢弃。
--audit-webhook-version string     Default: "audit.k8s.io/v1beta1"
指定序列化审计日志的 API 组名和版本号(默认值:audit.k8s.io/v1beta1)。
--authentication-token-webhook-cache-ttl duration     Default: 2m0s
指定从 webhook 标识认证方缓存响应的持续时间(默认值:2m0s)。
--authentication-token-webhook-config-file string
指定 kubeconfig 格式的 webhook 配置文件,用来进行标识认证。API 服务器将会查询远程服务器,来验证承载 token 的身份。
--authorization-mode stringSlice     Default: [AlwaysAllow]
指定在安全端口上执行授权的有序插件列表,以逗号分隔。(可选:AlwaysAllow、AlwaysDeny、ABAC、Webhook、RBAC、Node,默认值:[AlwaysAllow])。
--authorization-policy-file string
指定 csv 格式的授权策略文件。该参数与 --authorization-mode=ABAC 一起使用,作用在安全端口上。
--authorization-webhook-cache-authorized-ttl duration     Default: 5m0s
指定从 webhook 授权方缓存的 '已授权' 响应的持续时间(默认值:5m0s)。
--authorization-webhook-cache-unauthorized-ttl duration     Default: 30s
指定从 webhook 授权方缓存的 '未授权' 响应的持续时间(默认值:30s)。
--authorization-webhook-config-file string
指定 kubeconfig 格式的 webhook 配置文件。该参数与 --authorization-mode=webhook 一起使用。API 服务器将会查询远程服务器,来确认访问 API 服务器安全端口。
--azure-container-registry-config string
指定 Azure 容器注册表配置文件的路径。
--basic-auth-file string
如果设定该参数,则该文件将使用 http 基本身份验证接受对 API 服务器安全端口的请求。
--bind-address ip     Default: 0.0.0.0
指定一个 IP 地址来监听 --secure-port 的端口(默认值:0.0.0.0)。该地址对应的网络接口必须可被集群中其他成员、命令行和 web 客户端访问。如果该参数留空,则使用所有网络接口(IPv4 接口使用 0.0.0.0,IPv6 接口使用 ::)。
--cert-dir string     Default: "/var/run/kubernetes"
指定 TLS 认证文件所在的目录(默认值:/var/run/kubernetes)。如果设定了 --tls-cert-file 和 --tls-private-key-file,则忽略该参数。
--client-ca-file string
如果设定了该参数,则任何带客户端证书的请求,即包含被该文件中任何一个授权方签过名的证书的请求,都使用客户端证书中的 CommonName 作为该请求的身份。
--cloud-config string
指定云服务提供商的配置文件。若留空则表示没有配置文件。
--cloud-provider string
指定云服务提供商。若留空则表示没有云服务提供商。
--contention-profiling
若启用 profiling 分析,则该参数将指定是否用锁争用 profiling 分析。
--cors-allowed-origins stringSlice
设定允许跨域资源共享(CORS)的域列表,以逗号分隔。可用正则表达式支持匹配子域。若该列表为空则禁用跨域资源共享。
--default-watch-cache-size int     Default: 100
指定默认 watch 缓存大小(默认值:100)。若设为 0,则没有设定默认 watch 大小的资源将禁用 watch 缓存。
--delete-collection-workers int     Default: 1
指定调用 DeleteCollection 时产生的 worker 数量(默认值:1),用于加速命名空间的清理。
--deserialization-cache-size int
指定用于缓存反序列化 json 对象的内存大小。
--disable-admission-plugins stringSlice
设定禁用的权限相关的插件的列表,默认启用的插件列表中的插件也可禁用,以逗号分隔。该列表中的顺序不影响结果。所有列表项包括 AlwaysAdmit、AlwaysDeny、AlwaysPullImages、DefaultStorageClass、DefaultTolerationSeconds、DenyEscalatingExec、DenyExecOnPrivileged、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、Initializers、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodPreset、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、ValidatingAdmissionWebhook。其中默认启用的插件包括 NamespaceLifecycle、LimitRanger、ServiceAccount、Priority、DefaultTolerationSeconds、DefaultStorageClass、PersistentVolumeClaimResize、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota。
--enable-admission-plugins stringSlice
设定启用的权限相关的插件的列表,以逗号分隔。该列表中的插件顺序不影响结果。该列表中的插件会与默认启用的插件一起启用。
--enable-aggregator-routing
设定是否打开聚合路由请求到 endpoint IP,而非集群 IP。
--enable-bootstrap-token-auth
设定是否允许 kube-system 命名空间中的 bootstrap.kubernetes.io/token 类型用作 TLS bootstrapping 验证。
--enable-garbage-collector     Default: true
设定是否启用通用垃圾收集器(默认值:true)。该参数必须与 kube-controller-manager 的对应参数保持一致。
--enable-logs-handler     Default: true
如果该参数设为 true,则 API 服务器会使用 /logs 地址来处理日志(默认值:true)。
--enable-swagger-ui
设定是否在 /swagger-ui 地址中启用 swagger ui。
--endpoint-reconciler-type string     Default: "lease"
设置启用的终端协调器(可选:master-count、lease、none,默认:lease)。
--etcd-cafile string
设定用于保证 etcd 通信安全的 SSL 证书颁发机构的证书文件(CA 证书)。
--etcd-certfile string
设定用于保证 etcd 通信安全的 SSL 证书文件(由 CA 颁发的证书)。
--etcd-compaction-interval duration     Default: 5m0s
设定压缩请求的间隔(默认值:5m0s)。若设为 0,则 API 服务器将禁用压缩请求。
--etcd-count-metric-poll-period duration     Default: 1m0s
设置向 etcd 轮询获取每种资源剩余情况的时间。设定为 0 表示禁用收集资源信息。
--etcd-keyfile string
设置用于保证 etcd 通信安全的 SSL 密钥文件(与 --etcd-certfile 对应的密钥)。
--etcd-prefix string     Default: "/registry"
设置 etcd 中所有资源路径的前缀(默认值:/registry)。
--etcd-servers stringSlice
指定要连接的 etcd 服务器列表(格式:scheme://ip:port),以逗号分隔。
--etcd-servers-overrides stringSlice
指定 etcd 服务器需要覆盖的资源,以逗号分隔。每个独立的格式为 group/resource#servers,其中 servers 为多个URL,以分号分隔。
--event-ttl duration     Default: 1h0m0s
设定事件的保存时间(默认值:1h0m0s)。
--experimental-encryption-provider-config string
设定包含加密程序的配置文件路径,用于设定在 etcd 中如何加密存储数据。
--external-hostname string
设定该 master 节点创建集群时使用外部 URL 需要用的主机名(如 Swagger API 文档的 URL)。
--feature-gates mapStringBool
用于描述 alpha/experimental 特性的功能的一组键值对。包括:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=false)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true)
CSIBlockVolume=true|false (ALPHA - default=false)
CSIDriverRegistry=true|false (ALPHA - default=false)
CSINodeInfo=true|false (ALPHA - default=false)
CSIPersistentVolume=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomPodDNS=true|false (BETA - default=true)
CustomResourceSubresources=true|false (BETA - default=true)
CustomResourceValidation=true|false (BETA - default=true)
DebugContainers=true|false (ALPHA - default=false)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EnableEquivalenceClassCache=true|false (ALPHA - default=false)
ExpandInUsePersistentVolumes=true|false (ALPHA - default=false)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GCERegionalPersistentDisk=true|false (BETA - default=true)
HugePages=true|false (BETA - default=true)
HyperVContainer=true|false (ALPHA - default=false)
Initializers=true|false (ALPHA - default=false)
KubeletPluginsWatcher=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
MountContainers=true|false (ALPHA - default=false)
NodeLease=true|false (ALPHA - default=false)
PersistentLocalVolumes=true|false (BETA - default=true)
PodPriority=true|false (BETA - default=true)
PodReadinessGates=true|false (BETA - default=true)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (ALPHA - default=false)
RuntimeClass=true|false (ALPHA - default=false)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (ALPHA - default=false)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (ALPHA - default=false)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
VolumeScheduling=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (ALPHA - default=false)
-h, --help
打印 kube-apiserver 帮助。
--http2-max-streams-per-connection int
设定 HTTP/2 连接中流的最大数量限制。设定为 0 则使用 golang 的默认配置。
--kubelet-certificate-authority string
指定用于 kubelet CA 认证的证书文件路径。
--kubelet-client-certificate string
指定用于 TLS 的客户端证书。
--kubelet-client-key string
指定用于 TLS 的客户端密钥。
--kubelet-https     Default: true
设定是否在 kubelet 连接中使用 HTTPS。
--kubelet-preferred-address-types stringSlice     Default: [Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP]
指定用于 kubelet 连接的首选 NodeAddressTypes 列表(默认值:[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])。
--kubelet-read-only-port uint     Default: 10255
(已弃用)设定 kubelet 端口(默认值:10255)。
--kubelet-timeout duration     Default: 5s
设定 kubelet 操作的超时时间(默认值:5s)。
--kubernetes-service-node-port int
如果该参数设为非 0 值,则 Kubernetes master 服务(由 API 服务器创建和维护)将是 NodePort 类型,以该值作为端口。该值为 0 时,则 Kubernetes master 服务将是 ClusterIP 类型。
--log-flush-frequency duration     Default: 5s
设定日志刷新的最大间隔(默认值:5s)。
--master-service-namespace string     Default: "default"
(已弃用)设定 Kubernetes master 服务插入 pods 的命名空间(默认值:default)。
--max-connection-bytes-per-sec int
如果该参数设为非 0 值,则将用户连接每秒的比特数阈值设置为该值。目前该参数只应用在耗时请求中。
--max-mutating-requests-inflight int     Default: 200
设定给定时间内未响应的“修改类”请求的最大数量(默认值:200)。当请求数量超过该值时,服务器将拒绝新的请求。设定为 0 则代表无限制。
--max-requests-inflight int     Default: 400
设定给定时间内未响应的“非修改类”请求的最大数量(默认值:400)。当请求数量超过该值时,服务器将拒绝新的请求。设定为 0 则代表无限制。
--min-request-timeout int     Default: 1800
指定控制器在请求超时前,保持它的连接状态的最小秒数(默认值:1800)。目前该参数只有 watch 请求控制器生效,它选择一个随机值作为连接超时时间,用来分配负载。
--oidc-ca-file string
如果指定了该参数,则 OpenID 服务器的证书会使用该文件中的一个认证方进行验证,否则使用该主机的根证书进行验证。
--oidc-client-id string
设置 OpenID Connect 的客户端 ID。如果设定了 --oidc-issuer-url 参数,则该参数必须指定。
--oidc-groups-claim string
如果指定了该参数,则一个自定义的 OpenID Connect 将以它的名字声明指定的用户组。该声明的值应该为一个字符串或字符串数组。该参数为实验性参数,请参考权限文档获取更多信息。
--oidc-groups-prefix string
如果指定了该参数,则所有组将以该值作为前缀,以防止和其他的认证策略冲突。
--oidc-issuer-url string
设定 OpenID 发布者的 URL(仅接受 HTTPS)。如果设定了该参数,则它会被用来验证 OIDC JSON Web Token。
--oidc-required-claim mapStringString
设定一组描述 ID Token 中所需的声明的键值对。如果设定了该参数,则该声明将被用来验证 ID Token 中对应值是否存在。如果有多个声明则重复使用该参数。
--oidc-signing-algs stringSlice     Default: [RS256]
设定允许的 JOSE 非对称签名算法列表,用逗号分隔。alg header 的值不在此列表中的 JWT 将被拒绝。所有的值都通过 RFC 7518 定义(参见 https://tools.ietf.org/html/rfc7518#section-3.1)。
--oidc-username-claim string     Default: "sub"
设定作为用户名使用的 OpenID 声明。注意默认声明('sub')以外的声明不能保证唯一性和不变性。该参数为实验性参数,请参考权限文档获取更多信息。
--oidc-username-prefix string
如果指定了该参数,则所有的用户名将以该值作为前缀。如果不指定,则邮箱以外的用户名将使用发布者的 URL 作为前缀以防止冲突。如果不想指定任何前缀,则可将该参数设为 "-"。
--profiling     Default: true
指定是否在 /debug/pprof 网络接口中启用 web 服务状态分析(默认值:true)。
--proxy-client-cert-file string
设定用于在发送请求时证明 aggregator 或 kube-apiserver 身份的客户端证书,包括代理向用户 api 服务器发送的请求和发送到 webhook 权限插件的请求。该证书包含从 --requestheader-client-ca-file 中 CA 的签名。该 CA 被发布在 kube-system 命名空间中的 extension-apiserver-authentication 配置项中。接收 kube-aggregator 请求的组件必须向该 CA 提供双向 TLS 认证中它们的那部分证书。
--proxy-client-key-file string
设定用于在发送请求时证明 aggregator 或 kube-apiserver 身份的客户端私钥,包括代理向用户 api 服务器发送的请求和发送到 webhook 权限插件的请求。
--request-timeout duration     Default: 1m0s
该可选参数表示控制器在请求超时前,保持它的连接状态的最小秒数(默认值:1m0s)。该参数是请求的默认超时时间,但处理特定类型的请求时可使用 --min-request-timeout 等参数覆盖。
--requestheader-allowed-names stringSlice
指定客户端证书的 common names 列表,用来提供 --requestheader-username-headers 中特定头部的用户名。如果忽略该参数,则 --requestheader-client-ca-file 中认证方验证过的所有客户端证书都可用。
--requestheader-client-ca-file string
指定在信任 --requestheader-username-headers 中特定头部的用户名之前,用来验证请求中客户端证书的根证书集合。警告:通常不要依赖请求中已完成的授权。
--requestheader-extra-headers-prefix stringSlice
指定用于检查的请求头部的前缀。建议使用 "X-Remote-Extra-"。
--requestheader-group-headers stringSlice
指定用于检查的请求头部。建议使用 X-Remote-Group。
--requestheader-username-headers stringSlice
设定请求头部的用户名列表,通常设为 X-Remote-User。
--runtime-config mapStringString
指定一组用来描述运行时配置的键值对,它们会被传递到 API 服务器中。<group>/<version> 键可以用来打开或关闭特定的 API 版本(core 组则直接使用 <version>)。api/all 是用来控制所有 API 版本的特殊键,将它设置成 false 必须谨慎,除非你知道你在做什么。api/legacy 已被弃用,我们将来会删除它,所以不要使用该键。
--secure-port int     Default: 6443
设定用于提供 HTTPS 认证和授权服务的端口(默认值:6443)。该端口不能设成 0 来关闭。
--service-account-api-audiences stringSlice
指定 API 识别码。服务账户标识授权方将验证这些针对 API 使用的标识是否被绑定到至少一个受众中。
--service-account-issuer string
指定服务账户标识发布者的识别码。该发布者将断言该识别码在已发布标识的 "iss" 声明中。该参数是一个字符串或 URI。
--service-account-key-file stringArray
指定包含 PEM 编码的 X509 RSA 或 ECDSA 私钥或公钥的文件,用来验证 ServiceAccount 标识。该文件可用包含多个密钥,该参数也可用指定多次,来包含不同的文件。如果不指定该参数,则使用 --tls-private-key-file。当 --service-account-signing-key-file 指定时该参数必须指定。
--service-account-lookup     Default: true
如果该参数设为 true,则验证 etcd 中的 ServiceAccount 标识,作为授权的一部分(默认值:true)。
--service-account-max-token-expiration duration
设定服务账户发布者创建的标识的最大有效期。如果请求中包含一个有效的 TokenRequest,它的有效期大于该值,则会发布一个有效期为该值的标识。
--service-account-signing-key-file string
设定包含服务账户标识发布者当前的私钥的文件。该发布者将使用该私钥对 ID 标识进行签名(需要在 --feature-gates 参数中启用 TokenRequest)。
--service-cluster-ip-range ipNet     Default: 10.0.0.0/24
设定一个无类别域间路由记号 IP 网段,用来分配服务集群的 IP(默认值:10.0.0.0/24)。该网段不能与已分配到 pod 节点的网段重叠。
--service-node-port-range portRange     Default: 30000-32767
设定一个端口的范围,用来保留 NodePort 可见的服务(默认值:30000-32767)。两端均包含在内。
--storage-backend string
设定用于持久化的存储后端(默认值:etcd3,可选:etcd2)。
--storage-media-type string     Default: "application/vnd.kubernetes.protobuf"
设置用来在存储器中存储对象的介质类型(默认值:application/vnd.kubernetes.protobuf)。一些资源或存储后端可能只支持特定类型的存储介质,它们将忽略该参数设定。
--target-ram-mb int
设定 API 服务器的内存大小限制(单位:MB),用于配置缓存大小等。
--tls-cert-file string
设定 HTTPS 中包含默认 X509 证书的文件。该文件包含服务器证书。如果还有 CA 证书,则 CA 证书紧接服务器证书。如果启用 HTTPS 服务,但未指定 --tls-cert-file 和 --tls-private-key-file,则服务器会为公共地址产生一个自签名证书和密钥,然后将它们存在 --cert-dir 参数的值对应的目录下。
--tls-cipher-suites stringSlice
设置服务器的加密套件列表,用逗号分隔。如果忽略该参数,服务器将使用 Go 默认的加密套件。可选的值为: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_GCM_SHA384、TLS_RSA_WITH_RC4_128_SHA。
--tls-min-version string
设置最小支持的 TLS 版本。可选的值为:VersionTLS10、VersionTLS11、VersionTLS12。
--tls-private-key-file string
设定包含与 --tls-cert-file 对应的 X509 私钥的文件。
--tls-sni-cert-key namedCertKey     Default: []
设定一对 X509 证书和私钥的文件路径。该路径可能会带有一个域模式列表的后缀,这些域模式是一些完全可信的域名;也可能带有通配符段的前缀。如果不指定任何域模式,则证书中的名字将被提取作为域模式。非通配符匹配将覆盖通配符匹配,显式指定的域模式将覆盖提取的域模式。如果有多个密钥证书对,则可多次指定该参数(例:example.crt,example.key 或 foo.crt,foo.key:*.foo.com,foo.com)。
--token-auth-file string
如果指定了该参数,则该文件将被用来在 token 认证时保证 API 服务器安全端口的安全。
--version version[=true]
打印版本信息然后退出。
--watch-cache     Default: true
设定是否允许 API 服务器进行 watch 缓存。
--watch-cache-sizes stringSlice
设定每种资源(pods、nodes 等)的 watch 缓存大小,用逗号分隔。每个独立的格式为:resource[.group]#size,其中 resource 为复数形式小写,不包含版本号;group 为可选值;size 为一个数,当 --watch-cache 启用时生效。有些资源(replicationcontrollers、endpoints、nodes、pods、services、apiservices.apiregistration.k8s.io)会使用启发式的系统默认设置,其他资源则默认使用 --default-watch-cache-size 的值。
\ No newline at end of file diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md new file mode 100644 index 0000000000..e38b47e792 --- /dev/null +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -0,0 +1,185 @@ +--- +title: Kubelet 认证/授权 +--- + +{{< toc >}} + + +## 概述 + + +kubelet 的 HTTPS 端点公开了 API,可以访问不同敏感度的数据, +并允许您在节点和容器内执行不同权限级别的操作。 + + +本文档介绍如何认证和授权访问 kubelet 的 HTTPS 端点。 + + +## Kubelet 认证 + + +默认情况下,未被其他已配置的身份验证方法拒绝的对 kubelet 的 HTTPS 端点的请求将被视为匿名请求, +并提供一个 `system:anonymous` 用户名和一个 `system:unauthenticated` 用户组。 + + +禁用匿名访问并向未经身份验证的请求发送 `401 Unauthorized` 响应: + + +* 附带 `--anonymous-auth=false` 参数启动 kubelet + + +要为 kubelet 的 HTTPS 端点启用 X509 客户端证书身份验证,请执行以下操作: + + +* 附带 `--client-ca-file` 参数启动 kubelet,提供 CA 包以验证客户端证书 +* 附带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 参数启动 apiserver +* 查看 [apiserver 认证文档](/docs/reference/access-authn-authz/authentication/#x509-client-certs)以获取更多细节 + + +启用 API bearer 令牌(包括服务帐户令牌)以用于对 kubelet 的 HTTPS 端点进行身份验证: + + +* 确保 API 服务器启用了 `authentication.k8s.io/v1beta1` API 组 +* 附带 `--authentication-token-webhook` 和 `--kubeconfig` 参数启动 kubelet +* kubelet 在配置的 API 服务器上调用 `TokenReview` API,以确定来自 bearer 令牌的用户信息 + + +## Kubelet 授权 + + +任何成功经过身份验证的请求(包括匿名请求)都将得到授权。 +默认授权模式是 `AlwaysAllow`,它允许所有请求。 + + +有许多可能的原因来细分对 kubelet API 的访问: + + +* 匿名身份验证被启用,但匿名用户调用 kubelet API 的能力应该受到限制 +* bearer 令牌验证被启用,但应限制任意 API 用户(如服务帐户)调用 kubelet API 的能力 +* 启用了客户端证书身份验证,但只允许由配置的 CA 签名的某些客户端证书使用 kubelet API + + +要细分对 kubelet API 的访问权限,请将授权委派给 API 服务器: + + +* 确保 API 服务器启用了 `authorization.k8s.io/v1beta1` API 组 +* 附带 `--authorization-mode=Webhook` 和 `--kubeconfig` 参数启动 kubelet +* kubelet 在配置的 API 服务器上调用 `SubjectAccessReview` API,以判断每个请求是否是被授权的 + + +kubelet 使用与 apiserver 相同的[请求属性](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)方法为 API 请求授权。 + + +动词(verb)是根据传入请求的 HTTP 动词(verb)确定的: + + +HTTP 动词 | 请求动词 +----------|--------------- +POST | create +GET, HEAD | get +PUT | update +PATCH | patch +DELETE | delete + + +资源(resource)和子资源(subresource)由传入请求的路径确定: + + +Kubelet API | 资源 | 子资源 +-------------|----------|------------ +/stats/\* | nodes | stats +/metrics/\* | nodes | metrics +/logs/\* | nodes | log +/spec/\* | nodes | spec +*all others* | nodes | proxy + + +命名空间和 API 组属性始终为空字符串,资源名称始终是 kubelet 的 `Node` API 对象的名称。 + + +在此模式下运行时,请确保传递给 apiserver 的 `--kubelet-client-certificate` 和 `--kubelet-client-key` 参数所标识的用户有权使用以下属性: + +* verb=\*, resource=nodes, subresource=proxy +* verb=\*, resource=nodes, subresource=stats +* verb=\*, resource=nodes, subresource=log +* verb=\*, resource=nodes, subresource=spec +* verb=\*, resource=nodes, subresource=metrics diff --git a/content/zh/docs/reference/federation/_index.html b/content/zh/docs/reference/federation/_index.html new file mode 100644 index 0000000000..73b1875340 --- /dev/null +++ b/content/zh/docs/reference/federation/_index.html @@ -0,0 +1,11 @@ +--- +title: "联邦 API" +weight: 40 +--- + + diff --git a/content/zh/docs/reference/glossary/aggregation-layer.md b/content/zh/docs/reference/glossary/aggregation-layer.md new file mode 100644 index 0000000000..982c7ef3a2 --- /dev/null +++ b/content/zh/docs/reference/glossary/aggregation-layer.md @@ -0,0 +1,45 @@ +--- +title: 聚合层 +id: aggregation-layer +date: 2018-10-08 +full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ +short_description: > + 聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。 + +aka: +tags: +- architecture +- extension +- operation +--- + + + + + +聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。 + + + + + +当您配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/),您就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领(Claim)" 一个 URL 路径。 diff --git a/content/zh/docs/reference/glossary/annotation.md b/content/zh/docs/reference/glossary/annotation.md new file mode 100644 index 0000000000..75705d9745 --- /dev/null +++ b/content/zh/docs/reference/glossary/annotation.md @@ -0,0 +1,42 @@ +--- +title: 注解 +id: annotation +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/annotations +short_description: > + 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 + +aka: +tags: +- fundamental +--- + + + + + + 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 + + + + + +注解中的元数据可大可小,可以是结构化的也可以是非结构化的,并且能包含标签不允许使用的字符。像工具和软件库这样的客户端可以检索这些元数据。 + diff --git a/content/zh/docs/reference/glossary/application-architect.md b/content/zh/docs/reference/glossary/application-architect.md new file mode 100644 index 0000000000..849d1b7685 --- /dev/null +++ b/content/zh/docs/reference/glossary/application-architect.md @@ -0,0 +1,37 @@ +--- +title: 应用架构师 +id: application-architect +date: 2018-04-12 +full_link: +short_description: > + 应用架构师是负责应用高级设计的人。 + +aka: +tags: +- user-type +--- + 应用架构师是负责应用高级设计的人。 + + + + + + +应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。周边组件包括数据库、日志基础设施和其他微服务。 + diff --git a/content/zh/docs/reference/glossary/application-developer.md b/content/zh/docs/reference/glossary/application-developer.md new file mode 100644 index 0000000000..65650133da --- /dev/null +++ b/content/zh/docs/reference/glossary/application-developer.md @@ -0,0 +1,41 @@ +--- +title: 应用开发者 +id: application-developer +date: 2018-04-12 +full_link: +short_description: > + 编写可以在 Kubernetes 集群上运行的应用的人。 + +aka: +tags: +- user-type +--- + + + + + +编写可以在 Kubernetes 集群上运行的应用的人。 + + + + + +应用开发者专注于应用的某一部分。他们工作范围的大小有明显的差异。 diff --git a/content/zh/docs/reference/glossary/approver.md b/content/zh/docs/reference/glossary/approver.md new file mode 100755 index 0000000000..879ef5e58b --- /dev/null +++ b/content/zh/docs/reference/glossary/approver.md @@ -0,0 +1,40 @@ +--- +title: 批准者 +id: approver +date: 2018-04-12 +full_link: +short_description: > + 可以审核并批准 Kubernetes 代码贡献的人。 + +aka: +tags: +- community +--- + + + + 可以审核并批准 Kubernetes 代码贡献的人。 + + + + + +代码审核的重点是代码质量和正确性,而批准的重点是对贡献的整体接受。 +整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。 +批准者状态的作用域是代码库的一部分。 +审批者以前被称为维护者。 diff --git a/content/zh/docs/reference/glossary/certificate.md b/content/zh/docs/reference/glossary/certificate.md new file mode 100644 index 0000000000..238178c890 --- /dev/null +++ b/content/zh/docs/reference/glossary/certificate.md @@ -0,0 +1,42 @@ +--- +title: 证书 +id: certificate +date: 2018-04-12 +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +short_description: > + 证书是个安全加密文件,用来确认对 Kubernetes 集群访问的合法性。 + +aka: +tags: +- security +--- + + + + + +证书是个安全加密文件,用来确认对 Kubernetes 集群访问的合法性。 + + + + + +证书可以让 Kubernetes 集群中运行的应用程序安全的访问 Kubernetes API。证书可以确认客户端是否被允许访问 API。 + diff --git a/content/zh/docs/reference/glossary/cla.md b/content/zh/docs/reference/glossary/cla.md new file mode 100644 index 0000000000..dae58a89e6 --- /dev/null +++ b/content/zh/docs/reference/glossary/cla.md @@ -0,0 +1,38 @@ +--- +title: CLA (贡献者许可协议) +id: cla +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/CLA.md +short_description: > + 贡献者对他们在开源项目中所贡献的代码的授权许可条款。 + +aka: +tags: +- community +--- + + + + {{< glossary_tooltip text="贡献者" term_id="contributor" >}} 对他们在开源项目中所贡献的代码的授权许可条款。 + + + + + +CLA 对解决贡献者在开源社区所贡献的资料和智力资产(IP)导致的法律纠纷很有帮助。 + diff --git a/content/zh/docs/reference/glossary/cloud-controller-manager.md b/content/zh/docs/reference/glossary/cloud-controller-manager.md new file mode 100755 index 0000000000..b6254d7ce9 --- /dev/null +++ b/content/zh/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,47 @@ +--- +title: 云控制器管理器 +id: cloud-controller-manager +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/running-cloud-controller/ +short_description: > + 云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中,这是将 Kubernetes 与任何其他云集成的最佳方式。 + +aka: +tags: +- core-object +- architecture +- operation +--- + + + + + +云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中,这是将 Kubernetes 与任何其他云集成的最佳方式。 + + + + + +Kubernetes v1.6 包含一个新的可执行文件叫做 cloud-controller-manager。cloud-controller-manager 是一个守护进程,其中嵌入了特定于某云环境的控制环。 +这些特定于云环境的控制环最初位于 kube-controller-manager 中。 +由于云供应商的开发和发布节奏与 Kubernetes 项目不同步,将特定于供应商的代码抽象到 cloud-controller-manager 可执行文件可以允许云供应商独立于核心 Kubernetes 代码进行演进。 diff --git a/content/zh/docs/reference/glossary/cloud-provider.md b/content/zh/docs/reference/glossary/cloud-provider.md new file mode 100644 index 0000000000..16851569d6 --- /dev/null +++ b/content/zh/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,38 @@ +--- +title: 云供应商 +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + 云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。 + +aka: +tags: +- community +--- + + + + 云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。 + + + + +云供应商也叫云服务供应商(CSPs),他们可以为用户提供云计算平台。他们提供的服务可以是基础设施即服务(IaaS)或者平台即服务(PaaS)。云供应商除了运行 Kubernetes 集群,还提供一些集群交互的服务,例如负载均衡(Load Balancers)、存储类别(Storage Classes)等。 diff --git a/content/zh/docs/reference/glossary/cluster-architect.md b/content/zh/docs/reference/glossary/cluster-architect.md new file mode 100644 index 0000000000..c45bcfbe34 --- /dev/null +++ b/content/zh/docs/reference/glossary/cluster-architect.md @@ -0,0 +1,37 @@ +--- +title: 集群架构师 +id: cluster-architect +date: 2018-04-12 +full_link: +short_description: > + 集群架构师负责设计集群的基础设施,可能包含一个或多个 Kubernetes 集群。 + +aka: +tags: +- user-type +--- + + + + 集群架构师负责设计集群的基础设施,可能包含一个或多个 Kubernetes 集群。 + + + + + +集群架构师要具备分布式系统的最佳实践经验,例如:高可用性和安全性。 diff --git a/content/zh/docs/reference/glossary/cluster-operator.md b/content/zh/docs/reference/glossary/cluster-operator.md new file mode 100644 index 0000000000..8318dd46ed --- /dev/null +++ b/content/zh/docs/reference/glossary/cluster-operator.md @@ -0,0 +1,44 @@ +--- +title: 集群操作者 +id: cluster-operator +date: 2018-04-12 +full_link: +short_description: > + 配置、控制、监控集群的人。 + +aka: +tags: +- user-type +--- + + + + + 配置、控制、监控集群的人。 + + + + +他们的主要责任是保持集群正常运行,可能需要进行周期性的维护和升级活动。
+ +**注意:** 集群操作者不同于[操作者模式(Operator Pattern)](https://coreos.com/operators),操作者模式是用来扩展 Kubernetes API 的。 + diff --git a/content/zh/docs/reference/glossary/cluster.md b/content/zh/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000..8cc5502ed2 --- /dev/null +++ b/content/zh/docs/reference/glossary/cluster.md @@ -0,0 +1,43 @@ +--- +title: 集群 +id: cluster +date: 2018-04-12 +full_link: +short_description: > + 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。 + +aka: +tags: +- fundamental +- operation +--- + + + + + + 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。 + + + + + +集群由至少一个主节点和若干个工作节点组成。 diff --git a/content/zh/docs/reference/glossary/cni.md b/content/zh/docs/reference/glossary/cni.md new file mode 100644 index 0000000000..361a7f0911 --- /dev/null +++ b/content/zh/docs/reference/glossary/cni.md @@ -0,0 +1,44 @@ +--- +title: CNI (容器网络接口) +id: cni +date: 2018-05-25 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +short_description: > + 容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 + + +aka: +tags: +- networking +--- + + + + + + 容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 + + + + + +* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 diff --git a/content/zh/docs/reference/glossary/code-contributor.md b/content/zh/docs/reference/glossary/code-contributor.md new file mode 100644 index 0000000000..8d24d7f72f --- /dev/null +++ b/content/zh/docs/reference/glossary/code-contributor.md @@ -0,0 +1,43 @@ +--- +title: 代码贡献者 +id: code-contributor +date: 2018-04-12 +full_link: /docs/community/devel/ +short_description: > + 为 Kubernetes 开源代码库开发并贡献代码的人。 + +aka: +tags: +- community +- user-type +--- + + + + + + 为 Kubernetes 开源代码库开发并贡献代码的人。 + + + + + +代码贡献者也是加入一个或多个 {{< glossary_tooltip text="特别兴趣小组 (SIGs)" term_id="sig" >}} 的活跃的 {{< glossary_tooltip text="社区成员" term_id="member" >}}。 diff --git a/content/zh/docs/reference/glossary/configmap.md b/content/zh/docs/reference/glossary/configmap.md new file mode 100644 index 0000000000..d3d0945cdc --- /dev/null +++ b/content/zh/docs/reference/glossary/configmap.md @@ -0,0 +1,41 @@ +--- +title: ConfigMap +id: configmap +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/ +short_description: > + ConfigMap 是一种 API 对象,用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 + +aka: +tags: +- core-object +--- + + + + + + ConfigMap 是一种 API 对象,用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 + + + + + +ConfigMap 将您的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="container" >}} 解耦,便于应用配置的修改。当您需要储存机密信息时可以使用 [Secret](/docs/concepts/configuration/secret/) 对象。 diff --git a/content/zh/docs/reference/glossary/container-env-variables.md b/content/zh/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000..d851c14c92 --- /dev/null +++ b/content/zh/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,40 @@ +--- +title: 容器环境变量 +id: container-env-variables +date: 2018-04-12 +full_link: /docs/concepts/containers/container-environment-variables.md +short_description: > + 容器环境变量提供了运行容器化应用所必须的一些重要信息。 + +aka: +tags: +- fundamental +--- + + + + + + 容器环境变量提供了运行容器化应用所必须的一些重要信息。 + + + + + 容器环境变量为运行中的容器化应用提供必要的信息,同时还提供与 {{< glossary_tooltip text="容器" term_id="container" >}} 重要资源相关的其他信息,例如:文件系统信息、容器自身的信息以及其他像服务端点(Service endpoints)这样的集群资源信息。 diff --git a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md new file mode 100644 index 0000000000..3d1b708fe0 --- /dev/null +++ b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md @@ -0,0 +1,38 @@ +--- +title: 容器生命周期钩子 +id: container-lifecycle-hooks +date: 2018-10-08 +full_link: /docs/concepts/containers/container-lifecycle-hooks/ +short_description: > + 生命周期钩子暴露容器管理生命周期中的事件,允许用户在事件发生时运行代码。 + +aka: +tags: +- extension +--- + + + 生命周期钩子暴露{{< glossary_tooltip text="容器" term_id="container" >}}管理生命周期中的事件,允许用户在事件发生时运行代码。 + + + + +针对容器暴露了两个钩子:PostStart 在容器创建之后立即执行,PreStop 在容器停止之前立即阻塞并被调用。 + diff --git a/content/zh/docs/reference/glossary/container.md b/content/zh/docs/reference/glossary/container.md new file mode 100644 index 0000000000..16d99f4e30 --- /dev/null +++ b/content/zh/docs/reference/glossary/container.md @@ -0,0 +1,44 @@ +--- +title: 容器 +id: container +date: 2018-04-12 +full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers +short_description: > + 容器是可移植、可执行的轻量级的镜像,镜像中包含软件及其相关依赖。 + +aka: +tags: +- fundamental +- workload +--- + + + + + + 容器是可移植、可执行的轻量级的镜像,镜像中包含软件及其相关依赖。 + + + + + +容器使应用和底层的主机基础设施解耦,降低了应用在不同云环境或者操作系统上的部署难度,便于应用扩展。 + diff --git a/content/zh/docs/reference/glossary/contributor.md b/content/zh/docs/reference/glossary/contributor.md new file mode 100755 index 0000000000..32f21a5e54 --- /dev/null +++ b/content/zh/docs/reference/glossary/contributor.md @@ -0,0 +1,39 @@ +--- +title: 贡献者 +id: contributor +date: 2018-04-12 +full_link: +short_description: > + 通过贡献代码、文档或者投入时间等方式来帮助 Kubernetes 项目或社区的人。 + +aka: +tags: +- community +--- + + + + + +通过贡献代码、文档或者投入时间等方式来帮助 Kubernetes 项目或社区的人。 + + + + +贡献形式包括提交拉取请求(PRs)、问题报告(Issues)、反馈、参与{{< glossary_tooltip text="特别兴趣小组(SIG)" term_id="sig" >}}或者组织社区活动等等。 + diff --git a/content/zh/docs/reference/glossary/controller.md b/content/zh/docs/reference/glossary/controller.md new file mode 100644 index 0000000000..2b523c8b76 --- /dev/null +++ b/content/zh/docs/reference/glossary/controller.md @@ -0,0 +1,40 @@ +--- +title: 控制器 +id: controller +date: 2018-04-12 +full_link: /docs/admin/kube-controller-manager/ +short_description: > + 控制器通过 apiserver 监控集群的公共状态,并致力于将当前状态转变为期望的状态。 + +aka: +tags: +- architecture +- fundamental +--- + + + + 控制器通过 {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} 监控集群的公共状态,并致力于将当前状态转变为期望的状态。 + + + + + +Kubernetes 当前提供的部分控制器例子包括:副本控制器(replication controller)、端点控制器(endpoints controller)、命名空间控制器(namespace controller)、服务账号控制器(serviceaccounts controller)。 + diff --git a/content/zh/docs/reference/glossary/cronjob.md b/content/zh/docs/reference/glossary/cronjob.md new file mode 100644 index 0000000000..5af7746647 --- /dev/null +++ b/content/zh/docs/reference/glossary/cronjob.md @@ -0,0 +1,43 @@ +--- +title: CronJob +id: cronjob +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/cron-jobs/ +short_description: > + 管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 + +aka: +tags: +- core-object +- workload +--- + + + + + + 管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 + + + + + +Cronjob 对象类似 *crontab* 文件中的一行命令,它声明了一个遵循 [Cron](https://en.wikipedia.org/wiki/Cron) 格式的调度任务。 diff --git a/content/zh/docs/reference/glossary/csi.md b/content/zh/docs/reference/glossary/csi.md new file mode 100644 index 0000000000..afacbf8f1d --- /dev/null +++ b/content/zh/docs/reference/glossary/csi.md @@ -0,0 +1,48 @@ +--- +title: 容器存储接口 (CSI) +id: csi +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#csi +short_description: > + 容器存储接口 (CSI)定义了存储系统暴露给容器的标准接口。 + + +aka: +tags: +- storage +--- + + + + + 容器存储接口 (CSI)定义了存储系统暴露给容器的标准接口。 + + + + + +CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件,而无需将这些插件的代码添加到 Kubernetes 代码仓库(外部插件)。要使用某个存储提供商的 CSI 驱动,你首先要[将它部署到你的集群上](https://kubernetes-csi.github.io/docs/Setup.html)。然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 + +* [Kubernetes 文档中关于 CSI 的描述](/docs/concepts/storage/volumes/#csi) +* [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/Drivers.html) diff --git a/content/zh/docs/reference/glossary/customresourcedefinition.md b/content/zh/docs/reference/glossary/customresourcedefinition.md new file mode 100644 index 0000000000..510d26d3bc --- /dev/null +++ b/content/zh/docs/reference/glossary/customresourcedefinition.md @@ -0,0 +1,46 @@ +--- +title: CustomResourceDefinition +id: CustomResourceDefinition +date: 2018-04-12 +full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +short_description: > + 通过定制化的代码给您的 Kubernetes API 服务器增加资源对象,而无需编译完整的定制 API 服务器。 + +aka: +tags: +- fundamental +- operation +- extension +--- + + + + + + 通过定制化的代码给您的 Kubernetes API 服务器增加资源对象,而无需编译完整的定制 API 服务器。 + + + + + +当 Kubernetes 公开支持的 API 资源不能满足您的需要时,定制资源对象(Custom Resource Definitions)让您可以在您的环境上扩展 Kubernetes API。 + diff --git a/content/zh/docs/reference/glossary/daemonset.md b/content/zh/docs/reference/glossary/daemonset.md new file mode 100644 index 0000000000..f0ec7e9cda --- /dev/null +++ b/content/zh/docs/reference/glossary/daemonset.md @@ -0,0 +1,43 @@ +--- +title: DaemonSet +id: daemonset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/daemonset +short_description: > + 确保 Pod 的副本在集群中的一组节点上运行。 + +aka: +tags: +- fundamental +- core-object +- workload +--- + + + + 确保 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的副本在{{< glossary_tooltip text="集群" term_id="cluster" >}}中的一组节点上运行。 + + + + +用来部署系统守护进程,例如日志搜集和监控代理,这些进程通常必须运行在每个{{< glossary_tooltip text="节点" term_id="node" >}}上。 + diff --git a/content/zh/docs/reference/glossary/deployment.md b/content/zh/docs/reference/glossary/deployment.md new file mode 100644 index 0000000000..08abdc60c8 --- /dev/null +++ b/content/zh/docs/reference/glossary/deployment.md @@ -0,0 +1,45 @@ +--- +title: Deployment +id: deployment +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/deployment/ +short_description: > + Deployment 是管理应用副本的 API 对象。 + +aka: +tags: +- fundamental +- core-object +- workload +--- + + + + + + Deployment 是管理应用副本的 API 对象。 + + + + + +应用的每个副本就是一个 {{< glossary_tooltip term_id="pod" >}},并且这些 Pod 会分散运行在集群的节点上。 diff --git a/content/zh/docs/reference/glossary/developer.md b/content/zh/docs/reference/glossary/developer.md new file mode 100755 index 0000000000..2efbeea6e2 --- /dev/null +++ b/content/zh/docs/reference/glossary/developer.md @@ -0,0 +1,42 @@ +--- +title: 开发者 (释疑) +id: developer +date: 2018-04-12 +full_link: +short_description: > + 指的是:应用开发者、代码贡献者、或平台开发者。 + +aka: +tags: +- community +- user-type +--- + + + + 指的是: {{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、 {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、或 {{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。 + + + + + +根据上下文的不同,“开发者”这个被多处使用的词条会有不同的含义。 + + + diff --git a/content/zh/docs/reference/glossary/docker.md b/content/zh/docs/reference/glossary/docker.md new file mode 100755 index 0000000000..1d7c9a8511 --- /dev/null +++ b/content/zh/docs/reference/glossary/docker.md @@ -0,0 +1,41 @@ +--- +title: docker +id: docker +date: 2018-04-12 +full_link: /docs/reference/kubectl/docker-cli-to-kubectl/ +short_description: > + Docker 是一种可以提供操作系统级别虚拟化(也称作容器)的软件技术。 + +aka: +tags: +- fundamental +--- + + + + + + Docker 是一种可以提供操作系统级别虚拟化(也称作容器)的软件技术 + + + + + +Docker 使用了 Linux 内核中的资源隔离特性(如 cgroup 和内核命名空间)以及支持联合文件系统(如 OverlayFS 和其他),允许多个相互独立的“容器”一起运行在同一 Linux 实例上,从而避免启动和维护虚拟机(VMs)的开销。 diff --git a/content/zh/docs/reference/glossary/downstream.md b/content/zh/docs/reference/glossary/downstream.md new file mode 100755 index 0000000000..54f66a2bb1 --- /dev/null +++ b/content/zh/docs/reference/glossary/downstream.md @@ -0,0 +1,44 @@ +--- +title: 下游(消除歧义) +id: downstream +date: 2018-04-12 +full_link: +short_description: > + 可以指:Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。 + +aka: +tags: +- community +--- + + + +<-- +May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo. +--> + +可以指:Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。 + + + + + +* 在 **Kubernetes 社区**中:*下游(downstream)* 在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如,Kubernete 的一个新特性可以被*下游(downstream)* 应用采用,以提升它们的功能性。 +* 在 **GitHub** 或 **git** 中:约定用*下游(downstream)* 表示分支代码库,源代码库被认为是*上游(upstream)*。 + diff --git a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100755 index 0000000000..4f53bbef9d --- /dev/null +++ b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,44 @@ +--- +title: 动态卷供应 +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /docs/concepts/storage/dynamic-provisioning +short_description: > + 允许用户请求自动创建存储卷。 + +aka: +tags: +- core-object +- storage +--- + + + + + + 允许用户请求自动创建存储 {{< glossary_tooltip text="卷" term_id="volume" >}}。 + + + + + +动态供应让集群管理员无需再预先供应存储。相反,它通过用户请求自动地供应存储。 +动态卷供应是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的,StorageClass 可以引用 {{< glossary_tooltip text="卷插件(Volume Plugin)" term_id="volume-plugin" >}} 提供的 {{< glossary_tooltip text="卷(Volume)" term_id="volume" >}} ,也可以引用传递给卷插件(Volume Plugin)的参数集。 diff --git a/content/zh/docs/reference/glossary/etcd.md b/content/zh/docs/reference/glossary/etcd.md new file mode 100644 index 0000000000..916fa44122 --- /dev/null +++ b/content/zh/docs/reference/glossary/etcd.md @@ -0,0 +1,43 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + etcd 是兼具一致性和高可用性的键值数据库,用作保存 Kubernetes 所有集群数据的后台数据库。 + +aka: +tags: +- architecture +- storage +--- + + + + + +etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。 + + + + + +您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息,请参考 [etcd 文档](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)。 diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh/docs/reference/glossary/flexvolume.md new file mode 100644 index 0000000000..5cb6b7b9e4 --- /dev/null +++ b/content/zh/docs/reference/glossary/flexvolume.md @@ -0,0 +1,51 @@ +--- +title: Flexvolume +id: flexvolume +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#flexvolume +short_description: > + Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口(CSI)" term_id="csi" >}} 是比 Flexvolume 更新的接口,它解决了 Flexvolumes 的一些问题。 + + +aka: +tags: +- storage +--- + + + + Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口(CSI)" term_id="csi" >}} 是比 Flexvolume 更新的接口,它解决了 Flexvolume 的一些问题。 + + + + + +Flexvolume 允许用户编写自己的驱动程序,并在 Kubernetes 中加入对用户自己的数据卷的支持。 +FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。这需要 root 权限。 +如果可能的话,SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序,因为它解决了 Flexvolumes 的限制。 + + + +* [Kubernetes 文档中的 Flexvolume](/docs/concepts/storage/volumes/#flexvolume) +* [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) +* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/zh/docs/reference/glossary/helm-chart.md b/content/zh/docs/reference/glossary/helm-chart.md new file mode 100755 index 0000000000..d76c6a7906 --- /dev/null +++ b/content/zh/docs/reference/glossary/helm-chart.md @@ -0,0 +1,43 @@ +--- +title: Helm Chart +id: helm-chart +date: 2018-04-12 +full_link: https://github.com/kubernetes/helm/blob/master/docs/charts.md +short_description: > + Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包,可以使用 Helm 工具对其进行管理。 + +aka: +tags: +- tool +--- + + + + + +Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包,可以使用 Helm 工具对其进行管理。 + + + + + +Chart 提供了一种可重现的用来创建和共享 Kubernetes 应用的方法。 +单个 Chart 可用来部署简单的系统(例如一个 memcached Pod),也可以用来部署复杂的系统(例如包含 HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈)。 diff --git a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md new file mode 100755 index 0000000000..663ebd26c8 --- /dev/null +++ b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -0,0 +1,37 @@ +--- +title: Pod 水平自动扩缩器 +id: horizontal-pod-autoscaler +date: 2018-04-12 +full_link: /docs/tasks/run-application/horizontal-pod-autoscale/ +short_description: > + Pod 水平自动扩缩器(Horizontal Pod Autoscaler)是一种 API 资源,它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 + +aka: +tags: +- operation +--- + + + + Pod 水平自动扩缩器(Horizontal Pod Autoscaler)是一种 API 资源,它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 + + + + + +HPA 通常用于 {{< glossary_tooltip text="Replication Controllers" term_id="replication-controller" >}}、{{< glossary_tooltip text="Deployments" term_id="deployment" >}} 或者 Replica Sets 上。HPA 不能用于不支持扩缩的对象,例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。 diff --git a/content/zh/docs/reference/glossary/image.md b/content/zh/docs/reference/glossary/image.md new file mode 100755 index 0000000000..1fc7db55e5 --- /dev/null +++ b/content/zh/docs/reference/glossary/image.md @@ -0,0 +1,42 @@ +--- +title: 镜像 +id: image +date: 2018-04-12 +full_link: +short_description: > + 镜像是保存的容器实例,它打包了应用运行所需的一组软件。 + +aka: +tags: +- fundamental +--- + + + + + +镜像是保存的容器实例,它打包了应用运行所需的一组软件。 + + + + + +镜像是软件打包的一种方式,可以将镜像存储在容器镜像仓库、拉取到本地系统并作为应用来运行。 +镜像中包含的元数据指明了运行什么可执行程序、是由谁构建的以及其他信息。 diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh/docs/reference/glossary/index.md new file mode 100755 index 0000000000..6fc5f767f3 --- /dev/null +++ b/content/zh/docs/reference/glossary/index.md @@ -0,0 +1,23 @@ +--- +approvers: +- chenopis +- abiogenesis-now +title: 标准化词汇表 +layout: glossary +noedit: true +default_active_tag: fundamental +weight: 5 +--- + + diff --git a/content/zh/docs/reference/glossary/ingress.md b/content/zh/docs/reference/glossary/ingress.md new file mode 100644 index 0000000000..806dec752d --- /dev/null +++ b/content/zh/docs/reference/glossary/ingress.md @@ -0,0 +1,46 @@ +--- +title: Ingress +id: ingress +date: 2018-04-12 +full_link: /docs/concepts/services-networking/ingress/ +short_description: > + Ingress 是对集群中服务的外部访问进行管理的 API 对象,典型的访问方式是 HTTP。 + +aka: +tags: +- networking +- architecture +- extension +--- + + + + + + Ingress 是对集群中服务的外部访问进行管理的 API 对象,典型的访问方式是 HTTP。 + + + + + +Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 + diff --git a/content/zh/docs/reference/glossary/init-container.md b/content/zh/docs/reference/glossary/init-container.md new file mode 100755 index 0000000000..cf8cead312 --- /dev/null +++ b/content/zh/docs/reference/glossary/init-container.md @@ -0,0 +1,41 @@ +--- +title: 初始化容器 +id: init-container +date: 2018-04-12 +full_link: +short_description: > + 应用容器运行前必须先运行完成的一个或多个初始化容器。 + +aka: +tags: +- fundamental +--- + + + + + + 应用容器运行前必须先运行完成的一个或多个初始化容器。 + + + + + +初始化(init)容器像常规应用容器一样,只有一点不同:初始化(init)容器必须在应用容器启动前运行完成。Init 容器的运行顺序:一个初始化(init)容器必须在下一个初始化(init)容器开始前运行完成。 diff --git a/content/zh/docs/reference/glossary/istio.md b/content/zh/docs/reference/glossary/istio.md new file mode 100755 index 0000000000..58c4cfffcc --- /dev/null +++ b/content/zh/docs/reference/glossary/istio.md @@ -0,0 +1,45 @@ +--- +title: Istio +id: istio +date: 2018-04-12 +full_link: https://istio.io/docs/concepts/what-is-istio/overview.html +short_description: > + Istio 是个开放平台(非 Kubernetes 特有),提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。 +aka: +tags: +- networking +- architecture +- extension +--- + + + + + +Istio 是个开放平台(非 Kubernetes 特有),提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。 + + + + + +添加 Istio 时不需要修改应用代码。它是基础设施的一层,介于服务和网络之间。当它和服务的 Deployment 相结合时,就构成了通常所谓的服务网格(Service Mesh)。Istio 的控制面抽象掉了底层的集群管理平台,这一集群管理平台可以是 Kubernetes、Mesosphere 等。 + diff --git a/content/zh/docs/reference/glossary/job.md b/content/zh/docs/reference/glossary/job.md new file mode 100755 index 0000000000..8ce421f280 --- /dev/null +++ b/content/zh/docs/reference/glossary/job.md @@ -0,0 +1,45 @@ +--- +title: Job +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +short_description: > + Job 是需要运行完成的确定性的或批量的任务。 + +aka: +tags: +- fundamental +- core-object +- workload +--- + + + + + + Job 是需要运行完成的确定性的或批量的任务。 + + + + + +Job 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象,并确保指定数量的 Pod 成功终止。随着各 Pod 成功结束,Job 会跟踪记录成功完成的个数。 diff --git a/content/zh/docs/reference/glossary/kops.md b/content/zh/docs/reference/glossary/kops.md new file mode 100755 index 0000000000..c1024390e7 --- /dev/null +++ b/content/zh/docs/reference/glossary/kops.md @@ -0,0 +1,63 @@ +--- +title: Kops +id: kops +date: 2018-04-12 +full_link: /docs/getting-started-guides/kops/ +short_description: > + kops 是一个命令行工具,可以帮助您创建、销毁、升级和维护生产级,高可用性的 Kubernetes 集群。注意:官方仅支持 AWS,GCE 和 VMware vSphere 的支持还处于 alpha* 阶段。 + +aka: +tags: +- tool +- operation +--- + + + + + +kops 是一个命令行工具,可以帮助您创建、销毁、升级和维护生产级,高可用性的 Kubernetes 集群。*注意:官方仅支持 AWS,GCE 和 VMware vSphere 的支持还处于 alpha 阶段*。 + + + + + +`kops` 为您的集群提供了: + + * 全自动化安装 + * 基于 DNS 的集群标识 + * 自愈功能:所有组件都在自动伸缩组(Auto-Scaling Groups)中运行 + * 有限的操作系统支持 (推荐使用 Debian,支持 Ubuntu 16.04,试验性支持 CentOS & RHEL) + * 高可用 (HA) 支持 + * 直接提供或者生成 Terraform 清单文件的能力 + + + +您也可以将自己的集群作为一个构造块,使用 {{< glossary_tooltip term_id="kubeadm" >}} 构造集群。`kops` 是建立在 kubeadm 之上的。 diff --git a/content/zh/docs/reference/glossary/kube-apiserver.md b/content/zh/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..c2d0e8a9eb --- /dev/null +++ b/content/zh/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,44 @@ +--- +title: kube-apiserver +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + 主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 + +aka: +tags: +- architecture +- fundamental +--- + + + + + +主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 + + + + + +kube-apiserver 在设计上考虑了水平扩缩的需要。 +换言之,通过部署多个实例可以实现扩缩。 +参见[构造高可用集群](/docs/admin/high-availability/)。 + diff --git a/content/zh/docs/reference/glossary/kube-controller-manager.md b/content/zh/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..c24234e501 --- /dev/null +++ b/content/zh/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,39 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/generated/kube-controller-manager/ +short_description: > + 主节点上运行控制器的组件。 + +aka: +tags: +- architecture +- fundamental +--- + + + + +在主节点上运行{{< glossary_tooltip text="控制器" term_id="controller" >}}的组件。 + + + +从逻辑上讲,每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。 + diff --git a/content/zh/docs/reference/glossary/kube-proxy.md b/content/zh/docs/reference/glossary/kube-proxy.md new file mode 100755 index 0000000000..64a3626920 --- /dev/null +++ b/content/zh/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,43 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/generated/kube-proxy +short_description: > + `kube-proxy` 是集群中每个节点上运行的网络代理。 + +aka: +tags: +- fundamental +- core-object +--- + + + + + +`kube-proxy` 是集群中每个节点上运行的网络代理。 + + + + + +`kube-proxy` 负责转发请求。`kube-proxy` 能够提供 TCP 和 UDP 的流转发,也可为一组后端功能点提供轮转式 TCP 和 UDP 转发。 diff --git a/content/zh/docs/reference/glossary/kube-scheduler.md b/content/zh/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..67d82d98d7 --- /dev/null +++ b/content/zh/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,42 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 + +aka: +tags: +- architecture +- scheduler +--- + + + + + +主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 + + + + + +调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 diff --git a/content/zh/docs/reference/glossary/kubeadm.md b/content/zh/docs/reference/glossary/kubeadm.md new file mode 100644 index 0000000000..3d7ce11b59 --- /dev/null +++ b/content/zh/docs/reference/glossary/kubeadm.md @@ -0,0 +1,43 @@ +--- +title: Kubeadm +id: kubeadm +date: 2018-04-12 +full_link: /docs/admin/kubeadm/ +short_description: > + 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 + +aka: +tags: +- tool +- operation +--- + + + + + + 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 + + + + + +您可以使用 kubeadm 安装控制面和工作节点组件。 diff --git a/content/zh/docs/reference/glossary/kubectl.md b/content/zh/docs/reference/glossary/kubectl.md new file mode 100755 index 0000000000..2c8bde22eb --- /dev/null +++ b/content/zh/docs/reference/glossary/kubectl.md @@ -0,0 +1,43 @@ +--- +title: Kubectl +id: kubectl +date: 2018-04-12 +full_link: /docs/user-guide/kubectl-overview/ +short_description: > + kubectl 是用来和 Kubernetes API 服务器进行通信的命令行工具。 + +aka: +tags: +- tool +- fundamental +--- + + + + + + kubectl 是用来和 {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} 服务器进行通信的命令行工具。 + + + + + +您可以使用 kubectl 创建、检查、更新和删除 Kubernetes 对象。 diff --git a/content/zh/docs/reference/glossary/kubelet.md b/content/zh/docs/reference/glossary/kubelet.md new file mode 100755 index 0000000000..c561109b6e --- /dev/null +++ b/content/zh/docs/reference/glossary/kubelet.md @@ -0,0 +1,40 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +short_description: > + 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 + +aka: +tags: +- fundamental +- core-object +--- + + +一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 + + + + + +kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 diff --git a/content/zh/docs/reference/glossary/kubernetes-api.md b/content/zh/docs/reference/glossary/kubernetes-api.md new file mode 100755 index 0000000000..fc1dbeac6a --- /dev/null +++ b/content/zh/docs/reference/glossary/kubernetes-api.md @@ -0,0 +1,47 @@ +--- +title: Kubernetes API +id: kubernetes-api +date: 2018-04-12 +full_link: /docs/concepts/overview/kubernetes-api/ +short_description: > + Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 + +aka: +tags: +- fundamental +- architecture +--- + + + + + +Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 + + + + + +Kubernetes 资源和"意向记录"都是作为 API 对象储存的,并可以通过对 API 的 RESTful 调用进行修改。 +API 允许以声明方式管理配置。 +用户可以直接和 Kubernetes API 交互,也可以通过 `kubectl` 这样的工具进行交互。 +核心的 Kubernetes API 是很灵活的,可以扩展以支持定制资源。 + diff --git a/content/zh/docs/reference/glossary/label.md b/content/zh/docs/reference/glossary/label.md new file mode 100755 index 0000000000..6201aaeb29 --- /dev/null +++ b/content/zh/docs/reference/glossary/label.md @@ -0,0 +1,41 @@ +--- +title: 标签 +id: label +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels +short_description: > + 用来为对象设置可标识的属性标记;这些标记对用户而言是有意义且重要的。 + +aka: +tags: +- fundamental +--- + + + + + +用来为对象设置可标识的属性标记;这些标记对用户而言是有意义且重要的。 + + + + + +标签是一些关联到 {{< glossary_tooltip text="Pods" term_id="pod" >}} 这类对象上的键值对。 +它们通常用来组织和选择对象子集。 + diff --git a/content/zh/docs/reference/glossary/managed-service.md b/content/zh/docs/reference/glossary/managed-service.md new file mode 100755 index 0000000000..fb7d5440c9 --- /dev/null +++ b/content/zh/docs/reference/glossary/managed-service.md @@ -0,0 +1,42 @@ +--- +title: 托管服务 +id: managed-service +date: 2018-04-12 +full_link: +short_description: > + 由第三方供应商负责维护的一种软件产品。 + +aka: +tags: +- extension +--- + + + + + +由第三方供应商负责维护的一种软件产品。 + + + + + +托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等, +不过它们也可以是可以被某应用使用的任何软件交付件。 +[服务目录](/docs/concepts/service-catalog/)提供了一种方法用来列举、供应和绑定到 +{{< glossary_tooltip text="服务代理商" term_id="service-broker" >}}所提供的托管服务。 diff --git a/content/zh/docs/reference/glossary/member.md b/content/zh/docs/reference/glossary/member.md new file mode 100644 index 0000000000..57e7cac386 --- /dev/null +++ b/content/zh/docs/reference/glossary/member.md @@ -0,0 +1,42 @@ +--- +title: 成员 +id: member +date: 2018-04-12 +full_link: +short_description: > + K8s 社区中持续活跃的贡献者。 + +aka: +tags: +- community +--- + + + + + + K8s 社区中持续活跃的贡献者。 + + + + + +可以将问题单(issue)和 PR 指派给成员,成员也可以通过 GitHub 小组加入 {{< glossary_tooltip text="特别兴趣小组 (SIGs)" term_id="sig" >}}。针对成员所提交的 PR,系统自动运行提交前测试。成员应该是持续活跃的社区贡献者。 + diff --git a/content/zh/docs/reference/glossary/minikube.md b/content/zh/docs/reference/glossary/minikube.md new file mode 100755 index 0000000000..e88e513ba4 --- /dev/null +++ b/content/zh/docs/reference/glossary/minikube.md @@ -0,0 +1,43 @@ +--- +title: Minikube +id: minikube +date: 2018-04-12 +full_link: /docs/getting-started-guides/minikube/ +short_description: > + Minikube 是用来在本地运行 Kubernetes 的一种工具。 + +aka: +tags: +- fundamental +- tool +--- + + + + + +Minikube 是用来在本地运行 Kubernetes 的一种工具。 + + + + + +Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 diff --git a/content/zh/docs/reference/glossary/name.md b/content/zh/docs/reference/glossary/name.md new file mode 100755 index 0000000000..05532e0927 --- /dev/null +++ b/content/zh/docs/reference/glossary/name.md @@ -0,0 +1,41 @@ +--- +title: 名称 +id: name +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + 客户端提供的字符串,用来指代资源 URL 中的对象,如 `/api/v1/pods/some-name`。 + +aka: +tags: +- fundamental +--- + + + + + +客户端提供的字符串,用来指代资源 URL 中的对象,如 `/api/v1/pods/some-name`。 + + + + + +对给定资源类型 (kind) 而言,同一时刻只能有一个对象使用给定的名称。不过,如果该对象被删除,则可以使用同一名称创建新新对象。 diff --git a/content/zh/docs/reference/glossary/namespace.md b/content/zh/docs/reference/glossary/namespace.md new file mode 100644 index 0000000000..42019215cf --- /dev/null +++ b/content/zh/docs/reference/glossary/namespace.md @@ -0,0 +1,41 @@ +--- +title: 命名空间 +id: namespace +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/namespaces +short_description: > + 命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。 + +aka: +tags: +- fundamental +--- + + + + + +命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。 + + + + + +命名空间用来组织集群中对象,并为集群资源划分提供了一种方法。同一命名空间内的资源名称必须唯一,但跨命名空间时不作要求。 diff --git a/content/zh/docs/reference/glossary/network-policy.md b/content/zh/docs/reference/glossary/network-policy.md new file mode 100755 index 0000000000..25269bcc05 --- /dev/null +++ b/content/zh/docs/reference/glossary/network-policy.md @@ -0,0 +1,44 @@ +--- +title: 网络策略 +id: network-policy +date: 2018-04-12 +full_link: /docs/concepts/services-networking/network-policies/ +short_description: > + 网络策略是一种规范,规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 + +aka: +tags: +- networking +- architecture +- extension +--- + + + +网络策略是一种规范,规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 + + + + + +网络策略帮助您声明式地配置允许哪些 Pod 之间接、哪些命名空间之间允许进行通信,并具体配置了哪些端口号来执行各个策略。`NetworkPolicy` 资源使用标签来选择 Pod,并定义了所选 Pod 可以接受什么样的流量。网络策略由网络提供商提供的并被 Kubernetes 支持的网络插件实现。请注意,当没有控制器实现网络资源时,创建网络资源将不会生效。 diff --git a/content/zh/docs/reference/glossary/node.md b/content/zh/docs/reference/glossary/node.md new file mode 100755 index 0000000000..d1756799b7 --- /dev/null +++ b/content/zh/docs/reference/glossary/node.md @@ -0,0 +1,43 @@ +--- +title: 节点 +id: node +date: 2018-04-12 +full_link: /docs/concepts/architecture/nodes/ +short_description: > + Kubernetes 中的工作机器称作节点。 + +aka: +tags: +- fundamental +--- + + + + + +Kubernetes 中的工作机器称作节点。 + + + + + +工作机器可以是虚拟机也可以是物理机,取决于集群的配置。 +其上部署了运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所必需的{{< glossary_tooltip text="服务" term_id="service" >}}, +并由主控组件来管理。 +节点上的{{< glossary_tooltip text="服务" term_id="service" >}}包括 Docker、kubelet 和 kube-proxy。 + diff --git a/content/zh/docs/reference/glossary/persistent-volume-claim.md b/content/zh/docs/reference/glossary/persistent-volume-claim.md new file mode 100755 index 0000000000..00fc0c563f --- /dev/null +++ b/content/zh/docs/reference/glossary/persistent-volume-claim.md @@ -0,0 +1,39 @@ +--- +title: 持久卷申领 +id: persistent-volume-claim +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + 声明在持久卷中定义的存储资源,以便可以将其挂载为容器中的卷。 + +aka: +tags: +- core-object +- storage +--- + + + + +申领持久卷中定义的存储资源,以便可以将其挂载为容器中的卷。 + + + + +指定存储的数量,如何访问存储(只读、读写或独占)以及如何回收存储(保留、回收或删除)。存储本身的详细信息在 PersistentVolume 规范中。 diff --git a/content/zh/docs/reference/glossary/persistent-volume.md b/content/zh/docs/reference/glossary/persistent-volume.md new file mode 100644 index 0000000000..d2364a6f8a --- /dev/null +++ b/content/zh/docs/reference/glossary/persistent-volume.md @@ -0,0 +1,48 @@ +--- +title: 持久卷 +id: persistent-volume +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + 持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。 + +aka: +tags: +- core-object +- storage +--- + + + + + +持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。 + + + + + +持久卷(PersistentVolumes,PV)提供了一个 API,该 API 对存储的供应方式细节进行抽象,令其与使用方式相分离。 +在提前创建存储(静态供应)的场景中,PV 可以直接使用。 +在按需提供存储(动态供应)的场景中,需要使用 PersistentVolumeClaims (PVCs)。 + diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh/docs/reference/glossary/platform-developer.md new file mode 100755 index 0000000000..0cc10ac633 --- /dev/null +++ b/content/zh/docs/reference/glossary/platform-developer.md @@ -0,0 +1,42 @@ +--- +title: 平台开发者 +id: platform-developer +date: 2018-04-12 +full_link: +short_description: > + 定制 Kubernetes 平台以满足自己的项目需求的人。 + +aka: +tags: +- user-type +--- + + + + + + 定制 Kubernetes 平台以满足自己的项目需求的人。 + + + + + +例如,平台开发人员可以使用[定制资源](/docs/concepts/api-extension/custom-resources/)或[使用汇聚层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation/) 来为其 Kubernetes 实例增加功能,特别是为其应用程序添加功能。一些平台开发人员也是 Kubrenetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}},他们会开发贡献给 Kubernetes 社区的扩展;另一些则开发封闭源代码的商业扩展或用于特定功能的扩展。 + diff --git a/content/zh/docs/reference/glossary/pod-security-policy.md b/content/zh/docs/reference/glossary/pod-security-policy.md new file mode 100644 index 0000000000..e9937009cd --- /dev/null +++ b/content/zh/docs/reference/glossary/pod-security-policy.md @@ -0,0 +1,46 @@ +--- +title: Pod 安全策略 +id: pod-security-policy +date: 2018-04-12 +full_link: /docs/concepts/policy/pod-security-policy/ +short_description: > + 为 Pod 的创建和更新操作启用细粒度的授权。 + +aka: +tags: +- core-object +- fundamental +--- + + + + + +为 Pod 的创建和更新操作启用细粒度的授权。 + + + + + +Pod 安全策略是集群级别的资源,它控制着 Pod 规约中的安全性敏感的内容。 +`PodSecurityPolicy`对象定义了一组条件以及相关字段的默认值,Pod 运行时必须满足这些条件。Pod 安全策略控制实现上体现为一个可选的准入控制器。 + + diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh/docs/reference/glossary/pod.md new file mode 100755 index 0000000000..d8fcbb4cee --- /dev/null +++ b/content/zh/docs/reference/glossary/pod.md @@ -0,0 +1,43 @@ +--- +title: Pod +id: pod +date: 2018-04-12 +full_link: /docs/concepts/workloads/pods/pod-overview/ +short_description: > + Pod 是 Kubernetes 的原子对象。Pod 表示您的集群上一组正在运行的容器。 + +aka: +tags: +- core-object +- fundamental +--- + + + + + + Pod 是 Kubernetes 的原子对象。Pod 表示您的集群上一组正在运行的{{< glossary_tooltip text="容器" term_id="container" >}}。 + + + + + +通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的挂斗(sidecar)容器,以添加诸如日志记录之类的补充特性。通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。 diff --git a/content/zh/docs/reference/glossary/podpreset.md b/content/zh/docs/reference/glossary/podpreset.md new file mode 100755 index 0000000000..3c5789de6d --- /dev/null +++ b/content/zh/docs/reference/glossary/podpreset.md @@ -0,0 +1,40 @@ +--- +title: PodPreset +id: podpreset +date: 2018-04-12 +full_link: +short_description: > + PodPreset 是一种 API 对象,在创建 Pod 时将诸如 Secret、卷挂载和环境变量之类的信息注入到该 Pod 中。 + +aka: +tags: +- operation +--- + + + + +PodPreset 是一种 API 对象,在创建 Pod 时将诸如 Secret、卷挂载和环境变量之类的信息注入到该 Pod 中。 + + + + + +此 API 对象使用标准选择器选择 Pod 并向其中注入信息。这允许 podspec 定义是非特定的,从而将 podspec 与环境特定的配置解耦。 diff --git a/content/zh/docs/reference/glossary/quantity.md b/content/zh/docs/reference/glossary/quantity.md new file mode 100644 index 0000000000..70d5a95ffa --- /dev/null +++ b/content/zh/docs/reference/glossary/quantity.md @@ -0,0 +1,60 @@ +--- +title: 数量 +id: quantity +date: 2018-08-07 +full_link: +short_description: > + 使用 SI 后缀的小数或大数的整数表示。 + +aka: +tags: +- core-object +--- + + + + +数量是使用紧凑的整数表示法的小数或大数的表示,并带有国际计量单位制(SI)后缀。 +小数用 milli 单位表示,而大数用 kilo、mega 或 giga 单位表示。 + +例如,数字 `1.5` 表示为`1500m`, +而数字`1000`表示为`1k`,`1000000`表示为`1M`。 +您还可以指定二进制表示法后缀; 数字 2048 可以写成`2Ki`。 + +公认的十进制(10的幂)单位是 `m`(milli)、`k`(kilo, +有意小写)、`M`(mega),`G`(giga)、`T`(terra)、`P`(peta)、 +`E`(exa)。 + +公认的二进制(2的幂)单位是 `Ki` (kibi)、 `Mi` (mebi)、`Gi` (gibi)、 +`Ti` (tebi)、 `Pi` (pebi)、 `Ei` (exbi)。 + + diff --git a/content/zh/docs/reference/glossary/rbac.md b/content/zh/docs/reference/glossary/rbac.md new file mode 100755 index 0000000000..6f045ed9d0 --- /dev/null +++ b/content/zh/docs/reference/glossary/rbac.md @@ -0,0 +1,43 @@ +--- +title: RBAC(基于角色的访问控制) +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + 管理授权决策,允许管理员通过 Kubernetes API 动态配置访问策略。 + +aka: +tags: +- security +- fundamental +--- + + + + +管理授权决策,允许管理员通过 {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} 动态配置访问策略。 + + + + +RBAC 使用 *角色* (包含权限规则)和 *角色绑定* (将角色中定义的权限授予一组用户)。 + + diff --git a/content/zh/docs/reference/glossary/replica-set.md b/content/zh/docs/reference/glossary/replica-set.md new file mode 100755 index 0000000000..5f394133b6 --- /dev/null +++ b/content/zh/docs/reference/glossary/replica-set.md @@ -0,0 +1,45 @@ +--- +title: ReplicaSet +id: replica-set +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + ReplicaSet 是下一代副本控制器。 + +aka: +tags: +- fundamental +- core-object +- workload +--- + + + + + +ReplicaSet 是下一代副本控制器。 + + + + + +ReplicaSet 就像 ReplicationController 那样,确保一次运行指定数量的 Pod 副本。ReplicaSet 支持新的基于集合的选择器需求(在标签的用户指南中有相关描述),而副本控制器只支持基于等值的选择器需求。 diff --git a/content/zh/docs/reference/glossary/replication-controller.md b/content/zh/docs/reference/glossary/replication-controller.md new file mode 100644 index 0000000000..8fd910e799 --- /dev/null +++ b/content/zh/docs/reference/glossary/replication-controller.md @@ -0,0 +1,43 @@ +--- +title: Replication Controller +id: replication-controller +date: 2018-04-12 +full_link: +short_description: > + Replication Controller 是 Kubernetes 的一种服务,用来确保给定个数的 Pod 一直处于运行状态。 + +aka: +tags: +- workload +- core-object +--- + + + + + +Replication Controller 是 Kubernetes 的一种服务,用来确保给定个数的 Pod 一直处于运行状态。 + + + + + +Replication Controller 会基于设定值自动增删 Pod 的实例。如果 Pod 被误删除或者启动实例过多,Replication Controller 允许 Pod 的实例个数恢复到设定值。 diff --git a/content/zh/docs/reference/glossary/resource-quota.md b/content/zh/docs/reference/glossary/resource-quota.md new file mode 100755 index 0000000000..c0f40f3234 --- /dev/null +++ b/content/zh/docs/reference/glossary/resource-quota.md @@ -0,0 +1,47 @@ +--- +title: 资源配额 +id: resource-quota +date: 2018-04-12 +full_link: /docs/concepts/policy/resource-quotas/ +short_description: > + 资源配额提供了限制每个命名空间的资源消耗总和的约束。 + +aka: +tags: +- fundamental +- operation +- architecture +--- + + + + + +资源配额提供了限制每个 {{< glossary_tooltip text="命名空间" term_id="namespace">}} 的资源消耗总和的约束。 + + + + + +限制了命名空间中每种对象可以创建的数量,也限制了项目中可被资源对象利用的计算资源总数。 + + diff --git a/content/zh/docs/reference/glossary/reviewer.md b/content/zh/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000..a181122927 --- /dev/null +++ b/content/zh/docs/reference/glossary/reviewer.md @@ -0,0 +1,41 @@ +--- +title: 评审者 +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + 评审者是负责评审项目的某部分代码以便提高代码质量和正确性的人。 + +aka: +tags: +- community +--- + + + + + + 评审者是负责评审项目的某部分代码以便提高代码质量和正确性的人。 + + + + + +评审者既要了解代码库又要了解软件工程规范。评审者状态是基于代码库的组成部分来设定的。 diff --git a/content/zh/docs/reference/glossary/secret.md b/content/zh/docs/reference/glossary/secret.md new file mode 100755 index 0000000000..a43dbb6ece --- /dev/null +++ b/content/zh/docs/reference/glossary/secret.md @@ -0,0 +1,45 @@ +--- +title: Secret +id: secret +date: 2018-04-12 +full_link: /docs/concepts/configuration/secret/ +short_description: > + Secret 用于存储敏感信息,如密码、OAuth 令牌和 SSH 密钥。 + +aka: +tags: +- core-object +- security +--- + + + + + + Secret 用于存储敏感信息,如密码、OAuth 令牌和 SSH 密钥。 + + + + + +Secret 允许用户对如何使用敏感信息进行更多的控制,并减少信息意外暴露的风险,包括静态[加密](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)。 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 通过挂载卷中的文件的方式引用 Secret,或者通过 kubelet 为 pod 拉取镜像时引用。 +Secret 非常适合机密数据使用,而 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) 适用于非机密数据。 diff --git a/content/zh/docs/reference/glossary/security-context.md b/content/zh/docs/reference/glossary/security-context.md new file mode 100755 index 0000000000..31b99c635c --- /dev/null +++ b/content/zh/docs/reference/glossary/security-context.md @@ -0,0 +1,43 @@ +--- +title: 安全上下文(Security Context) +id: security-context +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/security-context/ +short_description: > + securityContext 字段定义 Pod 或容器的特权和访问控制设置,包括运行时 UID 和 GID。 + +aka: +tags: +- security +--- + + + + +securityContext 字段定义 Pod 或容器的特权和访问控制设置,包括运行时 UID 和 GID。 + + + + +{{< glossary_tooltip term_id="pod" >}} 或者容器中的 securityContext 字段(应用于所有容器)用于设置容器进程使用的用户(runAsUser)和组 (fsGroup)、权能字、特权设置和安全策略(SELinux/AppArmor/Seccomp)。 + + + + diff --git a/content/zh/docs/reference/glossary/selector.md b/content/zh/docs/reference/glossary/selector.md new file mode 100644 index 0000000000..5a3e83ef0d --- /dev/null +++ b/content/zh/docs/reference/glossary/selector.md @@ -0,0 +1,42 @@ +--- +title: 选择算符 +id: selector +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels/ +short_description: > + 选择算符允许用户通过标签对一组资源对象进行筛选过滤。 + +aka: +tags: +- fundamental +--- + + + + + +选择算符允许用户通过标签对一组资源对象进行筛选过滤。 + + + + + +在查询资源列表时,选择算符可以通过 {{< glossary_tooltip text="标签" term_id="label" >}} 对资源进行过滤筛选。 + diff --git a/content/zh/docs/reference/glossary/service-account.md b/content/zh/docs/reference/glossary/service-account.md new file mode 100755 index 0000000000..4dd29b301b --- /dev/null +++ b/content/zh/docs/reference/glossary/service-account.md @@ -0,0 +1,43 @@ +--- +title: 服务账户 +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + 为在 Pod 中运行的进程提供标识。 + +aka: +tags: +- fundamental +- core-object +--- + + + + +为在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的进程提供标识。 + + + + +当 Pod 中的进程访问集群时,API 服务器将它们作为特定的服务帐户进行身份验证,例如 `default`。当您创建 Pod 时,如果您没有指定服务帐户,它将在相同的命名空间 {{< glossary_tooltip text="命名空间" term_id="namespace" >}} 中自动分配 default 服务账户。 + + diff --git a/content/zh/docs/reference/glossary/service-broker.md b/content/zh/docs/reference/glossary/service-broker.md new file mode 100755 index 0000000000..8a017d127b --- /dev/null +++ b/content/zh/docs/reference/glossary/service-broker.md @@ -0,0 +1,42 @@ +--- +title: 服务代理(Service Broker) +id: service-broker +date: 2018-04-12 +full_link: +short_description: > + 由第三方提供并维护的一组托管服务的访问端点。 + +aka: +tags: +- extension +--- + + + + + +由第三方提供并维护的一组{{< glossary_tooltip text="托管服务" term_id="managed-service">}} 的访问端点。 + + + + + +{{< glossary_tooltip text="服务代理" term_id="service-broker">}}会实现 +[开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) +并为应用提供使用其托管服务的标准接口。 +[服务目录(Service Catalog)](/docs/concepts/service-catalog/)则提供一种方法,用来列举、供应和绑定服务代理商所提供的托管服务。 diff --git a/content/zh/docs/reference/glossary/service-catalog.md b/content/zh/docs/reference/glossary/service-catalog.md new file mode 100644 index 0000000000..726aff57c2 --- /dev/null +++ b/content/zh/docs/reference/glossary/service-catalog.md @@ -0,0 +1,43 @@ +--- +title: 服务目录 +id: service-catalog +date: 2018-04-12 +full_link: +short_description: > + 服务目录是一种扩展 API,它能让 Kubernetes 集群中运行的应用易于使用外部托管的软件服务,例如云供应商提供的数据仓库服务。 + + An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. +aka: +tags: +- extension +--- + + + + + +服务目录(Service Catalog)是一种扩展 API,它能让 Kubernetes 集群中运行的应用易于使用外部托管的的软件服务,例如云供应商提供的数据仓库服务。 + + + + + +服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="服务代理人(Service Brokers)" term_id="service-broker" >}} 提供的外部 {{< glossary_tooltip text="托管服务" term_id="managed-service" >}},而无需知道那些服务具体是怎样创建和托管的。 + diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md new file mode 100755 index 0000000000..6d2f3f0078 --- /dev/null +++ b/content/zh/docs/reference/glossary/service.md @@ -0,0 +1,43 @@ +--- +title: Service +id: service +date: 2018-04-12 +full_link: /docs/concepts/services-networking/service/ +short_description: > + Service 是一种 API 资源对象,它描述了应用的访问方式,例如包含一组 Pod 的应用如何进行访问,Service 还可以描述端口和负载均衡。 + +aka: +tags: +- fundamental +- core-object +--- + + + + + + Service 是一种 API 资源对象,它描述了应用的访问方式,例如包含一组 Pod 的应用如何进行访问,Service 还可以描述端口和负载均衡。 + + + + + +Service 的接入点可以是集群内部的也可以是集群外部的。 diff --git a/content/zh/docs/reference/glossary/sig.md b/content/zh/docs/reference/glossary/sig.md new file mode 100755 index 0000000000..a42a15b0b1 --- /dev/null +++ b/content/zh/docs/reference/glossary/sig.md @@ -0,0 +1,48 @@ +--- +title: SIG (特别兴趣小组) +id: sig +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list +short_description: > + 共同管理大范畴 Kubernetes 开源项目中某组件或方面的一组社区成员。 + +aka: +tags: +- community +--- + + + + + +共同管理大范畴 Kubernetes 开源项目中某组件或方面的一组{{< glossary_tooltip text="社区成员" term_id="member" >}}。 + + + + + +SIG 中的成员对推进某个领域(如体系结构、API 机制构件或者文档)具有相同的兴趣。 +SIGs 必须遵从 [SIG Governance](https://github.com/kubernetes/community/blob/master/sig-governance.md) 的规定, +不过可以有自己的贡献策略以及通信渠道(方式)。 + +更多的详细信息可参阅 [kubernetes/community](https://github.com/kubernetes/community) 仓库以及 +[SIGs 和工作组(Working Groups)](https://github.com/kubernetes/community/blob/master/sig-list.md)的最新列表。 + diff --git a/content/zh/docs/reference/glossary/statefulset.md b/content/zh/docs/reference/glossary/statefulset.md new file mode 100644 index 0000000000..ff63c63ce1 --- /dev/null +++ b/content/zh/docs/reference/glossary/statefulset.md @@ -0,0 +1,49 @@ +--- +title: StatefulSet +id: statefulset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/statefulset/ +short_description: > + StatefulSet 用来管理 Deployment 和伸缩一组 Pod,并且能为这些 Pod 提供*序号和唯一性保证*。 +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- + + + + StatefulSet 用来管理 Deployment 和扩展一组 Pod,并且能为这些 Pod 提供*序号和唯一性保证*。 + + + + + +和 {{< glossary_tooltip term_id="Deployment" >}} 相同的是,StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment 不同的是,StatefulSet 为它们的每个 Pod 维护了一个固定的 ID。这些 Pod 是基于相同的声明来创建的,但是不能相互替换:无论怎么调度,每个 Pod 都有一个永久不变的 ID。 + + + +StatefulSet 和其他控制器使用相同的工作模式。你在 StatefulSet *对象* 中定义你期望的状态,然后 StatefulSet 的 *控制器* 就会通过各种更新来达到那种你想要的状态。 + diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh/docs/reference/glossary/storage-class.md new file mode 100644 index 0000000000..52886478eb --- /dev/null +++ b/content/zh/docs/reference/glossary/storage-class.md @@ -0,0 +1,40 @@ + + +--- +title: 存储类别 +id: storageclass +date: 2018-04-12 +full_link: /docs/concepts/storage/storage-classes +short_description: > + StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 + +aka: +tags: +- core-object +- storage +--- + + StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 + + + + +StorageClass 可以映射到服务质量等级(QoS)、备份策略、或者管理员随机定义的策略。每个 StorageClass 对象包含的域有 `provisioner`、 `parameters` 和 `reclaimPolicy`,属于该存储类别的 {{< glossary_tooltip text="永久卷" term_id="persistent-volume" >}} 需要动态分配时就要用到这些域参数。通过 StorageClass 对象的名称,用户可以请求他们需要的特定存储类别。 + diff --git a/content/zh/docs/reference/glossary/uid.md b/content/zh/docs/reference/glossary/uid.md new file mode 100755 index 0000000000..4da74f8fad --- /dev/null +++ b/content/zh/docs/reference/glossary/uid.md @@ -0,0 +1,42 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + 由 Kubernetes 系统生成、用来唯一标识对象的字符串。 + +aka: +tags: +- fundamental +--- + + + + + +由 Kubernetes 系统生成、用来唯一标识对象的字符串。 + + + + + +在 Kubernetes 集群的整个生命周期中,每个被创建的对象都有不同的 UID。UID 用来区分相似实体的历史事件。 + diff --git a/content/zh/docs/reference/glossary/upstream.md b/content/zh/docs/reference/glossary/upstream.md new file mode 100644 index 0000000000..7f2c7ded3e --- /dev/null +++ b/content/zh/docs/reference/glossary/upstream.md @@ -0,0 +1,27 @@ +--- +title: Upstream (disambiguation) +id: upstream +date: 2018-04-12 +full_link: +short_description: > + May refer to: core Kubernetes or the source repo from which a repo was forked. + +aka: +tags: +- community +--- + + + + +可以参考:核心 Kubernetes 仓库或作为当前仓库派生来源的来源仓库。 + + + +* 在 **Kubernetes社区**:对话中通常使用 *upstream* 来表示核心 Kubernetes 代码库,也就是更广泛的 kubernetes 生态系统、其他代码或第三方工具所依赖的仓库。 例如,[社区成员](#term-member)可能会建议将某个功能特性贡献到 upstream,使其位于核心代码库中,而不是维护于插件或第三方工具中。 +* 在 **GitHub** 或 **git** 中:约定是将源仓库称为 *upstream*,而派生的仓库则被视为 *downstream*。 diff --git a/content/zh/docs/reference/glossary/volume-plugin.md b/content/zh/docs/reference/glossary/volume-plugin.md new file mode 100755 index 0000000000..ca4318d4ad --- /dev/null +++ b/content/zh/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,44 @@ +--- +title: 卷(Volume)插件 +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + 卷(Volume)插件可以让 Pod 集成存储。 + +aka: +tags: +- core-object +- storage +--- + + + + + +卷插件可以让 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集成存储。 + + + + + +卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分,并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。 + diff --git a/content/zh/docs/reference/glossary/volume.md b/content/zh/docs/reference/glossary/volume.md new file mode 100755 index 0000000000..279626861d --- /dev/null +++ b/content/zh/docs/reference/glossary/volume.md @@ -0,0 +1,43 @@ +--- +title: 卷 +id: volume +date: 2018-04-12 +full_link: /docs/concepts/storage/volumes/ +short_description: > + 包含可被 Pod 中容器访问的数据的目录。 + +aka: +tags: +- core-object +- fundamental +--- + + + + + +包含可被 {{< glossary_tooltip text="pod" term_id="pod" >}} 中容器访问的数据的目录。 + + + + +每个 Kubernetes 卷在所处的{{< glossary_tooltip text="pod" term_id="pod" >}} 存在期间保持存在状态。 +因此,卷的生命期会超出 {{< glossary_tooltip text="pod" term_id="pod" >}} 中运行的{{< glossary_tooltip text="容器" term_id="container" >}}, +并且保证{{< glossary_tooltip text="容器" term_id="container" >}}重启之后仍保留数据。 + diff --git a/content/zh/docs/reference/glossary/wg.md b/content/zh/docs/reference/glossary/wg.md new file mode 100644 index 0000000000..9a42e77ab0 --- /dev/null +++ b/content/zh/docs/reference/glossary/wg.md @@ -0,0 +1,45 @@ +--- +title: WG (工作组) +id: wg +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list +short_description: > + 工作组是为了方便讨论和(或)推进执行一些短周期、窄范围、或者从委员会和 SIG 分离出来的项目、以及跨 SIG 的活动。 + +aka: +tags: +- community +--- + + + + + +工作组是为了方便讨论和(或)推进执行一些短周期、窄范围、或者从委员会和 SIG 分离出来的项目、以及跨 SIG 的活动。 + + + + + +工作组可以将人们组织起来,一起完成一项分散的任务。它组建简单,完成任务即可解散。 + +更多信息请参考 [kubernetes/community](https://github.com/kubernetes/community) 代码库和当前的 [SIGs 和工作组](https://github.com/kubernetes/community/blob/master/sig-list.md) 列表。 diff --git a/content/zh/docs/reference/issues-security/_index.md b/content/zh/docs/reference/issues-security/_index.md new file mode 100644 index 0000000000..222e543541 --- /dev/null +++ b/content/zh/docs/reference/issues-security/_index.md @@ -0,0 +1,13 @@ +--- +title: Kubernetes 问题和安全 +weight: 10 +toc-hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh/docs/reference/issues-security/issues.md new file mode 100644 index 0000000000..7976be7684 --- /dev/null +++ b/content/zh/docs/reference/issues-security/issues.md @@ -0,0 +1,16 @@ +--- +title: Kubernetes 问题追踪 +weight: 10 +--- + + + + +Kubernetes 代码的问题追踪基于 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 进行。 diff --git a/content/zh/docs/reference/issues-security/security.md b/content/zh/docs/reference/issues-security/security.md new file mode 100644 index 0000000000..a0fe43786a --- /dev/null +++ b/content/zh/docs/reference/issues-security/security.md @@ -0,0 +1,129 @@ +--- +title: Kubernetes 安全和信息披露 +aliases: [/security/] +content_template: templates/concept +weight: 20 +--- + + + +{{% capture overview %}} + +本页面介绍 Kubernetes 安全和信息披露相关的内容。 +{{% /capture %}} + +{{% capture body %}} + +## 安全公告 + + +加入 [kubernets-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 组,以获取关于安全性和主要 API 公告的电子邮件。 + + +## 报告一个漏洞 + + +我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。 +所有的报告都由社区志愿者进行彻底调查。 + + +如需报告,请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)详细信息电邮到[security@kubernetes.io](mailto:security@kubernetes.io) 列表。 + + +您可以使用[产品安全团队成员](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst)的 GPG 密钥加密您的电子邮件到此列表。 +使用 GPG 加密不需要公开。 + + +### 我应该在什么时候报告漏洞? + + +- 您认为在 Kubernetes 中发现了一个潜在的安全漏洞 +- 您不确定漏洞如何影响 Kubernetes +- 您认为您在 Kubernetes 依赖的另一个项目中发现了一个漏洞(例如 docker、rkt、etcd) + + +### 我什么时候不应该报告漏洞? + + +- 您需要帮助调整 Kubernetes 组件的安全性 +- 您需要帮助应用与安全相关的更新 +- 您的问题与安全无关 + + +## 安全漏洞响应 + + +每个报告在 3 个工作日内由产品安全团队成员确认和分析。这将启动[安全发布过程](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures)。 + + +与产品安全团队共享的任何漏洞信息都保留在 Kubernetes 项目中,除非有必要修复该问题,否则不会传播到其他项目。 + + +随着安全问题从分类、识别修复、发布计划等方面的进展,我们将不断更新报告。 + + +## 公开披露时间 + + +公开披露日期由 Kubernetes 产品安全团队和 bug 提交者协商。我们倾向于在用户缓解措施可用时尽快完全披露该 bug。 + + +当 bug 或其修复还没有被完全理解,解决方案没有经过良好的测试,或者为了处理供应商协调问题时,延迟披露是合理的。 + + +信息披露的时间范围从即时(尤其是已经公开的)到几周。作为一个基本的约定,我们希望报告日期到披露日期的间隔是 7 天。在设置披露日期时,Kubernetes 产品安全团队拥有最终决定权。 +{{% /capture %}} diff --git a/content/zh/docs/reference/kubectl/_index.md b/content/zh/docs/reference/kubectl/_index.md new file mode 100644 index 0000000000..fb61e32478 --- /dev/null +++ b/content/zh/docs/reference/kubectl/_index.md @@ -0,0 +1,11 @@ +--- +title: "kubectl 命令行界面" +weight: 60 +--- + + diff --git a/content/zh/docs/reference/kubectl/conventions.md b/content/zh/docs/reference/kubectl/conventions.md new file mode 100644 index 0000000000..fdc050a1ea --- /dev/null +++ b/content/zh/docs/reference/kubectl/conventions.md @@ -0,0 +1,175 @@ +--- +title: kubectl 的用法约定 +reviewers: +- bgrant0607 +- janetkuo +content_template: templates/concept +--- + + + +{{% capture overview %}} + +`kubectl` 的推荐用法约定 +{{% /capture %}} + +{{% capture body %}} + + +## 在可重用脚本中使用 `kubectl` + + +对于脚本中的稳定输出: + + + +* 请求一个面向机器的输出格式,例如 `-o name`、`-o json`、`-o yaml`、`-o go template` 或 `-o jsonpath`。 +* 完全限定版本。例如 `jobs.v1.batch/myjob`。这将确保 kubectl 不会使用其默认版本,该版本会随着时间的推移而更改。 +* 在使用基于生成器的命令(例如 `kubectl run` 或者 `kubectl expose`)时,指定 `--generator` 参数以固定到特定行为。 +* 不要依赖上下文、首选项或其他隐式状态。 + + +## 最佳实践 + +### `kubectl run` + + +若希望 `kubectl run` 满足"基础设施即代码(infrastructure as code)"的要求: + + + +* 使用特定版本的标签标记镜像,不要将该标签移动到新版本。例如,使用 `:v1234`、`v1.2.3`、`r03062016-1-4`,而不是 `:latest`(有关详细信息,请参阅[配置的最佳实践](/docs/concepts/configuration/overview/#container-images))。 +* 使用基于版本控制的脚本来记录所使用的参数,或者至少使用 `--record` 参数以便为所创建的对象添加注解,在使用轻度参数化的镜像时,记录下所使用的命令行。 +* 使用基于版本控制的脚本来运行包含大量参数的镜像。 +* 对于无法通过 `kubectl run` 参数来表示的功能特性,使用基于源码控制的配置文件,以记录要使用的功能特性。 +* 固定到特定的[生成器](#生成器)版本,例如 `kubectl run --generator=deployment/v1beta1`。 + + +#### 生成器 + + +您可以使用带有 `--generator` 参数的 `kubectl run` 命令创建如下资源: + + + +| 资源 | kubectl 命令 | +|---------------------------------|---------------------------------------------------| +| Pod | `kubectl run --generator=run-pod/v1` | +| Replication controller | `kubectl run --generator=run/v1` | +| Deployment | `kubectl run --generator=extensions/v1beta1` | +| -同时获得端点(默认) | `kubectl run --generator=deployment/v1beta1` | +| Deployment | `kubectl run --generator=apps/v1beta1` | +| -端点(推荐) | `kubectl run --generator=deployment/apps.v1beta1` | +| Job | `kubectl run --generator=job/v1` | +| CronJob | `kubectl run --generator=batch/v1beta1` | +| -端点(默认) | `kubectl run --generator=cronjob/v1beta1` | +| CronJob | `kubectl run --generator=batch/v2alpha1` | +| -端点(废弃) | `kubectl run --generator=cronjob/v2alpha1` | + + + + +如果不指定 generator 参数,其他参数将提示您使用特定的生成器。下表列出了强制您使用特定生成器的参数,具体取决于集群的版本: + + + +| 生成的资源 | 集群版本 v1.4 及以后版本 | 集群版本 v1.3 | 集群版本 v1.2 | 集群版本 v1.1 及更早 | +|:----------------------:|------------------------|-----------------------|--------------------------------------------|--------------------------------------------| +| Pod | `--restart=Never` | `--restart=Never` | `--generator=run-pod/v1` | `--restart=OnFailure` 或 `--restart=Never` | +| Replication Controller | `--generator=run/v1` | `--generator=run/v1` | `--generator=run/v1` | `--restart=Always` | +| Deployment | `--restart=Always` | `--restart=Always` | `--restart=Always` | N/A | +| Job | `--restart=OnFailure` | `--restart=OnFailure` | `--restart=OnFailure` 或 `--restart=Never` | N/A | +| Cron Job | `--schedule=` | N/A | N/A | N/A | + +{{< note >}} + +只有在未指定任何参数时,这些参数才使用默认生成器。 +这意味着,当您将 `--generator` 与其他参数组合时,随后指定的生成器不会更改。 +例如,在集群版本 v1.4 中,如果最初指定了 `--restart=always`,则会创建 Deployment;如果后来指定了 `--restart=always` 和 `--generator=run/v1`,则会创建 Replication Controller。 +这使您能够将生成器固定到特定的行为,即使在以后更改默认生成器时也是如此。 +{{< /note >}} + + +这些参数按以下顺序设置生成器:首先是 `--schedule` 参数,然后是 `--restart` 策略参数,最后是 `--generator` 参数。 + + +要检查最终所创建的资源,请使用 `--dry run` 参数;该参数可以提供将要提交到集群的对象。 + +### `kubectl apply` + + + +* 您可以使用 `kubectl apply` 命令创建或更新资源。但是,要更新资源,您应该使用 `kubectl apply` 或者 `kubectl create --save-config` 创建该资源。有关使用 kubectl apply 更新资源的详细信息,请参阅 [管理资源](/docs/concepts/cluster-administration/manage-deployment/#kubectl-apply)。 + +{{% /capture %}} diff --git a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md new file mode 100644 index 0000000000..8410cb3b2e --- /dev/null +++ b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -0,0 +1,429 @@ +--- +title: Docker 用户的 kubectl 指南 +content_template: templates/concept +reviewers: +- bgrant0607 +- brendandburns +- thockin +--- + + + +{{% capture overview %}} + +您可以使用 Kubernetes 命令行工具 kubectl 与 API 服务器交互。如果您熟悉 Docker 命令行工具,那么使用 kubectl 非常简单。 +但是,Docker 命令和 kubectl 命令之间存在一些差异。以下部分介绍了 Docker 子命令,并描述了等效的 kubectl 命令。 +{{% /capture %}} + +{{% capture body %}} +## docker run + + +要运行 nginx Deployment 并公开该 Deployment,请参考 [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run)。 + +docker: + +```shell +$ docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx +55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db + +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app +``` + + + +kubectl: + +```shell +# 启动 Pod 运行 nginx +$ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" +deployment "nginx-app" created +``` + +{{< note >}} + +`kubectl` 命令打印创建或变更的资源类型和名称,以便可以在后续的命令中使用。可以在创建 Deployment 后公开一个新 Service。 +{{< /note >}} + + + +```shell +# 通过 Service 暴露端口 +$ kubectl expose deployment nginx-app --port=80 --name=nginx-http +service "nginx-http" exposed +``` + + +通过使用 kubectl,您可以创建一个[Deployment](/docs/concepts/workloads/controllers/deployment/) 来确保 N 个 Pod 运行 nginx,其中 N 是声明中规定的副本数,默认值为 1。 +您还可以使用与 Pod 标签匹配的选择器创建 [服务](/docs/concepts/services-networking/service/)。 +有关详细信息,请参阅[使用服务访问群集中的应用](/docs/tasks/access-application-cluster/service-access-application-cluster)。 + + + +默认情况下,镜像在后台运行,类似于 `docker run -d ...`。要在前台运行,请使用: + +```shell +kubectl run [-i] [--tty] --attach --image= +``` + + +不像 `docker run ...`,如果您指定了 `--attach` 参数,那您实际上就为其关联了 `stdin`、`stdout` 和 `stderr`。 +无法控制关联哪个流(`docker -a ...`)。 + + + +因为 kubectl run 命令会为容器启动 Deployment,所以如果使用 Ctrl+C 终止关联的进程,则 Deployment 将重新启动,这与 `docker run -it` 不同。 + +要销毁 Deployment 及其 Pod,需要运行 `kubectl delete deployment `。 + +## docker ps + + + +要列出当前正在运行的内容,请参考 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)。 + +docker: + +```shell +$ docker ps -a +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi +55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app +``` + +kubectl: + +```shell +$ kubectl get po +NAME READY STATUS RESTARTS AGE +nginx-app-8df569cb7-4gd89 1/1 Running 0 3m +ubuntu 0/1 Completed 0 20s +``` + +## docker attach + + + +要和已在容器中运行的进程建立联系,请参见 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)。 + +docker: + +```shell +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app + +$ docker attach 55c103fa1296 +... +``` + +kubectl: + +```shell +$ kubectl get pods +NAME READY STATUS RESTARTS AGE +nginx-app-5jyvm 1/1 Running 0 10m + +$ kubectl attach -it nginx-app-5jyvm +... +``` + + + +要退出容器,可以键入转义序列 Ctrl+P,然后键入 Ctrl+Q。 + +## docker exec + + + +要在容器中执行命令,请参见 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)。 + +docker: + +```shell +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app + +$ docker exec 55c103fa1296 cat /etc/hostname +55c103fa1296 +``` + +kubectl: + +```shell +$ kubectl get po +NAME READY STATUS RESTARTS AGE +nginx-app-5jyvm 1/1 Running 0 10m + +$ kubectl exec nginx-app-5jyvm -- cat /etc/hostname +nginx-app-5jyvm +``` + + + +使用交互命令。 + +docker: + +```shell +$ docker exec -ti 55c103fa1296 /bin/sh +# exit +``` + +kubectl: + +```shell +$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh +# exit +``` + + + +更多信息,请参见[获取正在运行的容器的 shell](/docs/tasks/debug-application-cluster/get-shell-running-container/)。 + +## docker logs + + + +要跟踪正在运行的进程的 stdout/stderr,请参见 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)。 + +docker: + +```shell +$ docker logs -f a9e +192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-" +192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-" +``` + +kubectl: + +```shell +$ kubectl logs -f nginx-app-zibvs +10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" +10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" +``` + + + +Pod 和容器之间有细微的区别;默认情况下,如果进程退出,Pod 不会终止。相反,Pod 会重新启动进程。 +这与 docker run 的选项 `--restart=always` 类似,不过有一点不同。 +在 Docker 中,每次进程调用的输出都是串联的,但是对于 Kubernetes,每次调用是独立的。 +要查看 Kubernetes 上一次运行的输出,请执行以下操作: + +```shell +$ kubectl logs --previous nginx-app-zibvs +10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" +10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" +``` + + + +更多信息请参考[日志架构](/docs/concepts/cluster-administration/logging/)。 + + +## docker stop 和 docker rm + + +要停止并删除一个运行中的进程,请参考 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)。 + +docker: + +```shell +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app + +$ docker stop a9ec34d98787 +a9ec34d98787 + +$ docker rm a9ec34d98787 +a9ec34d98787 +``` + +kubectl: + + + +```shell +$ kubectl get deployment nginx-app +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-app 1 1 1 1 2m + +$ kubectl get po -l run=nginx-app +NAME READY STATUS RESTARTS AGE +nginx-app-2883164633-aklf7 1/1 Running 0 2m + +$ kubectl delete deployment nginx-app +deployment "nginx-app" deleted + +$ kubectl get po -l run=nginx-app +# 什么都没返回 +``` + +{{< note >}} + +使用 kubectl 时,不会直接删除 Pod,必须先删除拥有该 Pod 的 Deployment。如果直接删除 Pod,Deployment 将重新创建 Pod。 +{{< /note >}} + +## docker login + + + +在 kubectl 中没有与 docker login 直接对应的操作。如果您有兴趣在 Kubernetes 中使用私有仓库,请参考 [使用私有仓库](/docs/concepts/containers/images/#using-a-private-registry)。 + +## docker version + + + +要获取客户端和服务器的版本,请参考 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)。 + +docker: + +```shell +$ docker version +Client version: 1.7.0 +Client API version: 1.19 +Go version (client): go1.4.2 +Git commit (client): 0baf609 +OS/Arch (client): linux/amd64 +Server version: 1.7.0 +Server API version: 1.19 +Go version (server): go1.4.2 +Git commit (server): 0baf609 +OS/Arch (server): linux/amd64 +``` + +kubectl: + +```shell +$ kubectl version +Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} +Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} +``` + +## docker info + + + +要获取有关环境和配置的其他信息,请参阅 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)。 + +docker: + +```shell +$ docker info +Containers: 40 +Images: 168 +Storage Driver: aufs + Root Dir: /usr/local/google/docker/aufs + Backing Filesystem: extfs + Dirs: 248 + Dirperm1 Supported: false +Execution Driver: native-0.2 +Logging Driver: json-file +Kernel Version: 3.13.0-53-generic +Operating System: Ubuntu 14.04.2 LTS +CPUs: 12 +Total Memory: 31.32 GiB +Name: k8s-is-fun.mtv.corp.google.com +ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO +WARNING: No swap limit support +``` + +kubectl: + +```shell +$ kubectl cluster-info +Kubernetes master is running at https://108.59.85.141 +KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy +kubernetes-dashboard is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy +Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy +``` +{{% /capture %}} diff --git a/content/zh/docs/reference/kubectl/jsonpath.md b/content/zh/docs/reference/kubectl/jsonpath.md new file mode 100644 index 0000000000..25590b1202 --- /dev/null +++ b/content/zh/docs/reference/kubectl/jsonpath.md @@ -0,0 +1,114 @@ +--- +title: JSONPath 支持 +--- + + + + + +JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。 +除了原始的 JSONPath 语法之外,我们还添加了三个函数: + + + +1. `$` 运算符是可选的,因为表达式默认情况下始终从根对象开始。 +2. 可以使用 `""` 来引用 JSONPath 表达式中的文本。 +3. 可以使用 `range` 运算符来遍历列表。 +4. 可以使用负切片索引来反向遍历列表。负索引并不会遍历完列表。它们只需要满足 `-index + listLength >= 0` 便可执行。 + + + +结果对象使用 String() 函数打印。 + + +给定输入: + +```json +{ + "kind": "List", + "items":[ + { + "kind":"None", + "metadata":{"name":"127.0.0.1"}, + "status":{ + "capacity":{"cpu":"4"}, + "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}] + } + }, + { + "kind":"None", + "metadata":{"name":"127.0.0.2"}, + "status":{ + "capacity":{"cpu":"8"}, + "addresses":[ + {"type": "LegacyHostIP", "address":"127.0.0.2"}, + {"type": "another", "address":"127.0.0.3"} + ] + } + } + ], + "users":[ + { + "name": "myself", + "user": {} + }, + { + "name": "e2e", + "user": {"username": "admin", "password": "secret"} + } + ] +} +``` + + + +函数 | 描述 | 示例 | 结果 +---------|--------------------|--------------------|------------------ +text | 纯文本 | kind is {.kind} | kind 是 List +@ | 当前对象 | {@} | 与输入相同 +. or [] | 子运算符 | {.kind} or {['kind']}| List +.. | 递归下降 | {..name} | 127.0.0.1 127.0.0.2 myself e2e +\* | 通配符,获取所有对象| {.items[*].metadata.name} | [127.0.0.1 127.0.0.2] +[start:end :step] | 下标运算符 | {.users[0].name}| myself +[,] | 并集运算符 | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] +?() | 过滤器 | {.users[?(@.name=="e2e")].user.password} | secret +range, end | 遍历列表 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] +'' | 引用解释字符串 | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2 + + +下面是使用 jsonpath 的一些例子: + +```shell +$ kubectl get pods -o json +$ kubectl get pods -o=jsonpath='{@}' +$ kubectl get pods -o=jsonpath='{.items[0]}' +$ kubectl get pods -o=jsonpath='{.items[0].metadata.name}' +$ kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}' +``` + + + +在 Windows 上,你必须要 _双_ 引号(而不是上面 bash 例子中的单引号)来引用包含空格符的任何 JSONPath 模板。 +这也意味着,如果你要用字面值,必须要使用单引号或者转义双引号。例如: + +```cmd +C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" +C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" +``` diff --git a/content/zh/docs/reference/kubectl/kubectl-cmds.md b/content/zh/docs/reference/kubectl/kubectl-cmds.md new file mode 100644 index 0000000000..b10d9ee45c --- /dev/null +++ b/content/zh/docs/reference/kubectl/kubectl-cmds.md @@ -0,0 +1,10 @@ +--- +title: kubectl 命令 +--- + + + + +[kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/) diff --git a/content/zh/docs/reference/kubectl/kubectl.md b/content/zh/docs/reference/kubectl/kubectl.md index 0b03dd140a..06d98eed3a 100644 --- a/content/zh/docs/reference/kubectl/kubectl.md +++ b/content/zh/docs/reference/kubectl/kubectl.md @@ -7,25 +7,25 @@ notitle: true -kubectl 可以操控 Kubernetes 集群。 +kubectl 用来控制 Kubernetes 集群管理器 -### 简介 +### 摘要 -kubectl 可以操控 Kubernetes 集群。 +kubectl 用来控制 Kubernetes 集群管理器。 -获取更多信息,请访问:https://kubernetes.io/docs/reference/kubectl/overview/ +更多信息参见 /docs/reference/kubectl/overview/ ``` kubectl [flags] ``` - ######2018年6月16日,通过spf13/cobra自动生成 + +* [kubectl alpha](kubectl_alpha.md) - kubectl alpha 功能 + +* [kubectl annotate](kubectl_annotate.md) - 更新资源所关联的注解 + +* [kubectl api-resources](kubectl_api-resources.md) - 打印服务器上所支持的 API 资源 + +* [kubectl api-versions](kubectl_api-versions.md) - 以“组/版本”的格式输出服务端支持的 API 版本 + +* [kubectl apply](kubectl_apply.md) - 基于文件名或标准输入,将新的配置应用到资源上 + +* [kubectl attach](kubectl_attach.md) - 连接到一个正在运行的容器 + +* [kubectl auth](kubectl_auth.md) - 检视授权信息 + +* [kubectl autoscale](kubectl_autoscale.md) - 对一个资源对象( Deployment、ReplicaSet 或 ReplicationController )进行扩缩 + +* [kubectl certificate](kubectl_certificate.md) - 修改证书资源 + +* [kubectl cluster-info](kubectl_cluster-info.md) - 显示集群信息 + +* [kubectl completion](kubectl_completion.md) - 根据已经给出的 Shell(bash 或 zsh),输出 Shell 补全后的代码 + +* [kubectl config](kubectl_config.md) - 修改 kubeconfig 配置文件 + +* [kubectl convert](kubectl_convert.md) - 在不同的 API 版本之间转换配置文件 + +* [kubectl cordon](kubectl_cordon.md) - 标记节点为不可调度的 + +* [kubectl cp](kubectl_cp.md) - 将文件和路径拷入/拷出容器。 + +* [kubectl create](kubectl_create.md) - 通过文件或标准输入来创建资源 + +* [kubectl delete](kubectl_delete.md) - 通过文件名、标准输入、资源和名字删除资源,或者通过资源和标签选择器来删除资源 + +* [kubectl describe](kubectl_describe.md) - 显示某个资源或某组资源的详细信息 + +* [kubectl drain](kubectl_drain.md) - 腾空节点,准备维护 + +* [kubectl edit](kubectl_edit.md) - 修改服务器上的某资源 + +* [kubectl exec](kubectl_exec.md) - 在容器中执行命令 + +* [kubectl explain](kubectl_explain.md) - 显示资源说明 + +* [kubectl expose](kubectl_expose.md) - 给定副本控制器、服务、Deployment 或 Pod,将其暴露为新的 kubernetes Service + +* [kubectl get](kubectl_get.md) - 显示一个或者多个资源信息 + +* [kubectl label](kubectl_label.md) - 更新资源的标签 + +* [kubectl logs](kubectl_logs.md) - 输出 pod 中某容器的日志 + +* [kubectl options](kubectl_options.md) - 打印所有命令都支持的共有参数列表 + +* [kubectl patch](kubectl_patch.md) - 基于策略性合并修补(Stategic Merge Patch)规则更新某资源中的字段 + +* [kubectl plugin](kubectl_plugin.md) - 运行命令行插件 + +* [kubectl port-forward](kubectl_port-forward.md) - 将一个或者多个本地端口转发到 pod + +* [kubectl proxy](kubectl_proxy.md) - 运行一个 kubernetes API 服务器代理 + +* [kubectl replace](kubectl_replace.md) - 基于文件名或标准输入替换资源 + +* [kubectl rollout](kubectl_rollout.md) - 管理资源的上线 + +* [kubectl run](kubectl_run.md) - 在集群中使用指定镜像启动容器 + +* [kubectl scale](kubectl_scale.md) - 为一个 Deployment、ReplicaSet、ReplicationController 或 Job 设置一个新的规模尺寸值 + +* [kubectl set](kubectl_set.md) - 在资源对象设置特定的功能 + +* [kubectl taint](kubectl_taint.md) - 在一个或者多个节点上更新污点配置 + +* [kubectl top](kubectl_top.md) - 显示资源(CPU /内存/存储)使用率 + +* [kubectl uncordon](kubectl_uncordon.md) - 标记节点为可调度的 + +* [kubectl version](kubectl_version.md) - 打印客户端和服务器的版本信息 + +* [kubectl wait](kubectl_wait.md) - 实验性:等待一个或多个资源达到某种状态 diff --git a/content/zh/docs/reference/kubernetes-api/_index.md b/content/zh/docs/reference/kubernetes-api/_index.md new file mode 100644 index 0000000000..19f9f15ffa --- /dev/null +++ b/content/zh/docs/reference/kubernetes-api/_index.md @@ -0,0 +1,11 @@ +--- +title: API 参考 +weight: 30 +--- + + diff --git a/content/zh/docs/reference/kubernetes-api/index.md b/content/zh/docs/reference/kubernetes-api/index.md new file mode 100644 index 0000000000..bb5a42fee9 --- /dev/null +++ b/content/zh/docs/reference/kubernetes-api/index.md @@ -0,0 +1,5 @@ +--- +title: v1.12 +--- + +[Kubernetes API v1.12](/docs/reference/generated/kubernetes-api/v1.12/) diff --git a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md new file mode 100644 index 0000000000..3c0857c3e3 --- /dev/null +++ b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md @@ -0,0 +1,204 @@ +--- +title: 知名标签、注解和污点 +content_template: templates/concept +weight: 10 +--- + + +{{% capture overview %}} + +Kubernetes 保留 kubernetes.io 命名空间中的所有标签和注解。 + + +本文档既可以作为值的参考,也可以作为分配值的协调点。 + +{{% /capture %}} + +{{% capture body %}} + +## beta.kubernetes.io/arch + + +例子:`beta.kubernetes.io/arch=amd64` + + +用于:节点 + + +Kubelet 用 Go 定义的 `runtime.GOARCH` 填充它。例如,如果您混合使用 arm 和 x86 节点,这可能会很方便。 + +## beta.kubernetes.io/os + + +例如:`beta.kubernetes.io/os=linux` + + +用于:节点 + + +Kubelet 用 Go 定义的 `runtime.GOOS` 填充它。如果您在您的集群中(尽管目前 Linux 是 Kubernetes 支持的唯一操作系统)混合使用操作系统,这可能会很方便。 + +## kubernetes.io/hostname + + +例如:`kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` + + +用于:节点 + + +Kubelet 使用主机名填充它。请注意,可以通过将 `--hostname-override` 参数传递给 kubelet,以便使其根据“实际”主机名对主机名进行变更。 + + +## beta.kubernetes.io/instance-type + + +例子:`beta.kubernetes.io/instance-type=m3.medium` + + +用于:节点 + + +Kubelet 使用 `cloudprovider` 定义的实例类型填充它。如果不使用 cloudprovider,则不会对它进行设置。 +如果您想将某些工作负载定位到某个实例类型,这可能很方便。 +但通常您希望依靠 Kubernetes 调度程序来执行基于资源的调度,您应该根据属性而不是实例类型来安排计划(例如,需要一个 GPU,而不是 `g2.2xlarge`) + +## failure-domain.beta.kubernetes.io/region + + +见 [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone)。 + +## failure-domain.beta.kubernetes.io/zone {#failure-domainbetakubernetesiozone} + + +例如: + +`failure-domain.beta.kubernetes.io/region=us-east-1` + +`failure-domain.beta.kubernetes.io/zone=us-east-1c` + + +用于:节点,持久卷 + + +在节点上:Kubelet 使用 `cloudprovider` 定义的区域信息填充它。如果不使用 `cloudprovider`,则不会设置它。 +但如果在拓扑中有意义,则应考虑在节点上设置它。 + + +在持久卷上:基于 GCE 和 AWS 环境,`PersistentVolumeLabel` 准入控制器会自动将区域标签添加到持久卷。 + + +Kubernetes 将自动把 pod 分布在跨越单个区域中的集群节点的副本控制器或服务中(以减少故障的影响)。 + +对于多区域集群,可以跨区域实现这种扩展行为(以减少区域故障的影响)。 + +这是通过 SelectorSpreadPriority 实现的。 + + +这是一个最佳的布局。但是,如果集群中的区域是异构的(例如,不同数量的节点、不同类型的节点或不同的 pod 资源需求),这些都可能会阻止您的 pod 在不同的区域中做到均匀分布。 + + +如果需要,可以使用同质区域(相同数量和类型的节点)来减少不均匀分布的概率。 + + +调度器(通过 VolumeZonePredicate)还将确保声明给定卷的 pod 只放置在与该卷相同的区域中,因为卷不能跨区域挂载。 + + +区域和区域的实际值无关紧要,层次结构的含义也没有严格定义。期望不同区域节点的故障应该是不相关的,除非整个区域都发生故障。 + +例如, + +区域通常应该避免共享一个网络交换机。确切的映射取决于特定的基础设施,三机架安装将选择与多数据中心配置非常不同的设置。 + + +如果 `PersistentVolumeLabel` 不支持自动标记您的持久卷,您又希望调度程序能防止 pod 在不同的区域挂载卷,则您应该考虑手动添加标签(或添加对 `PersistentVolumeLabel` 的支持)。 + +如果您的基础设施没有此约束,则根本不需要将区域标签添加到卷中。 +{{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/_index.md b/content/zh/docs/reference/setup-tools/_index.md new file mode 100644 index 0000000000..d2beef6a19 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/_index.md @@ -0,0 +1,13 @@ +--- +title: 配置工具参考 +weight: 50 +toc-hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/setup-tools/kubeadm/_index.md b/content/zh/docs/reference/setup-tools/kubeadm/_index.md new file mode 100755 index 0000000000..ca9ef3e69b --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/_index.md @@ -0,0 +1,13 @@ +--- +title: "Kubeadm" +weight: 10 +toc-hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/_index.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/_index.md new file mode 100644 index 0000000000..7244e274b8 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/_index.md @@ -0,0 +1,13 @@ +--- +title: "Kubeadm 生成" +weight: 10 +toc_hide: true +--- + + \ No newline at end of file diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md new file mode 100644 index 0000000000..c92bfb20f0 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md @@ -0,0 +1,115 @@ + + +kubeadm:轻松创建一个安全的 Kubernetes 集群 + + +### 摘要 + + + + +kubeadm:轻松创建一个安全的 Kubernetes 集群 + + + ┌──────────────────────────────────────────────────────────┐ + │ KUBEADM 正处在 BETA 阶段 │ + │ │ + │ 欢迎您踊跃试用,并通过以下网址提交反馈: │ + │ https://github.com/kubernetes/kubeadm/issues │ + │ 同时标注 @kubernetes/sig-cluster-lifecycle-bugs │ + │ 和 @kubernetes/sig-cluster-lifecycle-feature-requests │ + └──────────────────────────────────────────────────────────┘ + + + +用途示例: + + 创建一个有两台机器的集群,包含一个主节点(用来控制集群),和一个节点(运行您的工作负载,像 Pod 和 Deployment)。 + + + ┌──────────────────────────────────────────────────────────┐ + │ 在第一台机器上: │ + ├──────────────────────────────────────────────────────────┤ + │ master# kubeadm init │ + └──────────────────────────────────────────────────────────┘ + + ┌──────────────────────────────────────────────────────────┐ + │ 在第二台机器上: │ + ├──────────────────────────────────────────────────────────┤ + │ node# kubeadm join │ + └──────────────────────────────────────────────────────────┘ + + +您可以重复第二步,向集群添加更多机器。 + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
kubeadm 操作的帮助信息
--rootfs string
[试验阶段] 指向 '真实' 宿主机的根目录。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md new file mode 100644 index 0000000000..fe3cd34642 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md @@ -0,0 +1,106 @@ + +功能尚不完整的实验性子命令 + + + + + +### 概要 + + + + +功能尚不完整的实验性子命令。 + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
alpha 操作的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase.md new file mode 100644 index 0000000000..aea59b39f1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase.md @@ -0,0 +1,74 @@ + +分别调用 kubeadm function 的子集进行手动安装。 + + + + +### 概要 + + +此命令不能单独运行。请参阅可用子命令列表。 + + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
phase 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon.md new file mode 100644 index 0000000000..b9b4a1aa04 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon.md @@ -0,0 +1,93 @@ + +安装所需插件(addons)以通过合规性测试 + + +### 摘要 + +此命令不能单独运行。 请参阅可用的子命令列表。 + + +### 可选项 + + + + + + + + + + + + + + + + +
-h, --help
addon 帮助。
+ + + + + +### 从父命令继承的可选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_all.md new file mode 100644 index 0000000000..5f942af54c --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_all.md @@ -0,0 +1,216 @@ + + +将所有插件安装到 Kubernetes 集群 + + + +### 概要 + + +通过 API 服务器安装 CoreDNS 和 ku-proxy 组件。请注意,虽然已经部署了 DNS 服务器,但在安装 CNI 之前 DNS 服务器不能被调度运行。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase addon all [flags] +``` + + + +### 例子 + + + +``` + # 通过 API 服务器安装 CoreDNS 和 kube-proxy 插件, + # 在功能上与 kubeadm init 安装的相同。 + + kubeadm alpha phase selfhosting from-staticpods +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可用来访问 API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
可用来访问 API 服务器的端口
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
--feature-gates string
一组"key=value"偶对,用来描述多种功能特性的特性开关;可选项有:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
all 的帮助信息
--image-repository string     默认值: "k8s.gcr.io"
选择容器仓库拉取控制平面镜像
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubernetes-version string     默认值: "stable-1"
为控制平面选择特定的 Kubernetes 版本
--pod-network-cidr string
用于 Pod 网络的 IP 地址范围
--service-cidr string     默认值: "10.96.0.0/12"
服务 VIP 的 IP 范围
--service-dns-domain string     默认值: "cluster.local"
服务的可选域
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_coredns.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_coredns.md new file mode 100644 index 0000000000..b3cefe3299 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_coredns.md @@ -0,0 +1,208 @@ + +将 CoreDNS addon 安装到 Kubernetes 集群 + +### Synopsis + + +通过 API 服务器安装 CoreDNS addon 组件。 请注意尽管部署了 DNS 服务器,但是在 CNI 被安装之前,它不会被调度。 + +Alpha 免责声明:此命令目前是 alpha 阶段。 + +``` +kubeadm alpha phase addon coredns [flags] +``` + + + +### 可选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。 警告: 配置文件的使用是实验性的。
--feature-gates string
一组键=描述各个功能开关的键值对。 可选项有:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
获取 coredns 帮助信息。
--image-repository string     默认值: "k8s.gcr.io"
选择一个用于拉取控制平面镜像的容器镜像源。
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubernetes-version string     默认值: "stable-1"
为控制平面选择特定的 Kubernetes 版本。
--service-cidr string     默认值: "10.96.0.0/12"
服务 VIP 的 IP 范围。
--service-dns-domain string     Default: "cluster.local"
服务替代域。
+ + + +### 从父命令继承的可选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_kube-proxy.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_kube-proxy.md new file mode 100644 index 0000000000..16ec4db690 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_addon_kube-proxy.md @@ -0,0 +1,165 @@ + +将 kube-proxy 组件安装到 Kubernetes 集群 + + + + +### 概要 + + +通过 API 服务器安装 kube-proxy 组件。 + + + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase addon kube-proxy [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可用来访问 API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
可用来访问 API 服务器的端口号
--config string
kubeadm 配置文件的路径,警告:配置文件的使用是实验性的
-h, --help
kube-proxy 的帮助信息
--image-repository string     默认值:"k8s.gcr.io"
选择容器仓库拉取控制平面镜像
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubernetes-version string     默认值: "stable-1"
为控制平面选择特定的 Kubernetes 版本
--pod-network-cidr string
用于 Pod 网络的 IP 地址范围
+ + + + +### 从命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token.md new file mode 100644 index 0000000000..af57e5f0fd --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token.md @@ -0,0 +1,105 @@ + + + +管理特定于 kubeadm 的启动引导令牌(bootstrap token)功能 + +### 概要 + + + + +此命令不用于自己运行。请参阅可用的子命令列表。 + + +### 可选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
bootstrap-token 的帮助
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
与集群对话时用到的 KubeConfig 文件。如果未设置此标志,则搜索一组标准位置以查找现有KubeConfig文件。
+ + + + +### 继承于父命令的选择项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验性] 主机根目录文件系统“真实”路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_all.md new file mode 100644 index 0000000000..5dbc2b1213 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_all.md @@ -0,0 +1,237 @@ + + + +生成所有 bootstrap token 配置并生成一个初始 token + + + +### 概要 + + + +Bootstrap tokens 用来建立加入集群的节点和 master 节点间的双向互信。 + +此命令生成所有生成 bootstrap tokens 的所需配置并生成一个初始 token。 + +Alpha 免责声明:此命令处于 alpha 阶段。 + +``` +kubeadm alpha phase bootstrap-token all +``` + + +### 例子 + +``` + # 生成所有 bootstrap token 配置并生成一个初始 token + # 功能上等价于 kubeadm init 生成的。 + kubeadm alpha phase bootstrap-token all +``` + + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm config 文件路径(警告:配置文件的使用是实验性的)
--description string
人性化描述如何使用 token
--groups stringSlice     Default: [system:bootstrappers:kubeadm:default-node-token]
使用这个 token 进行身份认证的额外组。必须符合 "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z"
-h, --help
帮助
--skip-token-print
跳过打印 bootstrap token
--token string
token 用来建立节点和 master 间的双向互信。格式为 [a-z0-9]{6}\.[a-z0-9]{16} - 例如 abcdef.0123456789abcdef
--token-ttl duration     Default: 24h0m0s
token 在被自动删除前的持续时间(如 1s, 2m, 3h)。如果设为'0',token 将永不失效
--usages stringSlice     Default: [signing,authentication]
描述 token 可以使用的方式。您可以多次传递 --usages 或用逗号分隔开多个选择项。有效的选择项: [signing,authentication]
+ + + +### 继承于父命令的选项 + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
与集群对话时用到的 KubeConfig 文件。如果未设置此标志,则搜索一组标准位置以查找现有 KubeConfig 文件。
--rootfs string
[实验性] “真正的” 主机根目录文件系统路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_cluster-info.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_cluster-info.md new file mode 100644 index 0000000000..797823132b --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_cluster-info.md @@ -0,0 +1,100 @@ + +从指定的 kubeconfig 文件上传集群信息 ConfigMap + + + + +### 概要 + + +在 "kube-public" 命名空间中上传 "cluster-info" ConfigMap,使用指定的 kubeconfig 文件中提取的集群信息填充它。在客户端信任 API 服务器之前,ConfigMap 用于节点引导过程的初始阶段,即客户端能够信任 API 服务器之前。 + + +更多详细信息,请参阅有关使用 Bootstrap 令牌进行身份验证的联机文档 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase bootstrap-token cluster-info [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
cluster-info 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + +### 概要 + + + + +创建一个引导令牌。如果没有给出令牌值,kubeadm 将生成一个随机令牌。 + +或者,您可以使用 kubeadm 令牌。 + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase bootstrap-token create [flags] +``` + + + +### 选项 + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的
--description string
针对令牌用途的人性化的描述。
--groups stringSlice     默认值: [system:bootstrappers:kubeadm:default-node-token]
使用这个令牌进行身份认证的额外组。必须符合 "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z"
-h, --help
create 操作的帮助信息
--skip-token-print
跳过打印引导令牌操作
--token string
令牌用来建立节点与主控节点键的双向信任。格式为 [a-z0-9]{6}\.[a-z0-9]{16} - 例如 abcdef.0123456789abcdef
--token-ttl duration     默认值: 24h0m0s
令牌在被自动删除前的持续时间(如 1s, 2m, 3h)。如果设为'0',token 将永不失效
--usages stringSlice     默认值: [signing,authentication]
描述令牌可以使用的方式。您可以多次传递 --usages 或用逗号分隔开多个选择项。有效的选择项: [signing,authentication]
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md new file mode 100644 index 0000000000..e6f98f4cc7 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node.md @@ -0,0 +1,117 @@ + +配置节点引导过程 + + + + +### 概要 + + + +此命令不能单独运行。请参阅可用子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
node 操作的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md new file mode 100644 index 0000000000..6ab1f62a0f --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-auto-approve.md @@ -0,0 +1,99 @@ + +配置 RBAC 规则允许 csrapprover 控制器自动批准来自节点引导令牌的 CSR + + + + +### 概要 + + +配置 RBAC 规则,允许 csrapprover 控制器自动批准加入集群的节点生成的证书签名请求。它还配置用于证书轮换的 RBAC 规则(自动批准新证书)。 + + +有关更多详细信息,请参阅有关 TLS 引导的联机文档。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase bootstrap-token node allow-auto-approve [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
allow-auto-approve 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md new file mode 100644 index 0000000000..bc97cbdd55 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_bootstrap-token_node_allow-post-csrs.md @@ -0,0 +1,99 @@ + +配置 RBAC 允许节点引导令牌发送 CSR 请求,以便节点获得长期证书凭据 + + + + +### 概要 + + +配置 RBAC 规则,允许节点引导令牌发送证书签名请求,从而允许正在加入到集群中的节点请求长期证书凭据。 + + +有关更多详细信息,请参阅有关 TLS 引导的联机文档。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase bootstrap-token node allow-post-csrs [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
allow-post-csrs 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs.md new file mode 100644 index 0000000000..f5034edc2d --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs.md @@ -0,0 +1,75 @@ + + +为 Kubernetes 集群生成证书 + + + +### 概要 + + +此命令不能单独运行。请参阅可用的子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
certs 操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_all.md new file mode 100644 index 0000000000..8956b252c1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_all.md @@ -0,0 +1,208 @@ + +生成所有建立控制平面所需的 PKI 数据 + +### 概要 + + +生成自签名 CA,为集群中的每个组件(包括节点)提供标识,并为各种组件提供所需的客户端证书。 + +如果某指定的证书和私钥对都已经存在,kubeadm 跳过生成步骤而使用现有的文件。 + +Alpha 免责声明:此命令处于 Alpha 阶段。 + +``` +kubeadm alpha phase certs all [flags] +``` + + +### 例子 + +``` + # 生成所有建立控制平面所需的 PKI 数据, + # 功能等同于 kubeadm init 所生成的。 + kubeadm alpha phase certs all + + # 使用配置文件的选项创建所有 PKI 数据。 + kubeadm alpha phase certs all --config masterconfiguration.yaml +``` + + +### 选择项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可访问的 API 服务器 IP 地址,用于 API 服务器的服务证书
--apiserver-cert-extra-sans stringSlice
应用于 API 服务器服务证书的可选的额外的别名。可以使用 IP 地址和 dns 名
--cert-dir string     默认值: "/etc/kubernetes/pki"
认证存储路径
--config string
kubeadm 配置文件路径(警告: 配置文件的使用处于实验阶段)
-h, --help
帮助
--service-cidr string     默认值: "10.96.0.0/12"
可替换的服务 VIP 的 IP 地址范围,其中的内部 API 服务器的 VIP 将加到 API 服务器的服务证书
--service-dns-domain string     默认值: "cluster.local"
可替换的服务域,用于 API 服务器的服务证书
+ + + + +### 继承于父命令的选择项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验性] 主机根目录文件系统“真实”路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-etcd-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-etcd-client.md new file mode 100644 index 0000000000..6557f3a100 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-etcd-client.md @@ -0,0 +1,111 @@ + +生成 apiserver 客户端用于访问etcd + + + + +### 概要 + + +生成 apiserver 客户端用于访问 etcd,并将其保存到 apiserver-etcd-client.cert 和 apiserver-etcd-client.key 中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase certs apiserver-etcd-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书保存的路径
--config string
kubeadm 配置文件的路径。(警告:配置文件的使用是实验性的)
-h, --help
apiserver-etcd-client 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机 root 文件系统的路径。
+ + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-kubelet-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-kubelet-client.md new file mode 100644 index 0000000000..582b162856 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver-kubelet-client.md @@ -0,0 +1,110 @@ + +生成 API 服务器连接 kubelet 所使用的客户端证书 + + + + +### 概要 + + +生成 API 服务器连接 kubelet 所使用的客户端证书,并将其保存到 apiserver-kubelet-client.cert 和 apiserver-kubelet-client.key 文件中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤而直接使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase certs apiserver-kubelet-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
apiserver-kubelet-client 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] '真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md new file mode 100644 index 0000000000..56c69d23d1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_apiserver.md @@ -0,0 +1,203 @@ + + +生成用于 Kubernetes API 的证书 + + +### 概要 + + +生成用于 Kubernetes API 的证书,并把证书保存到 apiserver.cert 和 apiserver.key 文件中。 + + +默认的 SAN 是 kubernetes、kubernetes.default、kubernetes.default.svc、kubernetes.default.svc.cluster.local、10.96.0.1、127.0.0.1。 + + +如果这两个文件已经存在,kubeadm 将跳过生成步骤直接使用现有文件。 + + +Alpha 免责声明:此命令目前处于 alpha 阶段。 + +``` +kubeadm alpha phase certs apiserver [flags] +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
API 服务器可访问的 IP 地址,用于提供证书的 API 服务器
--apiserver-cert-extra-sans stringSlice
为证书提供服务的 API 服务器使用的可选的额外 altname, 可以是 IP 地址和 DNS 名称。
--cert-dir string     默认:"/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm config 文件路径(警告: 配置文件的使用是实验性的)
-h, --help
apiserver 的帮助信息
--service-cidr string     默认值:"10.96.0.0/12"
服务 VIP 的可选 IP 地址范围,从中会产生将添加到提供证书的 API 服务器的内部 API 服务器的 VIP
--service-dns-domain string     默认值:"cluster.local"
服务的备用域,用于提供证书的 API 服务器
+--> + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_ca.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_ca.md new file mode 100644 index 0000000000..60f661e8ec --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_ca.md @@ -0,0 +1,100 @@ + + +生成自签名 kubernetes 证书供其他 kuberenets 组件创建标识用 + + + +### 概要 + + +生成自签名 kubernetes 证书供其他 kuberenets 组件创建标识用,并将它们保存到 ca.cert 和 ca.key 中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并将使用现有文件。 + + +免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase certs ca [flags] +``` + + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
ca 的操作帮助信息
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-ca.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-ca.md new file mode 100644 index 0000000000..b7c5dbd6c5 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-ca.md @@ -0,0 +1,109 @@ + + +生成自签名证书以便为 etcd 提供标识 + + + +### 概要 + + +生成自签名证书以为 etcd 提供标识,并将它们保存到 etcd/ca.cert 和 etcd/ca.key 中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并将使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase certs etcd-ca [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
etcd-ca 操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-healthcheck-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-healthcheck-client.md new file mode 100644 index 0000000000..5c409d7dc6 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-healthcheck-client.md @@ -0,0 +1,109 @@ + +为活跃性探针生成客户端证书以便对 etcd 执行健康检查 + + + + +### 概要 + + +为活跃性探针生成客户端证书以便对 etcd 执行健康检查,并将它们保存到 etcd/healthcheck-client.cert 和 etcd/healthcheck-client.key 文件中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤并将使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase certs etcd-healthcheck-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
etcd-healthcheck-client 的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-peer.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-peer.md new file mode 100644 index 0000000000..892e860c31 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-peer.md @@ -0,0 +1,114 @@ + +为 etcd 节点生成相互通信的证书 + + + + +### 概要 + + +为 etcd 节点生成证书以便相互通信。并将这些证书保存到 etcd/peer.cert 和 etcd/peer.key 文件中。 + + +默认 SAN 是 localhost、127.0.0.1 和 ::1 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤并使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase certs etcd-peer [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书的保存路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
etcd-peer 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-server.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-server.md new file mode 100644 index 0000000000..37204a7ed0 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_etcd-server.md @@ -0,0 +1,115 @@ + + +生成服务 etcd 的证书 + + + +### 概要 + + +生成服务 etcd 的证书,并将它们保存到 etcd/server.cert 和 etcd/server.key 中。 + + +默认 SANs 是本机 127.0.0.1, ::1 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并将使用现有文件。 + +Alpha 免责声明:此命令属于 alpha。 + + +``` +kubeadm alpha phase certs etcd-server [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件存储路径(警告: 配置文件使用是实验性的)
-h, --help
etcd-server 的帮助信息
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-ca.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-ca.md new file mode 100644 index 0000000000..c9becd7c34 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-ca.md @@ -0,0 +1,110 @@ + +生成自签名证书为前端代理提供标识 + + + + +### 概要 + + +生成自签名证书为前端代理提供标识,并将其保存到 front-proxy-ca.cert 和 front-proxy-ca.key 中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并将使用现有文件。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase certs front-proxy-ca [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
front-proxy-ca 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-client.md new file mode 100644 index 0000000000..afe675dc84 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_front-proxy-client.md @@ -0,0 +1,110 @@ + +为前端代理生成客户端 + + + + +### 概要 + + +为前端代理生成客户端,并将其保存到 front-proxy-client.cert 和 front-proxy-client.key 文件中。 + + +如果两个文件都已存在,kubeadm 将跳过生成步骤,并将使用现有文件。 + + +Alpha 免责声明:此命令当前处于 alpha 阶段。 + +``` +kubeadm alpha phase certs front-proxy-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用处于试验阶段)
-h, --help
front-proxy-client 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew.md new file mode 100644 index 0000000000..75d910420c --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew.md @@ -0,0 +1,79 @@ + +续期 Kubernetes 集群的证书 + + + + + +### 概要 + + +此命令不能单独运行。请参阅可用子命令列表。 + +``` +kubeadm alpha phase certs renew [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
renew 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md new file mode 100644 index 0000000000..2a6521b4f0 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_all.md @@ -0,0 +1,162 @@ +续期所有可用的证书 + + + + + +### 摘要 + + +续期运行控制平面所需的所有已知证书。续期操作是无条件执行的,与证书到期时间无关。续期也可以单独运行以获得更多的控制。 + + +``` +kubeadm alpha phase certs renew all [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值:"/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告: 配置文件的使用是实验性的)
-h, --help
all 操作的帮助信息
--kubeconfig string     默认值:"/etc/kubernetes/admin.conf"
与集群交互时使用的 KubeConfig 文件。如果没有设置该参数,将会搜索一组标准位置来查找现有的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 续期证书
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验特性] 指向主机根文件系统的'真实'路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-etcd-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-etcd-client.md new file mode 100644 index 0000000000..06898231cd --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-etcd-client.md @@ -0,0 +1,131 @@ + +为 API 服务器生成用来访问 etcd 的客户端证书 + + + + +### 概要 + + +更新客户端 API 服务器用于访问 etcd,并将其保存到 apiserver-etcd-client.cert 和 apiserver-etcd-client.key 中。 + + + +额外的属性如 SANs 将基于现有的证书,不需要重新提供它们。 + +``` +kubeadm alpha phase certs renew apiserver-etcd-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
apiserver-etcd-client 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md new file mode 100644 index 0000000000..9c60bec8b5 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver-kubelet-client.md @@ -0,0 +1,127 @@ + +为 API 服务器生成连接 kubelet 的客户端证书 + + + + +### 概要 + + +续订 API 服务器的客户端证书以连接到 kubelet,并将其保存到 apiserver-kubelet-client.cert 和 apiserver-kubelet-client.key 文件中。 + + +额外的属性(如 SANs) 将基于现有的证书,不需要重新提供它们。 + +``` +kubeadm alpha phase certs renew apiserver-kubelet-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件路径(警告: 配置文件的使用处于实验阶段)
-h, --help
apiserver-kubelet-client 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一组标准路径来查找现有的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver.md new file mode 100644 index 0000000000..5e4277f348 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_apiserver.md @@ -0,0 +1,128 @@ + +生成提供 kubernetes API 服务的证书 + + + + +### 概要 + + +续期用于 kubernetes API 的证书,并将其保存到 apiserver.cert 和 apiserver.key 文件中。 + + +额外的属性(如 SAN) 将基于现有的证书,不需要重新提供它们。 + +``` +kubeadm alpha phase certs renew apiserver [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用处于试验阶段)
-h, --help
apiserver 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md new file mode 100644 index 0000000000..5e7859d054 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-healthcheck-client.md @@ -0,0 +1,128 @@ + +为用于 etcd 健康检查的存活性探针生成客户端证书 + + + + +### 概要 + + +更新用于 etcd 健康检查的存活性探针的客户端证书,并将其保存到 etcd/healthcheck-client.cert 和 etcd/healthcheck-client.key 文件中。 + + +额外的属性(如 SANs)将基于现有的证书完成设置,不需要重新提供。 + +``` +kubeadm alpha phase certs renew etcd-healthcheck-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书的保存路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
etcd-healthcheck-client 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md new file mode 100644 index 0000000000..47adeb1dc6 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-peer.md @@ -0,0 +1,164 @@ +生成 etcd 节点之间相互通信的凭证 + + + + + +### 摘要 + + +更新 etcd 节点的凭证以进行相互通信,并将其保存到 etcd/peer.cert 和 etcd/peer.key 文件中。 + +附加属性(如SAN)将基于现有凭证,不需要重新提供它们。 + +``` +kubeadm alpha phase certs renew etcd-peer [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值:"/etc/kubernetes/pki"
保存凭证的路径
--config string
kubeadm 配置文件的路径(警告: 配置文件的使用是实验性的)
-h, --help
etcd-peer 的帮助信息
--kubeconfig string     默认值:"/etc/kubernetes/admin.conf"
与集群交互时使用的 KubeConfig 文件。如果没有设置该参数,将会搜索一组标准位置来查找现有的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验性]指向主机根文件系统的“真实”路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-server.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-server.md new file mode 100644 index 0000000000..86dcca6703 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_etcd-server.md @@ -0,0 +1,127 @@ + +生成提供 etcd 服务所需的证书 + + + + +### 概要 + + +更新提供 etcd 服务所需的证书并将它们保存到 etcd/server.cert 和 etcd/server.key 文件中。 + + +额外的属性(如 SANs)将基于现有的证书完成设置,不需要重新提供。 + +``` +kubeadm alpha phase certs renew etcd-server [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书的保存路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
etcd-server 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--use-api
使用 Kubernetes 证书 API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_front-proxy-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_front-proxy-client.md new file mode 100644 index 0000000000..f8d6aeafd9 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_renew_front-proxy-client.md @@ -0,0 +1,129 @@ + + +为前端代理生成客户端 + + + +### 概要 + + +更新前端代理的客户端,并将其保存到 front-proxy-client.cert 和 front-proxy-client.key 中。 + + +额外的属性如 SANs 将基于现有的证书,不需要重新提供它们。 + +``` +kubeadm alpha phase certs renew front-proxy-client [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
front-proxy-client 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--use-api
使用 Kubernetes certificate API 更新证书
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_sa.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_sa.md new file mode 100644 index 0000000000..9f0097829d --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_certs_sa.md @@ -0,0 +1,129 @@ + + +生成私钥用于与公钥一起签署服务账户令牌 + +### 概要 + + + + +生成私钥用于与公钥一起签署服务账户令牌,并把它们存储在 sa.key 和 sa.pub 文件中。如果这两个文件都存在,kubeadm会跳过生成步骤并使用现存的文件。 + +Alpha 免责声明:此命令处于 alpha 阶段。 + + +``` +kubeadm alpha phase certs sa [flags] +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书存储路径
--config string
kubeadm config 配置文件路径(警告:配置文件的使用是实验性的)
-h, --help
sa 帮助
+ + + + +### 继承于父命令的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验性] 主机根目录文件系统“真实”路径。.
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane.md new file mode 100644 index 0000000000..9dc3464ac6 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane.md @@ -0,0 +1,97 @@ + + +生成建立控制面所需的所有静态 Pod 清单文件 + +### 简介 + + +此命令不能单独运行。请参阅可用子命令列表。 + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
controlplane 的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + +
--rootfs string
[实验] 宿主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_all.md new file mode 100644 index 0000000000..05b588a133 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_all.md @@ -0,0 +1,225 @@ + +生成用于创建控制平面所需的所有静态 Pod 清单文件 + + + + +### 概要 + + +生成用于创建控制平面所需的所有静态 Pod 清单文件。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase controlplane all [flags] +``` + + + +### 例子 + + + +``` + # 生成控制平面组件所需的所有静态 Pod 清单文件。 + # 在功能上和 kubeadm init 生成的内容是相同的。 + kubeadm alpha phase controlplane all + + # 使用从配置文件读取的选项,生成所有静态 Pod 清单文件 + kubeadm alpha phase controlplane --config masterconfiguration.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可用来访问 API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
可用来访问 API 服务器的端口号
--apiserver-extra-args mapStringString
一组以 <flagname>=<value> 的格式传递给 API 服务器或覆盖默认参数的附加的参数;
--cert-dir string     默认值: "/etc/kubernetes/pki"
存储证书的路径
--config string
kubeadm 配置文件的路径 警告: 配置文件的使用是实验性的
--controller-manager-extra-args mapStringString
一组以 <flagname>=<value> 的格式传递给控制器管理器或覆盖默认参数的附加的参数。
--feature-gates string
键值对集合,用来描述多种功能特性的特性开关;可选项有:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
all 的帮助信息
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本
--pod-network-cidr string
用于 Pod 网络的 IP 地址范围
--scheduler-extra-args mapStringString
一组以 <flagname>=<value> 的格式传递给调度器或覆盖默认参数的附加的参数;
--service-cidr string     默认值: "10.96.0.0/12"
>服务 VIP 的 IP 范围
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_apiserver.md new file mode 100644 index 0000000000..160fcb366d --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_apiserver.md @@ -0,0 +1,176 @@ + +生成 API 服务器的静态 Pod 清单 + + + + +### 概要 + + +为 API 服务器生成静态 Pod 清单文件,并将其保存到 /etc/kubernetes/manifests/kube-apiserver.yaml 文件中。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase controlplane apiserver [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可用来访问 API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
可用来访问 API 服务器的端口号
--apiserver-extra-args mapStringString
一组以 <flagname>=<value> 的格式传递给 API 服务器或覆盖默认参数的附加的参数;
--cert-dir string     默认值: "/etc/kubernetes/pki"
存储证书的路径
--config string
kubeadm 配置文件的路径 警告: 配置文件的使用是实验性的
--feature-gates string
键值对集合,用来描述多种功能特性的特性开关;可选项有:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
apiserver 的帮助信息
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本
--service-cidr string     默认值: "10.96.0.0/12"
用于 Pod 网络的 IP 地址范围
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_controller-manager.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_controller-manager.md new file mode 100644 index 0000000000..b0117df498 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_controller-manager.md @@ -0,0 +1,129 @@ + +生成控制器管理器的静态 Pod 清单 + + +### 概要 + + + +为控制器管理器生成静态 Pod 清单文件,并将其保存为 /etc/kubernetes/manifests/kube-controller-manager.yaml 。 + + +免责声明:此命令目前属于 alpha。 + + +### 命令行选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值:"/etc/kubernetes/pki"
证书的保存路径
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的
--controller-manager-extra-args mapStringString
一组额外参数,传递给控制管理器或以 <flagname>=<value> 的格式覆写默认参数。
-h, --help
控制器管理器帮助
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本
--pod-network-cidr string
Pod 网络的 IP 地址范围
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机 root 文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_scheduler.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_scheduler.md new file mode 100644 index 0000000000..ca13bc0860 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_controlplane_scheduler.md @@ -0,0 +1,129 @@ + +生成调度器的静态 Pod 清单 + + + + +### 概要 + + +为调度器生成静态 Pod 清单文件,并将其保存到 /etc/kubernetes/manifests/kube-scheduler.yaml 文件中。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase controlplane scheduler [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书的存储路径
--config string
kubeadm 配置文件的路径,警告:配置文件的使用是实验性的
-h, --help
scheduler 的帮助信息
--kubernetes-version string     ,默认值: "stable-1"
为控制平面选择特定的 Kubernetes 版本
--scheduler-extra-args mapStringString
一组以 <flagname>=<value> 的格式传递调度器或覆盖默认参数的附加的参数
+ + + + + +#### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd.md new file mode 100644 index 0000000000..55a3d3e2ec --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd.md @@ -0,0 +1,72 @@ + +为 etcd 生成静态 Pod 清单文件。 + + + + +### 概要 + + +此命令不能单独运行。请参阅可用的子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
etcd 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md new file mode 100644 index 0000000000..05426af6c1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_etcd_local.md @@ -0,0 +1,157 @@ + + +为本地单节点 etcd 实例生成静态 Pod 清单文件 + + +### 概要 + + +为本地单节点 etcd 实例生成静态 Pod 清单文件,并保存到 /etc/kubernetes/manifests/etcd.yaml 文件中。 + + +Alpha 免责声明:此命令当前处于 alpha 阶段。 + +``` +kubeadm alpha phase etcd local [flags] +``` + + +### 示例 + + + +``` + # 为 etcd 生成静态 Pod 清单文件,功能上相当于 kubeadm init 生成的内容。 + kubeadm alpha phase etcd local + + # 为 etcd 生成静态 Pod 清单文件。 + kubeadm alpha phase etcd local --config masterconfiguration.yaml +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值:"/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件路径。警告:配置文件的使用处于试验阶段。
-h, --help
local 的帮助信息
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[试验] 到'真实'主机的根文件系统的路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig.md new file mode 100644 index 0000000000..d0f88a8086 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig.md @@ -0,0 +1,96 @@ + + +生成建立控制面所需的所有 kubeconfig 文件和 admin kubeconfig 文件 + +### 简介 + +此命令不能单独运行。请参阅可用子命令列表。 + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
kubeconfig帮助
+ + + + +从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[EXPERIMENTAL] 查看宿主机文件系统根目录
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md new file mode 100644 index 0000000000..08c6eb1740 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_admin.md @@ -0,0 +1,176 @@ + +生成一个 kubeconfig 文件供管理员使用,也供 kubeadm 自身使用。 + + +### 概要 + + +为管理员和 kubeadm 本身生成 kubeconfig 文件,并将其保存到 admin.conf 文件。 + + + +Alpha 免责声明:此命令当前处于 alpha 阶段。 + +``` +kubeadm alpha phase kubeconfig admin [flags] +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
API 服务器可访问的 IP 地址
--apiserver-bind-port int32     默认值:6443
API 服务器可访问的端口
--cert-dir string     默认值:"/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的。
-h, --help
admin 的帮助信息
--kubeconfig-dir string     默认值:"/etc/kubernetes"
kubeconfig 文件保存的路径
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md new file mode 100644 index 0000000000..cd8c24b8d0 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_all.md @@ -0,0 +1,215 @@ + +生成建立控制平面所需的所有 kubeconfig 文件以及 admin kubconfig 文件 + + +### 概要 + + +生成建立控制平面所需的所有 kubeconfig 文件以及 admin kubconfig 文件。 + + +Alpha 免责声明:此命令当前处于 alpha 阶段。 + +``` +kubeadm alpha phase kubeconfig all [flags] +``` + + +### 示例 + + + +``` + # 生成所有 kubeconfig 文件,功能上相当于 kubeadm init 生成的内容。 + kubeadm alpha phase kubeconfig all + + # 使用从配置文件中读取的选项来生成所有 kubeconfig 文件。 + kubeadm alpha phase kubeconfig all --config masterconfiguration.yaml +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
API 服务器可访问的 IP 地址。
--apiserver-bind-port int32     默认值:6443
API 服务器可访问的端口。
--cert-dir string     默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件路径。警告:配置文件的使用处于试验阶段。
-h, --help
all 的帮助信息。
--kubeconfig-dir string     默认值:"/etc/kubernetes"
保存 kubeconfig 文件的路径。
--node-name string
用于 kubelet 客户端证书的节点名称。
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[试验] 到'真实'主机的根文件系统的路径。
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_controller-manager.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_controller-manager.md new file mode 100644 index 0000000000..9859109c41 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_controller-manager.md @@ -0,0 +1,142 @@ + +生成一个 kubeconfig 文件供控制器管理器使用 + + + + +### 概要 + + +生成一个 kubeconfig 文件供控制器管理器使用,并将其保存到 /etc/kubernetes/controller-manager.conf 文件中。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubeconfig controller-manager [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可用来访问 API 服务器的 IP 地址/td> +
--apiserver-bind-port int32     默认值: 6443
可用来访问 API 服务器的端口号
--cert-dir string     默认值: "/etc/kubernetes/pki"
存储证书的路径
--config string
kubeadm 配置文件的路径(警告: 配置文件的使用是实验性的)
-h, --help
controller-manager 的帮助信息
--kubeconfig-dir string     默认值: "/etc/kubernetes"
保存 kubeconfig 文件的路径
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_kubelet.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_kubelet.md new file mode 100644 index 0000000000..0c242c5b39 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_kubelet.md @@ -0,0 +1,155 @@ +生成 kubeconfig 文件供 kubelet 使用。请注意,这应该*只*用于引导目的 + + + + +### 概要 + + +生成要使用的 kubelet 的 kubeconfig 文件,并将其保存到 /etc/kubernetes/kubelet.conf 文件中。 + + +请注意,这只能用于引导。在控制平面启动之后,应该从 CSR API 请求所有 kubelet 证书。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubeconfig kubelet [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可访问的API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
用来访问 API 服务器的端口
--cert-dir string     默认值: "/etc/kubernetes/pki"
存储证书的路径
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的
-h, --help
kubelet 的帮助信息
--kubeconfig-dir string     默认值: "/etc/kubernetes"
保存 kubeconfig 文件的路径
--node-name string
用于 kubelet 客户端证书的节点名
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_scheduler.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_scheduler.md new file mode 100644 index 0000000000..969bd72fe6 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_scheduler.md @@ -0,0 +1,169 @@ + + + +生成 kubeconfig 文件给调度器使用 + +### 概要 + + +生成 kubeconfig 文件给调度器使用且把它保存至/etc/kubernetes/scheduler.conf。 + +Alpha 免责声明:此命令处于 Alpha 阶段。 + + +``` +kubeadm alpha phase kubeconfig scheduler [flags] +``` + +### 选择项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
可访问的 API 服务器 IP 地址
--apiserver-bind-port int32     默认值: 6443
可访问的 API 服务器的端口
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书存储路径
--config string
kubeadm 配置文件存储路径(警告: 配置文件使用是实验性的)
-h, --help
scheduler 帮助
--kubeconfig-dir string     默认值: "/etc/kubernetes"
kubeconfig 文件存储路径
+ + + +### 继承于父命令的选择项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验性] 主机根目录文件系统“真实”路径。
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md new file mode 100644 index 0000000000..c4cee9dceb --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubeconfig_user.md @@ -0,0 +1,228 @@ + +为其他用户输出 kubeconfig 文件 + + + + +### 概要 + + + +为其他用户输出 kubeconfig 文件。 +Alpha 免责声明:此命令目前是 alpha。 + +``` +kubeadm alpha phase kubeconfig user [flags] +``` + + + +### 样例 + + + +``` + # 为名为 foo 的其他用户输出 kubeconfig 文件 + kubeadm alpha phase kubeconfig user --client-name=foo +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
用来访问 API 服务器的 IP 地址
--apiserver-bind-port int32     默认值: 6443
用来访问 API 服务器的端口
--cert-dir string     默认值: "/etc/kubernetes/pki"
证书存储路径
--client-name string
用户名。如果创建了客户端证书,它将用作 CN
-h, --help
user 操作的帮助信息
--kubeconfig-dir string     默认值: "/etc/kubernetes"
kubeconfig 文件存储路径
--org stringSlice
客户端证书的组织。如果创建了客户端证书,它将用作 O。
--token string
需要用来完成 kubeconfig 身份认证操作的令牌,设定此值时 kubeadm 不再使用客户端证书
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet.md new file mode 100644 index 0000000000..f8a10d0be1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet.md @@ -0,0 +1,75 @@ + + +处理 kubelet 相关的命令。 + + + +### 概要 + + +此命令不能单独运行。请参阅可用的子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
kubelet 操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config.md new file mode 100644 index 0000000000..874bff047e --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config.md @@ -0,0 +1,72 @@ + +处理 kubelet 参数 + + + + +### 概要 + + +此命令不能单独运行。请参阅可用的子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
config 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_annotate-cri.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_annotate-cri.md new file mode 100644 index 0000000000..a0c25142bb --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_annotate-cri.md @@ -0,0 +1,114 @@ + +使用指定的 crisocket 对节点进行注释 + + + + +### 概要 + + +使用 kubeadm InitConfiguration 对象中指定的 CRI 套接字向当前节点添加注释。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet config annotate-cri [flags] +``` + + + +### 例子 + +``` + kubeadm alpha phase kubelet config annotate-cri --config kubeadm.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的
-h, --help
annotate-cri 的帮助信息
--kubeconfig string     默认: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_download.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_download.md new file mode 100644 index 0000000000..d11a7a3b5a --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_download.md @@ -0,0 +1,123 @@ + +从集群 ConfigMap kubelet-config-1.X 下载 kubelet 配置,其中 X 是 kubelet 的次要版本。 + + + + +### 概要 + + +从集群中名为 "kubelet-config-1.X" 的 ConfigMap 中下载 kubelet 配置信息,其中 X 是kubelet 的次要版本。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet config download [flags] +``` + + + +### 例子 + + + +``` + # 从集群中的 ConfigMap 下载 kubelet 配置。自动检测 kubelet 版本。 + kubeadm alpha phase kubelet config download + + # 从集群中的 ConfigMap 下载 kubelet 配置。使用特定的 kubelet 版本。 + kubeadm alpha phase kubelet config download --kubelet-version v1.12.0 +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
download 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/kubelet.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubelet-version string
kubelet 的理想版本,默认通过 'kubelet --version' 自动检测。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_enable-dynamic.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_enable-dynamic.md new file mode 100644 index 0000000000..f322fffd76 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_enable-dynamic.md @@ -0,0 +1,142 @@ + +实验:启用或更新节点的动态 kubelet 配置 + + + + +### 概要 + + +针对集群中的 kubelet-config-1.X ConfigMap 启用或更新节点的动态 kubelet 配置,其中 X 是 kubelet 的次要版本。 + + +警告:此功能仍处于试验阶段,默认情况下禁用。只有当您知道自己在做什么时才启用它,在这个阶段它可能有意想不到的效果。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet config enable-dynamic [flags] +``` + + + +### 例子 + + + +``` + # 为节点启用动态 kubelet 配置。 + kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version v1.12.0 + + 警告:此功能仍处于试验阶段,默认情况下禁用。只有当你清楚你在做什么时,才启用它。 + may have surprising side-effects at this stage. +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
enable-dynamic 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
与集群交互时使用的 KubeConfig 文件。如果未设置,将搜索一组标准路径来查找现有的 KubeConfig 文件。
--kubelet-version string
kubelet 的期望版本
--node-name string
启用动态 kubelet 配置的节点的名称
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md new file mode 100644 index 0000000000..41ef412826 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_upload.md @@ -0,0 +1,157 @@ + +基于 kubeadm InitConfiguration 文件将 kubelet 配置上载到 ConfigMap。 + + + +### 概要 + + + +将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上载到集群中 kubelet-config-1.X 形式的 ConfigMap,其中 X 是当前(API 服务器)Kubernetes 版本的次要版本。 + + + +Alpha 免责声明:此命令当前处于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet config upload [flags] +``` + + + +### 示例 + + + +``` + # 将 kubelet 配置从 kubeadm 配置文件上载到集群中的 ConfigMap。 + kubeadm alpha phase kubelet config upload --config kubeadm.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告:配置文件的使用处于试验阶段)
-h, --help
upload 的帮助信息
--kubeconfig string     默认值:"/etc/kubernetes/admin.conf"
与集群交互时使用的 KubeConfig 文件。如果未设置,将搜索一组标准路径来查找现有的 KubeConfig 文件。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_write-to-disk.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_write-to-disk.md new file mode 100644 index 0000000000..7ae2e276fd --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_config_write-to-disk.md @@ -0,0 +1,106 @@ + +基于 --config 参数将 kubelet 配置写到磁盘。 + + + + +### 概要 + + +基于 "--config" 传递的 kubeadm 配置,将 kubelet 配置写入磁盘。。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet config write-to-disk [flags] +``` + + + +### 例子 + + + +``` + # 从 kubeadm 配置文件中提取 kubelet 配置 + kubeadm alpha phase kubelet config write-to-disk --config kubeadm.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
write-to-disk 的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_write-env-file.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_write-env-file.md new file mode 100644 index 0000000000..ad696ad58e --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_kubelet_write-env-file.md @@ -0,0 +1,111 @@ + +为 kubelet 写入带有运行时参数的环境文件。 + + + + +### 概要 + + +生成一个环境文件,其中包含需要传递给在主节点或节点上执行的 kubelet 的参数。--config 参数的取值可以是一个 InitConfiguration 对象或一个 JoinConfiguration 对象,因为这个功能既用于 "kubeadm init" 也用于 "kubeadm join"。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase kubelet write-env-file [flags] +``` + + + +### 例子 + + + +``` + # 从 InitConfiguration 文件中写入带有 kubelet 参数的动态环境文件。 + kubeadm alpha phase kubelet write-env-file --config masterconfig.yaml + + # 从 JoinConfiguration 文件中写入带有 kubelet 参数的动态环境文件。 + kubeadm alpha phase kubelet write-env-file --config nodeconfig.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告: 配置文件的使用是实验性的)
-h, --help
write-env-file 的帮助信息
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_mark-master.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_mark-master.md new file mode 100644 index 0000000000..e8bc172247 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_mark-master.md @@ -0,0 +1,133 @@ + + +将节点标记为主节点 + + + +### 概要 + + +为某节点添加标签表明该节点是主节点,并为之添加污点以迫使工作负载在部署时考虑该污点的存在。 + + +Alpha 免责声明:此命令目前属于 alpha。 + +``` +kubeadm alpha phase mark-master [flags] +``` + + + +### 例子 + + + +``` + # 将主节点标签和污点应用到当前节点上,在功能上等同于 kubeadm init 执行的操作。 + kubeadm alpha phase mark-master + + # 将主节点标签和污点应用到当前节点上 + kubeadm alpha phase mark-master --node-name myNode +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
指向 kubeadm 配置文件的路径。警告:配置文件的使用是实验性的。
-h, --help
mark-master 操作的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--node-name string
应该使用标签和污点的节点名
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight.md new file mode 100644 index 0000000000..57b152fac9 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight.md @@ -0,0 +1,94 @@ + + +运行 pre-flight 检查 + + + +### 概要 + + +此命令不能单独运行。请参阅可用子命令列表。 + + + +#### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-h, --help
preflight 的帮助信息
--ignore-preflight-errors stringSlice
将检查的错误显示为警告,例如:'IsPrivilegedUser,Swap'. 值 'all' 忽略所有的检查错误。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_master.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_master.md new file mode 100644 index 0000000000..5d2268a20b --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_master.md @@ -0,0 +1,163 @@ + + +执行主节点运行前检查 + +### 简介 + + +运行前检查,功能上与 kubeadm init 实现的功能相同。 + +Alpha 免责声明:此命令目前是试运行版本。 + +``` +kubeadm alpha phase preflight master [flags] +``` + +### 例子 + +``` + #执行主节点运行前检查 + kubeadm alpha phase preflight master +``` + +### 选项 + + + + + + + + + + + + + + + + + + + +
-h, --help
master 的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
--ignore-preflight-errors stringSlice
一系列检查,其错误将显示为警告。示例:'IsPrivilegedUser,Swap'。值'all'忽略所有检查的错误。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_node.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_node.md new file mode 100644 index 0000000000..63e02ab772 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_preflight_node.md @@ -0,0 +1,117 @@ + +运行节点加入前的检查 + + + + +### 概要 + + +运行节点加入前的检查,功能上与 kubeadm join 的实现相同。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase preflight node [flags] +``` + + + +### 例子 + + + +``` + # 运行节点加入前的检查 + kubeadm alpha phase preflight node +``` + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
node 的帮助信息
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
--ignore-preflight-errors stringSlice
检查项列表,这些检查项的错误将以警告的形式显示。例如:'IsPrivilegedUser,Swap'。 值设置为 'all' 将会忽略来自所有检查项的错误。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting.md new file mode 100644 index 0000000000..774a234d68 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting.md @@ -0,0 +1,73 @@ + +创建一个 kubeadm 自托管集群 + + + + +### 概要 + + +此命令不能单独运行。请参阅可用的子命令列表。 + + + +### 选项 + + + + + + + + + + + + + + + + + +
-h, --help
selfhosting 的帮助信息
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md new file mode 100644 index 0000000000..73442d4dca --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_selfhosting_convert-from-staticpods.md @@ -0,0 +1,155 @@ + +将托管静态 Pod 的控制平面转换为自托管控制平面 + + + + +### 概要 + + +将控制平面组件的静态 Pod 文件转换为通过 Kubernetes API 配置的自托管 DaemonSet。 + + +有关自托管限制,请参阅文档。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase selfhosting convert-from-staticpods [flags] +``` + + + +### 例子 + +``` + # 将静态的 pod 托管的控制平面转换为自托管的控制平面, + # 在功能上等于 kubeadm init 所生成的执行 + # with --feature-gates=SelfHosting=true。 + + kubeadm alpha phase selfhosting convert-from-staticpods +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
存储证书的路径
--config string
kubeadm 配置文件的路径,警告:配置文件的使用是实验性的
--feature-gates string
以键值对形式描述各种特性的特性门,选项有:
Auditing=true|false (ALPHA - default=false)
CoreDNS=true|false (default=true)
DynamicKubeletConfig=true|false (BETA - default=false)
-h, --help
convert-from-staticpods 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
+ + + + +### 从父命令集成的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_upload-config.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_upload-config.md new file mode 100644 index 0000000000..a0be1a1a71 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_phase_upload-config.md @@ -0,0 +1,124 @@ + +将当前使用的 kubeadm 配置上传到 ConfigMap + + + + +### 概要 + + +将集群 kubeadm init 配置上传到 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap 中。这可以正确配置系统组件,并在升级时提供无缝的用户体验。 + + +或者您可以使用 kubeadm config。 + + +Alpha 免责声明:此命令目前属于 alpha 阶段。 + +``` +kubeadm alpha phase upload-config [flags] +``` + + + +### 例子 + + + +``` + # 上传集群的配置 + kubeadm alpha phase upload-config --config=myConfig.yaml +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。警告:配置文件的使用是实验性的。
-h, --help
upload-config 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md new file mode 100644 index 0000000000..6ae7d54293 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md @@ -0,0 +1,192 @@ +为指定的 shell(bash 或 zsh)输出 shell 自动补全代码。 + + + + +### 概要 + + + +为指定的 shell(bash 或 zsh)输出 shell 自动补全代码。 +必须激活 shell 代码以提供交互式 kubeadm 命令补全。这可以通过加载 .bash_profile 文件完成。 + + + +注意: 此功能依赖于 `bash-completion` 框架。 + + + +在 Mac 上使用 homebrew 安装: + + brew install bash-completion + +安装后,必须激活 bash_completion。这可以通过在 .bash_profile 文件中添加下面的命令行来完成 + + source $(brew --prefix)/etc/bash_completion + + + +如果在 Linux 上没有安装 bash-completion,请通过您的发行版的包管理器安装 'bash-completion' 软件包。 + + + +zsh 用户注意事项:[1] zsh 自动补全仅在 v5.2 及以上版本中支持。 + +``` +kubeadm completion SHELL [flags] +``` + + + +### 样例 + + + +``` +# 在 Mac 上使用 homebrew 安装 bash completion +brew install bash-completion +printf "\n# Bash completion support\nsource $(brew --prefix)/etc/bash_completion\n" >> $HOME/.bash_profile +source $HOME/.bash_profile + +# 将 bash 版本的 kubeadm 自动补全代码加载到当前 shell 中 +source <(kubeadm completion bash) + +# 将 bash 自动补全完成代码写入文件并且从 .bash_profile 文件加载它 +printf "\n# Kubeadm shell completion\nsource '$HOME/.kube/kubeadm_completion.bash.inc'\n" >> $HOME/.bash_profile +source $HOME/.bash_profile + +# 将 zsh 版本的 kubeadm 自动补全代码加载到当前 shell 中 +source <(kubeadm completion zsh) +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
completion 操作的帮助信息
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md new file mode 100644 index 0000000000..2b5dcb2363 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md @@ -0,0 +1,115 @@ + +管理集群中 ConfigMap 持久化保存的 kubeadm 集群配置 + +### 概要 + + + + + +kube-system 命名空间里有一个名为 "kubeadm-config" 的 ConfigMap,kubeadm 用它来存储有关集群的内部配置。 +kubeadm CLI v1.8.0+ 通过一个配置自动创建该 ConfigMap,这个配置是和 'kubeadm init' 共用的。但是您如果使用 kubeadm v1.7.x 或更低的版本初始化集群,那么必须使用 'config upload' 命令创建该 ConfigMap。这是必要的操作,目的是使 'kubeadm upgrade' 能够正确地配置升级后的集群。 + +``` +kubeadm config [flags] +``` + +### 可选项 + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
配置帮助。
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
+ +### 从父命令继承的可选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 主机根文件系统的“真实”路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md new file mode 100644 index 0000000000..d0fec7b2f1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md @@ -0,0 +1,90 @@ + + +与 kubeadm 使用的容器镜像交互。 + + + +### 概要 + + +与 kubeadm 使用的容器镜像交互。 + +``` +kubeadm config images [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
镜像的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md new file mode 100644 index 0000000000..f7774a3d89 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md @@ -0,0 +1,116 @@ + +打印 kubeadm 要使用的镜像列表。配置文件用于自定义任何镜像或镜像存储库。 + + +### 概要 + + +打印 kubeadm 要使用的镜像列表。配置文件用于自定义任何镜像或镜像存储库。 + + +``` +kubeadm config images list [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。
--feature-gates string
一组键=值对,用于描述各种特性的特性门。选项有:
Auditing=true|false (ALPHA - default=false)
CoreDNS=true|false (default=true)
DynamicKubeletConfig=true|false (BETA - default=false)
-h, --help
list 操作的帮助信息
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md new file mode 100644 index 0000000000..7a062da0f9 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md @@ -0,0 +1,129 @@ + +拉取 kubeadm 使用的图像。 + + +### 概要 + + + +拉取 kubeadm 使用的图像。 + + +``` +kubeadm config images pull [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
kubeadm 配置文件的路径。
--cri-socket string     默认值:"/var/run/dockershim.sock"
指定要连接的 CRI 套接字。
--feature-gates string
一组键=值对,用于描述各种特性的特性门。选项:
Auditing=true|false (ALPHA - default=false)
CoreDNS=true|false (default=true)
DynamicKubeletConfig=true|false (BETA - default=false)
-h, --help
pull 操作的帮助信息
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md new file mode 100644 index 0000000000..27deab3f64 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md @@ -0,0 +1,129 @@ + +从旧版本的文件中读取 kubeadm 配置 API的类型,并为新版本输出类似的配置对象。 + + + +### 概要 + + + + +此命令允许您在 CLI 工具中将本地旧版本的配置对象转换为最新支持的版本,而无需触及群集中的任何内容。在此版本的 kubeadm 中,支持以下 API 版本: + + +- kubeadm.k8s.io/v1alpha2 +- kubeadm.k8s.io/v1alpha3 + +此外,kubeadm 只能写出版本"kubeadm.k8s.io/v1alpha3"的配置,但能够读取这两种类型,不管你传递给 +--old-config 的参数是什么版本,在写入 stdout 或 --new-config(如果指定时),API 对象都是 +读取、反序列化、应用默认设置、执行版本转换与合法性验证,并在输出时重新序列化。 + + + +换句话说这个命令的输出就是 kubeadm 在内部读取的内容 +提交这个文件到 "kubeadm init" + + +``` +kubeadm config migrate [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
migrate 操作的帮助信息
--new-config string
使用新的 API 版本生成的 kubeadm 配置文件的路径。这个路径是可选的。如果没有指定,输出将被写到 stdout。
--old-config string
使用旧 API 版本的、需要进行转换的 kubeadm 配置文件路径。此参数是必需的。
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print-default.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print-default.md new file mode 100644 index 0000000000..63896e63e8 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print-default.md @@ -0,0 +1,108 @@ + +打印 kubeadm 配置对象的默认值。 + + +### 概要 + + + + +此命令打印用于 'kubeadm init' 和 'kubeadm upgrade' 的默认 InitConfiguration 对象,以及用于 'kubeadm join' 的默认 JoinConfiguration 对象。 + + +注意,如引导令牌字段这类敏感值会被替换为简单的值,如{"abcdef.0123456789abcdef" "" "nil" [] []},目的是在通过合法性验证的同时避免执行创建令牌这类真实计算。没有为创建令牌执行真正的计算。 + + + +``` +kubeadm config print-default [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + +
--api-objects stringSlice
API 对象打印默认值的逗号分隔列表。可用值:[InitConfiguration ClusterConfiguration JoinConfiguration KubeProxyConfiguration KubeletConfiguration MasterConfiguration]。此参数未设置时表示“打印所有已知对象”
-h, --help
print-default 操作的帮助信息
+ + + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload.md new file mode 100644 index 0000000000..46fa685449 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload.md @@ -0,0 +1,91 @@ + + +上传关于当前状态的配置,以便 'kubeadm upgrade' 以后可以知道如何配置升级后的集群。 + + + +### 概要 + + + +上传关于当前状态的配置,以便 'kubeadm upgrade' 以后可以知道如何配置升级后的集群。 + +``` +kubeadm config upload [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
upload 操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-file.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-file.md new file mode 100644 index 0000000000..6fe4f6b23a --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-file.md @@ -0,0 +1,113 @@ + +将配置文件上传到集群内的 ConfigMap 以进行 kubeadm 配置。 + + + +### 概要 + + + + + +使用此命令,您可以使用与 ‘kubeadm init’ 相同的配置文件将配置上传到集群中的 ConfigMap。 +如果您使用的是 v1.7.x 或更低版本的 kubeadm 客户端初始化集群并且使用了 --config 选项,那么在使用 'kubeadm upgrade' 升级到 v1.8 之前,您需要使用相同的配置文件运行此命令。 + + +该配置位于 "kube-system" 名称空间中的名为 "kubeadm-config" 的 ConfigMap 中。 + + + +``` +kubeadm config upload from-file [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
指向 kubeadm 配置文件的路径。警告:配置文件的使用是实验性的。
-h, --help
帮助文件
+ + + + +### 继承于父命令的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-flags.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-flags.md new file mode 100644 index 0000000000..f6626ceb0e --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_upload_from-flags.md @@ -0,0 +1,216 @@ + +首次使用 flags 参数创建群集内配置文件。 + + +### 概要 + + + + +使用此命令,您可以使用与 'kubeadm init' 相同的配置文件将配置上传到集群中的 ConfigMap。 +如果使用 v1.7.x 或更低版本的 kubeadm 客户端初始化集群并且使用 --config 选项,则需要在使用 'kubeadm upgrade' 升级到 v1.8 之前使用相同的配置文件运行此命令。 + + +该配置位于 "kube-system" 名称空间中的名为 "kubeadm-config" 的 ConfigMap 中。 + + + +``` +kubeadm config upload from-file [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
一个 IP 地址,API 服务器将宣告该 IP 地址正在监听。默认指定 '0.0.0.0' 用于网络接口的地址。
--apiserver-bind-port int32     默认值: 6443
用于绑定 API 服务器的端口。
--apiserver-cert-extra-sans stringSlice
用于 API 服务器服务证书的可选额外主题替代名称(SANs)。可以是 IP 地址和 DNS 名称。
--cert-dir string     默认值: "/etc/kubernetes/pki"
保存和存储证书的路径。
--cri-socket string     默认值: "/var/run/dockershim.sock"
指定要连接的 CRI 套接字。
--feature-gates string
一组键=值对,用于描述各种特性的特性门。选项:
-h, --help
from-flags 帮助
--kubernetes-version string     默认值: "stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
--node-name string
指定节点名。
--pod-network-cidr string
指定 pod 网络的 IP 地址范围。如果设置,控制平面将自动为每个节点分配 CIDRs。
--service-cidr string     默认值: "10.96.0.0/12"
使用可替代的 IP 地址范围进行服务。
--service-dns-domain string     默认值: "cluster.local"
为服务使用替代域名,例如: "myorg.internal"。
+ + + + + + + + + +### 继承于父命令的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md new file mode 100644 index 0000000000..6638764eea --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md @@ -0,0 +1,89 @@ + +查看存储在集群中的 kubeadm 配置 + + +### 概要 + + + +使用此命令,可以查看 kubeadm 配置的集群中的 ConfigMap。 + +该配置位于 "kube-system" 名称空间中的名为 "kubeadm-config" 的 ConfigMap 中。 + + + + +``` +kubeadm config view [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + +
-h, --help
view 操作的帮助信息
+ +### 继承于父命令的选项 + + + + + + + + + + + + + + + + + + + + + + + + + +
--kubeconfig string     默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md index 32e94830dd..c099ff5631 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md @@ -1,13 +1,13 @@ -运行这个命令来搭建Kubernetes master节点 +运行此命令来搭建 Kubernetes master 节点 ### 简介 -运行这个命令来搭建Kubernetes主节点。 +运行此命令来搭建 Kubernetes 主节点。 ``` kubeadm init [flags] @@ -28,7 +28,7 @@ kubeadm init [flags] - API Server将要广播的监听地址。如指定为 `0.0.0.0` 将使用缺省的网卡地址。 + API Server 将要广播的监听地址。如指定为 `0.0.0.0` 将使用缺省的网卡地址。 @@ -37,7 +37,7 @@ kubeadm init [flags] - API Server绑定的端口 + API Server 绑定的端口 @@ -62,7 +62,7 @@ kubeadm init [flags] - kubeadm配置文件的路径。警告:配置文件的功能是实验性的。 + kubeadm 配置文件的路径。警告:配置文件的功能是实验性的。 @@ -71,7 +71,7 @@ kubeadm init [flags] - 指明要连接的CRI socket文件 + 指明要连接的 CRI socket 文件 @@ -87,7 +87,7 @@ kubeadm init [flags] - 键值对的集合,用来控制各种功能的开关。可选项有:
Auditing=true|false (当前为ALPHA状态 - 缺省值=false)
CoreDNS=true|false (缺省值=true)
DynamicKubeletConfig=true|false (当前为BETA状态 - 缺省值=false) + 键值对的集合,用来控制各种功能的开关。可选项有:
Auditing=true|false (当前为 ALPHA 状态 - 缺省值=false)
CoreDNS=true|false (缺省值=true)
DynamicKubeletConfig=true|false (当前为 BETA 状态 - 缺省值=false) @@ -95,7 +95,7 @@ kubeadm init [flags] - 获取init命令的帮助信息 + 获取 init 命令的帮助信息 @@ -112,7 +112,7 @@ kubeadm init [flags] - 为control plane选择一个特定的Kubernetes版本。 + 为 control plane 选择一个特定的 Kubernetes 版本。 @@ -128,7 +128,7 @@ kubeadm init [flags] - 指明pod网络可以使用的IP地址段。 如果设置了这个参数,control plane将会为每一个节点自动分配CIDRs。 + 指明 pod 网络可以使用的IP地址段。 如果设置了这个参数,control plane 将会为每一个节点自动分配 CIDRs。 @@ -137,7 +137,7 @@ kubeadm init [flags] - 为service的虚拟IP地址另外指定IP地址段 + 为 service 的虚拟IP地址另外指定IP地址段 @@ -146,7 +146,7 @@ kubeadm init [flags] - 为services另外指定域名, 例如: "myorg.internal". + 为 services 另外指定域名, 例如: "myorg.internal". @@ -198,6 +198,3 @@ kubeadm init [flags] - - - diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md new file mode 100644 index 0000000000..bda3ff9795 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md @@ -0,0 +1,374 @@ +在想要加入现有集群的每台机器上运行。 + + + + + +### 摘要 + + + + +当节点加入 kubeadm 初始化的集群时,我们需要建立双向信任。 +这个过程可以分解为发现(让待加入节点信任 Kubernetes 主节点)和 TLS 引导(让Kubernetes 主节点信任待加入节点)两个部分。 + + + +有两种主要的发现方案。 +第一种方法是使用共享令牌和 API 服务器的 IP 地址。 +第二种是提供一个文件——标准 kubeconfig 文件的一个子集。 +该文件可以是本地文件,也可以通过 HTTPS URL 下载。 +格式是 kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443、kubeadm join--discovery-file path/to/file.conf、或者 kubeadm join --discovery-file`https://url/file.conf`。 +只能使用其中一种。 +如果发现信息是从 URL 加载的,必须使用 HTTPS。 +此外,在这种情况下,主机安装的 CA 包用于验证连接。 + + + +如果使用共享令牌进行发现,还应该传递 --discovery-token-ca-cert-hash 参数来验证 Kubernetes 主节点提供的根证书颁发机构(CA)的公钥。 +此参数的值指定为 ":",其中支持的哈希类型为 "sha256"。哈希是通过 Subject Public Key Info(SPKI)对象的字节计算的(如 RFC7469)。 +这个值可以从 "kubeadm init" 的输出中获得,或者可以使用标准工具进行计算。 +可以多次重复 --discovery-token-ca-cert-hash 参数以允许多个公钥。 + + + +如果无法提前知道 CA 公钥哈希,则可以通过 --discovery-token-unsafe-skip-ca-verification 参数禁用此验证。 +这削弱了kubeadm 安全模型,因为其他节点可能会模仿 Kubernetes 主节点。 + + + +TLS 引导机制也通过共享令牌驱动。 +这用于向 Kubernetes 主节点进行临时的身份验证,以提交本地创建的密钥对的证书签名请求(CSR)。 +默认情况下,kubeadm 将设置 Kubernetes 主节点自动批准这些签名请求。 +这个令牌通过 --tls-bootstrap-token abcdef.1234567890abcdef 参数传入。 + +通常两个部分会使用相同的令牌。 +在这种情况下可以使用 --token 参数,而不是单独指定每个令牌。 + +``` +kubeadm join [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--apiserver-advertise-address string
如果节点应该托管一个新的控制平面实例,那么 API 服务器将通知它正在监听的 IP 地址。
--apiserver-bind-port int32     Default: 6443
如果节点应该托管新的控制平面实例,则 API 服务器要绑定的端口。
--config string
kubeadm 配置文件的路径。
--cri-socket string     Default: "/var/run/dockershim.sock"
指定要连接的 CRI 套接字。
--discovery-file string
用来加载集群信息的文件或 URL。
--discovery-token string
用来验证从 API 服务器获取的集群信息的令牌。
--discovery-token-ca-cert-hash stringSlice
对基于令牌的发现,验证根 CA 公钥是否与此哈希匹配(格式: "<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许没有 --discovery-token-ca-cert-hash 的加入.
--experimental-control-plane
在节点上创建一个新的控制平面实例
--feature-gates string
一组健值对,用来描述不同功能的功能开关。 选项包括:
Auditing=true|false (ALPHA - default=false)
CoreDNS=true|false (default=true)
DynamicKubeletConfig=true|false (BETA - default=false)
-h, --help
join 的帮助信息
--ignore-preflight-errors stringSlice
检查项列表,检查的错误信息将显示为警告。 示例: 'IsPrivilegedUser,Swap'。 值 'all' 会忽略所有检查错误。
--node-name string
指定节点名称
--tls-bootstrap-token string
TLS 引导使用的令牌。
--token string
用作 discovery-token 和 tls-bootstrap-token 的令牌
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[EXPERIMENTAL] 连接 '真正的' 主机根文件系统的路径。
+--> + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md new file mode 100644 index 0000000000..322d040f20 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md @@ -0,0 +1,141 @@ + +此命令可将 'kubeadm init' 或者 'kubeadm join' 对主机的改动恢复到执行前的状态。 + +### 摘要 + +此命令可将 'kubeadm init' 或者 'kubeadm join' 对主机的改动恢复到执行前的状态。 + + + +``` +kubeadm reset [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--cert-dir string     默认值: "/etc/kubernetes/pki"
到存储证书的目录的路径。如果指定了,需要清除此目录。
--cri-socket string     默认值: "/var/run/dockershim.sock"
在清理容器时与 crictl 一起使用的 CRI 套接字的路径。
-f, --force
在不提示确认的情况下重置节点。
-h, --help
reset 操作的帮助信息
--ignore-preflight-errors stringSlice
检查列表,其错误将显示为警告。示例:'IsPrivilegedUser,Swap'。值设为 'all' 将忽略所有检查中的错误。
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[EXPERIMENTAL] 通往'真正的'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md new file mode 100644 index 0000000000..d378bc86dd --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md @@ -0,0 +1,125 @@ + + +管理引导令牌(bootstrap token)。 + + +### 概述 + + +此命令管理引导令牌(bootstrap token)。它是可选的,仅适用于高级用例。 + + +简而言之,引导令牌(bootstrap token)用于在客户端和服务器之间建立双向信任。 +当客户端(例如,即将加入集群的节点)需要时,可以使用引导令牌相信正在与之通信的服务器。 +然后可以使用具有 “签名” 的引导令牌。 + + +引导令牌还可以作为一种允许对 API 服务器进行短期身份验证的方法(令牌用作 API 服务器信任客户端的方式),例如用于执行 TLS 引导程序。 + + +引导令牌准确来说是什么? + - 它是位于 kube-system 命名空间中类型为 “bootstrap.kubernetes.io/token” 的一个 Secret。 + - 引导令牌的格式必须为 “[a-z0-9]{6}.[a-z0-9]{16}”,前一部分是公共令牌 ID,而后者是令牌秘钥,必须在任何情况下都保密! + - 必须将 Secret 的名称命名为 “bootstrap-token-(token-id)”。 + + +您可以在此处阅读有关引导令牌(bootstrap token)的更多信息: + /docs/admin/bootstrap-tokens/ + +``` +kubeadm token [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
是否启用 dry-run 模式
-h, --help
token 帮助
--kubeconfig string     默认: "/etc/kubernetes/admin.conf"
与集群通信时使用的 KubeConfig 文件。如果未设置,则搜索一组标准位置以查找现有 KubeConfig 文件。
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验性的] 指向“真实”主机根文件系统的路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md new file mode 100644 index 0000000000..f7dcf727d5 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md @@ -0,0 +1,228 @@ + +在服务器上创建引导令牌 + + + + + +### 概要 + + + +这个命令将为你创建一个引导令牌。 +您可以设置此令牌的用途,"有效时间" 和可选的人性化的描述。 + +这里的 [token] 是指将要生成的实际令牌。 +该令牌应该是一个通过安全机制生成的随机令牌,形式为 "[a-z0-9]{6}.[a-z0-9]{16}"。 +如果没有给出 [token],kubeadm 将生成一个随机令牌。 + +``` +kubeadm token create [token] +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--config string
指定 kubeadm 配置文件的路径 (警告: 使用配置文件是实验阶段的)
--description string
针对令牌用途的人性化的描述。
--groups stringSlice     默认值: [system:bootstrappers:kubeadm:default-node-token]
此令牌将在用于身份验证时进行身份验证的额外组。必须匹配 "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z"
-h, --help
create 操作的帮助信息
--print-join-command
输出使用令牌加入群集所需的完整的 "kubeadm join" 样式的命令,而不是只输出令牌。
--ttl duration     默认值: 24h0m0s
令牌有效时间,超过该时间令牌被自动删除。(例如: 1s, 2m, 3h)。如果设置为 '0',令牌将永远不过期。
--usages stringSlice     默认值: [signing,authentication]
描述可以使用此令牌的方式。你可以多次使用 `--usages` 或者提供一个以逗号分隔的选项列表。合法选项有: [signing,authentication]
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md new file mode 100644 index 0000000000..247baaad12 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md @@ -0,0 +1,140 @@ +在服务器上删除引导令牌 + + + + + +### 概要 + + + +这个命令将为你删除指定的引导令牌。 + +[token-value] 是要删除的 "[a-z0-9]{6}.[a-z0-9]{16}" 形式的完整令牌或者是 "[a-z0-9]{6}" 形式的的令牌 ID。 + +``` +kubeadm token delete [token-value] +``` + + + +### 可选项 + + + + + + + + + + + + + + + + + + +
-h, --help
delete 操作的帮助信息
+ + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md new file mode 100644 index 0000000000..9d0f03b27a --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md @@ -0,0 +1,155 @@ + +生成并打印一个引导令牌但并不在服务器上创建令牌对象。 + + + + + +### 概要 + + + +此命令将打印一个随机生成的可以被 "init" 和 "join" 命令使用的引导令牌。 + +您不必使用此命令来生成令牌。你可以自己设定,只要格式符合 "[a-z0-9]{6}.[a-z0-9]{16}"。这个命令提供是为了方便生成规定格式的令牌。 + +您也可以使用 "kubeadm init" 并且不指定令牌,该命令会生成一个令牌并打印出来。 + +``` +kubeadm token generate [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + +
-h, --help
generate 操作的帮助信息
+ + + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md new file mode 100644 index 0000000000..02b0b70421 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md @@ -0,0 +1,100 @@ + + +列出服务器上的引导令牌。 + + + +### 概要 + + + +此命令将为您列出所有的引导令牌。 + +``` +kubeadm token list [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
list 操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
是否启用干运行模式
--kubeconfig string     默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md new file mode 100644 index 0000000000..f35d4a1e4c --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md @@ -0,0 +1,99 @@ + + +此命令能将您的集群平滑升级到新版本。 + +### 概要 + + +此命令能将您的集群平滑升级到新版本。 + + +``` +kubeadm upgrade [flags] +``` + + +### 选项 + + + + + + + + + + + + + + + + +
-h, --help
upgrade 帮助
+ + + +### 继承于父命令的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验性] 主机根目录文件系统“真实”路径。
+ + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md new file mode 100644 index 0000000000..21f4be9991 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md @@ -0,0 +1,281 @@ + + +将Kubernetes集群升级到指定版本。 + +### 简介 + + +将Kubernetes集群升级到指定版本。 + +``` +kubeadm upgrade apply [version] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--allow-experimental-upgrades
显示 Kubernetes 的不稳定版本作为升级替代方案,并允许升级到 Kubernetes 的 alpha/beta 或 RC 版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的候选版本作为升级替代方案,并允许升级到 Kubernetes 的 RC 版本。
--config string
kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
--cri-socket string     Default: "/var/run/dockershim.sock"
指定要连接的 CRI 套接字。
--dry-run
不要更改任何状态,只输出要执行的操作。
--etcd-upgrade     Default: true
执行 etcd 的升级。
--feature-gates string
一组键值对,用于描述各种功能的功能门。选项包括:
Auditing=true|false (ALPHA - default=false)
CoreDNS=true|false (default=true)
DynamicKubeletConfig=true|false (BETA - default=false)
-f, --force
强制升级,但可能无法满足某些要求。这也意味着非交互模式。
-h, --help
帮助
--ignore-preflight-errors stringSlice
一系列检查,其错误将显示为警告。示例:'IsPrivilegedUser,Swap'。值'all'忽略所有检查的错误。
--image-pull-timeout duration     Default: 15m0s
等待控制面 pod 下载的最长时间。
--kubeconfig string     Default: "/Users/zarnold/.kube/config"
与集群通信时使用的 KubeConfig 文件。如果未设置标志,则在相关目录下搜索以查找现有KubeConfig文件。
--print-config
指定是否应打印将在升级中使用的配置文件。
-y, --yes
执行升级,不提示确认(非交互模式)。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[EXPERIMENTAL] 宿主机根文件系统的路径。
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md new file mode 100644 index 0000000000..2942bae794 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md @@ -0,0 +1,143 @@ + +显示将对现有静态 pod 清单产生的影响。这也能够通过 `kubeadm upgrade apply --dry-run` 命令查看。 + + + + +### 概要 + + +显示将对现有静态 pod 清单产生的影响。这也能够通过 `kubeadm upgrade apply --dry-run` 命令查看。 + +``` +kubeadm upgrade diff [version] [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--api-server-manifest string     默认值:"/etc/kubernetes/manifests/kube-apiserver.yaml"
API 服务器清单的路径
--config string
到 kubeadm 配置文件的路径(警告:配置文件的使用是实验性的)
-c, --context-lines int     默认值:3
diff 中有多少行上下文
--controller-manager-manifest string     默认值:"/etc/kubernetes/manifests/kube-controller-manager.yaml"
控制器清单的路径
-h, --help
diff 的帮助信息
--scheduler-manifest string     默认值:"/etc/kubernetes/manifests/kube-scheduler.yaml"
调度器清单的路径
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机 root 文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md new file mode 100644 index 0000000000..383e664505 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md @@ -0,0 +1,78 @@ + +升级集群中某个节点的命令,目前只支持升级配置,不支持 kubelet 本身。 + + + +### 概要 + + +升级集群中某个节点的命令,目前只支持升级配置,不支持 kubelet 本身。 + +``` +kubeadm upgrade node [flags] +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + +
-h, --help
节点操作的帮助信息
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_config.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_config.md new file mode 100644 index 0000000000..caa5cb45ca --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_config.md @@ -0,0 +1,122 @@ + + +从集群 ConfigMap kubelet-config-1.X 下载 kubelet 配置。其中 X 是 kubelet 的次要版本。 + + +### 概要 + + +从群集中 "kubelet-config-1.X" 的 ConfigMap 下载 kubelet 配置,其中 X 是kubelet 的次要版本。kubeadm 使用 --kubelet-version 参数来确定所需的 kubelet 版本。 + +``` +kubeadm upgrade node config [flags] +``` + + + + +### 例子 + +``` + # 从集群中的 ConfigMap 下载 kubelet 配置,使用特定的 kubelet 版本。 + kubeadm upgrade node config --kubelet-version v1.12.0 + + # 模拟从集群中的 ConfigMap 下载具有特定版本的 kubelet 配置。节点上的任何本地状态没有改变吗? + kubeadm upgrade node config --kubelet-version v1.12.0 --dry-run +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
不改变任何状态,只输出将要执行的操作
-h, --help
配置操作的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/kubelet.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubelet-version string
升级后的 kubelet 的*期望*版本。
+ + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ +[EXPERIMENTAL] The path to the 'real' host root filesystem. +--> + + + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_experimental-control-plane.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_experimental-control-plane.md new file mode 100644 index 0000000000..3809648c9d --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_experimental-control-plane.md @@ -0,0 +1,121 @@ + +升级部署在此节点上的控制平面实例。【重要】执行此命令之前,需要在控制平面的另一实例上执行 `kubeadm upgrade apply`。 + + + + +### 概要 + + +从集群中 "kubelet-config-1.X" 的 ConfigMap 下载 kubelet 配置,在集群中 X 是 kubelet 的次要版本。kubeadm 使用 --kubelet-version 参数来确定所需的 kubelet 版本。 + +``` +kubeadm upgrade node experimental-control-plane [flags] +``` + + + +### 例子 + + + +``` + # 从集群中的 ConfigMap 下载 kubelet 配置。使用特定的 kubelet 版本。 + kubeadm upgrade node config --kubelet-version v1.12.0 + + # 模拟从集群中的 ConfigMap 下载 kubelet 配置,使用特定的指定版本。不更改节点上的任何本地状态。 + kubeadm upgrade node config --kubelet-version v1.12.0 --dry-run +``` + + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--dry-run
不改变任何状态,只输出将要执行的动作
-h, --help
experimental-control-plane 的帮助信息
--kubeconfig string     默认值: "/etc/kubernetes/kubelet.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md new file mode 100644 index 0000000000..1ec2a180fe --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md @@ -0,0 +1,118 @@ + + +检查当前可供升级的版本有哪些以及验证你当前的集群是否可以升级。传入可选的 [version] 参数可以跳过联网检查。 + + +### 简介 + + + +检查当前可供升级的版本有哪些以及验证你当前的集群是否可以升级。传入可选的 [version] 参数可以跳过联网检查。 + +``` +kubeadm upgrade plan [version] [flags] +``` + + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--allow-experimental-upgrades
显示 Kubernetes 的不稳定版本作为升级的替代方案并且允许升级到 alpha/beta/release candidate 状态的 Kubernetes 版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的 release candidate 版本作为升级的替代方案并且允许升级到 release candidate 状态的 Kubernetes 版本。
--config string
kubeadm 配置文件的路径(警告:配置文件功能是实验性的)
--feature-gates string
键值对的结合,用于控制各种功能的开关。可选项有:
Auditing=true|false (ALPHA状态 - 缺省值=false)
CoreDNS=true|false (缺省值=true)
DynamicKubeletConfig=true|false (BETA状态 - 缺省值=false)
-h, --help
显示 plan 命令的帮助信息
--ignore-preflight-errors stringSlice
检查项的集合,这些检查项如果发生错误则会被显示为警告。 示例: 'IsPrivilegedUser,Swap'。 如果值为 'all' 则将忽略所有的检查错误。
--kubeconfig string     缺省值: "~/.kube/config"
同集群通信时使用的 KubeConfig 文件。 如果没有设置这个参数,将会通过搜索一系列标准的位置来找到一份已存在的 KubeConfig 文件。
--print-config
指明是否打印出用于升级的配置文件。
+ + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + + +
--rootfs string
[实验性的功能] 相对“真实”宿主机根目录的路径。
+ + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md new file mode 100644 index 0000000000..a4b003396c --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md @@ -0,0 +1,87 @@ + +打印 kubeadm 的版本号 + + + + +### 概要 + + +打印 kubeadm 的版本号 + +``` +kubeadm version [flags] +``` + +### 选项 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
-h, --help
版本的帮助信息
-o, --output string
输出格式;可用的选项有 'yaml', 'json' 和 'short'
+ + + + + +### 从父命令继承的选项 + + + + + + + + + + + + + + + + +
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
+ + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md new file mode 100644 index 0000000000..982f1c243b --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -0,0 +1,73 @@ +--- +reviewers: +- mikedanese +- luxas +- jbeda +title: kubeadm config +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + + +从 v1.8.0 开始,kubeadm 将集群的配置上传到名为 kube-system 的 ConfigMap 对象中,对象位于 kube-system 命名空间内。并在以后的升级中读取这个 ConfigMap 配置对象。 +这样可以保证系统组件的正确配置,提供无缝的用户体验。 + + + +您可以执行 kubeadm config view 来查看 ConfigMap。如果使用 kubeadm v1.7.x 或更低版本来初始化群集,必须先使用 kubeadm config upload 创建 ConfigMap,然后才能使用 kubeadm upgrade。 + + + +在 Kubernetes v1.11.0 中,添加了一些新命令。你可以使用 kubeadm config print-default +打印默认配置,可以用 kubeadm config migrate 来将旧的配置文件转换到较新的版本,还可以使用 kubeadm config images list 和 kubeadm config images pull +列出并拉取 kubeadm 所需的镜像。 + +{{% /capture %}} + +{{% capture body %}} +## kubeadm config upload from-file {#cmd-config-from-file} +{{< include "generated/kubeadm_config_upload_from-file.md" >}} + +{{< include "generated/kubeadm_config_upload_from-flags.md" >}} + +## kubeadm config view {#cmd-config-view} +{{< include "generated/kubeadm_config_view.md" >}} + +## kubeadm config print-default {#cmd-config-print-default} +{{< include "generated/kubeadm_config_print-default.md" >}} + +## kubeadm config migrate {#cmd-config-migrate} +{{< include "generated/kubeadm_config_migrate.md" >}} + +## kubeadm config images list {#cmd-config-images-list} +{{< include "generated/kubeadm_config_images_list.md" >}} + +## kubeadm config images pull {#cmd-config-images-pull} +{{< include "generated/kubeadm_config_images_pull.md" >}} + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 将 Kubernetes 集群升级到更新版本 [kubeadm upgrade] +{{% /capture %}} + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md index eb4fcea451..7191ca6688 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -5,7 +5,7 @@ weight: 20 --- {{% capture overview %}} -此命令初始化一个 Kubernetes master 节点 +此命令初始化一个 Kubernetes 主节点 {{% /capture %}} {{% capture body %}} @@ -16,7 +16,7 @@ weight: 20 ### Init 命令的工作流程 {#init-workflow} -`kubeadm init` 命令通过执行下列步骤来启动一个 Kubernetes master 节点。 +`kubeadm init` 命令通过执行下列步骤来启动一个 Kubernetes 主节点。 (`/etc/kubernetes/pki` by default) this step is skipped as described in the [Using custom certificates](#custom-certificates) document. The APIServer certs will have additional SAN entries for any `--apiserver-cert-extra-sans` arguments, lowercased if necessary. --> -2. 生成一个自签名的 CA证书 (或者使用现有的证书,如果提供的话) 来为集群中的每一个组件建立身份标识。如果用户已经通过 `--cert-dir` 配置的证书目录(缺省值为 `/etc/kubernetes/pki`)提供了他们自己的 CA证书 以及/或者 密钥, 那么将会跳过这个步骤,正如文档[使用自定义证书](#custom-certificates)中所描述的那样。 +2. 生成一个自签名的 CA 证书 (或者使用现有的证书,如果提供的话) 来为集群中的每一个组件建立身份标识。如果用户已经通过 `--cert-dir` 配置的证书目录(缺省值为 `/etc/kubernetes/pki`)提供了他们自己的 CA证书 以及/或者 密钥, 那么将会跳过这个步骤,正如文档[使用自定义证书](#custom-certificates)中所描述的那样。 如果指定了 `--apiserver-cert-extra-sans` 参数, APIServer 的证书将会有额外的 SAN 条目,如果必要的话,将会被转为小写。 -1. 将 kubeconfig 文件写入 `/etc/kubernetes/` 目录以便 kubelet、controller-manager 和 scheduler 用来连接到 API server,它们每一个都有自己的身份标识,同时生成一个名为 admin.conf 的独立的 kubeconfig 文件,用于管理操作。 +1. 将 kubeconfig 文件写入 `/etc/kubernetes/` 目录以便 kubelet、控制器管理器和调度器用来连接到 API 服务器,它们每一个都有自己的身份标识,同时生成一个名为 admin.conf 的独立的 kubeconfig 文件,用于管理操作。 -5. 为 API server、controller manager 和 scheduler 生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话,也会为 etcd 生成一份额外的静态 Pod 清单文件。 +1. 为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话,也会为 etcd 生成一份额外的静态 Pod 清单文件。 静态 Pod 的清单文件被写入到 `/etc/kubernetes/manifests` 目录; kubelet 会监视这个目录以便在系统启动的时候创建 Pods。 -一旦 control plane 的 Pods 都运行起来, `kubeadm init` 的工作流程就继续往下执行。 +一旦控制平面的 Pods 都运行起来, `kubeadm init` 的工作流程就继续往下执行。 -2. 对 master 节点应用 labels 和 taints 以便不会在它上面运行其它的工作负载。 +1. 对主节点应用标签和污点标记以便不会在它上面运行其它的工作负载。 -3. 生成令牌以便其它节点以后可以使用这个令牌向 master 节点注册它们自己。 可选的,用户可以通过 `--token` 提供一个令牌, 正如文档[kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。 +3. 生成令牌以便其它节点以后可以使用这个令牌向主节点注册它们自己。 可选的,用户可以通过 `--token` 提供一个令牌, 正如文档 [kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。 In Kubernetes version 1.11 and later CoreDNS is the default DNS server. To install kube-dns instead of CoreDNS, kubeadm must be invoked with `--feature-gates=CoreDNS=false`. Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed. --> -1. 通过 API server 安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 +1. 通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 在 1.11 版本以及更新版本的 Kubernetes 中 CoreDNS 是默认的 DNS 服务器。 如果要安装 kube-dns 而不是 CoreDNS, 你需要在调用 kubeadm 的时候附加 `--feature-gates=CoreDNS=false` 参数。请注意,尽管 DNS 服务器已经被部署了,它并不会被调度直到你安装好了 CNI 网络插件。 -2. 如果调用 `kubeadm init` 命令时启用了 alpha 状态的 self-hosting 功能(`--feature-gates=SelfHosting=true`),基于静态 Pod 的 control plane 将被转换为 [self-hosted control plane](#self-hosting)。 +1. 如果调用 `kubeadm init` 命令时启用了 alpha 状态的自托管功能(`--feature-gates=SelfHosting=true`),基于静态 Pod 的控制平面将被转换为 [自托管的控制平面](#self-hosting)。 ### 结合一份配置文件来使用 kubeadm init {#config-file} @@ -139,7 +139,7 @@ because `v1alpha3` will be removed in Kubernetes 1.14. --> -如果你想获取 `v1beta1` 版本配置中每个字段的细节说明,你可以查看我们的[API reference 页面]。 (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1) +如果你想获取 `v1beta1` 版本配置中每个字段的细节说明,你可以查看我们的 [API reference 页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1) ### 添加 kube-proxy 参数 {#kube-proxy} @@ -155,12 +155,12 @@ kubeadm 配置中有关 kube-proxy 的说明请查看: - [IPVS](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/README.md) -### 向 control plane 组件传递自定义的 flags {#control-plane-flags} +### 向控制平面组件传递自定义的命令行参数 {#control-plane-flags} -有关向 control plane 组件传递 flags 的说明请查看: -- [control-plane-flags](/docs/setup/independent/control-plane-flags/) +有关向控制平面组件传递命令行参数的说明请查看: +- [控制平面命令行参数](/docs/setup/independent/control-plane-flags/) ### 使用自定义的镜像 {#custom-images} @@ -168,7 +168,7 @@ kubeadm 配置中有关 kube-proxy 的说明请查看: -默认情况下, kubeadm 会从 `k8s.gcr.io` 仓库拉取镜像, 除非请求的 Kubernetes 版本是一个持续集成版本。这这种情况下,则会使用 `gcr.io/kubernetes-ci-images` 仓库。 +默认情况下, kubeadm 会从 `k8s.gcr.io` 仓库拉取镜像, 除非请求的 Kubernetes 版本是一个持续集成版本。在这种情况下,则会使用 `gcr.io/kubernetes-ci-images` 仓库。 你可以通过这份文档里描述的方法 [结合一份配置文件来使用 kubeadm](#config-file) 来改变镜像拉取的策略。 @@ -180,7 +180,7 @@ the requested Kubernetes version is a CI version. In this case, * To provide a `unifiedControlPlaneImage` to be used instead of different images for control plane components. * To provide a specific `etcd.image` to be used instead of the image available at`k8s.gcr.io`. --> * 提供一个替代的镜像仓库 `imageRepository` 而不是使用 `k8s.gcr.io`。 -* 提供一个统一的 Control Plane 镜像 `unifiedControlPlaneImage` 而不是对每一个 control plane 组件使用不同的镜像。 +* 提供一个统一的控制平面镜像 `unifiedControlPlaneImage` 而不是对每一个控制平面组件使用不同的镜像。 * 提供一个指定的 etcd 服务的镜像 `etcd.image` 而不是在 `k8s.gcr.io` 仓库中的可用镜像。 -如果给定的证书和密钥对已经存在,kubeadm 将会跳过生成证书的步骤并且直接将已经存在的文件用于规定的案例中。也就是说你可以拷贝一份已存在的 CA 文件到 `/etc/kubernetes/pki/ca.crt` 和 `/etc/kubernetes/pki/ca.key`,kubeadm将会使用这份 CA 来签发其余的证书。 +如果给定的证书和密钥对已经存在,kubeadm 将会跳过生成证书的步骤并且直接将已经存在的文件用于规定的案例中。也就是说你可以拷贝一份已存在的 CA 文件到 `/etc/kubernetes/pki/ca.crt` 和 `/etc/kubernetes/pki/ca.key`,kubeadm 将会使用这份 CA 来签发其余的证书。 #### 外部 CA 模式 {#external-ca-mode} @@ -256,10 +256,10 @@ ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $K -* `--kubeconfig=/etc/kubernetes/kubelet.conf` 指向 kubeconfig 文件,这份文件为 kubelet 指明 API server 的地址。这份文件也包含了 kubelet 的证书。 +* `--kubeconfig=/etc/kubernetes/kubelet.conf` 指向 kubeconfig 文件,这份文件为 kubelet 指明 API 服务器的地址。这份文件也包含了 kubelet 的证书。 -* `--pod-manifest-path=/etc/kubernetes/manifests` 指明从哪里读取静态 Pod 的清单文件用于启动 control plane。 +* `--pod-manifest-path=/etc/kubernetes/manifests` 指明从哪里读取静态 Pod 的清单文件用于启动控制平面。 * `--allow-privileged=true` 允许 kubelet 运行 privileged Pods。 @@ -280,7 +280,7 @@ ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $K * `--client-ca-file=/etc/kubernetes/pki/ca.crt` 使用这个 CA 证书认证发往 Kubelet API 的请求。 -* `--authorization-mode=Webhook` 通过 `POST` 方法向 API server 发送一个 `SubjectAccessReview` 对象来授权发往 Kubelet API 的请求。 +* `--authorization-mode=Webhook` 通过 `POST` 方法向 API 服务器发送一个 `SubjectAccessReview` 对象来授权发往 Kubelet API 的请求。 * `--rotate-certificates` 当证书临近过期的时候,通过从 `kube-apiserver` 请求新证书来自动替换 kubelet 客户端证书。 @@ -293,7 +293,7 @@ ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $K -从v1.6.0版本开始, Kubernetes 默认启用了 CRI, 容器运行时接口。 +从 v1.6.0 版本开始, Kubernetes 默认启用了 CRI, 容器运行时接口。 默认使用的容器运行时是 Docker, 这通过 `kubelet` 内置的 `dockershim` CRI 实现支持。 @@ -339,37 +339,37 @@ using an external CRI implementation. --> ### 在你的集群中使用内网 IP -为了配置一个 master 与 worker 节点间使用内网 IP 地址通信的集群(而不是使用公网地址),执行以下操作。 +为了配置一个主节点与工作节点间使用内网 IP 地址通信的集群(而不是使用公网地址),执行以下操作。 -1. 当运行 init 命令的时候, 你必须为 API server 指定一个内网 IP 作为监听地址,像这样: +1. 当运行 init 命令的时候, 你必须为 API 服务器指定一个内网 IP 作为监听地址,像这样: `kubeadm init --apiserver-advertise-address=` -2. 当一个 master 或者 worker 节点可供使用时,向 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 文件添加一个标记指明 worker 节点的私有 IP。 +2. 当一个主节点或者工作节点可供使用时,向 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 文件添加一个标记指明工作节点的私有 IP。 `--node-ip=` -3. 最后, 当你运行 `kubeadm join` 的时候, 确保你提供了正确的 API server 所在的、步骤 1 中定义的私有 IP。 +3. 最后, 当你运行 `kubeadm join` 的时候, 确保你提供了正确的 API 服务器所在的、步骤 1 中定义的私有 IP。 ### 设置节点的名称 默认情况下, `kubeadm` 基于机器的 host 地址分配一个节点名称。你可以使用 `--node-name` 参数覆盖这个设置。 - -这个参数会向 kubelet 传递相应的 [`--hostname-override`](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options) 参数。 + +这个参数会向 kubelet 传递相应的 [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options) 参数。 注意覆盖主机名称可能会 [干扰到云服务提供商](https://github.com/kubernetes/website/pull/8873)。 -### Self-hosting Kubernetes control plane {#self-hosting} +### 自托管的 Kubernetes 控制平面 {#self-hosting} -从1.8开始, 你可以试验性地创建一个 _self-hosted_ Kubernetes control plane. 这意味着诸如 API server、controller manager、 以及 scheduler 这些关键组件将作为通过 Kubernetes API 配置的 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 运行,而不是在 kubelet 中通过静态文件配置的 [static pods](/docs/tasks/administer-cluster/static-pod/)。 +从1.8开始, 你可以试验性地创建一个 _self-hosted_ Kubernetes 控制平面。 这意味着诸如 API 服务器、控制器管理器、 以及调度器这些关键组件将作为通过 Kubernetes API 配置的 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 运行,而不是在 kubelet 中通过静态文件配置的 [static pods](/docs/tasks/administer-cluster/static-pod/)。 若要创建一个 self-hosted 的集群, 向 `kubeadm init` 命令传递 `--feature-gates=SelfHosting=true` 参数。 @@ -392,10 +392,10 @@ and will be removed in 1.13. --> self-hosted cluster _cannot recover from a reboot of the master node_ without manual intervention. This and other limitations are expected to be resolved before self-hosting graduates from alpha. --> -1.8 版本中的 Self-hosting 功能有一些重要的限制。特别的, 一个 self-hosted 的集群如果不手动介入的话 _不能够从 master node 的重新启动中恢复_ 。 这个以及其它的一些限制被期望在 self-hosting 功能从 alpha 状态毕业前解决。 +1.8 版本中的自托管功能有一些重要的限制。特别的, 一个自托管的集群如果不手动介入的话 _不能够从主节点的重新启动中恢复_ 。 这个以及其它的一些限制被期望在自托管功能从 alpha 状态毕业前解决。 - -默认情况下, self-hosted control plane Pods 依赖位于 [`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) 数据卷中的证书。除了初始化创建证书的过程, 这些证书不被 kubeadm 管理。你可以使用 `--feature-gates=StoreCertsInSecrets=true` 参数来启用一个试验性的模式,在这个模式中 control plane 证书从 Secrets 加载。 这要求对你的集群进行非常小心的对鉴权和授权配置的控制, 并且可能并不适合你的环境。 + +默认情况下, self-hosted 控制平面 Pods 依赖位于 [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 数据卷中的证书。除了初始化创建证书的过程, 这些证书不被 kubeadm 管理。你可以使用 `--feature-gates=StoreCertsInSecrets=true` 参数来启用一个试验性的模式,在这个模式中控制平面证书从 Secrets 加载。 这要求对你的集群进行非常小心的对鉴权和授权配置的控制, 并且可能并不适合你的环境。 {{< caution >}} -在 kubeadm 1.8 版本中, control plane 的 self-hosted 的组件并不包含 etcd,它仍然是作为静态 Pod 运行的。 +在 kubeadm 1.8 版本中, 控制平面的 self-hosted 的组件并不包含 etcd,它仍然是作为静态 Pod 运行的。 #### 流程 -self-hosting 集群的启动过程写在了这份 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 文档中。 +自托管集群的启动过程写在了这份 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 文档中。 总的说来, `kubeadm init --feature-gates=SelfHosting=true` 是按照以下步骤工作的: - 1. 等待 control plane 的相关组件成功运行起来。这与没有启用 self-hosting 的 `kubeadm init` 指令的流程是一致的。 + 1. 等待控制平面的相关组件成功运行起来。这与没有启用自托管的 `kubeadm init` 指令的流程是一致的。 - 2. 使用静态的 control plane Pod 清单文件构建一个 DaemonSet 清单文件用来运行 self-hosted control plane。有时也会在必要的时候修改这些清单文件,比如为 secrets 添加新的数据卷。 + 1. 使用静态的控制平面 Pod 清单文件构建一个 DaemonSet 清单文件用来运行自托管的控制平面。有时也会在必要的时候修改这些清单文件,比如为 secrets 添加新的数据卷。 @@ -436,8 +436,7 @@ self-hosting 集群的启动过程写在了这份 [kubeadm 设计文档](https:/ - 5. 当原始的 static control plane 停止的时候, 新创建的 self-hosted control - plane 就能够绑定到端口并且可供使用。 + 5. 当原始的基于静态 Pod 的控制平面停止的时候, 新创建的自托管的控制平面就能够绑定到端口并且可供使用。 这个过程 (3-6步) 也可以通过 `kubeadm phase selfhosting convert-from-staticpods` 指令触发。 @@ -486,7 +485,7 @@ kubeadm config images pull ### kubeadm 自动化 -与其如文档 [kubeadm 基础教程](/docs/setup/independent/create-cluster-kubeadm/) 所述,将从 `kubeadm init` 取得的令牌拷贝到每一个节点, 倒不如你可以使用更加简单的自动化的方式将令牌并行地分发出去。如果要实现这个自动化,你必须要知道 master node 启动后的 IP 地址。 +与其如文档 [kubeadm 基础教程](/docs/setup/independent/create-cluster-kubeadm/) 所述,将从 `kubeadm init` 取得的令牌拷贝到每一个节点, 倒不如你可以使用更加简单的自动化的方式将令牌并行地分发出去。如果要实现这个自动化,你必须要知道主节点启动后的 IP 地址。 -2. 使用这个令牌同时启动 master node 和 worker nodes。它们一旦运行起来应该就会互相寻找对方并且建立集群。同样的 `--token` 参数可以同时用于 `kubeadm init` 和 `kubeadm join` 命令。 +2. 使用这个令牌同时启动主节点和工作节点。它们一旦运行起来应该就会互相寻找对方并且建立集群。同样的 `--token` 参数可以同时用于 `kubeadm init` 和 `kubeadm join` 命令。 -一旦集群启动起来,你就可以从 master node 的 `/etc/kubernetes/admin.conf` 文件获取管理凭证,然后你就可以使用这个凭证同集群通信了。 +一旦集群启动起来,你就可以从主节点的 `/etc/kubernetes/admin.conf` 文件获取管理凭证,然后你就可以使用这个凭证同集群通信了。 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 启动一个 Kubernetes worker node 并且将其加入到集群 +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 启动一个 Kubernetes 工作节点并且将其加入到集群 * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 将 Kubernetes 集群升级到新版本 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 使用 `kubeadm init` 或者 `kubeadm join`来恢复对节点的改变 +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 使用 `kubeadm init` 或者 `kubeadm join` 来恢复对节点的改变 {{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md new file mode 100644 index 0000000000..e3b7e1cdc1 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -0,0 +1,402 @@ +--- +reviewers: +- mikedanese +- luxas +- jbeda +title: kubeadm join +content_template: templates/concept +weight: 30 +--- +{{% capture overview %}} + +此命令用来初始化 Kubernetes 工作节点并将其加入集群。 +{{% /capture %}} + +{{% capture body %}} +{{< include "generated/kubeadm_join.md" >}} + + + +### 加入流程 + +`kubeadm join` 初始化 Kubernetes 工作节点并将其加入集群。 +该操作过程包含下面几个步骤: + + +1. kubeadm 从 API 服务器下载必要的集群信息。 + 默认情况下,它使用引导令牌和 CA 密钥哈希来验证数据的真实性。 + 也可以通过文件或 URL 直接发现根 CA。 + + + +1. 如果调用 kubeadm 时启用了 `--feature-gates=DynamicKubeletConfig`,它首先从主机上检索 kubelet 初始化配置并将其写入磁盘。 + 当 kubelet 启动时,kubeadm 更新节点的 `Node.spec.configSource` 属性。 + 进一步了解动态 kubelet 配置 请参考 [使用配置文件设置 Kubelet 参数](/docs/tasks/administer-cluster/kubelet-config-file/) 和 [重新配置集群中节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/)。 + + + +1. 一旦知道集群信息,kubelet 就可以开始 TLS 引导过程。 + TLS 引导程序使用共享令牌与 Kubernetes API 服务器进行临时的身份验证,以提交证书签名请求 (CSR); + 默认情况下,控制平面自动对该 CSR 请求进行签名。 + + + +1. 最后,kubeadm 配置本地 kubelet 使用分配给节点的确定标识连接到 API 服务器。 + + + +### 发现要信任的集群 CA + +Kubeadm 的发现有几个选项,每个选项都有安全性上的优缺点。 +适合您的环境的正确方法取决于节点是如何准备的以及您对网络的安全性期望和节点的生命周期特点。 + + + +#### 带 CA 锁定模式的基于令牌的发现 + +这是 Kubernetes 1.8 及以上版本中的默认模式。 +在这种模式下,kubeadm 下载集群配置(包括根CA)并使用令牌验证它,并且会验证根 CA 的公钥与所提供的哈希是否匹配,以及 API 服务器证书在根 CA 下是否有效。 + + + +CA 键哈希格式为 `sha256:`。 +默认情况下,在 `kubeadm init` 最后打印的 `kubeadm join` 命令或者 `kubeadm token create--print-join-command` 的输出信息中返回哈希值。 +它使用标准格式 (请参考 [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) 并且也能通过第三方工具或者驱动系统进行计算。 +例如,使用 OpenSSL CLI: + +```bash +openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //' +``` + + +**`kubeadm join` 命令示例** + +```bash +kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443 +``` + + + +**优势:** + - 允许引导节点安全地发现主节点的信任根,即使其他工作节点或网络受到损害。 + + - 方便手动执行,因为所需的所有信息都适合于易于复制和粘贴的单个 `kubeadm join` 命令。 + + + +**劣势:** + - CA 哈希通常在主节点被提供之前是不知道的,这使得构建使用 kubeadm 的自动化配置工具更加困难。 + 通过预先生成CA,您可以解决这个限制。 + + + +#### 无 CA 锁定模式的基于令牌的发现 + +_这是 Kubernetes 1.7 和早期版本_中的默认设置;使用时要注意一些重要的补充说明。 +此模式仅依赖于对称令牌来签名(HMAC-SHA256)发现信息,这些发现信息为主节点建立信任根。 +在 Kubernetes 1.8 及以上版本中仍然可以使用 `--discovery-token-unsafe-skip-ca-verification` 参数,但是如果可能的话,您应该考虑使用一种其他模式。 + +**`kubeadm join` 命令示例** + +``` +kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443` +``` + + + +**优势** + + - 仍然可以防止许多网络级攻击。 + + - 可以提前生成令牌并与主节点和工作节点共享,这样主节点和工作节点就可以并行引导而无需协调。 + 这允许它在许多配置场景中使用。 + + + +**劣势** + + - 如果攻击者能够通过某些漏洞窃取引导令牌,那么他们可以使用该令牌(连同网络级访问)为其它处于引导过程中的节点提供假冒的主节点。 + 在您的环境中,这可能是一个适当的折衷方法,也可能不是。 + + + +#### 基于 HTTPS 或文件发现 + +这种方案提供了一种带外方式在主节点和引导节点之间建立信任根。 +如果使用 kubeadm 构建自动配置,请考虑使用此模式。 + + + +**`kubeadm join` 命令示例:** + - `kubeadm join --discovery-file path/to/file.conf` (本地文件) + + - `kubeadm join --discovery-file https://url/file.conf` (远程 HTTPS URL) + + + +**优势:** + + - 允许引导节点安全地发现主节点的信任根,即使网络或其他工作节点受到损害。 + + + +**劣势:** + + - 要求您有某种方法将发现信息从主节点传送到引导节点。 + 例如,这可以通过云提供商或驱动工具实现。 + 该文件中的信息不是加密的,而是需要 HTTPS 或等效文件来保证其完整性。 + + + +### 确保您的安装更加安全 {#securing-more} + +Kubeadm 的默认值可能不适用于所有人。 +本节说明如何以牺牲可用性为代价来加强 kubeadm 安装。 + + + +#### 关闭节点客户端证书的自动批准 + +默认情况下,Kubernetes 启用了 CSR 自动批准器,如果在身份验证时使用 Bootstrap Token,它会批准对 kubelet 的任何客户端证书的请求。 +如果不希望集群自动批准kubelet客户端证书,可以通过执行以下命令关闭它: + +```console +$ kubectl delete clusterrole kubeadm:node-autoapprove-bootstrap +``` + + +关闭后,`kubeadm join` 操作将会被阻断,直到管理员已经手动批准了在途中的 CSR 才会继续: + +```console +$ kubectl get csr +NAME AGE REQUESTOR CONDITION +node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending + +$ kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ +certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved + +$ kubectl get csr +NAME AGE REQUESTOR CONDITION +node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued +``` + + +只有执行了 `kubectl certificate approve` 后,`kubeadm join` 才会继续。 + +#### 关闭对集群信息 ConfigMap 的公开访问 + +为了实现使用令牌作为唯一验证信息的加入工作流,默认情况下会公开带有验证主节点标识所需数据的 ConfigMap。 +虽然此 ConfigMap 中没有私有数据,但一些用户可能希望无论如何都关闭它。 +这样做需要禁用 `kubeadm join` 工作流的 `--discovery-token` 参数。 +以下是实现步骤: + +```console +$ kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml +apiVersion: v1 +clusters: +- cluster: + certificate-authority-data: + server: https://: + name: "" +contexts: [] +current-context: "" +kind: Config +preferences: {} +users: [] +``` + + + +* 使用 `cluster-info.yaml` 文件作为 `kubeadm join --discovery-file` 参数。 + +* 关闭 `cluster-info` ConfigMap 的公开访问: + +```console +$ kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo +``` + + + +这些命令应该在执行 `kubeadm init` 之后、在`kubeadm join` 之前执行。 + +### 使用带有配置文件的 kubeadm join + +{{< caution >}} + +配置文件目前是 alpha 功能,在将来的版本中可能会变动。 +{{< /caution >}} + + + +可以用配置文件替代命令行参数的方法配置 `kubeadm join`,一些高级功能也只有在使用配置文件时才可选用。 +该文件通过 `--config` 参数来传递,并且文件中必须包含 `JoinConfiguration` 结构。 + +执行下面的命令可以查看 `JoinConfiguration` 默认值: + +```bash +kubeadm config print-default --api-objects=JoinConfiguration +``` + + + +要了解 `JoinConfiguration` 中各个字段的详细信息请参考 [godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration)。 +{{% /capture %}} + +{{% capture whatsnext %}} + +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 初始化 Kubernetes 主节点 +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 管理 `kubeadm join` 的令牌 +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 将 `kubeadm init` 或 `kubeadm join` 对主机的更改恢复到之前状态 +{{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md new file mode 100644 index 0000000000..5aa1028cc4 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -0,0 +1,56 @@ +--- +reviewers: +- mikedanese +- luxas +- jbeda +title: kubeadm reset +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +此命令用来将 `kubeadm init` 或 `kubeadm join` 命令所做的改动恢复到之前的状态。 +{{% /capture %}} + +{{% capture body %}} +{{< include "generated/kubeadm_reset.md" >}} + + + +### 外部 etcd 清理 + +如果使用了外部 etcd,`kubeadm reset` 将不会删除任何 etcd 中的数据。 +这意味着,如果再次使用相同的 etcd 端点运行 `kubeadm init`,您将看到先前集群的状态。 + +要擦除 etcd 中的数据,建议您使用 etcdctl 这样的客户端,例如: + +```bash +etcdctl del "" --prefix +``` + + +更多详情请参考 [etcd 文档](https://github.com/coreos/etcd/tree/master/etcdctl)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +* 参考 [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 来初始化 Kubernetes 主节点。 +* 参考 [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 来初始化 Kubernetes 工作节点并加入集群。 + +{{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md new file mode 100644 index 0000000000..24d3dac6b6 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md @@ -0,0 +1,61 @@ +--- +reviewers: +- mikedanese +- luxas +- jbeda +title: kubeadm 令牌 +content_template: templates/concept +weight: 70 +--- + + + +{{% capture overview %}} + + +如[使用引导令牌进行身份验证](/docs/reference/access-authn-authz/bootstrap-tokens/)所描述的,引导令牌用于在即将加入集群的节点和主节点间建立双向认证。 + + + +`kubeadm init` 创建了一个有效期为 24 小时的令牌,下面的命令允许您管理令牌,也可以创建和管理新的令牌。 + +{{% /capture %}} + +{{% capture body %}} +## kubeadm token create {#cmd-token-create} +{{< include "generated/kubeadm_token_create.md" >}} + +## kubeadm token delete {#cmd-token-delete} +{{< include "generated/kubeadm_token_delete.md" >}} + +## kubeadm token generate {#cmd-token-generate} +{{< include "generated/kubeadm_token_generate.md" >}} + +## kubeadm token list {#cmd-token-list} +{{< include "generated/kubeadm_token_list.md" >}} +{{% /capture %}} + +{{% capture whatsnext %}} +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 引导 Kubernetes 工作节点并将其加入群集 +{{% /capture %}} + + + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md new file mode 100644 index 0000000000..9a28793a46 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -0,0 +1,80 @@ +--- +title: kubeadm upgrade +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +`kubeadm upgrade` 是一个对用户友好的命令,它将复杂的升级逻辑包装在一个命令后面,支持升级的规划和实际执行。 +如有必要,`kubeadm upgrade` 也可用于降级集群。 +{{% /capture %}} + +{{% capture body %}} + +## kubeadm 升级指南 + + +每个升级过程可能会有所不同,因此我们分别记录了每个小的升级过程。 +有关特定版本的更多升级指南,请参阅以下资源: + + + * [1.10 到 1.11 升级](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/) + * [1.11 到 1.12 升级](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/) + + +_对于更老的版本,请参阅 Kubernetes 网站上的旧版文档。_ + + +在 Kubernetes v1.11.0 及更高版本中,您可以使用 `kubeadm upgrade diff` 来查看将应用于静态 Pod 清单的更改。 + +## kubeadm upgrade plan {#cmd-upgrade-plan} +{{< include "generated/kubeadm_upgrade_plan.md" >}} + +## kubeadm upgrade apply {#cmd-upgrade-apply} +{{< include "generated/kubeadm_upgrade_apply.md" >}} + +## kubeadm upgrade diff {#cmd-upgrade-diff} +{{< include "generated/kubeadm_upgrade_diff.md" >}} + +## kubeadm upgrade node config {#cmd-upgrade-node-config} +{{< include "generated/kubeadm_upgrade_node_config.md" >}} + +## kubeadm upgrade node experimental-control-plane {#cmd-experimental-control-plane} +{{< include "generated/kubeadm_upgrade_node_experimental-control-plane.md" >}} + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) 如果使用 kubeadm v1.7.x 或更低版本初始化的集群,请配置您的集群来使用 `kubeadm upgrade`。 +{{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md new file mode 100644 index 0000000000..d139966055 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md @@ -0,0 +1,22 @@ +--- +reviewers: +- mikedanese +- luxas +- jbeda +title: kubeadm version +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + + +此命令用来查询 kubeadm 的版本。 + +{{% /capture %}} + +{{% capture body %}} +{{< include "generated/kubeadm_version.md" >}} +{{% /capture %}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md index bf0c215001..cd028ea1cf 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md @@ -8,7 +8,7 @@ weight: 10 Kubeadm 是一个工具,它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。 -kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群,而不是之前的节点准备工作。同样的,诸如安装各种各样值得拥有的插件,例如 Kubernetes Dashboard、监控解决方案以及特定云提供商的插件,这些都不在它负责的范围。 +kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群,而不是准备节点环境的工作。同样的,诸如安装各种各样的可有可无的插件,例如 Kubernetes 控制面板、监控解决方案以及特定云提供商的插件,这些都不在它负责的范围。 相反,我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情;并且,理想情况下,使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。 @@ -23,12 +23,12 @@ kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群 * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本 -* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果使用 v1.7.x 或者更低版本的 kubeadm 初始化集群,您需要对集群做一些配置以便使用 `kubeadm upgrade` 命令 +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本,你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令 -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 管理 `kubeadm join` 使用的令牌 +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原 `kubeadm init` 或者 `kubeadm join` 对主机所做的任何更改 +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 使用 `kubeadm init` 或者 `kubeadm join` 来恢复对节点的改变 -* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印 kubeadm 版本 +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本 * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈 diff --git a/content/zh/docs/reference/setup-tools/kubefed/_index.md b/content/zh/docs/reference/setup-tools/kubefed/_index.md new file mode 100644 index 0000000000..e76834dc5e --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/_index.md @@ -0,0 +1,13 @@ +--- +title: kubefed +weight: 20 +toc-hide: true +--- + + diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed-options.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed-options.md new file mode 100644 index 0000000000..2ae8d5f403 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed-options.md @@ -0,0 +1,176 @@ +--- +title: kubefed 选项 +notitle: true +weight: 20 +--- + + + + + +## kubefed 选项 + + +打印所有命令继承的参数列表 + + + +### 概要 + + +打印所有命令继承的参数列表 + +``` +kubefed options [flags] +``` + + + +### 例子 + + + +``` + # 打印所有命令继承的参数 + kubefed options +``` + + + +### 选项 + + + +``` + -h, --help help for options +``` + + + +### 从父命令继承的选项 + + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端秘钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16) + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标 (默认 "k8s") + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数 (默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中; 默认值为 true + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时; 默认值为 "0" + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr (默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证 + -v, --v Level V log 的 log 级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N" +``` + + + + + +### 查看其它 + +* [kubefed](/docs/reference/setup-tools/kubefed/kubefed/) - kubefed 控制一个 Kubernetes 集群联邦 + + + + + + diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed.md new file mode 100644 index 0000000000..3fdc8b36cc --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed.md @@ -0,0 +1,137 @@ +## kubefed + + + +使用 kubefed 控制 Kubernetes 集群联邦 + + + +### 概要 + + +使用 kubefed 控制 Kubernetes 集群联邦 + + +更多信息请前往 https://github.com/kubernetes/federation + +``` +kubefed [flags] +``` + +### 选项 + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端密钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16)。 + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + -h, --help kubefed 的帮助信息 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全。 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认 "k8s")。 + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数(默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中;默认值为 true。 + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0"。 + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证。 + -v, --v Level V 日志的日志级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N"。 +``` + + + +### 其他参考 +* [kubefed init](kubefed_init.md) - 初始化联邦控制平面 +* [kubefed join](kubefed_join.md) - 将集群加入联邦 +* [kubefed options](kubefed_options.md) - 打印所有命令继承的参数列表 +* [kubefed unjoin](kubefed_unjoin.md) - 将集群从联邦中移除 +* [kubefed version](kubefed_version.md) - 打印客户端和服务器版本信息 + + +###### 原文由 spf13/cobra 自动生成于 2018-9-24 + diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed_init.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed_init.md new file mode 100644 index 0000000000..7389f6f51f --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed_init.md @@ -0,0 +1,212 @@ +## kubefed init + + + +初始化联邦控制平面 + + + +### 概要 + + + +Init 用来初始化联邦控制平面 + + 联邦控制平面位于 Kubernetes 集群内。必须使用 --host-cluster-context 参数指定主机集群。 + +``` +kubefed init FEDERATION_NAME --host-cluster-context=HOST_CONTEXT [flags] +``` + + + +### 示例 + +``` + + +``` + # 为主机集群中名为 foo 的联邦初始化控制平面,该主机集群中的本地 kubeconfig 上下文为 bar。 + kubefed init foo --host-cluster-context=bar +``` + + + +### 选项 + + + +``` + --api-server-advertise-address string 公布 API 服务器的 nodeport 服务的首选地址。 只在 'api-server-service-type=NodePort' 时有效。 + --api-server-port int32 API 服务器的 nodeport 服务的首选端口(设置为 0 将随机指定端口)。只在 'api-server-service-type=NodePort' 时有效。 + --api-server-service-type string 创建联邦 API 服务器的服务类型。 选项包括:'LoadBalancer'(默认),'NodePort'。(默认 "LoadBalancer") + --apiserver-arg-overrides string 要重写的联合 API 服务器参数列表,用逗号分隔, 例如 "--arg1=value1,--arg2=value2..." + --apiserver-enable-basic-auth 为联邦 API 服务器启用 HTTP 基本身份验证。默认关闭。 + --apiserver-enable-token-auth 为联邦 API 服务器启用令牌身份验证。默认关闭。 + --controllermanager-arg-overrides string 要重写的 federation-controller-manager 参数列表,用逗号分隔,例如:"--arg1=value1,--arg2=value2..." + --credentials-kubeconfig string 本地文件系统上的 kubeconfig 文件路径,应用于与主机集群或加入集群(而不是默认的 kubeconfig)进行身份验证。这可用于在初始化联邦控制平面或将集群加入到一个集群时覆盖基于 RBAC 的身份验证,即使在集群公开 RBAC API 时也是如此。 + --dns-provider string 此 deployment 使用的 DNS 驱动。 + --dns-provider-config string 用来配置 DNS 驱动的本地文件系统中的配置文件。 + --dns-zone-name string 此联邦的 DNS 后缀。使用此后缀发布联邦服务 DNS 名称。 + --dry-run 在不向服务器发送命令的情况下进行试运行。 + --etcd-image string 服务器使用的镜像(默认 "gcr.io/google_containers/etcd:3.1.10") + --etcd-persistent-storage etcd 使用持久卷,默认为 'true'。(默认 true) + --etcd-pv-capacity string etcd 所使用的持久卷申领的大小(默认 "10Gi") + --etcd-pv-storage-class string etcd 所使用的持久卷申领的存储类。如果主机集群没有配置默认存储类,就必须提供。 + --etcd-servers string 用来存储联邦状态的外部预部署的 etcd 服务器。 + --federation-system-namespace string 主机集群上用来安装联邦系统组件的命名空间(默认 "federation-system") + -h, --help init 的帮助信息 + --host-cluster-context string 主机集群的上下文 + --image string 用于联邦 API 服务器和控制器管理器二进制文件的镜像。(默认 "gcr.io/k8s-jkns-e2e-gce-federation/fcp-amd64:v0.0.0-master_$Format:%h$") + --image-pull-policy string 拉取策略描述了容器映像的拉取策略。默认的拉取策略是 ifNotPresent,如果镜像已存在,则不会拉它。(默认 "IfNotPresent") + --image-pull-secrets string 提供访问私有仓库的 secret。 + --node-selector string 逗号分隔的 nodeSelector(节点选择器)参数列表,例如:"arg1=value1,arg2=value2..." +``` + + + +### 从父命令继承的选项 + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端秘钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16) + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认 "k8s") + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数(默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中;默认值为 true + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0" + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证 + -v, --v Level V 日志的日志级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N" +``` + + + +### 其他参考 +* [kubefed](kubefed.md) - 用 kubefed 控制 Kubernetes 集群联邦 + + +###### 原文由 spf13/cobra 自动生成于 2018-9-24 diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed_join.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed_join.md new file mode 100644 index 0000000000..e481c1f43c --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed_join.md @@ -0,0 +1,202 @@ +## kubefed join + + + +将集群加入联邦 + + + +### 概要 + + + +Join 将集群加入联邦。 + + + + 假设当前上下文是联邦 API 服务器。否则请使用 --context 参数。 + +``` +kubefed join CLUSTER_NAME --host-cluster-context=HOST_CONTEXT [flags] +``` + + + +### 示例 + + + +``` + # 通过指定集群名称和联邦控制平面的主机集群上下文名称,将集群添加到联邦。集群名称必须是符合 RFC 1123 规范的可用子域名。 + # 如果集群名称和本地 kubeconfig 中的集群上下文不同,就必须指定集群上下文。 + kubefed join foo --host-cluster-context=bar +``` + + + +### 选项 + + + +``` + --allow-missing-template-keys 如果为 true,当模版中的字段或者映射键缺失时,将忽略模版中的任何错误。仅应用于 golang 和 jsonpath 输出格式。(默认值为 true) + --cluster-context string 本地 kubeconfig 中的集群上下文名称。如果未指定,默认为集群名称。 + --credentials-kubeconfig string 本地文件系统上的 kubeconfig 的文件路径,应用于对主机集群或加入集群(而不是默认的 kubeconfig)进行身份验证。这可用于在初始化联合控制平面或将集群加入到其中时覆盖基于 RBAC 的身份验证,即使在集群公开 RBAC API 时也是如此。 + --dry-run 如果为 true,只打印将要发送的对象,实际上并没有发送出去。 + --federation-system-namespace string 安装联邦系统组件的主机集群命名空间(默认值为 "federation-system")。 + --generator string 要使用的 API 生成器的名称(默认值为 "cluster/v1beta1")。 + -h, --help join 的帮助信息。 + --host-cluster-context string 主机集群上下文。 + --no-headers 当使用默认或者定制列输出格式时,不打印头信息(默认打印头信息)。 + -o, --output string 输出格式。下列之一: json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... 参考定制列 [/docs/user-guide/kubectl-overview/#custom-columns],golang 模版 [http://golang.org/pkg/text/template/#pkg-overview] 和 jsonpath 模版 [/docs/user-guide/jsonpath]。 + --save-config 如果为 true,当前对象的配置将保存到它的注解中。否则将不会改变注解。 当你将来对此对象执行 kubectl apply 时,会用到该参数。 + -a, --show-all 打印时,显示所有资源。(默认隐藏已终止的 pod) + --show-labels 打印时,将所有标签显示在最后一列。 (默认隐藏标签列) + --sort-by string 如果非空, 使用此字段的指定项对列表类型进行排序。此字段的指定项使用 JSONPath 表达式(例如 '{.metadata.name}')。 此 JSONPath 表达式指定的 API 资源中的字段必须是整数或字符串。 + --template string 当设置 -o=go-template,-o=go-template-file 时, 要使用的模板文件的模板字符串或路径。模版格式为 golang 模版 [http://golang.org/pkg/text/template/#pkg-overview]。 + --validate 如果为 true,在发送输入信息之前先进行语法检查(默认值为 true)。 +``` + + + +### 从父命令继承的选项 + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr)。 + --as string 用户名模拟操作。 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认值为 "/Users/jrondeau/.kube/http-cache")。 + --certificate-authority string 证书创建的证书机构的的路径。 + --client-certificate string TLS 客户端证书的路径。 + --client-key string TLS 客户端秘钥的路径。 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16)。 + --cluster string 使用的 kubeconfig 集群的名称。 + --context string 使用的 kubeconfig 上下文名称。 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全。 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认值为 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认值为 "k8s")。 + --ir-hawkular string Hawkular 配置 URL。 + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认值为 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy")。 + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认值为 "root")。 + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认值为 "root")。 + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为:0。 + --log-dir string 如果非空,在此目录中写入日志文件。 + --log-flush-frequency duration 日志刷新的最大秒数(默认值为 5s)。 + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中;默认值为 true。 + --match-server-version 要求服务器版本与客户端版本匹配。 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围。 + --password string 用来对 API 服务器进行基本身份验证的密码。 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0"。 + -s, --server string Kubernetes API 服务器的地址和端口。 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认值为 2)。 + --token string 向 API 服务器进行身份验证的持有者令牌。 + --user string 使用的 kubeconfig 用户的名称。 + --username string 用户名,用于对 API 服务器的基本身份验证。 + -v, --v Level V 日志的日志级别。 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N"。 +``` + + + +### 其他参考 +* [kubefed](kubefed.md) - 使用 kubefed 控制集群联邦 + + + +###### 由 spf13/cobra 自动生成于 2018-9-24 diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed_options.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed_options.md new file mode 100644 index 0000000000..87e0b5cf0b --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed_options.md @@ -0,0 +1,161 @@ +## kubefed 选项 + + + +打印适用于所有命令的参数列表 + + + +### 概要 + + + +打印适用于所有命令的参数列表 + +``` +kubefed options [flags] +``` + + + +### 示例 + + + +``` + # 打印适用于所有命令的参数 + kubefed options +``` + + + +### 选项 + + + +``` + -h, --help options 的帮助信息 +``` + + + +### 从父命令继承的选项 + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端秘钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16)。 + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全。 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认 "k8s")。 + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数(默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中;默认值为 true。 + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0"。 + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证。 + -v, --v Level V 日志的日志级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N"。 +``` + + + +### 其他参考 +* [kubefed](kubefed.md) - 使用 kubefed 控制 Kubernetes 集群联邦 + + + +###### 原文由 spf13/cobra 自动生成于 2018-9-24 diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed_unjoin.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed_unjoin.md new file mode 100644 index 0000000000..72e63b6825 --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed_unjoin.md @@ -0,0 +1,175 @@ +## kubefed unjoin + + + +从联邦中移除一个集群 + + + +### 概要 + + +从联邦中移除一个集群 + + + 假定当前上下文是联邦端点。 + 否则请使用 --context 参数。 + +``` +kubefed unjoin CLUSTER_NAME --host-cluster-context=HOST_CONTEXT [flags] +``` + + + +### 示例 + + + +``` + # 从联邦中移除指定集群。必须通过 --host-cluster-context 参数指定联邦控制平面所在群集的上下文名称,以便正确清理凭证。 + kubectl unjoin foo --host-cluster-context=bar --cluster-context=baz +``` + + + +### 选项 + + + +``` + --cluster-context string 本地 kubeconfig 中的集群上下文名称。 如果未指定,默认为集群名称。 + --credentials-kubeconfig string 本地文件系统上的 kubeconfig 文件路径,应用于与主机群集或加入群集(而不是默认的 kubeconfig)进行身份验证。这可用于在初始化联邦控制平面或将群集加入到一个群集时覆盖基于 RBAC 的身份验证,即使在群集公开 RBAC API 时也是如此。 + --federation-system-namespace string 主机集群上用来安装联邦系统组件的命名空间(默认 "federation-system") + -h, --help unjoin 的帮助信息 + --host-cluster-context string 宿主集群的上下文 +``` + + + +### 从父命令继承的选项 + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端密钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16) + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认 "k8s") + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数 (默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中; 默认值为 true + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0" + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证 + -v, --v Level V 日志的日志级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N" +``` + + + +### 其他参考 +* [kubefed](kubefed.md) - 用 kubefed 控制 Kubernetes 集群联邦 + + +###### 原文由 spf13/cobra 自动生成于 2018-9-24 diff --git a/content/zh/docs/reference/setup-tools/kubefed/kubefed_version.md b/content/zh/docs/reference/setup-tools/kubefed/kubefed_version.md new file mode 100644 index 0000000000..3d4087672d --- /dev/null +++ b/content/zh/docs/reference/setup-tools/kubefed/kubefed_version.md @@ -0,0 +1,165 @@ +## kubefed version + + + +打印客户端和服务器的版本信息 + + + +### 概要 + + + +打印当前上下文的客户端和服务器版本信息 + +``` +kubefed version [flags] +``` + + +### 示例 + + + +``` + # 打印当前上下文的客户端和服务器版本信息 + kubefed version +``` + + + +### 选项 + + + +``` + --client 只打印客户端版本(不打印服务器的版本)。 + -h, --help version 的帮助信息 + -o, --output string 'yaml' 或 'json' 之一。 + --short 仅打印版本号。 +``` + + + +### 从父命令继承的选项 + + + + +``` + --alsologtostderr 同时将日志输出到标准错误输出(stderr) + --as string 用户名模拟操作 + --as-group stringArray 要模拟操作的组,可以重复使用此参数来指定多个组。 + --cache-dir string 默认 HTTP 缓存目录(默认 "/Users/jrondeau/.kube/http-cache") + --certificate-authority string 证书创建的证书机构的的路径 + --client-certificate string TLS 客户端证书的路径 + --client-key string TLS 客户端秘钥的路径 + --cloud-provider-gce-lb-src-cidrs cidrs 在 GCE 防火墙中放开的 CIDRs,用于 LB 流量代理和检查是否正常(默认 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16) + --cluster string 使用的 kubeconfig 集群的名称 + --context string 使用的 kubeconfig 上下文名称 + --default-not-ready-toleration-seconds int 对于未添加 notReady:NoExecute 容忍度设置的所有 Pod,为其设置此参数值作为对 notReady:NoExecute 容忍度的容忍秒数(tolerationSeconds);默认值为 300 秒。 + --default-unreachable-toleration-seconds int 对于未设置 unreachable:NoExecute 容忍度的所有 Pod,设置其对 unreachable:NoExecute 的容忍度秒数(tolerationSeconds);默认值为 300 秒。 + --insecure-skip-tls-verify 如果是 true,将不检查服务器证书的有效性。这将使您的 HTTPS 连接不安全 + --ir-data-source string 由 InitialResources 使用的数据源;支持的选项有:influxdb 和 gcm(默认 "influxdb")。 + --ir-dbname string 数据库名,其中包含 InitialResources 所需的指标(默认 "k8s") + --ir-hawkular string Hawkular 配置 URL + --ir-influxdb-host string 包含 InitialResources 需要的指标的 InfluxDB 的地址(默认 "localhost:8080/api/v1/namespaces/kube-system/services/monitoring-influxdb:api/proxy") + --ir-namespace-only 是否仅根据来自相同命名空间的数据进行估算。 + --ir-password string 用于连接到 InfluxDB 的密码(默认 "root") + --ir-percentile int 在估算资源时,InitialResoruces 要使用的样本百分比。仅用于实验目的。默认值为 90。 + --ir-user string 用于连接到 InfluxDB 的用户(默认 "root") + --kubeconfig string 用于 CLI 请求的 kubeconfig 文件的路径。 + --log-backtrace-at traceLocation 当日志机制遇到文件行 file:N 时,打印堆栈轨迹;默认值为 “:0”。 + --log-dir string 如果非空,在此目录中写入日志文件 + --log-flush-frequency duration 日志刷新的最大秒数(默认 5s) + --logtostderr 记录日志到标准错误输出(stderr)而不是文件中;默认值为 true + --match-server-version 要求服务器版本与客户端版本匹配 + -n, --namespace string 若给定,用来设置 CLI 请求的命名空间范围 + --password string 用来对 API 服务器进行基本身份验证的密码 + --request-timeout string 放弃单个服务器请求前等待的时间长度。非零值应包含相应的时间单位(如 1s、2m 或 3h)。值为 0 表示请求不超时;默认值为 "0" + -s, --server string Kubernetes API 服务器的地址和端口 + --stderrthreshold severity 在此阈值或以上的日志将转到 stderr(默认 2) + --token string 向 API 服务器进行身份验证的持有者令牌 + --user string 使用的 kubeconfig 用户的名称 + --username string 用户名,用于对 API 服务器的基本身份验证 + -v, --v Level V 日志的日志级别 + --vmodule moduleSpec 基于文件的日志过滤,取值为逗号分隔的列表,列表中每项的格式为 "pattern=N" +``` + + + +### 其他参考 +* [kubefed](kubefed.md) - 使用 kubefed 控制集群联邦 + + + +###### 原文由 spf13/cobra 自动生成于 2018-9-24 diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index 388187aebe..8f1914ee63 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -1,3 +1,10 @@ +--- +reviewers: +- janetkuo +title: 工具 +content_template: templates/concept +--- + ---- -reviewers: -- janetkuo -title: 工具 -content_template: templates/concept ---- + + diff --git a/content/zh/docs/reference/using-api/client-libraries.md b/content/zh/docs/reference/using-api/client-libraries.md new file mode 100644 index 0000000000..1b1b8dea7e --- /dev/null +++ b/content/zh/docs/reference/using-api/client-libraries.md @@ -0,0 +1,139 @@ +--- +title: 客户端库 +content_template: templates/concept +weight: 30 +--- + + + +{{% capture overview %}} + +本页面包含基于各种编程语言使用 Kubernetes API 的客户端库概述。 +{{% /capture %}} + +{{% capture body %}} + +在使用 [Kubernetes REST API](/docs/reference/using-api/api-overview/) 编写应用程序时, +您并不需要自己实现 API 调用和 “请求/响应” 类型。 +您可以根据自己的编程语言需要选择使用合适的客户端库。 + + +客户端库通常为您处理诸如身份验证之类的常见任务。 +如果 API 客户端在 Kubernetes 集群中运行,大多数客户端库可以发现并使用 Kubernetes 服务帐户进行身份验证, +或者能够理解 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) +格式来读取凭据和 API 服务器地址。 + + +## 官方支持的 Kubernetes 客户端库 + + +以下客户端库由 [Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 正式维护。 + + +| 语言 | 客户端库 | 样例程序 | +|----------|----------------|-----------------| +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [浏览](https://github.com/kubernetes/client-go/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [浏览](https://github.com/kubernetes-client/python/tree/master/examples) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [浏览](https://github.com/kubernetes-client/java#installation) +| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [浏览](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [浏览](https://github.com/kubernetes-client/javascript/tree/master/examples) + + + +## 社区维护的客户端库 + + +以下 Kubernetes API 客户端库是由社区,而非 Kubernetes 团队支持、维护的。 + + +| 语言 | 客户端库 | +| -------------------- | ---------------------------------------- | +| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | +| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | +| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | +| Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | +| Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | +| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | +| PHP | [github.com/devstub/kubernetes-api-php-client](https://github.com/devstub/kubernetes-api-php-client) | +| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | +| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | +| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | +| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | +| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Haskell | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) | +{{% /capture %}} + + diff --git a/content/zh/docs/search.md b/content/zh/docs/search.md new file mode 100644 index 0000000000..d0a89719f7 --- /dev/null +++ b/content/zh/docs/search.md @@ -0,0 +1,11 @@ +--- +layout: search +title: 搜索结果 +--- + + \ No newline at end of file diff --git a/content/zh/docs/setup/_index.md b/content/zh/docs/setup/_index.md new file mode 100644 index 0000000000..22c00bb3cf --- /dev/null +++ b/content/zh/docs/setup/_index.md @@ -0,0 +1,211 @@ +--- +reviewers: +- brendandburns +- erictune +- mikedanese +no_issue: true +title: 设置 +main_menu: true +weight: 30 +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +在这个页面可以找到最适合您以及您需要的解决方案类型。 + + +Kubernetes 在何处运行取决于您拥有什么资源以及您需要多大的灵活性。您几乎可以在任何地方运行 Kubernetes, +从笔记本电脑到云服务提供商的虚拟机,再到一排裸金属服务器。您还可以通过运行单个命令来设置完全 +托管的集群,或者在裸金属服务器上创建您自己的定制集群。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 本地机器解决方案 + + +本地机器解决方案是开始使用 Kubernetes 的一种简单的方法。您可以创建和测试 Kubernetes 集群,而不必担心消耗云资源和配额。 + + +你应该选择一个本地解决方案,如果您想: + + + +* 尝试或开始了解 Kubernetes +* 在本地开发和测试集群 + + +选择[本地机器解决方案](/docs/setup/pick-right-solution/#local-machine-solutions)。 + + +## 托管解决方案 + + +托管解决方案是创建和维护 Kubernetes 集群的一种实用的方法。他们管理和操作您的集群,所以您不需要。 + + +您应该选择一个托管解决方案,如果您需要: + + + +* 想要一个完全托管的解决方案 +* 希望专注于开发您的应用或者服务 +* 没有专门的可靠的工程(SRE)团队,但需要高可用 +* 没有资源来托管和监视集群 + + +选择[托管解决方案](/docs/setup/pick-right-solution/#hosted-solutions)。 + + + +## 一站式云解决方案 + + +这些解决方案允许您仅使用几个命令创建 Kubernetes 集群,这些集群是积极开发的,并且得到了社区的支持。 +它们也可以托管在一系列云服务 IaaS 提供商上,它们提供了更多的自由和灵活性来换取工作量。 + + +您应该选择一个一站式云服务解决方案,如果您需要: + + + +* 希望对集群拥有比托管解决方案更多的控制 +* 希望拥有更多的运营所有权 + + +选择[一站式云服务解决方案](/docs/setup/pick-right-solution/#turnkey-cloud-solutions)。 + + + +## 一站式本地解决方案 + + +这些解决方案允许您在您的内部、安全的云网络上创建 Kubernetes 集群,只需要几个命令。 + + + +您应该选择一个一站式本地解决方案,如果您需要: + + + +* 希望在您的私有云网络上部署集群 +* 有一个专门的 SRE 团队 +* 拥有托管和监视集群的资源 + + +选择[一站式本地云服务解决方案](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions)。 + + + +## 定制解决方案 + + +定制解决方案为您的集群提供了最大的自由度,但需要最多的专业知识。这些解决方案涵盖了从裸金属到不同操作系统上的云服务提供商。 + + +选择[定制解决方案](/docs/setup/pick-right-solution/#custom-solutions)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +转到完整的解决方案列表选择[正确的解决方案](/docs/setup/pick-right-solution/)。 +{{% /capture %}} + + + + diff --git a/content/zh/docs/setup/certificates.md b/content/zh/docs/setup/certificates.md new file mode 100644 index 0000000000..a9e1239c3d --- /dev/null +++ b/content/zh/docs/setup/certificates.md @@ -0,0 +1,284 @@ +--- +title: PKI 证书和需求 +content_template: templates/concept +--- + + +{{% capture overview %}} + + +Kubernetes 需要 PKI 证书才能通过 TLS 进行身份验证。如果使用 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 安装 Kubernetes,集群所需的证书会被自动生成。 +您还可以生成自己的证书——例如,通过不将私钥保存在 API 服务器上,来更安全地保护它们。。 +此页面说明了集群所需的证书。 + +{{% /capture %}} + +{{% capture body %}} + + +## 集群如何使用证书 + + +Kubernetes 在执行以下操作时需要相应的证书: + + +* 客户端证书,供 kubelet 访问 API 服务器时的身份验证使用 +* API 服务器端点的服务器证书 +* 客户端证书,供集群管理员访问 API 服务器时的身份验证之用 +* API 服务器与 kubelet 通信所需的客户端证书 +* API 服务器与 etcd 通信所需的客户端证书 +* 客户端证书/kubeconfig,供控制器管理器与 API 服务器通信 +* 客户端证书/kubeconfig,供调度器与 API 服务器通信。 +* [front-proxy][proxy] 的客户端和服务器证书 + +{{< note >}} + +仅在您使用 kube-proxy 来支持 [一个扩展 API 服务器](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 时才需要 `front-proxy` 证书。 +{{< /note >}} + + +etcd 还实现了双向 TLS 来验证客户端和对等端。 + + +## 证书在何处存储 + + +如果使用 kubeadm 安装 Kubernetes,证书将存储在 `/etc/kubernetes/pki` 目录中。 本文档中的所有路径,都是与该目录的相对路径。 + + +## 手动配置证书 + + +如果您不希望 kubeadm 生成所需的证书,可以使用以下任一方法创建它们。 + + +单个 root CA + + +您可以创建一个由管理员控制的单个 root CA。然后,此 root CA 可以创建多个中间 CA,并委托 Kubernetes 本身完成后续创建操作。 + + +所需 CA: + +| 路径 | 默认 CN | 描述 | +|------------------------|---------------------------|----------------------------------| +| ca.crt,key | kubernetes-ca | Kubernetes 通用 CA | +| etcd/ca.crt,key | etcd-ca | 所有 etcd 相关操作 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 供 [front-end proxy][proxy] 使用 | + + +### 所有证书 + + +如果您不希望将这些私钥复制到 API 服务器,您可以自己生成所有证书。 + + +所需证书: + +| 默认 CN | 父 CA | O (in Subject) | 种类 | 主机 (SAN) | +|-------------------------------|---------------------------|----------------|----------------------------------------|-----------------------------------------------------| +| kube-etcd | etcd-ca | | server, client [1][etcdbug] | `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-healthcheck-client | etcd-ca | | client | | +| kube-apiserver-etcd-client | etcd-ca | system:masters | client | | +| kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | +| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | +| front-proxy-client | kubernetes-front-proxy-ca | | client | | + +[1]: `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local` + + +`kind` 映射到一个或多个 [x509 key usage][usage] 类型上 + + +| 种类 | 密钥用途 | +|--------|---------------------------------------------------------------------------------| +| server | 数字签名,密钥加密,服务器鉴权 | +| client | 数字签名,密钥加密,客户端鉴权 | + + +### 证书路径 + + +证书应放置在推荐路径 (类似 [kubeadm][kubeadm] 中指定的)。无论位置如何,都应使用给定的参数指定路径。 + +| 默认 CN | 建议密钥路径 | 建议 cert 路径 | 命令 | 密钥参数 | cert 参数 | +|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| +| etcd-ca | | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| etcd-client | apiserver-etcd-client.crt | apiserver-etcd-client.crt | kube-apiserver | --etcd-certfile | --etcd-keyfile | +| kubernetes-ca | | ca.crt | kube-apiserver | --client-ca-file | | +| kube-apiserver | apiserver.crt | apiserver.key | kube-apiserver | --tls-cert-file | --tls-private-key | +| apiserver-kubelet-client | apiserver-kubelet-client.crt | | kube-apiserver | --kubelet-client-certificate | | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-cert-file | --proxy-client-key-file | +| | | | | | | +| etcd-ca | | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | +| kube-etcd | | etcd/server.crt | etcd | | --cert-file | +| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | +| etcd-ca | | etcd/ca.crt | etcdctl[2] | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl[2] | --key | --cert | + + +[2]: 对应自托管时的活跃度检测场景 + + +## 为用户帐户配置证书 + + +您必须手动配置这些管理员帐户和服务帐户: + + +| 文件名 | 凭据名 | 默认 | O (in Subject) | +|-------------------------|----------------------------|--------------------------------|----------------| +| admin.conf | default-admin | kubernetes-admin | system:masters | +| kubelet.conf | default-auth | system:node:`` | system:nodes | +| controller-manager.conf | default-controller-manager | system:kube-controller-manager | | +| scheduler.conf | default-manager | system:kube-scheduler | | + + +1. 对于每个配置,使用给定的 CN 和 O 生成 x509 证书/密钥对。 + +1. 对于每个配置按如下所示执行 `kubectl`: + +```shell +KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs +KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs +KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user +KUBECONFIG= kubectl config use-context default-system +``` + + +这些文件用途如下: + + +| 文件名 | 命令 | 描述 | +|-------------------------|-------------------------|-----------------------------------------------------------------------| +| admin.conf | kubectl | 配置集群的管理员用户 | +| kubelet.conf | kubelet | 集群中的每个节点都需要一个。 | +| controller-manager.conf | kube-controller-manager | 必须添加到清单 `manifests/kube-controller-manager.yaml` 中 | +| scheduler.conf | kube-scheduler | 必须添加到清单 `manifests/kube-scheduler.yaml` 中 | + + +[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage +[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ +[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ + +{{% /capture %}} diff --git a/content/zh/docs/setup/cri.md b/content/zh/docs/setup/cri.md new file mode 100644 index 0000000000..a77476a074 --- /dev/null +++ b/content/zh/docs/setup/cri.md @@ -0,0 +1,471 @@ +--- +title: 安装 CRI +content_template: templates/concept +weight: 100 +--- + + + +{{% capture overview %}} + +从 v1.6.0 开始,Kubernetes 默认启用 CRI(容器运行时接口)。此页面包含各种运行时的安装说明。 +此页面包含各种运行时的安装说明。 + + + +{{% /capture %}} + +{{% capture body %}} + +请以 root 用户在操作系统上执行以下命令。 +SSH 登录到各个主机后,你可以执行 `sudo -i` 成为 root 用户。 + + + +## Docker + + + +在每台机器上安装 Docker + + + +建议使用版本 18.06,但已知 1.11,1.12,1.13 和 17.03 也可以使用。 + + + +跟踪在 Kubernetes 发行说明中最新的已验证 Docker 版本。 + + + +使用以下命令在系统上安装 Docker: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +{{< tabs name="tab-cri-docker-installation" >}} +{{< tab name="Ubuntu 16.04" codelang="bash" >}} + +# 从 Ubuntu 的存储库安装 Docker: +apt-get update +apt-get install -y docker.io + +# 或者从 Docker 的 Ubuntu 或 Debian 镜像仓库中安装 Docker CE 18.06: + +## 安装环境准备。 +apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common + +## 下载 GPG 密钥。 +url -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - + +## 添加 docker apt 镜像仓库。 +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" + +## 安装 docker。 +apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu + +# 设置守护进程。 +cat > /etc/docker/daemon.json <}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} + +# 从 CentOs 镜像仓库安装 Docker: +yum install -y docker + +# 或从 Docker 的 Centos 存储库安装 Docker CE 18.06: + +## 安装环境准备。 +yum install yum-utils device-mapper-persistent-data lvm2 + +## 添加 docker 镜像仓库。 +m-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## 安装 docker。 +yum update && yum install docker-ce-18.06.1.ce + +## 创建 /etc/docker 目录。 +mkdir /etc/docker + +# 设置守护进程。 + +cat > /etc/docker/daemon.json <}} +{{< /tabs >}} + +请参阅 [Docker 官方安装指南](https://docs.docker.com/engine/installation/) +获取更多信息。 + + + +## CRI-O + +本节包含将“CRI-O”安装为 CRI 运行时所需的步骤。 + + + +使用以下命令在系统上安装 CRI-O: + + + +### 环境准备 + + + + + + + + + + + + + + + + + +```shell +modprobe overlay +modprobe br_netfilter + +# 设置需要 sysctl 参数,这些参数在重新引导时仍然存在。 +cat > /etc/sysctl.d/99-kubernetes-cri.conf <}} +{{< tab name="Ubuntu 16.04" codelang="bash" >}} + +# 安装环境准备。 +apt-get update +apt-get install software-properties-common + +add-apt-repository ppa:projectatomic/ppa +apt-get update + +# 安装 CRI-O +apt-get install cri-o-1.11 + +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} + +# 安装环境准备 +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ + +# 安装 CRI-O +apt-get install cri-o-1.11 + +{{< /tab >}} +{{< /tabs >}} + +### 启动 CRI-O + +``` +systemctl start crio +``` + + + +请参阅 [CRI-O 安装指南](https://github.com/kubernets-sigs/cri-o# get -started) +的更多的信息。 + + + +## 容器 + + + +本节包含使用“容器运行时”作为 CRI 运行时所需的步骤。 + + + +使用以下命令在系统上安装容器: + + + +### 环境准备 + + +```shell +modprobe overlay +modprobe br_netfilter + +# 设置需要 sysctl 参数,这些参数在重新引导时仍然存在。 +cat > /etc/sysctl.d/99-kubernetes-cri.conf < /etc/sysctl.d/99-kubernetes-cri.conf < + +{{< tabs name="tab-cri-containerd-installation" >}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} +apt-get install -y libseccomp2 +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +yum install -y libseccomp +{{< /tab >}} +{{< /tabs >}} + + + +### 安装容器运行时 + + + +[容器运行时版本](https://github.com/containerd/containerd/release)定期发布,下面的值被硬编码为编写本文时可用的最新版本。请查看更新的版本和哈希[此处](https://storage.googleapis.com/cri-containerd.release)。 + + + + + + + + + + + + + + + + + +```shell +# 导出所需的环境变量。 +export CONTAINERD_VERSION="1.1.2" +export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" + +# 下载容器 tar 包。 +wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# 哈希校验和检查。 +echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - + +# 解压缩。 +tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# 启动容器。 +systemctl start containerd +``` + +## 其他 CRI 运行时:rktlet 和 frakti + + + +参考 [Frakti 快速入门指南](https://github.com/kubernetes/frakti# QuickStart)和 [Rktlet 入门指南](https://github.com/kubernets-incubator/rktlet/blob/master/docs/getting-startedguide.md)获取更多信息。 + +{{% /capture %}} + + diff --git a/content/zh/docs/setup/custom-cloud/_index.md b/content/zh/docs/setup/custom-cloud/_index.md new file mode 100644 index 0000000000..c9f1706c1b --- /dev/null +++ b/content/zh/docs/setup/custom-cloud/_index.md @@ -0,0 +1,11 @@ +--- +title: 定制的云解决方案 +weight: 50 +--- + + diff --git a/content/zh/docs/setup/custom-cloud/coreos.md b/content/zh/docs/setup/custom-cloud/coreos.md new file mode 100644 index 0000000000..ffbc056ece --- /dev/null +++ b/content/zh/docs/setup/custom-cloud/coreos.md @@ -0,0 +1,209 @@ +--- +title: 在 AWS 或者 GCE 上的 CoreOS +reviewers: +- errordeveloper +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +有很多关于使用 [CoreOS](https://coreos.com/kubernetes/docs/latest/) 运行 Kubernetes 的指南。 + +{{% /capture %}} + +{{% capture body %}} + + + +## CoreOS 官方指南 + + +这些指南由 CoreOS 维护,并以 "CoreOS 方式" 部署 Kubernetes 包括完整的 TLS、DNS 附加组件等等。这些指南通过了 Kubernetes 合规测试,我们鼓励您[自己测试](https://coreos.com/kubernetes/docs/latest/conformance-tests.html) + + +* [**AWS 多节点**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html) + + + 用于在 AWS 上设置多节点群集的指南和 CLI 工具。 + 使用了 CloudFormation 来将一个主节点和多个工作节点配置到一个自动扩缩组中。 + + + +* [**裸金属多节点**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-baremetal.html#automated-provisioning) + + 用于 PXE 引导和配置裸机上的多节点集群的指南和 HTTP/API 服务。 + [Ignition](https://coreos.com/ignition/docs/latest/) 被用来在第一次从磁盘引导时配置一个主节点和多个工作节点。 + + + +* [**Vagrant 多节点**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html) + + 在 Vagrant 上设置多节点集群的指南。 + 部署人员可以独立配置 etcd 节点、主节点和工作节点的数量,从而生成一个完全高可用的控制平面。 + + + +* [**Vagrant 单节点**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html) + + 在本地设置 Kubernetes 开发环境的最快方法。 + 简单到只需 `git clone`、`vagrant up` 和 配置 `kubectl`。 + + +* [**完整的分步指南**](https://coreos.com/kubernetes/docs/latest/getting-started.html) + + 使用完整 TLS 在任何云或裸机上设置 HA 集群的通用指南。 + 重复主节点或工作节点步骤,以配置更多同一角色的机器。 + + + +## 社区指南 + + +这些指南由社区成员维护,涵盖特定平台和用例,并尝试在 CoreOS 上配置 Kubernetes 的不同方法。 + + + +* [**Google Compute Engine 上的轻松多节点集群**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md) + + 在 GCE 上脚本安装单个主节点、多个工作节点集群。 + Kubernetes 组件由 [fleet](https://github.com/coreos/fleet) 管理。 + + + +* [**在 Vagrant 上使用 cloud-config 和 Weave 搭建多节点集群**](https://github.com/errordeveloper/weave-demos/blob/master/poseidon/README.md) + + 使用 Weave 提供的网络配置基于 Vagrant 的 3 台计算机集群。 + + + +* [**使用 cloud-config 和 Vagrant 搭建多节点集群**](https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/README.md) + + 在本地配置单个主节点,多工作节点的集群,在您选择的虚拟机管理程序上运行:VirtualBox、Parallels 或 VMware + + + + +* [**使用一个小型 macOS 应用程序来搭建单节点集群**](https://github.com/rimusz/kube-solo-osx/blob/master/README.md) + + 运行由 macOS 菜单栏应用程序控制的单节点集群(主 + 工作节点)指南。 + 底层使用的是 xhyve + CoreOS。 + + + +* [**使用一个小型 macOS 应用程序并具有 Vagrant 和 fleet 单元搭建多节点集群**](https://github.com/rimusz/coreos-osx-gui-kubernetes-cluster/blob/master/README.md) + + 运行由 macOS 菜单栏应用程序控制的单主节点,多工作节点集群的指南。 + 底层使用的是 Vagrant。 + + + +* [**使用 cloud-config,CoreOS 和 VMware ESXi 搭建多节点群集**](https://github.com/xavierbaude/VMware-coreos-multi-nodes-Kubernetes) + + 在 VMware ESXi 上配置单个主节点,单个工作节点的集群。 + + + +* [**使用 cloud-config,CoreOS 和 Foreman 的单/多节点集群**](https://github.com/johscheuer/theforeman-coreos-kubernetes) + + 使用 [Foreman](https://theforeman.org) 配置独立的 Kubernetes 或 Kubernetes 集群。 + + + +## 支持级别 + + + +IaaS 供应商 | 配置管理 | 操作系统 | 网络 | 文档 | 合规 | 支持级别 +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +GCE | CoreOS | CoreOS | flannel | [文档](/docs/getting-started-guides/coreos) | | 社区 ([@pires](https://github.com/pires)) +Vagrant | CoreOS | CoreOS | flannel | [文档](/docs/getting-started-guides/coreos) | | 社区 ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles)) + + +有关所有解决方案的支持级别信息,请参阅[解决方案表](/docs/getting-started-guides/#table-of-solutions)。 + +{{% /capture %}} diff --git a/content/zh/docs/setup/independent/_index.md b/content/zh/docs/setup/independent/_index.md new file mode 100755 index 0000000000..faa96e1ab0 --- /dev/null +++ b/content/zh/docs/setup/independent/_index.md @@ -0,0 +1,9 @@ +--- +title: "用 kubeadm 创建集群" +weight: 30 +--- + + diff --git a/content/zh/docs/setup/independent/control-plane-flags.md b/content/zh/docs/setup/independent/control-plane-flags.md new file mode 100644 index 0000000000..94b042370f --- /dev/null +++ b/content/zh/docs/setup/independent/control-plane-flags.md @@ -0,0 +1,130 @@ +--- +title: 使用 kubeadm 定制控制平面配置 +content_template: templates/concept +weight: 40 +--- + + + +{{% capture overview %}} + + +kubeadm 配置公开了以下字段,这些字段可以覆盖传递给控制平面组件(如 APIServer、ControllerManager 和 Scheduler)的默认参数: + +- `APIServerExtraArgs` +- `ControllerManagerExtraArgs` +- `SchedulerExtraArgs` + + +这些字段由 `key: value` 对组成。 +要覆盖控制平面组件的参数: + + +1. 将适当的字段添加到配置中。 +2. 向字段添加要覆盖的参数值。 + + +有关配置中的每个字段的详细信息,您可以导航到我们的 [API 参考页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterConfiguration)。 + +{{% /capture %}} + +{{% capture body %}} + + +## APIServer 参数 + + +有关详细信息,请参阅 [kube-apiserver 参考文档](/docs/reference/command-line-tools-reference/kube-apiserver/)。 + + +使用示例: +```yaml +apiVersion: kubeadm.k8s.io/v1alpha3 +kind: ClusterConfiguration +kubernetesVersion: v1.12.0 +metadata: + name: 1.12-sample +apiServerExtraArgs: + advertise-address: 192.168.0.103 + anonymous-auth: false + enable-admission-plugins: AlwaysPullImages,DefaultStorageClass + audit-log-path: /home/johndoe/audit.log +``` + + +## ControllerManager 参数 + + +有关详细信息,请参阅 [kube-controller-manager 参考文档](/docs/reference/command-line-tools-reference/kube-controller-manager/)。 + + +使用示例: +```yaml +apiVersion: kubeadm.k8s.io/v1alpha3 +kind: ClusterConfiguration +kubernetesVersion: v1.12.0 +metadata: + name: 1.12-sample +controllerManagerExtraArgs: + cluster-signing-key-file: /home/johndoe/keys/ca.key + bind-address: 0.0.0.0 + deployment-controller-sync-period: 50 +``` + + +## Scheduler 参数 + + +有关详细信息,请参阅 [kube-scheduler 参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/)。 + + +使用示例: +```yaml +apiVersion: kubeadm.k8s.io/v1alpha3 +kind: ClusterConfiguration +kubernetesVersion: v1.12.0 +metadata: + name: 1.12-sample +schedulerExtraArgs: + address: 0.0.0.0 + config: /home/johndoe/schedconfig.yaml + kubeconfig: /home/johndoe/kubeconfig.yaml +``` + +{{% /capture %}} diff --git a/content/zh/docs/setup/independent/create-cluster-kubeadm.md b/content/zh/docs/setup/independent/create-cluster-kubeadm.md index f35508319f..b8635a319c 100644 --- a/content/zh/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/zh/docs/setup/independent/create-cluster-kubeadm.md @@ -1,5 +1,7 @@ --- -title: 使用 kubeadm 创建一个单主集群 +reviewers: +- sig-cluster-lifecycle +title: 使用 kubeadm 创建只有一个主节点的集群 content_template: templates/task weight: 30 --- @@ -15,13 +17,13 @@ weight: 30 {{% capture overview %}} **kubeadm** 能帮助您建立一个小型的符合最佳实践的 Kubernetes 集群。通过使用 kubeadm, 您的集群会符合 [Kubernetes 合规性测试](https://kubernetes.io/blog/2017/10/software-conformance-certification)的要求. Kubeadm 也支持其他的集群生命周期操作,比如升级、降级和管理[启动引导令牌](/docs/reference/access-authn-authz/bootstrap-tokens/)。 - 因为您可以在不同类型的机器(比如笔记本、服务器和树莓派等)上安装 kubeadm,因此它非常适合与 Terraform 或 Ansible 这类自动化管理系统集成。 @@ -129,7 +131,7 @@ Kubernetes 发现版本的通常只维护支持九个月,在维护周期内, {{% /capture %}} {{% capture prerequisites %}} - ## 步骤 -### 在您的机器上安装 kubeadm +### 在您的机器上安装 kubeadm 请查阅[安装 kubeadm](/docs/setup/independent/install-kubeadm/)。 @@ -198,22 +200,22 @@ communicates with). --> 主节点是集群里运行控制面的机器,包括 etcd (集群的数据库)和 API 服务(kubectl CLI 与之交互)。 - @@ -227,7 +229,7 @@ IPv6 的集群,则需要指定一个 IPv6 地址,比如 `--apiserver-adverti 现在运行: ```bash -kubeadm init +kubeadm init ``` 如果需要再次运行 `kubeadm init`,您必须先[卸载集群](#tear-down)。 @@ -383,8 +385,8 @@ each other. --> kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).** Several projects provide Kubernetes Pod networks using CNI, some of which also -support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons. -- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). +support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons. +- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). - [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. --> **网络必须在部署任何应用之前部署好。此外,在网络安装之前是 CoreDNS 不会启用的。 @@ -527,7 +529,7 @@ kubectl create -f ./ {{% /tab %}} - {{% capture overview %}} - * 一台或多台运行着下列系统的机器: - Ubuntu 16.04+ @@ -49,7 +49,7 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust - HypriotOS v1.0.1+ - Container Linux (针对1800.6.0 版本测试) * 每台机器 2 GB 或更多的 RAM (如果少于这个数字将会影响您应用的运行内存) -* 2 CPU 核心或更多 +* 2 CPU 核心或更多 * 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以) * 节点之中不可以有重复的主机名,MAC 地址,product_uuid。更多详细信息请参见[这里](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) 。 * 开启主机上的一些特定端口. 更多详细信息请参见[这里](#check-required-ports)。 @@ -59,8 +59,8 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust {{% capture steps %}} - ## 确保每个节点上 MAC 地址和 product_uuid 的唯一性。 @@ -71,13 +71,14 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust * 您可以使用下列命令获取网络接口的 MAC 地址:`ip link` 或是 `ifconfig -a` * 下列命令可以用来获取 product_uuid `sudo cat /sys/class/dmi/id/product_uuid` - -一般来讲,硬件设备会拥有独一无二的地址,但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一,可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。 +一般来讲,硬件设备会拥有独一无二的地址,但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。 +如果这些值在集群中不唯一,可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。 -** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。 +** [NodePort 服务](/docs/concepts/services-networking/service/)的默认端口范围。 - 任何使用 * 标记的端口号都有可能被覆盖,所以您需要保证您的自定义端口的状态是开放的。 - 虽然主节点已经包含了 etcd 的端口,您也可以使用自定义的外部 etcd 集群,或是指定自定义端口。 ## 安装 runtime - -从 v1.6.0 起,Kubernetes 开始允许使用 CRI,容器运行时接口。默认的容器运行时是 Docker,这是由 `kubelet` 内置的 CRI 实现 `dockershim` 开启的。 +从 v1.6.0 起,Kubernetes 开始允许使用 CRI,容器运行时接口。 +默认的容器运行时是 Docker,这是由 `kubelet` 内置的 CRI 实现 `dockershim` 开启的。 - 其他的容器运行时有: @@ -171,17 +173,17 @@ Other CRI-based runtimes include: - [frakti](https://github.com/kubernetes/frakti) - [rkt](https://github.com/kubernetes-incubator/rktlet) - -参考 [CRI 安装指南](/docs/setup/cri) 获取更多信息. +参考 [CRI 安装指南](/docs/setup/cri)获取更多信息. ## 安装 kubeadm, kubelet 和 kubectl - 您需要在每台机器上都安装以下的软件包: * `kubeadm`: 用来初始化集群的指令。 - - * `kubelet`: 在集群中的每个节点上用来启动 pod 和 container 等。 - + + * `kubelet`: 在集群中的每个节点上用来启动 pod 和容器等。 + * `kubectl`: 用来与集群通信的命令行工具。 - -kubeadm **不能** 帮您安装或管理 `kubelet` 或 `kubectl` ,所以您得保证他们满足通过 kubeadm 安装的 Kubernetes 控制层对版本的要求。如果版本没有满足要求,就有可能导致一些难以想到的错误或问题。然而控制层与 kubelet 间的 _小版本号_ 不一致无伤大雅,不过请记住 kubelet 的版本不可以超过 API server 的版本。例如 1.8.0 的 API server 可以适配 1.7.0 的 kubelet,反之就不行了。 +kubeadm **不能** 帮您安装或管理 `kubelet` 或 `kubectl` ,所以您得保证他们满足通过 kubeadm 安装的 Kubernetes 控制层对版本的要求。 +如果版本没有满足要求,就有可能导致一些难以想到的错误或问题。 +然而控制层与 kubelet 间的 _小版本号_ 不一致无伤大雅,不过请记住 kubelet 的版本不可以超过 API server 的版本。 +例如 1.8.0 的 API server 可以适配 1.7.0 的 kubelet,反之则不行。 - {{< warning >}} -这些指南不包括所有系统升级时使用的 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 需要 [升级时的特别注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)。 -{{}} +这些指南不包括所有系统升级时使用的 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 需要[升级时的特别注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)。 +{{}} - -更多关于版本偏差的信息,请参阅 [版本偏差政策](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)。 +更多关于版本偏差的信息,请参阅[版本偏差政策](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)。 {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} ```bash apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - @@ -271,12 +276,12 @@ systemctl enable kubelet && systemctl start kubelet **请注意:** - - 通过命令 `setenforce 0` 和 `sed ...` 可以将 SELinux 设置为 permissive 模式(将其禁用)。 只有执行这一操作之后,容器才能访问宿主的文件系统,进而能够正常使用 Pod 网络。您必须这么做,直到 kubelet 做出升级支持 SELinux 为止。 @@ -303,10 +308,10 @@ mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` - -安装 crictl (kubeadm / Kubelet 的容器运行时接口 (CRI) 要求) +安装 crictl (kubeadm / Kubelet 的容器运行时接口 (CRI) 要求) ```bash CRICTL_VERSION="v1.11.1" @@ -314,7 +319,7 @@ mkdir -p /opt/bin curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz ``` - 安装 `kubeadm`, `kubelet`, `kubectl` 并且添加一个 `kubelet` systemd 服务: @@ -332,8 +337,8 @@ mkdir -p /etc/systemd/system/kubelet.service.d curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` - 启用并启动 `kubelet`: @@ -391,19 +396,19 @@ systemctl daemon-reload systemctl restart kubelet ``` - ## 查错 - -如果您在使用 kubeadm 时候遇到问题,请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/). +如果您在使用 kubeadm 时候遇到问题,请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/). {{% capture whatsnext %}} - -* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) +* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) {{% /capture %}} diff --git a/content/zh/docs/setup/independent/setup-ha-etcd-with-kubeadm.md b/content/zh/docs/setup/independent/setup-ha-etcd-with-kubeadm.md new file mode 100644 index 0000000000..664d2d04da --- /dev/null +++ b/content/zh/docs/setup/independent/setup-ha-etcd-with-kubeadm.md @@ -0,0 +1,406 @@ +--- +title: 使用 kubeadm 创建一个高可用 etcd 集群 +content_template: templates/task +weight: 60 +--- + + +{{% capture overview %}} + + +默认情况下,kubeadm 运行单成员的 etcd 集群,该集群由控制面节点上的 kubelet 以静态 Pod 的方式进行管理。由于 etcd 集群只包含一个成员且不能在任一成员不可用时保持运行,所以这不是一种高可用设置。本任务,将告诉您如何在使用 kubeadm 创建一个 kubernetes 集群时创建一个外部 etcd:有三个成员的高可用 etcd 集群。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +* 三个可以通过 2379 和 2380 端口相互通信的主机。本文档使用这些作为默认端口。不过,它们可以通过 kubeadm 的配置文件进行自定义。 + + +* 每个主机必须 [安装有 docker、kubelet 和 kubeadm][工具箱]。 + + +* 一些可以用来在主机间复制文件的基础设施。例如 `ssh` 和 `scp` 就可以满足需求。 + + +[工具箱]: /docs/setup/independent/install-kubeadm/ + +{{% /capture %}} + +{{% capture steps %}} + + +## 建立集群 + + +一般来说,是在一个节点上生成所有证书并且只分发这些*必要*的文件到其它节点上。 + +{{< note >}} + +kubeadm 包含生成下述证书所需的所有必要的密码学工具;在这个例子中,不需要其他加密工具。 +{{< /note >}} + + +1. 将 kubelet 配置为 etcd 的服务管理器。 + + 运行 etcd 比运行 kubernetes 更简单,因此您必须通过创建具有更高优先级的新文件来覆盖 kubeadm 提供的 kubelet 单元文件。 + + ```sh + cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf + [Service] + ExecStart= + ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true + Restart=always + EOF + + systemctl daemon-reload + systemctl restart kubelet + ``` + + + +1. 为 kubeadm 创建配置文件。 + + 使用以下脚本为每个将要运行 etcd 成员的主机生成一个 kubeadm 配置文件。 + + + ```sh + # 使用 IP 或可解析的主机名替换 HOST0、HOST1 和 HOST2 + export HOST0=10.0.0.6 + export HOST1=10.0.0.7 + export HOST2=10.0.0.8 + + # 创建临时目录来存储将被分发到其它主机上的文件 + mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/ + + ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2}) + NAMES=("infra0" "infra1" "infra2") + + for i in "${!ETCDHOSTS[@]}"; do + HOST=${ETCDHOSTS[$i]} + NAME=${NAMES[$i]} + cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml + apiVersion: "kubeadm.k8s.io/v1alpha3" + kind: ClusterConfiguration + etcd: + local: + serverCertSANs: + - "${HOST}" + peerCertSANs: + - "${HOST}" + extraArgs: + initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380 + initial-cluster-state: new + name: ${NAME} + listen-peer-urls: https://${HOST}:2380 + listen-client-urls: https://${HOST}:2379 + advertise-client-urls: https://${HOST}:2379 + initial-advertise-peer-urls: https://${HOST}:2380 + EOF + done + ``` + + +1. 生成证书颁发机构 + + 如果您已经拥有 CA,那么唯一的操作是复制 CA 的 `crt` 和 `key` 文件到 `etc/kubernetes/pki/etcd/ca.crt` 和 `/etc/kubernetes/pki/etcd/ca.key`。复制完这些文件后继续下一步,“为每个成员创建证书”。 + + + 如果您还没有 CA,则在 `$HOST0`(您为 kubeadm 生成配置文件的位置)上运行此命令。 + + ``` + kubeadm alpha phase certs etcd-ca + ``` + + + 创建了如下两个文件 + + - `/etc/kubernetes/pki/etcd/ca.crt` + - `/etc/kubernetes/pki/etcd/ca.key` + + +1. 为每个成员创建证书 + + + ```sh + kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + cp -R /etc/kubernetes/pki /tmp/${HOST2}/ + # 清理不可重复使用的证书 + find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete + + kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + cp -R /etc/kubernetes/pki /tmp/${HOST1}/ + find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete + + kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + # 不需要移动 certs 因为它们是给 HOST0 使用的 + + # 清理不应从此主机复制的证书 + find /tmp/${HOST2} -name ca.key -type f -delete + find /tmp/${HOST1} -name ca.key -type f -delete + ``` + + +1. 复制证书和 kubeadm 配置 + + 证书已生成,现在必须将它们移动到对应的主机。 + + ```sh + USER=ubuntu + HOST=${HOST1} + scp -r /tmp/${HOST}/* ${USER}@${HOST}: + ssh ${USER}@${HOST} + USER@HOST $ sudo -Es + root@HOST $ chown -R root:root pki + root@HOST $ mv pki /etc/kubernetes/ + ``` + + +1. 确保已经所有预期的文件都存在 + + `$HOST0` 所需文件的完整列表如下: + + ``` + /tmp/${HOST0} + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── ca.key + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + + + 在 `$HOST1`: + + ``` + $HOME + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + + + 在 `$HOST2` + + ``` + $HOME + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + + +1. 创建静态 Pod 清单 + + 既然证书和配置已经就绪,是时候去创建清单了。在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。 + + ```sh + root@HOST0 $ kubeadm alpha phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml + root@HOST1 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST2 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + ``` + + +1. 可选:检查群集运行状况 + + ```sh + docker run --rm -it \ + --net host \ + -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:v3.2.18 etcdctl \ + --cert-file /etc/kubernetes/pki/etcd/peer.crt \ + --key-file /etc/kubernetes/pki/etcd/peer.key \ + --ca-file /etc/kubernetes/pki/etcd/ca.crt \ + --endpoints https://${HOST0}:2379 cluster-health + ... + cluster is healthy + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + +一旦拥有了一个正常工作的 3 成员的 etcd 集群,你就可以基于[使用 kubeadm 的外部 etcd 方法](/docs/setup/independent/high-availability/),继续部署一个高可用的控制平面。 + +{{% /capture %}} + diff --git a/content/zh/docs/setup/node-conformance.md b/content/zh/docs/setup/node-conformance.md new file mode 100644 index 0000000000..420da8746f --- /dev/null +++ b/content/zh/docs/setup/node-conformance.md @@ -0,0 +1,178 @@ +--- +reviewers: +- Random-Liu +title: 验证节点设置 +--- + + + +{{< toc >}} + + +## 节点合规性测试 + + +*节点合规性测试* 是一种容器化测试框架,为节点提供系统验证和功能测试。该测试验证节点是否满足 Kubernetes 的最低要求;通过测试的节点有资格加入 Kubernetes 集群。 + + +## 限制 + + +在 Kubernetes 1.5 版中,节点合规性测试具有以下限制: + +* 节点合规性测试仅支持 Docker 作为容器运行时。 + + +## 节点先决条件 + + +要运行节点合规性测试,节点必须满足与标准 Kubernetes 节点相同的先决条件。该节点至少应安装以下守护程序: + +* 容器运行时(Docker) +* Kubelet + + +## 运行节点合规性测试 + + + +要运行节点合规性测试,请执行以下步骤: + +1. 将您的 Kubelet 指向 localhost `--api-servers="http://localhost:8080"`,因为测试框架启动了一个本地主服务器来测试 Kubelet。您可能会关注其他一些 Kubelet 标记: + * `--pod-cidr`: 如果你使用 `kubenet`,你应该为 Kubelet 指定一个任意的 CIDR,例如 `--pod-cidr=10.180.0.0/24`。 + * `--cloud-provider`: 如果您使用`--cloud-provider = gce`,则应删除该标志以运行测试。 + +2. 使用以下命令运行节点合规性测试: + +```shell +# $CONFIG_DIR is the pod manifest path of your Kubelet. +# $LOG_DIR is the test output path. +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + k8s.gcr.io/node-test:0.2 +``` + + +## 为其他架构运行节点合规性测试 + + +Kubernetes 还为其他架构提供节点合规性测试 docker 镜像: + + Arch | Image | +--------|:-----------------:| + amd64 | node-test-amd64 | + arm | node-test-arm | + arm64 | node-test-arm64 | + + +## 运行选定的测试 + + +要运行特定测试,请使用要运行的测试的正则表达式覆盖环境变量 `FOCUS`。 + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e FOCUS=MirrorPod \ # Only run MirrorPod test + k8s.gcr.io/node-test:0.2 +``` + + +要跳过特定测试,请使用要跳过的测试的正则表达式覆盖环境变量 `SKIP`。 + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + k8s.gcr.io/node-test:0.2 +``` + + +节点合规性测试是[节点 e2e 测试](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md)的容器化版本。默认情况下,它会运行所有一致性测试。 + + +从理论上讲,如果配置容器并正确安装所需的卷,则可以运行任何节点 e2e 测试。 但**强烈建议仅运行一致性测试**,因为它需要更复杂的配置来运行不一致性测试。 + + +## 注意事项 + + +* 测试在节点上留下一些 docker 镜像,包括节点合规性测试镜像和功能测试中使用的容器镜像。 +* 测试在节点上留下了死容器。 这些容器是在功能测试期间创建的。 diff --git a/content/zh/docs/setup/on-premises-metal/krib.md b/content/zh/docs/setup/on-premises-metal/krib.md new file mode 100644 index 0000000000..3ba60c2f75 --- /dev/null +++ b/content/zh/docs/setup/on-premises-metal/krib.md @@ -0,0 +1,205 @@ + +--- +title: 通过 KRIB 安装带有 Digital Rebar Provision(DRP)的 Kubernetes +krib-version: 2.4 +author: Rob Hirschfeld (zehicle) +--- + + +## 概览 + + +本指南帮助使用 [Digital Rebar Provision](https://github.com/digitalrebar/provision) 安装在裸机上托管的 Kubernetes 集群,且仅使用其内容包和 *kubeadm* 。 + + +Digital Rebar Provision(DRP)是一个集成的 Golang DHCP、裸机配置(PXE/iPXE)和工作流自动化平台。 虽然 [DRP 可用于调用](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](../kubespray),但它还提供了一个独立的 Kubernetes 安装,称为 [KRIB(Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib)。 + +{{< note >}} + +KRIB 不是一个 _独立的_ 安装程序:Digital Rebar 模板驱动一个标准的 *[kubeadm](/docs/admin/kubeadm/)* 配置,使用 [Digital Rebar 集群模式](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) 管理 Kubernetes 安装,_在没有外部监督的情况下_ 选举领导者。 +{{< /note >}} + + +KRIB特点: + +* 零接触,无需预配置或组件目录的自配置集群 +* 非常快,无需 ssh 的自动化 +* 关注裸机和本地部署的平台 +* 高度可用的集群选项(包括将 etcd 从控制节点分离) +* 动态生成 TLS 基础架构 +* 可组合属性和按配置文件自动检测硬件 +* 支持基于持久存储、不可变存储和映像的部署 +* 支持 Ubuntu 18.04、CentOS/RHEL 7 等 + + +## 创建集群 + + +有关安装该平台的详细信息,请查看 [Digital Rebar 文档](https://https://provision.readthedocs.io/en/tip/README.html)。 + + +Digital Rebar Provision Golang 二进制文件应该安装在类似 Linux 的系统上,内存为 16 GB 或更大(Packet.net Tiny 和 Rasberry Pi 也可以接受)。 + + +### (1/5) 发现服务器 + + +按 [Digital Rebar 安装](https://provision.readthedocs.io/en/tip/doc/quickstart.html) 文档所给的步骤执行安装,允许一个或多个服务器通过 _Sledgehammer_ 发现过程引导以向 API 注册。 这将自动安装 Digital Rebar runner 并允许后续步骤。 + + +### (2/5) 安装 KRIB 内容和证书插件 + + +上传与您的 DRP 平台匹配的 KRIB 软件包(或从[源代码](https://github.com/digitalrebar/provision-content/tree/master/krib)构建)和 Cert 插件(例如:[amd64 Linux v2.4.0](https://s3-us-west-2.amazonaws.com/rebar-catalog/certs/v2.4.0-0-02301d35f9f664d6c81d904c92a9c81d3fd41d2c/amd64/linux/certs))。两者都可以通过 [RackN UX](https://portal.rackn.io) 免费获得。 + + +### (3/5) 启动集群部署 + + +{{< note >}} +KRIB 文档是从源代码动态生成的,并且将比本指南更新。 +{{< /note >}} + + +遵循 [KRIB 文档](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html),为您的集群创建配置文件,并将目标服务器分配到集群配置文件中。 配置文件必须将 `krib\cluster-name` 和 `etcd\cluster-name` 参数(Params)设置为配置文件的名称。 可以通过向配置文件添加其他参数来进行集群配置选择; 不过所有参数都有安全的默认值。 + + +将所有目标服务器分配给集群配置文件后,通过将所包含的工作流程之一分配给所有集群服务器来启动 KRIB 安装工作流程。 例如,选择 `krib-live-cluster` 将在 Sledgehammer 所发现的操作系统中执行不可变的部署。您可以使用其中一个预先创建的只读工作流,也可以选择构建自己的自定义变体。 + + +对于一般安装,无需进一步操作。高级用户可以选择在相关参数中设定控制器、etcd 服务器或其他配置值。 + + +### (4/5) 监控集群部署 + + +Digital Rebar Provision 在安装过程中提供详细的日志记录和实时更新。通过 websocket 连接或监视作业列表可以获得工作流事件。 + +在安装过程中,KRIB 将集群配置数据写回集群配置文件。 + + +### (5/5) 访问您的集群 + + +一旦设置了 `krib/cluster-admin-conf` 参数,就可以通过 *kubectl* 访问集群。 该参数包含访问集群所需的 `kubeconfig` 信息。 + +例如,如果您将集群配置文件命名为 `krib`,则以下命令将允许您从本地终端连接到已安装的集群。 + + :: + + drpcli profiles get krib params krib/cluster-admin-conf > admin.conf + export KUBECONFIG=admin.conf + kubectl get nodes + + +在 `krib/cluster-admin-conf` 设置为安装 Kubernetes UI 和 Helm 后,安装继续。只要 `admin.conf` 文件可用,您就可以与集群进行交互。 + + +## 集群操作 + + +KRIB 提供额外的工作流来管理您的集群。有关高级集群操作的更新列表,请参阅 [KRIB 文档](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)。 + + +### 扩展您的集群 + + +您可以通过将集群配置文件添加到服务器并运行相应的工作流来将服务器添加到集群中。 + + +### 清理集群(面向开发人员) + + +您可以使用集群中任何服务器上的 `krib-reset-cluster` 工作流重置您的集群并清除所有配置和 TLS 证书。 + + +{{< caution >}} +运行重置工作流程时,请小心不要指向生产集群! +{{< /caution >}} + + +## 反馈 + + +* Slack Channel:[#community](https://rackn.slack.com/messages/community/) +* [GitHub 问题](https://github.com/digital/provision/issues) diff --git a/content/zh/docs/setup/on-premises-vm/_index.md b/content/zh/docs/setup/on-premises-vm/_index.md new file mode 100644 index 0000000000..9663db39ec --- /dev/null +++ b/content/zh/docs/setup/on-premises-vm/_index.md @@ -0,0 +1,11 @@ +--- +title: 本地部署的虚拟机(On-Premises VMs) +weight: 60 +--- + + diff --git a/content/zh/docs/setup/on-premises-vm/cloudstack.md b/content/zh/docs/setup/on-premises-vm/cloudstack.md new file mode 100644 index 0000000000..a6ef64fef3 --- /dev/null +++ b/content/zh/docs/setup/on-premises-vm/cloudstack.md @@ -0,0 +1,213 @@ +--- +reviewers: +- thockin +title: Cloudstack +content_template: templates/concept +--- + + + + +{{% capture overview %}} + + + +[CloudStack](https://cloudstack.apache.org/) 是一种基于硬件虚拟化原则(传统 IaaS 概念)用来构建公有云和私有云的软件。要在 CloudStack 上部署 Kubernetes, +有几种可能性取决于正在使用的云以及可用的镜像。CloudStack 还提供了一个 vagrant 插件,因此 vagrant 可以使用现有的 shell 创建程序,或新的基于 Salt 的方法来部署 Kubernetes。 + + +CloudStack 的 [CoreOS](http://coreos.com) 模板会[每夜](http://stable.release.core-os.net/amd64-usr/current/)构建。 +CloudStack operators 需要在他们的云中 [注册](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html)这个模板,然后才能继续执行 Kubernetes 部署的命令。 + + + +本指南只用到一个 [Ansible playbook](https://github.com/apachecloudstack/k8s),完全自动化,可以使用 CoreOS 镜像在基于 CloudStack 的云上部署 Kubernetes。playbook 会创建 ssh 密钥对、创建安全组和相关规则,最后启动通过 cloud-init 配置的 CoreOS 实例。 + +{{% /capture %}} + +{{% capture body %}} + + + +## 先决条件 + +```shell +sudo apt-get install -y python-pip libssl-dev +sudo pip install cs +sudo pip install sshpubkeys +sudo apt-get install software-properties-common +sudo apt-add-repository ppa:ansible/ansible +sudo apt-get update +sudo apt-get install ansible +``` + + +在 CloudStack 服务器上,您还必须安装 libselinux-python: + +```shell +yum install libselinux-python +``` + + +[_cs_](https://github.com/exoscale/cs) 是 CloudStack API 的 python 模块。 + + +设置所使用的 CloudStack 端点、API 键和 HTTP 方法。 + + +你可以将它们定义为环境变量:`CLOUDSTACK_ENDPOINT`、`CLOUDSTACK_KEY`、`CLOUDSTACK_SECRET` 和 `CLOUDSTACK_METHOD`。 + + +或者创建一个 `~/.cloudstack.ini` 文件: + +```none +[cloudstack] +endpoint = +key = +secret = +method = post +``` + + +我们需要使用 http POST 方法将 _large_ userdata 传递给 coreOS 实例。 + + + +### 复制 playbook + +```shell +git clone https://github.com/apachecloudstack/k8s +cd kubernetes-cloudstack +``` + + + +### 创建一个 Kubernetes 集群 + + +你只需要运行 playbook 即可。 + +```shell +ansible-playbook k8s.yml +``` + + +可以在 `k8s.yml` 文件中编辑某些变量。 + +```none +vars: + ssh_key: k8s + k8s_num_nodes: 2 + k8s_security_group_name: k8s + k8s_node_prefix: k8s2 + k8s_template: + k8s_instance_type: +``` + + +这将启动一个 Kubernetes 主节点和一些计算节点(默认情况下为 2)。 +`instance_type` 和`模板`是特定的,编辑它们可以指定特定于 CloudStack 云的模板和实例类型(即服务提供)。 + + +如果您想修改任何内容,请检查 `roles/k8s` 中的任务和模板。 + + +一旦副本完成,它将打印出 Kubernetes 主节点的IP: + +```none +TASK: [k8s | debug msg='k8s master IP is {{ k8s_master.default_ip }}'] ******** +``` + + +使用创建的密钥和 _core_ 用户 SSH 到它。 + +```shell +ssh -i ~/.ssh/id_rsa_k8s core@ +``` + + +您可以列出群集中的计算机: + +```shell +fleetctl list-machines +``` + +```none +MACHINE IP METADATA +a017c422... role=node +ad13bf84... role=master +e9af8293... role=node +``` + + + +## 支持级别 + + + +IaaS 供应商 | 配置管理 | 操作系统 | 网络 | 文档 | 合规 | 支持级别 +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +CloudStack | Ansible | CoreOS | flannel | [文档](/docs/setup/on-premises-vm/cloudstack/) | | 社区 ([@Guiques](https://github.com/ltupin/)) + + + +有关所有解决方案的支持级别信息,请查看[解决方案](/docs/setup/pick-right-solution/# Table -of-solutions)图表。 + +{{% /capture %}} diff --git a/content/zh/docs/setup/on-premises-vm/dcos.md b/content/zh/docs/setup/on-premises-vm/dcos.md new file mode 100644 index 0000000000..19beb1f7a5 --- /dev/null +++ b/content/zh/docs/setup/on-premises-vm/dcos.md @@ -0,0 +1,48 @@ +--- +title: 在 DC/OS 上运行 Kubernetes +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +Mesosphere 提供了一个将 Kubernetes 加入 [DC/OS](https://mesosphere.com/product/) 的简易选项,提供: + + + +* 纯粹的上游 Kubernetes +* 一键集群供应 +* 默认的高可用和安全保障 +* Kubernetes 与快速数据处理平台一起运行(例如 Akka、Cassandra、Kafka、Spark) + +{{% /capture %}} + +{{% capture body %}} + + +## Mesosphere 官方指南 + + +开始使用 DC/OS 的权威指南位于 [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart)。 + +{{% /capture %}} diff --git a/content/zh/docs/setup/release/_index.md b/content/zh/docs/setup/release/_index.md new file mode 100644 index 0000000000..93f01fa8d4 --- /dev/null +++ b/content/zh/docs/setup/release/_index.md @@ -0,0 +1,11 @@ +--- +title: "下载 Kubernetes" +weight: 20 +--- + + diff --git a/content/zh/docs/setup/release/building-from-source.md b/content/zh/docs/setup/release/building-from-source.md new file mode 100644 index 0000000000..3d66b049e3 --- /dev/null +++ b/content/zh/docs/setup/release/building-from-source.md @@ -0,0 +1,53 @@ +--- +title: 从源代码构建 +--- + + + +您可以从源代码构建发行包,也可以下载预构建的发行包。 + + +如果您不打算开发 Kubernetes 本身,我们建议您使用当前发行包的预构建版本,该版本可以在[发行说明](/docs/setup/release/notes/)中找到。 + + +Kubernetes 源代码可以从 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库下载。 + + +## 从源代码构建 + + +如果您只是简单地想从源代码构建一个发行包,则不需要设置完整的 golang 环境,因为所有构建过程都发生在 Docker 容器中。 + + +构建一个发行包很简单。 + + +```shell +git clone https://github.com/kubernetes/kubernetes.git +cd kubernetes +make release +``` + +有关发布过程的更多细节,请参见 kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) 目录。 + diff --git a/content/zh/docs/setup/salt.md b/content/zh/docs/setup/salt.md index aa5ef2a87d..98d49d5dba 100755 --- a/content/zh/docs/setup/salt.md +++ b/content/zh/docs/setup/salt.md @@ -148,52 +148,31 @@ The following enumerates the set of defined key/value pairs that are supported t 键 | 值 -----------------------------------|---------------------------------------------------------------- - `api_servers` | (可选) IP 地址/主机名 ,kubelet 用其访问 kube-apiserver - `cbr-cidr` | (可选) docker 容器网桥分配给 minion 节点的 IP 地址范围 - `cloud` | (可选) 托管 Kubernetes 的 IaaS 平台, *gce*, *azure*, *aws*, *vagrant* - `etcd_servers` | (可选) 以逗号分隔的 IP 地址列表,kube-apiserver 和 kubelet 使用其访问 etcd。kubernetes_master 角色的节点使用第一个机器的 IP ,在 GCE 环境上使用 127.0.0.1。 - `hostnamef` | (可选) 机器的完整主机名,即:uname -n - `node_ip` | (可选)用于定位本节点的 IP 地址 - `hostname_override` | (可选)对应 kubelet 的 hostname-override 参数 - `network_mode` | (可选)节点间使用的网络模型:*openvswitch* - `networkInterfaceName` | (可选)用于绑定地址的网络接口,默认值 *eth0* - `publicAddressOverride` | (可选)kube-apiserver 用于外部只读访问而绑定的IP地址 - `roles` | (必选)1、`kubernetes-master` 表示本节点是 Kubernetes 集群的 master。2、`kubernetes-pool` 表示本节点是一个 kubernetes-node。根据角色,Salt 脚本会在机器上提供不同的资源 diff --git a/content/zh/docs/setup/turnkey/alibaba-cloud.md b/content/zh/docs/setup/turnkey/alibaba-cloud.md new file mode 100644 index 0000000000..f568c239ce --- /dev/null +++ b/content/zh/docs/setup/turnkey/alibaba-cloud.md @@ -0,0 +1,53 @@ +--- +title: 在阿里云上运行 Kubernetes +--- + + + +## 阿里云容器服务 + + +[阿里云容器服务](https://www.aliyun.com/product/containerservice)允许您在阿里云 ECS 实例集群上运行和管理 Docker 应用程序。 +它支持流行的开源容器编排框架:Docker Swarm 和 Kubernetes。 + + +为了简化集群部署和管理,您可以使用[阿里云容器服务的 Kubernetes 支持](https://www.aliyun.com/solution/kubernetes/)。 + + +您可以通过 [Kubernetes 演练](https://help.aliyun.com/document_detail/53751.html) 快速入门, +这里还有一些中文版的[阿里云 Kubernetes 支持教程](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)。 + + +要使用自定义二进制文件或开源 Kubernetes,请遵循下面的说明。 + + +## 自定义部署 + + +[阿里云提供的 Kubernetes 实现](https://github.com/AliyunContainerService/kubernetes)是开源的,您可以在 GitHub 上找到。 + + +更多信息,请参见英文版“[快速部署 Kubernetes - 阿里云 VPC 环境](https://www.alibabacloud.com/forum/read-830)”以及[中文版](https://yq.aliyun.com/articles/66474)。 diff --git a/content/zh/docs/setup/turnkey/aws.md b/content/zh/docs/setup/turnkey/aws.md new file mode 100644 index 0000000000..3feceb2ad6 --- /dev/null +++ b/content/zh/docs/setup/turnkey/aws.md @@ -0,0 +1,191 @@ +--- +reviewers: +- justinsb +- clove +title: 在 AWS EC2 上运行 Kubernetes +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本页介绍如何在 AWS 上安装 Kubernetes 集群。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +要在 AWS 上创建 Kubernetes 集群,您需要一个访问密钥 ID 和一个来自 AWS 的 Secret 访问密钥。 + + + +### 支持的生产等级工具 + + + +* [conjure-up](/docs/getting-started-guides/ubuntu/) 是 Kubernetes 的一个开源安装程序,可以在 Ubuntu 上创建本机 AWS 集成的 Kubernetes 集群。 + \ +* [Kubernetes 操作](https://github.com/kubernetes/kops) - 生产级 K8s 安装、升级和管理。支持在 AWS 中运行 Debian、Ubuntu、CentOS 和 RHEL。 + +* [CoreOS 结构](https://coreos.com/tectonic/)包括开源[结构](https://github.com/coreos/tectonic-installer),它在 AWS 上创建带有 Linux 容器节点的 Kubernetes 集群。 + +* CoreOS 起源于 Kubernetes 孵化器,Kubernetes 孵化器维护 [一个 CLI 工具 kube-aws](https://github.com/kubernetes-incubator/kube-aws),它使用 AWS 工具:EC2、CloudFormation 和 Autoscaling 创建和管理 [Linux 容器](https://coreos.com/why/)节点的 Kubernetes 集群。 + + +{{% /capture %}} + +{{% capture steps %}} + + + +## 开始您的集群 + + + +### 命令行管理工具:kubectl + + +集群启动脚本将在您的工作站上留下一个 `kubernetes` 目录。 +或者,您可以从[这个页面](https://github.com/kubernetes/kubernetes/releases)下载最新的 Kubernetes 版本。 + + +接下来,将相应的二进制文件夹添加到您的 `PATH` 中访问 kubectl: + +```shell +# macOS +export PATH=/platforms/darwin/amd64:$PATH + +# Linux +export PATH=/platforms/linux/amd64:$PATH +``` + + +这个工具的最新文档页面可以在这里找到:[kubectl 手册](/docs/user-guide/kubectl/) + + +默认情况下,`kubectl` 将使用集群启动期间生成的 `kubeconfig` 文件对 API 进行身份验证。 +更多信息,请阅读 [kubeconfig 文件](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) + + + +### 例子 + + +查看一个[简单的 nginx 示例](/docs/tasks/run-application/run-stateless-application-deployment/)来试用您的新集群。 + + +"留言板"应用程序是 Kubernetes 的另一个流行示例:[留言板示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) + + +有关更完整的应用程序,请查看[示例目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) + + + +## 扩展集群 + + +`kubectl` 不支持添加和删除节点。您仍然可以通过[自动扩缩功能组](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scale.html) 中的 `Desired` 和 `Max` 属性手动调整节点的数量,该属性是在安装过程中创建的。 + + + +## 拆除集群 + + +确保用于提供集群的环境变量已经导出,然后在 `kubernetes` 目录中调用以下脚本: + +```shell +cluster/kube-down.sh +``` + + + +## 支持级别 + + + + +IaaS 供应商 | 配置管理 | 操作系统 | 网络 | 文档 | 合规 | 支持级别 +-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ---------------------------- +AWS | kops | Debian | k8s (VPC) | [文档](https://github.com/kubernetes/kops) | | 社区 ([@justinsb](https://github.com/justinsb)) +AWS | CoreOS | CoreOS | flannel | [文档](/docs/getting-started-guides/aws) | | 社区 +AWS | Juju | Ubuntu | flannel, calico, canal | [文档](/docs/getting-started-guides/ubuntu) | 100% | 商业、社区 + + +有关所有解决方案的支持级别信息,请查看[解决方案表](/docs/getting-started-guides/#table-of-solutions)。 + + + +## 进一步阅读 + + +有关管理和使用 Kubernetes 集群的详细信息,请参阅 [Kubernetes 文档](/docs/)。 + + +{{% /capture %}} diff --git a/content/zh/docs/setup/turnkey/azure.md b/content/zh/docs/setup/turnkey/azure.md new file mode 100644 index 0000000000..7d010d7003 --- /dev/null +++ b/content/zh/docs/setup/turnkey/azure.md @@ -0,0 +1,87 @@ +--- +reviewers: +- colemickens +- brendandburns +title: 在 Azure 上运行 Kubernetes +--- + + + + +## Azure Kubernetes Service (AKS) + + +[Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) 为 Kubernetes 集群提供简单的部署。 + + +通过 Azure Kubernetes Service 将 Kubernetes 集群部署到 Azure 的示例: + + +**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)** + + +## 自定义部署:ACS-Engine + + +Azure Kubernetes 服务的核心是 **开源的** ,可在 GitHub 上获取,供社区使用和贡献:**[ACS-Engine](https://github.com/Azure/acs-engine)**。 + + +如果您需要对 Azure Kubernetes Service 官方支持的部署进行自定义,ACS-Engine 是一个不错的选择。 这些自定义包括部署到现有网络虚拟,使用多个代理池等。一些社区对 ACS-Engine 的贡献甚至可能成为 Azure Kubernetes Service 的功能。 + + +导入 ACS-Engine 类似于用于直接使用 Azure Kubernetes Service 部署集群的 ARM 模板语法。 +结果导出是 Azure 资源管理器模板,然后可以将其检入源控件,然后可以用于将 Kubernetes 集群部署到 Azure 中。 + + +您可以按照 **[ACS-Engine Kubernetes 演练](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.md)** 快速入门。 + + +## Azure 上使用 CoreOS Tectonic + + +在 Azure 上安装 CoreOS Tectonic 的程序是 **开源的** ,可在 GitHub 上获取,供社区使用和贡献:**[Tectonic Installer](https://github.com/coreos/tectonic-installer)**。 + + +当您需要进行集群自定义时,Tectonic Installer 是一个不错的选择,因为它是基于 [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure 资源管理器(ARM)提供程序构建的。这使用户能够使用熟悉的 Terraform 工具进行自定义或集成。 + + +您可以开始使用 [在 Azure 上安装 Tectonic 指南](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html)。 diff --git a/content/zh/docs/tasks/_index.md b/content/zh/docs/tasks/_index.md new file mode 100644 index 0000000000..0be5747945 --- /dev/null +++ b/content/zh/docs/tasks/_index.md @@ -0,0 +1,191 @@ +--- +title: 任务 +main_menu: true +weight: 50 +content_template: templates/concept +--- + + +{{< toc >}} + +{{% capture overview %}} + +Kubernetes 文档这一部分包含的一些页面展示如何去做单个任务。一个任务页面展示了如何执行操作单一的项目,通常是通过给出若干步骤。 + + +{{% /capture %}} + +{{% capture body %}} + +## Web 用户界面 (Dashboard) + +部署和访问 Dashboard Web 用户界面,以帮助您管理和监控 Kubernetes 集群中的容器化应用程序。 + + + +## 使用 kubectl 命令行 + +下载并设置用于直接管理 Kubernetes 集群的 kubectl 命令行工具。 + + + +## 配置 Pod 和容器 + +执行 Pod 和容器的常见配置任务。 + + + +## 运行应用程序 + +执行常见的应用程序管理任务,例如滚动更新、将信息注入 Pod、以及 Pod 水平自动伸缩。 + + + +## 运行 Job + +使用并行处理方式运行 Job。 + + + +## 访问集群中的应用程序 + +配置负载均衡和端口转发、或者设置防火墙、或者配置 DNS 以访问集群中的应用程序。 + + + +## 监控、日志记录和调试 + +设置监控和日志记录以对集群进行故障排除或者调试容器化应用程序。 + + + +## 访问 Kubernetes API + +了解直接访问 Kubernetes API 的各种方法。 + + + +## 使用 TLS + +配置您的应用程序去信任和使用集群的根证书机构( CA )。 + + + +## 管理集群 + +了解管理集群的常见任务。 + + + +## 管理联邦 + +配置集群联邦中的组件。 + + + +## 管理状态应用程序 + +执行管理有状态应用程序的常见任务,包括扩展、删除和调试 StatefulSets。 + + + +## 集群 Daemons + +执行管理 DaemonSet 的常见任务,例如执行滚动更新。 + + + +## 管理 GPU + +配置和调度 NVIDIA GPU 作为集群中节点使用的资源。 + + + +## 管理 HugePage + +配置和调度 HugePage 作为集群中的可调度资源。 + + + +{{% /capture %}} + +{{% capture whatsnext %}} + +如果您想编写任务页面,请参阅[创建文档提取请求](/docs/home/contribute/create-pull-request/)。 + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/access-application-cluster/_index.md b/content/zh/docs/tasks/access-application-cluster/_index.md new file mode 100644 index 0000000000..8436005bc0 --- /dev/null +++ b/content/zh/docs/tasks/access-application-cluster/_index.md @@ -0,0 +1,11 @@ +--- +title: 访问集群中的应用程序 +weight: 60 +--- + + diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md index 10b68fbed3..09c045b4fd 100644 --- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md @@ -1,15 +1,16 @@ - ---- -title: 访问集群 -weight: 20 -content_template: templates/concept ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md index 48cc0a019a..14d691387d 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -1,3 +1,9 @@ +--- +title: 为集群配置 DNS +weight: 120 +content_template: templates/concept +--- + ---- -title: 为集群配置 DNS -weight: 120 -content_template: templates/concept ---- {{% capture overview %}} ---- -title: 创建一个外部负载均衡器 -content_template: templates/task -weight: 80 ---- - {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md index fb3850c3b0..6e1b8ffde7 100644 --- a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -1,3 +1,9 @@ +--- +title: 列出集群中所有运行容器的镜像 +content_template: templates/task +weight: 100 +--- + ---- -title: 列出集群中所有运行容器的镜像 -content_template: templates/task -weight: 100 ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md index b653c5aecb..6256f3b2d1 100644 --- a/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md @@ -1,3 +1,9 @@ +--- +title: 提供对集群中应用程序的负载均衡访问 +content_template: templates/tutorial +weight: 50 +--- + ---- -title: 提供对集群中应用程序的负载均衡访问 -content_template: templates/tutorial -weight: 50 ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index 13eb4b1f49..5bbcead46d 100644 --- a/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -1,3 +1,9 @@ +--- +title: 使用端口转发来访问集群中的应用 +content_template: templates/task +weight: 40 +--- + ---- -title: 使用端口转发来访问集群中的应用 -content_template: templates/task -weight: 40 ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md index 908280e29d..92283bc070 100644 --- a/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -1,3 +1,9 @@ +--- +title: 使用服务来访问集群中的应用 +content_template: templates/tutorial +weight: 60 +--- + ---- -title: 使用服务来访问集群中的应用 -content_template: templates/tutorial -weight: 60 ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md new file mode 100644 index 0000000000..cc2b73b3a3 --- /dev/null +++ b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -0,0 +1,366 @@ +--- +reviewers: +- bryk +- mikedanese +- rf232 +title: Web UI (Dashboard) +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + + +Dashboard 是基于网页的 Kubernetes 用户界面。您可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中,也可以对容器应用排错,还能管理集群本身及其附属资源。您可以使用 Dashboard 获取运行在集群中的应用的概览信息,也可以创建或者修改 Kubernetes 资源(如 Deployment,Job,DaemonSet 等等)。例如,您可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。 + +Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。 + +![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) + +{{% /capture %}} + + +{{% capture body %}} + + +## 部署 Dashboard UI + +默认情况下不会部署 Dashboard。可以通过以下命令部署: + +``` +kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml +``` + + +## 访问 Dashboard UI + +访问 Dashboard UI 有多种方式;可以使用 kubectl 命令行,或者使用浏览器访问 Kubernetes 主节点的 API 服务器。 + + +### 命令行代理 +您可以使用 kubectl 命令行工具访问 Dashboard,命令如下: + +``` +kubectl proxy +``` + + +kubectl 会处理与 API 服务器的认证过程,并使得 Dashboard 可以通过 http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 访问。 + +UI _只能_ 通过执行这条命令的机器进行访问。更多选项参见 `kubectl proxy --help`。 + + +### 主节点 API 服务器 +UI 可以直接通过 Kubernetes 主节点上的 API 服务器访问。打开浏览器,输入 `https://:/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/`,其中 `<` 是 Kubernetes 主服务器的 IP 地址或域名。 + +请注意,只有当 API 服务器允许使用用户名密码认证时,这种方式才可以正常工作。但目前对于安装工具(如 `kubeadm`)来说并非如此。关于如何手工设置,参见 [认证管理文档](/docs/reference/access-authn-authz/authentication/)。 + +如果您不知道配置的用户名密码,可以使用 `kubectl config view` 查询。 + + +## 欢迎界面 + +当访问空集群的 Dashboard 时,您会看到欢迎界面。页面包含一个指向此文档的链接,以及一个用于部署第一个应用程序的按钮。此外,您可以看到在默认情况下有哪些默认系统应用运行在 `kube-system` [命名空间](/docs/tasks/administer-cluster/namespaces/) 中,比如 Dashboard 自己。 + + +![Kubernetes Dashboard 欢迎页面](/images/docs/ui-dashboard-zerostate.png) + + +## 部署容器化应用 + +通过一个简单的部署向导,您可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的 Service 进行创建和部署。可以手工指定应用的详细配置,或者上传一个包含应用配置的 YAML 或 JSON 文件。 + +想要访问部署向导,可以点击欢迎界面上的各个部署按钮。向导也可以之后通过点击任何页面右上角的 **创建** 按钮进行快速访问。 + + +![部署向导](/images/docs/ui-dashboard-deploy-simple.png) + + +### 指定应用的详细配置 + +部署向导需要您提供以下信息: + + +- **应用名称**(必填):应用的名称。内容为`应用名称`的[标签](/docs/concepts/overview/working-with-objects/labels/) 会被添加到任何将被部署的 Deployment 和 Service。 + + 在选定的 Kubernetes [命名空间](/docs/tasks/administer-cluster/namespaces/) 中,应用名称必须唯一。必须由小写字母开头,以数字或者小写字母结尾,并且只含有小写字母、数字和中划线(-)。小于等于24个字符。开头和结尾的空格会被忽略。 + + +- **容器镜像**(必填):公共镜像仓库上的 Docker [容器镜像](/docs/concepts/containers/images/) 或者私有镜像仓库(通常是 Google Container Registery 或者 Docker Hub)的 URL。容器镜像参数说明必须以冒号结尾。 + + +- **pod 的数量**(必填):您希望应用程序部署的 Pod 的数量。值必须为正整数。 + + 系统会创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) 用于保证集群中运行了期望的 Pod 数量。 + + +- **服务**(可选):对于部分应用(比如前端),您可能想对外暴露一个 [Service](/docs/concepts/services-networking/service/) ,这个 Service(外部 Service)可能用的是集群之外的公网 IP 地址。对于外部 Service 的情况,需要开放一个或者多个端口来满足。更多信息请参考 [这里](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/。 + + + 其它只能对集群内部可见的 Service 称为内部 Service。 + + 不管哪种 Service 类型,如果您选择创建一个 Service,而且容器在一个端口上开启了监听(入向的),那么您需要定义两个端口。创建的 Service 会把(入向的)端口映射到容器可见的目标端口。该 Service 会把流量路由到您部署的 Pod。支持的协议有 TCP 和 UDP。这个 Service 的内部 DNS 解析名就是之前您定义的应用名称的值。 + + +如果需要,您可以打开 **高级选项** 部分,这里您可以定义更多设置: + + +- **描述**:这里您输入的文本会作为一个 [注解](/docs/concepts/overview/working-with-objects/annotations/) 添加到 Deployment,并显示在应用的详细信息中。 + + +- **标签**:应用默认使用的 [标签](/docs/concepts/overview/working-with-objects/labels/) 是应用名称和版本。您可以为 Deployment、Service(如果有)定义额外的标签,比如 release(版本)、environment(环境)、tier(层级)、partition(分区) 和 release track(版本跟踪)。 + + 例子: + + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` + + +- **命名空间**:Kubernetes 支持多个虚拟集群依附于同一个物理集群。这些虚拟集群被称为 [命名空间](/docs/tasks/administer-cluster/namespaces/),可以让您将资源划分为逻辑命名的组。 + + Dashboard 通过下拉菜单提供所有可用的命名空间,并允许您创建新的命名空间。命名空间的名称最长可以包含 63 个字母或数字和中横线(-),但是不能包含大写字母。 + 命名空间的名称不能只包含数字。如果名字被设置成一个数字,比如 10,pod 就会被放在默认的命名空间中。 + + 在 namespace 创建成功的情况下,默认会使用新创建的命名空间。如果创建失败,那么第一个命名空间会被选中。 + + +- **镜像拉取 Secret**:如果要使用私有的 Docker 容器镜像,需要拉取 [secret](/docs/concepts/configuration/secret/) 凭证。 + + Dashboard 通过下拉菜单提供所有可用的 secret,并允许您创建新的 secret。secret 名称必须遵循 DNS 域名语法,比如 `new.image-pull.secret`。secret 的内容必须是 base64 编码的,并且在一个 [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文件中声明。secret 名称最大可以包含 253 个字符。 + + 在镜像拉取 secret 创建成功的情况下,默认会使用新创建的 secret。如果创建失败,则不会使用任何 secret。 + + +- **CPU 需求(核数)**和**内存需求(MiB)**:您可以为容器定义最小的 [资源限制](/docs/tasks/configure-pod-container/limit-range/)。默认情况下,Pod 没有 CPU 和内存限制。 + + +- **运行命令**和**运行命令参数**:默认情况下,您的容器会运行 Docker 镜像的默认 [入口命令](/docs/user-guide/containers/#containers-and-commands)。您可以使用 command 选项覆盖默认值。 + + +- **以特权运行**:这个设置决定了在 [特权容器](/docs/user-guide/pods/#privileged-mode-for-pod-containers) 中运行的进程是否像主机中使用 root 运行的进程一样。特权容器可以使用诸如操纵网络堆栈和访问设备的功能。 + + +- **环境变量**:Kubernetes 通过 [环境变量](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) 暴露 Service。您可以构建环境变量,或者将环境变量的值作为参数传递给您的命令。它们可以被应用用于查找 Service。值可以通过 `$(VAR_NAME)` 语法关联其他变量。 + + +### 上传 YAML 或者 JSON 文件 + +Kubernetes 支持声明式配置。所有的配置都存储在遵循 Kubernetes [API](/docs/concepts/overview/kubernetes-api/) 架构的 YAML 或者 JSON 配置文件中。 + +作为一种替代在部署向导中指定应用详情的方式,您可以在 YAML 或者 JSON 文件中定义应用,并且使用 Dashboard 上传文件: + + +![部署向导中上传文件](/images/docs/ui-dashboard-deploy-file.png) + + +## 使用 Dashboard +以下各节描述了 Kubernetes Dashboard UI 视图;包括它们提供的内容,以及怎么使用它们。 + + +### 导航栏 + +当在集群中定义 Kubernetes 对象时,Dashboard 会在初始视图中显示它们。默认情况下只会显示 _默认_ 命名空间中的对象,可以通过更改导航栏菜单中的命名空间筛选器进行改变。 + +Dashboard 展示大部分 Kubernetes 对象,并将它们分组放在几个菜单类别中。 + + +#### 管理 +集群和命名空间管理的视图。它会列出节点、命名空间和持久卷,并且有它们的详细视图。节点列表视图包含从所有节点聚合的 CPU 和内存使用的度量值。详细信息视图显示了一个节点的度量值,它的规格、状态、分配的资源、事件和这个节点上运行的 Pod。 + + +![节点详细信息视图](/images/docs/ui-dashboard-node.png) + + +#### 负载 +入口视图显示选中的命名空间中所有运行的应用。视图按照负载类型(如 Deployment、ReplicaSet、StatefulSet 等)罗列应用,并且每种负载都可以单独查看。列表总结了关于负载的可执行信息,比如一个 ReplicaSet 的准备状态的 Pod 数量,或者目前一个 Pod 的内存使用量。 + + +![负载视图](/images/docs/ui-dashboard-workloadview.png) + + +工作负载的详情视图展示了对象的状态、详细信息和相互关系。例如,ReplicaSet 所控制的 Pod,或者 Deployment 关联的 新 ReplicaSet 和 Pod 水平扩展控制器。 + + +![部署详情视图](/images/docs/ui-dashboard-deployment-detail.png) + + +#### 服务发现 +服务发现视图展示允许暴露给外网服务和允许集群内部发现的 Kubernetes 资源。因此,Service 和 Ingress 视图展示他们关联的 Pod、给集群连接使用的内部端点和给外部用户使用的外部端点。 + + +![服务列表部分视图](/images/docs/ui-dashboard-service-list.png) + + +#### 存储 +存储视图展示持久卷申领(PVC)资源,这些资源被应用程序用来存储数据。 + + +#### 配置 +配置视图展示的所有 Kubernetes 资源是在集群中运行的应用程序的实时配置。目前来说就是 ConfigMap 和 Secret。通过这个视图可以编辑和管理配置对象,并显示那些默认隐藏的 secret。 + + +![Secret 详情视图](/images/docs/ui-dashboard-secret-detail.png) + + +#### 日志查看器 +Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。查看器可以钻取属于同一个 Pod 的不同容器的日志。 + + +![日志浏览](/images/docs/ui-dashboard-logs-view.png) + +{{% /capture %}} + +{{% capture whatsnext %}} + + +更多信息,参见 +[Kubernetes Dashboard 项目页面](https://github.com/kubernetes/dashboard). + +{{% /capture %}} diff --git a/content/zh/docs/tasks/access-kubernetes-api/_index.md b/content/zh/docs/tasks/access-kubernetes-api/_index.md new file mode 100755 index 0000000000..345cd8381b --- /dev/null +++ b/content/zh/docs/tasks/access-kubernetes-api/_index.md @@ -0,0 +1,11 @@ +--- +title: "扩展 Kubernetes" +weight: 90 +--- + + diff --git a/content/zh/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/zh/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md new file mode 100644 index 0000000000..d59c38c146 --- /dev/null +++ b/content/zh/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -0,0 +1,100 @@ +--- +title: 配置聚合层 +reviewers: +- lavalamp +- cheftako +- chenopis +content_template: templates/task +weight: 10 +--- + + +{{% capture overview %}} + +配置[聚合层](/docs/concepts/api-extension/apiserver-aggregation/)允许 Kubernetes apiserver 使用其它 API 进行扩展,这些 API 不是核心 Kubernetes API 的一部分。 + + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{< note >}} +**注意:** 在您的环境中启用聚合层时,如需要支持代理和扩展 apiserver 之间的双向 TLS 身份验证,需要满足一些设置要求。 +Kubernetes 和 kube-apiserver 都有多个 CA,因此要确保代理的证书由聚合层 CA 签署,而不是由其它 CA (如主 CA)来签署。 +{{< /note >}} + + +{{% /capture %}} + +{{% capture steps %}} + +## 启用 apiserver 参数 + +通过以下 kube-apiserver 参数启用聚合层。这一操作可能已由您的供应商完成。 + + --requestheader-client-ca-file= + --requestheader-allowed-names=front-proxy-client + --requestheader-extra-headers-prefix=X-Remote-Extra- + --requestheader-group-headers=X-Remote-Group + --requestheader-username-headers=X-Remote-User + --proxy-client-cert-file= + --proxy-client-key-file= + +**警告**:除非您了解 CA 的风险和保护 CA 使用的机制,否则**不要**在不同的场合重复使用同一 CA。 + +如果您未在运行 API 服务器的主机上运行 kube-proxy ,则必须确保配置了以下 apiserver 参数: + + --enable-aggregator-routing=true + + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [安装一个扩展的 api-server ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 以使用聚合层。 +* 有关高级概述,请参阅[使用聚合层扩展 Kubernetes API ](/docs/concepts/api-extension/apiserver-aggregation/)。 +* 了解如何[使用自定义资源扩展 Kubernetes API ](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 + + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/access-kubernetes-api/custom-resources/_index.md b/content/zh/docs/tasks/access-kubernetes-api/custom-resources/_index.md new file mode 100755 index 0000000000..7fb09fb93d --- /dev/null +++ b/content/zh/docs/tasks/access-kubernetes-api/custom-resources/_index.md @@ -0,0 +1,9 @@ +--- +title: "使用自定义资源" +weight: 10 +--- + + diff --git a/content/zh/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/content/zh/docs/tasks/access-kubernetes-api/http-proxy-access-api.md new file mode 100644 index 0000000000..4f6978fbcf --- /dev/null +++ b/content/zh/docs/tasks/access-kubernetes-api/http-proxy-access-api.md @@ -0,0 +1,128 @@ +--- +title: 使用 HTTP 代理访问 Kubernetes API +content_template: templates/task +weight: 40 +--- + + + + + +{{% capture overview %}} + +本文说明如何使用 HTTP 代理访问 Kubernetes API。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +* 如果您的集群中还没有任何应用,使用如下命令启动一个 Hello World 应用: + + kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + +{{% /capture %}} + +{{% capture steps %}} + + +## 使用 kubectl 启动代理服务器 + +使用如下命令启动 Kubernetes API 服务器的代理: + + kubectl proxy --port=8080 + + +## 探究 Kubernetes API + +当代理服务器在运行时,你可以通过 `curl`、`wget` 或者浏览器访问 API。 + + +获取 API 版本: + + curl http://localhost:8080/api/ + + { + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.2.15:8443" + } + ] + } + + +获取 Pod 列表: + + curl http://localhost:8080/api/v1/namespaces/default/pods + + { + "kind": "PodList", + "apiVersion": "v1", + "metadata": { + "selfLink": "/api/v1/namespaces/default/pods", + "resourceVersion": "33074" + }, + "items": [ + { + "metadata": { + "name": "kubernetes-bootcamp-2321272333-ix8pt", + "generateName": "kubernetes-bootcamp-2321272333-", + "namespace": "default", + "selfLink": "/api/v1/namespaces/default/pods/kubernetes-bootcamp-2321272333-ix8pt", + "uid": "ba21457c-6b1d-11e6-85f7-1ef9f1dab92b", + "resourceVersion": "33003", + "creationTimestamp": "2016-08-25T23:43:30Z", + "labels": { + "pod-template-hash": "2321272333", + "run": "kubernetes-bootcamp" + }, + ... + } + +{{% /capture %}} + + + +{{% capture whatsnext %}} + +想了解更多信息,请参阅 [kubectl 代理](/docs/reference/generated/kubectl/kubectl-commands#proxy)。 + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md index f7b3fff81a..6e6779c41c 100644 --- a/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md +++ b/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md @@ -1,3 +1,13 @@ +--- +title: 设置一个扩展的 API server +reviewers: +- lavalamp +- cheftako +- chenopis +content_template: templates/task +weight: 15 +--- + ---- -title: 设置一个扩展的 API server -reviewers: -- lavalamp -- cheftako -- chenopis -content_template: templates/task -weight: 15 ---- {{% capture overview %}} diff --git a/content/zh/docs/tasks/administer-cluster/_index.md b/content/zh/docs/tasks/administer-cluster/_index.md new file mode 100755 index 0000000000..348e449aa8 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/_index.md @@ -0,0 +1,11 @@ +--- +title: "管理集群" +weight: 20 +--- + + diff --git a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md index fe419be70b..0dbfb7c8ee 100644 --- a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md @@ -36,54 +36,61 @@ content_template: templates/task 1. 列出您集群中的 StorageClasses: - kubectl get storageclass + ```bash + kubectl get storageclass + ``` + 输出类似这样: - 输出类似这样: + ```bash + NAME PROVISIONER AGE + standard (default) kubernetes.io/gce-pd 1d + gold kubernetes.io/gce-pd 1d + ``` - NAME TYPE - standard (default) kubernetes.io/gce-pd - gold kubernetes.io/gce-pd - - - 默认 StorageClass 以 `(default)` 标记。 + 默认 StorageClass 以 `(default)` 标记。 2. 标记默认 StorageClass 非默认: - 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。 + 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。 + + 要标记一个 StorageClass 为非默认的,您需要改变它的值为 `false`: + + ```bash + kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' + ``` - 要标记一个 StorageClass 为非默认的,您需要改变它的值为 `false`: - - kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' - - - 这里的 `` 是您选择的 StorageClass 的名字。 + 这里的 `` 是您选择的 StorageClass 的名字。 3. 标记一个 StorageClass 为默认的: - 和前面的步骤类似,您需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。 + 和前面的步骤类似,您需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。 - kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ```bash + kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ``` - - 请注意,最多只能有一个 StorageClass 能够被标记为默认。如果它们中有两个或多个被标记为默认,Kubernetes 将忽略这个注解,也就是它将表现为没有默认 StorageClass。 + 请注意,最多只能有一个 StorageClass 能够被标记为默认。如果它们中有两个或多个被标记为默认,Kubernetes 将忽略这个注解,也就是它将表现为没有默认 StorageClass。 4. 验证您选用的 StorageClass 为默认的: - kubectl get storageclass + ```bash + kubectl get storageclass + ``` + 输出类似这样: - 输出类似这样: - - NAME TYPE - standard kubernetes.io/gce-pd - gold (default) kubernetes.io/gce-pd + ```bash + NAME PROVISIONER AGE + standard kubernetes.io/gce-pd 1d + gold (default) kubernetes.io/gce-pd 1d + ``` {{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md new file mode 100644 index 0000000000..479151b213 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -0,0 +1,310 @@ +--- +title: 配置多个调度器 +content_template: templates/task +--- + + +{{% capture overview %}} + + +Kubernetes 自带了一个默认调度器,其详细描述请查阅[这里](/docs/reference/command-line-tools-reference/kube-scheduler/)。 + +如果默认调度器不适合您的需求,您可以实现自己的调度器。 + +不仅如此,您甚至可以伴随着默认调度器同时运行多个调度器,并告诉 Kubernetes 为每个 pod 使用什么调度器。 +让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。 + + +关于实现调度器的具体细节描述超出了本文范围。 +请参考 kube-scheduler 的实现,规范示例代码位于 [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + +## 打包调度器 + + +将调度器二进制文件打包到容器镜像中。出于示例目的,我们就使用默认调度器(kube-scheduler)作为我们的第二个调度器。 + +从 Github 克隆 [Kubernetes 源代码](https://github.com/kubernetes/kubernetes),并编译构建源代码。 + +```shell +git clone https://github.com/kubernetes/kubernetes.git +cd kubernetes +make +``` + + +创建一个包含 kube-scheduler 二进制文件的容器镜像。用于构建镜像的 `Dockerfile` 内容如下: + +```docker +FROM busybox +ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler +``` + + +将文件保存为 `Dockerfile`,构建镜像并将其推送到镜像仓库。 +此示例将镜像推送到 [Google 容器镜像仓库(GCR)](https://cloud.google.com/container-registry/)。 + +有关详细信息,请阅读 GCR [文档](https://cloud.google.com/container-registry/docs/)。 + +```shell +docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . +gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 +``` + + +## 为调度器定义 Kubernetes Deployment + + +现在我们将调度器放在容器镜像中,我们可以为它创建一个 pod 配置,并在我们的 Kubernetes 集群中运行它。 +但是与其在集群中直接创建一个 pod,不如使用 [Deployment](/docs/concepts/workloads/controllers/deployment/)。 +[Deployment](/docs/concepts/workloads/controllers/deployment/) 管理一个 [Replica Set](/docs/concepts/workloads/controllers/replicaset/),Replica Set 再管理 pod,从而使调度器能够适应故障。 +以下是 Deployment 配置,被保存为 `my-scheduler.yaml`: + +{{< codenew file="admin/sched/my-scheduler.yaml" >}} + + +这里需要注意的是,在该部署文件中 Container 的 spec 配置的调度器启动命令参数(--scheduler-name)指定的调度器名称应该是惟一的。 +这个名称应该与 pods 上的可选参数 `spec.schedulerName` 的值相匹配,也就是说调度器名称的匹配关系决定了 pods 的调度任务由哪个调度器负责。 + + +还要注意,我们创建了一个专用服务帐户 `my-scheduler` 并将集群角色 `system:kube-scheduler` 绑定到它,以便它可以获得与 `kube-scheduler` 相同的权限。 + + +请参阅 [kube-scheduler 文档](/docs/reference/command-line-tools-reference/kube-scheduler/)以获取其他命令行参数的详细说明。 + + +## 在集群中运行第二个调度器 + + +为了在 Kubernetes 集群中运行我们的第二个调度器,只需在 Kubernetes 集群中创建上面配置中指定的 Deployment: + +```shell +kubectl create -f my-scheduler.yaml +``` + + +验证调度器 pod 正在运行: + +```shell +$ kubectl get pods --namespace=kube-system +NAME READY STATUS RESTARTS AGE +.... +my-scheduler-lnf4s-4744f 1/1 Running 0 2m +... +``` + + +此列表中,除了默认的 kube-scheduler pod 之外,您应该还能看到处于 “Running” 状态的 my-scheduler pod。 + + +要在启用了 leader 选举的情况下运行多调度器,您必须执行以下操作: + + +首先,更新上述 Deployment YAML(my-scheduler.yaml)文件中的以下字段: + +* `--leader-elect=true` +* `--lock-object-namespace=lock-object-namespace` +* `--lock-object-name=lock-object-name` + + +如果在集群上启用了 RBAC,则必须更新 `system:kube-scheduler` 集群角色。将调度器名称添加到应用于端点资源的规则的 resourceNames,如以下示例所示: +``` +$ kubectl edit clusterrole system:kube-scheduler +- apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRole + metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler + rules: + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update +``` + + +## 指定 pod 的调度器 + + +现在我们的第二个调度器正在运行,让我们创建一些 pod,并指定它们由默认调度器或我们刚部署的调度器进行调度。 +为了使用特定的调度器调度给定的 pod,我们在那个 pod 的 spec 中指定调度器的名称。让我们看看三个例子。 + + + + - Pod spec 没有任何调度器名称 + + {{< codenew file="admin/sched/pod1.yaml" >}} + + +如果未提供调度器名称,则会使用 default-scheduler 自动调度 pod。 + + +将此文件另存为 `pod1.yaml`,并将其提交给 Kubernetes 集群。 + +```shell +kubectl create -f pod1.yaml +``` + + + - Pod spec 设置为 `default-scheduler` + + {{< codenew file="admin/sched/pod2.yaml" >}} + + +通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。在这种情况下,我们提供默认调度器的名称,即 `default-scheduler`。 + + +将此文件另存为 `pod2.yaml`,并将其提交给 Kubernetes 集群。 + +```shell +kubectl create -f pod2.yaml +``` + + + - Pod spec 设置为 `my-scheduler` + + {{< codenew file="admin/sched/pod3.yaml" >}} + + +在这种情况下,我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。 +请注意,`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给 scheduler 命令的参数名称匹配。 + + +将此文件另存为 `pod3.yaml`,并将其提交给 Kubernetes 集群。 + +```shell +kubectl create -f pod3.yaml +``` + + +确认所有三个 pod 都在运行。 + +```shell +kubectl get pods +``` + +{{% /capture %}} + +{{% capture discussion %}} + + +### 验证是否使用所需的调度器调度了 pod + + +为了更容易地完成这些示例,我们没有验证 pod 实际上是使用所需的调度程序调度的。 +我们可以通过更改 pod 的顺序和上面的部署配置提交来验证这一点。 +如果我们在提交调度器部署配置之前将所有 pod 配置提交给 Kubernetes 集群,我们将看到注解了 `annotation-second-scheduler` 的 pod 始终处于 “Pending” 状态,而其他两个 pod 被调度。 +一旦我们提交调度器部署配置并且我们的新调度器开始运行,注解了 `annotation-second-scheduler` 的 pod 就能被调度。 + + +或者,可以查看事件日志中的 “Scheduled” 条目,以验证是否由所需的调度器调度了 pod。 + +```shell +kubectl get events +``` + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/coredns.md b/content/zh/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000..26a7741935 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,153 @@ +--- +reviewers: +- johnbelamaric +title: 使用 CoreDNS 进行服务发现 +min-kubernetes-server-version: v1.9 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +此页面介绍了 CoreDNS 升级过程以及如何安装 CoreDNS 而不是 kube-dns。 + +{{% /capture %}} + +{{% capture prerequisites %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{% /capture %}} + +{{% capture steps %}} + + + +## 关于 CoreDNS + + +[CoreDNS](https://coredns.io) 是一个灵活可扩展的 DNS 服务器,可以作为 Kubernetes 集群 DNS。与 Kubernetes 一样,CoreDNS 项目由 CNCF(http://www.cncf.io) 持有。 + + +通过在现有的集群中替换 kube-dns,可以在集群中使用 CoreDNS 代替 kube-dns 部署,或者使用 kubeadm 等工具来为您部署和升级集群。 + + + +## 安装 CoreDNS + + +有关手动部署或替换 kube-dns,请参阅 [CoreDNS GitHub 工程](https://github.com/coredns/deployment/tree/master/kubernetes)。 + + + +## 使用 kubeadm 升级现有集群 + + +在 Kubernetes 1.10 及更高版本中,当您使用 `kubeadm` 升级使用 `kube-dns` 的集群时,您还可以迁移到 CoreDNS。 +在本例中 `kubeadm` 将生成 CoreDNS 配置("Corefile")基于 `kube-dns` ConfigMap,保存联邦、存根域和上游名称服务器的配置。 + + +如果您正在从 kube-dns 迁移到 CoreDNS,请确保在升级期间将 `CoreDNS` 特性门设置为 `true`。例如,`v1.11.0` 升级应该是这样的: + +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + + +在 1.11 之前的版本中,核心文件将被升级过程中创建的文件覆盖。 +**如果已对其进行自定义,则应保存现有的 ConfigMap。** 在新的 ConfigMap 启动并运行后,您可以重新应用自定义。 + + +如果您在 Kubernetes 1.11 及更高版本中运行 CoreDNS,则在升级期间,将保留现有的 Corefile。 + + +## 使用 kubeadm 安装 kube-dns 而不是 CoreDNS + +{{< note >}} + + +在 Kubernetes 1.11 中,CoreDNS 已经升级到通用可用性(GA),并默认安装。 + +{{< /note >}} + + +若要安装 kube-dns,请将 `CoreDNS` 特性门值设置为 `false`: + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + + + +## CoreDNS 调优 + + +当涉及到资源利用时,优化内核的配置可能是有用的。有关详细信息,请参阅 [关于扩展 CoreDNS 的文档]((https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md))。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +您可以通过修改 `Corefile` 来配置 [CoreDNS](https://coredns.io),以支持比 ku-dns 更多的用例。有关更多信息,请参考 [CoreDNS 网站](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md new file mode 100644 index 0000000000..09dc35a528 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -0,0 +1,84 @@ +--- +reviewers: +- luxas +- thockin +- wlan0 +title: 开发云控制器管理器 +content_template: templates/concept +--- + + + + + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +在即将发布的版本中,云控制器管理器将是把 Kubernetes 与任何云集成的首选方式。 这将确保驱动可以独立于核心 Kubernetes 发布周期开发其功能。 + +{{< feature-state for_k8s_version="1.8" state="alpha" >}} + + +在讨论如何构建自己的云控制器管理器之前,了解有关它如何工作的一些背景知识是有帮助的。云控制器管理器是来自 `kube-controller-manager` 的代码,利用 Go 接口允许插入任何云的实现。大多数框架和通用控制器的实现在 core,但只要满足 [云提供者接口](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62),它就会始终执行它所提供的云接口。 + + +为了深入了解实施细节,所有云控制器管理器都将从 Kubernetes 核心导入依赖包,唯一的区别是每个项目都会通过调用 [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) 来注册自己的驱动,更新可用驱动的全局变量。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 开发 + +### Out of Tree + + +要为您的云构建一个 out-of-tree 云控制器管理器,请按照下列步骤操作: + + +1. 使用满足 [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) 的实现创建一个 go 包。 +2. 使用来自 Kubernetes 核心包的 [cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) 作为 main.go 的模板。如上所述,唯一的区别应该是将导入的云包。 +3. 在 `main.go` 中导入你的云包,确保你的包有一个 `init` 块来运行 cloudprovider.RegisterCloudProvider。 + + +用现有的 out-of-tree 云驱动作为例子可能会有所帮助。你可以在这里找到 [清单](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)。 + + +### In Tree + + +对于 in-tree 驱动,您可以将 in-tree 云控制器管理器作为群集中的 [Daemonset](/examples/admin/cloud/ccm-example.yaml) 运行。有关详细信息,请参阅 [运行的云控制器管理器文档](/docs/tasks/administer-cluster/running-cloud-controller.md)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md new file mode 100644 index 0000000000..aaf3f2230f --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -0,0 +1,601 @@ +--- +translator: +- nicksu +reviewers: +- bowei +- zihongz +title: Debug DNS 方案 +content_template: templates/task +--- + + + +{{% capture overview %}} +这篇文章提供了一些关于 DNS 问题诊断的方法。 +{{% /capture %}} + + + +{{% capture prerequisites %}} + +- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +- Kubernetes 1.6 或者以上版本。 +- 集群必须使用了 `coredns` (或者 `kube-dns`)插件。 + {{% /capture %}} + +{{% capture steps %}} + + + +### 创建一个简单的 Pod 作为测试环境 + +新建一个名为 busybox.yaml 的文件并填入下列内容: + +{{< codenew file="admin/dns/busybox.yaml" >}} + +然后使用这个文件创建一个 Pod 并验证其状态: + +```shell +kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml +pod/busybox created + +kubectl get pods busybox +NAME READY STATUS RESTARTS AGE +busybox 1/1 Running 0 +``` + + + +只要 Pod 处于 running 状态,您就可以在环境里执行 `nslookup` 。 +如果您看到类似下列的内容,则表示 DNS 是正常运行的。 + +```shell +kubectl exec -ti busybox -- nslookup kubernetes.default +Server: 10.0.0.10 +Address 1: 10.0.0.10 + +Name: kubernetes.default +Address 1: 10.0.0.1 +``` + +如果 `nslookup` 命令执行失败,请检查下列内容: + + + +### 先检查本地的 DNS 配置 + +查看 resolv.conf 文件的内容 +(阅读下面的 [从节点继承 DNS 配置](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 和 +[已知问题](#known-issues) ,获取更多信息) + +```shell +kubectl exec busybox cat /etc/resolv.conf +``` + +验证 search 和 name server 的配置是否类似下面的配置 +(注意 search 根据不同的云提供商可能会有所不同): + +``` +search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal +nameserver 10.0.0.10 +options ndots:5 +``` + + + +下列错误表示 coredns/kube-dns 或者相关服务出现了问题: + +``` +kubectl exec -ti busybox -- nslookup kubernetes.default +Server: 10.0.0.10 +Address 1: 10.0.0.10 + +nslookup: can't resolve 'kubernetes.default' +``` + +或者 + +``` +kubectl exec -ti busybox -- nslookup kubernetes.default +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +nslookup: can't resolve 'kubernetes.default' +``` + + + +### 检查 DNS Pod 是否运行 + +使用 `kubectl get pods` 命令来验证 DNS Pod 是否运行。 + +对于 CoreDNS 的情况: + +```shell +kubectl get pods --namespace=kube-system -l k8s-app=coredns +NAME READY STATUS RESTARTS AGE +... +coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h +coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h +... +``` + +或者是 kube-dns: + +```shell +kubectl get pods --namespace=kube-system -l k8s-app=kube-dns +NAME READY STATUS RESTARTS AGE +... +kube-dns-v19-ezo1y 3/3 Running 0 1h +... +``` + +如果您发现没有 pod 在运行,或者这些 Pod 的状态是 failed 或者 completed, 那可能这个 DNS 插件在您当前的环境里并没有成功部署,您将需要手动去部署它。 + + + +### 检查 DNS pod 里的错误 + +使用 `kubectl logs` 命令来查看 DNS 容器的日志信息。 + +对于 CoreDNS: + +```shell +for p in $(kubectl get pods --namespace=kube-system -l k8s-app=coredns -o name); do kubectl logs --namespace=kube-system $p; done +``` + +下列是一个正常运行的 CoreDNS 日志信息: + +``` +.:53 +2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2 +2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6 +CoreDNS-1.2.2 +linux/amd64, go1.10.3, 2e322f6 +2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c +``` + + + +对于 kube-dns, 总共有三种类型的日志需要查看: + +```shell +kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns + +kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq + +kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar +``` + +看日志信息里是否有可疑的错误,对于 kube-dns, 一个 '`W`', '`E`' 或者 '`F`' 开头的行表示对应的 Warning(警告), Error(错误)或者 Failure(失败)。请搜索日志等级是否有这样的关键字的日志信息并使用 [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) 来提交错误报告。 + +### 检查是否启用了 DNS 服务 + +使用`kubectl get service` 命令来检查 DNS 服务是否已经启用。 + +```shell +kubectl get svc --namespace=kube-system +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +... +kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h +... +``` + +注意不管是 CoreDNS 还是 kube-dns , 这个 service 的名字都会是“kube-dns” 。 +如果您已经创建了这个 service 或者说在这个例子里它应该是默认自动创建的,但是它并没有出现,请阅读 [services 纠错](/docs/tasks/debug-application-cluster/debug-service/)来获取更多信息。 + + + +### DNS 的 endpoints 公开了吗? + +您可以使用 `kubectl get endpoints`命令来验证 DNS 的 endpoint 是否公开了。 + +```shell +kubectl get ep kube-dns --namespace=kube-system +NAME ENDPOINTS AGE +kube-dns 10.180.3.17:53,10.180.3.17:53 1h +``` + +如果您没看到对应的 endpoints, 请阅读[services 纠错](/docs/tasks/debug-application-cluster/debug-service/)的 endpoints 小节。 + +若需要更多的 Kubernetes DNS 例子,请在 Kubernetes GitHub 仓库里查看[cluster-dns 例子](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) 。 + + + +### DNS 查询有被接收或者执行吗? + +您可以通过给 CoreDNS 的配置文件 (也叫 Corefile)添加`log`插件来判断查询是否被正确接收。 + CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里,使用下列命令来编辑它: + +``` +kubectl -n kube-system edit configmap coredns +``` + + + +然后类似下面的例子给 Corefile 添加 `log`。 + +``` +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + log + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + upstream + fallthrough in-addr.arpa ip6.arpa + } + prometheus :9153 + proxy . /etc/resolv.conf + cache 30 + loop + reload + loadbalance + } + +``` + +保存这些更改后,您可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到 CoreDNS 的 pods 里。 + + + +接下来,发起一些查询并依照本文上面章节的内容查看日志信息,如果 CoreDNS 的 pods 接收到这些查询,您将可以在日志信息里看到他们。 + +下面是日志信息里的查询例子: + +``` +.:53 +2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0 +2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6 +CoreDNS-1.2.0 +linux/amd64, go1.10.3, 2e322f6 +2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f +2018/09/07 15:29:04 [INFO] Reloading complete +172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s + +``` + + + +## 已知问题 + +有些 Linux 发行版本 (比如 Ubuntu), 默认使用一个本地的 DNS 解析器 (systemd-resolved)。 +Systemd-resolved 会用一个 stub 文件来覆盖 `/etc/resolv.conf`从而在解析域名的时候导致了重复向 DNS 上游服务器推送请求。 这个问题可以通过手动指定 kubelet 的 `--resolv-conf` 标签为正确的 `resolv.conf` (如果是 `systemd-resolved`,则这个文件路径为 `/run/systemd/resolve/resolv.conf`) 来解决。 +kubeadm (>= 1.11) 会自动检测`systemd-resolved`并对应的更改 kubelet 的标签。 + + + +Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务,因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 + +Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录,那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置,但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。 + +如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像,DNS 可能会由于Alpine 一个已知的问题导致无法正常工作,请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。 + + + +## Kubernetes Federation (支持多区域部署) + +自从 1.3 版本支持了多个 Kubernetes 的联邦集群后,集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的),从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 [联邦集群管理向导](/docs/concepts/cluster-administration/federation/) 获取更多关于联邦集群和多点支持的信息。 + + + +## 参考 + +- [Services 和 Pods 的 DNS 指南](/docs/concepts/services-networking/dns-pod-service/) +- [kube-dns DNS 插件文档](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md) + +## 接下来 + +- [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). + +{{% /capture %}} + + + diff --git a/content/zh/docs/tasks/administer-cluster/encrypt-data.md b/content/zh/docs/tasks/administer-cluster/encrypt-data.md index d1f12a6edf..7784389bd9 100644 --- a/content/zh/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/zh/docs/tasks/administer-cluster/encrypt-data.md @@ -1,3 +1,10 @@ +--- +reviewers: +- smarterclayton +title: 静态加密 Secret 数据 +content_template: templates/task +--- + ---- -reviewers: -- smarterclayton -title: 加密静态 Secret 数据 -content_template: templates/task ---- {{% capture overview %}} + +{{% capture overview %}} + + +本文展示了如何为节点指定扩展资源。 扩展资源允许集群管理员发布节点级别的资源,这些资源在不进行发布的情况下无法被 Kubernetes 感知。 + +{{< feature-state state="stable" >}} + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + +## 获取您的节点名称 + +```shell +kubectl get nodes +``` + +选择您的一个节点用于此练习。 + + +## 在您的一个节点上发布一种新的扩展资源 + +为在一个节点上发布一种新的扩展资源,需要发送一个 HTTP PATCH 请求到 Kubernetes API server。 例如:假设您的一个节点上带有四个 dongle 资源。下面是一个 PATCH 请求的示例, 该请求为您的节点发布四个 dongle 资源。 + +```shell +PATCH /api/v1/nodes//status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/example.com~1dongle", + "value": "4" + } +] +``` + +注意:Kubernetes 不需要了解 dongle 资源的含义和用途。 前面的 PATCH 请求仅仅告诉 Kubernetes 您的节点拥有四个您称之为 dongle 的东西。 + +启动一个代理(proxy),以便您可以很容易地向 Kubernetes API server 发送请求: + +``` +kubectl proxy +``` + +在另一个命令窗口中,发送 HTTP PATCH 请求。 用您的节点名称替换 ``: + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \ +http://localhost:8001/api/v1/nodes//status +``` + +{{< note >}} +在前面的请求中,`~1` 为 patch 路径中 “/” 符号的编码。JSON-Patch 中的操作路径值被解析为 JSON 指针。 更多细节,请查看 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901) 的第 3 部分。 +{{< /note >}} + +输出显示该节点的 dongle 资源容量(capacity)为 4: + +``` +"capacity": { + "cpu": "2", + "memory": "2049008Ki", + "example.com/dongle": "4", +``` + +描述您的节点: + +``` +kubectl describe node +``` + +输出再次展示了 dongle 资源: + +```yaml +Capacity: + cpu: 2 + memory: 2049008Ki + example.com/dongle: 4 +``` + +现在,应用开发者可以创建请求一定数量 dongle 资源的 Pod 了。 参见[将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/)。 + + +## 讨论 + +扩展资源类似于内存和 CPU 资源。 例如,正如一个节点拥有一定数量的内存和 CPU 资源, 它们被节点上运行的所有组件共享,该节点也可以拥有一定数量的 dongle 资源, 这些资源同样被节点上运行的所有组件共享。 此外,正如应用开发者可以创建请求一定数量的内存和 CPU 资源的 Pod, 他们也可以创建请求一定数量 dongle 资源的 Pod。 + +扩展资源对 Kubernetes 是不透明的。 Kubernetes 不知道扩展资源含义相关的任何信息。 Kubernetes 只了解一个节点拥有一定数量的扩展资源。 扩展资源必须以整形数量进行发布。 例如,一个节点可以发布 4 个 dongle 资源,但是不能发布 4.5 个。 + + +### 存储示例 + +假设一个节点拥有一种特殊类型的磁盘存储,其容量为 800 GiB。 您可以为该特殊存储创建一个名称, 如 example.com/special-storage。 然后您就可以按照一定规格的块(如 100 GiB)对其进行发布。 在这种情况下,您的节点将会通知它拥有八个 example.com/special-storage 类型的资源。 + +```yaml +Capacity: + ... + example.com/special-storage: 8 +``` + +如果您想要允许针对特殊存储任意(数量)的请求,您可以按照 1 byte 大小的块来发布特殊存储。 在这种情况下,您将会发布 800Gi 数量的 example.com/special-storage 类型的资源。 + +```yaml +Capacity: + ... + example.com/special-storage: 800Gi +``` + +然后,容器就能够请求任意数量(多达 800Gi)字节的特殊存储。 + + +## 清理 + +这里是一个从节点移除 dongle 资源发布的 PATCH 请求。 + +```shell +PATCH /api/v1/nodes//status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "remove", + "path": "/status/capacity/example.com~1dongle", + } +] +``` + +启动一个代理,以便您可以很容易地向 Kubernetes API server 发送请求: + +``` +kubectl proxy +``` + +在另一个命令窗口中,发送 HTTP PATCH 请求。 用您的节点名称替换 ``: + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \ +http://localhost:8001/api/v1/nodes//status +``` + +验证 dongle 资源的发布已经被移除: + +``` +kubectl describe node | grep dongle +``` + +{{% /capture %}} + + +{{% capture whatsnext %}} + + +### 针对应用开发人员 + +* [将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/) + +### 针对集群管理员 + +* [为 Namespace 配置最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [为 Namespace 配置最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md index a99010e0d4..fea250a56c 100644 --- a/content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md +++ b/content/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md @@ -1,54 +1,40 @@ --- -approvers: -- davidopp -- filipg -- piosz title: 关键插件 Pod 的调度保证 +content_template: templates/concept --- -{{< toc >}} +{{% capture overview %}} + +除了在主机上运行的 Kubernetes 核心组件(如 api-server 、scheduler 、controller-manager)之外,还有许多插件,由于各种原因, +必须在常规集群节点(而不是 Kubernetes 主节点)上运行。 +其中一些插件对于功能完备的群集至关重要,例如 Heapster、DNS 和 UI。 +如果关键插件被逐出(手动或作为升级等其他操作的副作用)或者变成挂起状态,群集可能会停止正常工作。 +关键插件进入挂起状态的例子有:集群利用率过高;被逐出的关键插件 Pod 释放了空间,但该空间被之前悬决的 Pod 占用;由于其它原因导致节点上可用资源的总量发生变化。 +{{% /capture %}} -## 概览 +{{% capture body %}} -除了 Kubernetes 核心组件,像运行在 master 机器上的 api-server、scheduler、controller-manager,由于各种原因,还有很多插件必须运行在一个普通的集群节点上(而不是 Kubernetes master)。 -这些插件中的一些对于一个功能完备的集群来说是非常关键的,例如 Heapster、DNS 以及 UI。 -如果一个关键的插件被移除(或者手动,或是类似升级这样具有副作用的其它操作),或者变成挂起状态(例如,当集群利用率过高,以及或者其它被调度到该空间中的挂起 Pod 被清理关键插件 Pod 给移除,或者由于其它原因导致节点上可用资源的总量发生变化),集群可能会停止正常工作。 + +### 标记关键 Pod + +要将 pod 标记为关键性(critical),pod 必须在 kube-system 命名空间中运行(可通过参数配置)。 +同时,需要将 `priorityClassName` 设置为 `system-cluster-critical` 或 `system-node-critical` ,后者是整个群集的最高级别。 +或者,也可以为 Pod 添加名为 `scheduler.alpha.kubernetes.io/critical-pod`、值为空字符串的注解。 +不过,这一注解从 1.13 版本开始不再推荐使用,并将在 1.14 中删除。 - -## 二次调度器:关键插件的调度保证 - -二次调度器确保关键的插件总是能被调度(假定普通的 Pod 不存在时,集群具有足够的资源去运行关键插件 Pod)。 -如果调度器确定没有节点有足够资源去运行关键插件 Pod,假使有 Pod 已经运行在集群中(通过将关键插件 Pod 的条件 PodScheduled 设置为 false,原因设置为 Unschedulable 来指示),这时二次调度器通过清理一些 Pod 尽量去释放空间,然后调度器将调度该插件 Pod。 - - - -为了避免这种情况,当另一个 Pod 被调度到该空间,为了该关键插件,被选择的节点导致临时变成 "CriticalAddonsOnly" 的 taint(查看 [更多详情](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md))。 -每个关键插件不得不容忍它,然而其它一些 Pod 不可能容忍该 taint。一旦该插件被成功调度,该 taint 会被移除。 - -*警告:* 当前对选中哪个节点,以及为了调度该关键 Pod 杀掉哪个 Pod 并没有任何保证,所以如果启用了二次调度器,任何 Pod 都可能被偶然的杀掉以达到目的。 - - - -## 配置 - -二次调度器应该被 [作为 static Pod 默认启用](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest)。 -它没有任何面向用户的配置(组件配置),或者 API,可以通过如下方式来禁用: - - - -* 在集群安装过程中通过设置 `ENABLE_RESCHEDULER` 标志为 `false` -* 在运行中的集群中从 master 节点删除它的 manifest(默认路径 `/etc/kubernetes/manifests/rescheduler.manifest`) - - - -### 标记关键插件 - -想变成关键插件,必须运行在 `kube-system` Namespace 中(是基于标志可配置的),并且: -* 将 `scheduler.alpha.kubernetes.io/critical-pod` annotation 设置为空字符串,并且 -* 将 PodSpec 的 `tolerations` 字段设置为 `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]` - -第一个表示是一个关键 Pod。第二个是二次调度器算法必需的。 - +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/_index.md b/content/zh/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100644 index 0000000000..19f6db4cfa --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,11 @@ +--- +title: "用 kubeadm 进行管理" +weight: 10 +--- + + diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md new file mode 100644 index 0000000000..8c5786f8de --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md @@ -0,0 +1,446 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: 将 kubeadm 集群从 v1.11 升级到 v1.12 +content_template: templates/task +--- + +{{% capture overview %}} + + +本页介绍了如何将 `kubeadm` 创建的 Kubernetes 集群从 1.11.x 版本升级到 1.12.x 版本,以及从版本 1.12.x 升级到 1.12.y ,其中 `y > x`。 +{{% /capture %}} + +{{% capture prerequisites %}} + + +- 您需要有一个由 `kubeadm` 创建并运行着 1.11.0 或更高版本的 Kubernetes 集群。 + [Swap 必须被禁用][swap]. + 集群应使用静态的控制平面和 etcd pod。 +- 请务必认真阅读[发行说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md)。 +- 请务必备份所有重要组件,例如存储在数据库中应用层面的状态。 + `kubeadm upgrade` 不会触及您的工作负载,只会触及 Kubernetes 内部的组件,但备份终究是好的。 + +[swap]: https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux + + + +### 附加信息 + +- 升级后重新启动所有容器,因为容器 spec 的哈希值已更改。 +- 您只能从一个次版本升级到下一个次版本。 + 也就是说,升级时无法跳过版本。 + 例如,您只能从 1.10 升级到 1.11,而不能从 1.9 升级到 1.11。 + +{{% /capture %}} + +{{% capture steps %}} + + + + +## 升级控制平面 + +1. 在主节点上,升级 kubeadm: + + {{< tabs name="k8s_install" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + apt-get update + apt-get upgrade -y kubeadm + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + yum upgrade -y kubeadm --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. 验证下载是否有效并且是预期的版本 + + ```shell + kubeadm version + ``` + +1. 在主节点上,运行: + + ```shell + kubeadm upgrade plan + ``` + + + 您应该可以看到与下面类似的输出: + + ```shell + [preflight] Running pre-flight checks. + [upgrade] Making sure the cluster is healthy: + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [upgrade] Fetching available versions to upgrade to + [upgrade/versions] Cluster version: v1.11.3 + [upgrade/versions] kubeadm version: v1.12.0 + [upgrade/versions] Latest stable version: v1.11.3 + [upgrade/versions] Latest version in the v1.11 series: v1.11.3 + [upgrade/versions] Latest experimental version: v1.13.0-alpha.0 + + Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': + COMPONENT CURRENT AVAILABLE + Kubelet 2 x v1.11.1 v1.12.0 + 1 x v1.11.3 v1.12.0 + + Upgrade to the latest experimental version: + + COMPONENT CURRENT AVAILABLE + API Server v1.11.3 v1.12.0 + Controller Manager v1.11.3 v1.12.0 + Scheduler v1.11.3 v1.12.0 + Kube Proxy v1.11.3 v1.12.0 + CoreDNS 1.1.3 1.2.2 + Etcd 3.2.18 3.2.24 + + You can now apply the upgrade by executing the following command: + + kubeadm upgrade apply v1.12.0 + + _____________________________________________________________________ + + ``` + + 此命令检查您的集群是否可以升级,并可以获取到升级的版本。 + +1. 选择要升级到的版本,然后运行相应的命令。 例如: + + ```shell + kubeadm upgrade apply v1.12.0 + ``` + + 您应该可以看见与下面类似的输出: + + + ```shell + [preflight] Running pre-flight checks. + [upgrade] Making sure the cluster is healthy: + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [upgrade/apply] Respecting the --cri-socket flag that is set with higher priority than the config file. + [upgrade/version] You have chosen to change the cluster version to "v1.12.0" + [upgrade/versions] Cluster version: v1.11.3 + [upgrade/versions] kubeadm version: v1.12.0 + [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y + [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] + [upgrade/prepull] Prepulling image for component etcd. + [upgrade/prepull] Prepulling image for component kube-apiserver. + [upgrade/prepull] Prepulling image for component kube-controller-manager. + [upgrade/prepull] Prepulling image for component kube-scheduler. + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd + [upgrade/prepull] Prepulled image for component kube-apiserver. + [upgrade/prepull] Prepulled image for component kube-controller-manager. + [upgrade/prepull] Prepulled image for component kube-scheduler. + [upgrade/prepull] Prepulled image for component etcd. + [upgrade/prepull] Successfully prepulled the images for all the control plane components + [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.12.0"... + Static pod: kube-apiserver-ip-172-31-80-76 hash: d9b7af93990d702b3ee9a2beca93384b + Static pod: kube-controller-manager-ip-172-31-80-76 hash: 44a081fb5d26e90773ceb98b4e16fe10 + Static pod: kube-scheduler-ip-172-31-80-76 hash: 009228e74aef4d7babd7968782118d5e + Static pod: etcd-ip-172-31-80-76 hash: 997fcf3d8d974c98abc14556cc02617e + [etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests661777755/etcd.yaml" + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-09-19-18-58-14/etcd.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s + Static pod: etcd-ip-172-31-80-76 hash: 997fcf3d8d974c98abc14556cc02617e + + [apiclient] Found 1 Pods for label selector component=etcd + [upgrade/staticpods] Component "etcd" upgraded successfully! + [upgrade/etcd] Waiting for etcd to become available + [util/etcd] Waiting 0s for initial delay + [util/etcd] Attempting to see if all cluster endpoints are available 1/10 + [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests661777755" + [controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests661777755/kube-apiserver.yaml" + [controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests661777755/kube-controller-manager.yaml" + [controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests661777755/kube-scheduler.yaml" + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-09-19-18-58-14/kube-apiserver.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s + + Static pod: kube-apiserver-ip-172-31-80-76 hash: 854a5a8468f899093c6a967bb81dcfbc + [apiclient] Found 1 Pods for label selector component=kube-apiserver + [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-09-19-18-58-14/kube-controller-manager.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s + Static pod: kube-controller-manager-ip-172-31-80-76 hash: 44a081fb5d26e90773ceb98b4e16fe10 + Static pod: kube-controller-manager-ip-172-31-80-76 hash: b651f83474ae70031d5fb2cab73bd366 + [apiclient] Found 1 Pods for label selector component=kube-controller-manager + [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-09-19-18-58-14/kube-scheduler.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s + Static pod: kube-scheduler-ip-172-31-80-76 hash: 009228e74aef4d7babd7968782118d5e + Static pod: kube-scheduler-ip-172-31-80-76 hash: da406e5a49adfbbeb90fe2a0cf8fd8d1 + [apiclient] Found 1 Pods for label selector component=kube-scheduler + [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! + [uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace + [kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster + [kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace + [kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" + [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "ip-172-31-80-76" as an annotation + [bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials + [bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token + [bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster + [addons] Applied essential addon: CoreDNS + [addons] Applied essential addon: kube-proxy + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy! + + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` + +1. 手动升级软件定义网络(SDN)。 + + 您的容器网络接口(CNI)应该提供了程序自身的升级说明。 + 检查 [addons](/docs/concepts/cluster-administration/addons/) 页面以 + 查找您 CNI 所提供的程序,并查看是否需要其他升级步骤。 + + + + +## 升级主节点和其他节点的软件包 + +1. 准备为每个节点进行维护,将其标记为不可调度并移出工作负载: + + ```shell + kubectl drain $NODE --ignore-daemonsets + ``` + + 在 master 节点上,您必须增加 `--ignore-daemonsets`: + + ```shell + kubectl drain ip-172-31-85-18 + node "ip-172-31-85-18" cordoned + error: unable to drain node "ip-172-31-85-18", aborting command... + + There are pending nodes to be drained: + ip-172-31-85-18 + error: DaemonSet-managed pods (use --ignore-daemonsets to ignore): calico-node-5798d, kube-proxy-thjp9 + ``` + + ``` + kubectl drain ip-172-31-85-18 --ignore-daemonsets + node "ip-172-31-85-18" already cordoned + WARNING: Ignoring DaemonSet-managed pods: calico-node-5798d, kube-proxy-thjp9 + node "ip-172-31-85-18" drained + ``` + +1. 通过运行适用于您的 Linux 发行版包管理器,在每个 `$NODE` 节点上升级 Kubernetes 软件包版本: + + {{< tabs name="k8s_upgrade" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + apt-get update + apt-get upgrade -y kubelet kubeadm + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + yum upgrade -y kubelet kubeadm --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + + +{{% /capture %}} + +## 在每个节点上升级 kubelet + +1. 在除主节点之外的每个节点上,升级 kubelet 配置: + + ```shell + sudo kubeadm upgrade node config --kubelet-version $(kubelet --version | cut -d ' ' -f 2) + ``` + +1. 重启 kubelet 进程: + + ```shell + sudo systemctl restart kubelet + ``` + +1. 验证新版本的 `kubelet` 已经运行到了各个节点上。 + + ```shell + systemctl status kubelet + ``` + +1. 通过将节点标记为可调度,让节点重新上线: + + ```shell + kubectl uncordon $NODE + ``` + +1. 在所有节点上升级 kubelet 之后,通过以下命令验证所有的节点是否依旧可用,使得 kubectl 可以访问整个集群: + + ```shell + kubectl get nodes + ``` + + `STATUS` 列应显示所有节点为 `Ready` 状态,并且版本号已经被更新。 + + + +## 从故障状态恢复 + +如果 `kubeadm upgrade` 失败并且没有回滚,例如由于执行期间意外关闭,您可以再次运行 `kubeadm upgrade`。 +此命令是幂等的,并最终确保实际状态是您声明的所需状态。 +要从故障状态恢复,您还可以运行 `kubeadm upgrade --force` 而不去更改集群正在运行的版本。 + + + +## 它是怎么运作的 + +`kubeadm upgrade apply` 做了以下工作: + +- 检查您的集群是否处于可升级状态: + - API 服务器是可访问的 + - 所有节点处于 `Ready` 状态 + - 控制平面是健康的 +- 强制执行版本 skew 策略。 +- 确保控制平面的镜像是可用的或可拉取到服务器上。 +- 升级控制平面组件或回滚(如果其中任何一个组件无法启动)。 +- 应用新的 `kube-dns` 和 `kube-proxy` 清单,并强制创建所有必需的 RBAC 规则。 +- 如果旧文件在 180 天后过期,将创建 API 服务器的新证书和密钥文件并备份旧文件。 diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md new file mode 100644 index 0000000000..c0155be3cb --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md @@ -0,0 +1,425 @@ +--- +reviewers: +- jamiehannaford +- luxas +- timothysc +- jbeda +title: 将 kubeadm 高可用集群从 v1.11 升级到 v1.12 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本页介绍了如何将基于 kubeadm 创建的 Kubernetes HA 集群从 1.11.x 版本升级到 1.12.x 版本。除了升级,您还必须遵守[使用 kubeadm 创建 HA 集群](/docs/setup/independent/high-availability/) 的相关说明。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +在继续之前: + + + +- 您需要一个 1.11 或更高版本的 kubeadm 高可用集群。 +- 请务必仔细阅读[发行说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md)。 +- 确保备份所有重要组件,比如存储在数据库中的应用程序级状态。`kubeadm upgrade` 不涉及您的工作负载,只涉及 Kubernetes 内部的组件,但备份始终是最佳实践。 +- 检查[在 v1.11 到 v1.12 之间升级/降级 kubeadm 集群](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/) 的条件。 + +{{< note >}} + + +任何控制平面或 etcd 节点上的所有命令都应以 root 身份运行。 + +{{< /note >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 准备两种方法 + +升级 `kubeadm` 到与要升级到的 Kubernetes 版本匹配的版本: + +```shell +apt-mark unhold kubeadm && \ +apt-get update && apt-get install -y kubeadm && \ +apt-mark hold kubeadm +``` + + +检查条件并确定升级版本: + +```shell +kubeadm upgrade plan +``` + + +您应该看到如下内容: + + Upgrade to the latest stable version: + + COMPONENT CURRENT AVAILABLE + API Server v1.11.3 v1.12.0 + Controller Manager v1.11.3 v1.12.0 + Scheduler v1.11.3 v1.12.0 + Kube Proxy v1.11.3 v1.12.0 + CoreDNS 1.1.3 1.2.2 + Etcd 3.2.18 3.2.24 + + + +## 叠加控制平面节点 + +### 升级第一个控制平面节点 + +为该控制平面节点修改 `configmap/kubeadm-config` 文件: + +```shell +kubectl get configmap -n kube-system kubeadm-config -o yaml > kubeadm-config-cm.yaml +``` + + +在编辑器中打开文件并替换以下值: + + + + + + +- `api.advertiseAddress` + + 应将其设置为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.advertise-client-urls` + + 此值应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.initial-advertise-peer-urls` + + 此值应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.listen-client-urls` + + 此值应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.listen-peer-urls` + + 此值应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.initial-cluster` + + 应更新此项以包含群集中每个控制平面节点的主机名和 IP 地址对。例如: + + "ip-172-31-92-42=https://172.31.92.42:2380,ip-172-31-89-186=https://172.31.89.186:2380,ip-172-31-90-42=https://172.31.90.42:2380" + + +您还必须将另一个参数(`initial-cluster-state: existing`)传递给 etcd.local.extraArgs。 + +```shell +kubectl apply -f kubeadm-config-cm.yaml --force +``` + + +开始升级: + +```shell +kubeadm upgrade apply v +``` + + +您应该看到如下内容: + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy! + + + +`kubeadm-config` ConfigMap 现在从 `v1alpha2` 版本更新为 `v1alpha3`。 + +## 升级其他控制平面节点 + +每个额外的控制平面节点都需要与第一个控制平面节点做不同的修改。运行: + +```shell +kubectl get configmap -n kube-system kubeadm-config -o yaml > kubeadm-config-cm.yaml +``` + + +在编辑器中打开文件并为 `ClusterConfiguration` 替换以下值: + + + + +- `etcd.local.extraArgs.advertise-client-urls` + + 这应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.initial-advertise-peer-urls` + + 这应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.listen-client-urls` + + 这应该更新为本地节点的 IP 地址。 + +- `etcd.local.extraArgs.listen-peer-urls` + + 这应该更新为本地节点的 IP 地址。 + + +您还必须修改 `ClusterStatus`, 为 apiEndpoints 下的当前主机添加映射。 + +将 cri-socket 的注解添加到当前节点,例如使用 docker: + +```shell +kubectl annotate node kubeadm.alpha.kubernetes.io/cri-socket=/var/run/dockershim.sock +``` + + +在节点上应用修改后的 kubeadm-config: + +```shell +kubectl apply -f kubeadm-config-cm.yaml --force +``` + + +开始升级: + +```shell +kubeadm upgrade apply v +``` + + +您应该看到如下内容: + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy! + + + +## 外部 etcd + +### 升级每个控制平面 + +获取用于创建集群的 kubeadm 配置的副本。所有节点的配置应该相同。在升级开始之前,配置必须存在于每个控制平面节点上。 + + + +``` +# 在每个控制平面节点上 +kubectl get configmap -n kube-system kubeadm-config -o jsonpath={.data.MasterConfiguration} > kubeadm-config.yaml +``` + + +在编辑器中打开文件并设置 `api.advertiseAddress` 为本地节点的 IP 地址。 + +现在,在每个控制平面节点上分别执行升级命令。 + +``` +kubeadm upgrade apply v1.12.0 --config kubeadm-config.yaml +``` + + + +### 升级 etcd + +Kubernetes v1.11 至 v1.12 只将 etcd 的 patch 版本从 v3.2.18 更改为 v3.2.24。这是一个滚动升级,没有停机时间,因为您可以在同一个集群中运行两个版本。 + +在第一台主机上,修改 etcd 清单: + +```shell +sed -i 's/3.2.18/3.2.24/' /etc/kubernetes/manifests/etcd.yaml +``` + + + +等待 etcd 进程重新连接。其他 etcd 节点日志中将出现错误警告。这是预料之中的。 + +在其他 etcd 主机上重复此步骤。 + +## 下一步 + +### 手动升级您的 CNI 提供商 + +您的容器网络接口(CNI)提供程序可能有自己的升级说明。检查[插件](/docs/concepts/cluster-administration/addons/)页面找到您的 CNI 提供商,看看是否需要采取其他升级步骤。 + +### 更新 kubelet 和 kubectl 包 + +通过在每个节点上运行以下命令来升级 kubelet 和 kubectl: + + + +```shell +# 使用你的发行版软件包管理器,例如基于 Debian 系统上的 'apt-get' +# 对于版本,基于 kubeadm 的输出来设置(参见上文) +apt-mark unhold kubelet kubectl && \ +apt-get update && \ +apt-get install kubelet= kubectl= && \ +apt-mark hold kubelet kubectl && \ +systemctl restart kubelet +``` + + +本例假设使用一个基于 _deb_ 的系统,并使用 `apt-get` 安装升级后的软件。在基于 rpm 的系统上,对于所有软件包都使用 `yum install =` 命令。 + +验证新版本的 `kubelet` 是否正在运行: + +```shell +systemctl status kubelet +``` + + +无论当前路径在哪里,使用 `kubectl` 运行以下命令,再次验证已升级的节点是否可用: + +```shell +kubectl get nodes +``` + + +如果对于升级后的主机其 `STATUS` 列显示 `Ready`,则可以继续;否则您可能需要重复该命令,直到节点显示 `Ready`。 + + + +## 如果出现问题 + +如果升级失败,请检查是否符合以下列出的可能场景: + +- 如果 `kubeadm upgrade apply` 无法升级集群,它将尝试执行回滚。如果在第一个主控节点上就是这种情况,则集群可能仍然完好无损。 + + 您可以再次运行 `kubeadm upgrade apply`,因为它是幂等的,最终应该确保实际状态是您声明的期望状态。您可以运行 `kubeadm upgrade apply` 并设置参数 `--force` 请求"更新"正在运行的集群(从 `x.x.x --> x.x.x` ),尝试从错误状态中恢复。 + +- 如果其他节点上的 `kubeadm upgrade apply` 失败,则集群已经升级并运行,只是这些节点处于未定义的状态。您需要进一步调试并手动将其加入集群。 + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md index e6ce55345e..9d5ade5e19 100644 --- a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md @@ -1,66 +1,137 @@ --- -approvers: +reviewers: - mtaufen - dawnchen -cn-approvers: -- xiaosuiba -cn-reviwers: -- pigletfly -- zjj2wry -- chentao1596 title: 通过配置文件设置 Kubelet 参数 content_template: templates/task --- - + {{% capture overview %}} -{{< feature-state state="alpha" >}} +{{< feature-state state="beta" >}} + +通过保存在硬盘的配置文件设置 Kubelet 的配置参数子集,可以作为命令行参数的替代。此功能在 v1.10 中为 beta 版。 + + +建议通过配置文件的方式提供参数,因为这样可以简化节点部署和配置管理。 -在 Kubernetes 1.8 版本上,除了可以通过命令行参数外,还可以通过保存在硬盘的配置文件设置 Kubelet 的配置子集。 -将来,大部分现存的命令行参数都将被废弃,取而代之以配置文件的方式提供参数,以简化节点部署过程。 {{% /capture %}} {{% capture prerequisites %}} - -- 需要安装 1.8 版本或更高版本的 Kubelet 二进制文件。 + +- 需要安装 1.10 或更高版本的 Kubelet 二进制文件,才能实现 beta 功能。 {{% /capture %}} {{% capture steps %}} - + ## 创建配置文件 + +`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集,该结构体在 [这里(v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/config/types.go) 可以找到。 -`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集,该结构体在 [这里(v1alpha1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go) 可以找到。配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。请注意,这个结构体及配置文件 API 仍然为 alpha 版本,对其稳定性不作保证。 + +配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。确保 Kubelet 可以读取该文件。 + +下面的示例是这个文件的结构 +``` +kind: KubeletConfiguration +apiVersion: kubelet.config.k8s.io/v1beta1 +evictionHard: + memory.available: "200Mi" +``` + +在该示例中,Kubelet 的配置是当可用内存低于 200Mi 时驱逐 Pods。除非被参数覆盖,否则其他 Kubelet 配置值都保留其内置默认值。命令行参数与配置文件有相同的值时,将会覆盖配置文件中的该值。 -在单独的文件夹中创建一个名为 `kubelet` 的文件,并保证 Kubelet 可以读取该文件夹及文件。您应该在这个 `kubelet` 文件中编写 Kubelet 配置。 - - -作为一个小技巧,您可以从活动节点生成配置文件,相关方法请查看 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。 - + +有关从活动节点生成配置文件的技巧,请参阅 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。 + ## 启动通过配置文件配置的 Kubelet 进程 + +启动 Kubelet 需要将 `--config` 参数设置为 Kubelet 配置文件的路径。Kubelet 将从此文件加载其配置。 -启动 Kubelet 需要将其 `--init-config-dir` 标志设置为包含 `kubelet` 文件的文件夹路径。Kubelet 将从 `kubelet` 文件中读取由 `KubeletConfiguration` 定义的参数,而不是从参数相关的命令行标志中读取。 + +请注意,命令行参数与配置文件有相同的值时,就会覆盖配置文件中的该值。这有助于确保命令行 API 的向后兼容性。 + + +请注意,Kubelet 配置文件中的相对文件路径是相对于 Kubelet 配置文件的位置解析的,而命令行参数中的相对路径是相对于 Kubelet 的当前工作目录解析的。 + + +请注意,命令行参数和 Kubelet 配置文件的某些默认值不同。如果设置了 `--config`,并且没有通过命令行指定值,则 `KubeletConfiguration` 版本的默认值生效。在上面的例子中,version 是 `kubelet.config.k8s.io/v1beta1`。 {{% /capture %}} {{% capture discussion %}} - + ## 与动态 Kubelet 配置的关系 - -如果您正在使用 [动态 Kubelet 配置(Dynamic Kubelet Configuration)](/docs/tasks/administer-cluster/reconfigure-kubelet) 特性,那么自动回滚机制将认为通过 `--init-config-dir` 提供的配置是“最后已知正常(last known good)”的配置。 - - -请注意,`--init-config-dir` 文件的布局结构镜像了 ConfigMap 中用于动态 Kubelet 配置的数据结构;文件命名和 ConfigMap 的 key 相同,文件的内容是 ConfigMap 中相同数据结构的 JSON 或 YAML 表现形式。虽然以后可能会出现更多,但目前只有 kubelet:KubeletConfiguration 配置对。更多信息请查阅 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。 - + +如果您正在使用 [动态 Kubelet 配置](/docs/tasks/administer-cluster/reconfigure-kubelet) 特性,那么自动回滚机制将认为是 "最后已知正常(last known good)" 的配置,通过 `--config` 提供的配置与覆盖这些值的任何参数的结合。 {{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md new file mode 100644 index 0000000000..e8cadbd4b2 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -0,0 +1,143 @@ +--- +title: 限制存储消耗 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +此示例演示了一种限制命名空间中存储使用量的简便方法。 + + +演示中用到了以下资源:[ResourceQuota](/docs/concepts/policy/resource-quotas/),[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/) 和 [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + +## 场景:限制存储消耗 + + +集群管理员代表用户群操作集群,管理员希望控制单个名称空间可以消耗多少存储空间以控制成本。 + + +管理员想要限制: + + +1. 命名空间中持久卷申领(persistent volume claims)的数量 +2. 每个申领(claim)可以请求的存储量 +3. 命名空间可以具有的累计存储量 + + +## 使用 LimitRange 限制存储请求 + + +将 `LimitRange` 添加到命名空间会为存储请求大小强制设置最小值和最大值。存储是通过 `PersistentVolumeClaim` 来发起请求的。执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。 + + +在此示例中,请求 10Gi 存储的 PVC 将被拒绝,因为它超过了最大 2Gi。 + +``` +apiVersion: v1 +kind: LimitRange +metadata: + name: storagelimits +spec: + limits: + - type: PersistentVolumeClaim + max: + storage: 2Gi + min: + storage: 1Gi +``` + + +当底层存储提供程序需要某些最小值时,将会用到所设置最小存储请求值。例如,AWS EBS volumes 的最低要求为 1Gi。 + + +## 使用 StorageQuota 限制 PVC 数目和累计存储容量 + + +管理员可以限制某个命名空间中的 PVCs 个数以及这些 PVCs 的累计容量。新 PVCs 请求如果超过任一上限值将被拒绝。 + + +在此示例中,命名空间中的第 6 个 PVC 将被拒绝,因为它超过了最大计数 5。或者,当与上面的 2Gi 最大容量限制结合在一起时,意味着 5Gi 的最大配额不能支持 3 个都是 2Gi 的 PVC。后者实际上是向命名空间请求 6Gi 容量,而该命令空间已经设置上限为 5Gi。 + +``` +apiVersion: v1 +kind: ResourceQuota +metadata: + name: storagequota +spec: + hard: + persistentvolumeclaims: "5" + requests.storage: "5Gi" +``` + +{{% /capture %}} + +{{% capture discussion %}} + + +## 小结 + + +限制范围对象可以用来设置可请求的存储量上限,而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/_index.md b/content/zh/docs/tasks/administer-cluster/manage-resources/_index.md index cdc4c457a5..8fcbf33fe5 100644 --- a/content/zh/docs/tasks/administer-cluster/manage-resources/_index.md +++ b/content/zh/docs/tasks/administer-cluster/manage-resources/_index.md @@ -1,12 +1,11 @@ +--- +title: 管理内存,CPU 和 API 资源 +weight: 20 +--- + - ---- -title: 管理内存,CPU 和 API 资源 -weight: 20 ---- - diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 41f6af4b29..8607d283b6 100644 --- a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -1,3 +1,9 @@ +--- +title: 为命名空间配置CPU最小和最大限制 +content_template: templates/task +weight: 40 +--- + ---- -title: 为命名空间配置CPU最小和最大限制 -content_template: templates/task -weight: 40 ---- - - {{% capture overview %}} ---- -title: 为命名空间配置默认的CPU请求和限制 -content_template: templates/task -weight: 20 ---- - {{% capture overview %}} -* [为容器和Pod分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) +* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) -* [为容器和Pod分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [为Pod配置Service数量](/docs/tasks/configure-pod-container/quality-service-pod/) +* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/) {{% /capture %}} - - diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 84149f2b1e..0fd7481edc 100644 --- a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -1,3 +1,9 @@ +--- +title: 配置命名空间的最小和最大内存约束 +content_template: templates/task +weight: 30 +--- + ---- -title: 配置命名空间的最小和最大内存约束 -content_template: templates/task -weight: 30 ---- - {{% capture overview %}} ---- -title: 为命名空间配置默认的内存请求和限制 -content_template: templates/task -weight: 10 ---- - {{% capture overview %}} * 运行在命名空间中的每个容器必须有自己的内存限制。 -* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。 +* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。 ---- -title: 为命名空间配置内存和 CPU 配额 -content_template: templates/task -weight: 50 ---- - - {{% capture overview %}} + +{{% capture overview %}} + + + +本文介绍怎样给命名空间配置可以运行的 Pod 总数配额。你在 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)对象中可以进行声明。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 创建命名空间 + +创建一个命名空间,以便本练习所创建的资源和集群的其余资源相隔离。 + +```shell +kubectl create namespace quota-pod-example +``` + + + +## 创建一个 ResourceQuota + +这里给出了一个 ResourceQuota 对象的配置文件: + +{{< codenew file="admin/resource/quota-pod.yaml" >}} + + + +创建 ResourceQuota + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example +``` + + + +查看 ResourceQuota 详情: + +```shell +kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml +``` + + + +输出结果显示该命名空间有两个 Pod 的配额,并且当前没有 Pod;也就是配额没有被使用。 + +```yaml +spec: + hard: + pods: "2" +status: + hard: + pods: "2" + used: + pods: "0" +``` + + + +这里给出了一个 Deployment 的配置文件: + +{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}} + + + +配置文件中,`replicas: 3` 使 Kubernetes 尝试创建3个 Pod,都运行相同的应用。 + +创建 Deployment: + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example +``` + + + +查看 Deployment 详情: + +```shell +kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml +``` + + + +输出结果显示尽管 Deployment 声明了三个副本,但由于配额的限制只创建了两个 Pod。 + +```yaml +spec: + ... + replicas: 3 +... +status: + availableReplicas: 2 +... +lastUpdateTime: 2017-07-07T20:57:05Z + message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden: + exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2' +``` + + + +## 清理环境 + +删除你的命名空间: + +```shell +kubectl delete namespace quota-pod-example +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +### 集群管理员参考 + +* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/) + + + +### 应用开发者参考 + +* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) + +* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/) + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 78d0d8e675..8b5d304fc7 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -65,17 +65,19 @@ weight: 10 ``` Calico 的 pods 名以 `calico` 打头,检查确认每个 pods 状态为 `Running`。 + + +--> ## 使用 kubeadm 创建一个本地 Calico 集群 -在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群,请参考 -[Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。 +在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群,请参考 [Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。 {{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 26eb7434ba..3dccf47430 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -34,13 +34,16 @@ The Weave Net addon for Kubernetes comes with a [Network Policy Controller](http 按照[通过插件集成Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)指南。 Kubernetes 的 Weave Net 插件带有[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc),可自动监控 Kubernetes 所有名称空间中的任何 NetworkPolicy 注释。 配置`iptables`规则以允许或阻止策略指示的流量。 - + +--> ## 测试安装 diff --git a/content/zh/docs/tasks/administer-cluster/out-of-resource.md b/content/zh/docs/tasks/administer-cluster/out-of-resource.md new file mode 100644 index 0000000000..87ff04089f --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/out-of-resource.md @@ -0,0 +1,667 @@ +--- +reviewers: +- derekwaynecarr +- vishh +- timstclair +title: 配置资源不足时的处理方式 +content_template: templates/concept +--- + + +{{% capture overview %}} + + +本页介绍了如何使用 `kubelet` 配置资源不足时的处理方式。 + +当可用计算资源较少时,`kubelet` 需要保证节点稳定性。这在处理如内存和硬盘之类的不可压缩资源时尤为重要。如果任意一种资源耗尽,节点将会变得不稳定。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 驱逐策略 + +`kubelet` 能够主动监测和防止计算资源的全面短缺。在那种情况下,`kubelet` 可以主动地结束一个或多个 pod 以回收短缺的资源。当 `kubelet` 结束一个 pod 时,它将终止 pod 中的所有容器,而 pod 的 `PodPhase` 将变为 `Failed`。 + + +### 驱逐信号 + +`kubelet` 支持按照以下表格中描述的信号触发驱逐决定。每个信号的值在 description 列描述,基于 `kubelet` 摘要 API。 + +| 驱逐信号 | 描述 | +|----------------------------|-----------------------------------------------------------------------| +| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` | +| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` | +| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` | +| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` | +| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` | + +上面的每个信号都支持字面值或百分比的值。基于百分比的值的计算与每个信号对应的总容量相关。 + +`memory.available` 的值从 cgroupfs 获取,而不是通过类似 `free -m` 的工具。这很重要,因为 `free -m` 不能在容器中工作,并且如果用户使用了[可分配节点](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)特性,资源不足的判定将同时在本地 cgroup 层次结构的终端用户 pod 部分和根节点做出。这个[脚本](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)复现了与 `kubelet` 计算 `memory.available` 相同的步骤。`kubelet` 将 inactive_file(意即活动 LRU 列表上基于文件后端的内存字节数)从计算中排除,因为它假设内存在出现压力时将被回收。 + +`kubelet` 只支持两种文件系统分区。 + +1. `nodefs` 文件系统,kubelet 将其用于卷和守护程序日志等。 +2. `imagefs` 文件系统,容器运行时用于保存镜像和容器可写层。 + +`imagefs` 可选。`kubelet` 使用 cAdvisor 自动发现这些文件系统。`kubelet` 不关心其它文件系统。当前不支持配置任何其它类型。例如,在专用`文件系统`中存储卷和日志是不可以的。 + +在将来的发布中,`kubelet` 将废除当前存在的[垃圾回收](/docs/concepts/cluster-administration/kubelet-garbage-collection/)机制,这种机制目前支持将驱逐操作作为对磁盘压力的响应。 + + +### 驱逐阈值 + +`kubelet` 支持指定驱逐阈值,用于触发 `kubelet` 回收资源。 + +每个阈值形式如下: + +`[eviction-signal][operator][quantity]` + +* 合法的 `eviction-signal` 标志如上所示。 +* `operator` 是所需的关系运算符,例如 `<`。 +* `quantity` 是驱逐阈值值标志,例如 `1Gi`。合法的标志必须匹配 Kubernetes 使用的数量表示。驱逐阈值也可以使用 `%` 标记表示百分比。 + +举例说明,如果一个节点有 `10Gi` 内存,希望在可用内存下降到 `1Gi` 以下时引起驱逐操作,则驱逐阈值可以使用下面任意一种方式指定(但不是两者同时)。 + +* `memory.available<10%` +* `memory.available<1Gi` + + +#### 软驱逐阈值 + +软驱逐阈值使用一对由驱逐阈值和管理员必须指定的宽限期组成的配置对。在超过宽限期前,`kubelet` 不会采取任何动作回收和驱逐信号关联的资源。如果没有提供宽限期,`kubelet` 启动时将报错。 + +此外,如果达到了软驱逐阈值,操作员可以指定从节点驱逐 pod 时,在宽限期内允许结束的 pod 的最大数量。如果指定了 `pod.Spec.TerminationGracePeriodSeconds` 值,`kubelet` 将使用它和宽限期二者中较小的一个。如果没有指定,`kubelet` 将立即终止 pod,而不会优雅结束它们。 + +软驱逐阈值的配置支持下列标记: + +* `eviction-soft` 描述了驱逐阈值的集合(例如 `memory.available<1.5Gi`),如果在宽限期之外满足条件将触发 pod 驱逐。 +* `eviction-soft-grace-period` 描述了驱逐宽限期的集合(例如 `memory.available=1m30s`),对应于在驱逐 pod 前软驱逐阈值应该被控制的时长。 +* `eviction-max-pod-grace-period` 描述了当满足软驱逐阈值并终止 pod 时允许的最大宽限期值(秒数)。 + + +#### 硬驱逐阈值 + +硬驱逐阈值没有宽限期,一旦察觉,`kubelet` 将立即采取行动回收关联的短缺资源。如果满足硬驱逐阈值,`kubelet` 将立即结束 pod 而不是优雅终止。 + +硬驱逐阈值的配置支持下列标记: + +* `eviction-hard` 描述了驱逐阈值的集合(例如 `memory.available<1Gi`),如果满足条件将触发 pod 驱逐。 + +`kubelet` 有如下所示的默认硬驱逐阈值: + +* `memory.available<100Mi` +* `nodefs.available<10%` +* `nodefs.inodesFree<5%` +* `imagefs.available<15%` + + +### 驱逐监控时间间隔 + +`kubelet` 根据其配置的整理时间间隔计算驱逐阈值。 + +* `housekeeping-interval` 是容器管理时间间隔。 + + +### 节点状态 + +`kubelet` 会将一个或多个驱逐信号映射到对应的节点状态。 + +如果满足硬驱逐阈值,或者满足独立于其关联宽限期的软驱逐阈值时,`kubelet` 将报告节点处于压力下的状态。 + +下列节点状态根据相应的驱逐信号定义。 + +| 节点状态 | 驱逐信号 | 描述 | +|-------------------------|-------------------------------|--------------------------------------------| +| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold | +| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold | + +`kubelet` 将以 `--node-status-update-frequency` 指定的频率连续报告节点状态更新,其默认值为 `10s`。 + + +### 节点状态振荡 + +如果节点在软驱逐阈值的上下振荡,但没有超过关联的宽限期时,将引起对应节点的状态持续在 true 和 false 间跳变,并导致不好的调度结果。 + +为了防止这种振荡,可以定义下面的标志,用于控制 `kubelet` 从压力状态中退出之前必须等待的时间。 + +* `eviction-pressure-transition-period` 是 `kubelet` 从压力状态中退出之前必须等待的时长。 + +`kubelet` 将确保在设定的时间段内没有发现和指定压力条件相对应的驱逐阈值被满足时,才会将状态变回 `false`。 + + +### 回收节点层级资源 + +如果满足驱逐阈值并超过了宽限期,`kubelet` 将启动回收压力资源的过程,直到它发现低于设定阈值的信号为止。 + +`kubelet` 将尝试在驱逐终端用户 pod 前回收节点层级资源。发现磁盘压力时,如果节点针对容器运行时配置有独占的 `imagefs`,`kubelet` 回收节点层级资源的方式将会不同。 + + +#### 使用 `Imagefs` + +如果 `nodefs` 文件系统满足驱逐阈值,`kubelet` 通过驱逐 pod 及其容器来释放磁盘空间。 + +如果 `imagefs` 文件系统满足驱逐阈值,`kubelet` 通过删除所有未使用的镜像来释放磁盘空间。 + +#### 未使用 `Imagefs` + +如果 `nodefs` 满足驱逐阈值,`kubelet` 将以下面的顺序释放磁盘空间: + +1. 删除停止运行的 pod/container +2. 删除全部没有使用的镜像 + + +### 驱逐最终用户的 pod + +如果 `kubelet` 在节点上无法回收足够的资源,`kubelet` 将开始驱逐 pod。 + +`kubelet` 首先根据他们对短缺资源的使用是否超过请求来排除 pod 的驱逐行为,然后通过[优先级](/docs/concepts/configuration/pod-priority-preemption/),然后通过相对于 pod 的调度请求消耗急需的计算资源。 + +`kubelet` 按以下顺序对要驱逐的 pod 排名: + +* `BestEffort` 或 `Burstable`,其对短缺资源的使用超过了其请求,此类 pod 按优先级排序,然后使用高于请求。 +* `Guaranteed` pod 和 `Burstable` pod,其使用率低于请求,最后被驱逐。`Guaranteed` pod 只有为所有的容器指定了要求和限制并且它们相等时才能得到保证。由于另一个 pod 的资源消耗,这些 pod 保证永远不会被驱逐。如果系统守护进程(例如 `kubelet`、`docker`、和 `journald`)消耗的资源多于通过 `system-reserved` 或 `kube-reserved` 分配保留的资源,并且该节点只有 `Guaranteed` 或 `Burstable` pod 使用少于剩余的请求,然后节点必须选择驱逐这样的 pod 以保持节点的稳定性并限制意外消耗对其他 pod 的影响。在这种情况下,它将首先驱逐优先级最低的 pod。 + +必要时,`kubelet` 会在遇到 `DiskPressure` 时驱逐一个 pod 来回收磁盘空间。如果 `kubelet` 响应 `inode` 短缺,它会首先驱逐服务质量最低的 pod 来回收 `inodes`。如果 `kubelet` 响应缺少可用磁盘,它会将 pod 排在服务质量范围内,该服务会消耗大量的磁盘并首先结束这些磁盘。 + + +#### 使用 `imagefs` + +如果是 `nodefs` 触发驱逐,`kubelet` 将按 `nodefs` 用量 - 本地卷 + pod 的所有容器日志的总和对其排序。 + +如果是 `imagefs` 触发驱逐,`kubelet` 将按 pod 所有可写层的用量对其进行排序。 + +#### 未使用 `imagefs` + +如果是 `nodefs` 触发驱逐,`kubelet` 会根据磁盘的总使用情况对 pod 进行排序 - 本地卷 + 所有容器的日志及其可写层。 + + +### 最小驱逐回收 + +在某些场景,驱逐 pod 会导致回收少量资源。这将导致 `kubelet` 反复碰到驱逐阈值。除此之外,对如 `disk` 这类资源的驱逐时比较耗时的。 + +为了减少这类问题,`kubelet` 可以为每个资源配置一个 `minimum-reclaim`。当 `kubelet` 发现资源压力时,`kubelet` 将尝试至少回收驱逐阈值之下 `minimum-reclaim` 数量的资源。 + +例如使用下面的配置: + +``` +--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi +--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"` +``` + +如果 `memory.available` 驱逐阈值被触发,`kubelet` 将保证 `memory.available` 至少为 `500Mi`。对于 `nodefs.available`,`kubelet` 将保证 `nodefs.available` 至少为 `1.5Gi`。对于 `imagefs.available`,`kubelet` 将保证 `imagefs.available` 至少为 `102Gi`,直到不再有相关资源报告压力为止。 + +所有资源的默认 `eviction-minimum-reclaim` 值为 `0`。 + + +### 调度器 + +当资源处于压力之下时,节点将报告状态。调度器将那种状态视为一种信号,阻止更多 pod 调度到这个节点上。 + +| 节点状态 | 调度器行为 | +| ---------------- | ------------------------------------------------ | +| `MemoryPressure` | No new `BestEffort` Pods are scheduled to the node. | +| `DiskPressure` | No new Pods are scheduled to the node. | + + +## 节点 OOM 行为 + +如果节点在 `kubelet` 回收内存之前经历了系统 OOM(内存不足) 事件,它将基于 [oom_killer](https://lwn.net/Articles/391222/) 做出响应。 + +`kubelet` 基于 pod 的 service 质量为每个容器设置一个 `oom_score_adj` 值。 + +| Service 质量 | oom_score_adj | +|----------------------------|-----------------------------------------------------------------------| +| `Guaranteed` | -998 | +| `BestEffort` | 1000 | +| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) | + +如果 `kubelet` 在节点经历系统 OOM 之前无法回收内存,`oom_killer` 将基于它在节点上使用的内存百分比算出一个 `oom_score`,并加上 `oom_score_adj` 得到容器的有效 `oom_score`,然后结束得分最高的容器。 + +预期的行为应该是拥有最低 service 质量并消耗和调度请求相关内存量最多的容器第一个被结束,以回收内存。 + +和 pod 驱逐不同,如果一个 pod 的容器是被 OOM 结束的,基于其 `RestartPolicy`,它可能会被 `kubelet` 重新启动。 + + +## 最佳实践 + +以下部分描述了资源外处理的最佳实践。 + +### 可调度资源和驱逐策略 + +考虑以下场景: + +* 节点内存容量:`10Gi` +* 操作员希望为系统守护进程保留 10% 内存容量(内核、`kubelet` 等)。 +* 操作员希望在内存用量达到 95% 时驱逐 pod,以减少对系统的冲击并防止系统 OOM 的发生。 + +为了促成这个场景,`kubelet` 将像下面这样启动: + +``` +--eviction-hard=memory.available<500Mi +--system-reserved=memory=1.5Gi +``` + +这个配置的暗示是理解“系统保留”应该包含被驱逐阈值覆盖的内存数量。 + +要达到这个容量,要么某些 pod 使用了超过它们请求的资源,要么系统使用的内存超过 `1.5Gi - 500Mi = 1Gi`。 + +这个配置将保证在 pod 使用量都不超过它们配置的请求值时,如果可能立即引起内存压力并触发驱逐时,调度器不会将 pod 放到这个节点上。 + + +### DaemonSet + +我们永远都不希望 `kubelet` 驱逐一个从 `DaemonSet` 派生的 pod,因为这个 pod 将立即被重建并调度回相同的节点。 + +目前,`kubelet` 没有办法区分一个 pod 是由 `DaemonSet` 还是其他对象创建。如果/当这个信息可用时,`kubelet` 可能会预先将这些 pod 从提供给驱逐策略的候选集合中过滤掉。 + +总之,强烈推荐 `DaemonSet` 不要创建 `BestEffort` 的 pod,防止其被识别为驱逐的候选 pod。相反,理想情况下 `DaemonSet` 应该启动 `Guaranteed` 的 pod。 + + +## 弃用现有特性标签以回收磁盘 + +`kubelet` 已经按需求清空了磁盘空间以保证节点稳定性。 + +当磁盘驱逐成熟时,下面的 `kubelet` 标志将被标记为废弃的,以简化支持驱逐的配置。 + +| 现有标签 | 新标签 | +| ------------- | -------- | +| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | +| `--maximum-dead-containers` | deprecated | +| `--maximum-dead-containers-per-container` | deprecated | +| `--minimum-container-ttl-duration` | deprecated | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | + + +## 已知问题 + +以下部分描述了与资源外处理有关的已知问题。 + +### kubelet 可能无法立即发现内存压力 + +`kubelet` 当前通过以固定的时间间隔轮询 `cAdvisor` 来收集内存使用数据。如果内存使用在那个时间窗口内迅速增长,`kubelet` 可能不能足够快的发现 `MemoryPressure`,`OOMKiller` 将不会被调用。我们准备在将来的发行版本中通过集成 `memcg` 通知 API 来减小这种延迟。当超过阈值时,内核将立即告诉我们。 + +如果您想处理可察觉的超量使用而不要求极端精准,可以设置驱逐阈值为大约 75% 容量作为这个问题的变通手段。这将增强这个特性的能力,防止系统 OOM,并提升负载卸载能力,以再次平衡集群状态。 + + +### kubelet 可能会驱逐超过需求数量的 pod + +由于状态采集的时间差,驱逐操作可能驱逐比所需的更多的 pod。将来可通过添加从根容器获取所需状态的能力 [(https://github.com/google/cadvisor/issues/1247)]([(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247)) 来减缓这种状况。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/quota-api-object.md b/content/zh/docs/tasks/administer-cluster/quota-api-object.md new file mode 100644 index 0000000000..67249bd075 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/quota-api-object.md @@ -0,0 +1,274 @@ +--- +title: 配置 API 对象配额 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本文讨论如何为 API 对象配置配额,包括 PersistentVolumeClaims 和 Services。 +配额限制了可以在命名空间中创建的特定类型对象的数量。 +您可以在 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) 对象中指定配额。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 创建命名空间 + +创建一个命名空间以便本例中创建的资源和集群中的其余部分相隔离。 + +```shell +kubectl create namespace quota-object-example +``` + + + +## 创建 ResourceQuota + +下面是一个 ResourceQuota 对象的配置文件: + +{{< codenew file="admin/resource/quota-objects.yaml" >}} + + + +创建 ResourceQuota + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example +``` + + + +查看 ResourceQuota 的详细信息: + +```shell +kubectl get resourcequota object-quota-demo --namespace=quota-object-example --output=yaml +``` + + + +输出结果表明在 quota-object-example 命名空间中,至多只能有一个 PersistentVolumeClaim,最多两个 LoadBalancer 类型的服务,不能有 NodePort 类型的服务。 + + +```yaml +status: + hard: + persistentvolumeclaims: "1" + services.loadbalancers: "2" + services.nodeports: "0" + used: + persistentvolumeclaims: "0" + services.loadbalancers: "0" + services.nodeports: "0" +``` + + + +## 创建 PersistentVolumeClaim + +下面是一个 PersistentVolumeClaim 对象的配置文件: + +{{< codenew file="admin/resource/quota-objects-pvc.yaml" >}} + + + +创建 PersistentVolumeClaim: + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example +``` + + + +确认已创建完 PersistentVolumeClaim: + +```shell +kubectl get persistentvolumeclaims --namespace=quota-object-example +``` + + + +输出信息表明 PersistentVolumeClaim 存在并且处于 Pending 状态: + +```shell +NAME STATUS +pvc-quota-demo Pending +``` + + + +## 尝试创建第二个 PersistentVolumeClaim + +下面是第二个 PersistentVolumeClaim 的配置文件: + +{{< codenew file="admin/resource/quota-objects-pvc-2.yaml" >}} + + + +尝试创建第二个 PersistentVolumeClaim: + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc-2.yaml --namespace=quota-object-example +``` + + +输出信息表明第二个 PersistentVolumeClaim 没有创建成功,因为这会超出命名空间的配额。 + + +``` +persistentvolumeclaims "pvc-quota-demo-2" is forbidden: +exceeded quota: object-quota-demo, requested: persistentvolumeclaims=1, +used: persistentvolumeclaims=1, limited: persistentvolumeclaims=1 +``` + + +## 注意事项 + +下面这些字符串可被用来标识那些能被配额限制的 API 资源: + + + + + + + + + + + + +
StringAPI Object
"pods"Pod
"servicesService
"replicationcontrollers"ReplicationController
"resourcequotas"ResourceQuota
"secrets"Secret
"configmaps"ConfigMap
"persistentvolumeclaims"PersistentVolumeClaim
"services.nodeports"Service of type NodePort
"services.loadbalancers"Service of type LoadBalancer
+ + + +## 清理 + +删除您的命名空间: + +```shell +kubectl delete namespace quota-object-example +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +### 集群管理员参考 + +* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [为命名空间配置内存的最小和最大限制](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [为命名空间配置 CPU 的最小和最大限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [为命名空间配置 CPU 和内存配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/) + + + +### 应用开发者参考 + +* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) +* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [为 Pod 配置服务质量](/docs/tasks/configure-pod-container/quality-service-pod/) + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/administer-cluster/static-pod.md b/content/zh/docs/tasks/administer-cluster/static-pod.md index 0539e1e8ed..7c0c3479ac 100644 --- a/content/zh/docs/tasks/administer-cluster/static-pod.md +++ b/content/zh/docs/tasks/administer-cluster/static-pod.md @@ -1,32 +1,32 @@ --- approvers: - jsafrane -title: 静态Pods +title: 静态 Pods --- -**如果你正在运行Kubernetes集群并且使用静态pods在每个节点上起一个pod,那么最好使用[DaemonSet](/cn/docs/concepts/workloads/controllers/daemonset/)!** +**如果你正在运行 Kubernetes 集群并且使用静态 pods 在每个节点上起一个 pod,那么最好使用 [DaemonSet](/cn/docs/concepts/workloads/controllers/daemonset/)!** -*静态pods*直接由特定节点上的kubelet进程来管理,不通过主控节点上的API服务器。静态pod不关联任何replication controller,它由kubelet进程自己来监控,当pod崩溃时重启该pod。对于静态pod没有健康检查。静态pod始终绑定在某一个kubelet,并且始终运行在同一个节点上。 +*静态 pods* 直接由特定节点上的 kubelet 进程来管理,不通过主控节点上的 API 服务器。静态 pod 不关联任何 replication controller,它由 kubelet 进程自己来监控,当 pod 崩溃时重启该 pod。对于静态 pod 没有健康检查。静态 pod 始终绑定在某一个 kubelet,并且始终运行在同一个节点上。 -Kubelet自动为每一个静态pod在Kubernetes的API服务器上创建一个镜像Pod(Mirror Pod),因此可以在API服务器查询到该pod,但是不被API服务器控制(例如不能删除)。 +Kubelet 自动为每一个静态 pod 在 Kubernetes 的 API 服务器上创建一个镜像 Pod(Mirror Pod),因此可以在 API 服务器查询到该 pod,但是不被 API 服务器控制(例如不能删除)。 -## 静态pod创建 +## 静态 pod 创建 -静态pod有两种创建方式:用配置文件或者通过HTTP。 +静态 pod 有两种创建方式:用配置文件或者通过 HTTP。 ### 配置文件 -配置文件就是放在特定目录下的标准的JSON或YAML格式的pod定义文件。用`kubelet --pod-manifest-path=`来启动kubelet进程,kubelet将会周期扫描这个目录,根据这个目录下出现或消失的YAML/JSON文件来创建或删除静态pod。 +配置文件就是放在特定目录下的标准的 JSON 或 YAML 格式的 pod 定义文件。用`kubelet --pod-manifest-path=`来启动 kubelet 进程,kubelet 将会周期扫描这个目录,根据这个目录下出现或消失的 YAML/JSON 文件来创建或删除静态 pod。 -下面例子用静态pod的方式启动一个nginx的Web服务器: +下面例子用静态 pod 的方式启动一个 nginx 的 Web 服务器: -1. 选择一个节点来运行静态pod。这个例子中就是`my-node1`。 +1. 选择一个节点来运行静态 pod。这个例子中就是`my-node1`。 ``` [joe@host ~] $ ssh my-node1 ``` -2. 选择一个目录,例如/etc/kubelet.d,把web服务器的pod定义文件放在这个目录下,例如`/etc/kubelet.d/static-web.yaml`: +2. 选择一个目录,例如/etc/kubelet.d,把 web 服务器的 pod 定义文件放在这个目录下,例如`/etc/kubelet.d/static-web.yaml`: ``` [root@my-node1 ~] $ mkdir /etc/kubelet.d/ @@ -48,27 +48,27 @@ Kubelet自动为每一个静态pod在Kubernetes的API服务器上创建一个镜 EOF ``` -3.配置节点上的kubelet使用这个目录,kubelet启动时增加`--pod-manifest-path=/etc/kubelet.d/`参数。如果是Fedora系统,在Kubelet配置文件/etc/kubernetes/kubelet中添加下面这行: +3.配置节点上的 kubelet 使用这个目录,kubelet 启动时增加`--pod-manifest-path=/etc/kubelet.d/`参数。如果是 Fedora 系统,在 Kubelet 配置文件 /etc/kubernetes/kubelet 中添加下面这行: ``` KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" ``` -如果是其它Linux发行版或者其它Kubernetes安装方式,配置方法可能会不一样。 +如果是其它 Linux 发行版或者其它 Kubernetes 安装方式,配置方法可能会不一样。 -4. 重启kubelet。如果是Fedora系统,就是: +4. 重启 kubelet。如果是 Fedora 系统,就是: ``` [root@my-node1 ~] $ systemctl restart kubelet ``` -## 通过HTTP创建静态Pods +## 通过 HTTP 创建静态 Pods -Kubelet周期地从--manifest-url=参数指定的地址下载文件,并且把它翻译成JSON/YAML格式的pod定义。此后的操作方式与--pod-manifest-path=相同,kubelet会不时地重新下载该文件,当文件变化时对应地终止或启动静态pod(如下)。 +Kubelet 周期地从 --manifest-url= 参数指定的地址下载文件,并且把它翻译成 JSON/YAML 格式的 pod 定义。此后的操作方式与 --pod-manifest-path= 相同,kubelet 会不时地重新下载该文件,当文件变化时对应地终止或启动静态 pod(如下)。 -## 静态pods的动作行为 +## 静态 pods 的动作行为 -kubelet启动时,由`--pod-manifest-path=` or `--manifest-url=`参数指定的目录下定义的所有pod都会自动创建,例如,我们示例中的static-web。 (可能要花些时间拉取nginx镜像,耐心等待...) +kubelet 启动时,由 `--pod-manifest-path=` 或者 `--manifest-url=` 参数指定的目录下定义的所有 pod 都会自动创建,例如,我们示例中的 static-web。 (可能要花些时间拉取 nginx 镜像,耐心等待...) ```shell [joe@my-node1 ~] $ docker ps @@ -76,7 +76,7 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAME f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` -如果我们查看Kubernetes的API服务器(运行在主机 `my-master`),可以看到这里创建了一个新的镜像Pod: +如果我们查看 Kubernetes 的 API 服务器(运行在主机 `my-master`),可以看到这里创建了一个新的镜像 Pod: ```shell [joe@host ~] $ ssh my-master @@ -85,9 +85,9 @@ NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 2m ``` -静态pod的标签会传递给镜像Pod,可以用来过滤或筛选。 +静态 pod 的标签会传递给镜像 Pod,可以用来过滤或筛选。 -需要注意的是,我们不能通过API服务器来删除静态pod(例如,通过 [`kubectl`](/docs/user-guide/kubectl/) 命令),kebelet不会删除它。 +需要注意的是,我们不能通过 API 服务器来删除静态 pod(例如,通过 [`kubectl`](/docs/user-guide/kubectl/) 命令),kebelet 不会删除它。 ```shell [joe@my-master ~] $ kubectl delete pod static-web-my-node1 @@ -97,7 +97,7 @@ NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s ``` -返回`my-node1`主机,我们尝试手动终止容器,可以看到kubelet很快就会自动重启容器。 +返回`my-node1`主机,我们尝试手动终止容器,可以看到 kubelet 很快就会自动重启容器。 ```shell [joe@host ~] $ ssh my-node1 @@ -108,9 +108,9 @@ CONTAINER ID IMAGE COMMAND CREATED ... 5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... ``` -## 静态pods的动态增加和删除 +## 静态 pods 的动态增加和删除 -运行中的kubelet周期扫描配置的目录(我们这个例子中就是`/etc/kubelet.d`)下文件的变化,当这个目录中有文件出现或消失时创建或删除pods。 +运行中的 kubelet 周期扫描配置的目录(我们这个例子中就是`/etc/kubelet.d`)下文件的变化,当这个目录中有文件出现或消失时创建或删除 pods。 ```shell [joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp diff --git a/content/zh/docs/tasks/administer-cluster/storage-object-in-use-protection.md b/content/zh/docs/tasks/administer-cluster/storage-object-in-use-protection.md new file mode 100644 index 0000000000..c173b854ab --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/storage-object-in-use-protection.md @@ -0,0 +1,442 @@ + + +--- +reviewers: +- msau42 +- jsafrane + +title: 保护使用的存储对象 +content_template: templates/task +--- + +{{% capture overview %}} + + + +Kubernetes 可以对被 Pod 持续使用的永久卷声明(PVCs)和绑定到 PVC 的永久卷(PVs)进行保护,以避免它们被用户不小心删除掉。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +在下面列出的 Kubernetes 版本中,激活了在用存储对象的保护特性: + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 在用存储对象的保护功能用于 PVC 的保护 + +下面的例子中使用了 GCE PD `StorageClass`, 但是类似的步骤可以在任意的卷类型上执行。 + +创建 `StorageClass` 以便提供存储: + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + + + +下面列出了验证场景。 + + + +### 场景1: PVC 没有被 Pod 使用 + + + +- 创建 PVC + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: slzc +spec: + accessModes: + - ReadWriteOnce + storageClassName: slow + resources: + requests: + storage: 3.7Gi +``` + + + +- 检查 PVC 设置了终结器 `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc slzc +Name: slzc +Namespace: default +StorageClass: slow +Status: Bound +Volume: pvc-bee8c30a-d6a3-11e7-9af0-42010a800002 +Labels: +Annotations: pv.kubernetes.io/bind-completed=yes + pv.kubernetes.io/bound-by-controller=yes + volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd +Finalizers: [kubernetes.io/pvc-protection] +Capacity: 4Gi +Access Modes: RWO +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ProvisioningSucceeded 2m persistentvolume-controller Successfully provisioned volume pvc-bee8c30a-d6a3-11e7-9af0-42010a800002 using kubernetes.io/gce-pd +``` + + + +- 删除 PVC 并检查 PVC (当前未被某 Pod 使用)被成功删除。 + + + +### 场景 2: PVC 被 Pod 使用 + +- 再来一次,创建相同的 PVC。 +- 创建一个 Pod ,并使用上面创建的 PVC: + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: app1 +spec: + containers: + - name: test-pod + image: k8s.gcr.io/busybox:1.24 + command: + - "/bin/sh" + args: + - "-c" + - "date > /mnt/app1.txt; sleep 60 && exit 0 || exit 1" + volumeMounts: + - name: path-pvc + mountPath: "/mnt" + restartPolicy: "Never" + volumes: + - name: path-pvc + persistentVolumeClaim: + claimName: slzc +``` + + +- 等到 Pod 的状态为 `Running`,即 PVC 变为在用状态。 +- 删除被 Pod 使用的 PVC 并确认其没有被删除成功,但它的状态为 `Terminating`: + +```shell +Name: slzc +Namespace: default +StorageClass: slow +Status: Terminating (since Fri, 01 Dec 2017 14:47:55 +0000) +Volume: pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 +Labels: +Annotations: pv.kubernetes.io/bind-completed=yes + pv.kubernetes.io/bound-by-controller=yes + volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd +Finalizers: [kubernetes.io/pvc-protection] +Capacity: 4Gi +Access Modes: RWO +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ProvisioningSucceeded 52s persistentvolume-controller Successfully provisioned volume pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 using kubernetes.io/gce-pd +``` + + + +- 等到 Pod 的状态变为 `Terminated` (删除 Pod 或者等到它结束),紧接着确认 PVC 被删除掉了。 + + + +### 场景 3: Pod 开始使用正在停止状态(Terminating)的 PVC + +- 再次创建相同的 PVC。 +- 创建使用这个 PVC 的第一个 Pod: + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: app1 +spec: + containers: + - name: test-pod + image: k8s.gcr.io/busybox:1.24 + command: + - "/bin/sh" + args: + - "-c" + - "date > /mnt/app1.txt; sleep 600 && exit 0 || exit 1" + volumeMounts: + - name: path-pvc + mountPath: "/mnt" + restartPolicy: "Never" + volumes: + - name: path-pvc + persistentVolumeClaim: + claimName: slzc +``` + + + +- 等到 Pod 状态为 `Running`,即 PVC 变为使用状态。 +- 删除被 Pod 使用的 PVC 并确认其没有被删除成功,但它的状态为 `Terminating`: + +```shell +Name: slzc +Namespace: default +StorageClass: slow +Status: Terminating (since Fri, 01 Dec 2017 14:47:55 +0000) +Volume: pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 +Labels: +Annotations: pv.kubernetes.io/bind-completed=yes + pv.kubernetes.io/bound-by-controller=yes + volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd +Finalizers: [kubernetes.io/pvc-protection] +Capacity: 4Gi +Access Modes: RWO +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ProvisioningSucceeded 52s persistentvolume-controller Successfully provisioned volume pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 using kubernetes.io/gce-pd +``` + + + +- 创建使用这个 PVC 的第二个 Pod: + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: app2 +spec: + containers: + - name: test-pod + image: gcr.io/google_containers/busybox:1.24 + command: + - "/bin/sh" + args: + - "-c" + - "date > /mnt/app1.txt; sleep 600 && exit 0 || exit 1" + volumeMounts: + - name: path-pvc + mountPath: "/mnt" + restartPolicy: "Never" + volumes: + - name: path-pvc + persistentVolumeClaim: + claimName: slzc +``` + + + +- 检查第二个 Pod 因为下面的警告而导致调度失败: + +```shell +Warning FailedScheduling 18s (x4 over 21s) default-scheduler persistentvolumeclaim "slzc" is being deleted +``` + + + +- 等到两个 Pod 的状态为 `Terminated` 或者 `Completed`(删除 Pod 或者等待它们结束),紧接着检查 PVC 被删除掉了。 + + + +## 使用在用存储对象保护的功能来保护 PV + +下面的示例使用了 `HostPath` PV。 + +下面列出了验证场景。 + +### 场景 1: PV 没有绑定到 PVC + +- 创建 PV: + +```yaml +kind: PersistentVolume +apiVersion: v1 +metadata: + name: task-pv-volume + labels: + type: local +spec: + capacity: + storage: 1Gi + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: standard + hostPath: + path: "/tmp/data" +``` + + + +- 检查 PV 设置了终结器 `kubernetes.io/pv-protection`: + +```shell +Name: task-pv-volume +Labels: type=local +Annotations: pv.kubernetes.io/bound-by-controller=yes +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating (lasts 1m) +Claim: default/task-pv-claim +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + + + +- 删除 PV 并检查该 PV(没有绑定到 PVC )被成功删除。 + +### 场景 2: PV 绑定了 PVC。 + +- 再次创建相同的 PV。 + +- 创建一个 PVC: + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: task-pv-claim +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + + + +- 等到 PV 和 PVC 相互绑定。 +- 删除 PV 并确认该 PV 没有被删除掉,但它的状态是 `Terminating`: + +```shell +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE +task-pv-volume 1Gi RWO Delete Terminating default/task-pv-claim standard 59s + +``` + + + +- 删除 PVC 并确认 PV 也一同被删除了。 + +```shell +kubectl delete pvc task-pv-claim +persistentvolumeclaim "task-pv-claim" deleted +$ kubectl get pvc +No resources found. +$ kubectl get pv +No resources found. +``` + +{{% /capture %}} + +{{% capture discussion %}} + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-federation/_index.md b/content/zh/docs/tasks/administer-federation/_index.md index 1ab6c7e5d6..44abdee8cc 100644 --- a/content/zh/docs/tasks/administer-federation/_index.md +++ b/content/zh/docs/tasks/administer-federation/_index.md @@ -1,3 +1,8 @@ +--- +title: "联邦:在多个集群上运行一个应用" +weight: 160 +--- + ---- -title: "联邦:在多个集群上运行一个应用" -weight: 160 ---- - diff --git a/content/zh/docs/tasks/administer-federation/cluster.md b/content/zh/docs/tasks/administer-federation/cluster.md new file mode 100644 index 0000000000..b6d7b30a09 --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/cluster.md @@ -0,0 +1,224 @@ +--- +title: 联邦 Cluster +content_template: templates/task +--- + + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + + +本指南介绍了如何在联邦控制平面中使用集群 API 资源。 + +与 Deployment、Service 和 ConfigMap 等 Kubernetes 资源不同,cluster 只存在于联邦上下文中,即这些请求必须提交给联邦 api-server。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "federated-task-tutorial-prereqs.md" >}} + + + +* 你需要具备基本的 [Kubernetes 工作知识](/docs/setup/pick-right-solution/)。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 集群列表 + + + +要列出联邦中可用的 cluster,可以使用 [kubectl](/docs/user-guide/kubectl/) +运行: + +```shell +kubectl --context=federation get clusters +``` + + + +`--context=federation` 参数告诉 kubectl 将请求提交给联邦 apiserver, +而不是将其发送给 Kubernetes 集群。如果您将其提交给 k8s 集群,则会收到错误消息 + + +``` +the server doesn't have a resource type "clusters" +``` + + + +如果您传递了正确的联邦上下文,但是收到了一条消息错误 + +``` +No resources found. +``` + + +这表示着没有向联邦添加任何集群。 + + + +## 创建一个联邦集群 + + +在联邦中创建`集群`资源意味着将其加入到联邦中。因此,您可以使用 `kubefed join`。基本上,您需要为新群集指定一个名称, +并说明与承载联邦的集群相对应的上下文的名称。下面的示例命令将集群 `gondor` 添加到运行在主机集群 `rivendell` 上的联邦: + + +```shell +kubefed join gondor --host-cluster-context=rivendell +``` + + +您可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation)的相关章节中找到更多关于如何实现这一点的详细信息。 + + + +## 删除一个联邦集群 + + +与创建集群相反,删除集群意味着从联邦中取消加入这个集群。这可以通过 `kubefed unjoin` 命令完成。要删除 `gondor` 群集,需要执行以下操作: + +```shell +kubefed unjoin gondor --host-cluster-context=rivendell +``` + + +你可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#removing-a-cluster-from-a-federation)中找到更多关于取消加入的详细信息。 + + + +## 标记集群 + + +您可以使用与其他任何 Kubernetes 对象相同的方法标记集群,这有助于对集群进行分组,也可以配合使用 ClusterSelector。 + +``` shell +kubectl --context=rivendell label cluster gondor key1=value1 key2=value2 +``` + + + +## ClusterSelector 注解 + + + +从 Kubernetes 1.7 开始,alpha 支持通过注解 `federation.alpha.kubernetes.io/cluster-selector` 在联邦集群中引导对象。。 +*ClusterSelector* 在概念上类似于 `nodeSelector`,但是它不是针对节点上的标签进行选择,而是针对联邦集群上的标签进行选择。 + +注解值必须是 JSON 格式并且必须可解析为 [ClusterSelector API 类型](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector)。 +例如:`[{"key": "load", "operator": "Lt", "values": ["10"]}]`,不能正确解析的内容将抛出一个错误,并阻止将对象分发到任何联邦集群。alpha 实现包含 ConfigMap、Secret、Daemonset、Service 和 Ingress 类型的对象。 + +下面是一个 ClusterSelector 注释示例,它只会选择带有标签 `pci=true` 不选择标签为 `environment=test` 的集群: + +```yaml + metadata: + annotations: + federation.alpha.kubernetes.io/cluster-selector: '[{"key": "pci", "operator": + "In", "values": ["true"]}, {"key": "environment", "operator": "NotIn", "values": + ["test"]}]' +``` + + + +*key* 与联邦集群上的标签名称匹配。 + +*values* 与联邦集群上的标签值匹配。 + +可能的*操作符*有:`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`。 + +*values* 字段在指定 `Exists` 或 `DoesNotExist` 时为空,在使用 `In` 或 `NotIn` 时可能包含多个字符串。 + +目前,`Gt` 和 `Lt` 操作符只支持整数。 + + + +## 集群 API 参考 + +完整的集群 API 参考目前在 `federation/v1beta1` 中,更多细节可以在[联邦 API 参考页面](/docs/reference/federation/)中找到。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-federation/configmap.md b/content/zh/docs/tasks/administer-federation/configmap.md new file mode 100644 index 0000000000..8ac208f32d --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/configmap.md @@ -0,0 +1,129 @@ +--- +title: 联邦 ConfigMap +content_template: templates/task +--- + + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + + +这个指南介绍了如何在联邦控制平面中使用 ConfigMaps。 + + + +联邦 ConfigMaps 与传统的 [Kubernetes +ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) 十分相似,并且提供相同的功能。 +在联邦控制平面中创建它们可确保它们在联邦集群间的同步。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + + +* {{< include "federated-task-tutorial-prereqs.md" >}} +* 你还需要有基本的[Kubernetes 工作常识](/docs/setup/pick-right-solution/),尤其是[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 创建一个 Federated ConfigMap + + + +Federated ConfigMap 的 API 100% 兼容传统的 Kubernetes ConfigMap。你可以通过发送一个请求到联邦 apiserver 来创建一个 ConfigMap。 + + + +你可以使用[kubectl](/docs/user-guide/kubectl/)执行: + +``` shell +kubectl --context=federation-cluster create -f myconfigmap.yaml +``` + + + +`--context=federation-cluster` 参数告诉 kubectl 发送请求至联邦 apiserver 而不是 Kubernetes 集群。 + + + +一旦联邦 ConfigMap 创建成功,联邦控制平面会在所有底层 Kubernetes 集群中创建匹配的 ConfigMap。你可以通过检查每个底层的集群来验证这点,例如: + +``` shell +kubectl --context=gce-asia-east1a get configmap myconfigmap +``` + + + +以上是假设你在客户端中为该区域中的集群配置了一个名为 'gce-asia-east1a' 的上下文。 + + +这些在底层集群中的 ConfigMaps 会自动匹配联邦 ConfigMap。 + + + + +## 更新一个联邦 ConfigMap + + + +你可以像更新 Kubernetes ConfigMap 一样更新一个联邦 ConfigMap。然而,对于联邦 ConfigMap,你必须发送请求至联邦 apiserver 而不是指定的 Kubernetes 集群。 +联邦控制平面会确保无论何时联邦 ConfigMap 被更新,它都会更新所有底层集群中想相匹配的 ConfigMaps。 + + + +## 删除一个联邦 ConfigMap + + + +你可以像删除一个 Kubernetes ConfigMap 一样删除一个联邦 ConfigMap。然而,对于联邦 ConfigMap,你必须发送请求至联邦 apiserver 而不是指定的 Kubernetes 集群。 + + + +例如,你可以使用 kubectl 执行: + +```shell +kubectl --context=federation-cluster delete configmap +``` + +{{< note >}} + + +删除一个联邦 ConfigMap 不会从底层集群中删除相应的 ConfigMaps。你必须手动地删除底层 ConfigMaps。 +{{< /note >}} + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-federation/daemonset.md b/content/zh/docs/tasks/administer-federation/daemonset.md new file mode 100644 index 0000000000..d213a14104 --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/daemonset.md @@ -0,0 +1,156 @@ +--- +title: 联邦(Federated) DaemonSet +content_template: templates/task +--- + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + +本指南介绍了如何在联邦控制平面中使用 DaemonSet。 + + +联邦控制平面中的 DaemonSet (即本指南中的联邦 DaemonSet)与传统的 Kubernetes [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 非常相似,并提供相同的功能。 + + +在联邦控制平面中创建它们可以确保它们跨联邦中的所有集群保持同步。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +* {{< include "federated-task-tutorial-prereqs.md" >}} +* 您还需要具备基本的 [Kubernetes 工作知识](/docs/setup/pick-right-solution/),特别是关于 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)。 + +{{% /capture %}} + +{{% capture steps %}} + + +## 创建一个联邦 DaemonSet + + +用于联邦 DaemonSet 的 API 与用于传统 Kubernetes DaemonSet 的 API 100% 兼容。 + +您可以通过向联邦 apiserver 发送请求来创建 DaemonSet。 + + +您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行以下命令来执行此操作: + +``` shell +kubectl --context=federation-cluster create -f mydaemonset.yaml +``` + + +`--context=federation-cluster` 参数告诉 kubectl 将请求提交给联邦 apiserver, +而不是发送给 Kubernetes 集群。 + + +一旦创建了联邦 DaemonSet,联邦控制平面将在所有底层 Kubernetes 集群中创建匹配的 DaemonSet。 + +您可以通过检查每个基础集群来验证这一点,例如: + +``` shell +kubectl --context=gce-asia-east1a get daemonset mydaemonset +``` + + +上面假设您的客户机中为该区域中的集群配置了一个名为 'gce-asia-east1a' 的上下文。 + + +## 更新联邦 DaemonSet + + +您可以像更新 Kubernetes DaemonSet 一样更新联邦 DaemonSet; + +但是,对于联邦 DaemonSet,您必须将请求发送到 + +联邦 apiserver 而不是将其发送到特定的 Kubernetes 集群。 + +联邦控制平面确保每当更新联邦 DaemonSet 时,它都会更新所有底层集群中的相应 DaemonSet 以匹配它。 + + +## 删除联邦 DaemonSet + + +您可以删除联邦 DaemonSet,就像删除 Kubernetes DaemonSet 一样; + +但是,对于联邦 DaemonSet,您必须将请求发送到 + +联邦 apiserver 而不是将其发送到特定的 Kubernetes 集群。 + + +例如,您可以通过使用 kubectl 运行以下命令执行此操作: + +```shell +kubectl --context=federation-cluster delete daemonset mydaemonset +``` + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-federation/events.md b/content/zh/docs/tasks/administer-federation/events.md new file mode 100644 index 0000000000..385db13674 --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/events.md @@ -0,0 +1,85 @@ +--- +title: 联邦事件 +content_template: templates/concept +--- + + + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + +本指南介绍如何在联邦控制平面中使用事件来帮助调试。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 前提条件 + + +本指南假设您已安装好了 Kubernetes 集群联邦。如果没有,请先查看 [联邦管理指南](/docs/admin/federation/) 来学习怎样安装集群联邦(也可以让您的管理员替您完成安装)。 +其他的教程,例如 Kelsey Hightower 编写的 [这个教程](https://github.com/kelseyhightower/kubernetes-cluster-federation) 也会帮到你。 + + +您还应该具备 [Kubernetes 的基本操作](/docs/setup) 的知识。 + + +## 查看联邦事件 + + +联邦控制平面的事件(本指南中称为“联邦事件”)与传统的 Kubernetes 事件非常相似,提供相同功能。 +联邦事件仅存储在联邦控制平面中,不会传递给下层 Kubernetes 集群。 + + +联邦控制器在处理 API 资源时创建事件,以向用户显示它们所处的状态。 +您可以通过运行以下命令从联邦 API 服务器获取所有事件: + +```shell +kubectl --context=federation-cluster get events +``` + + +标准的 kubectl get、update、delete 命令都可以正常工作。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-federation/hpa.md b/content/zh/docs/tasks/administer-federation/hpa.md new file mode 100644 index 0000000000..2608ce6447 --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/hpa.md @@ -0,0 +1,292 @@ +--- +title: 联邦横向 Pod 伸缩器 (HPA) +content_template: templates/task +--- + + +{{% capture overview %}} + +{{< feature-state state="alpha" >}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + +本指南介绍了如何在联邦控制平面中使用联邦横向 pod 自动伸缩器 (HPAs)。 + +联邦控制平面中的 HPA 与传统的 [Kubernetes HPA](/docs/tasks/run-application/horizontal-pod-autoscale/) 非常相似,提供相同的功能。 + 在联邦控制平面中针对联邦对象创建的 HPA 将保证目标对象的期望副本在所有注册集群上进行伸缩,而不是在单个集群上。此外,控制平面持续监控联邦集群中单个 HPA 的状态,通过操作联邦集群中 HPA 对象的最小和最大限制值来确保工作副本被移动到最需要的地方。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +* {{< include "federated-task-tutorial-prereqs.md" >}} +* 通常您还应当拥有基本的 [Kubernetes 应用知识](/docs/setup/),特别是 [HPA](/docs/tasks/run-application/horizontal-pod-autoscale/) 。 + +联邦 HPA 是一个 alpha 特性。默认情况下该 API 没有在联邦 API server 上启用。要使用此特性,部署联邦控制平面的用户或管理员需要使用 `--runtime-config=api/all=true` 选项运行联邦 API server 以启用所有 API(包括 alpha API)。此外,联邦 HPA 只能和 CPU 使用率度量一起使用。 + +{{% /capture %}} + +{{% capture steps %}} + + +## 创建联邦 HPA + +联邦 HPA 的 API 100% 兼容传统 Kubernetes HPA 的 API。您可以通过向联邦 API server 发送请求来创建 HPA。 + +您可以使用 [kubectl](/docs/user-guide/kubectl/) 运行命令: + +```shell +cat <}} +集群的最小副本总和不能为 0。 +{{< /note >}} + + +### 在基础集群中分发 HPA 的最小和最大副本数 + +默认情况下,首先将最大副本数在所有基础集群中平均分布,然后再将最小副本数分发给已接收了最大副本数的集群。这意味着,如果指定的最大副本数大于联邦的集群数,则每个集群都将获得一个 HPA。反之,如果指定的最大副本数小于联邦的集群数,则会跳过某些集群。 + +举例说明:如果您有3个注册集群,并且您使用参数 `spec.maxReplicas = 9` 和 `spec.minReplicas = 2` 创建了一个联邦 HPA,那么3个集群中的每个 HPA 都将获得 `spec.maxReplicas=3` 和 `spec.minReplicas = 1` 的参数。 + +目前,联邦 HPA 仅可以使用默认的分发机制,但在将来,用户将可以设置偏好来控制和/或限制分发过程。 + + +## 更新联邦 HPA + +您可以像更新 Kubernetes HPA 一样更新联邦 HPA;但是,对于联邦 HPA 您必须将请求发送给联邦 API server 而不是发送到一个特定的 Kubernetes 集群。联邦控制平面将保证在联邦 HPA 被更新后,它会对所有基础集群中与之对应的 HPA 进行更新。 + +如果您的更新修改了副本数量,联邦控制平面将修改基础集群中的副本数量,保证最小副本总数和最大副本总数仍然符合要求正如前文所述。 + + +## 删除联邦 HPA + +您可以像删除 Kubernetes HPA 一样删除联邦 HPA;但是,对于联邦 HPA, 您必须将请求发送给联邦 API server 而不是发送到一个特定的 Kubernetes 集群。 + +{{< note >}} +如果要删除所有基础集群中的联邦资源,应该使用 [级联删除](/docs/concepts/cluster-administration/federation/#cascading-deletion)。 +{{< /note >}} + +例如,您可以使用 `kubectl` 运行命令: + +```shell +kubectl --context=federation-cluster delete HPA php-apache +``` + + +## 使用联邦 HPA 的其他方法 + +对于和联邦控制平面(或简称联邦)交互的用户,这种交互几乎和与一个普通 Kubernetes 集群的交互完全相同(但只能使用有限的联邦 API 集合)。由于目前 Deployment 和 HorizontalPodAutoscaler 都有联邦版本,类似 `kubectl run` 和 `kubectl autoscale` 的 `kubectl` 命令都可以在联邦上运行。鉴于这个事实,[horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) 中指定的机制同样可以在联邦中运行。但也需要注意,当[在目标 deployment 上生成负载](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load) 时,应该针对一个特定的联邦集群(或多个集群)而不是整个联邦。 + + +## 结论 + +使用联邦 HPA 是为了保证工作副本移动到最需要它们的地方,换句话说,是移动到负载超过期望阈值的地方。联邦 HPA 功能通过操作其在联邦集群中创建的 HPA 的最小和最大副本数来实现此目的。它并不直接监控联邦集群中目标对象的度量值,实际上依赖于集群内部的 HPA 控制器来监控目标 pod 的度量值并更新相关字段。集群内部的 HPA 控制器监控目标 pod 的度量值并更新相关字段,如期望的副本数(在基于度量的计算之后)和当前副本数(通过观察集群中 pod 的当前状态)。另一方面,联邦 HPA 控制器只监控集群特定的 HPA 对象字段并更新集群中 HPA 对象的最小和最大副本数字段,这些对象的副本数和阈值匹配。 + +例如,如果一个集群同时拥有期望副本数和当前副本数,其值与最大副本数相同,但当前 CPU 的平均利用率仍然高于目标使用率(它们都是本地 HPA 对象上的字段)时,集群中的目标应用程序就需要更多的副本,但是扩容动作被本地 HPA 对象上设置的最大副本数限制。在这种场景下,联邦 HPA 控制器将会扫描所有集群并尝试查找没有这种条件的集群(意思是期望副本数小于最大值且当前 CPU 平均使用率低于阈值)。如果找到了这样的集群,它会减少该集群中 HPA 的最大副本数,并增加最需要副本的集群上的 HPA 的最大副本数。 + +还存在许多类似的情况导致联邦 HPA 控制器检查并移动联邦集群中本地 HPA 的最大和最小副本数,以确保副本最终移动(或保留)到最需要它们的集群中。 + +更多相关信息请参考["联邦 HPA 设计提议"](https://github.com/kubernetes/community/pull/593)。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/administer-federation/namespaces.md b/content/zh/docs/tasks/administer-federation/namespaces.md new file mode 100644 index 0000000000..04261c46a8 --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/namespaces.md @@ -0,0 +1,140 @@ +--- +title: 联邦命名空间 +content_template: templates/task +--- + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + +本指南介绍如何在联邦控制平面中使用命名空间。 + +联邦控制平面中的命名空间(在本指南中称为“联邦命名空间”)与提供相同功能的传统 [Kubernetes 命名空间](/docs/concepts/overview/working-with-objects/namespaces/)非常相似。在联邦控制平面中创建它们可确保它们在联邦中的所有集群之间同步。 + + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "federated-task-tutorial-prereqs.md" >}} +* 一般来说您还应具备 [Kubernetes 的基本工作知识](/docs/setup/pick-right-solution/),尤其是[命名空间](/docs/concepts/overview/working-with-objects/namespaces/)。 + + + +{{% /capture %}} + +{{% capture steps %}} + +## 创建联邦命名空间 + +联邦命名空间的 API 与传统 Kubernetes 命名空间的 API 100%兼容。您可以通过给联邦 API 服务器发送请求来创建一个命名空间。 + +您可以通过运行以下 kubectl 命令来执行此操作: + + + +``` shell +kubectl --context=federation-cluster create -f myns.yaml +``` + +参数 `--context=federation-cluster` 用于告知 kubectl 要向联邦 API 服务器提交请求而不是 Kubernetes 集群。 + +一旦联邦命名空间被创建,联邦控制平面将在所有基础的 Kubernetes 集群中创建与之相匹配的命名空间。 +您可以通过检查每个基础集群来验证这一点,例如: + + + +``` shell +kubectl --context=gce-asia-east1a get namespaces myns +``` + +以上假设您在客户机中为该区域的集群配置了一个名为 'gce-asia-east1a' 的上下文。基础命名空间的名称和 spec 将与您在上面创建的联合命名空间的名称和 spec 相匹配。 + + + + +## 更新联邦命名空间 + +您可以像更新 Kubernetes 命名空间一样更新联邦命名空间,只需要将请求发送给联邦的 API 服务器,而不是发送给特定的 Kubernetes 集群。 +联邦控制平面将确保每当更新联邦命名空间时,它都会更新所有基础集群中的相应命名空间以与其匹配。 + + + +## 删除联邦命名空间 + +您可以删除联邦命名空间就像删除 Kubernetes 命名空间一样,只需要将请求发送给联邦的 API 服务器,而不是发送给特定的 Kubernetes 集群。 + +例如,您可以通过运行以下 kubectl 命令来执行此操作: + + +```shell +kubectl --context=federation-cluster delete ns myns +``` + +与在 Kubernetes 中一样,删除联邦命名空间将从联邦控制平面中删除该命名空间中的所有资源。 + + + +{{< note >}} +就此,删除联邦命名空间不会从基础集群中删除相应的命名空间或这些命名空间中的资源。用户必须手动删除它们。我们打算在将来解决这个问题。 + +{{< /note >}} + +{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-federation/secret.md b/content/zh/docs/tasks/administer-federation/secret.md new file mode 100644 index 0000000000..c13f095d0b --- /dev/null +++ b/content/zh/docs/tasks/administer-federation/secret.md @@ -0,0 +1,156 @@ +--- +title: 联邦 Secret +content_template: templates/concept +--- + + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + + +本指南解释了怎样使用联邦控制平面中的 secret。 + +联邦控制平面中的 secret (请参考本文的 "联邦 secrets" 章节) 和传统的[Kubernetes Secrets](/docs/concepts/configuration/secret/)非常类似并提供相同的功能。 +在联邦控制平面中创建它们可以确保它们在联邦中的所有集群之间同步。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 前提条件 + +本指南假设您安装好了 Kubernetes 集群联邦。如果没有,请先查看 [federation admin guide](/docs/admin/federation/) 来学习怎样安装集群联邦(也可以让您的管理员替您完成安装)。 +其他的教程,例如 Kelsey Hightower 编写的 [这个教程](https://github.com/kelseyhightower/kubernetes-cluster-federation) 也会帮到你。 + + + +也希望您大概了解一些基本的 [Kubernetes 知识](/docs/setup/) 特别是和 [Secrets](/docs/concepts/configuration/secret/) 相关的知识。 + + + +## 创建联邦 Secret + +联邦 Secret 的 API 与传统的 Kubernetes Secret 的 API 100% 兼容。 +你可以通过向联邦的 ApiServer 发出请求来创建 Secret。 + +``` shell +kubectl --context=federation-cluster create -f mysecret.yaml +``` + + + +`--context=federation-cluster` 参数告诉 kubectl 将请求提交给联邦 ApiServer 而不是将其发送到 Kubernetes 集群上。 + + + +在创建完联邦 secret 后,联邦控制平面将在所有底层 Kubernetes 集群中创建匹配的 secret。 +您可以通过检查每个底层集群来验证这一点,例如: + +``` shell +kubectl --context=gce-asia-east1a get secret mysecret +``` + + + +以上假设您在客户端上为该区域的集群配置了一个名为 'gce-asia-east1a' 的上下文。 + +底层集群中的这些 secret 将与联邦 secret 相匹配。 + + + +## 更新联邦 secret + +您可以像更新 Kubernetes secret 那样更新联邦 secret;但是,对于联邦 secret,必须将请求发送到联邦 ApiServer,而非某个 Kubernetes 集群上。 +联邦控制平面确保每当联邦 secret 被更新时,它来更新所有底层集群中的相应 secret ,以便相互匹配。 + + + +## 删除联邦 Secret + +您可以像删除 Kubernetes secret 那样删除联邦 secret;但是,对于联邦 secret,必须将请求发送到联邦 ApiServer,而不是将其发送到特定的 Kubernetes 集群。 + +例如,您可以使用 kubectl 来进行删除: + +```shell +kubectl --context=federation-cluster delete secret mysecret +``` + +{{< note >}} + +目前,删除联邦 secret 并不会从底层集群中删除相应的 secret。您必须手动删除底层 secret。我们考虑在将来解决这个问题。 +{{< /note >}} + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/_index.md b/content/zh/docs/tasks/configure-pod-container/_index.md index 2e7dd9a95a..de5e02d5a0 100644 --- a/content/zh/docs/tasks/configure-pod-container/_index.md +++ b/content/zh/docs/tasks/configure-pod-container/_index.md @@ -1,12 +1,10 @@ - ---- -title: "配置 Pod 和 容器" -weight: 20 ---- - diff --git a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md new file mode 100644 index 0000000000..129e076179 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -0,0 +1,169 @@ +--- +title: 为容器生命周期事件添加处理程序 +content_template: templates/task +weight: 140 +--- + + +{{% capture overview %}} + +本页面展示了如何将容器生命周期事件绑定到处理程序上。Kubernetes 支持 postStart 和 preStop 事件。Kubernetes 在启动容器之后会立即发送 postStart 事件 +,在容器终止之前会立即发送 preStop 事件。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 定义 postStart 和 preStop 处理程序 + +在本练习中,您将创建一个具有一个容器的 Pod。该容器包含用于处理 postStart 和 preStop 事件的程序。 + +这是 Pod 的配置文件: + +{{< codenew file="pods/lifecycle-events.yaml" >}} + + +在配置文件中,您可以看到 postStart 命令写入 `message` 文件到容器的的 `/usr/share` 目录。preStop 命令优雅地关闭了 nginx 。如果容器因故障而终止,这就会非常有用。 + + +创建 Pod: + + kubectl create -f https://k8s.io/examples/pods/lifecycle-events.yaml + + +验证 Pod 里的容器处于运行状态: + + kubectl get pod lifecycle-demo + + + +获取一个访问 Pod 中运行容器的 shell: + + kubectl exec -it lifecycle-demo -- /bin/bash + + +在 shell 中,验证 `postStart` 处理程序是否创建了 `message` 文件: + + root@lifecycle-demo:/# cat /usr/share/message + +输出显示 postStart 处理程序写入的文本: + + Hello from the postStart handler + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 讨论 + +Kubernetes 在创建容器后立即发送 postStart 事件。但是,不能保证 postStart 处理程序 +在容器的 entrypoint 调用之前被调用。相对于容器的代码,postStart 处理程序以异步方式运行,但 Kubernetes 对容器的管理 +会阻塞直到 postStart 处理程序完成。容器的状态直到 postStart 处理程序完成后才会设置为 RUNNING 。 + + +Kubernetes 在容器终止之前立即发送 preStop 事件。 +Kubernetes 对容器的管理一直阻塞直到 preStop 处理程序完成, 除非 Pod 的宽限期过期。有关详细信息,请参阅 +[Pods 的终止](/docs/user-guide/pods/#termination-of-pods) 。 + +{{< note >}} + +Kubernetes 仅在 Pod 是 *terminated* 时发送 preStop 事件。这意味着当 Pod 是 *completed* 状态时,preStop 钩子程序不会被触发。 +这个限制被记录在 [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807) 中。 +{{< /note >}} + +{{% /capture %}} + + +{{% capture whatsnext %}} + + + +* 进一步了解 [容器生命周期钩子](/docs/concepts/containers/container-lifecycle-hooks/). +* 进一步了解 [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/). + + + +### 参考 + +* [Lifecycle](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lifecycle-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* 查看 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 文档中关于 `terminationGracePeriodSeconds` 的说明 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md new file mode 100644 index 0000000000..51143113fe --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -0,0 +1,375 @@ +--- +title: 配置 Pod 以使用 PersistentVolume 作为存储 +content_template: templates/task +weight: 60 +--- + + + +{{% capture overview %}} + + + +本文介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。 +以下是该过程的总结: + +1. 集群管理员创建由物理存储支持的 PersistentVolume。管理员不将卷与任何 Pod 关联。 + +1. 群集用户创建一个 PersistentVolumeClaim,它将自动绑定到合适的 PersistentVolume。 + +1. 用户创建一个使用 PersistentVolumeClaim 作为存储的 Pod。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +* 您需要一个包含单个节点的 Kubernetes 集群,并且必须配置 kubectl 命令行工具以便与集群交互。 +如果还没有单节点集群,可以使用 [Minikube](/docs/getting-started-guides/minikube) 创建一个。 + +* 熟悉[持久卷](/docs/concepts/storage/persistent-volumes/)中的材料。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 在你的节点上创建一个 index.html 文件 + +打开集群中节点的一个 shell。 +如何打开 shell 取决于集群的设置。 +例如,如果您正在使用 Minikube,那么可以通过输入 `minikube ssh` 来打开节点的 shell。 + +在 shell 中,创建一个 `/mnt/data` 目录: + + mkdir /mnt/data + + + +在 `/mnt/data` 目录中创建一个 index.html 文件: + + echo 'Hello from Kubernetes storage' > /mnt/data/index.html + + + +## 创建 PersistentVolume + +在本练习中,您将创建一个 *hostPath* 类型的 PersistentVolume。 +Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。 +hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟附带网络的存储。 + + + +在生产集群中,您不会使用 hostPath。集群管理员会提供网络存储资源,比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。 +集群管理员还可以使用 [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage) 来设置[动态提供存储](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)。 + +下面是 hostPath PersistentVolume 的配置文件: + +{{< codenew file="pods/storage/pv-volume.yaml" >}} + + + +配置文件指定了该卷位于集群节点上的 `/mnt/data` 目录。 +该配置还指定了 10 吉比特的卷大小和 `ReadWriteOnce` 的访问模式,这意味着该卷可以在单个节点上以读写方式挂载。 +它为 PersistentVolume 定义了 [StorageClass 名称](/docs/concepts/storage/persistent-volumes/#class) 为 `manual`,StorageClass 名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolum。 + +创建 PersistentVolume: + + kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml + + + +查看 PersistentVolume 的信息: + + kubectl get pv task-pv-volume + + + +输出结果显示该 PersistentVolume 的`状态(STATUS)` 为 `Available`。 +这意味着它还没有被绑定给 PersistentVolumeClaim。 + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + task-pv-volume 10Gi RWO Retain Available manual 4s + + + +## 创建 PersistentVolumeClaim + +下一步是创建一个 PersistentVolumeClaim。 +Pod 使用 PersistentVolumeClaim 来请求物理存储。 +在本练习中,您将创建一个 PersistentVolumeClaim,它请求至少 3 吉比特容量的卷,该卷至少可以为一个节点提供读写访问。 + +下面是 PersistentVolumeClaim 的配置文件: + +{{< codenew file="pods/storage/pv-claim.yaml" >}} + + + +创建 PersistentVolumeClaim: + + kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml + + + +创建 PersistentVolumeClaim 之后,Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。 +如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume,则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。 + +再次查看 PersistentVolume 信息: + + kubectl get pv task-pv-volume + + +现在输出的 `STATUS` 为 `Bound`。 + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim manual 2m + + +查看 PersistentVolumeClaim: + + kubectl get pvc task-pv-claim + + + +输出结果表明该 PersistentVolumeClaim 绑定了你的 PersistentVolume `task-pv-volume`。 + + NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE + task-pv-claim Bound task-pv-volume 10Gi RWO manual 30s + + + +## 创建 Pod + +下一步是创建一个 Pod, 该 Pod 使用你的 PersistentVolumeClaim 作为存储卷。 + +下面是 Pod 的 配置文件: + +{{< codenew file="pods/storage/pv-pod.yaml" >}} + + + +注意 Pod 的配置文件指定了 PersistentVolumeClaim,但没有指定 PersistentVolume。对 Pod 而言,PersistentVolumeClaim 就是一个存储卷。 + +创建 Pod: + + kubectl create -f https://k8s.io/examples/pods/storage/pv-pod.yaml + + + +检查 Pod 中的容器是否运行正常: + + kubectl get pod task-pv-pod + + + +打开一个 shell 访问 Pod 中的容器: + + kubectl exec -it task-pv-pod -- /bin/bash + + + +在 shell 中,验证 nginx 是否正在从 hostPath 卷提供 `index.html` 文件: + + root@task-pv-pod:/# apt-get update + root@task-pv-pod:/# apt-get install curl + root@task-pv-pod:/# curl localhost + + + +输出结果是你之前写到 hostPath 卷中的 `index.html` 文件中的内容: + + Hello from Kubernetes storage + +{{% /capture %}} + + +{{% capture discussion %}} + + + +## 访问控制 + +使用 group ID(GID)配置的存储仅允许 Pod 使用相同的 GID 进行写入。 +GID 不匹配或缺少将会导致许可被拒绝的错误。 +为了减少与用户的协调,管理员可以使用 GID 对 PersistentVolume 进行注解。 +这样 GID 就能自动的添加到使用 PersistentVolume 的任何 Pod 中。 + +使用 `pv.beta.kubernetes.io/gid` 注解的方法如下所示: + +```yaml +kind: PersistentVolume +apiVersion: v1 +metadata: + name: pv1 + annotations: + pv.beta.kubernetes.io/gid: "1234" +``` + + + +当 Pod 使用带有 GID 注解的 PersistentVolume 时,注解的 GID 会被应用于 Pod 中的所有容器,应用的方法与 Pod 的安全上下文中指定的 GID 相同。 +每个 GID,无论是来自 PersistentVolume 注解还是来自 Pod 的规范,都应用于每个容器中运行的第一个进程。 + +{{< note >}} + +当 Pod 使用 PersistentVolume 时,与 PersistentVolume 关联的 GID 不会在 Pod 本身的资源对象上出现。 +{{< /note >}} + +{{% /capture %}} + + +{{% capture whatsnext %}} + + + +* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。 +* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)。 + + + +### 参考 + +* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) +* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md new file mode 100644 index 0000000000..c9c875c476 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -0,0 +1,151 @@ +--- +title: 配置 Pod 初始化 +content_template: templates/task +weight: 130 +--- + + + +{{% capture overview %}} + +本文介绍在应用容器运行前,怎样利用 Init 容器初始化 Pod。 +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 创建一个包含 Init 容器的 Pod + +本例中您将创建一个包含一个应用容器和一个 Init 容器的 Pod。Init 容器在应用容器启动前运行完成。 + +下面是 Pod 的配置文件: + +{{< codenew file="pods/init-containers.yaml" >}} + + + +配置文件中,您可以看到应用容器和 Init 容器共享了一个卷。 + +Init 容器将共享卷挂载到了 `/work-dir` 目录,应用容器将共享卷挂载到了 `/usr/share/nginx/html` 目录。 +Init 容器执行完下面的命令就终止: + + wget -O /work-dir/index.html http://kubernetes.io + + + +请注意 Init 容器在 nginx 服务器的根目录写入 `index.html`。 + +创建 Pod: + + kubectl create -f https://k8s.io/examples/pods/init-containers.yaml + + + +检查 nginx 容器运行正常: + + kubectl get pod init-demo + + + +结果表明 nginx 容器运行正常: + + NAME READY STATUS RESTARTS AGE + init-demo 1/1 Running 0 1m + + + +通过 shell 进入 init-demo Pod 中的 nginx 容器: + + kubectl exec -it init-demo -- /bin/bash + + + +在 shell 中,发送个 GET 请求到 nginx 服务器: + + root@nginx:~# apt-get update + root@nginx:~# apt-get install curl + root@nginx:~# curl localhost + + + +结果表明 nginx 正在为 Init 容器编写的 web 页面服务: + + + + + + ... + "url": "http://kubernetes.io/"} + + + ... +

Kubernetes is open source giving you the freedom to take advantage ...

+ ... + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 进一步了解 [相同 Pod 中的容器间的通信](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。 +* 进一步了解 [Init 容器](/docs/concepts/workloads/pods/init-containers/)。 +* 进一步了解 [卷](/docs/concepts/storage/volumes/)。 +* 进一步了解 [Init 容器排错](/docs/tasks/debug-application-cluster/debug-init-containers/)。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md new file mode 100644 index 0000000000..ec892fe01e --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -0,0 +1,110 @@ +--- +reviewers: +- jpeeler +- pmorie +title: 配置 Pod 使用投射卷作存储 +content_template: templates/task +weight: 70 +--- + + + +{{% capture overview %}} + + +本文介绍怎样通过[`投射`](/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。 +当前,`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。 + +{{< note >}} + +`serviceAccountToken` 不是一种卷类型 +{{< /note >}} +{{% /capture %}} + +{{% capture prerequisites %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{% /capture %}} + +{{% capture steps %}} + + + +## 为 Pod 配置投射卷 + +本练习中,您将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod,该 Pod 使用[`投射`](/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。 + +下面是 Pod 的配置文件: + +{{< codenew file="pods/storage/projected.yaml" >}} + +1. 创建 Secrets: +```shell + # 创建包含用户名和密码的文件: + echo -n "admin" > ./username.txt + echo -n "1f2d1e2e67df" > ./password.txt--> + + # 将上述文件引用到 Secret: + kubectl create secret generic user --from-file=./username.txt + kubectl create secret generic pass --from-file=./password.txt +``` + +1. 创建 Pod: + +```shell + kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml +``` + +确认 Pod 中的容器运行正常,然后监视 Pod 的变化: + +```shell + kubectl get --watch pod test-projected-volume +``` + + 输出结果和下面类似: + NAME READY STATUS RESTARTS AGE + test-projected-volume 1/1 Running 0 14s + +1. 在另外一个终端中,打开容器的 shell: +```shell + kubectl exec -it test-projected-volume -- /bin/sh +``` + +1. 在 shell 中,确认 `projected-volume` 目录包含你的投射源: +```shell + ls /projected-volume/ +``` +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 进一步了解[`投射`](/docs/concepts/storage/volumes/#projected) 卷。 +* 阅读[一体卷](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)设计文档。 +{{% /capture %}} + diff --git a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..0c8414e4e6 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,454 @@ +--- +reviewers: +- bprashanth +- liggitt +- thockin +title: 为 Pod 配置服务账户 +content_template: templates/task +weight: 90 +--- + + + +{{% capture overview %}} + + + +服务账户为 Pod 中运行的进程提供了一个标识。 + +*本文是服务账户的用户使用介绍。您也可以参考[集群管理指南之服务账户](/docs/reference/access-authn-authz/service-accounts-admin/)。* + + +{{< note >}} + + +本文档描述 Kubernetes 项目推荐的集群中服务帐户的行为。 +集群管理员也可能已经定制了服务账户在集群中的属性,在这种情况下,本文档可能并不适用。 + +{{< /note >}} + + + +当您(人类)访问集群时(例如,使用 `kubectl`),api 服务器将您的身份验证为特定的用户帐户(当前这通常是 `admin`,除非您的集群管理员已经定制了您的集群配置)。 +Pod 内的容器中的进程也可以与 api 服务器接触。 +当它们进行身份验证时,它们被验证为特定的服务帐户(例如,`default`)。 +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 使用默认的服务账户访问 API 服务器 + +当您创建 Pod 时,如果没有指定服务账户,Pod 会被指定命名空间中的`default`服务账户。 +如果您查看 Pod 的原始 json 或 yaml(例如:`kubectl get pods/podname -o yaml`), +您可以看到 `spec.serviceAccountName` 字段已经被[自动设置](/docs/user-guide/working-with-resources/#resources-are-automatically-modified)了。 + + + +您可以使用自动挂载给 Pod 的服务账户凭据访问 API,[访问集群](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中有相关描述。 +服务账户的 API 许可取决于您所使用的[授权插件和策略](/docs/reference/access-authn-authz/authorization/#authorization-modules)。 + +在 1.6 以上版本中,您可以通过在服务账户上设置 `automountServiceAccountToken: false` 来实现不给服务账号自动挂载 API 凭据: + + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + + + +在 1.6 以上版本中,您也可以选择不给特定 Pod 自动挂载 API 凭据: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + + + +如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值,则 Pod 的 spec 优先于服务帐户。 + +## 使用多个服务账户 + +每个命名空间都有一个名为 `default` 的服务账户资源。 +您可以用下面的命令查询这个服务账户以及命名空间中的其他 serviceAccount 资源: + +```shell +kubectl get serviceAccounts +NAME SECRETS AGE +default 1 1d +``` + + + +您可以像这样来创建额外的 ServiceAccount 对象: + +```shell +kubectl create -f - < + +如果您查询服务帐户对象的完整信息,如下所示: + +```shell +kubectl get serviceaccounts/build-robot -o yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-06-16T00:12:59Z + name: build-robot + namespace: default + resourceVersion: "272500" + selfLink: /api/v1/namespaces/default/serviceaccounts/build-robot + uid: 721ab723-13bc-11e5-aec2-42010af0021e +secrets: +- name: build-robot-token-bvbk5 +``` + + + +那么您就能看到系统已经自动创建了一个令牌并且被服务账户所引用。 + +您可以使用授权插件来 [设置服务账户的访问许可](/docs/reference/access-authn-authz/rbac/#service-account-permissions)。 + +要使用非默认的服务账户,只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为您想用的服务账户名称。 + + + +Pod 被创建时服务账户必须存在,否则会被拒绝。 + +您不能更新已经创建好的 Pod 的服务账户。 + +您可以清除服务账户,如下所示: + +```shell +kubectl delete serviceaccount/build-robot +``` + + + +## 手动创建服务账户 API 令牌 + +假设我们有一个上面提到的名为 "build-robot" 的服务账户,然后我们手动创建一个新的 Secret。 + +```shell +kubectl create -f - < + +现在,您可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。 + +令牌控制器将清理不存在的服务帐户的所有令牌。 + +```shell +kubectl describe secrets/build-robot-secret +Name: build-robot-secret +Namespace: default +Labels: +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} + +这里省略了 `token` 的内容。 +{{< /note >}} + + + +## 为服务账户添加 ImagePullSecrets + +首先,创建一个 ImagePullSecrets,可以参考[这里](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 的描述。 +然后,确认创建是否成功。例如: + +```shell +kubectl get secrets myregistrykey +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + + +接着修改命名空间的默认服务帐户,以将该 Secret 用作 imagePullSecret。 + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + + + +需要手动编辑的交互式版本: + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml + +cat sa.yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge + +vi sa.yaml +[editor session not shown] +[delete line with key "resourceVersion"] +[add lines with "imagePullSecrets:"] + +cat sa.yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey + +kubectl replace serviceaccount default -f ./sa.yaml +serviceaccounts/default +``` + + + +现在,在当前命名空间中创建的每个新 Pod 的 spec 中都会添加下面的内容: + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + + + + + +## 服务帐户令牌卷投影 + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} + + +ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段,可以通过向 API 服务器传递以下所有参数来启用它: + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +<!-- +The kubelet can also project a service account token into a Pod. You can +specify desired properties of the token, such as the audience and the validity +duration. These properties are not configurable on the default service account +token. The service account token will also become invalid against the API when +the Pod or the ServiceAccount is deleted. +--> + +kubelet 还可以将服务帐户令牌投影到 Pod 中。 +您可以指定令牌的所需属性,例如受众和有效持续时间。 +这些属性在默认服务帐户令牌上无法配置。 +当删除 Pod 或 ServiceAccount 时,服务帐户令牌也将对 API 无效。 + + + +使用名为 [ServiceAccountToken](/docs/concepts/storage/volumes/#projected) 的 ProjectedVolume 类型在 PodSpec 上配置此功能。 +要向 Pod 提供具有 "vault" 观众以及两个小时有效期的令牌,可以在 PodSpec 中配置以下内容: + +```yaml +kind: Pod +apiVersion: v1 +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault +``` + + + +Kubelet 将代表 Pod 请求和存储令牌,使令牌在可配置的文件路径上对 Pod 可用,并在令牌接近到期时刷新令牌。 +如果令牌存活时间大于其总 TTL 的 80% 或者大于 24 小时,Kubelet 则会主动旋转令牌。 + +应用程序负责在令牌旋转时重新加载令牌。 +对于大多数情况,定期重新加载(例如,每 5 分钟一次)就足够了。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md new file mode 100644 index 0000000000..8d5395f68c --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -0,0 +1,198 @@ +--- +title: 配置 Pod 以使用卷进行存储 +content_template: templates/task +weight: 50 +--- + + + +{{% capture overview %}} + +此页面展示了如何配置 Pod 以使用卷进行存储。 + +只要容器存在,容器的文件系统就会存在,因此当一个容器终止并重新启动,对该容器的文件系统改动将丢失。对于独立于容器的持久化存储,您可以使用[卷](/docs/concepts/storage/volumes/)。这对于有状态应用程序尤为重要,例如键值存储(如 Redis)和数据库。 + + + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## 为 Pod 配置卷 + +在本练习中,您将创建一个运行 Pod,该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷,在整个 Pod 生命周期中一直存在,即使 Pod 中的容器被终止和重启。以下是 Pod 的配置: + + + +{{< codenew file="pods/storage/redis.yaml" >}} + +1. 创建 Pod: + + ```shell + kubectl create -f https://k8s.io/examples/pods/storage/redis.yaml + ``` + +1. 验证 Pod 中的容器是否正在运行,然后留意 Pod 的更改: + + ```shell + kubectl get pod redis --watch + ``` + + 输出如下: + + ```shell + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + ``` + +1. 在另一个终端,用 shell 连接正在运行的容器: + + ```shell + kubectl exec -it redis -- /bin/bash + ``` + +1. 在您的 shell 终端中,切换到 `/data/redis` 目录下,然后创建一个文件: + + ```shell + root@redis:/data# cd /data/redis/ + root@redis:/data/redis# echo Hello > test-file + ``` + +1. 在您的 shell 终端中,列出正在运行的进程: + + ```shell + root@redis:/data/redis# apt-get update + root@redis:/data/redis# apt-get install procps + root@redis:/data/redis# ps aux + ``` + + 输出类似于: + + ```shell + USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND + redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 + root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash + root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux + ``` + +1. 在您的 shell 终端中,结束 Redis 进程: + + ```shell + root@redis:/data/redis# kill + ``` + + 其中 `` 是 Redis 进程的 ID (PID)。 + +1. 在您原先终端中,留意 Redis Pod 的更改。最终您将会看到和下面类似的输出: + + ```shell + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + redis 0/1 Completed 0 6m + redis 1/1 Running 1 6m + ``` + +此时,容器已经终止并重新启动。这是因为 Redis Pod 的 [restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 为 `Always`。 + + +1. 用 shell 终端进入重新启动的容器中: + + + ```shell + kubectl exec -it redis -- /bin/bash + ``` + +1. 在您的 shell 终端中,进入到 `/data/redis` 目录下,并确认 `test-file` 文件是否仍然存在。 + + + ```shell + root@redis:/data/redis# cd /data/redis/ + root@redis:/data/redis# ls + test-file + ``` + +1. 删除为此练习所创建的 Pod: + + + ```shell + kubectl delete pod redis + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 参阅[卷](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)。 + +* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。 + +* 除了 `emptyDir` 提供的本地磁盘存储外,Kubernetes 还支持许多不同的网络附加存储解决方案,包括 GCE 上的 PD 和 EC2 上的 EBS,它们是关键数据的首选,并将处理节点上的一些细节,例如安装和卸载设备。了解更多详情请参阅[卷](/docs/concepts/storage/volumes/)。 + + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/extended-resource.md b/content/zh/docs/tasks/configure-pod-container/extended-resource.md new file mode 100644 index 0000000000..a2e1228786 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/extended-resource.md @@ -0,0 +1,235 @@ +--- +title: 为容器分派扩展资源 +content_template: templates/task +weight: 40 +--- + + + +{{% capture overview %}} + + + +本文介绍如何为容器指定扩展资源。 + +{{< feature-state state="stable" >}} + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +在您开始此练习前,请先练习[为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)。 +在那个练习中将配置您的一个节点来广播 dongle 资源。 + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 给 Pod 分派扩展资源 + +要请求扩展资源,需要在您的容器清单中包括 `resources:requests` 字段。 +扩展资源可以使用任何完全限定名称,只是不能使用 `*.kubernetes.io/`。 +有效的扩展资源名的格式为 `example.com/foo`,其中 `example.com` 应被替换为您的组织的域名,而 `foo` 则是描述性的资源名称。 + +下面是包含一个容器的 Pod 配置文件: + +{{< codenew file="pods/resource/extended-resource-pod.yaml" >}} + + + +在配置文件中,您可以看到容器请求了 3 个 dongles。 + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml +``` + + + +检查 Pod 是否运行正常: + +```shell +kubectl get pod extended-resource-demo +``` + + + +描述 Pod: + +```shell +kubectl describe pod extended-resource-demo +``` + + + +输出结果显示 dongle 请求如下: + +```yaml +Limits: + example.com/dongle: 3 +Requests: + example.com/dongle: 3 +``` + + + +## 尝试创建第二个 Pod + +下面是包含一个容器的 Pod 配置文件,容器请求了 2 个 dongles。 + +{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}} + + + +Kubernetes 将不能满足 2 个 dongles 的请求,因为第一个 Pod 已经使用了 4 个可用 dongles 中的 3 个。 + +尝试创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml +``` + + + +描述 Pod + +```shell +kubectl describe pod extended-resource-demo-2 +``` + + + +输出结果表明 Pod 不能被调度,因为没有一个节点上存在两个可用的 dongles。 + +``` +Conditions: + Type Status + PodScheduled False +... +Events: + ... + ... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node +fit failure summary on nodes : Insufficient example.com/dongle (1) +``` + + + +查看 Pod 的状态: + +```shell +kubectl get pod extended-resource-demo-2 +``` + + + +输出结果表明 Pod 虽然被创建了,但没有被调度到节点上正常运行。Pod 的状态为 Pending: + +```yaml +NAME READY STATUS RESTARTS AGE +extended-resource-demo-2 0/1 Pending 0 6m +``` + + + +## 环境清理 + +删除本练习中创建的 Pod: + +```shell +kubectl delete pod extended-resource-demo +kubectl delete pod extended-resource-demo-2 +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +## 应用开发者参考 + +* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) +* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) + + + +### 集群管理员参考 + +* [为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md new file mode 100644 index 0000000000..7a2cc0d7c2 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -0,0 +1,286 @@ +--- +title: 从私有仓库拉取镜像 +content_template: templates/task +weight: 100 +--- + + + +{{% capture overview %}} + + + +本文介绍如何使用 Secret 从私有的 Docker 镜像仓库或代码仓库拉取镜像来创建 Pod。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +您需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 登录 Docker 镜像仓库 + +在个人电脑上,要想拉取私有镜像必须在镜像仓库上进行身份验证。 + +```shell +docker login +``` + + + +当提示时,输入 Docker 用户名和密码。 + +登录过程会创建或更新保存有授权令牌的 `config.json` 文件。 + +查看 `config.json` 文件: + +```shell +cat ~/.docker/config.json +``` + + + +输出结果包含类似于以下内容的部分: + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "auth": "c3R...zE2" + } + } +} +``` + +{{< note >}} + +如果使用 Docker 凭证仓库,则不会看到 `auth` 条目,看到的将是以仓库名称作为值的 `credsStore` 条目。 +{{< /note >}} + + + +## 在集群中创建保存授权令牌的 Secret + +Kubernetes 集群使用 `docker-registry` 类型的 Secret 来通过容器仓库的身份验证,进而提取私有映像。 + +创建 Secret,命名为 `regcred`: + +```shell +kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email= +``` + + + +在这里: + +* `` 是你的私有 Docker 仓库全限定域名(FQDN)。(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分) +* `` 是你的 Docker 用户名。 +* `` 是你的 Docker 密码。 +* `` 是你的 Docker 邮箱。 + +这样您就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。 + + + +## 检查 Secret `regcred` + +要了解你创建的 `regcred` Secret 的内容,可以用 YAML 格式进行查看: + +```shell +kubectl get secret regcred --output=yaml +``` + + + +输出和下面类似: + +```yaml +apiVersion: v1 +data: + .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0= +kind: Secret +metadata: + ... + name: regcred + ... +type: kubernetes.io/dockerconfigjson +``` + + + +`.dockerconfigjson` 字段的值是 Docker 凭据的 base64 表示。 + +要了解 `dockerconfigjson` 字段中的内容,请将 Secret 数据转换为可读格式: + +```shell +kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode +``` + + + +输出和下面类似: + +```json +{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}} +``` + + + +要了解 `auth` 字段中的内容,请将 base64 编码过的数据转换为可读格式: + +```shell +echo "c3R...zE2" | base64 --decode +``` + + + +输出结果中,用户名和密码用 `:` 链接,类似下面这样: + +```none +janedoe:xxxxxxxxxxx +``` + + + +注意,Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。 + +这样您就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。 + +## 创建一个使用您的 Secret 的 Pod + +下面是一个 Pod 配置文件,它需要访问 `regcred` 中的 Docker 凭据: + +{{< codenew file="pods/private-reg-pod.yaml" >}} + + + +下载上述文件: + +```shell +wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +``` + + + +在`my-private-reg-pod.yaml` 文件中,使用私有仓库的镜像路径替换 ``,例如: + +```none +janedoe/jdoe-private:v1 +``` + + + +要从私有仓库拉取镜像,Kubernetes 需要凭证。 +配置文件中的 `imagePullSecrets` 字段表明 Kubernetes 应该通过名为 `regcred` 的 Secret 获取凭证。 + +创建使用了你的 Secret 的 Pod,并检查它是否正常运行: + +```shell +kubectl create -f my-private-reg-pod.yaml +kubectl get pod private-reg +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 进一步了解 [Secrets](/docs/concepts/configuration/secret/)。 +* 进一步了解 [使用私有仓库](/docs/concepts/containers/images/#using-a-private-registry)。 +* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)。 +* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)。 +* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段 。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md new file mode 100644 index 0000000000..1be7afdddc --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md @@ -0,0 +1,440 @@ +--- +title: 配置 Pod 的服务质量 +content_template: templates/task +weight: 30 +--- + + + +{{% capture overview %}} + + + +本文介绍怎样配置 Pod 让其获得特定的服务质量(QoS)类。Kubernetes 使用 QoS 类来决定 Pod 的调度和驱逐策略。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## QoS 类 + +Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类: + +* Guaranteed +* Burstable +* BestEffort + + + +## 创建命名空间 + +创建一个命名空间,以便将本练习所创建的资源与集群的其余资源相隔离。 + +```shell +kubectl create namespace qos-example +``` + + + +## 创建一个 QoS 类为 Guaranteed 的 Pod + +对于 QoS 类为 Guaranteed 的 Pod: + +* Pod 中的每个容器必须指定内存请求和内存限制,并且两者要相等。 +* Pod 中的每个容器必须指定 CPU 请求和 CPU 限制,并且两者要相等。 + +下面是包含一个容器的 Pod 配置文件。 +容器设置了内存请求和内存限制,值都是 200 MiB。 +容器设置了 CPU 请求和 CPU 限制,值都是 700 milliCPU: + +{{< codenew file="pods/qos/qos-pod.yaml" >}} + + + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example +``` + + + +查看 Pod 详情: + +```shell +kubectl get pod qos-demo --namespace=qos-example --output=yaml +``` + + + +结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Guaranteed。 +结果也确认了 Pod 容器设置了与内存限制匹配的内存请求,设置了与 CPU 限制匹配的 CPU 请求。 + +```yaml +spec: + containers: + ... + resources: + limits: + cpu: 700m + memory: 200Mi + requests: + cpu: 700m + memory: 200Mi +... + qosClass: Guaranteed +``` + +{{< note >}} + + +如果容器指定了自己的内存限制,但没有指定内存请求,Kubernetes 会自动为它指定与内存限制匹配的内存请求。 +同样,如果容器指定了自己的 CPU 限制,但没有指定 CPU 请求,Kubernetes 会自动为它指定与 CPU 限制匹配的 CPU 请求。 +{{< /note >}} + + + +删除 Pod: + +```shell +kubectl delete pod qos-demo --namespace=qos-example +``` + + + +## 创建一个 QoS 类为 Burstable 的 Pod + +如果满足下面条件,将会指定 Pod 的 QoS 类为 Burstable: + +* Pod 不符合 Guaranteed QoS 类的标准。 +* Pod 中至少一个容器具有内存或 CPU 请求。 + +下面是包含一个容器的 Pod 配置文件。 +容器设置了内存限制 200 MiB 和内存请求 100 MiB。 + +{{< codenew file="pods/qos/qos-pod-2.yaml" >}} + + + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example +``` + + + +查看 Pod 详情: + +```shell +kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml +``` + + + +结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable。 + +```yaml +spec: + containers: + - image: nginx + imagePullPolicy: Always + name: qos-demo-2-ctr + resources: + limits: + memory: 200Mi + requests: + memory: 100Mi +... + qosClass: Burstable +``` + + + +删除 Pod: + +```shell +kubectl delete pod qos-demo-2 --namespace=qos-example +``` + + + +## 创建一个 QoS 类为 BestEffort 的 Pod + +对于 QoS 类为 BestEffort 的 Pod,Pod 中的容器必须没有设置内存和 CPU 限制或请求。 + +下面是包含一个容器的 Pod 配置文件。 +容器没有设置内存和 CPU 限制或请求。 + + + +{{< codenew file="pods/qos/qos-pod-3.yaml" >}} + + + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example +``` + + + +查看 Pod 详情: + +```shell +kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml +``` + + + +结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。 + +```yaml +spec: + containers: + ... + resources: {} + ... + qosClass: BestEffort +``` + + + +删除 Pod: + +```shell +kubectl delete pod qos-demo-3 --namespace=qos-example +``` + + + +## 创建包含两个容器的 Pod + +下面是包含两个容器的 Pod 配置文件。 +一个容器指定了内存请求 200 MiB。 +另外一个容器没有指定任何请求和限制。 + + +{{< codenew file="pods/qos/qos-pod-4.yaml" >}} + + + +注意此 Pod 满足 Burstable QoS 类的标准。 +也就是说它不满足 Guaranteed QoS 类标准,因为它的一个容器设有内存请求。 + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example +``` + + + +查看 Pod 详情: + +```shell +kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml +``` + + + +结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable: + +```yaml +spec: + containers: + ... + name: qos-demo-4-ctr-1 + resources: + requests: + memory: 200Mi + ... + name: qos-demo-4-ctr-2 + resources: {} + ... + qosClass: Burstable +``` + + + +删除 Pod: + +```shell +kubectl delete pod qos-demo-4 --namespace=qos-example +``` + + + +## 环境清理 + +删除命名空间: + +```shell +kubectl delete namespace qos-example +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + + +### 应用开发者参考 + +* [为 Pod 和容器分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) + +* [为 Pod 和容器分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) + + + +### 集群管理员参考 + +* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [为命名空间配置最小和最大 CPU 限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/) + + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/configure-pod-container/share-process-namespace.md b/content/zh/docs/tasks/configure-pod-container/share-process-namespace.md new file mode 100644 index 0000000000..9e745c9e93 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/share-process-namespace.md @@ -0,0 +1,187 @@ +--- +title: 在 Pod 中的容器之间共享进程命名空间 +min-kubernetes-server-version: v1.10 +content_template: templates/task +weight: 160 +--- + + +{{% capture overview %}} + +{{< feature-state state="beta" >}} + + +此页面展示如何为 pod 配置进程命名空间共享。 +当启用进程命名空间共享时,容器中的进程对该 pod 中的所有其他容器都是可见的。 + + +您可以使用此功能来配置协作容器,比如日志处理 sidecar 容器,或者对那些不包含诸如 shell 等调试实用工具的镜像进行故障排查。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +进程命名空间共享是默认启用的 **beta** 版功能。 +您可以通过设置 `--feature-gates=PodShareProcessNamespace=false` 禁用此功能。 + +{{% /capture %}} + +{{% capture steps %}} + + +## 配置 Pod + + +进程命名空间共享使用 `v1.PodSpec` 中的 `ShareProcessNamespace` 字段启用。例如: + +{{< codenew file="pods/share-process-namespace.yaml" >}} + + +1. 在集群中创建 `nginx` pod: + + kubectl create -f https://k8s.io/examples/pods/share-process-namespace.yaml + +2. 获取容器 `shell`,执行 `ps`: + + ``` + kubectl attach -it nginx -c shell + ``` + + 如果没有看到命令提示符,请按 enter 回车键。 + + ``` + / # ps ax + PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 14 101 0:00 nginx: worker process + 15 root 0:00 sh + 21 root 0:00 ps ax + ``` + +您可以在其他容器中对进程发出信号。例如,发送 `SIGHUP` 到 nginx 以重启工作进程。这需要 `SYS_PTRACE` 功能。 + + / # kill -HUP 8 + / # ps ax + PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 15 root 0:00 sh + 22 101 0:00 nginx: worker process + 23 root 0:00 ps ax + + +甚至可以使用 `/proc/$pid/root` 链接访问另一个容器镜像。 + + / # head /proc/8/root/etc/nginx/nginx.conf + + user nginx; + worker_processes 1; + + error_log /var/log/nginx/error.log warn; + pid /var/run/nginx.pid; + + + events { + worker_connections 1024; + +{{% /capture %}} + +{{% capture discussion %}} + + +## 理解进程命名空间共享 + + +Pod 共享许多资源,因此它们共享进程命名空间是很有意义的。 +不过,有些容器镜像可能希望与其他容器隔离,因此了解这些差异很重要: + + + +1. **容器进程不再具有 PID 1。** 在没有 PID 1 的情况下,一些容器镜像拒绝启动(例如,使用 `systemd` 的容器),或者拒绝执行 `kill -HUP 1` 之类的命令来通知容器进程。在具有共享进程命名空间的 pod 中,`kill -HUP 1` 将通知 pod 沙箱(在上面的例子中是 `/pause`)。 + +2. **进程对 pod 中的其他容器可见。** 这包括 `/proc` 中可见的所有信息,例如作为参数或环境变量传递的密码。这些仅受常规 Unix 权限的保护。 + +3. **容器文件系统通过 `/proc/$pid/root` 链接对 pod 中的其他容器可见。** 这使调试更加容易,但也意味着文件系统安全性只受文件系统权限的保护。 + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md new file mode 100644 index 0000000000..7623a8d991 --- /dev/null +++ b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -0,0 +1,844 @@ +--- +reviewers: +- cdrage +title: 将 Docker Compose 文件转换为 Kubernetes 资源 +content_template: templates/task +weight: 170 +--- + + + +{{% capture overview %}} + + + +Kompose 是什么?它是个转换工具,可将 compose(即 Docker Compose)所组装的所有内容转换成容器编排器(Kubernetes 或 OpenShift)可识别的形式。 + + + +更多信息请参考 Kompose 官网 [http://kompose.io](http://kompose.io)。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 安装 Kompose + + + +我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。 + + + +## GitHub 发布版本 + + + +Kompose 通过 GitHub 发布版本,发布周期为三星期。您可以在[GitHub 发布页面](https://github.com/kubernetes/kompose/releases)上看到所有当前版本。 + +```sh +# Linux +curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose + +# macOS +curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose + +# Windows +curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe + +chmod +x kompose +sudo mv ./kompose /usr/local/bin/kompose +``` + + +或者,您可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。 + +## Go + + + +用 `go get` 命令从主分支拉取最新的开发变更的方法安装 Kompose。 + + +```sh +go get -u github.com/kubernetes/kompose +``` + +## CentOS + + + +Kompose 位于 [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS 代码仓库。 +如果您还没有安装启用 [EPEL](https://fedoraproject.org/wiki/EPEL) 代码仓库,请运行命令 `sudo yum install epel-release`。 + + + +如果您的系统中已经启用了 [EPEL](https://fedoraproject.org/wiki/EPEL),您就可以像安装其他软件包一样安装 Kompose。 + +```bash +sudo yum -y install kompose +``` + +## Fedora + + + +Kompose 位于 Fedora 24、25 和 26 的代码仓库。您可以像安装其他软件包一样安装 Kompose。 + +```bash +sudo dnf -y install kompose +``` + +## macOS + + + +在 macOS 上您可以通过 [Homebrew](https://brew.sh) 安装 Kompose 的最新版本: + +```bash +brew install kompose + +``` + + +## 使用 Kompose + + + +再需几步,我们就把你从 Docker Compose 带到 Kubernetes。 +您只需要一个现有的 `docker-compose.yml` 文件。 + +1. + 进入 `docker-compose.yml` 文件所在的目录。如果没有,请使用下面这个进行测试。 + + ```yaml + version: "2" + + services: + + redis-master: + image: k8s.gcr.io/redis:e2e + ports: + - "6379" + + redis-slave: + image: gcr.io/google_samples/gb-redisslave:v1 + ports: + - "6379" + environment: + - GET_HOSTS_FROM=dns + + frontend: + image: gcr.io/google-samples/gb-frontend:v4 + ports: + - "80:80" + environment: + - GET_HOSTS_FROM=dns + labels: + kompose.service.type: LoadBalancer + ``` + + +2. + 运行 `kompose up` 命令直接部署到 Kubernetes,或者跳到下一步,生成 `kubectl` 使用的文件。 + + ```bash + $ kompose up + We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. + If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + + INFO Successfully created Service: redis + INFO Successfully created Service: web + INFO Successfully created Deployment: redis + INFO Successfully created Deployment: web + + Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details. + ``` + + +3. + 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件,请运行 `kompose convert` 命令进行转换,然后运行 `kubectl create -f ` 进行创建。 + + ```bash + $ kompose convert + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + ``` + + ```bash + $ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml + service/frontend created + service/redis-master created + service/redis-slave created + deployment.apps/frontend created + deployment.apps/redis-master created + deployment.apps/redis-slave created + ``` + + 您部署的应用在 Kubernetes 中运行起来了。 + + +4. 访问您的应用。 + + + + 如果您在开发过程中使用 `minikube`,请执行: + + ```bash + $ minikube service frontend + ``` + + + 否则,我们要查看一下您的服务使用了什么 IP! + + ```sh + $ kubectl describe svc frontend + Name: frontend + Namespace: default + Labels: service=frontend + Selector: service=frontend + Type: LoadBalancer + IP: 10.0.0.183 + LoadBalancer Ingress: 123.45.67.89 + Port: 80 80/TCP + NodePort: 80 31144/TCP + Endpoints: 172.17.0.4:80 + Session Affinity: None + No events. + + ``` + + + 如果您使用的是云提供商,您的 IP 将在 `LoadBalancer Ingress` 字段给出。 + + ```sh + $ curl http://123.45.67.89 + ``` + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 用户指南 + + + +- CLI + - [`kompose convert`](#kompose-convert) + - [`kompose up`](#kompose-up) + - [`kompose down`](#kompose-down) +- 文档 + - [构建和推送 Docker 镜像](#构建和推送-docker-镜像) + - [其他转换方式](#其他转换方式) + - [标签](#标签) + - [重启](#重启) + - [Docker Compose 版本](#docker-compose-版本) + + + +Kompose 支持两种驱动:OpenShift 和 Kubernetes。 +您可以通过全局选项 `--provider` 选择驱动方式。如果没有指定,会将 Kubernetes 作为默认驱动。 + +## `kompose convert` + +Kompose 支持将 V1、V2 和 V3 版本的 Docker Compose 文件转换为 Kubernetes 和 OpenShift 资源对象。 + +### Kubernetes + +```sh +$ kompose --file docker-voting.yml convert +WARN Unsupported key networks - ignoring +WARN Unsupported key build - ignoring +INFO Kubernetes file "worker-svc.yaml" created +INFO Kubernetes file "db-svc.yaml" created +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "result-svc.yaml" created +INFO Kubernetes file "vote-svc.yaml" created +INFO Kubernetes file "redis-deployment.yaml" created +INFO Kubernetes file "result-deployment.yaml" created +INFO Kubernetes file "vote-deployment.yaml" created +INFO Kubernetes file "worker-deployment.yaml" created +INFO Kubernetes file "db-deployment.yaml" created + +$ ls +db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml +db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml +``` + + + +您也可以同时提供多个 docker-compose 文件进行转换: + +```sh +$ kompose -f docker-compose.yml -f docker-guestbook.yml convert +INFO Kubernetes file "frontend-service.yaml" created +INFO Kubernetes file "mlbparks-service.yaml" created +INFO Kubernetes file "mongodb-service.yaml" created +INFO Kubernetes file "redis-master-service.yaml" created +INFO Kubernetes file "redis-slave-service.yaml" created +INFO Kubernetes file "frontend-deployment.yaml" created +INFO Kubernetes file "mlbparks-deployment.yaml" created +INFO Kubernetes file "mongodb-deployment.yaml" created +INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created +INFO Kubernetes file "redis-master-deployment.yaml" created +INFO Kubernetes file "redis-slave-deployment.yaml" created + +$ ls +mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml +frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml +frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml +redis-master-deployment.yaml +``` + + + +当提供多个 docker-compose 文件时,配置将会合并。任何通用的配置都将被后续文件覆盖。 + +### OpenShift + +```sh +$ kompose --provider openshift --file docker-voting.yml convert +WARN [worker] Service cannot be created because of missing port. +INFO OpenShift file "vote-service.yaml" created +INFO OpenShift file "db-service.yaml" created +INFO OpenShift file "redis-service.yaml" created +INFO OpenShift file "result-service.yaml" created +INFO OpenShift file "vote-deploymentconfig.yaml" created +INFO OpenShift file "vote-imagestream.yaml" created +INFO OpenShift file "worker-deploymentconfig.yaml" created +INFO OpenShift file "worker-imagestream.yaml" created +INFO OpenShift file "db-deploymentconfig.yaml" created +INFO OpenShift file "db-imagestream.yaml" created +INFO OpenShift file "redis-deploymentconfig.yaml" created +INFO OpenShift file "redis-imagestream.yaml" created +INFO OpenShift file "result-deploymentconfig.yaml" created +INFO OpenShift file "result-imagestream.yaml" created +``` + + + +kompose 还支持为服务中的构建指令创建 buildconfig。 +默认情况下,它使用当前 git 分支的 remote 仓库作为源仓库,使用当前分支作为构建的源分支。 +您可以分别使用 ``--build-repo`` 和 ``--build-branch`` 选项指定不同的源仓库和分支。 + +```sh +$ kompose --provider openshift --file buildconfig/docker-compose.yml convert +WARN [foo] Service cannot be created because of missing port. +INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. +INFO OpenShift file "foo-deploymentconfig.yaml" created +INFO OpenShift file "foo-imagestream.yaml" created +INFO OpenShift file "foo-buildconfig.yaml" created +``` + +{{< note >}} + + +如果使用 ``oc create -f`` 手动推送 Openshift 工件,则需要确保在构建配置工件之前推送 imagestream 工件,以解决 Openshift 的这个问题:https://github.com/openshift/origin/issues/4518 。 +{{< /note >}} + +## `kompose up` + + + +Kompose 支持通过 `kompose up` 直接将您的"复合的(composed)" 应用程序部署到 Kubernetes 或 OpenShift。 + +### Kubernetes + +```sh +$ kompose --file ./examples/docker-guestbook.yml up +We are going to create Kubernetes deployments and services for your Dockerized application. +If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + +INFO Successfully created service: redis-master +INFO Successfully created service: redis-slave +INFO Successfully created service: frontend +INFO Successfully created deployment: redis-master +INFO Successfully created deployment: redis-slave +INFO Successfully created deployment: frontend + +Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details. + +$ kubectl get deployment,svc,pods +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +deployment.extensions/frontend 1 1 1 1 4m +deployment.extensions/redis-master 1 1 1 1 4m +deployment.extensions/redis-slave 1 1 1 1 4m + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/frontend ClusterIP 10.0.174.12 80/TCP 4m +service/kubernetes ClusterIP 10.0.0.1 443/TCP 13d +service/redis-master ClusterIP 10.0.202.43 6379/TCP 4m +service/redis-slave ClusterIP 10.0.1.85 6379/TCP 4m + +NAME READY STATUS RESTARTS AGE +pod/frontend-2768218532-cs5t5 1/1 Running 0 4m +pod/redis-master-1432129712-63jn8 1/1 Running 0 4m +pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m +``` + + + +**注意**: + +- 您必须有一个运行正常的 Kubernetes 集群,该集群具有预先配置的 kubectl 上下文。 +- 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。如果需要部署其他不同类型的资源,请使用 `kompose convert` 和 `kubectl create -f` 命令。 + + +### OpenShift +```sh +$ kompose --file ./examples/docker-guestbook.yml --provider openshift up +We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application. +If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead. + +INFO Successfully created service: redis-slave +INFO Successfully created service: frontend +INFO Successfully created service: redis-master +INFO Successfully created deployment: redis-slave +INFO Successfully created ImageStream: redis-slave +INFO Successfully created deployment: frontend +INFO Successfully created ImageStream: frontend +INFO Successfully created deployment: redis-master +INFO Successfully created ImageStream: redis-master + +Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details. + +$ oc get dc,svc,is +NAME REVISION DESIRED CURRENT TRIGGERED BY +dc/frontend 0 1 0 config,image(frontend:v4) +dc/redis-master 0 1 0 config,image(redis-master:e2e) +dc/redis-slave 0 1 0 config,image(redis-slave:v1) +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +svc/frontend 172.30.46.64 80/TCP 8s +svc/redis-master 172.30.144.56 6379/TCP 8s +svc/redis-slave 172.30.75.245 6379/TCP 8s +NAME DOCKER REPO TAGS UPDATED +is/frontend 172.30.12.200:5000/fff/frontend +is/redis-master 172.30.12.200:5000/fff/redis-master +is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 +``` + + + +**注意**: + +- 您必须有一个运行正常的 OpenShift 集群,该集群具有预先配置的 `oc` 上下文 (`oc login`)。 + +## `kompose down` + + + +您一旦将"复合(composed)" 应用部署到 Kubernetes,`$ kompose down` 命令将能帮您通过删除 Deployment 和 Service 对象来删除应用。如果需要删除其他资源,请使用 'kubectl' 命令。 + +```sh +$ kompose --file docker-guestbook.yml down +INFO Successfully deleted service: redis-master +INFO Successfully deleted deployment: redis-master +INFO Successfully deleted service: redis-slave +INFO Successfully deleted deployment: redis-slave +INFO Successfully deleted service: frontend +INFO Successfully deleted deployment: frontend +``` + + + +**注意**: + +- 您必须有一个运行正常的 Kubernetes 集群,该集群具有预先配置的 kubectl 上下文。 + +## 构建和推送 Docker 镜像 + +Kompose 支持构建和推送 Docker 镜像。如果 Docker Compose 文件中使用了 `build` 关键字,您的镜像将会: + + - 使用文档中指定的 `image` 键自动构建 Docker 镜像 + - 使用本地凭据推送到正确的 Docker 仓库 + +使用 [Docker Compose 文件示例](https://raw.githubusercontent.com/kubernetes/kompose/master/examples/buildconfig/docker-compose.yml) + +```yaml +version: "2" + +services: + foo: + build: "./build" + image: docker.io/foo/bar +``` + + + +使用带有 `build` 键的 `kompose up` 命令: + +```none +$ kompose up +INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' +INFO Building image 'docker.io/foo/bar' from directory 'build' +INFO Image 'docker.io/foo/bar' from directory 'build' built successfully +INFO Pushing image 'foo/bar:latest' to registry 'docker.io' +INFO Attempting authentication credentials 'https://index.docker.io/v1/ +INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io' +INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + +INFO Deploying application in "default" namespace +INFO Successfully created Service: foo +INFO Successfully created Deployment: foo + +Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details. +``` + + + +要想禁用该功能,或者使用 BuildConfig 中的版本(在 OpenShift 中),可以通过传递 `--build (local|build-config|none)` 参数来实现。 + +```sh +# Disable building/pushing Docker images +$ kompose up --build none + +# Generate Build Config artifacts for OpenShift +$ kompose up --provider openshift --build build-config +``` + + + +## 其他转换方式 + +默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes [Deployment](/docs/concepts/workloads/controllers/deployment/) 和 [Service](/docs/concepts/services-networking/service/) 对象。 +您可以选择通过 `-j` 参数生成 json 格式的对象。 +您也可以替换生成 [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) 对象、[Daemon Sets](/docs/concepts/workloads/controllers/daemonset/) 或 [Helm](https://github.com/helm/helm) charts。 + +```sh +$ kompose convert -j +INFO Kubernetes file "redis-svc.json" created +INFO Kubernetes file "web-svc.json" created +INFO Kubernetes file "redis-deployment.json" created +INFO Kubernetes file "web-deployment.json" created +``` + + + +`*-deployment.json` 文件中包含 Deployment 对象。 + +```sh +$ kompose convert --replication-controller +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-replicationcontroller.yaml" created +INFO Kubernetes file "web-replicationcontroller.yaml" created +``` + + + +`*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。如果您想指定副本数(默认为 1),可以使用 `--replicas` 参数:`$ kompose convert --replication-controller --replicas 3` + +```sh +$ kompose convert --daemon-set +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-daemonset.yaml" created +INFO Kubernetes file "web-daemonset.yaml" created +``` + + + +`*-daemonset.yaml` 文件包含 Daemon Set 对象。 + +如果您想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart,只需简单的执行下面的命令: + +```sh +$ kompose convert -c +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-deployment.yaml" created +INFO Kubernetes file "redis-deployment.yaml" created +chart created in "./docker-compose/" + +$ tree docker-compose/ +docker-compose +├── Chart.yaml +├── README.md +└── templates + ├── redis-deployment.yaml + ├── redis-svc.yaml + ├── web-deployment.yaml + └── web-svc.yaml +``` + + + +这个图标结构旨在为构建 Helm Chart 提供框架。 + +## 标签 + +`kompose` 支持 `docker-compose.yml` 文件中用于 Kompose 的标签,以便在转换时明确定义 Service 的行为。 + +- `kompose.service.type` 定义要创建的 Service 类型。 + + + +```yaml +version: "2" +services: + nginx: + image: nginx + dockerfile: foobar + build: ./foobar + cap_add: + - ALL + container_name: foobar + labels: + kompose.service.type: nodeport +``` + + + +- `kompose.service.expose` 定义 是否允许从集群外部访问 Service。如果该值被设置为 "true",提供程序将自动设置端点,对于任何其他值,该值将被设置为主机名。如果在 Service 中定义了多个端口,则选择第一个端口作为公开端口。 + - 对于 Kubernetes 驱动程序,创建了一个 Ingress 资源,并且假定已经配置了相应的 Ingress 控制器。 + - 对于 OpenShift 驱动程序, 创建一个 route。 + +例如: + +```yaml +version: "2" +services: + web: + image: tuna/docker-counter23 + ports: + - "5000:5000" + links: + - redis + labels: + kompose.service.expose: "counter.example.com" + redis: + image: redis:3.0 + ports: + - "6379" +``` + + + +当前支持的选项有: + +| 键 | 值 | +|----------------------|-------------------------------------| +| kompose.service.type | nodeport / clusterip / loadbalancer | +| kompose.service.expose| true / hostname | + + +{{< note >}} + +`kompose.service.type` 标签应该只用`ports`来定义,否则 `kompose` 会失败。 +{{< /note >}} + + + +## 重启 + +如果你想创建没有控制器的普通 Pod,可以使用 docker-compose 的 `restart` 结构来定义它。请参考下表了解 `restart` 的不同参数。 + + + +| `docker-compose` `restart` | 创建的对象 | Pod `restartPolicy` | +|----------------------------|-------------------|---------------------| +| `""` | 控制器对象 | `Always` | +| `always` | 控制器对象 | `Always` | +| `on-failure` | Pod | `OnFailure` | +| `no` | Pod | `Never` | + + + +{{< note >}} + +控制器对象可以是 `deployment` 或 `replicationcontroller` 等。 +{{< /note >}} + + + +例如,`pival` Service 将在这里变成 Pod。这个容器的计算值为 `pi`。 + +```yaml +version: '2' + +services: + pival: + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restart: "on-failure" +``` + + + +### 关于 Deployment Config 的提醒 + +如果 Docker Compose 文件中为服务声明了卷,Deployment (Kubernetes) 或 DeploymentConfig (OpenShift) 的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。 +这样做的目的是为了避免服务的多个实例同时访问卷。 + + + +如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`),那么将会被替换为 `-`,服务也相应的会重命名(例如 `web-service`)。 +Kompose 这样做的原因是 "Kubernetes" 不允许对象名称中包含 `_`。 + + + +## Docker Compose 版本 + +Kompose 支持的 Docker Compose 版本包括:1、2 和 3。有限支持 2.1 和 3.2 版本,因为它们还在实验阶段。 + +所有三个版本的兼容性列表请查看我们的 [转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md),文档中列出了所有不兼容的 Docker Compose 关键字。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/_index.md b/content/zh/docs/tasks/debug-application-cluster/_index.md index d78ae89c63..8932f3e7ee 100644 --- a/content/zh/docs/tasks/debug-application-cluster/_index.md +++ b/content/zh/docs/tasks/debug-application-cluster/_index.md @@ -1,12 +1,11 @@ +--- +title: "监控、日志和排错" +weight: 80 +--- + - ---- -title: "监控、日志和排错" -weight: 80 ---- - diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md index f833d148b4..2a1a9c25eb 100644 --- a/content/zh/docs/tasks/debug-application-cluster/audit.md +++ b/content/zh/docs/tasks/debug-application-cluster/audit.md @@ -602,7 +602,7 @@ Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您 [auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md [auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1beta1/types.go [gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 -[kubeconfig]: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/ +[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ [fluentd]: http://www.fluentd.org/ [fluentd_install_doc]: http://docs.fluentd.org/v0.12/articles/quickstart#step1-installing-fluentd [logstash]: https://www.elastic.co/products/logstash diff --git a/content/zh/docs/tasks/debug-application-cluster/core-metrics-pipeline.md b/content/zh/docs/tasks/debug-application-cluster/core-metrics-pipeline.md new file mode 100644 index 0000000000..35429257c5 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/core-metrics-pipeline.md @@ -0,0 +1,120 @@ +--- +reviewers: +- fgrzadkowski +- piosz +title: 核心指标传递管道 +content_template: templates/concept +--- + + + +{{% capture overview %}} + + + +从 Kubernetes 1.8 版本开始,用户在 Kubernetes 中可以通过度量 API 获取资源使用度量(如容器 CPU 和内存使用率)。 +这些度量可以由用户直接访问,例如使用 `kubectl top` 命令,也可以由集群中的控制器(例如 Pod 水平自动扩缩器)用来做决策。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 度量 API + + + +通过度量 API,您可以获得给定节点或给定 Pod 当前使用的资源数量。 +此 API 不存储度量值,因此不可能获得 10 分钟前给定节点使用的资源数量。 + + + +度量 API 和其他 API 没有什么不同: + + + +- 它可通过与 `/apis/metrics.k8s.io/` 路径下的其他 Kubernetes API 相同的端点来发现 +- 它提供相同的安全性、可扩展性和可靠性保证 + + + + +度量 API 是在 [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) 仓库进行定义的。您可以在那里找到该 API 相关的更多信息。 + +{{< note >}} + +度量 API 要求在集群中部署度量服务器。否则它将不可用。 +{{< /note >}} + + + +## 度量服务器 + + + +[指标服务器](https://github.com/kubernetes-incubator/metrics-server)是集群范围内的资源使用数据的聚合器。 +从 Kubernetes 1.8 版本开始,它作为部署对象默认部署在由 `kube-up.sh` 脚本创建的集群中。 +如果您使用了不同的 Kubernetes 安装机制,则可以使用提供的[部署 yaml](https://github.com/kubernetes孵化器/metrics-server/tree/master/deploy)。 +它在 Kubernetes 1.7 以上版本中被支持(请参见下面的详细信息)。 + + + + +度量服务器通过 Summary API 获取度量值,该 API 由 [Kubelet](/docs/admin/kubelet/) 在每个节点上进行暴露。 + + + +度量服务器通过 [Kubernetes 聚合器](/docs/concepts/api-extension/apiserver-aggregation/)在主 API 服务器中注册,该聚合器是在 Kubernetes 1.7 版本中引入的。 + + + + +进一步了解度量服务器请参考[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/crictl.md b/content/zh/docs/tasks/debug-application-cluster/crictl.md new file mode 100644 index 0000000000..aa25f7cd11 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/crictl.md @@ -0,0 +1,485 @@ +--- +reviewers: +- Random-Liu +- feiskyer +- mrunalp +title: 使用 crictl 对 Kubernetes 节点进行调试 +content_template: templates/task +--- + + + + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + + + +`crictl` 是 CRI 兼容的容器运行时命令行接口。 +您可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。 +`crictl`和它的源代码在 [cri-tools](https://github.com/kubernetes-incubator/cri-tools) 代码库. + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +`crictl` 需要带有 CRI 运行时的 Linux 操作系统。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 安装 crictl + +您可以从 cri-tools [发布页面](https://github.com/kubernetes-incubator/cri-tools/releases)下载一个压缩的 `crictl` 归档文件,用于几种不同的架构。 +下载与您的 kubernetes 版本相对应的版本。 +提取它并将其移动到系统路径上的某个位置,例如`/usr/local/bin/`。 + + + +## 一般用法 + + + +`crictl` 命令有几个子命令和运行时参数。 +有关详细信息,请使用 `crictl help` 或 `crictl help` 获取帮助信息。 + + + +`crictl` 默认连接到 `unix:///var/run/dockershim.sock`。 +对于其他的运行时,您可以用多种不同的方法设置端点: + + + +- 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint` +- 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT` +- 通过在配置文件中设置端点 `--config=/etc/crictl.yaml` + + + + +您还可以在连接到服务器并启用或禁用调试时指定超时值,方法是在配置文件中指定 `timeout` 或 `debug` 值,或者使用 `--timeout` 和 `--debug` 命令行参数。 + + + +要查看或编辑当前配置,请查看或编辑 `/etc/crictl.yaml` 的内容。 + +```sh +cat /etc/crictl.yaml +runtime-endpoint: unix:///var/run/dockershim.sock +image-endpoint: unix:///var/run/dockershim.sock +timeout: 10 +debug: true +``` + + + +## crictl 命令示例 + +{{< warning >}} + +如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器,kubelet 最终将删除它们。 +`crictl` 不是一个通用的工作流工具,而是一个对调试有用的工具。 +{{< /warning >}} + + + +### 打印 Pod 清单 + +打印所有 Pod 的清单: + +```bash +crictl pods +``` +```none +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 +4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 +a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0 +919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0 +``` + + + +根据名称打印 Pod 清单: + +```bash +crictl pods --name nginx-65899c769f-wv2gp +``` +```none +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + + + +根据标签打印 Pod 清单: + +```bash +crictl pods --label run=nginx +``` +```none +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + + + +### 打印镜像清单 + +打印所有镜像清单: + +```bash +crictl images +``` +```none +IMAGE TAG IMAGE ID SIZE +busybox latest 8c811b4aec35f 1.15MB +k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB +k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB +nginx latest cd5239a0906a6 109MB +``` + + + +根据仓库打印镜像清单: + +```bash +crictl images nginx +``` +```none +IMAGE TAG IMAGE ID SIZE +nginx latest cd5239a0906a6 109MB +``` + + + +只打印镜像 ID: + +```bash +crictl images -q +``` +```none +sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a +sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 +sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e +sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 +``` + + + +### 打印容器清单 + +打印所有容器清单: + +```bash +crictl ps -a +``` +```none +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 +9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0 +``` + + + +打印正在运行的容器清单: + +```bash +crictl ps +``` +```none +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0 +``` + + + +### 在正在运行的容器上执行命令 + +```bash +crictl exec -i -t 1f73f2d81bf98 ls +``` +```none +bin dev etc home proc root sys tmp usr var +``` + + + +### 获取容器日志 + +获取容器的所有日志: + +```bash +crictl logs 87d3992f84f74 +``` +```none +10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + + + +获取最近的 `N` 行日志: + +```bash +crictl logs --tail=1 87d3992f84f74 +``` +```none +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + + + +### 运行 Pod 沙盒 + +用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。 +在运行的 Kubernetes 集群中,沙盒会随机地被 kubelet 停止和删除。 + +1. + 编写下面的 JSON 文件: + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "logDirectory": "/tmp", + "linux": { + } + } + ``` + +2. + 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。 + + ```bash + crictl runp pod-config.json + ``` + + + 返回了沙盒的 ID。 + + + +### 创建容器 + +用 `crictl` 创建容器对容器运行时排错很有帮助。 +在运行的 Kubernetes 集群中,沙盒会随机的被 kubelet 停止和删除。 + + +1. + 拉取 busybox 镜像 + + ```bash + crictl pull busybox + Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 + ``` + +2. + 创建 Pod 和容器的配置: + + + **Pod 配置**: + ```yaml + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + + + **容器配置**: + ```yaml + { + "metadata": { + "name": "busybox" + }, + "image":{ + "image": "busybox" + }, + "command": [ + "top" + ], + "log_path":"busybox/0.log", + "linux": { + } + } + ``` + +3. + 创建容器,传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。 + + ```bash + crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json + ``` + +4. + 查询所有容器并确认新创建的容器状态为 `Created`。 + + ```bash + crictl ps -a + ``` + ```none + CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT + 3e025dd50a72d busybox 32 seconds ago Created busybox 0 + ``` + + + +### 启动容器 + +要启动容器,要将容器 ID 传给 `crictl start`: + +```bash +crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` +```none +3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + + + +确认容器的状态为 `Running`。 + +```bash +crictl ps +``` +```none +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + +{{% /capture %}} + + +{{% capture discussion %}} + + + +更多信息请参考 [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md new file mode 100644 index 0000000000..95d1abc891 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -0,0 +1,224 @@ +--- +reviewers: +- bprashanth +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +- smarterclayton +title: 调试 Init 容器 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +此页显示如何核查与 init 容器执行相关的问题。 +下面的示例命令行将 Pod 称为 ``,而 init 容器称为 `` 和 ``。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +* 您应该熟悉 [Init 容器](/docs/concepts/abstractions/init-containers/)的基础知识。 +* 您应该已经[配置好一个 Init 容器](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 检查 Init 容器的状态 + +显示你的 Pod 的状态: + +```shell +kubectl get pod +``` + + + +例如,状态 `Init:1/2` 表明两个 Init 容器中的一个已经成功完成: + +``` +NAME READY STATUS RESTARTS AGE + 0/1 Init:1/2 0 7s +``` + + + +更多状态值及其含义请参考[了解 Pod 的状态](#understanding-pod-status)。 + + + +## 获取 Init 容器详情 + + + +查看 Init 容器运行的更多详情: + +```shell +kubectl describe pod +``` + + + +例如,对于包含两个 Init 容器的 Pod 应该显示如下信息: + +``` +Init Containers: + : + Container ID: ... + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: ... + Finished: ... + Ready: True + Restart Count: 0 + ... + : + Container ID: ... + ... + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 + Started: ... + Finished: ... + Ready: False + Restart Count: 3 + ... +``` + + + +您还可以通过读取 Pod Spec 上的 `status.initContainerStatuses` 字段以编程方式了解 Init 容器的状态: + +```shell +kubectl get pod nginx --template '{{.status.initContainerStatuses}}' +``` + + + +此命令将返回与原始 JSON 中相同的信息. + + + +## 通过 Init 容器访问日志 + + + +一起传递 Init 容器名称与 Pod 名称来访问它的日志。 + +```shell +kubectl logs -c +``` + + + +运行 shell 脚本打印命令的init容器,执行 shell 脚本。 +例如,您可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。 + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 了解 Pod 的状态 + + + +以 `Init:` 开头的 Pod 状态汇总了 Init 容器执行的状态。 +下表介绍调试 Init 容器时可能看到的一些状态值示例。 + + + +状态 | 含义 +------ | ------- +`Init:N/M` | Pod 包含 `M` 个 Init 容器,其中 `N` 个已经运行完成。 +`Init:Error` | Init 容器已执行失败。 +`Init:CrashLoopBackOff` | Init 容器反复执行失败。 +`Pending` | Pod 还没有开始执行 Init 容器。 +`PodInitializing` or `Running` | Pod 已经完成执行 Init 容器。 + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-service.md b/content/zh/docs/tasks/debug-application-cluster/debug-service.md new file mode 100644 index 0000000000..999f10d6e8 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/debug-service.md @@ -0,0 +1,1181 @@ +--- +reviewers: +- thockin +- bowei +content_template: templates/concept +title: 调试 Service +--- + + + +{{% capture overview %}} + +对于新安装的 Kubernetes,经常出现的一个问题是 `Service` 没有正常工作。如果您已经运行了 `Deployment` 并创建了一个 `Service`,但是当您尝试访问它时没有得到响应,希望这份文档能帮助您找出问题所在。 + +{{% /capture %}} + + +{{% capture body %}} + + +## 约定 + +在整个文档中,您将看到各种可以运行的命令。有些命令需要在 `Pod` 中运行,有些命令需要在 Kubernetes `Node` 上运行,还有一些命令可以在您拥有 `kubectl` 和集群凭证的任何地方运行。为了明确预期的效果,本文档将使用以下约定。 + +如果命令 "COMMAND" 期望在 `Pod` 中运行,并且产生 "OUTPUT": + +```shell +u@pod$ COMMAND +OUTPUT +``` + +如果命令 "COMMAND" 期望在 `Node` 上运行,并且产生 "OUTPUT": + +```shell +u@node$ COMMAND +OUTPUT +``` + +如果命令是 "kubectl ARGS": + +```shell +$ kubectl ARGS +OUTPUT +``` + + +## 在 pod 中运行命令 + +对于这里的许多步骤,您可能希望知道运行在集群中的 `Pod` 看起来是什么样的。最简单的方法是运行一个交互式的 busybox `Pod`: + + +```none +$ kubectl run -it --rm --restart=Never busybox --image=busybox sh +如果你没有看到命令提示符,请尝试按 Enter 键。 +/ # +``` + +如果您已经有了您喜欢使用的正在运行的 `Pod`,则可以运行一下命令去使用: + +```shell +$ kubectl exec -c -- +``` + + +## 设置 + +为了完成本次演练的目的,我们先运行几个 `Pod`。因为可能正在调试您自己的 `Service`,所以,您可以使用自己的详细信息进行替换,或者,您也可以跟随并开始下面的步骤来获得第二个数据点。 + +```shell +$ kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ + --labels=app=hostnames \ + --port=9376 \ + --replicas=3 +deployment.apps/hostnames created +``` + +`kubectl` 命令将打印创建或变更的资源的类型和名称,它们可以在后续命令中使用。 +{{< note >}} +这与您使用以下 YAML 启动 `Deployment` 相同: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: hostnames +spec: + selector: + matchLabels: + app: hostnames + replicas: 3 + template: + metadata: + labels: + app: hostnames + spec: + containers: + - name: hostnames + image: k8s.gcr.io/serve_hostname + ports: + - containerPort: 9376 + protocol: TCP +``` +{{< /note >}} + +确认您的 `Pods` 是运行状态: + +```shell +$ kubectl get pods -l app=hostnames +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 2m +hostnames-632524106-ly40y 1/1 Running 0 2m +hostnames-632524106-tlaok 1/1 Running 0 2m +``` + + +## Service 存在吗? + +细心的读者会注意到我们还没有真正创建一个 `Service` - 其实这是我们有意的。这是一个有时会被遗忘的步骤,也是第一件要检查的事情。 + +那么,如果我试图访问一个不存在的 `Service`,会发生什么呢?假设您有另一个 `Pod`,想通过名称使用这个 `Service`,您将得到如下内容: + +```shell +u@pod$ wget -O- hostnames +Resolving hostnames (hostnames)... failed: Name or service not known. +wget: unable to resolve host address 'hostnames' +``` + +因此,首先要检查的是 `Service` 是否确实存在: + +```shell +$ kubectl get svc hostnames +No resources found. +Error from server (NotFound): services "hostnames" not found +``` + +我们已经有一个罪魁祸首了,让我们来创建 `Service`。就像前面一样,这里的内容仅仅是为了步骤的执行 - 在这里您可以使用自己的 `Service` 细节。 + +```shell +$ kubectl expose deployment hostnames --port=80 --target-port=9376 +service/hostnames exposed +``` + +再查询一遍,确定一下: + +```shell +$ kubectl get svc hostnames +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +hostnames ClusterIP 10.0.1.175 80/TCP 5s +``` + +与前面相同,这与您使用 YAML 启动的 `Service` 一样: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: hostnames +spec: + selector: + app: hostnames + ports: + - name: default + protocol: TCP + port: 80 + targetPort: 9376 +``` + +现在您可以确认 `Service` 存在。 + + +## Service 是否通过 DNS 工作? + +从相同 `Namespace` 下的 `Pod` 中运行: + +```shell +u@pod$ nslookup hostnames +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +如果失败,那么您的 `Pod` 和 `Service` 可能位于不同的 `Namespace` 中,请尝试使用限定命名空间的名称: + +```shell +u@pod$ nslookup hostnames.default +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +如果成功,那么需要调整您的应用,使用跨命名空间的名称去访问服务,或者,在相同的 `Namespace` 中运行应用和 `Service`。如果仍然失败,请尝试一个完全限定的名称: + +```shell +u@pod$ nslookup hostnames.default.svc.cluster.local +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default.svc.cluster.local +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +注意这里的后缀:"default.svc.cluster.local"。"default" 是我们正在操作的 `Namespace`。"svc" 表示这是一个 `Service`。"cluster.local" 是您的集群域,在您自己的集群中可能会有所不同。 + +您也可以在集群中的 Node 上尝试此操作: + +{{< note >}} +10.0.0.10 是我的 DNS `Service`,您的可能不同). +{{< /note >}} + +```shell +u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10 +Server: 10.0.0.10 +Address: 10.0.0.10#53 + +Name: hostnames.default.svc.cluster.local +Address: 10.0.1.175 +``` + +如果您能够使用完全限定的名称查找,但不能使用相对名称,则需要检查 `/etc/resolv.conf` 文件是否正确。 + +```shell +u@pod$ cat /etc/resolv.conf +nameserver 10.0.0.10 +search default.svc.cluster.local svc.cluster.local cluster.local example.com +options ndots:5 +``` + +`nameserver` 行必须指示您的集群的 DNS `Service`,它通过 `--cluster-dns` 标志传递到 `kubelet`。 + +`search` 行必须包含一个适当的后缀,以便查找 `Service` 名称。在本例中,它在本地 `Namespace`(`default.svc.cluster.local`)、所有 `Namespace` 中的 `Service`(`svc.cluster.local`)以及集群(`cluster.local`)中查找服务。 根据您自己的安装情况,可能会有额外的记录(最多 6 条)。集群后缀通过 `--cluster-domain` 标志传递给 `kubelet`。 本文档中,我们假定它是 “cluster.local”,但是您的可能不同,这种情况下,您应该在上面的所有命令中更改它。 + +`options` 行必须设置足够高的 `ndots`,以便 DNS 客户端库考虑搜索路径。在默认情况下,Kubernetes 将这个值设置为 5,这个值足够高,足以覆盖它生成的所有 DNS 名称。 + + +### DNS 中是否存在任何服务? + +如果上面仍然失败 - DNS 查找不到您需要的 `Service` - 我们可以后退一步,看看还有什么不起作用。Kubernetes 主 `Service` 应该一直是工作的: + +```shell +u@pod$ nslookup kubernetes.default +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: kubernetes.default +Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local +``` + +如果失败,您可能需要转到这个文档的 kube-proxy 部分,或者甚至回到文档的顶部重新开始,但不是调试您自己的 `Service`,而是调试 DNS。 + +### Service 能够通过 IP 访问么? + +假设我们可以确认 DNS 工作正常,那么接下来要测试的是您的 `Service` 是否工作正常。从集群中的一个节点,访问 `Service` 的 IP(从上面的 `kubectl get` 命令获取)。 + +```shell +u@node$ curl 10.0.1.175:80 +hostnames-0uton + +u@node$ curl 10.0.1.175:80 +hostnames-yp2kp + +u@node$ curl 10.0.1.175:80 +hostnames-bvc05 +``` + +如果 `Service` 是正常的,您应该得到正确的响应。如果没有,有很多可能出错的地方,请继续。 + + +## Service 是对的吗? + +这听起来可能很愚蠢,但您应该加倍甚至三倍检查您的 `Service` 是否正确,并且与您的 `Pod` 匹配。查看您的 `Service` 并验证它: + +```shell +$ kubectl get service hostnames -o json +``` +```json +{ + "kind": "Service", + "apiVersion": "v1", + "metadata": { + "name": "hostnames", + "namespace": "default", + "selfLink": "/api/v1/namespaces/default/services/hostnames", + "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc", + "resourceVersion": "347189", + "creationTimestamp": "2015-07-07T15:24:29Z", + "labels": { + "app": "hostnames" + } + }, + "spec": { + "ports": [ + { + "name": "default", + "protocol": "TCP", + "port": 80, + "targetPort": 9376, + "nodePort": 0 + } + ], + "selector": { + "app": "hostnames" + }, + "clusterIP": "10.0.1.175", + "type": "ClusterIP", + "sessionAffinity": "None" + }, + "status": { + "loadBalancer": {} + } +} +``` + +`spec.ports[]` 中描述的是您想要尝试访问的端口吗?`targetPort` 对您的 `Pod` 来说正确吗(许多 `Pod` 选择使用与 `Service` 不同的端口)?如果您想把它变成一个数字端口,那么它是一个数字(9376)还是字符串 “9376”?如果您想把它当作一个指定的端口,那么您的 `Pod` 是否公开了一个同名端口?端口的 `protocol` 和 `Pod` 的一样吗? + + +## Service 有端点吗? + +如果您已经走到了这一步,我们假设您已经确认您的 `Service` 存在,并能通过 DNS 解析。现在,让我们检查一下,您运行的 `Pod` 确实是由 `Service` 选择的。 + +早些时候,我们已经看到 `Pod` 是运行状态。我们可以再检查一下: + +```shell +$ kubectl get pods -l app=hostnames +NAME READY STATUS RESTARTS AGE +hostnames-0uton 1/1 Running 0 1h +hostnames-bvc05 1/1 Running 0 1h +hostnames-yp2kp 1/1 Running 0 1h +``` + +"AGE" 列表明这些 `Pod` 已经启动一个小时了,这意味着它们运行良好,而不是崩溃。 + +`-l app=hostnames` 参数是一个标签选择器 - 就像我们的 `Service` 一样。在 Kubernetes 系统中有一个控制循环,它评估每个 `Service` 的选择器,并将结果保存到 `Endpoints` 对象中。 + +```shell +$ kubectl get endpoints hostnames +NAME ENDPOINTS +hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 +``` + +这证实 endpoints 控制器已经为您的 `Service` 找到了正确的 `Pods`。如果 `hostnames` 行为空,则应检查 `Service` 的 `spec.selector` 字段,以及您实际想选择的 `Pods` 的 `metadata.labels` 的值。常见的错误是输入错误或其他错误,例如 `Service` 想选择 `run=hostnames`,但是 `Deployment` 指定的是 `app=hostnames`。 + + +## Pod 正常工作吗? + +到了这步,我们知道您的 `Service` 存在并选择了您的 `Pods`。让我们检查一下 `Pod` 是否真的在工作 - 我们可以绕过 `Service` 机制,直接进入 `Pod`。 + +{{< note >}} +这些命令使用的是 `Pod` 端口(9376),而不是 `Service` 端口(80)。 +{{< /note >}} + +```shell +u@pod$ wget -qO- 10.244.0.5:9376 +hostnames-0uton + +pod $ wget -qO- 10.244.0.6:9376 +hostnames-bvc05 + +u@pod$ wget -qO- 10.244.0.7:9376 +hostnames-yp2kp +``` + +我们期望的是 `Endpoints` 列表中的每个 `Pod` 返回自己的主机名。如果这没有发生(或者您自己的 `Pod` 的正确行为没有发生),您应该调查发生了什么。您会发现 `kubectl logs` 这个时候非常有用,或者使用 `kubectl exec` 直接进入到您的 `Pod`,并从那里检查服务。 + +另一件要检查的事情是,您的 Pod 没有崩溃或正在重新启动。频繁的重新启动可能会导致断断续续的连接问题。 + +```shell +$ kubectl get pods -l app=hostnames +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 2m +hostnames-632524106-ly40y 1/1 Running 0 2m +hostnames-632524106-tlaok 1/1 Running 0 2m +``` + +如果重新启动计数很高,请查阅有关如何[调试 pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods) 获取更多信息。 + + +## kube-proxy 正常工作吗? + +如果您到了这里,那么您的 `Service` 正在运行,也有 `Endpoints`,而您的 `Pod` 实际上也正在服务。在这一点上,整个 `Service` 代理机制是否正常就是可疑的了。我们来确认一下,一部分一部分来。 + + +### kube-proxy 在运行吗? + +确认 `kube-proxy` 正在您的 `Nodes` 上运行。您应该得到如下内容: + +```shell +u@node$ ps auxw | grep kube-proxy +root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 +``` + +下一步,确认它并没有出现明显的失败,比如连接主节点失败。要做到这一点,您必须查看日志。访问日志取决于您的 `Node` 操作系统。在某些操作系统是一个文件,如 /var/log/messages kube-proxy.log,而其他操作系统使用 `journalctl` 访问日志。您应该看到类似的东西: + +```none +I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" +I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier. +I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable. +I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53] +I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53] +I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443] +I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master +I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP +I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP +I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP +``` + +如果您看到有关无法连接主节点的错误消息,则应再次检查节点配置和安装步骤。 + +`kube-proxy` 无法正确运行的可能原因之一是找不到所需的 `conntrack` 二进制文件。在一些 Linux 系统上,这也是可能发生的,这取决于您如何安装集群,例如,您正在从头开始安装 Kubernetes。如果是这样的话,您需要手动安装 `conntrack` 包(例如,在 Ubuntu 上使用 `sudo apt install conntrack`),然后重试。 + + +### kube-proxy 是否在写 iptables 规则? + +`kube-proxy` 的主要职责之一是写实现 `Services` 的 `iptables` 规则。让我们检查一下这些规则是否已经被写好了。 + +kube-proxy 可以在 "userspace" 模式、 "iptables" 模式或者 "ipvs" 模式下运行。 +希望您正在使用 "iptables" 模式或者 "ipvs" 模式。您应该看到以下情况之一。 + +#### Userpace + +```shell +u@node$ iptables-save | grep hostnames +-A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577 +-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 +``` + +您的 `Service` 上的每个端口应该有两个规则(本例中只有一个)- "KUBE-PORTALS-CONTAINER" 和 "KUBE-PORTALS-HOST"。如果您没有看到这些,请尝试将 `-V` 标志设置为 4 之后重新启动 `kube-proxy`,然后再次查看日志。 + +几乎没有人应该再使用 "userspace" 模式了,所以我们不会在这里花费更多的时间。 + + +#### Iptables + +```shell +u@node$ iptables-save | grep hostnames +-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 +-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 +-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR +``` + +`KUBE-SERVICES` 中应该有 1 条规则,`KUBE-SVC-(hash)` 中每个端点有 1 或 2 条规则(取决于 `SessionAffinity`),每个端点中应有 1 条 `KUBE-SEP-(hash)` 链。准确的规则将根据您的确切配置(包括节点、端口组合以及负载均衡器设置)而有所不同。 + + +#### IPVS + +```shell +u@node$ ipvsadm -ln +Prot LocalAddress:Port Scheduler Flags + -> RemoteAddress:Port Forward Weight ActiveConn InActConn +... +TCP 10.0.1.175:80 rr + -> 10.244.0.5:9376 Masq 1 0 0 + -> 10.244.0.6:9376 Masq 1 0 0 + -> 10.244.0.7:9376 Masq 1 0 0 +... +``` + +IPVS 代理将为每个服务器地址(例如集群 IP、外部 IP、节点端口 IP、负载均衡 IP等)创建虚拟服务器,并为服务的端点创建一些相应的真实服务器(如果有)。在这个例子中,服务器主机名(`10.0.1.175:80`)有 3 个端点(`10.244.0.5:9376`, `10.244.0.6:9376`, `10.244.0.7:9376`),你会得到类似上面的结果。 + + + +### kube-proxy 在执行代理操作么? + +假设您确实看到了上述规则,请再次尝试通过 IP 访问您的 `Service`: + +```shell +u@node$ curl 10.0.1.175:80 +hostnames-0uton +``` + +如果失败了,并且您正在使用 userspace 代理,您可以尝试直接访问代理。如果您使用的是 iptables 代理,请跳过本节。 + +回顾上面的 `iptables-save` 输出,并提取 `kube-proxy` 用于您的 `Service` 的端口号。在上面的例子中,它是 “48577”。现在连接到它: + +```shell +u@node$ curl localhost:48577 +hostnames-yp2kp +``` + +如果仍然失败,请查看 `kube-proxy` 日志中的特定行,如: + +```shell +Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] +``` + +如果您没有看到这些,请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`,然后再查看日志。 + + +### Pod 无法通过 Service IP 访问自己 + +如果网络没有为“发夹模式”流量生成正确配置,通常当 `kube-proxy` 以 `iptables` 模式运行,并且 Pod 与桥接网络连接时,就会发生这种情况。`Kubelet` 公开了一个 `hairpin-mode` 标志,如果 pod 试图访问它们自己的 Service VIP,就可以让 Service 的端点重新负载到他们自己身上。`hairpin-mode` 标志必须设置为 `hairpin-veth` 或者 `promiscuous-bridge`。 + +解决这一问题的常见步骤如下: + +* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。您应该看到下面这样的内容。在下面的示例中,`hairpin-mode` 被设置为 `promiscuous-bridge`。 + +```shell +u@node$ ps auxw|grep kubelet +root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 + +``` + +* 确认有效的 `hairpin-mode`。要做到这一点,您必须查看 kubelet 日志。访问日志取决于节点的操作系统。在一些操作系统上,它是一个文件,如 /var/log/kubelet.log,而其他操作系统则使用 `journalctl` 访问日志。请注意,由于兼容性,有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log 中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的 `hairpin-mode`,比如下面的内容。 +```shell +I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" +``` + +* 如果有效的发夹模式是 `hairpin-veth`,请确保 `Kubelet` 具有在节点上的 `/sys` 中操作的权限。如果一切正常工作,您应该看到如下内容: + +```shell +for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done +1 +1 +1 +1 +``` + +* 如果有效的发夹模式是 `promiscuous-bridge`,则请确保 `Kubelet` 拥有在节点上操纵 Linux 网桥的权限。如果正确使用和配置了 cbr0 网桥,您应该看到: + +```shell +u@node$ ifconfig cbr0 |grep PROMISC +UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 + +``` + +* 如果上述任何一项都没有效果,请寻求帮助。 + + +## 寻求帮助 + +如果您走到这一步,那么就真的是奇怪的事情发生了。您的 `Service` 正在运行,有 `Endpoints`,您的 `Pods` 也确实在服务中。您的 DNS 正常,`iptables` 规则已经安装,`kube-proxy` 看起来也正常。然而 `Service` 不起作用。这种情况下,您应该让我们知道,这样我们可以帮助调查! + +使用 [Slack](/docs/troubleshooting/#slack) 或者 [Forum](https://discuss.kubernetes.io) 或者 [GitHub](https://github.com/kubernetes/kubernetes) 联系我们。 + + +{{% /capture %}} + +{{% capture whatsnext %}} + + +访问[故障排查文档](/docs/troubleshooting/)获取更多信息。 + +{{% /capture %}} + diff --git a/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md new file mode 100644 index 0000000000..8e1b947be6 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -0,0 +1,172 @@ +--- +title: 确定 Pod 失败的原因 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本文介绍如何编写和读取容器的终止消息。 + + + +终止消息为容器提供了一种方法,可以将有关致命事件的信息写入某个位置,在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。 +在大多数情况下,您放入终止消息中的信息也应该写入[常规 Kubernetes 日志](/docs/concepts/cluster-administration/logging/)。 + + + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 读写终止消息 + +在本练习中,您将创建运行一个容器的 Pod。 +配置文件指定在容器启动时要运行的命令。 + +{{< codenew file="debug/termination.yaml" >}} + +1. 基于 YAML 配置文件创建 Pod: + + kubectl create -f https://k8s.io/examples/debug/termination.yaml + + + YAML 文件中,在 `cmd` 和 `args` 字段,你可以看到容器休眠 10 秒然后将 "Sleep expired" 写入 `/dev/termination-log` 文件。 + 容器写完 "Sleep expired" 消息后,它就终止了。 + +1. 显示 Pod 的信息: + + kubectl get pod termination-demo + + + 重复前面的命令直到 Pod 不再运行。 + +1. 显示 Pod 的详细信息: + + kubectl get pod --output=yaml + + 输出结果包含 "Sleep expired" 消息: + + apiVersion: v1 + kind: Pod + ... + lastState: + terminated: + containerID: ... + exitCode: 0 + finishedAt: ... + message: | + Sleep expired + ... + +1. 使用 Go 模板过滤输出结果,使其只含有终止消息: + + kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" + + + +## 定制终止消息 + + + +Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息,默认值为 `/dev/termination-log`。 +通过定制这个字段,您可以告诉 Kubernetes 使用不同的文件。 +Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状态消息。 + + + +在下例中,容器将终止消息写入 `/tmp/my-log` 给 Kubernetes 来接收: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: msg-path-demo +spec: + containers: + - name: msg-path-demo-container + image: debian + terminationMessagePath: "/tmp/my-log" +``` + + + +此外,用户可以设置容器的 `terminationMessagePolicy` 字段,以便进一步自定义。 +此字段默认为 "`File`",这意味着仅从终止消息文件中检索终止消息。 +通过将 `terminationMessagePolicy` 设置为 "`FallbackToLogsOnError`",你就可以告诉 Kubernetes,在容器因错误退出时,如果终止消息文件为空,则使用容器日志输出的最后一块作为终止消息。 +日志输出限制为 2048 字节或 80 行,以较小者为准。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 参考[容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)的 `terminationMessagePath` 字段。 +* 了解[接收日志](/docs/concepts/cluster-administration/logging/)。 +* 了解 [Go 模版](https://golang.org/pkg/text/template/)。 + +{{% /capture %}} + + + diff --git a/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md b/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md new file mode 100644 index 0000000000..0dbda745d5 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md @@ -0,0 +1,167 @@ +--- +reviewers: +- piosz +- x13n +content_template: templates/concept +title: StackDriver 中的事件 +--- + + + +{{% capture overview %}} + + + +Kubernetes 事件是一种对象,它为用户提供了洞察集群内发生的事情的能力,例如调度程序做出了什么决定,或者为什么某些 Pod 被逐出节点。 +您可以在[应用程序自检和调试](/docs/tasks/debug-application-cluster/debug-application-introspection/)中阅读有关使用事件调试应用程序的更多信息。 + + + +由于事件是 API 对象,因此它们存储在主节点上的 apiserver 中。 +为了避免主节点磁盘空间被填满,将强制执行保留策略:在最后一次事件发生一小时后删除事件。 +为了提供更长的历史记录和聚合能力,应该安装第三方解决方案来捕获事件。 + + + +本文描述了一个将 Kubernetes 事件导出为 Stackdriver Logging 的解决方案,在这里可以对它们进行处理和分析。 + +{{< note >}} + +不能保证集群中发生的所有事件都将导出到 Stackdriver。 +事件不能导出的一种可能情况是事件导出器没有运行(例如,在重新启动或升级期间)。 +在大多数情况下,可以将事件用于设置 [metrics][sdLogMetrics] 和 [alerts][sdAlerts] 等目的,但您应该注意潜在的不准确性。 +{{< /note >}} + +[sdLogMetrics]: https://cloud.google.com/logging/docs/view/logs_based_metrics +[sdAlerts]: https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy + +{{% /capture %}} + + +{{% capture body %}} + + + +## 部署 + +### Google Kubernetes Engine + + + +在 Google Kubernetes Engine 中,如果启用了云日志,那么事件导出器默认部署在主节点运行版本为 1.7 及更高版本的集群中。 +为了防止干扰您的工作负载,事件导出器没有设置资源,并且处于尽力而为的 QoS 类型中,这意味着它将在资源匮乏的情况下第一个被杀死。 +如果要导出事件,请确保有足够的资源给事件导出器 Pod 使用。 +这可能会因为工作负载的不同而有所不同,但平均而言,需要大约 100MB 的内存和 100m 的 CPU。 + + + +### 部署到现有集群 + + + +使用下面的命令将事件导出器部署到您的集群: + +```shell +kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml +``` + + + +由于事件导出器访问 Kubernetes API,因此它需要权限才能访问。 +以下的部署配置为使用 RBAC 授权。 +它设置服务帐户和集群角色绑定,以允许事件导出器读取事件。 +为了确保事件导出器 Pod 不会从节点中退出,您可以另外设置资源请求。 +如前所述,100MB 内存和 100m CPU 应该就足够了。 + +{{< codenew file="debug/event-exporter.yaml" >}} + + + +## 用户指南 + + + +事件在 Stackdriver Logging 中被导出到 `GKE Cluster` 资源。 +您可以通过从可用资源的下拉菜单中选择适当的选项来找到它们: + +Events location in the Stackdriver Logging interface + + + +您可以使用 Stackdriver Logging 的[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)基于事件对象字段进行过滤。 +例如,下面的查询将显示调度程序中有关 Deployment `nginx-deployment` 中的 Pod 的事件: + +``` +resource.type="gke_cluster" +jsonPayload.kind="Event" +jsonPayload.source.component="default-scheduler" +jsonPayload.involvedObject.name:"nginx-deployment" +``` + +{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}} + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md new file mode 100644 index 0000000000..15d5331f3d --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -0,0 +1,241 @@ +--- +reviewers: +- caesarxuchao +- mikedanese +title: 获取正在运行容器的 Shell +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +本文介绍怎样使用 `kubectl exec` 命令获取正在运行容器的 Shell。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 获取容器的 Shell + + + +在本练习中,你将创建包含一个容器的 Pod。容器运行 nginx 镜像。下面是 Pod 的配置文件: + +{{< codenew file="application/shell-demo.yaml" >}} + + + +创建 Pod: + +```shell +kubectl create -f https://k8s.io/examples/application/shell-demo.yaml +``` + + + +检查容器是否运行正常: + +```shell +kubectl get pod shell-demo +``` + + + +获取正在运行容器的 Shell: + +```shell +kubectl exec -it shell-demo -- /bin/bash +``` +{{< note >}} + + +双破折号 "--" 用于将要传递给命令的参数与 kubectl 的参数分开。 +note >}} + + + +在 shell 中,打印根目录: + +```shell +root@shell-demo:/# ls / +``` + + + +在 shell 中,实验其他命令。下面是一些示例: + +```shell +root@shell-demo:/# ls / +root@shell-demo:/# cat /proc/mounts +root@shell-demo:/# cat /proc/1/maps +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install -y tcpdump +root@shell-demo:/# tcpdump +root@shell-demo:/# apt-get install -y lsof +root@shell-demo:/# lsof +root@shell-demo:/# apt-get install -y procps +root@shell-demo:/# ps aux +root@shell-demo:/# ps aux | grep nginx +``` + + + +## 编写 nginx 的 根页面 + + + +在看一下 Pod 的配置文件。该 Pod 有个 `emptyDir` 卷,容器将该卷挂载到了 `/usr/share/nginx/html`。 + + + +在 shell 中,在 `/usr/share/nginx/html` 目录创建一个 `index.html 文件: + +```shell +root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +``` + + + +在 shell 中,向 nginx 服务器发送 GET 请求: + +```shell +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install curl +root@shell-demo:/# curl localhost +``` + + + +输出结果显示了你在 `index.html` 中写入的文本。 + +```shell +Hello shell demo +``` + + + +当用完 shell 后,输入 `exit` 退出。 + + + +## 在容器中运行单个命令 + + + +在普通的命令窗口(而不是 shell)中,打印环境运行容器中的变量: + +```shell +kubectl exec shell-demo env +``` + + + +实验运行其他命令。下面是一些示例: + +```shell +kubectl exec shell-demo ps aux +kubectl exec shell-demo ls / +kubectl exec shell-demo cat /proc/1/mounts +``` + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 当 Pod 包含多个容器时打开 shell + + + +如果 Pod 有多个容器,`--container` 或者 `-c` 可以在 `kubectl exec` 命令中指定容器。 +例如,您有个名为 my-pod 的容器,该 Pod 有两个容器分别为 main-app 和 healper-app。 +下面的命令将会打开一个 shell 访问 main-app 容器。 + +```shell +kubectl exec -it my-pod --container main-app -- /bin/bash +``` + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) + +{{% /capture %}} + + + diff --git a/content/zh/docs/tasks/debug-application-cluster/local-debugging.md b/content/zh/docs/tasks/debug-application-cluster/local-debugging.md new file mode 100644 index 0000000000..cdcb6bbd1a --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/local-debugging.md @@ -0,0 +1,126 @@ +--- +title: 在本地开发和调试服务 +content_template: templates/task +--- + + + +{{% capture overview %}} + + + +Kubernetes 应用程序通常由多个独立的服务组成,每个服务都在自己的容器中运行。 +在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦,需要[在运行的容器上打开 shell](/docs/tasks/debug-application-cluster/get-shell-running-container/),然后在远端 shell 中运行您所需的工具。 + + + +`telepresence` 是一种工具,用于在本地轻松开发和调试服务,同时将服务代理到远程 Kubernetes 集群。 +使用 `telepresence` 可以为本地服务使用自定义工具(如调试器和 IDE),并提供对 Configmap、Secrets 和远程集群上运行的服务的完全访问。 + + + +* Kubernetes 集群安装完毕 +* 配置好 `kubectl` 与集群交互 +* [Telepresence](https://www.telepresence.io/reference/install) 安装完毕 + +{{% /capture %}} + +{{% capture steps %}} + + + +打开终端,不带参数运行 `telepresence`,以打开 `telepresence` shell。这个 shell 在本地运行,使您可以完全访问本地文件系统。 + + + +`telepresence` shell 的使用方式多种多样。 +例如,在你的笔记本电脑上写一个 shell 脚本,然后直接在 shell 中实时运行它。 +您也可以在远端 shell 上执行此操作,但这样可能无法使用首选的代码编辑器,并且在容器终止时脚本将被删除。 + + + +## 开发和调试现有的服务 + +在 Kubernetes 上开发应用程序时,通常对单个服务进行编程或调试。 +服务可能需要访问其他服务以进行测试和调试。 +一种选择是使用连续部署管道,但即使最快的部署管道也会在程序或调试周期中引入延迟。 + + + +使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。交换允许您在本地运行服务并能够连接到远端的 Kubernetes 集群。远端的集群中的服务现在就可以访问本地运行的实例。 + +到运行 telepresence 并带有 `--swap-deployment` 选项,请输入: + +`telepresence --swap-deployment $DEPLOYMENT_NAME` + + + +这里的 $DEPLOYMENT_NAME 是您现有的部署名称。 + +运行此命令将生成 shell。在 shell 中,启动您的服务。 +然后,您就可以在本地对源代码进行编辑、保存并能看到更改立即生效。您还可以在调试器或任何其他本地开发工具中运行服务。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +如果您对实践教程感兴趣,请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s),其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。 + + + +Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods),以满足您的各种情况。 + +要了解更多信息,请访问 [Telepresence 网站](https://www.telepresence.io)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md new file mode 100644 index 0000000000..d815f17ed9 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -0,0 +1,193 @@ +--- +reviewers: +- piosz +- x13n +content_template: templates/concept +title: 使用 ElasticSearch 和 Kibana 进行日志管理 +--- + + + +{{% capture overview %}} + + + +在 Google Compute Engine (GCE) 平台上,默认的日志管理支持目标是 [Stackdriver Logging](https://cloud.google.com/logging/),在 [使用 Stackdriver Logging 管理日志](/docs/user-guide/logging/stackdriver)中详细描述了这一点。 + + + +本文介绍了如何设置一个集群,将日志导入[Elasticsearch](https://www.elastic.co/products/elasticsearch),并使用 [Kibana](https://www.elastic.co/products/kibana) 查看日志,作为在 GCE 上运行应用时使用 Stackdriver Logging 管理日志的替代方案。 + +{{< note >}} + +您不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动的部署 Elasticsearch 和 Kibana。您必须手动部署它们。 +{{< /note >}} + +{{% /capture %}} + +{{% capture body %}} + + + +要使用 Elasticsearch 和 Kibana 处理集群日志,您应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量: + +```shell +KUBE_LOGGING_DESTINATION=elasticsearch +``` + + + +您还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` (这是 GCE 平台的默认设置)。 + + + +现在,当您创建集群时,将有一条消息将指示每个节点上运行的 Fluentd 日志收集守护进程以 ElasticSearch 为日志输出目标: + +```shell +$ cluster/kube-up.sh +... +Project: kubernetes-satnam +Zone: us-central1-b +... calling kube-up +Project: kubernetes-satnam +Zone: us-central1-b ++++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel ++++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d) ++++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0) +Looking for already existing resources +Starting master and configuring firewalls +Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd]. +NAME ZONE SIZE_GB TYPE STATUS +kubernetes-master-pd us-central1-b 20 pd-ssd READY +Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip]. ++++ Logging using Fluentd to elasticsearch +``` + + + +每个节点的 Fluentd pod、Elasticsearch pod 和 Kibana pod 都应该在集群启动后不久运行在 kube-system 命名空间中。 + +```shell +$ kubectl get pods --namespace=kube-system +NAME READY STATUS RESTARTS AGE +elasticsearch-logging-v1-78nog 1/1 Running 0 2h +elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h +fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h +kibana-logging-v1-bhpo8 1/1 Running 0 2h +kube-dns-v3-7r1l9 3/3 Running 0 2h +monitoring-heapster-v4-yl332 1/1 Running 1 2h +monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h +``` + + + +`fluentd-elasticsearch` pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` pods,该 pod 是名为 `elasticsearch-logging` 的[服务](/docs/concepts/services-networking/service/)的一部分。 +这些 ElasticSearch pod 存储日志,并通过 REST API 将其公开。 +`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI,它是名为 `kibana-logging` 的服务的一部分。 + + + +Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中,并且没有通过可公开访问的 IP 地址直接暴露。 +要访问它们,请参照[访问集群中运行的服务](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster)的说明进行操作。 + + + +如果你想在浏览器中访问 `elasticsearch-logging` 服务,你将看到类似下面的状态页面: + +![Elasticsearch Status](/images/docs/es-browser.png) + + + +现在你可以直接在浏览器中输入 Elasticsearch 查询,如果你愿意的话。 +请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。 + + + +或者,您可以使用 Kibana 查看集群的日志(再次使用[访问集群中运行的服务的说明](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster))。 +第一次访问 Kibana URL 时,将显示一个页面,要求您配置所接收日志的视图。 +选择时间序列值的选项,然后选择 `@timestamp`。 +在下面的页面中选择 `Discover` 选项卡,然后您应该能够看到所摄取的日志。 +您可以将刷新间隔设置为 5 秒,以便定期刷新日志。 + + + +以下是从 Kibana 查看器中摄取日志的典型视图: + +![Kibana logs](/images/docs/kibana-logs.png) + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +Kibana 为浏览您的日志提供了各种强大的选项!有关如何深入研究它的一些想法,请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md new file mode 100644 index 0000000000..f01fe70956 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -0,0 +1,315 @@ +--- +content_template: templates/task +title: 节点健康监测 +--- + + +{{% capture overview %}} + +*节点问题探测器* 是一个 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 用来监控节点健康。它从各种守护进程收集节点问题,并以[NodeCondition](/docs/concepts/architecture/nodes/#condition) 和 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) 的形式报告给 apiserver 。 + + + +它现在支持一些已知的内核问题检测,并将随着时间的推移,检测更多节点问题。 + + +目前,Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。将来可能会引入一个补救系统来处理这些节点问题。 + + +更多信息请参阅 [这里](https://github.com/kubernetes/node-problem-detector)。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + +## 局限性 + + +* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。 它不支持像 journald 这样的命令行日志工具。 + + +* 节点问题检测器的内核问题检测对内核日志格式有一定要求,现在它只适用于 Ubuntu 和 Debian。但是,将其扩展为 [支持其它日志格式](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format) 也很容易。 + + +## 在 GCE 集群中启用/禁用 + + +节点问题检测器在 gce 集群中以[集群插件的形式](/docs/setup/cluster-large/#addon-resources)默认启用。 + + +您可以在运行 `kube-up.sh` 之前,以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。 + + +## 在其它环境中使用 + + +要在 GCE 之外的其他环境中启用节点问题检测器,您可以使用 `kubectl` 或插件 pod。 + + +### Kubectl + + +这是在 GCE 之外启动节点问题检测器的推荐方法。它的管理更加灵活,例如覆盖默认配置以使其适合您的环境或检测自定义节点问题。 + + +* **步骤 1:** `node-problem-detector.yaml`: + +{{< codenew file="debug/node-problem-detector.yaml" >}} + + + +***请注意保证您的系统日志路径与您的 OS 发行版相对应。*** + + +* **步骤 2:** 执行 `kubectl` 来启动节点问题检测器: + +```shell + kubectl create -f https://k8s.io/examples/debug/node-problem-detector.yaml +``` + + +### 插件 Pod + + +这适用于拥有自己的集群引导程序解决方案的用户,并且不需要覆盖默认配置。 他们可以利用插件 Pod 进一步自动化部署。 + + +只需创建 `node-problem-detector.yaml`,并将其放在主节点上的插件 pod 目录 `/etc/kubernetes/addons/node-problem-detector` 下。 + + + +## 覆盖配置文件 + + +构建节点问题检测器的 docker 镜像时,会嵌入[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。 + + +不过,您可以像下面这样使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 将其覆盖: + + +* **步骤 1:** 在 `config/` 中更改配置文件。 +* **步骤 2:** 使用 `kubectl create configmap node-problem-detector-config --from-file=config/` 创建 `node-problem-detector-config` 。 +* **步骤 3:** 更改 `node-problem-detector.yaml` 以使用 ConfigMap: + +{{< codenew file="debug/node-problem-detector-configmap.yaml" >}} + + + +* **步骤 4:** 使用新的 yaml 文件重新创建节点问题检测器: + +```shell + kubectl delete -f https://k8s.io/examples/debug/node-problem-detector.yaml # If you have a node-problem-detector running + kubectl create -f https://k8s.io/examples/debug/node-problem-detector-configmap.yaml +``` + + +***请注意,此方法仅适用于通过 `kubectl` 启动的节点问题检测器。*** + + +由于插件管理器不支持ConfigMap,因此现在不支持对于作为集群插件运行的节点问题检测器的配置进行覆盖。 + + +## 内核监视器 + + +*内核监视器* 是节点问题检测器中的问题守护进程。它监视内核日志并按照预定义规则检测已知内核问题。 + + +内核监视器根据 [`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json) 中的一组预定义规则列表匹配内核问题。 +规则列表是可扩展的,您始终可以通过覆盖配置来扩展它。 + + +### 添加新的 NodeCondition + + +您可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。 + +```json +{ + "type": "NodeConditionType", + "reason": "CamelCaseDefaultNodeConditionReason", + "message": "arbitrary default node condition message" +} +``` + + +### 检测新的问题 + + +您可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。 + +```json +{ + "type": "temporary/permanent", + "condition": "NodeConditionOfPermanentIssue", + "reason": "CamelCaseShortReason", + "message": "regexp matching the issue in the kernel log" +} +``` + + +### 更改日志路径 + + +不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。您始终可以修改配置使其与您的 OS 发行版匹配。 + + +### 支持其它日志格式 + + +内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。我们可以很容易为新的日志格式实现新的翻译器。 +{{% /capture %}} + +{{% capture discussion %}} + + +## 注意事项 + + +我们建议在集群中运行节点问题检测器来监视节点运行状况。但是,您应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响,因为: + + +* 内核日志生成相对较慢。 +* 节点问题检测器有资源限制。 +* 即使在高负载下,资源使用也是可以接受的。 +(参阅 [基准测试结果](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629)) + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000..6e96cdc257 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -0,0 +1,217 @@ +--- +reviewers: +- mikedanese +content_template: templates/concept +title: 资源监控工具 +--- + + + +{{% capture overview %}} + + + +要扩展应用程序并提供可靠的服务,您需要了解应用程序部署时的行为。 +您可以通过检查容器、[pod](/docs/user-guide/pods)、[服务](/docs/user-guide/services) 和整个集群的特性来检查 Kubernetes 集群中的应用程序性能。 +Kubernetes 在每一个级别上提供了关于应用程序资源使用的详细信息。 +此信息允许您评估应用程序的性能,以及在何处可以消除瓶颈以提高整体性能。 + +{{% /capture %}} + +{{% capture body %}} + + + +在 Kubernetes 中,应用程序监控不依赖单个监控解决方案。 +默认情况下,新集群上可以使用两个单独的管道来收集监控统计信息: + + + +- [**资源度量管道**](#resource-metrics-pipeline)提供了一组与集群组件(如 HorizontalPodautoScaler 控制器)以及 `kubectl top` 实用程序相关的有限度量。 + 这些度量由[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集,并通过 `metrics.k8s.io` API 公开。 + `度量服务器`发现群集中的所有节点,并查询每个节点的 [Kubelet](/docs/admin/kubelet) 以获取 CPU 和内存使用情况。 + Kubelet 从 [cAdvisor](https://github.com/google/cadvisor) 获取数据。 + `度量服务器`是一个轻量级的短期内存存储。 + + + +- 一个[**完整度量管道**](#full-metrics-pipelines),如 Prometheus,可以让您访问更丰富的度量。 + 此外,Kubernetes 还可以根据集群的当前状态,使用 Pod 水平自动扩缩器等机制,通过自动调用扩展或调整集群来响应这些度量。 + 监控管道从 kubelet 获取度量,然后通过适配器将它们公开给 Kubernetes,方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。 + + + +## 资源度量管道 + + +### Kubelet + + + +Kubelet充当 Kubernetes 主节点和节点之间的桥梁。 +它管理机器上运行的 Pod 和容器。 +Kubelet 将每个 Pod 转换为它的组成容器,并从 cAdvisor 获取各个容器的使用统计信息。然后它通过一个 REST API 公开聚合的 Pod 资源使用统计信息。 + +### cAdvisor + + + +cAdvisor 是一个开源容器资源使用和性能分析代理。 +它是专门为容器构造的,并原生支持 Docker 容器。 +在 Kubernetes 中,cAdvisor 被集成到了 kubelet 二进制文件中。 +cAdvisor 自动发现机器中的所有容器,并收集 CPU、内存、文件系统和网络使用统计信息。 +cAdvisor 还通过分析机器上的 'root' 容器来提供机器的总体使用情况。 + + + +在大多数 Kubernetes 集群中,cAdvisor 在端口 4194 上为机上容器提供了一个简单的用户界面。以下是 cAdvisor 的部分用户界面的快照,其中显示了机器的总体使用情况: + +![cAdvisor](/images/docs/cadvisor.png) + + + +## 完整度量管道 + + + +现有许多用于 Kubernetes 的完整度量解决方案。 + +### Prometheus + + + +[Prometheus](https://prometheus.io) 可以原生监控 Kubernetes、节点和 Prometheus 自身。 +[Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/) 简化了 Kubernetes 上的 Prometheus 安装,并允许您使用 [Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter) 为自定义度量 API 提供支持。 +Prometheus 提供了一种强大的查询语言和一个内置的仪表板,用于查询和可视化您的数据。 +Prometheus 也是支持 [Grafana](https://prometheus.io/docs/visualization/grafana/) 的数据源。 + +### Google Cloud Monitoring + + + +Google Cloud Monitoring 是一个托管的监控服务,您可以使用它对应用程序中的重要指标进行可视化和警报。 +可以从 Kubernetes 收集度量,并且可以使用 [Cloud Monitoring Console](https://app.google.stackdriver.com/) 访问它们。 +您可以创建和自定义仪表板,从而可视化从您的 Kubernetes 集群中收集的数据。 + + + +下面的视频介绍了如何配置和运行 Google Cloud Monitoring 支持的 Heapster: + + +[![how to setup and run a Google Cloud Monitoring backed Heapster](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs) + + +{{< figure src="/images/docs/gcm.png" alt="Google Cloud Monitoring dashboard example" title="Google Cloud Monitoring dashboard example" caption="This dashboard shows cluster-wide resource usage." >}} + + + +## CronJob 监控 + +### Kubernetes Job Monitor + + + +使用 [Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) 仪表板,集群管理员可以看到哪些 job 在运行以及查看已完成 job 的状态。 + + + +### New Recil Kubernetes 监控集成 + + + +[New Relic Kubernetes](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)集成提高了对 Kubernetes 环境性能的可视性。 +New Relic 的 Kubernetes 集成通过报告来自 Kubernetes 对象的指标,为容器编排层提供参数。 +该集成让您可以深入了解 Kubernetes 节点、名称空间、部署、副本集、pod 和容器。 + + + +移动文字功能: +在预构建的仪表板中查看数据,以便立即了解 Kubernetes 环境信息。 +根据自动报告的数据创建自己的自定义查询和图表。 +对 Kubernetes 数据创建警告条件。 +进一步了解该功能请参考这个[页面](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)。 + + +{{% /capture %}} diff --git a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md new file mode 100644 index 0000000000..f2206d28d6 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md @@ -0,0 +1,220 @@ +--- +reviewers: +- brendandburns +- davidopp +content_template: templates/concept +title: 排错 +--- + + + +{{% capture overview %}} + + + +有时候事情会出错。本指南旨在正确解决这些问题。它包含两个部分: + + + + * [应用排错](/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。 + * [集群排错](/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。 + + + +您也应该查看所用[版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 获取帮助 + +如果您的问题在上述指南中没有得到答案,您还有另外几种方式从 Kubernetes 团队获得帮助。 + + + +### 提问 + +网站上的文档针对回答各类问题进行了结构化组织和分类。 +[概念](/docs/concepts/)部分解释了 Kubernetes 体系结构以及每个组件的工作方式,[安装](/docs/setup/)部分提供了入门的实用说明。 +[任务](/docs/tasks/)部分展示了如何完成常用任务,[入门](/docs/tutorials/)部分则是对现实世界、特定行业或端到端开发场景的更全面的演练。 +[参考](/docs/reference/)部分提供了详细的 [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档和命令行 (CLI) 接口,例如[`kubectl`](/docs/user-guide/kubectl-overview/)。 + + + +您还可以找到堆栈溢出相关的主题: + + * [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes) + * [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine) + + + +## 求救!我的问题还没有解决!我需要立即得到帮助! + + + +### 堆栈溢出 + + + +社区中的其他人可能已经问过和您类似的问题,这或许能帮助解决您的问题。 +Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](http://stackoverflow.com/questions/tagged/kubernetes)。 +如果现有的问题对您没有帮助,请[问一个新问题](http://stackoverflow.com/questions/ask?tags=kubernetes)! + + + +### Slack + +Kubernetes 团队在 Slack 中建有 `#kubernetes-users` 频道。 +您可以[在这里](https://kubernetes.slack.com)参加与 Kubernetes 团队的讨论。 +Slack 需要注册,但 Kubernetes 团队公开邀请任何人[在这里](http://slack.kubernetes.io)注册。 +欢迎您随时来问任何问题。 + + + +一旦注册完成,您就可以浏览各种感兴趣的频道列表。 +例如,Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。作为另一个例子,开发人员应该加入 `#kubernetes-dev` 频道。 + + + +还有许多国家/地区语言频道。请随时加入这些频道以获得本地化支持和信息: + + + +- 中国: `#cn-users`, `#cn-events` +- 法国: `#fr-users`, `#fr-events` +- 德国: `#de-users`, `#de-events` +- 印度: `#in-users`, `#in-events` +- 意大利: `#it-users`, `#it-events` +- 日本: `#jp-users`, `#jp-events` +- 韩国: `#kr-users` +- 荷兰: `#nl-users` +- 挪威: `#norw-users` +- 波兰: `#pl-users` +- 俄罗斯: `#ru-users` +- 西班牙: `#es-users` +- 土耳其: `#tr-users`, `#tr-events` + + + + +### 论坛 + +Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io) + + + + +如果你发现一个看起来像 bug 的东西,或者你想提出一个功能请求,请使用[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。 + + + + +在提交问题之前,请搜索现有问题以查看是否已涵盖您的问题。 + +如果提交 bug,请提供如何重现问题的详细信息,例如: + + + +* Kubernetes 版本:获取版本的命令为 `kubectl version` +* 云提供商,OS 发行版、网络配置和 Docker 版本 +* 重现问题的步骤 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/dns-horizontal-autoscaling.md b/content/zh/docs/tasks/dns-horizontal-autoscaling.md new file mode 100644 index 0000000000..336b24b7ff --- /dev/null +++ b/content/zh/docs/tasks/dns-horizontal-autoscaling.md @@ -0,0 +1,485 @@ +--- +title: 自动伸缩集群中的 DNS 服务 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +此页面展示如何启用和配置集群中 DNS 服务的自动伸缩。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* 确保 [DNS 特性](/docs/concepts/services-networking/dns-pod-service/)是启用的。 + +* 推荐使用 Kubernetes 1.4.0 或更高版本。 + +{{% /capture %}} + +{{% capture steps %}} + + +## 确定 DNS 水平自动伸缩是否已经启用 + + +列出集群中命名空间 kube-system 下的 Deployment: + + kubectl get deployment --namespace=kube-system + + +输出类似: + + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + ... + dns-autoscaler 1 1 1 1 ... + ... + + +如果在输出中看到 `dns-autoscaler`,则表示已启用 DNS 水平自动缩放, +可以跳过阅读[优化自动缩放参数](#tuning-autoscaling-parameters)章节。 + + + +## 获取 DNS Deployment 名或 ReplicationController 名 + + +列出集群中命名空间 kube-system 下的 Deployment: + + kubectl get deployment --namespace=kube-system + + + +在早于 1.12 的 Kubernetes 版本中,DNS Deployment 称之为 `kube-dns`。 + + + +在 Kubernetes 1.5 之前的版本中,DNS 是使用 ReplicationController 而不是 Deployment 来实现的。 +因此,如果在前面的输出中没有看到 kube-dns 或类似的名称,请在 kube-system 名称空间中列出集群中的 ReplicationControllers: + + kubectl get rc --namespace=kube-system + + + +输出类似: + + NAME DESIRED CURRENT READY AGE + ... + kube-dns-v20 1 1 1 ... + ... + + + +## 确定规模目标 + + + +如果是 DNS Deployment,则伸缩目标是: + + Deployment/ + + + +其中, 是 DNS Deployment 的名称。 +例如,如果 DNS Deployment 名是 coredns, +则伸缩目标是 Deployment/coredns。 + + + +如果是 DNS ReplicationController,则伸缩目标是: + + ReplicationController/ + + + +其中, 是 DNS ReplicationController 的名称。 +例如,如果 DNS ReplicationController 的名称为 kube-dns-v20,则伸缩目标是 ReplicationControlle/kube-dns-v20。 + + + +## 启用 DNS 水平自动扩缩 + + + +在本节中,您将创建一个 Deployment。Deployment 中的 Pod 根据 `cluster-proportional-autoscaler-amd64` 镜像运行容器。 + + + +创建一个名为 `dns-horizontal-autoscaler.yaml` 的文件内容如下: + +{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}} + + + +在文件中,将 `` 替换为扩缩目标。 + + + +转至包含配置文件的目录,然后输入以下命令以创建 Deployment: + + kubectl create -f dns-horizontal-autoscaler.yaml + + + +运行成功后的输出结果为: + + deployment.apps/kube-dns-autoscaler created + + + +现在启用了 DNS 水平自动扩缩。 + + + +## 调优自动扩缩参数 + + + +验证 dns-autoscaler ConfigMap 存在: + + kubectl get configmap --namespace=kube-system + + + +输出类似: + + NAME DATA AGE + ... + dns-autoscaler 1 ... + ... + + + +修改 ConfigMap 中的数据: + + kubectl edit configmap dns-autoscaler --namespace=kube-system + + + +寻找这一行: + + linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}' + + + +根据需要修改字段。`min` 字段表示 DNS 后端的最小数量。实际后端数的计算公式为: + + replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ) + + + +注意,`coresPerReplica` 和 `nodesPerReplica` 的值都是整数。 + + + +其思想是,当集群使用具有多个核心的节点时,`coresPerReplica` 占主导地位。 +当集群使用内核较少的节点时,`nodesPerReplica` 占主导地位。 + + + +还有其他受支持的扩展模式。有关详细信息,请参见 [cluster-proportion -autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。 + + + +## 禁用 DNS 水平自动扩缩 + + + +有一些选项可用于调优 DNS 水平自动扩缩。使用哪个选项取决于不同的条件。 + + + +### 选项 1:将 dns-autoscaler deployment 降低到 0 个副本 + + + +此选项适用于所有情况。输入这个命令: + + kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system + + + +输出是: + + deployment.extensions/dns-autoscaler scaled + + + +验证副本计数是否为零: + + kubectl get deployment --namespace=kube-system + + + +输出在 DESIRED 和 CURRENT 列中显示 0: + + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + ... + dns-autoscaler 0 0 0 0 ... + ... + + + +### 选项 2:删除 dns-autoscaler deployment + + + +如果 dns-autoscaler 在您自己的控制之下,则此选项有效,这意味着没有人会重新创建它: + + kubectl delete deployment dns-autoscaler --namespace=kube-system + + + +输出是: + + deployment.extensions "dns-autoscaler" deleted + + + +### 选项 3:从主节点中删除 dns-autoscaler 清单文件 + + + +此选项可行的前提是,dns-autoscaler 在[附加组件管理器](https://git.k8s.io/kubernetes/cluster/addons/README.md) 的控制之下, +并且有对主节点的写访问权。 + + + +登录主节点并删除相应的清单文件。这个 dns-autoscaler 的通用路径是: + + /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml + + + +删除清单文件后,附加组件管理器将删除 dns-autoscaler Deployment。 + +{{% /capture %}} + +{{% capture discussion %}} + + + +了解 DNS 水平自动缩放的工作原理 + + + +* 集群比例自动伸缩器应用程序与 DNS 服务分开部署。 + +* 一个自动伸缩 Pod 运行一个客户端,该客户端轮询 Kubernetes API 服务器以获得集群中的节点和核心的数量。 + +* 根据当前可调度节点和核心以及给定的缩放参数,计算并应用所需的副本计数到 DNS 后端。 + +* 缩放参数和数据点是通过 ConfigMap 提供给 autoscaler 的,它会在每个轮询间隔刷新参数表,以更新所需的最新缩放参数。 + +* 允许在不重新构建或重新启动自动缩放Pod的情况下更改缩放参数。 + +* autoscaler 提供了一个控制器接口来支持两种控制模式:*linear* 和 *ladder*。 + + + +## 未来的改进 + + + +除了线性和梯形之外,未来将考虑自定义度量的控制模式。 + + + +基于 DNS 特定指标的 DNS 后端扩展正在考虑作为未来发展。当前实现使用集群中的节点和核心数量是有限的。 + + + +未来将考虑支持类似于[水平 Pod 自动伸缩](/docs/tasks/run-application/horizontal-pod-autoscale/) + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +了解更多关于[实施 of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。 + +{{% /capture %}} + + + diff --git a/content/zh/docs/tasks/example-task-template.md b/content/zh/docs/tasks/example-task-template.md new file mode 100644 index 0000000000..3d3bec9b53 --- /dev/null +++ b/content/zh/docs/tasks/example-task-template.md @@ -0,0 +1,105 @@ +--- +title: 示例任务的模板 +reviewers: +- chenopis +content_template: templates/task +toc_hide: true +--- + + + +{{% capture overview %}} + + + +{{< note >}} +还要确保为新文档[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。 +{{< /note >}} + + +这个页面展示了如何... + +{{% /capture %}} + +{{% capture prerequisites %}} + + + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* 做这个。 +* 也做这个。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 做... + + + +1. 做这个。 +1. 接下来做这个。可能需要阅读一下这个[相关解释](...). + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 理解 ... + +**[可选部分]** + + +关于你刚才所做的过程,有一点是需要知道的。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +**[可选部分]** + + + +* 了解更多关于[撰写新主题](/docs/home/contribute/write-new-topic/). +* 查看[使用页面模板-任务模板](/docs/home/contribute/page-templates/#task_template) for how to use this template. + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/federation/_index.md b/content/zh/docs/tasks/federation/_index.md old mode 100644 new mode 100755 index 4885914869..c583d43de1 --- a/content/zh/docs/tasks/federation/_index.md +++ b/content/zh/docs/tasks/federation/_index.md @@ -1,12 +1,11 @@ +--- +title: "联邦 - 在多个集群上运行一个应用" +weight: 120 +--- + - ---- -title: "联邦 - 在多个集群上运行一个应用" -weight: 120 ---- - diff --git a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md b/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md new file mode 100644 index 0000000000..e113b82622 --- /dev/null +++ b/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md @@ -0,0 +1,255 @@ +--- +title: 在联邦中设置放置策略 +content_template: templates/task +--- + + + +{{% capture overview %}} + +{{< note >}} +{{< include "federation-current-state.md" >}} +{{< /note >}} + + +此页面显示如何使用外部策略引擎对联邦资源强制执行基于策略的放置决策。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +您需要一个正在运行的 Kubernetes 集群(它被引用为主机集群)。有关您的平台的安装说明,请参阅[入门](/docs/setup/)指南。 + +{{% /capture %}} + +{{% capture steps %}} + + +## Deploying 联邦并配置外部策略引擎 + + +可以使用 `kubefed init` 部署联邦控制平面。 + + +Deploying 联邦控制平面之后,必须在联邦 API 服务器中配置一个准入控制器,该控制器强制执行从外部策略引擎接收到的放置决策。 + + + kubectl create -f scheduling-policy-admission.yaml + + +下图是准入控制器的 ConfigMap 示例: + +{{< codenew file="federation/scheduling-policy-admission.yaml" >}} + + +ConfigMap 包含三个文件: + + +* `config.yml` 指定 `调度策略` 准入控制器配置文件的位置。 +* `scheduling-policy-config.yml` 指定与外部策略引擎联系所需的 kubeconfig 文件的位置。 +该文件还可以包含一个 `retryBackoff` 值,该值以毫秒为单位控制初始重试 backoff 延迟。 +* `opa-kubeconfig` 是一个标准的 kubeconfig,包含联系外部策略引擎所需的 URL 和凭证。 + + +编辑联邦 API 服务器部署以启用 `SchedulingPolicy` 准入控制器。 + + kubectl -n federation-system edit deployment federation-apiserver + + +更新 Federation API 服务器命令行参数以启用准入控制器, +并将 ConfigMap 挂载到容器中。如果存在现有的 `-enable-admissionplugins` 参数,则追加 `SchedulingPolicy` 而不是添加另一行。 + + + --enable-admission-plugins=SchedulingPolicy + --admission-control-config-file=/etc/kubernetes/admission/config.yml + + +将以下卷添加到联邦 API 服务器 pod: + + - name: admission-config + configMap: + name: admission + + +添加以下卷挂载联邦 API 服务器的 `apiserver` 容器: + + volumeMounts: + - name: admission-config + mountPath: /etc/kubernetes/admission + + + +## Deploying 外部策略引擎 + + +[Open Policy Agent (OPA)](http://openpolicyagent.org) 是一个开源的通用策略引擎, +您可以使用它在联邦控制平面中执行基于策略的放置决策。 + + +在主机群集中创建服务以联系外部策略引擎: + + kubectl create -f policy-engine-service.yaml + + +下面显示的是 OPA 的示例服务。 + +{{< codenew file="federation/policy-engine-service.yaml" >}} + + +使用联邦控制平面在主机群集中创建部署: + + kubectl create -f policy-engine-deployment.yaml + + +下面显示的是 OPA 的部署示例。 + +{{< codenew file="federation/policy-engine-deployment.yaml" >}} + + + +## 通过 ConfigMaps 配置放置策略 + + +外部策略引擎将发现在 Federation API 服务器的 `kube-federation-scheduling-policy` +命名空间中创建的放置策略。 + + +如果命名空间尚不存在,请创建它: + + kubectl --context=federation create namespace kube-federation-scheduling-policy + + +配置一个示例策略来测试外部策略引擎: + +{{< code file="policy.rego" >}} + + +下面显示的是创建示例策略的命令: + + kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego + + +这个示例策略说明了一些关键思想: + + + +* 位置策略可以引用联邦资源中的任何字段。 +* 放置策略可以利用外部上下文(例如,集群元数据)来做出决策。 +* 管理策略可以集中管理。 +* 策略可以定义简单的接口(例如 `requirements -pci` 注解),以避免在清单中重复逻辑。 + + + +## 测试放置政策 + + +注释其中一个集群以表明它是经过 PCI 认证的。 + + kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true + + +部署联邦副本来测试放置策略。 + +{{< codenew file="federation/replicaset-example-policy.yaml" >}} + + +下面显示的命令用于部署与策略匹配的副本集。 + + kubectl --context=federation create -f replicaset-example-policy.yaml + + +检查副本集以确认已应用适当的注解: + + kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}' + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/inject-data-application/_index.md b/content/zh/docs/tasks/inject-data-application/_index.md index c979d4d97f..7cf635bc76 100644 --- a/content/zh/docs/tasks/inject-data-application/_index.md +++ b/content/zh/docs/tasks/inject-data-application/_index.md @@ -1,3 +1,8 @@ +--- +title: "给应用注入数据" +weight: 30 +--- + ---- -title: "给应用注入数据" -weight: 30 ---- + diff --git a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md index 8823041a09..b0aa9a0ea1 100644 --- a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -33,7 +33,6 @@ content_template: templates/task ```shell kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml ``` - 1. 获取一下当前正在运行的Pods信息: ```shell @@ -42,7 +41,7 @@ content_template: templates/task 查询结果应为: - ```log + ```shell NAME READY STATUS RESTARTS AGE envar-demo 1/1 Running 0 9s ``` @@ -61,14 +60,13 @@ content_template: templates/task 打印结果应为: - ```log + ```shell NODE_VERSION=4.4.2 EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 HOSTNAME=envar-demo ... DEMO_GREETING=Hello from the environment ``` - 1. 通过键入`exit`退出命令终端。 {{% /capture %}} @@ -80,6 +78,3 @@ content_template: templates/task * 关于[EnvVarSource](/docs/api-reference/{{< param "version" >}}/#envvarsource-v1-core)资源的信息。 {{% /capture %}} - - - diff --git a/content/zh/docs/tasks/job/_index.md b/content/zh/docs/tasks/job/_index.md index 92bcf81909..06c6528ac6 100644 --- a/content/zh/docs/tasks/job/_index.md +++ b/content/zh/docs/tasks/job/_index.md @@ -1,12 +1,11 @@ +--- +title: "运行 Jobs" +weight: 50 +--- + - ---- -title: "运行任务" -weight: 50 ---- - diff --git a/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md new file mode 100644 index 0000000000..6b9913392e --- /dev/null +++ b/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -0,0 +1,504 @@ +--- +title: 使用工作队列进行粗粒度并行处理 +content_template: templates/task +weight: 30 +--- + + + +{{% capture overview %}} + + + +本例中,我们会运行包含多个并行工作进程的 Kubernetes Job。 + +本例中,每个 Pod 一旦被创建,会立即从任务队列中取走一个工作单元并完成它,然后将工作单元从队列中删除后再退出。 + +下面是本次示例的主要步骤: + +1. **启动一个消息队列服务** 本例中,我们使用 RabbitMQ,你也可以用其他的消息队列服务。在实际工作环境中,你可以创建一次消息队列服务然后在多个任务中重复使用。 + +1. **创建一个队列,放上消息数据** 每个消息表示一个要执行的任务。本例中,每个消息是一个整数值。我们将基于这个整数值执行很长的计算操作。 + +1. **启动一个在队列中执行这些任务的 Job**。该 Job 启动多个 Pod。每个 Pod 从消息队列中取走一个任务,处理它,然后重复执行,直到队列的队尾。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + + + +要熟悉 Job 基本用法(非并行的),请参考 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)。 + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + + +## 启动消息队列服务 + +本例使用了 RabbitMQ,使用其他 AMQP 类型的消息服务应该比较容易。 + +在实际工作中,在集群中一次性部署某个消息队列服务,之后在很多 Job 中复用,包括需要长期运行的服务。 + +按下面的方法启动 RabbitMQ: + +```shell +$ kubectl create -f examples/celery-rabbitmq/rabbitmq-service.yaml +service "rabbitmq-service" created +$ kubectl create -f examples/celery-rabbitmq/rabbitmq-controller.yaml +replicationcontroller "rabbitmq-controller" created +``` + + + +我们仅用到 [celery-rabbitmq 示例](https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/celery-rabbitmq) 中描述的部分功能。 + + + +## 测试消息队列服务 + +现在,我们可以试着访问消息队列。我们将会创建一个临时的可交互的 Pod,在它上面安装一些工具,然后用队列做实验。 + +首先创建一个临时的可交互的 Pod: + +```shell +# 创建一个临时的可交互的 Pod +$ kubectl run -i --tty temp --image ubuntu:14.04 +Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false +... [ previous line repeats several times .. hit return when it stops ] ... +``` + + + +请注意你的 Pod 名称和命令提示符将会不同。 + +接下来安装 `amqp-tools` ,这样我们就能用消息队列了。 + +```shell +# 安装一些工具 +root@temp-loe07:/# apt-get update +.... [ lots of output ] .... +root@temp-loe07:/# apt-get install -y curl ca-certificates amqp-tools python dnsutils +.... [ lots of output ] .... +``` + + + +后续,我们将制作一个包含这些包的 Docker 镜像。 + +接着,我们将要验证我们发现 RabbitMQ 服务: + + + + +``` +# 请注意 rabbitmq-service 有Kubernetes 提供的 DNS 名称, + +root@temp-loe07:/# nslookup rabbitmq-service +Server: 10.0.0.10 +Address: 10.0.0.10#53 + +Name: rabbitmq-service.default.svc.cluster.local +Address: 10.0.147.152 + +# 你的 IP 地址将会发生变化。 +``` + + + +如果 Kube-DNS 没有正确安装,上一步可能会出错。 +你也可以在环境变量中找到服务 IP。 + + + +``` +# env | grep RABBIT | grep HOST +RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152 + +# 你的 IP 地址将会发生变化。 +``` + + + +接着我们将要确认可以创建队列,并能发布消息和消费消息。 + + + + + + + +```shell +# 下一行,rabbitmq-service 是访问 rabbitmq-service 的主机名。5672是 rabbitmq 的标准端口。 + +root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672 + +# 如果上一步中你不能解析 "rabbitmq-service",可以用下面的命令替换: +# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672 + +# 现在创建队列: + +root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d foo + +# 向它推送一条消息: + +root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello + +# 然后取回它. + +root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo +Hello +root@temp-loe07:/# +``` + + +最后一个命令中, `amqp-consume` 工具从队列中取走了一个消息,并把该消息传递给了随机命令的标准输出。在这种情况下,`cat` 只会打印它从标准输入或得的内容,echo 只会添加回车符以便示例可读。 + + + +## 为队列增加任务 + +现在让我们给队列增加一些任务。在我们的示例中,任务是多个待打印的字符串。 + +实践中,消息的内容可以是: + +- 待处理的文件名 +- 程序额外的参数 +- 数据库表的关键字范围 +- 模拟任务的配置参数 +- 待渲染的场景的帧序列号 + + + +本例中,如果有大量的数据需要被 Job 的所有 Pod 读取,典型的做法是把它们放在一个共享文件系统中,如NFS,并以只读的方式挂载到所有 Pod,或者 Pod 中的程序从类似 HDFS 的集群文件系统中读取。 + +例如,我们创建队列并使用 amqp 命令行工具向队列中填充消息。实践中,你可以写个程序来利用 amqp 客户端库来填充这些队列。 + +```shell +$ /usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d job1 +$ for f in apple banana cherry date fig grape lemon melon + +do + /usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f +done +``` + + + +这样,我们给队列中填充了8个消息。 + +## 创建镜像 + +现在我们可以创建一个做为 Job 来运行的镜像。 + +我们将用 `amqp-consume` 来从队列中读取消息并实际运行我们的程序。这里给出一个非常简单的示例程序: + +{{< codenew language="python" file="application/job/rabbitmq/worker.py" >}} + + + +现在,编译镜像。如果你在用源代码树,那么切换到目录 `examples/job/work-queue-1`。否则的话,创建一个临时目录,切换到这个目录。下载 [Dockerfile](/examples/application/job/rabbitmq/Dockerfile),和 [worker.py](/examples/application/job/rabbitmq/worker.py)。无论哪种情况,都可以用下面的命令编译镜像 + +```shell +$ docker build -t job-wq-1 . +``` + + + +对于 [Docker Hub](https://hub.docker.com/), 给你的应用镜像打上标签,标签为你的用户名,然后用下面的命令推送到 Hub。用你的 Hub 用户名替换 ``。 + +```shell +docker tag job-wq-1 /job-wq-1 +docker push /job-wq-1 +``` + + + +如果你在用[谷歌容器仓库](https://cloud.google.com/tools/container-registry/),用你的项目 ID 作为标签打到你的应用镜像上,然后推送到 GCR。用你的项目 ID 替换 ``。 + +```shell +docker tag job-wq-1 gcr.io//job-wq-1 +gcloud docker -- push gcr.io//job-wq-1 +``` + + + +## 定义 Job + +这里给出一个 Job 定义 yaml文件。你需要拷贝一份并编辑镜像以匹配你使用的名称,保存为 `./job.yaml`。 + +{{< codenew file="application/job/rabbitmq/job.yaml" >}} + + + +本例中,每个 Pod 使用队列中的一个消息然后退出。这样,Job 的完成计数就代表了完成的工作项的数量。本例中我们设置 `.spec.completions: 8`,因为我们放了8项内容在队列中。 + +## 运行 Job + +现在我们运行 Job: + +```shell +kubectl create -f ./job.yaml +``` + + + +稍等片刻,然后检查 Job。 + +```shell +$ kubectl describe jobs/job-wq-1 +Name: job-wq-1 +Namespace: default +Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f +Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f + job-name=job-wq-1 +Annotations: +Parallelism: 2 +Completions: 8 +Start Time: Wed, 06 Sep 2017 16:42:02 +0800 +Pods Statuses: 0 Running / 8 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f + job-name=job-wq-1 + Containers: + c: + Image: gcr.io/causal-jigsaw-637/job-wq-1 + Port: + Environment: + BROKER_URL: amqp://guest:guest@rabbitmq-service:5672 + QUEUE: job1 + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + ───────── ──────── ───── ──── ───────────── ────── ────── ─────── + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5 + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr + 26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj + 15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe + 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa + 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0 +``` + + + +我们所有的 Pod 都成功了。耶! + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 替代方案 + +本文所讲述的处理方法的好处是你不需要修改你的 "worker" 程序使其知道工作队列的存在。 + + 本文所描述的方法需要你运行一个消息队列服务。如果不方便运行消息队列服务,你也许会考虑另外一种[任务模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 + + + +本文所述的方法为每个工作项创建了一个 Pod。如果你的工作项仅需数秒钟,为每个工作项创建 Pod会增加很多的常规消耗。可以考虑另外的方案请参考[示例](/docs/tasks/job/fine-parallel-processing-work-queue/),这种方案可以实现每个 Pod 执行多个工作项。 + +示例中,我们使用 `amqp-consume` 从消息队列读取消息并执行我们真正的程序。这样的好处是你不需要修改你的程序使其知道队列的存在。要了解怎样使用客户端库和工作队列通信,请参考[不同的示例](/docs/tasks/job/fine-parallel-processing-work-queue/)。 + + + +## 友情提醒 + +如果设置的完成数量小于队列中的消息数量,会导致一部分消息项不会被执行。 + +如果设置的完成数量大于队列中的消息数量,当队列中所有的消息都处理完成后,Job 也会显示为未完成。Job 将创建 Pod 并阻塞等待消息输入。 + +当发生下面两种情况时,即使队列中所有的消息都处理完了,Job 也不会显示为完成状态: +* 在 amqp-consume 命令拿到消息和容器成功退出之间的时间段内,执行杀死容器操作; +* 在 kubelet 向 api-server 传回 Pod 成功运行之前,发生节点崩溃。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md index 4d4d3432dc..6b1dc65a81 100755 --- a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -40,17 +40,22 @@ Here is an overview of the steps in this example: detect when a finite-length work queue is empty. In practice you would set up a store such as Redis once and reuse it for the work queues of many jobs, and other things. --> + 1. **启动存储服务用于保存工作队列。** 在这个例子中,我们使用 Redis 来存储工作项。在上一个例子中,我们使用了 RabbitMQ。在这个例子中,由于 AMQP 不能为客户端提供一个良好的方法来检测一个有限长度的工作队列是否为空,我们使用了 Redis 和一个自定义的工作队列客户端库。在实践中,您可能会设置一个类似于 Redis 的存储库,并将其同时用于多项任务或其他事务的工作队列。 + -1. **创建一个队列,然后向其中填充消息。** 每个消息表示一个将要被处理的工作任务。在这个例子中,消息只是一个我们将用于进行长度计算的整数。 + +2. **创建一个队列,然后向其中填充消息。** 每个消息表示一个将要被处理的工作任务。在这个例子中,消息只是一个我们将用于进行长度计算的整数。 + -1. **启动一个 Job 对队列中的任务进行处理**。这个 Job 启动了若干个 Pod 。每个 Pod 从消息队列中取出一个工作任务,处理它,然后重复,直到到达队列的尾部。 + +3. **启动一个 Job 对队列中的任务进行处理**。这个 Job 启动了若干个 Pod 。每个 Pod 从消息队列中取出一个工作任务,处理它,然后重复,直到到达队列的尾部。 {{% /capture %}} diff --git a/content/zh/docs/tasks/job/parallel-processing-expansion.md b/content/zh/docs/tasks/job/parallel-processing-expansion.md new file mode 100644 index 0000000000..5cbdc3e8da --- /dev/null +++ b/content/zh/docs/tasks/job/parallel-processing-expansion.md @@ -0,0 +1,302 @@ +--- +title: 使用扩展进行并行处理 +content_template: templates/concept +weight: 20 +--- + + + +{{% capture overview %}} + + +在这个示例中,我们将运行从一个公共模板创建的多个 Kubernetes 作业。您可能希望熟悉 +[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本、非并行使用。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 基本模板扩展 + + +首先,将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中 + +{{< codenew file="application/job/job-tmpl.yaml" >}} + + +与 *pod 模板*不同,我们的 *job 模板*不是 Kubernetes API 类型。它只是作业对象的 yaml 表示, +YAML 文件有一些占位符,在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 + + +在这个例子中,容器所做的唯一处理是 `echo` 一个字符串并休眠一段时间。 +在真实的用例中,处理将是一些重要的计算,例如呈现电影的帧,或者处理数据库中的一系列行。例如,`$ITEM` 参数将指定帧号或行范围。 + + +这个作业及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 +这个标签使得我们可以方便地同时操作组中的所有作业。 +我们还将相同的标签放在 pod 模板上,这样我们就可以用一个命令检查这些作业的所有 pod。 +创建作业之后,系统将添加更多的标签来区分一个作业的 pod 和另一个作业的 pod。 +注意,标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 + + +下一步,将模板展开到多个文件中,每个文件对应要处理的项。 + +```shell +# Expand files into a temporary directory +$ mkdir ./jobs +$ for i in apple banana cherry +do + cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml +done +``` + + +检查是否工作正常: + +```shell +$ ls jobs/ +job-apple.yaml +job-banana.yaml +job-cherry.yaml +``` + + +在这里,我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 +您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成作业对象。 + + +接下来,使用 kubectl 命令创建所有作业: + +```shell +$ kubectl create -f ./jobs +job "process-item-apple" created +job "process-item-banana" created +job "process-item-cherry" created +``` + + +现在,检查这些作业: + +```shell +$ kubectl get jobs -l jobgroup=jobexample +NAME DESIRED SUCCESSFUL AGE +process-item-apple 1 1 31s +process-item-banana 1 1 31s +process-item-cherry 1 1 31s +``` + + +在这里,我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作,我们不想看到。) + + +我们可以检查 pod 以及使用同样地标签选择器: + +```shell +$ kubectl get pods -l jobgroup=jobexample +NAME READY STATUS RESTARTS AGE +process-item-apple-kixwv 0/1 Completed 0 4m +process-item-banana-wrsf7 0/1 Completed 0 4m +process-item-cherry-dnfu9 0/1 Completed 0 4m +``` + + +没有一个命令可以一次检查所有作业的输出,但是循环遍历所有 pod 非常简单: + +```shell +$ for p in $(kubectl get pods -l jobgroup=jobexample -o name) +do + kubectl logs $p +done +Processing item apple +Processing item banana +Processing item cherry +``` + + + +## 多个模板参数 + + +在第一个示例中,模板的每个实例都有一个参数,该参数也用作标签。 +但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 + + +这个稍微复杂一点的示例使用 jinja2 板语言来生成我们的对象。 +我们将使用一行 python 脚本将模板转换为文件。 + + +首先,粘贴作业对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中: + +```liquid +{%- set params = [{ "name": "apple", "url": "http://www.orangepippin.com/apples", }, + { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", }, + { "name": "raspberry", "url": "https://www.raspberrypi.org/" }] +%} +{%- for p in params %} +{%- set name = p["name"] %} +{%- set url = p["url"] %} +apiVersion: batch/v1 +kind: Job +metadata: + name: jobexample-{{ name }} + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] + restartPolicy: Never +--- +{%- endfor %} + +``` + + +上面的模板使用 python dicts 列表(第1-4行)定义每个作业对象的参数。 +然后 for 循环为每组参数(剩余行)生成一个作业 yaml 对象。 +我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实(倒数第二行)。 +我们可以将输出直接传递给 kubectl 来创建对象。 + + +如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 +现在,使用这个一行 python 程序来展开模板: + +```shell +alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' +``` + + + +输出可以保存到一个文件,像这样: + +```shell +cat job.yaml.jinja2 | render_template > jobs.yaml +``` + + +或直接发送到 kubectl,如下所示: + +```shell +cat job.yaml.jinja2 | render_template | kubectl create -f - +``` + + +## 替代方案 + + +如果您有大量作业对象,您可能会发现: + + + +- 即使使用标签,管理这么多作业对象也很麻烦。 +- 在一次创建所有作业时,您超过了资源配额,可是您也不希望以递增方式创建作业并等待其完成。 +- 同时创建的大量作业会使 Kubernetes apiserver、控制器或调度程序过载。 + + + +在这种情况下,您可以考虑 +其他[工作模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/manage-daemon/_index.md b/content/zh/docs/tasks/manage-daemon/_index.md new file mode 100644 index 0000000000..6291829ea9 --- /dev/null +++ b/content/zh/docs/tasks/manage-daemon/_index.md @@ -0,0 +1,11 @@ +--- +title: "管理集群守护进程" +weight: 130 +--- + + diff --git a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md new file mode 100644 index 0000000000..aa8c9a241b --- /dev/null +++ b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md @@ -0,0 +1,333 @@ +--- +reviewers: +- janetkuo +title: 对 DaemonSet 执行滚动更新 +content_template: templates/task +--- + + + +{{% capture overview %}} + + +本文介绍了如何对 DaemonSet 执行滚动更新。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + + +* Kubernetes 1.6 或者更高版本中才支持 DaemonSet 滚动更新功能。 + +{{% /capture %}} + + +{{% capture steps %}} + + +## DaemonSet 更新策略 + + +DaemonSet 有两种更新策略: + + +* OnDelete: 使用 `OnDelete` 更新策略时,在更新 DaemonSet 模板后,只有当您手动删除老的 DaemonSet pods 之后,新的 DaemonSet pods *才会*被自动创建。跟 Kubernetes 1.6 以前的版本类似。 +* RollingUpdate: 这是默认的更新策略。使用 `RollingUpdate` 更新策略时,在更新 DaemonSet 模板后,老的 DaemonSet pods 将被终止,并且将以受控方式自动创建新的 DaemonSet pods。 + + +## 执行滚动更新 + + +要启用 DaemonSet 的滚动更新功能,必须设置 `.spec.updateStrategy.type` 为 `RollingUpdate`。 + + +您可能想设置[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (默认为 1) 和[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (默认为 0)。 + + +### 步骤 1: 检查 DaemonSet 的滚动更新策略 + + +首先,检查 DaemonSet 的更新策略,确保已经将其设置为 `RollingUpdate`: + +```shell +kubectl get ds/ -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' +``` + + +如果还没在系统中创建 DaemonSet,请使用以下命令检查 DaemonSet 的清单: + +```shell +kubectl create -f ds.yaml --dry-run -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' +``` + +两个命令的输出都应该为: + +```shell +RollingUpdate +``` + + +如果输出不是 `RollingUpdate`,请返回并相应地修改 DaemonSet 对象或者清单。 + + +### 步骤 2:使用 `RollingUpdate` 更新策略创建 DaemonSet + + +如果已经创建了 DaemonSet,则可以跳过该步骤并跳转到步骤 3。 + + +验证 DaemonSet 清单的更新策略后,创建 DaemonSet: + +```shell +kubectl create -f ds.yaml +``` + + +或者,您打算使用 `kubectl apply` 更新 DaemonSet,请使用 `kubectl apply` 创建相同的 DaemonSet。 + +```shell +kubectl apply -f ds.yaml +``` + + +### 步骤 3:更新 DaemonSet 模板 + + +对 `RollingUpdate` DaemonSet `.spec.template` 的任何更新都将触发滚动更新。这可以通过几个不同的 `kubectl` 命令来完成。 + + +#### 声明式命令 + + +如果您使用[配置文件](/docs/concepts/overview/object-management-kubectl/declarative-config/)来更新 DaemonSets,请使用 `kubectl apply`: + +```shell +kubectl apply -f ds-v2.yaml +``` + + +#### 命令式命令 + + +如果您使用[命令式命令](/docs/concepts/overview/object-management-kubectl/imperative-command/)来更新 DaemonSets,请使用`kubectl edit` 或者 `kubectl patch`: + +```shell +kubectl edit ds/ +``` + +```shell +kubectl patch ds/ -p= +``` + + +##### 只更新容器镜像 + + +如果您只需要更新 DaemonSet 模板里的容器镜像,比如,`.spec.template.spec.containers[*].image`, 请使用 `kubectl set image`: + +```shell +kubectl set image ds/ = +``` + + +### 步骤 4:查看滚动更新状态 + + +最后,观察 DaemonSet 最新滚动更新的进度: + +```shell +kubectl rollout status ds/ +``` + + +当滚动更新完成时,输出结果如下: + +```shell +daemonset "" successfully rolled out +``` + + +## 故障排查 + + +### DaemonSet 滚动更新卡住 + + +有时,DaemonSet 滚动更新可能会卡住。可能原因如下: + + +#### 一些节点资源用尽 + + +由于新 DaemonSet pods 无法调度到至少一个节点时,滚动更新就会卡住。这可能是由于节点已经[资源用尽](/docs/tasks/administer-cluster/out-of-resource/)。 + + +发生这种情况时,通过对 `kubectl get nodes` 和下面命令行的输出作比较,找出没有调度部署 DaemonSet pods 的节点: + +```shell +kubectl get pods -l = -o wide +``` + + +一旦找到这些节点,从节点上删除一些非 DaemonSet pods,为新的 DaemonSet pods 腾出空间。 + + +{{< note >}} +当所删除的 pods 不受任何控制器管理,也不是多副本的 pods,上述操作将导致服务中断。 +同时,上述操作也不会考虑 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/) 所施加的约束。 + +{{< /note >}} + + +#### 滚动中断 + + +如果最近的 DaemonSet 模板更新被破坏了,比如,容器处于崩溃循环状态或者容器镜像不存在(通常由于拼写错误),就会发生 DaemonSet 滚动更新中断。 + + +要解决此问题,只需再次更新 DaemonSet 模板即可。以前不健康的滚动更新不会阻止新的滚动更新。 + + +#### 时钟偏差 + + +如果在 DaemonSet 中指定了 `.spec.minReadySeconds`,主节点和工作节点之间的时钟偏差会使 DaemonSet 无法检测到正确的滚动更新进度。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + + +* 查看[任务: 在 DaemonSet 上执行回滚](/docs/tasks/manage-daemon/rollback-daemon-set/) +* 查看[概念: 创建 DaemonSet 以适应现有的 DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) + +{{% /capture %}} diff --git a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md index 7750980c9b..3a2e86de0f 100644 --- a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md @@ -5,175 +5,318 @@ title: 调度 GPU content_template: templates/task --- + + {{% capture overview %}} + + + +Kubernetes 支持对节点上的 AMD 和 NVIDA GPU 进行管理,目前处于**实验**状态。对 NVIDIA GPU 的支持在 v1.6 中加入,已经经历了多次不向后兼容的迭代。而对 AMD GPU 的支持则在 v1.9 中通过 [device plugin](#deploying-amd-gpu-device-plugin) 加入。 + +这个页面介绍了用户如何在不同的 Kubernetes 版本中使用 GPU,以及当前存在的一些限制。 {{% /capture %}} -{{% capture prerequisites %}} +{{% capture body %}} + -{{% /capture %}} +## 从 v1.8 起 -{{% capture steps %}} +**从 1.8 版本开始,我们推荐通过 [设备插件](/docs/concepts/cluster-administration/device-plugins) 的方式来使用 GPU。** -## API +在 1.10 版本之前,为了通过设备插件开启 GPU 的支持,我们需要在系统中将 `DevicePlugins` 这一特性门控显式地设置为 true:`--feature-gates="DevicePlugins=true"`。不过,从 1.10 版本开始,我们就不需要这一步骤了。 +接着你需要在主机节点上安装对应厂商的 GPU 驱动 并运行对应厂商的 device plugin [AMD](#%E9%83%A8%E7%BD%B2-amd-gpu-device-plugin)、[NVIDIA](#%E9%83%A8%E7%BD%B2-nvidia-gpu-device-plugin)。 -容器可以通过名称为 `alpha.kubernetes.io/nvidia-gpu` 的标识来申请需要使用的 NVIDIA GPU 的数量 + + +当上面的条件都满足,Kubernetes 将会暴露 `nvidia.com/gpu` 或 `amd.com/gpu` 来作为一种可调度的资源。 + +你也能通过像请求 `cpu` 或 `memory` 一样请求 `.com/gpu` 来在容器中使用 GPU。然而,当你要通过指定资源请求来使用 GPU 时,存在着以下几点限制: + +- GPU 仅仅支持在 `limits` 部分被指定,这表明: + * 你可以仅仅指定 GPU 的 `limits` 字段而不必须指定 `requests` 字段,因为 Kubernetes 会默认使用 limit 字段的值来作为 request 字段的默认值。 + * 你能同时指定 GPU 的 `limits` 和 `requests` 字段,但这两个值必须相等。 + * 你不能仅仅指定 GPU 的 `request` 字段而不指定 `limits`。 +- 容器(以及 pod)并不会共享 GPU,也不存在对 GPU 的过量使用。 +- 每一个容器能够请求一个或多个 GPU。然而只请求一个 GPU 的一部分是不允许的。 + +下面是一个例子: ```yaml apiVersion: v1 -kind: Pod +kind: Pod metadata: - name: gpu-pod -spec: - containers: - - - name: gpu-container-1 - image: k8s.gcr.io/pause:2.0 - resources: - limits: - alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs - - - name: gpu-container-2 - image: k8s.gcr.io/pause:2.0 - resources: - limits: - alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs -``` - - -- GPU 只能在容器资源的 `limits` 中配置 - -- 容器和 Pod 都不支持共享 GPU - -- 每个容器可以申请使用一个或者多个 GPU - -- GPU 必须以整数为单位被申请使用 - -- 所有节点的 GPU 硬件要求相同 - - -如果在不同的节点上面安装了不同版本的 GPU,可以通过设置节点标签以及使用节点选择器的方式将 pod 调度到期望运行的节点上。工作流程如下: - - -在节点上,识别出 GPU 硬件类型,然后将其作为节点标签进行暴露 - -```shell -NVIDIA_GPU_NAME=$(nvidia-smi --query-gpu=gpu_name --format=csv,noheader --id=0) -source /etc/default/kubelet -KUBELET_OPTS="$KUBELET_OPTS --node-labels='alpha.kubernetes.io/nvidia-gpu-name=$NVIDIA_GPU_NAME'" -echo "KUBELET_OPTS=$KUBELET_OPTS" > /etc/default/kubelet -``` - - -在 pod 上,通过节点[亲和性](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)规则为它指定可以使用的 GPU 类型 - -```yaml -kind: pod -apiVersion: v1 -metadata: - annotations: - scheduler.alpha.kubernetes.io/affinity: > - { - "nodeAffinity": { - "requiredDuringSchedulingIgnoredDuringExecution": { - "nodeSelectorTerms": [ - { - "matchExpressions": [ - { - "key": "alpha.kubernetes.io/nvidia-gpu-name", - "operator": "In", - "values": ["Tesla K80", "Tesla P100"] - } - ] - } - ] - } - } - } + name: cuda-vector-add spec: + restartPolicy: OnFailure containers: - - - name: gpu-container-1 + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" resources: limits: - alpha.kubernetes.io/nvidia-gpu: 2 + nvidia.com/gpu: 1 # requesting 1 GPU ``` + -到目前为止,还需要预先在节点上安装 CUDA 库 +### 部署 AMD GPU device plugin +[官方的 AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) 有以下要求: -为了避免后面使用库出现问题,可以将库放到 ``/var/lib/`` 下的某个文件夹下,或者直接改变库目录的权限(以后的版本会自动完成这一过程) +- Kubernetes 节点必须预先安装 AMD GPU 的 Linux 驱动。 +如果你的集群已经启动并且上述要求满足的话,可以这样部署 AMD device plugin: -Pods能够通过 `hostPath` 卷来访问库 +``` +# 针对 Kubernetes v1.9 +kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.9/k8s-ds-amdgpu-dp.yaml + +# 针对 Kubernetes v1.10 +kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml +``` + +请到 [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) 报告有关此 device plugin 的问题。 + + + +### 部署 NVIDIA GPU device plugin + +对于 NVIDIA,目前存在两种 device plugin 的实现: + +#### 官方的 NVIDIA GPU device plugin + +[官方的 NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin) 有以下要求: + +- Kubernetes 的节点必须预先安装了 NVIDIA 驱动 +- Kubernetes 的节点必须预先安装 [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) +- Docker 的[默认运行时](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)必须设置为 nvidia-container-runtime,而不是 runc +- NVIDIA 驱动版本 ~= 361.93 + +如果你的集群已经启动并且上述要求满足的话,可以这样部署 NVIDIA device plugin: + +``` +# 针对 Kubernetes v1.8 +kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml + +# 针对 Kubernetes v1.9 +kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml +``` + +请到 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin) 报告有关此 device plugin 的问题。 + + + +#### GKE/GCE 中使用的 NVIDIA GPU device plugin + +[GKE/GCE 使用的 NVIDIA GPU device plugin](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) +并不要求使用 nvidia-docker,并且对于任何实现了 Kubernetes CRI 的容器运行时,都应该能够使用。这一实现已经在 [Container-Optimized OS](https://cloud.google.com/container-optimized-os/) 上进行了测试,并且在 1.9 版本之后会有对于 Ubuntu 的实验性代码。 + +在你 1.9 版本的集群上,你能使用下面的命令来安装 NVIDIA 驱动以及 device plugin: + +``` +# 在 Container-Optimized OS 上安装 NVIDIA 驱动: +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/daemonset.yaml + +# 在 Ubuntu 上安装 NVIDIA 驱动 (实验性质): +kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/ubuntu/daemonset.yaml + +# 安装 device plugin: +kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.9/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml +``` + +请到 [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators) 报告有关此 device plugin 以及安装方法的问题 + + + +## 集群内存在不同类型的 NVIDIA GPU + +如果集群内部的不同节点上有不同类型的 NVIDIA GPU,那么你可以使用 [Node Label 和 Node Selecter](/docs/tasks/configure-pod-container/assign-pods-nodes/) 来将pod调度到合适的节点上。 + +举一个例子: + +```shell +# 为你的节点加上它们所拥有的加速器类型的标签 +kubectl label nodes accelerator=nvidia-tesla-k80 +kubectl label nodes accelerator=nvidia-tesla-p100 +``` + +在 pod 的 spec 字段中指定 GPU 的类型: ```yaml -kind: Pod apiVersion: v1 +kind: Pod metadata: - name: gpu-pod + name: cuda-vector-add spec: + restartPolicy: OnFailure containers: - - name: gpu-container-1 - image: k8s.gcr.io/pause:2.0 - resources: - limits: - alpha.kubernetes.io/nvidia-gpu: 1 - volumeMounts: - - mountPath: /usr/local/nvidia/bin - name: bin - - mountPath: /usr/lib/nvidia - name: lib - volumes: - - hostPath: - path: /usr/lib/nvidia-375/bin - name: bin - - hostPath: - path: /usr/lib/nvidia-375 - name: lib + - name: cuda-vector-add + # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc. ``` + -## 未来 - - -- Kubernetes 对硬件加速器的支持还处在早期阶段 - -- GPU 和其它的加速器很快会成为系统的本地计算资源 - -- 将引入更好的 API 以可扩展的方式提供和使用加速器 - -- Kubernetes 将会自动确保应用在使用 GPU 时得到最佳性能 - -- 类似访问 CUDA 库这种关键的可用性问题将得到解决 - -{{% /capture %}} - - +这能够保证 pod 能够被调度到拥有你所指定类型的 GPU 的节点上去。 diff --git a/content/zh/docs/tasks/network-policy-provider/_index.md b/content/zh/docs/tasks/network-policy-provider/_index.md new file mode 100644 index 0000000000..b66f21bfa8 --- /dev/null +++ b/content/zh/docs/tasks/network-policy-provider/_index.md @@ -0,0 +1,11 @@ +--- +title: 安装网络策略驱动 +weight: 30 +--- + + diff --git a/content/zh/docs/tasks/run-application/_index.md b/content/zh/docs/tasks/run-application/_index.md new file mode 100644 index 0000000000..795623eb40 --- /dev/null +++ b/content/zh/docs/tasks/run-application/_index.md @@ -0,0 +1,11 @@ +--- +title: "运行应用" +weight: 40 +--- + + diff --git a/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md new file mode 100644 index 0000000000..7197d8034d --- /dev/null +++ b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -0,0 +1,158 @@ +--- +reviewers: +- bprashanth +- erictune +- foxish +- smarterclayton +title: 强制删除 StatefulSet 类型的 Pods +content_template: templates/task +weight: 70 +--- + + + +{{% capture overview %}} + +本文介绍了如何删除 StatefulSet 管理的部分 pods,并且解释了这样操作时需要记住的注意事项。 +{{% /capture %}} + +{{% capture prerequisites %}} + + +* 这是一项相当高级的任务,并且可能会违反 StatefulSet 固有的某些属性。 +* 继续任务之前,请熟悉下面列举的注意事项。 + +{{% /capture %}} + +{{% capture steps %}} + + +## StatefulSet 注意事项 + + +在 StatefulSet 的正常操作中,**永远不**需要强制删除 StatefulSet 管理的 pod。StatefulSet 控制器负责创建,扩容和删除 StatefulSet 管理的 pods。它尝试确保从序号 0 到 N-1 指定数量的 pods 处于活动状态并准备就绪。StatefulSet 确保在任何时候,集群中最多只有一个具有给定标识的 pod。这就是所谓的由 StatefulSet 提供的*最多一个*的语义。 + + +应谨慎进行手动强制删除操作,因为它可能会违反 StatefulSet 固有的至多一个的语义。StatefulSets 可用于运行分布式和集群级的应用,这些应用需要稳定的网络标识和可靠的存储。这些应用通常配置为具有固定标识固定数量的成员集合。具有相同身份的多个成员可能是灾难性的,并且可能导致数据丢失 (e.g. 基于 quorum 系统中的脑裂场景)。 + + +## 删除 Pods + + +您可以使用下面的命令执行优雅地删除 pod: + +```shell +kubectl delete pods +``` + + +为了使上面的方法能够正常终止,Pod **一定不能**设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的,强烈建议 StatefulSet 类型的 pods 不要使用。优雅删除是安全的,并且会在 kubelet 从 apiserver 中删除名称之前确保 [优雅地关闭 pod ](/docs/user-guide/pods/#termination-of-pods)。 + + +Kubernetes (1.5 版本或者更新版本)不会因为一个 Node 无法访问而删除 pods。在无法访问节点上运行的 pods 在[超时](/docs/admin/node/#node-condition)后会进入'Terminating' 或者 'Unknown' 状态。当用户尝试优雅删除无法访问节点上的 pod 时,pods 也可能会进入这些状态。从 apiserver 中删除处于这些状态 pod 的唯一方法如下: + + + * Node 对象被删除(要么您删除, 或者[Node Controller](/docs/admin/node))。
+ * 无响应节点上的 kubelet 开始响应,杀死 pod 并从 apiserver 中移除该条目。
+ * 用户强制删除 pod。 + + +推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如,永久断开网络,断电等),则删除 Node 对象。如果节点遇到网裂,请尝试解决该问题或者等待其解决。当网裂愈合时,kubelet 将完成 pod 的删除并从 apiserver 中释放其名字。 + + +通常,pod 一旦不在节点上运行,或者管理员删除了节点,系统就会完成删除。你可以通过强制删除 pod 来覆盖它。 + + +### 强制删除 + + +强制删除**不要**等待来自 kubelet 的确认 pod 已被终止。无论强制删除是否成功杀死了 pod,它都会立即从 apiserver 中释放该名字。这将让 StatefulSet 控制器创建一个具有相同标识的替换 pod;这可能导致正在运行 pod 的重复,并且如果所述 pod 仍然可以与 StatefulSet 的成员通信,则将违反 StatefulSet 旨在保证的最多一个的语义。 + + +当你强制删除 StatefulSet 类型的 pod 时,你要确保有问题的 pod 不会再和 StatefulSet 管理的其他 pods通信,并且可以安全地释放其名字以便创建替换 pod。 + + +如果要使用 kubectl version >= 1.5 强制删除 pod,请执行下面命令: + +```shell +kubectl delete pods --grace-period=0 --force +``` + + +如果您使用 kubectl <= 1.4 的任何版本,则应省略 `--force` 选项: + +```shell +kubectl delete pods --grace-period=0 +``` + +如果在这些命令后 pod 仍处于`Unknown`状态,请使用以下命令从集群中删除 pod: + +```shell +kubectl patch pod -p '{"metadata":{"finalizers":null}}' +``` + + +请始终谨慎地执行强制删除 StatefulSet 类型的 pods,并完全了解所涉及地风险。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +进一步了解[调试 StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/)。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md index b4956d0d8a..573339ed3b 100644 --- a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md @@ -1,32 +1,81 @@ --- -approvers: +reviewers: - janetkuo title: 基于Replication Controller执行滚动升级 +content_template: templates/concept +weight: 80 --- - -{{< toc >}} + ## 概述 **注**: 创建副本应用的首选方法是使用[Deployment](/docs/api-reference/{{< param "version" >}}/#deployment-v1beta1-apps),Deployment使用[ReplicaSet](/docs/api-reference/{{< param "version" >}}/#replicaset-v1beta1-extensions)来进行副本控制。 更多信息, 查看[使用Deployment运行一个无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。 + + 为了在更新服务的同时不中断业务, `kubectl` 支持['滚动更新'](/docs/user-guide/kubectl/v1.6/#rolling-update),它一次更新一个pod,而不是同时停止整个服务。 有关更多信息,请参阅 [滚动更新设计文档](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) 和 [滚动更新示例](/docs/tasks/run-application/rolling-update-replication-controller/)。 + 请注意, `kubectl rolling-update` 仅支持Replication Controllers。 但是,如果使用Replication Controllers部署应用,请考虑将其切换到[Deployments](/docs/concepts/workloads/controllers/deployment/). Deployment是一种被推荐使用的更高级别的控制器,它可以对应用进行声明性的自动滚动更新。 如果您仍然希望保留您的Replication Controllers并使用 `kubectl rolling-update`进行滚动更新, 请继续往下阅读: + 滚动更新可以对replication controller所管理的Pod的配置进行变更,变更可以通过一个新的配置文件来进行,或者,如果只更新镜像,则可以直接指定新的容器镜像。 + 滚动更新的工作流程: + 1. 通过新的配置创建一个replication controller 2. 在新的控制器上增加副本数,在旧的上面减少副本数,直到副本数达到期望值 3. 删除之前的replication controller + 使用`kubectl rolling-update`命令来进行滚动更新: $ kubectl rolling-update NAME \ ([NEW_NAME] --image=IMAGE | -f FILE) + ## 通过配置文件更新 @@ -43,6 +92,25 @@ title: 基于Replication Controller执行滚动升级 * `metadata.namespace`字段必须相同 Replication Controllers的配置文件详细介绍见[创建Replication Controllers](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). + ### 示例 @@ -51,6 +119,15 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll // 将frontend-v2.json数据传到标准输入来更新frontend-v1的pods $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f - + ## 更新容器镜像 @@ -64,6 +141,28 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll 如果`IMAGE:TAG` 和当前值相同,更新就会失败。 因此,我们建议使用版本号来作为标签,而不是使用 `:latest`。从一个 `image:latest`镜像升级到一个新的 `image:latest` 镜像将会失败,即使这两个镜像不是相同的。 所以,我们不建议使用 `:latest` 来作为标签,详细信息见[最佳配置实践](/docs/concepts/configuration/overview/#container-images) 。 + ### 示例 @@ -72,6 +171,15 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll // 更新frontend的pods,不更改replication controller的名称 $ kubectl rolling-update frontend --image=image:v2 + ## 必选和可选字段 @@ -98,6 +206,46 @@ Replication Controllers的配置文件详细介绍见[创建Replication Controll * `--update-period DURATION`: 更新两个pod之间等待的时间,默认值是`1m0s`。有效单位如`--poll-interval`所述。 有关`kubectl rolling-update`命令的更多信息见[`kubectl`参考](/docs/user-guide/kubectl/v1.6/#rolling-update). + ## 实践 @@ -214,6 +362,123 @@ Scaling my-nginx-v4 up to 5 Update succeeded. Deleting old controller: my-nginx replicationcontroller "my-nginx-v4" rolling updated ``` + ## 故障分析 @@ -222,3 +487,15 @@ replicationcontroller "my-nginx-v4" rolling updated 如果更新失败,可以尝试使用同样的命令来继续更新过程。 在尝试更新之前如果需要回滚到之前的状态,可在之前的命令后面添加`--rollback=true`参数,这将回退所有的更改。 + diff --git a/content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md b/content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md new file mode 100644 index 0000000000..c2a9354e4a --- /dev/null +++ b/content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md @@ -0,0 +1,507 @@ +--- +title: 使用 kubectl patch 更新 API 对象 +description: 使用 kubectl patch 更新 Kubernetes API 对象。做一个策略性的合并 patch 或 JSON 合并 patch。 +content_template: templates/task +weight: 40 +--- + + + +{{% capture overview %}} + + + +这个任务展示了如何使用 `kubectl patch` 就地更新 API 对象。这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + + + +## 使用策略合并 patch 更新 Deployment + + + +下面是具有两个副本的 Deployment 的配置文件。每个副本是一个 Pod,有一个容器: + +{{< codenew file="application/deployment-patch.yaml" >}} + + + +创建 Deployment: + +```shell +kubectl create -f https://k8s.io/examples/application/deployment-patch.yaml +``` + + +查看与 Deployment 相关的 Pod: + +```shell +kubectl get pods +``` + + +输出显示 Deployment 有两个 Pod。`1/1` 表示每个 Pod 有一个容器: + +``` +NAME READY STATUS RESTARTS AGE +patch-demo-28633765-670qr 1/1 Running 0 23s +patch-demo-28633765-j5qs3 1/1 Running 0 23s +``` + + +把运行的 Pod 的名字记下来。稍后,您将看到这些 Pod 被终止并被新的 Pod 替换。 + + +此时,每个 Pod 都有一个运行 nginx 镜像的容器。现在假设您希望每个 Pod 有两个容器:一个运行 nginx,另一个运行 redis。 + + +创建一个名为 `patch-file-containers.yaml` 的文件。内容如下: + +```yaml +spec: + template: + spec: + containers: + - name: patch-demo-ctr-2 + image: redis +``` + + +修补您的 Deployment: + +```shell +kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)" +``` + +查看修补后的 Deployment: + +```shell +kubectl get deployment patch-demo --output yaml +``` + + +输出显示 Deployment 中的 PodSpec 有两个容器: + +```shell +containers: +- image: redis + imagePullPolicy: Always + name: patch-demo-ctr-2 + ... +- image: nginx + imagePullPolicy: Always + name: patch-demo-ctr + ... +``` + + +查看与 patch Deployment 相关的 Pod: + +```shell +kubectl get pods +``` + + +输出显示正在运行的 Pod 与以前运行的 Pod 有不同的名称。Deployment 终止了旧的 Pod,并创建了两个 +符合更新的部署规范的新 Pod。`2/2` 表示每个 Pod 有两个容器: + +``` +NAME READY STATUS RESTARTS AGE +patch-demo-1081991389-2wrn5 2/2 Running 0 1m +patch-demo-1081991389-jmg7b 2/2 Running 0 1m +``` + + +仔细查看其中一个 patch-demo Pod: + +```shell +kubectl get pod --output yaml +``` + + +输出显示 Pod 有两个容器:一个运行 nginx,一个运行 redis: + +``` +containers: +- image: redis + ... +- image: nginx + ... +``` + + + +### 策略性合并类的 patch + + +您在前面的练习中所做的 patch 称为`策略性合并 patch`。 +请注意,patch 没有替换`容器`列表。相反,它向列表中添加了一个新容器。换句话说, +patch 中的列表与现有列表合并。当您在列表中使用策略性合并 patch 时,并不总是这样。 +在某些情况下,列表是替换的,而不是合并的。 + + +对于策略性合并 patch,列表可以根据其 patch 策略进行替换或合并。patch 策略由 Kubernetes 源代码中字段标记中的 `patchStrategy` 键的值指定。 +例如,`PodSpec` 结构体的 `Containers` 字段有 `merge` 的 `patchStrategy`: + +```go +type PodSpec struct { + ... + Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...` +``` + + + +您还可以在 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json) +规范中看到 patch 策略: + +```json +"io.k8s.api.core.v1.PodSpec": { + ... + "containers": { + "description": "List of containers belonging to the pod. ... + }, + "x-kubernetes-patch-merge-key": "name", + "x-kubernetes-patch-strategy": "merge" + }, +``` + + +您可以在 [Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +中看到 patch 策略 + + +创建一个名为 `patch-file-tolerations.yaml` 的文件。内容如下: + +```yaml +spec: + template: + spec: + tolerations: + - effect: NoSchedule + key: disktype + value: ssd +``` + + +patch Deployment: + +```shell +kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)" +``` + + +查看 patch Deployment: + +```shell +kubectl get deployment patch-demo --output yaml +``` + + +输出结果显示部署中的 PodSpec 只有一个默认: + +```shell +tolerations: + - effect: NoSchedule + key: disktype + value: ssd +``` + + +请注意,PodSpec 中的 `tolerations` 列表被替换,而不是合并。这是因为 PodSpec 的 tolerance 字段的字段标签中没有 +`patchStrategy` 键。所以策略合并 patch 使用默认的 patch 策略,也就是 `replace`。 + +```go +type PodSpec struct { + ... + Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"` +``` + + +## 使用 JSON 合并 patch 更新部署 + + +策略性合并 patch 不同于 [JSON 合并 patch](https://tools.ietf.org/html/rfc7386)。 +使用 JSON 合并 patch,如果您想更新列表,您必须指定整个新列表。新的列表完全取代了现有的列表。 + + +`kubectl patch` 命令有一个 `type` 参数,您可以将其设置为以下值之一: + + + + + + +
Parameter valueMerge type
jsonJSON Patch, RFC 6902
mergeJSON Merge Patch, RFC 7386
strategicStrategic merge patch
+ + +有关 JSON patch 和 JSON 合并 patch 的比较,查看[ JSON patch 和 JSON 合并 patch](http://erosb.github.io/post/json-patch-vs-merge-patch/)。 + + +`type` 参数的默认值是 `strategic`。在前面的练习中,我们做了一个策略性的合并 patch。 + + +下一步,在相同的部署上执行 JSON 合并 patch。创建一个名为 `patch-file-2` 的文件。内容如下: + +```yaml +spec: + template: + spec: + containers: + - name: patch-demo-ctr-3 + image: gcr.io/google-samples/node-hello:1.0 +``` + + +在 patch 命令中,将 `type` 设置为 `merge`: + +```shell +kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)" +``` + + +查看 patch 部署: + +```shell +kubectl get deployment patch-demo --output yaml +``` + + +patch 中指定的`容器`列表只有一个容器。 +输出显示您的一个容器列表替换了现有的`容器`列表。 + +```shell +spec: + containers: + - image: gcr.io/google-samples/node-hello:1.0 + ... + name: patch-demo-ctr-3 +``` + + +列表中运行的 Pod: + +```shell +kubectl get pods +``` + + +在输出中,您可以看到已经终止了现有的 Pod,并创建了新的 Pod。`1/1` 表示每个新 Pod只运行一个容器。 + +```shell +NAME READY STATUS RESTARTS AGE +patch-demo-1307768864-69308 1/1 Running 0 1m +patch-demo-1307768864-c86dc 1/1 Running 0 1m +``` + + + +## kubectl patch 命令的其他形式 + + + `kubectl patch` 命令使用 YAML 或 JSON。它可以将 patch 作为文件,也可以直接在命令行中使用。 + + +创建一个文件名称是 `patch-file.json` 内容如下: + +```json +{ + "spec": { + "template": { + "spec": { + "containers": [ + { + "name": "patch-demo-ctr-2", + "image": "redis" + } + ] + } + } + } +} +``` + + +以下命令是相同的: + +```shell +kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" +kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis' + +kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" +kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}' +``` + + + +## 总结 + + +在本练习中,您使用 `kubectl patch` 更改部署对象的实时配置。您没有更改最初用于创建部署对象的配置文件。 +用于更新 API 对象的其他命令包括 +[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate), +[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit), +[kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace), +[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), +和 +[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply)。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + + + +* [Kubernetes 对象管理器](/docs/concepts/overview/object-management-kubectl/overview/) +* [使用命令管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-command/) +* [使用配置文件强制管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-config/) +* [使用配置文件对 Kubernetes 对象进行声明式管理](/docs/concepts/overview/object-management-kubectl/declarative-config/) + +{{% /capture %}} + + diff --git a/content/zh/docs/tasks/service-catalog/_index.md b/content/zh/docs/tasks/service-catalog/_index.md new file mode 100644 index 0000000000..e8c5c78485 --- /dev/null +++ b/content/zh/docs/tasks/service-catalog/_index.md @@ -0,0 +1,11 @@ +--- +title: "安装服务目录" +weight: 150 +--- + + diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md new file mode 100644 index 0000000000..94f5d511ff --- /dev/null +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -0,0 +1,159 @@ +--- +title: 使用 Helm 安装 Service Catalog +content_template: templates/task +--- + + +{{% capture overview %}} +{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} + + +使用 [Helm](https://helm.sh/) 在 Kubernetes 集群上安装 Service Catalog。 +要获取有关此过程的最新信息,请浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) 仓库。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* 理解 [Service Catalog](/docs/concepts/service-catalog/) 的关键概念。 +* Service Catalog 需要 Kubernetes 集群版本在 1.7 或更高版本。 +* 您必须启用 Kubernetes 集群的 DNS 功能。 + * 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}},则可能已经启用了集群 DNS。 + * 如果您正在使用 `hack/local-up-cluster.sh`,请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量,然后运行安装脚本。 +* [安装和设置 v1.7 或更高版本的 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/),确保将其配置为连接到 Kubernetes 集群。 +* 安装 v2.7.0 或更高版本的 [Helm](http://helm.sh/)。 + * 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。 + * 如果已经安装了适当版本的 Helm,请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。 + +{{% /capture %}} + +{{% capture steps %}} + +## 添加 service-catalog Helm 仓库 + + +安装 Helm 后,通过执行以下命令将 *service-catalog* Helm 存储库添加到本地计算机: + +```shell +helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com +``` + + +通过执行以下命令进行检查,以确保安装成功: + +```shell +helm search service-catalog +``` + + +如果安装成功,该命令应输出以下内容: + +``` +NAME VERSION DESCRIPTION +svc-cat/catalog 0.0.1 service-catalog API server and controller-manag... +``` + + +## 启用 RBAC + + +您的 Kubernetes 集群必须启用 RBAC,这需要您的 Tiller Pod 具有 `cluster-admin` 访问权限。 + + +如果您使用的是 Minikube,请使用以下参数运行 `minikube start` 命令: + +```shell +minikube start --extra-config=apiserver.Authorization.Mode=RBAC +``` + + +如果您使用 `hack/local-up-cluster.sh`,请使用以下值设置 `AUTHORIZATION_MODE` 环境变量: + +``` +AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O +``` + + +默认情况下,`helm init` 将 Tiller Pod 安装到 `kube-system` 命名空间,Tiller 配置为使用 `default` 服务帐户。 + +{{< note >}} + +如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数,则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的 namespace 和 ServiceAccount 名称。 +{{< /note >}} + + +配置 Tiller 以获得 `cluster-admin` 访问权限: + +```shell +kubectl create clusterrolebinding tiller-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default +``` + + +## 在 Kubernetes 集群中安装 Service Catalog + + +使用以下命令从 Helm 存储库的根目录安装 Service Catalog: + +```shell +helm install svc-cat/catalog \ + --name catalog --namespace catalog +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。 +* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md new file mode 100644 index 0000000000..706d624898 --- /dev/null +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -0,0 +1,128 @@ +--- +title: 使用 SC 安装服务目录 +reviewers: +- chenopis +content_template: templates/task +--- + + + +{{% capture overview %}} +{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} + + +使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。 +这个 CLI 工具以 `sc` 命令形式被安装在您的本地环境中。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +* 了解[服务目录](/docs/concepts/service-catalog/)的主要概念。 +* 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。 +* 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。 +* 服务目录需要 Kubernetes 1.7+ 版本。 +* [安装和设置 kubectl](/docs/tasks/tools/install-kubectl/),以便将其配置为连接到 Kubernetes v1.7+ 集群。 +* 要安装服务目录,kubectl 用户必须绑定到 *cluster-admin* 角色。为了确保这是正确的,请运行以下命令: + + kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= + +{{% /capture %}} + + +{{% capture steps %}} + +## 在本地环境中安装 `sc` + + +使用 `go get` 命令安装 `sc` CLI 工具: + +```Go +go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc +``` + + +执行上述命令后,`sc` 应被安装在 `GOPATH/bin` 目录中了。 + + +## 在 Kubernetes 集群中安装服务目录 + + +首先,检查是否已经安装了所有依赖项。运行: + +```shell +sc check +``` + + +如检查通过,应输出: + +``` +Dependency check passed. You are good to go. +``` + + +接下来,运行安装命令并指定要用于备份的 `storageclass`: + +```shell +sc install --etcd-backup-storageclass "standard" +``` + + +## 卸载服务目录 + + +如果您想使用 `sc` 工具从 Kubernetes 集群卸载服务目录,请运行: + +```shell +sc uninstall +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 查看 [服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。 +* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。 + +{{% /capture %}} diff --git a/content/zh/docs/tasks/tls/_index.md b/content/zh/docs/tasks/tls/_index.md new file mode 100755 index 0000000000..3bf0ceffca --- /dev/null +++ b/content/zh/docs/tasks/tls/_index.md @@ -0,0 +1,4 @@ +--- +title: "TLS" +weight: 100 +--- diff --git a/content/zh/docs/tasks/tools/_index.md b/content/zh/docs/tasks/tools/_index.md new file mode 100644 index 0000000000..b45ce8b48f --- /dev/null +++ b/content/zh/docs/tasks/tools/_index.md @@ -0,0 +1,11 @@ +--- +title: "安装工具" +weight: 10 +--- + + diff --git a/content/zh/docs/tasks/tools/install-kubectl.md b/content/zh/docs/tasks/tools/install-kubectl.md new file mode 100644 index 0000000000..5fa6d426e8 --- /dev/null +++ b/content/zh/docs/tasks/tools/install-kubectl.md @@ -0,0 +1,703 @@ +--- +reviewers: +- bgrant0607 +- mikedanese +title: 安装并设置 kubectl +content_template: templates/task +weight: 10 +--- + +{{% capture overview %}} + + 在 Kubernetes 上使用 Kubernetes 命令行工具 [kubectl](/docs/user-guide/kubectl/) 部署和管理应用程序。使用 kubectl,您可以检查集群资源;创建、删除和更新组件;查看您的新集群;并启动实例应用程序。 +{{% /capture %}} + +{{% capture prerequisites %}} + +您必须使用与集群小版本号差别为一的 kubectl 版本。例如,1.2版本的客户端应该与1.1版本、1.2版本和1.3版本的主节点一起使用。使用最新版本的 kubectl 有助于避免无法预料的问题。 +{{% /capture %}} + + +{{% capture steps %}} + + +## 安装 kubectl + +以下是一些安装 kubectl 的方法。 + + +## 使用本地软件包管理软件安装 kubectl 二进制文件 + +{{< tabs name="kubectl_install" >}} +{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} +sudo apt-get update && sudo apt-get install -y apt-transport-https +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list +sudo apt-get update +sudo apt-get install -y kubectl +{{< /tab >}} +{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat < /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 +enabled=1 +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +EOF +yum install -y kubectl +{{< /tab >}} +{{< /tabs >}} + + + +## 在 Ubuntu 上使用 snap 安装 kubectl + +如果您使用的是 Ubuntu 或其他支持 [snap](https://snapcraft.io/docs/core/install) 软件包管理器的Linux发行版,kubectl 可以作为一个 [snap](https://snapcraft.io/) 应用程序使用。 + +1. 切换到 snap 用户并运行安装命令: + + ``` + sudo snap install kubectl --classic + ``` + +2. 测试以确保您安装的版本是最新的: + + ``` + kubectl version + ``` + + +## 在 macOS 上用 Homebrew 安装 kubectl + +如果您使用的是 macOS 系统并使用 [Homebrew](https://brew.sh/) 包管理器,您可以通过 Homebrew 安装 kubectl。 + +1. 运行安装命令: + + ``` + brew install kubernetes-cli + ``` + +2. 测试以确保您安装的版本是最新的: + + ``` + kubectl version + ``` + + + + +## 在 macOS 上用 Macports 安装 kubectl + +如果您使用的是 macOS 系统并使用 [Macports](https://macports.org/) 包管理器,您可以通过 Macports 安装 kubectl。 + +1. 运行安装命令: + + ``` + port install kubectl + ``` + +2. 测试以确保您安装的版本是最新的: + + ``` + kubectl version + ``` + + +## 从 PSGallery 通过 Powershell 安装 kubectl + +如果您使用的是 Windows 系统并使用 [Powershell Gallery](https://www.powershellgallery.com/) 软件包管理器,您可以使用 Powershell 安装和更新 kubectl。 + +1. 运行安装命令(确保指定 `DownloadLocation`): + + ``` + Install-Script -Name install-kubectl -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] + ``` + + {{< note >}} + 如果你没有指定 `DownloadLocation`,那么 `kubectl` 将安装在用户的临时目录中。 + {{< /note >}} + + 安装程序创建 `$ HOME/.kube` 并指示它创建配置文件 + +2. 测试以确保您安装的版本是最新的: + ``` + kubectl version + ``` + + {{< note >}} + 通过重新运行步骤1中列出的两个命令来执行更新安装。 + {{< /note >}} + + +## 在 Windows 上用 Chocolatey 安装 kubectl + +如果您使用的是 Windows 系统并使用 [Chocolatey](https://chocolatey.org) 包管理器,您可以使用 Chocolatey 安装 kubectl。 + +1. 运行安装命令: + + ``` + choco install kubernetes-cli + ``` + +2. 测试以确保您安装的版本是最新的: + + ``` + kubectl version + ``` +3. 切换到 %HOME% 目录: + + 例如:`cd C:\users\yourusername` + +4. 创建 .kube 目录: + + ``` + mkdir .kube + ``` + +5. 切换到刚刚创建的 .kube 目录: + + ``` + cd .kube + ``` + +6. 配置 kubectl 以使用远程 Kubernetes 集群: + + ``` + New-Item config -type file + ``` + + {{< note >}} + 使用您偏爱的编辑器编辑配置文件,例如 Notepad。 + {{< /note >}} + + +## 将 kubectl 作为 Google Cloud SDK 的一部分下载 + +kubectl 可以作为 Google Cloud SDK 的一部分进行安装。 + +1. 安装 [Google Cloud SDK](https://cloud.google.com/sdk/). +2. 运行以下命令安装 `kubectl`: + + ``` + gcloud components install kubectl + ``` + +3. 测试以确保您安装的版本是最新的: + + ``` + kubectl version + ``` + + +## 通过 curl 命令安装 kubectl 可执行文件 + +{{< tabs name="kubectl_install_curl" >}} +{{% tab name="macOS" %}} +1. 通过以下命令下载 kubectl 的最新版本: + + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl + ``` + + 若需要下载特定版本的 kubectl,请将上述命令中的 `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 部分替换成为需要下载的 kubectl 的具体版本即可。 + + 例如,如果需要下载 {{< param "fullversion" >}} 版本在 macOS 系统上,需要使用如下命令: + + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + ``` + +2. 修改所下载的 kubectl 二进制文件为可执行模式。 + + ``` + chmod +x ./kubectl + ``` + +3. 将 kubectl 可执行文件放置到你的 PATH 目录下。 + + + ``` + sudo mv ./kubectl /usr/local/bin/kubectl + ``` +{{% /tab %}} +{{% tab name="Linux" %}} + +1. 通过以下命令下载 kubectl 的最新版本: + + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl + ``` + + 若需要下载特定版本的 kubectl,请将上述命令中的 `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 部分替换成为需要下载的 kubectl 的具体版本即可。 + + 例如,如果需要下载用于 Linux 的 {{< param "fullversion" >}} 版本,需要使用如下命令: + + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + ``` + +2. 修改所下载的 kubectl 二进制文件为可执行模式。 + + ``` + chmod +x ./kubectl + ``` + +3. 将 kubectl 可执行文件放置到你的 PATH 目录下。 + + ``` + sudo mv ./kubectl /usr/local/bin/kubectl + ``` +{{% /tab %}} +{{% tab name="Windows" %}} +1. 从[本链接](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)下载 kubectl 的最新版 {{< param "fullversion" >}}。 + + 或者如果您已经在系统中安装了 `curl` 工具,也可以通过以下命令下载: + + ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` + +若要查找最新的稳定版本(例如脚本等),请查看 [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). + +2. 将 kubectl 可执行文件添加到你的 PATH 目录。 +{{% /tab %}} +{{< /tabs >}} + + + + +## 配置 kubectl + +kubectl 需要一个 [kubeconfig 配置文件](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)使其找到并访问 Kubernetes 集群。当您使用 kube-up.sh 脚本创建 Kubernetes 集群或者部署 Minikube 集群时,会自动生成 kubeconfig 配置文件。请参阅[入门指南](/docs/setup/)以了解更多创建集群相关的信息。如果您需要访问一个并非由您创建的集群,请参阅[如何共享集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。默认情况下,kubectl 配置文件位于 `~/.kube/config`。 + + +## 检查 kubectl 的配置 +通过获取集群状态检查 kubectl 是否被正确配置: + +```shell +kubectl cluster-info +``` +如果您看到一个 URL 被返回,那么 kubectl 已经被正确配置,能够正常访问您的 Kubernetes 集群。 + +如果您看到类似以下的信息被返回,那么 kubectl 没有被正确配置,无法正常访问您的 Kubernetes 集群。 + +```shell +The connection to the server was refused - did you specify the right host or port? +``` + +例如,如果您打算在笔记本电脑(本地)上运行 Kubernetes 集群,则需要首先安装 minikube 等工具,然后重新运行上述命令。 + +如果 kubectl cluster-info 能够返回 url 响应,但您无法访问您的集群,可以使用下面的命令检查配置是否正确: + +```shell +kubectl cluster-info dump +``` + + +## 启用 shell 自动补全功能 + +kubectl 支持自动补全功能,可以节省大量输入! + +自动补全脚本由 kubectl 产生,您仅需要在您的 shell 配置文件中调用即可。 + +以下仅提供了使用命令补全的常用示例,更多详细信息,请查阅 `kubectl completion -h` 帮助命令的输出。 + + +### Linux 系统,使用 bash +在 CentOS Linux系统上,您可能需要安装默认情况下未安装的 bash-completion 软件包。 + +```shell +yum install bash-completion -y +``` + +执行 `source <(kubectl completion bash)` 命令在您目前正在运行的 shell 中开启 kubectl 自动补全功能。 + +可以将上述命令添加到 shell 配置文件中,这样在今后运行的 shell 中将自动开启 kubectl 自动补全: + +```shell +echo "source <(kubectl completion bash)" >> ~/.bashrc +``` + + +### macOS 系统,使用 bash +macOS 系统需要先通过 [Homebrew](https://brew.sh/) 安装 bash-completion: + +```shell +## 如果您运行的是 macOS 自带的 Bash 3.2,请运行: +brew install bash-completion +## 如果您使用的是 Bash 4.1+,请运行: +brew install bash-completion@2 +``` + +请根据 Homebrew 输出的”注意事项(caveats)”部分的内容将 bash-completion 的路径添加到本地 .bashrc 文件中。 + +如果您是按照 [Homebrew 指示](#jump)中的步骤安装的 kubectl,那么无需其他配置,kubectl 的自动补全功能已经被启用。 + +如果您是手工下载并安装的 kubectl,那么您需要将 kubectl 自动补全添加到 bash-completion: + +```shell +kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl +``` + +由于 Homebrew 项目与 Kubernetes 无关,所以并不能保证 bash-completion 总能够支持 kubectl 的自动补全功能。 + + +### 使用 Zsh +如果您使用的是 zsh,请编辑 ~/.zshrc 文件并添加以下代码以启用 kubectl 自动补全功能。 + + +```shell +if [ $commands[kubectl] ]; then + source <(kubectl completion zsh) +fi +``` + +如果您使用的是 [Oh-My-Zsh](http://ohmyz.sh/),请编辑 ~/.zshrc 文件并更新 `plugins=` 行以包含 kubectl 插件。 + +```shell +plugins=(kubectl) +``` +{{% /capture %}} + +{{% capture whatsnext %}} + +[了解如何启动并对外暴露您的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/) +{{% /capture %}} + diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md new file mode 100644 index 0000000000..5f22328883 --- /dev/null +++ b/content/zh/docs/tasks/tools/install-minikube.md @@ -0,0 +1,112 @@ +--- +title: 安装 Minikube +content_template: templates/task +weight: 20 +--- + + + +{{% capture overview %}} + +本页面讲述如何安装 Minikube。 + + +{{% /capture %}} + +{{% capture prerequisites %}} + +您的计算机必须在 BIOS 中启用 VT-x 或 AMD-v 虚拟化。 + + +{{% /capture %}} + +{{% capture steps %}} + +## 安装 Hypervisor + + +如果还没有装过 hypervisor,以下是一些不错的选择: + + + + +* macOS:[VirtualBox](https://www.virtualbox.org/wiki/Downloads) 或者 +[VMware Fusion](https://www.vmware.com/products/fusion),或者 +[HyperKit](https://github.com/moby/hyperkit)。 +* Linux:[VirtualBox](https://www.virtualbox.org/wiki/Downloads) 或者 +[KVM](http://www.linux-kvm.org/)。 + + + {{< note >}} + + Minikube 也支持 `-\-vm-driver=none` 选项,该选项在主机而非 VM 上运行 Kubernetes 组件。 + 使用这个驱动程序需要 Docker 和 linux 环境,而不需要 hypervisor。 + + + + + {{< /note >}} + +* Windows:[VirtualBox](https://www.virtualbox.org/wiki/Downloads) 或者 +[Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)。 + +## 安装 kubectl + + + + +* 请参照 [安装与设置 kubectl](/docs/tasks/tools/install-kubectl/) 中的说明安装 kubectl。 + +## 安装 Minikube + + + + +* 请参照[最新发行](https://github.com/kubernetes/minikube/releases)指导安装 Minikube。 + + + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [使用 Minikube 在本地运行 Kubernetes](/docs/getting-started-guides/minikube/) + + + +{{% /capture %}} + + diff --git a/content/zh/docs/templates/feature-state-alpha.txt b/content/zh/docs/templates/feature-state-alpha.txt new file mode 100644 index 0000000000..37b3ef9753 --- /dev/null +++ b/content/zh/docs/templates/feature-state-alpha.txt @@ -0,0 +1,7 @@ +该功能目前处于 *alpha* 状态,意味着: + +* 版本名称包含 alpha(例如 v1alpha1)。 +* 可能存在问题,启用该功能可能会暴露 bug。默认情况下被禁用。 +* 对该功能的支持可能在任何时候被取消,而不另行通知。 +* API 可能会在以后的软件版本中以不兼容的方式被更改,而不另行通知。 +* 建议仅在短期测试集群中使用该功能,这是因为使用该功能会增加出现 bug 的风险,而且缺乏长期支持。 \ No newline at end of file diff --git a/content/zh/docs/templates/feature-state-beta.txt b/content/zh/docs/templates/feature-state-beta.txt new file mode 100644 index 0000000000..34765b6e8e --- /dev/null +++ b/content/zh/docs/templates/feature-state-beta.txt @@ -0,0 +1,8 @@ +该功能目前处于 *beta* 状态,意味着: + +* 版本名称包含 beta (例如 v2beta3)。 +* 代码经过了充分测试,启用该功能被认为是安全的。默认情况下被启用。 +* 对整体功能的支持在未来不会被移除,尽管细节上可能会做更改。 +* 在后续的 beta 或稳定版本中,对象的模式、语义可能以不兼容的方式发生变化。当这种情况发生时,我们将提供迁移到下一个版本的说明。这可能需要删除、编辑和重建 API 对象,编辑过程可能需要一些思考。这可能导致依赖该功能的应用程序停机一段时间。 +* 建议仅在非业务关键场景使用该功能,因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的集群,那么您可能可以放松这个限制。 +* **请尝试使用我们的 beta 版功能,并给出反馈!在它们退出 beta 测试阶段之后,我们将很难去做更多的更改。** \ No newline at end of file diff --git a/content/zh/docs/templates/feature-state-deprecated.txt b/content/zh/docs/templates/feature-state-deprecated.txt new file mode 100644 index 0000000000..06a0a43660 --- /dev/null +++ b/content/zh/docs/templates/feature-state-deprecated.txt @@ -0,0 +1,2 @@ + +该功能已被*弃用*。有关此状态的更多信息,请参见[Kubernetes 弃用策略](/docs/reference/deprecation-policy/)。 diff --git a/content/zh/docs/templates/feature-state-stable.txt b/content/zh/docs/templates/feature-state-stable.txt new file mode 100644 index 0000000000..aa422b9f1a --- /dev/null +++ b/content/zh/docs/templates/feature-state-stable.txt @@ -0,0 +1,5 @@ + +该功能是“稳定的”,意味着: + +* 版本名是 vX,其中 X 是整数。 +* 该功能将出现在多个后续释出的软件稳定版中。 diff --git a/content/zh/docs/templates/index.md b/content/zh/docs/templates/index.md index ca03031f1e..cddc5576cc 100644 --- a/content/zh/docs/templates/index.md +++ b/content/zh/docs/templates/index.md @@ -1,3 +1,29 @@ --- headless: true + +resources: +- src: "*alpha*" + title: "alpha" +- src: "*beta*" + title: "beta" +- src: "*deprecated*" + title: "废弃" +- src: "*stable*" + title: "稳定" --- + + diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md new file mode 100644 index 0000000000..1928131edc --- /dev/null +++ b/content/zh/docs/tutorials/_index.md @@ -0,0 +1,189 @@ +--- +title: 教程 +main_menu: true +weight: 60 +content_template: templates/concept +--- + + + +{{% capture overview %}} + +Kubernetes 文档的这一部分包含教程。一个教程展示了如何完成一个比单个[任务](/docs/tasks/)更大的目标。 +通常,通常一个教程有几个部分,每个部分都有一系列步骤。在浏览每个教程之前, +您可能希望将[标准化术语表](/docs/reference/glossary/)页面添加到书签,供以后参考。 + + + +{{% /capture %}} + +{{% capture body %}} + +## 基础知识 + + + +* [Kubernetes 基础知识](/docs/tutorials/Kubernetes-Basics/)是一个深入的交互式教程,帮助您理解 Kubernetes 系统,并尝试一些基本的 Kubernetes 特性。 + + + +* [使用 Kubernetes (Udacity) 的可伸缩微服务](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) + + + +* [介绍 Kubernetes (edx)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) + + + +* [你好 Minikube](/docs/tutorials/hello-minikube/) + + + +## 配置 + + + +* [使用一个 ConfigMap 配置 Redis](/docs/tutorials/configuration/configure-redis-using-configmap/) + + + +## 无状态应用程序 + + + +* [公开外部 IP 地址访问集群中的应用程序](/docs/tutorials/stateless-application/expose-external-ip-address/) + + + +* [示例:使用 Redis 部署 PHP 留言板应用程序](/docs/tutorials/stateless-application/guestbook/) + + + +## 有状态应用程序 + + + +* [StatefulSet 基础](/docs/tutorials/stateful-application/basic-stateful-set/) + + + +* [示例:WordPress 和 MySQL 使用持久卷](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) + + + +* [示例:使用有状态集部署 Cassandra](/docs/tutorials/stateful-application/cassandra/) + + + +* [运行 ZooKeeper,CP 分布式系统](/docs/tutorials/stateful-application/zookeeper/) + + + +## CI/CD 管道 + + + +* [用 Kubernetes 第一部分:概述建立 CI/CD 管道](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) + + + +* [与 Kubernetes 中的 Jenkins Pod 一起建立 CI/CD 管道(第二部分)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) + + + +* [在 Kubernetes 上运行并扩展一个带有 CI/CD 的分布式填字游戏应用程序(第三部分)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) + + + +* [为 Kubernetes 上的分布式填字游戏应用程序设置 CI/CD (第四部分))](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) + + + +## 集群 + +* [AppArmor](/docs/tutorials/clusters/apparmor/) + + + +## 服务 + +* [使用源 IP](/docs/tutorials/services/source-ip/) + + + +{{% /capture %}} + +{{% capture whatsnext %}} + +如果您想编写教程,请参阅[使用页面模板](/docs/home/contribute/page-templates/) +以获取有关教程页面类型和教程模板的信息。 + + +{{% /capture %}} + diff --git a/content/zh/docs/tutorials/clusters/_index.md b/content/zh/docs/tutorials/clusters/_index.md new file mode 100644 index 0000000000..1909047b2d --- /dev/null +++ b/content/zh/docs/tutorials/clusters/_index.md @@ -0,0 +1,11 @@ +--- +title: "集群" +weight: 60 +--- + + diff --git a/content/zh/docs/tutorials/configuration/_index.md b/content/zh/docs/tutorials/configuration/_index.md new file mode 100644 index 0000000000..a83d20d37e --- /dev/null +++ b/content/zh/docs/tutorials/configuration/_index.md @@ -0,0 +1,11 @@ +--- +title: "配置" +weight: 30 +--- + + \ No newline at end of file diff --git a/content/zh/docs/tutorials/k8s101.md b/content/zh/docs/tutorials/k8s101.md new file mode 100644 index 0000000000..6e3abf48f0 --- /dev/null +++ b/content/zh/docs/tutorials/k8s101.md @@ -0,0 +1,296 @@ +--- +reviewers: +- eparis +- mikedanese +title: Kubernetes 101 +content_template: templates/tutorial +--- + +{{% capture overview %}} + + +关于 Kubernetes 101,我们将涵盖 kubectl, Pods, Volumes 和多个容器这些内容。 + +{{% /capture %}} + +{{% capture objectives %}} + + +* `kubectl` 是什么。 +* 管理 Pod。 +* 创建和挂载卷。 +* 在一个 Pod 中创建多个容器。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* 为了 kubectl 使用示例能正常工作,请确保您在本地有一个示例目录,可以从 [一个发行版本](https://github.com/kubernetes/kubernetes/releases) 或者最新的 `.yaml` 文件 [这里](https://github.com/kubernetes/website/tree/master/content/en/docs/tutorials) 获取。 + +{{% /capture %}} + +{{% capture lessoncontent %}} + + +## Kubectl 命令行 + +与 Kubernetes 进行交互最简单的方法就是通过 kubectl 命令行。 + +想要了解更多关于 kubectl,包括它的使用、命令和参数,查看 [kubectl 概览](/docs/reference/kubectl/overview/)。 + +想要了解更多关于 kubectl 的安装和配置,查看 [安装和设置 kubectl](/docs/tasks/tools/install-kubectl/)。 + + +## Pods + +在 Kubernetes 中,一组一个或者多个容器被称为 _Pod_ 。在一个 Pod 里的容器是在一起部署的,它们作为一组一起启动、停止和伸缩。 + +想要了解更多, 查看 [Pods](/docs/concepts/workloads/pods/pod/)。 + + +#### Pod 定义 + +最简单的 Pod 定义描述了 Deployment 中的单个容器。例如,一个 nginx web 服务器 Pod 可能被定义为: + +{{< codenew file="pods/simple-pod.yaml" >}} + +Pod 是对预期状态的声明的定义。预期状态在 Kubernetes 模型中是一个非常重要的概念。在这个系统中的很多东西都呈现为预期的状态,Kubernetes 保证现在的状态和预期的状态保持一致。例如,当您创建了一个 Pod 并且声明了将要在里面运行的容器。如果这些容器因为程序故障没有运行,Kubernetes 将继续创建或者重新创建这个 Pod 以使这个 Pod 达到期望状态。这个过程会一直持续直到您删除这个 Pod。 + +想了解更多信息,请查看 [Kubernetes Design Documents and Proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/README.md)。 + + + +#### Pod 管理 + +创建一个包含 nginx 服务器的 Pod ([simple-pod.yaml](/examples/pods/simple-pod.yaml)): + +```shell +kubectl create -f https://k8s.io/examples/pods/simple-pod.yaml +``` + + 列出所有的 Pod: + +```shell +kubectl get pods +``` + + + +对于大多数服务提供商,Pod IP 无法从外部访问。测试 Pod 是否工作的最简单方法是创建一个 busybox Pod 并且远程执行 exec 命令。有关更多信息,请参阅 [获取正在运行的容器的Shell](/docs/tasks/debug-application-cluster/get-shell-running-container/). + +如果可以访问 Pod 的 IP,则可以使用端口 80 上的 wget 访问其 http 端点: + +```shell +kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')" +u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container +u@busybox$ exit # Exit the busybox container +``` + +```shell +kubectl delete pod busybox # Clean up the pod we created with "kubectl run" +``` + + +删除一个名为 nginx 的 Pod: + +```shell +kubectl delete pod nginx +``` + + + +#### 卷 + +这对于简单的静态 Web 服务器来说非常棒,但是持久存储呢? + +容器文件系统只在容器中存在。因此,如果您的应用程序的状态需要在重定位,重新启动和崩溃中存活,您将需要配置一些持久存储。 + +在此示例中,您将创建一个具有数据卷的 Redis Pod,并将数据卷挂载到指定的路径。 + + +1. 定义一个卷: + + + ```yaml + volumes: + - name: redis-storage + emptyDir: {} + ``` + + +1. 在容器定义中定义卷挂载: + + ```yaml + volumeMounts: +  # name must match the volume name defined in volumes +  - name: redis-storage + # mount path within the container + mountPath: /data/redis + ``` + + +以下是具有持久存储卷的 Redis Pod 定义的示例 ([redis.yaml](/examples/pods/storage/redis.yaml)): + +{{< codenew file="pods/storage/redis.yaml" >}} + + + +其中: + +- `volumeMounts` `name` 是特定 `volumes` `name` 的引用。 +- `volumeMounts` `mountPath` 是在容器中挂载卷的路径。 + + +##### 卷类型 + +- **EmptyDir**: 只要 Pod 在节点上运行,就会创建一个新目录,但它可以在容器故障和重新启动之间保持不变。 +- **HostPath**: 在节点的文件系统上安装现有目录。例如 (`/var/logs`). + + +有关更多信息,请参阅 [卷](/docs/concepts/storage/volumes/). + + +#### 多个容器 + +{{< note >}} +**注意:** 以下示例在语法上是正确的,但某些镜像(例如 kubernetes/git-monitor)尚不存在。我们正在努力将这些变成可以工作的示例。 +{{< /note >}} + + +但是,通常您希望有两个不同的容器一起工作。这方面的一个例子是 Web 服务器和一个帮助程序作业,它可以轮询 git 仓库以获取更新: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: www +spec: + containers: + - name: nginx + image: nginx + volumeMounts: + - mountPath: /srv/www + name: www-data + readOnly: true + - name: git-monitor + image: kubernetes/git-monitor + env: + - name: GIT_REPO + value: http://github.com/some/repo.git + volumeMounts: + - mountPath: /data + name: www-data + volumes: + - name: www-data + emptyDir: {} +``` + + +请注意,我们在此处还添加了一个卷。在这种情况下,卷安装在两个容器中。它在 Web 服务器容器的情况下标记为 `readOnly`,因为它不需要写入目录。 + +最后,我们还向 `git-monitor` 容器引入了一个环境变量,它允许我们使用我们想要跟踪的特定 git 仓库来参数化该容器。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + +继续阅读 [Kubernetes 201](/docs/tutorials/k8s201/) 或者有关完整的应用程序,请参阅 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) + +{{% /capture %}} diff --git a/content/zh/docs/tutorials/kubernetes-basics/_index.html b/content/zh/docs/tutorials/kubernetes-basics/_index.html index 562a6094f9..5abac252ad 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/_index.html +++ b/content/zh/docs/tutorials/kubernetes-basics/_index.html @@ -35,7 +35,7 @@ linkTitle: 学习 Kubernetes 基础知识

Kubernetes 可以为您做些什么?

-

通过现代的 Web 服务,用户希望应用程序能够 24/7 全天候使用,开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包达成这些目标,使应用程序能够以简单快速的方式发布和更新,而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的时间和地点运行,并帮助应用程序找到它们需要的资源和工具。 Kubernetes 是一个可用于生产的开源平台,根据 Google 容器集群方面积累的经验,以及来自社区的最佳实践而设计。

+

通过现代的 Web 服务,用户希望应用程序能够 24/7 全天候使用,开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包达成这些目标,使应用程序能够以简单快速的方式发布和更新,而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的时间和地点运行,并帮助应用程序找到它们需要的资源和工具。 Kubernetes 是一个可用于生产的开源平台,根据 Google 容器集群方面积累的经验,以及来自社区的最佳实践而设计。

diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md new file mode 100644 index 0000000000..28ca16ffe3 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md @@ -0,0 +1,11 @@ +--- +title: 创建集群 +weight: 10 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html new file mode 100644 index 0000000000..ae0974c817 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -0,0 +1,53 @@ +--- +title: 交互式教程 - 创建集群 +weight: 20 +--- + + + + + + + + + + + + + +
+ +
+ +
+
+ + + 要与终端交互,请使用桌面/平板 + +
+
+
+ + +
+ +
+ + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/_index.md b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/_index.md new file mode 100644 index 0000000000..31eb6a0d36 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/_index.md @@ -0,0 +1,11 @@ +--- +title: 部署应用 +weight: 20 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/_index.md b/content/zh/docs/tutorials/kubernetes-basics/explore/_index.md new file mode 100644 index 0000000000..7cd33c1312 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/explore/_index.md @@ -0,0 +1,9 @@ +--- +title: 了解你的应用 +weight: 30 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html new file mode 100644 index 0000000000..f5b2f96955 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -0,0 +1,54 @@ +--- +title: 交互式教程-探索您的应用程序 +weight: 20 +--- + + + + + + + + + + + + + +
+ +
+ +
+
+ + + +
+ 要与终端交互,请使用桌面/平板 版本 +
+ +
+
+
+ + +
+ +
+ + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/_index.md b/content/zh/docs/tutorials/kubernetes-basics/expose/_index.md new file mode 100644 index 0000000000..c1325ed082 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/_index.md @@ -0,0 +1,11 @@ +--- +title: 公开地暴露你的应用 +weight: 40 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html new file mode 100644 index 0000000000..b4d6a795b8 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -0,0 +1,50 @@ +--- +title: 交互式教程 - 发布您的应用程序 +weight: 20 +--- + + + + + + + + + + + + + +
+ +
+ +
+
+ + + 要与终端交互,请使用台式机/平板电脑 + +
+
+
+
+ + +
+ +
+ + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale-intro.html index 05d1e2b47d..c0f1cc35e5 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale-intro.html @@ -26,7 +26,7 @@ title: 运行应用程序的多个实例

应用程序伸缩

-

在之前的模块中,我们创建了一个 Deployment,然后通过 Service让应用程序外部可见。 +

在之前的模块中,我们创建了一个 Deployment,然后通过 Service让应用程序外部可见。 Deployment 仅为我们的应用程序创建了一个 Pod。 当流量增加时,我们将需要扩展应用程序以跟上用户需求。

@@ -88,7 +88,7 @@ title: 运行应用程序的多个实例

扩展 Deployment 将确保创建新的 Pods 并将其调度到拥有可用资源的 Node 节点上,收缩会保证 Pods 数量减少至新的所需状态。 - Kubernetes 还支持 Pods 的 自动缩放 ,但不在本教程范围之内。收缩到零也是可以的,此时它将终止指定 Deployment 的所有 Pod。

+ Kubernetes 还支持 Pods 的 自动缩放 ,但不在本教程范围之内。收缩到零也是可以的,此时它将终止指定 Deployment 的所有 Pod。

运行应用程序的多个实例需要一种将流量分发给所有实例的方法。服务有内置的负载均衡器,可将网络流量分配给 Deployment 暴露的所有 Pods。服务通过使用 endpoints 持续监控运行的 Pods,以确保流量仅发送到可用的 Pods。

diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md b/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md new file mode 100644 index 0000000000..6f79e3fd83 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/_index.md @@ -0,0 +1,11 @@ +--- +title: 伸缩您的应用 +weight: 50 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html index aeff024382..7fbecbc8d2 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -27,10 +27,10 @@ weight: 10

扩缩应用程序

- -

在之前的模块中,我们创建了一个 Deployment,然后通过 Service让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时,我们需要扩容应用程序满足用户需求。

+

在之前的模块中,我们创建了一个 Deployment,然后通过 Service让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时,我们需要扩容应用程序满足用户需求。

扩缩 是通过改变 Deployment 中的副本数量来实现的。

@@ -95,8 +95,8 @@ weight: 10
-

扩展 Deployment 将创建新的 Pods,并将资源调度请求分配到有可用资源的节点上,收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的自动缩放,但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的,但这会终止 Deployment 上所有已经部署的 Pods。

+ autoscaling of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.

--> +

扩展 Deployment 将创建新的 Pods,并将资源调度请求分配到有可用资源的节点上,收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的自动缩放,但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的,但这会终止 Deployment 上所有已经部署的 Pods。

diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/_index.md b/content/zh/docs/tutorials/kubernetes-basics/update/_index.md new file mode 100644 index 0000000000..951286385e --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/update/_index.md @@ -0,0 +1,11 @@ +--- +title: 更新你的应用 +weight: 60 +--- + + diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html new file mode 100644 index 0000000000..0fca436e53 --- /dev/null +++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -0,0 +1,190 @@ +--- +title: 执行滚动更新 +weight: 10 +--- + + + + + + + + + + + + +
+ +
+ +
+ +
+

Objectives

+
    + +
  • 使用 kubectl 执行滚动更新。
  • +
+
+ +
+ +

更新应用程序

+ + +

用户希望应用程序始终可用,并且开发人员应该每天多次 developers 新版本的应用程序。在 Kubernetes 中,这些是通过滚动更新(Rolling Updates)完成的。 滚动更新 允许通过使用新的实例逐步更新 Pod 实例,零停机进行 Deployment 更新。新的 Pod 将在具有可用资源的节点上进行调度。

+ + +

在前面的模块中,我们将应用程序扩展为运行多个实例。这是在不影响应用程序可用性的情况下执行更新的要求。默认情况下,更新期间不可用的 pod 的最大值和可以创建的新 pod 数都是 1。这两个选项都可以配置为(pod)数字或百分比。 + 在 Kubernetes 中,更新是经过版本控制的,任何 Deployment 更新都可以恢复到以前的(稳定)版本。

+ + +
+
+
+ +

摘要:

+
    + +
  • 更新应用
  • +
+
+
+ +

滚动更新允许通过使用新的实例逐步更新 Pod 实例从而实现 Deployments 更新,停机时间为零。

+
+
+
+
+ +
+
+ +

滚动更新概述

+
+
+
+
+
+ +
+
+
+ +
+
+ +

与应用程序扩展类似,如果公开了 Deployment,服务将在更新期间仅对可用的 pod 进行负载均衡。可用 Pod 是应用程序用户可用的实例。

+ + +

滚动更新允许以下操作:

+
    + +
  • 将应用程序从一个环境提升到另一个环境(通过容器镜像更新)
  • +
  • 回滚到以前的版本
  • +
  • 持续集成和持续交付应用程序,无需停机
  • +
+ +
+
+
+ +

如果 Deployment 是公开的,则服务将仅在更新期间对可用的 pod 进行负载均衡。

+
+
+
+ +
+ +
+
+ +

在下面的交互式教程中,我们将应用程序更新为新版本,并执行回滚。

+ +
+
+
+ +
+ +
+ +
+ +
+ + + diff --git a/content/zh/docs/tutorials/object-management-kubectl/object-management.md b/content/zh/docs/tutorials/object-management-kubectl/object-management.md index 85d95adfc4..04e18e03ab 100644 --- a/content/zh/docs/tutorials/object-management-kubectl/object-management.md +++ b/content/zh/docs/tutorials/object-management-kubectl/object-management.md @@ -57,7 +57,7 @@ kubectl create deployment nginx --image nginx 在命令式对象配置中,`kubectl` 命令指定操作(创建,替换等),可选标志和至少一个文件名称。指定的文件必须包含对象的完整定义以 YAML 或 JSON 格式。 -请参阅[参考资源](https://kubernetes.io/docs/resources-reference/v1.6/) +请参阅[参考资源](/docs/resources-reference/v1.6/) 查看有关对象定义的更多细节。 **警告:** 命令式 `replace` 命令用新提供的命令替换现有资源规格,将对配置文件中缺少的对象的所有更改都丢弃。这种方法不应更新与配置文件无关的资源类型。例如,`LoadBalancer` 类型的服务使其 `externalIPs` 字段与集群的配置无关。 @@ -149,5 +149,3 @@ kubectl apply -R -f configs/ {{< comment >}} {{< /comment >}} {{% /capture %}} - - diff --git a/content/zh/docs/tutorials/online-training/_index.md b/content/zh/docs/tutorials/online-training/_index.md new file mode 100644 index 0000000000..05dd318a4b --- /dev/null +++ b/content/zh/docs/tutorials/online-training/_index.md @@ -0,0 +1,11 @@ +--- +title: "在线培训课程" +weight: 20 +--- + + diff --git a/content/zh/docs/tutorials/online-training/overview.md b/content/zh/docs/tutorials/online-training/overview.md new file mode 100644 index 0000000000..c89827186b --- /dev/null +++ b/content/zh/docs/tutorials/online-training/overview.md @@ -0,0 +1,58 @@ +--- +title: Kubernetes 在线培训概述 +content_template: templates/concept +--- + + + +{{% capture overview %}} + + +以下是一些为 Kubernetes 提供在线培训的网站: + +{{% /capture %}} + +{{% capture body %}} + + + +* [使用 Kubernetes 的可伸缩微服务(Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) + +* [Kubernetes 简介(edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) + +* [开始使用 Kubernetes(Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes) + +* [Kubernetes 实践手册(Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) + +* [使用交互式动手场景学习 Kubernetes(Katacoda)](https://www.katacoda.com/courses/kubernetes/) + +* [认证 Kubernetes 管理员预备课程(LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course) + +* [Kubernetes 坎坷路(LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) + +* [认证 Kubernetes 应用程序开发人员准备课程(KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course) + +{{% /capture %}} diff --git a/content/zh/docs/tutorials/services/_index.md b/content/zh/docs/tutorials/services/_index.md new file mode 100644 index 0000000000..a40568271b --- /dev/null +++ b/content/zh/docs/tutorials/services/_index.md @@ -0,0 +1,11 @@ +--- +title: "Services" +weight: 70 +--- + + diff --git a/content/zh/docs/tutorials/stateful-application/_index.md b/content/zh/docs/tutorials/stateful-application/_index.md new file mode 100644 index 0000000000..9c460f34bc --- /dev/null +++ b/content/zh/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,11 @@ +--- +title: "有状态的应用" +weight: 50 +--- + + diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index 025b91b9bb..95e215b2ac 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -67,7 +67,7 @@ kubectl get pods -w -l app=nginx 在另一个终端中,使用 [`kubectl create`](/docs/user-guide/kubectl/{{< param "version" >}}/#create) 来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml service "nginx" created statefulset "web" created ``` @@ -149,7 +149,7 @@ web-1 使用 [`kubectl run`](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 运行一个提供 `nslookup` 命令的容器,该命令来自于 `dnsutils` 包。通过对 Pod 的主机名执行 `nslookup`,你可以检查他们在集群内部的 DNS 地址。 ```shell -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -206,7 +206,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -433,7 +433,7 @@ Kubernetes 1.7 版本的 StatefulSet 控制器支持自动更新。更新策略 `OnDelete` 更新策略实现了传统(1.7之前)行为,它也是默认的更新策略。当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时, StatefulSet 控制器将不会自动的更新Pod。 -Patch `web` StatefulSet 的容器镜像。 +Patch `web` StatefulSet 的容器镜像。 ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' @@ -448,7 +448,7 @@ kubectl delete pod web-0 pod "web-0" deleted ``` -<-- + @@ -479,12 +479,13 @@ web-2 k8s.gcr.io/nginx-slim:0.8 ``` `web-0` 已经更新了它的镜像,但是 `web-1` 和 `web-2` 仍保留了原始镜像。 +通过删除剩余的 Pod 来完成更新。 -​```shell +```shell kubectl delete pod web-1 web-2 pod "web-1" deleted pod "web-2" deleted @@ -493,7 +494,7 @@ pod "web-2" deleted 观察 StatefulSet 的 Pod,等待它们全部变成 Running 和 Ready。 -``` +```shell kubectl get pods -w -l app=nginx NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 8m @@ -850,7 +851,7 @@ kubectl get pods -w -l app=nginx 在另一个终端里重新创建 StatefulSet。请注意,除非你删除了 `nginx` Service (你不应该这样做),你将会看到一个错误,提示 Service 已经存在。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml statefulset "web" created Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists ``` @@ -943,7 +944,7 @@ service "nginx" deleted 再一次重新创建 StatefulSet 和 Headless Service。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml service "nginx" created statefulset "web" created ``` @@ -1008,7 +1009,7 @@ kubectl get po -lapp=nginx -w 在另一个终端窗口创建清单中的 StatefulSet 和 Service。 ```shell -kubectl create -f webp.yaml +kubectl create -f webp.yaml service "nginx" created statefulset "web" created ``` @@ -1051,12 +1052,15 @@ web-2 1/1 Running 0 10s web-3 1/1 Running 0 26s ``` - + + StatefulSet 控制器启动了两个新的 Pod,而且在启动第二个之前并没有等待第一个变成 Running 和 Ready 状态。 保持这个终端打开,并在另一个终端删除 `web` StatefulSet。 @@ -1109,5 +1113,3 @@ kubectl delete svc nginx 你需要删除本教程中用到的 PersistentVolumes 的持久化存储媒体。基于你的环境、存储配置和提供方式,按照必须的步骤保证回收所有的存储。 {{% /capture %}} - - diff --git a/content/zh/docs/tutorials/stateful-application/cassandra.md b/content/zh/docs/tutorials/stateful-application/cassandra.md index 91bd0d1833..40c81dc117 100644 --- a/content/zh/docs/tutorials/stateful-application/cassandra.md +++ b/content/zh/docs/tutorials/stateful-application/cassandra.md @@ -38,7 +38,7 @@ title: “示例:使用 Stateful Sets 部署 Cassandra” ## 准备工作 -本示例假设你已经安装运行了一个 Kubernetes集群(版本 >=1.2),并且还在某个路径下安装了 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 命令行工具。请查看 [getting started guides](https://kubernetes.io/docs/getting-started-guides/) 获取关于你的平台的安装说明。 +本示例假设你已经安装运行了一个 Kubernetes集群(版本 >=1.2),并且还在某个路径下安装了 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。请查看 [getting started guides](/docs/getting-started-guides/) 获取关于你的平台的安装说明。 本示例还需要一些代码和配置文件。为了避免手动输入,你可以 `git clone` Kubernetes 源到你本地。 @@ -176,7 +176,7 @@ cassandra None 9042/TCP 45s ## 步骤2:使用 StatefulSet 创建 Cassandra Ring环 -StatefulSets(以前叫做 PetSets)特性在 Kubernetes 1.5 中升级为一个 Beta 组件。在集群环境中部署类似于 Cassandra 的有状态分布式应用是一项具有挑战性的工作。我们实现了StatefulSet,极大的简化了这个过程。本示例使用了 StatefulSet 的多个特性,但其本身超出了本文的范围。[请参考 Stateful Set 文档。](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) +StatefulSets(以前叫做 PetSets)特性在 Kubernetes 1.5 中升级为一个 Beta 组件。在集群环境中部署类似于 Cassandra 的有状态分布式应用是一项具有挑战性的工作。我们实现了StatefulSet,极大的简化了这个过程。本示例使用了 StatefulSet 的多个特性,但其本身超出了本文的范围。[请参考 Stateful Set 文档。](/docs/concepts/workloads/controllers/statefulset/) 以下是StatefulSet 的清单文件,用于创建一个由三个 pods 组成的 Cassandra ring环。 @@ -848,4 +848,3 @@ $ kubectl delete daemonset cassandra [!Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/cassandra/README.md?pixel)]() - diff --git a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index f3ff5fd631..b1301be37c 100644 --- a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -13,11 +13,11 @@ approvers: 展示的 Kubernetes 概念: -* [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) 定义持久化磁盘(磁盘生命周期不和 Pods 绑定)。 -* [Services](https://kubernetes.io/docs/concepts/services-networking/service/) 使得 Pods 能够找到其它 Pods。 -* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 对外暴露 Services。 -* [Deployments](http://kubernetes.io/docs/user-guide/deployments/) 确保 Pods 持续运行。 -* [Secrets](http://kubernetes.io/docs/user-guide/secrets/) 保存敏感密码信息。 +* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/) 定义持久化磁盘(磁盘生命周期不和 Pods 绑定)。 +* [Services](/docs/concepts/services-networking/service/) 使得 Pods 能够找到其它 Pods。 +* [External Load Balancers](/docs/concepts/services-networking/service/#type-loadbalancer) 对外暴露 Services。 +* [Deployments](/docs/user-guide/deployments/) 确保 Pods 持续运行。 +* [Secrets](/docs/user-guide/secrets/) 保存敏感密码信息。 ## 快速入门 @@ -66,18 +66,18 @@ kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/m Kubernetes本质是模块化的,可以在各种环境中运行。但并不是所有集群都相同。此处是本示例的一些要求: * 需要 1.2 版本以上的 Kubernetes,以使用更新的特性,例如 PV Claims 和 Deployments。运行 `kubectl version` 来查看你的集群版本。 * [Cluster DNS](https://github.com/kubernetes/dns) 将被用于服务发现。 -* 一个 [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 将被用于接入 WordPress。 -* 使用了 [Persistent Volume Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。你必须创建集群中需要的 Persistent Volumes。本示例将展示两种类型的 volume 的创建方法,但是任何类型的 volume 都是足够使用的。 +* 一个 [external load balancer](/docs/concepts/services-networking/service/#type-loadbalancer) 将被用于接入 WordPress。 +* 使用了 [Persistent Volume Claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。你必须创建集群中需要的 Persistent Volumes。本示例将展示两种类型的 volume 的创建方法,但是任何类型的 volume 都是足够使用的。 -查阅 [Getting Started Guide](http://kubernetes.io/docs/getting-started-guides/),搭建一个集群并安装 [kubectl](http://kubernetes.io/docs/user-guide/prereqs/) 命令行工具。 +查阅 [Getting Started Guide](/docs/getting-started-guides/),搭建一个集群并安装 [kubectl](/docs/user-guide/prereqs/) 命令行工具。 ## 决定在哪里存储你的数据 -MySQL 和 WordPress 各自使用一个 [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) 来存储自己的数据。我们将使用一个 Persistent Volume Claim 来取得一个可用的持久化存储。本示例覆盖了 HostPath 和 -GCEPersistentDisk 卷类型。你可以从两者中选择一个,或者查看 [Persistent Volumes的类型](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes)。 +MySQL 和 WordPress 各自使用一个 [Persistent Volume](/docs/concepts/storage/persistent-volumes/) 来存储自己的数据。我们将使用一个 Persistent Volume Claim 来取得一个可用的持久化存储。本示例覆盖了 HostPath 和 +GCEPersistentDisk 卷类型。你可以从两者中选择一个,或者查看 [Persistent Volumes的类型](/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes)。 ### Host Path @@ -112,7 +112,7 @@ kubectl create -f $KUBE_REPO/mysql-wordpress-pd/local-volumes.yaml ### GCE Persistent Disk -如果在 [Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/) 上运行集群,你可以使用这个存储选项。 +如果在 [Google Compute Engine](/docs/getting-started-guides/gce/) 上运行集群,你可以使用这个存储选项。 创建两个永久磁盘。你需要在和 Kubernetes 集群相同的 [GCE zone](https://cloud.google.com/compute/docs/zones) 中创建这些磁盘。默认的安装脚本将在 `us-central1-b` zone 中创建集群,就像你在 [config-default.sh](https://git.k8s.io/kubernetes/cluster/gce/config-default.sh) 文件中看到的。替换下面的 `` 为合适的 zone。`wordpress-1` 和 `wordpress-2` 的名字必须和 [gce-volumes.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/gce-volumes.yaml) 指定的 `pdName` 字段匹配。 @@ -134,7 +134,7 @@ kubectl create -f $KUBE_REPO/mysql-wordpress-pd/gce-volumes.yaml ## 创建 MySQL 密码 Secret -使用一个 [Secret](http://kubernetes.io/docs/user-guide/secrets/) 对象存储 MySQL 密码。首先,创建一个名为 `password.txt` 的文件(和 wordpress 示例文件在相同的文件夹),并且将你的密码保存于其中。请确保密码文件的结尾没有空行。如果你的编辑器添加了一个,开始的 `tr` 命令将会删除这个空行。然后,创建这个 Secret 对象。 +使用一个 [Secret](/docs/user-guide/secrets/) 对象存储 MySQL 密码。首先,创建一个名为 `password.txt` 的文件(和 wordpress 示例文件在相同的文件夹),并且将你的密码保存于其中。请确保密码文件的结尾没有空行。如果你的编辑器添加了一个,开始的 `tr` 命令将会删除这个空行。然后,创建这个 Secret 对象。 ```shell tr --delete '\n' .strippedpassword.txt && mv .strippedpassword.txt password.txt @@ -318,11 +318,10 @@ kubectl delete pv wordpress-pv-1 wordpress-pv-2 ## 接下来的步骤 -* [Introspection and Debugging](http://kubernetes.io/docs/user-guide/introspection-and-debugging/) -* [Jobs](http://kubernetes.io/docs/user-guide/jobs/) may be useful to run SQL queries. -* [Exec](http://kubernetes.io/docs/user-guide/getting-into-containers/) -* [Port Forwarding](http://kubernetes.io/docs/user-guide/connecting-to-applications-port-forward/) +* [Introspection and Debugging](/docs/user-guide/introspection-and-debugging/) +* [Jobs](/docs/user-guide/jobs/) may be useful to run SQL queries. +* [Exec](/docs/user-guide/getting-into-containers/) +* [Port Forwarding](/docs/user-guide/connecting-to-applications-port-forward/) [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/examples/mysql-wordpress-pd/README.md?pixel)]() - diff --git a/content/zh/docs/tutorials/stateless-application/_index.md b/content/zh/docs/tutorials/stateless-application/_index.md new file mode 100644 index 0000000000..83a20836eb --- /dev/null +++ b/content/zh/docs/tutorials/stateless-application/_index.md @@ -0,0 +1,11 @@ +--- +title: "无状态应用程序" +weight: 40 +--- + + diff --git a/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md new file mode 100644 index 0000000000..b22d2a365a --- /dev/null +++ b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -0,0 +1,257 @@ +--- +title: 公开外部 IP 地址以访问集群中应用程序 +content_template: templates/tutorial +weight: 10 +--- + + + +{{% capture overview %}} + + +此页面显示如何创建公开外部 IP 地址的 Kubernetes 服务对象。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + + + + * 安装 [kubectl](/docs/tasks/tools/install-kubectl/). + + * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 群集。 + 本教程创建了一个[外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/),需要云供应商。 + + * 配置 `kubectl` 与 Kubernetes API 服务器通信。有关说明,请参阅云供应商文档。 + +{{% /capture %}} + + +{{% capture objectives %}} + + + +* 运行 Hello World 应用程序的五个实例。 +* 创建一个公开外部 IP 地址的 Service 对象。 +* 使用 Service 对象访问正在运行的应用程序。 + +{{% /capture %}} + + +{{% capture lessoncontent %}} + + + +## 为一个在五个 pod 中运行的应用程序创建服务 + + +1. 在集群中运行 Hello World 应用程序: + + kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + + + 前面的命令创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) + 对象和一个关联的 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)对象。 + ReplicaSet 有五个 [Pod](/docs/concepts/workloads/pods/pod/),每个都运行 Hello World 应用程序。 + + +2. 显示有关 Deployment 的信息: + + kubectl get deployments hello-world + kubectl describe deployments hello-world + + +3. 显示有关 ReplicaSet 对象的信息: + + kubectl get replicasets + kubectl describe replicasets + + +4. 创建公开 deployment 的 Service 对象: + + kubectl expose deployment hello-world --type=LoadBalancer --name=my-service + + +5. 显示有关 Service 的信息: + + kubectl get services my-service + + + 输出类似于: + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + my-service ClusterIP 10.3.245.137 104.198.205.71 8080/TCP 54s + + + 注意:如果外部 IP 地址显示为 \,请等待一分钟再次输入相同的命令。 + + +6. 显示有关 Service 的详细信息: + + kubectl describe services my-service + + + 输出类似于: + + Name: my-service + Namespace: default + Labels: run=load-balancer-example + Annotations: + Selector: run=load-balancer-example + Type: LoadBalancer + IP: 10.3.245.137 + LoadBalancer Ingress: 104.198.205.71 + Port: 8080/TCP + NodePort: 32377/TCP + Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... + Session Affinity: None + Events: + + + 记下服务公开的外部 IP 地址(`LoadBalancer Ingress`)。 + 在本例中,外部 IP 地址是 104.198.205.71。还要注意 `Port` 和 `NodePort` 的值。 + 在本例中,`Port` 是 8080,`NodePort` 是32377。 + + + +7. 在前面的输出中,您可以看到服务有几个端点: + 10.0.0.6:8080、10.0.1.6:8080、10.0.1.7:8080 和另外两个, + 这些都是正在运行 Hello World 应用程序的 pod 的内部地址。 + 要验证这些是 pod 地址,请输入以下命令: + + kubectl get pods --output=wide + + + 输出类似于: + + NAME ... IP NODE + hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a + hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc + + +8. 使用外部 IP 地址(`LoadBalancer Ingress`)访问 Hello World 应用程序: + + curl http://: + + + 其中 `` 是您的服务的外部 IP 地址(`LoadBalancer Ingress`), + `` 是您的服务描述中的 `port` 的值。 + 如果您正在使用 minikube,输入 `minikube service my-service` 将在浏览器中自动打开 Hello World 应用程序。 + + + 成功请求的响应是一条问候消息: + + Hello Kubernetes! + +{{% /capture %}} + + +{{% capture cleanup %}} + + +要删除服务,请输入以下命令: + + kubectl delete services my-service + + +要删除正在运行 Hello World 应用程序的 Deployment,ReplicaSet 和 Pod,请输入以下命令: + + kubectl delete deployment hello-world + +{{% /capture %}} + + +{{% capture whatsnext %}} + + + +了解更多关于[将应用程序与服务连接](/docs/concepts/services-networking/connect-applications-service/)。 + +{{% /capture %}} diff --git a/content/zh/docs/tutorials/stateless-application/guestbook.md b/content/zh/docs/tutorials/stateless-application/guestbook.md new file mode 100644 index 0000000000..0dac40d655 --- /dev/null +++ b/content/zh/docs/tutorials/stateless-application/guestbook.md @@ -0,0 +1,622 @@ +--- +title: "示例:使用 Redis 部署 PHP 留言板应用程序" +reviewers: +- ahmetb +content_template: templates/tutorial +weight: 20 +--- + + + +{{% capture overview %}} + + +本教程向您展示如何使用 Kubernetes 和 [Docker](https://www.docker.com/) 构建和部署 +一个简单的多层 web 应用程序。本例由以下组件组成: + + + +* 单实例 [Redis](https://redis.io/) 主节点保存留言板条目 +* 多个[从 Redis](https://redis.io/topics/replication) 节点用来读取数据 +* 多个 web 前端实例 + + +{{% /capture %}} + +{{% capture objectives %}} + + + +* 启动 Redis 主节点。 +* 启动 Redis 从节点。 +* 启动留言板前端。 +* 公开并查看前端服务。 +* 清理。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} + +{{< version-check >}} + +{{% /capture %}} + +{{% capture lessoncontent %}} + + + +## 启动 Redis 主节点 + + +留言板应用程序使用 Redis 存储数据。它将数据写入一个 Redis 主实例,并从多个 Redis 读取数据。 + + + +### 创建 Redis 主节点的 Deployment + + +下面包含的清单文件指定了一个 Deployment 控制器,该控制器运行一个 Redis 主节点 Pod 副本。 + +{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} + + +1. 在下载清单文件的目录中启动终端窗口。 +2. 从 `redis-master-deployment.yaml` 文件中应用 Redis 主 Deployment: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + ``` + + +3. 查询 Pod 列表以验证 Redis 主节点 Pod 是否正在运行: + + ```shell + kubectl get pods + ``` + + 响应应该与此类似: + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 28s + ``` + + +4. 运行以下命令查看 Redis 主节点 Pod 中的日志: + + ```shell + kubectl logs -f POD-NAME + ``` + +{{< note >}} + + +将 POD-NAME 替换为您的 Pod 名称。 + +{{< /note >}} + + + +### 创建 Redis 主节点的服务 + + +留言板应用程序需要往 Redis 主节点中写数据。因此,需要创建 [Service](/docs/concepts/services-networking/service/) 来代理 Redis 主节点 Pod 的流量。Service 定义了访问 Pod 的策略。 + +{{< codenew file="application/guestbook/redis-master-service.yaml" >}} + + +1. 使用下面的 `redis-master-service.yaml` 文件创建 Redis 主节点的服务: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + ``` + + +2. 查询服务列表验证 Redis 主节点服务是否正在运行: + + ```shell + kubectl get service + ``` + + + 响应应该与此类似: + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 1m + redis-master ClusterIP 10.0.0.151 6379/TCP 8s + ``` + +{{< note >}} + + +这个清单文件创建了一个名为 `Redis-master` 的 Service,其中包含一组与前面定义的标签匹配的标签,因此服务将网络流量路由到 Redis 主节点 Pod 上。 + +{{< /note >}} + + + +## 启动 Redis 从节点 + + +尽管 Redis 主节点是一个单独的 pod,但是您可以通过添加 Redis 从节点的方式来使其高可用性,以满足流量需求。 + + + +### 创建 Redis 从节点 Deployment + + +Deployments 根据清单文件中设置的配置进行伸缩。在这种情况下,Deployment 对象指定两个副本。 + + +如果没有任何副本正在运行,则此 Deployment 将启动容器集群上的两个副本。相反, +如果有两个以上的副本在运行,那么它的规模就会缩小,直到运行两个副本为止。 + +{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} + + +1. 从 `redis-slave-deployment.yaml` 文件中应用 Redis Slave Deployment: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml + ``` + + +2. 查询 Pod 列表以验证 Redis Slave Pod 正在运行: + + ```shell + kubectl get pods + ``` + + + 响应应该与此类似: + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 1m + redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s + redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s + ``` + + + +### 创建 Redis 从节点的 Service + + +留言板应用程序需要从 Redis 从节点中读取数据。 +为了便于 Redis 从节点可发现, +您需要设置一个 Service。Service 为一组 Pod 提供负载均衡。 + +{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} + + +1. 从以下 `redis-slave-service.yaml` 文件应用 Redis Slave 服务: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml + ``` + + +2. 查询服务列表以验证 Redis 在服务是否正在运行: + + ```shell + kubectl get services + ``` + + + 响应应该与此类似: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 2m + redis-master ClusterIP 10.0.0.151 6379/TCP 1m + redis-slave ClusterIP 10.0.0.223 6379/TCP 6s + ``` + + + +## 设置并公开留言板前端 + + +留言板应用程序有一个 web 前端,服务于用 PHP 编写的 HTTP 请求。 +它被配置为连接到写请求的 `redis-master` 服务和读请求的 `redis-slave` 服务。 + + + +### 创建留言板前端 Deployment + +{{< codenew file="application/guestbook/frontend-deployment.yaml" >}} + + +1. 从 `frontend-deployment.yaml` 应用前端 Deployment 文件: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` + + +2. 查询 Pod 列表,验证三个前端副本是否正在运行: + + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` + + + 响应应该与此类似: + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-dsvc5 1/1 Running 0 54s + frontend-3823415956-k22zn 1/1 Running 0 54s + frontend-3823415956-w9gbt 1/1 Running 0 54s + ``` + + + +### 创建前端服务 + + +应用的 `redis-slave` 和 `redis-master` 服务只能在容器集群中访问,因为服务的默认类型是 +[ClusterIP](/docs/concepts/Services-networking/Service/#publishingservices-Service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。 + + +如果您希望客人能够访问您的留言板,您必须将前端服务配置为外部可见的,以便客户机可以从容器集群之外请求服务。Minikube 只能通过 `NodePort` 公开服务。 + +{{< note >}} + + +一些云提供商,如 Google Compute Engine 或 Google Kubernetes Engine,支持外部负载均衡器。如果您的云提供商支持负载均衡器,并且您希望使用它, +只需删除或注释掉 `type: NodePort`,并取消注释 `type: LoadBalancer` 即可。 + +{{< /note >}} + +{{< codenew file="application/guestbook/frontend-service.yaml" >}} + + +1. 从 `frontend-service.yaml` 文件中应用前端服务: + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` + + +2. 查询服务列表以验证前端服务正在运行: + + ```shell + kubectl get services + ``` + + + 响应应该与此类似: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.0.0.112 80:31323/TCP 6s + kubernetes ClusterIP 10.0.0.1 443/TCP 4m + redis-master ClusterIP 10.0.0.151 6379/TCP 2m + redis-slave ClusterIP 10.0.0.223 6379/TCP 1m + ``` + + + +### 通过 `NodePort` 查看前端服务 + + +如果您将此应用程序部署到 Minikube 或本地集群,您需要找到 IP 地址来查看您的留言板。 + + +1. 运行以下命令获取前端服务的 IP 地址。 + + ```shell + minikube service frontend --url + ``` + + + 响应应该与此类似: + + ``` + http://192.168.99.100:31323 + ``` + + +2. 复制 IP 地址,然后在浏览器中加载页面以查看留言板。 + + + +### 通过 `LoadBalancer` 查看前端服务 + + +如果您部署了 `frontend-service.yaml`。你需要找到 IP 地址来查看你的留言板。 + + +1. 运行以下命令以获取前端服务的 IP 地址。 + + ```shell + kubectl get service frontend + ``` + + + 响应应该与此类似: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` + + +2. 复制外部 IP 地址,然后在浏览器中加载页面以查看留言板。 + + + +## 扩展 Web 前端 + + +伸缩很容易是因为服务器本身被定义为使用一个 Deployment 控制器的 Service。 + + +1. 运行以下命令扩展前端 Pod 的数量: + + ```shell + kubectl scale deployment frontend --replicas=5 + ``` + + +2. 查询 Pod 列表验证正在运行的前端 Pod 的数量: + + ```shell + kubectl get pods + ``` + + + 响应应该类似于这样: + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-70qj5 1/1 Running 0 5s + frontend-3823415956-dsvc5 1/1 Running 0 54m + frontend-3823415956-k22zn 1/1 Running 0 54m + frontend-3823415956-w9gbt 1/1 Running 0 54m + frontend-3823415956-x2pld 1/1 Running 0 5s + redis-master-1068406935-3lswp 1/1 Running 0 56m + redis-slave-2005841000-fpvqc 1/1 Running 0 55m + redis-slave-2005841000-phfv9 1/1 Running 0 55m + ``` + + +3. 运行以下命令缩小前端 Pod 的数量: + + ```shell + kubectl scale deployment frontend --replicas=2 + ``` + + +4. 查询 Pod 列表验证正在运行的前端 Pod 的数量: + + ```shell + kubectl get pods + ``` + + + 响应应该类似于这样: + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-k22zn 1/1 Running 0 1h + frontend-3823415956-w9gbt 1/1 Running 0 1h + redis-master-1068406935-3lswp 1/1 Running 0 1h + redis-slave-2005841000-fpvqc 1/1 Running 0 1h + redis-slave-2005841000-phfv9 1/1 Running 0 1h + ``` + +{{% /capture %}} + +{{% capture cleanup %}} + + +删除 Deployments 和服务还会删除正在运行的 Pod。使用标签用一个命令删除多个资源。 + + +5. 运行以下命令以删除所有 Pod,Deployments 和 Services。 + + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + ``` + + + 响应应该是: + + ``` + deployment.apps "redis-master" deleted + deployment.apps "redis-slave" deleted + service "redis-master" deleted + service "redis-slave" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` + + +6. 查询 Pod 列表,确认没有 Pod 在运行: + + ```shell + kubectl get pods + ``` + + + 响应应该是: + + ``` + No resources found. + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 完成 [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) 交互式教程 +* 使用 Kubernetes 创建一个博客,使用 [MySQL 和 Wordpress 的持久卷](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) +* 阅读更多关于[连接应用程序](/docs/concepts/services-networking/connect-applications-service/) +* 阅读更多关于[管理资源](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) + +{{% /capture %}} + diff --git a/content/zh/docs/user-guide/docker-cli-to-kubectl.md b/content/zh/docs/user-guide/docker-cli-to-kubectl.md index 88bfa0d6d4..706993d4f3 100644 --- a/content/zh/docs/user-guide/docker-cli-to-kubectl.md +++ b/content/zh/docs/user-guide/docker-cli-to-kubectl.md @@ -6,11 +6,11 @@ approvers: title: Docker 用户使用 kubectl 命令指南 --- -在本文中,我们将向 docker-cli 用户介绍 Kubernetes 命令行如何与 api 进行交互。该命令行工具——kubectl,被设计成 docker-cli 用户所熟悉的样子,但是它们之间又存在一些必要的差异。该文档将向您展示每个 docker 子命令和 kubectl 与其等效的命令。 +在本文中,我们将向 docker-cli 用户介绍 Kubernetes 命令行如何与 api 进行交互。该命令行工具 —— kubectl,被设计成 docker-cli 用户所熟悉的样子,但是它们之间又存在一些必要的差异。该文档将向您展示每个 docker 子命令和 kubectl 与其等效的命令。 {{< toc >}} -#### docker run +## docker run 如何运行一个 nginx Deployment 并将其暴露出来? 查看 [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run) 。 @@ -51,7 +51,7 @@ service "nginx-http" exposed 在 kubectl 命令中,我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/),这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数,默认为 1)。我们还创建了一个 [service](/docs/user-guide/services),使用 selector 匹配具有相应的 selector 的 Deployment。查看[快速开始](/docs/user-guide/quick-start)获取更多信息。 -默认情况下镜像会在后台运行,与`docker run -d ...` 类似,如果您想在前台运行,使用: +默认情况下镜像会在后台运行,与 `docker run -d ...` 类似,如果您想在前台运行,使用: ```shell kubectl run [-i] [--tty] --attach --image= @@ -62,7 +62,7 @@ kubectl run [-i] [--tty] --attach --image= 因为我们使用 Deployment 启动了容器,如果您终止了连接到的进程(例如 `ctrl-c`),容器将会重启,这跟 `docker run -it` 不同。 如果想销毁该 Deployment(和它的 pod),您需要运行 `kubectl delete deployment `。 -#### docker ps +## docker ps 如何列出哪些正在运行?查看 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)。 @@ -82,7 +82,7 @@ NAME READY STATUS RESTARTS AGE nginx-app-5jyvm 1/1 Running 0 1h ``` -#### docker attach +## docker attach 如何连接到已经运行在容器中的进程?查看 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)。 @@ -106,7 +106,7 @@ $ kubectl attach -it nginx-app-5jyvm ... ``` -#### docker exec +## docker exec 如何在容器中执行命令?查看 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)。 @@ -148,7 +148,7 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh 更多信息请查看[获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。 -#### docker logs +## docker logs 如何查看运行中进程的 stdout/stderr?查看 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)。 @@ -178,7 +178,7 @@ $ kubectl logs --previous nginx-app-zibvs 查看[记录和监控集群活动](/docs/concepts/cluster-administration/logging/)获取更多信息。 -#### docker stop 和 docker rm +## docker stop 和 docker rm 如何停止和删除运行中的进程?查看 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)。 @@ -212,11 +212,11 @@ $ kubectl get po -l run=nginx-app 请注意,我们不直接删除 pod。使用 kubectl 命令,我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod,Deployment 将会重新创建该 pod。 -#### docker login +## docker login 在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes,请参阅[使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。 -#### docker version +## docker version 如何查看客户端和服务端的版本?查看 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)。 @@ -244,7 +244,7 @@ Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4 Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} ``` -#### docker info +## docker info 如何获取有关环境和配置的各种信息?查看 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)。 diff --git a/content/zh/docs/user-guide/jsonpath.md b/content/zh/docs/user-guide/jsonpath.md deleted file mode 100644 index e85041951c..0000000000 --- a/content/zh/docs/user-guide/jsonpath.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: JSONPath 支持 ---- - -JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。 -除了原始的 JSONPath 语法之外,我们还添加了三个函数: - -1. `$` 运算符是可选的,因为表达式默认情况下始终从根对象开始。 -2. 我们可以使用 `""` 来引用 JSONPath 表达式中的文本。 -3. 我们可以使用 `range` 运算符来迭代列表。 - -结果对象使用 String() 函数打印。 - -给定输入: - -```json -{ - "kind": "List", - "items":[ - { - "kind":"None", - "metadata":{"name":"127.0.0.1"}, - "status":{ - "capacity":{"cpu":"4"}, - "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}] - } - }, - { - "kind":"None", - "metadata":{"name":"127.0.0.2"}, - "status":{ - "capacity":{"cpu":"8"}, - "addresses":[ - {"type": "LegacyHostIP", "address":"127.0.0.2"}, - {"type": "another", "address":"127.0.0.3"} - ] - } - } - ], - "users":[ - { - "name": "myself", - "user": {} - }, - { - "name": "e2e", - "user": {"username": "admin", "password": "secret"} - } - ] -} -``` -| 函数 | 描述 | 示例 | 结果 | -| ----------------- | ---------- | ---------------------------------------- | ---------------------------------------- | -| text | 纯文本 | kind is {.kind} | kind is List | -| @ | 当前对象 | {@} | 与输入相同 | -| . or [] | 子运算符 | {.kind} 或者 {['kind']} | List | -| .. | 递归下降 | {..name} | 127.0.0.1 127.0.0.2 myself e2e | -| * | 通配符,获取所有对象 | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2] | -| [start:end :step] | 下标运算符 | {.users[0].name} | myself | -| [,] | 并集运算符 | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] | -| ?() | 过滤 | {.users[?(@.name=="e2e")].user.password} | secret | -| range, end | 迭代列表 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] | -| "" | 引用解释执行字符串 | {range .items[*]}{.metadata.name}{"\t"}{end} | 127.0.0.1 127.0.0.2 | \ No newline at end of file diff --git a/content/zh/examples/README.md b/content/zh/examples/README.md new file mode 100644 index 0000000000..dac0f47105 --- /dev/null +++ b/content/zh/examples/README.md @@ -0,0 +1,17 @@ +注意:这些测试是从 kubernetes 导入的代码实际上并不打算在存储库之外使用。 +这就导致了供应商依赖问题。因此,我们必须在 travis 配置这些行: + + +``` +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go +- cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ +- rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* +- cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ +``` diff --git a/content/zh/examples/admin/cloud/ccm-example.yaml b/content/zh/examples/admin/cloud/ccm-example.yaml new file mode 100644 index 0000000000..4c98162a70 --- /dev/null +++ b/content/zh/examples/admin/cloud/ccm-example.yaml @@ -0,0 +1,69 @@ +# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster. +# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master +# Note that this Daemonset will not work straight out of the box for your cloud, this is +# meant to be a guideline. + +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:cloud-controller-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin +subjects: +- kind: ServiceAccount + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + labels: + k8s-app: cloud-controller-manager + name: cloud-controller-manager + namespace: kube-system +spec: + selector: + matchLabels: + k8s-app: cloud-controller-manager + template: + metadata: + labels: + k8s-app: cloud-controller-manager + spec: + serviceAccountName: cloud-controller-manager + containers: + - name: cloud-controller-manager + # for in-tree providers we use k8s.gcr.io/cloud-controller-manager + # this can be replaced with any other image for out-of-tree providers + image: k8s.gcr.io/cloud-controller-manager:v1.8.0 + command: + - /usr/local/bin/cloud-controller-manager + - --cloud-provider= # Add your own cloud provider here! + - --leader-elect=true + - --use-service-account-credentials + # these flags will vary for every cloud provider + - --allocate-node-cidrs=true + - --configure-cloud-routes=true + - --cluster-cidr=172.17.0.0/16 + tolerations: + # this is required so CCM can bootstrap itself + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + # this is to have the daemonset runnable on master nodes + # the taint may vary depending on your cluster setup + - key: node-role.kubernetes.io/master + effect: NoSchedule + # this is to restrict CCM to only run on master nodes + # the node selector may vary depending on your cluster setup + nodeSelector: + node-role.kubernetes.io/master: "" diff --git a/content/zh/examples/admin/cloud/pvl-initializer-config.yaml b/content/zh/examples/admin/cloud/pvl-initializer-config.yaml new file mode 100644 index 0000000000..4a2576cc2a --- /dev/null +++ b/content/zh/examples/admin/cloud/pvl-initializer-config.yaml @@ -0,0 +1,13 @@ +kind: InitializerConfiguration +apiVersion: admissionregistration.k8s.io/v1alpha1 +metadata: + name: pvlabel.kubernetes.io +initializers: + - name: pvlabel.kubernetes.io + rules: + - apiGroups: + - "" + apiVersions: + - "*" + resources: + - persistentvolumes diff --git a/content/zh/examples/admin/dns/busybox.yaml b/content/zh/examples/admin/dns/busybox.yaml new file mode 100644 index 0000000000..31f009d307 --- /dev/null +++ b/content/zh/examples/admin/dns/busybox.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - name: busybox + image: busybox:1.28 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml new file mode 100644 index 0000000000..5e6d55a6b2 --- /dev/null +++ b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -0,0 +1,33 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: dns-autoscaler + namespace: kube-system + labels: + k8s-app: dns-autoscaler +spec: + selector: + matchLabels: + k8s-app: dns-autoscaler + template: + metadata: + labels: + k8s-app: dns-autoscaler + spec: + containers: + - name: autoscaler + image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1 + resources: + requests: + cpu: "20m" + memory: "10Mi" + command: + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=dns-autoscaler + - --target= + # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. + # If using small nodes, "nodesPerReplica" should dominate. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}} + - --logtostderr=true + - --v=2 diff --git a/content/zh/examples/admin/logging/fluentd-sidecar-config.yaml b/content/zh/examples/admin/logging/fluentd-sidecar-config.yaml new file mode 100644 index 0000000000..eea1849b03 --- /dev/null +++ b/content/zh/examples/admin/logging/fluentd-sidecar-config.yaml @@ -0,0 +1,25 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: fluentd-config +data: + fluentd.conf: | + + type tail + format none + path /var/log/1.log + pos_file /var/log/1.log.pos + tag count.format1 + + + + type tail + format none + path /var/log/2.log + pos_file /var/log/2.log.pos + tag count.format2 + + + + type google_cloud + diff --git a/content/zh/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/zh/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml new file mode 100644 index 0000000000..b37b616e6f --- /dev/null +++ b/content/zh/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-agent + image: k8s.gcr.io/fluentd-gcp:1.30 + env: + - name: FLUENTD_ARGS + value: -c /etc/fluentd-config/fluentd.conf + volumeMounts: + - name: varlog + mountPath: /var/log + - name: config-volume + mountPath: /etc/fluentd-config + volumes: + - name: varlog + emptyDir: {} + - name: config-volume + configMap: + name: fluentd-config diff --git a/content/zh/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/zh/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml new file mode 100644 index 0000000000..87bd198cfd --- /dev/null +++ b/content/zh/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-1 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-2 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/zh/examples/admin/logging/two-files-counter-pod.yaml b/content/zh/examples/admin/logging/two-files-counter-pod.yaml new file mode 100644 index 0000000000..6ebeb717a1 --- /dev/null +++ b/content/zh/examples/admin/logging/two-files-counter-pod.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml new file mode 100644 index 0000000000..88c165d144 --- /dev/null +++ b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml @@ -0,0 +1,11 @@ +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: pvc-quota-demo-2 +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 4Gi diff --git a/content/zh/examples/admin/resource/quota-objects-pvc.yaml b/content/zh/examples/admin/resource/quota-objects-pvc.yaml new file mode 100644 index 0000000000..b38256b897 --- /dev/null +++ b/content/zh/examples/admin/resource/quota-objects-pvc.yaml @@ -0,0 +1,11 @@ +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: pvc-quota-demo +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 3Gi diff --git a/content/zh/examples/admin/resource/quota-objects.yaml b/content/zh/examples/admin/resource/quota-objects.yaml new file mode 100644 index 0000000000..e97748decd --- /dev/null +++ b/content/zh/examples/admin/resource/quota-objects.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-quota-demo +spec: + hard: + persistentvolumeclaims: "1" + services.loadbalancers: "2" + services.nodeports: "0" diff --git a/content/zh/examples/admin/resource/quota-pod-deployment.yaml b/content/zh/examples/admin/resource/quota-pod-deployment.yaml new file mode 100644 index 0000000000..86e85aa468 --- /dev/null +++ b/content/zh/examples/admin/resource/quota-pod-deployment.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: pod-quota-demo +spec: + selector: + matchLabels: + purpose: quota-demo + replicas: 3 + template: + metadata: + labels: + purpose: quota-demo + spec: + containers: + - name: pod-quota-demo + image: nginx diff --git a/content/zh/examples/admin/resource/quota-pod.yaml b/content/zh/examples/admin/resource/quota-pod.yaml new file mode 100644 index 0000000000..0a07f055ca --- /dev/null +++ b/content/zh/examples/admin/resource/quota-pod.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: pod-demo +spec: + hard: + pods: "2" diff --git a/content/zh/examples/admin/sched/my-scheduler.yaml b/content/zh/examples/admin/sched/my-scheduler.yaml new file mode 100644 index 0000000000..ab0c385cd6 --- /dev/null +++ b/content/zh/examples/admin/sched/my-scheduler.yaml @@ -0,0 +1,67 @@ +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-scheduler + namespace: kube-system +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: my-scheduler-as-kube-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: kube-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + component: scheduler + tier: control-plane + name: my-scheduler + namespace: kube-system +spec: + selector: + matchLabels: + component: scheduler + tier: control-plane + replicas: 1 + template: + metadata: + labels: + component: scheduler + tier: control-plane + version: second + spec: + serviceAccountName: my-scheduler + containers: + - command: + - /usr/local/bin/kube-scheduler + - --address=0.0.0.0 + - --leader-elect=false + - --scheduler-name=my-scheduler + image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 + livenessProbe: + httpGet: + path: /healthz + port: 10251 + initialDelaySeconds: 15 + name: kube-second-scheduler + readinessProbe: + httpGet: + path: /healthz + port: 10251 + resources: + requests: + cpu: '0.1' + securityContext: + privileged: false + volumeMounts: [] + hostNetwork: false + hostPID: false + volumes: [] diff --git a/content/zh/examples/admin/sched/pod1.yaml b/content/zh/examples/admin/sched/pod1.yaml new file mode 100644 index 0000000000..560b6aa0fb --- /dev/null +++ b/content/zh/examples/admin/sched/pod1.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: no-annotation + labels: + name: multischeduler-example +spec: + containers: + - name: pod-with-no-annotation-container + image: k8s.gcr.io/pause:2.0 \ No newline at end of file diff --git a/content/zh/examples/admin/sched/pod2.yaml b/content/zh/examples/admin/sched/pod2.yaml new file mode 100644 index 0000000000..2f065efe65 --- /dev/null +++ b/content/zh/examples/admin/sched/pod2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-default-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: default-scheduler + containers: + - name: pod-with-default-annotation-container + image: k8s.gcr.io/pause:2.0 diff --git a/content/zh/examples/admin/sched/pod3.yaml b/content/zh/examples/admin/sched/pod3.yaml new file mode 100644 index 0000000000..a1b8db3200 --- /dev/null +++ b/content/zh/examples/admin/sched/pod3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-second-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: my-scheduler + containers: + - name: pod-with-second-annotation-container + image: k8s.gcr.io/pause:2.0 diff --git a/content/zh/examples/application/cassandra/cassandra-service.yaml b/content/zh/examples/application/cassandra/cassandra-service.yaml new file mode 100644 index 0000000000..31bee74b58 --- /dev/null +++ b/content/zh/examples/application/cassandra/cassandra-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + app: cassandra + name: cassandra +spec: + clusterIP: None + ports: + - port: 9042 + selector: + app: cassandra diff --git a/content/zh/examples/application/cassandra/cassandra-statefulset.yaml b/content/zh/examples/application/cassandra/cassandra-statefulset.yaml new file mode 100644 index 0000000000..a7bdbedc9c --- /dev/null +++ b/content/zh/examples/application/cassandra/cassandra-statefulset.yaml @@ -0,0 +1,100 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: cassandra + labels: + app: cassandra +spec: + serviceName: cassandra + replicas: 3 + selector: + matchLabels: + app: cassandra + template: + metadata: + labels: + app: cassandra + spec: + terminationGracePeriodSeconds: 1800 + containers: + - name: cassandra + image: gcr.io/google-samples/cassandra:v13 + imagePullPolicy: Always + ports: + - containerPort: 7000 + name: intra-node + - containerPort: 7001 + name: tls-intra-node + - containerPort: 7199 + name: jmx + - containerPort: 9042 + name: cql + resources: + limits: + cpu: "500m" + memory: 1Gi + requests: + cpu: "500m" + memory: 1Gi + securityContext: + capabilities: + add: + - IPC_LOCK + lifecycle: + preStop: + exec: + command: + - /bin/sh + - -c + - nodetool drain + env: + - name: MAX_HEAP_SIZE + value: 512M + - name: HEAP_NEWSIZE + value: 100M + - name: CASSANDRA_SEEDS + value: "cassandra-0.cassandra.default.svc.cluster.local" + - name: CASSANDRA_CLUSTER_NAME + value: "K8Demo" + - name: CASSANDRA_DC + value: "DC1-K8Demo" + - name: CASSANDRA_RACK + value: "Rack1-K8Demo" + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + readinessProbe: + exec: + command: + - /bin/bash + - -c + - /ready-probe.sh + initialDelaySeconds: 15 + timeoutSeconds: 5 + # These volume mounts are persistent. They are like inline claims, + # but not exactly because the names need to match exactly one of + # the stateful pod volumes. + volumeMounts: + - name: cassandra-data + mountPath: /cassandra_data + # These are converted to volume claims by the controller + # and mounted at the paths mentioned above. + # do not use these in production until ssd GCEPersistentDisk or other ssd pd + volumeClaimTemplates: + - metadata: + name: cassandra-data + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: fast + resources: + requests: + storage: 1Gi +--- +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: k8s.io/minikube-hostpath +parameters: + type: pd-ssd diff --git a/content/zh/examples/application/deployment-patch.yaml b/content/zh/examples/application/deployment-patch.yaml new file mode 100644 index 0000000000..7b32e2fcae --- /dev/null +++ b/content/zh/examples/application/deployment-patch.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: patch-demo +spec: + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: patch-demo-ctr + image: nginx + tolerations: + - effect: NoSchedule + key: dedicated + value: test-team diff --git a/content/zh/examples/application/deployment-scale.yaml b/content/zh/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000..3bdc7b6f5b --- /dev/null +++ b/content/zh/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Update the replicas from 2 to 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.8 + ports: + - containerPort: 80 diff --git a/content/zh/examples/application/deployment-update.yaml b/content/zh/examples/application/deployment-update.yaml new file mode 100644 index 0000000000..8c683d6dc7 --- /dev/null +++ b/content/zh/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8 + ports: + - containerPort: 80 diff --git a/content/zh/examples/application/deployment.yaml b/content/zh/examples/application/deployment.yaml new file mode 100644 index 0000000000..0f526b16c0 --- /dev/null +++ b/content/zh/examples/application/deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 # tells deployment to run 2 pods matching the template + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/zh/examples/application/guestbook/frontend-deployment.yaml b/content/zh/examples/application/guestbook/frontend-deployment.yaml new file mode 100644 index 0000000000..50d6e1f0d4 --- /dev/null +++ b/content/zh/examples/application/guestbook/frontend-deployment.yaml @@ -0,0 +1,38 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: frontend + labels: + app: guestbook +spec: + selector: + matchLabels: + app: guestbook + tier: frontend + replicas: 3 + template: + metadata: + labels: + app: guestbook + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google-samples/gb-frontend:v4 + resources: + requests: + cpu: 100m + memory: 100Mi + env: + - name: GET_HOSTS_FROM + value: dns + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead + # access an environment variable to find the master + # service's host. To do so, comment out the 'value: dns' line above, and + # uncomment the line below: + # value: env + ports: + - containerPort: 80 diff --git a/content/zh/examples/application/guestbook/frontend-service.yaml b/content/zh/examples/application/guestbook/frontend-service.yaml new file mode 100644 index 0000000000..6f283f347b --- /dev/null +++ b/content/zh/examples/application/guestbook/frontend-service.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Service +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # comment or delete the following line if you want to use a LoadBalancer + type: NodePort + # if your cluster supports it, uncomment the following to automatically create + # an external load-balanced IP for the frontend service. + # type: LoadBalancer + ports: + - port: 80 + selector: + app: guestbook + tier: frontend diff --git a/content/zh/examples/application/guestbook/redis-master-deployment.yaml b/content/zh/examples/application/guestbook/redis-master-deployment.yaml new file mode 100644 index 0000000000..fc6f418c39 --- /dev/null +++ b/content/zh/examples/application/guestbook/redis-master-deployment.yaml @@ -0,0 +1,29 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: redis-master + labels: + app: redis +spec: + selector: + matchLabels: + app: redis + role: master + tier: backend + replicas: 1 + template: + metadata: + labels: + app: redis + role: master + tier: backend + spec: + containers: + - name: master + image: k8s.gcr.io/redis:e2e # or just image: redis + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 diff --git a/content/zh/examples/application/guestbook/redis-master-service.yaml b/content/zh/examples/application/guestbook/redis-master-service.yaml new file mode 100644 index 0000000000..a484014f1f --- /dev/null +++ b/content/zh/examples/application/guestbook/redis-master-service.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis-master + labels: + app: redis + role: master + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: master + tier: backend diff --git a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml new file mode 100644 index 0000000000..ec4e48bc21 --- /dev/null +++ b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml @@ -0,0 +1,40 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: redis-slave + labels: + app: redis +spec: + selector: + matchLabels: + app: redis + role: slave + tier: backend + replicas: 2 + template: + metadata: + labels: + app: redis + role: slave + tier: backend + spec: + containers: + - name: slave + image: gcr.io/google_samples/gb-redisslave:v1 + resources: + requests: + cpu: 100m + memory: 100Mi + env: + - name: GET_HOSTS_FROM + value: dns + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead + # access an environment variable to find the master + # service's host. To do so, comment out the 'value: dns' line above, and + # uncomment the line below: + # value: env + ports: + - containerPort: 6379 diff --git a/content/zh/examples/application/guestbook/redis-slave-service.yaml b/content/zh/examples/application/guestbook/redis-slave-service.yaml new file mode 100644 index 0000000000..238fd63fb6 --- /dev/null +++ b/content/zh/examples/application/guestbook/redis-slave-service.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis-slave + labels: + app: redis + role: slave + tier: backend +spec: + ports: + - port: 6379 + selector: + app: redis + role: slave + tier: backend diff --git a/content/zh/examples/application/hpa/php-apache.yaml b/content/zh/examples/application/hpa/php-apache.yaml new file mode 100644 index 0000000000..c73ae7d631 --- /dev/null +++ b/content/zh/examples/application/hpa/php-apache.yaml @@ -0,0 +1,13 @@ +apiVersion: autoscaling/v1 +kind: HorizontalPodAutoscaler +metadata: + name: php-apache + namespace: default +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: php-apache + minReplicas: 1 + maxReplicas: 10 + targetCPUUtilizationPercentage: 50 diff --git a/content/zh/examples/application/job/job-tmpl.yaml b/content/zh/examples/application/job/job-tmpl.yaml new file mode 100644 index 0000000000..790025b38b --- /dev/null +++ b/content/zh/examples/application/job/job-tmpl.yaml @@ -0,0 +1,18 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: process-item-$ITEM + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"] + restartPolicy: Never diff --git a/content/zh/examples/application/job/job.yaml b/content/zh/examples/application/job/job.yaml new file mode 100644 index 0000000000..4e1a61892b --- /dev/null +++ b/content/zh/examples/application/job/job.yaml @@ -0,0 +1,20 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-1 +spec: + completions: 8 + parallelism: 2 + template: + metadata: + name: job-wq-1 + spec: + containers: + - name: c + image: gcr.io//job-wq-1 + env: + - name: BROKER_URL + value: amqp://guest:guest@rabbitmq-service:5672 + - name: QUEUE + value: job1 + restartPolicy: OnFailure diff --git a/content/zh/examples/application/job/rabbitmq/Dockerfile b/content/zh/examples/application/job/rabbitmq/Dockerfile new file mode 100644 index 0000000000..cbd36bb620 --- /dev/null +++ b/content/zh/examples/application/job/rabbitmq/Dockerfile @@ -0,0 +1,10 @@ +# Specify BROKER_URL and QUEUE when running +FROM ubuntu:14.04 + +RUN apt-get update && \ + apt-get install -y curl ca-certificates amqp-tools python \ + --no-install-recommends \ + && rm -rf /var/lib/apt/lists/* +COPY ./worker.py /worker.py + +CMD /usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 /worker.py diff --git a/content/zh/examples/application/job/rabbitmq/job.yaml b/content/zh/examples/application/job/rabbitmq/job.yaml new file mode 100644 index 0000000000..4e1a61892b --- /dev/null +++ b/content/zh/examples/application/job/rabbitmq/job.yaml @@ -0,0 +1,20 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-1 +spec: + completions: 8 + parallelism: 2 + template: + metadata: + name: job-wq-1 + spec: + containers: + - name: c + image: gcr.io//job-wq-1 + env: + - name: BROKER_URL + value: amqp://guest:guest@rabbitmq-service:5672 + - name: QUEUE + value: job1 + restartPolicy: OnFailure diff --git a/content/zh/examples/application/job/rabbitmq/worker.py b/content/zh/examples/application/job/rabbitmq/worker.py new file mode 100644 index 0000000000..a20884515d --- /dev/null +++ b/content/zh/examples/application/job/rabbitmq/worker.py @@ -0,0 +1,7 @@ +#!/usr/bin/env python + +# Just prints standard out and sleeps for 10 seconds. +import sys +import time +print("Processing " + sys.stdin.lines()) +time.sleep(10) diff --git a/content/zh/examples/application/job/redis/Dockerfile b/content/zh/examples/application/job/redis/Dockerfile new file mode 100644 index 0000000000..2de23b3c98 --- /dev/null +++ b/content/zh/examples/application/job/redis/Dockerfile @@ -0,0 +1,6 @@ +FROM python +RUN pip install redis +COPY ./worker.py /worker.py +COPY ./rediswq.py /rediswq.py + +CMD python worker.py diff --git a/content/zh/examples/application/job/redis/redis-pod.yaml b/content/zh/examples/application/job/redis/redis-pod.yaml new file mode 100644 index 0000000000..ae0c43a793 --- /dev/null +++ b/content/zh/examples/application/job/redis/redis-pod.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: redis-master + labels: + app: redis +spec: + containers: + - name: master + image: redis + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 diff --git a/content/zh/examples/application/job/redis/redis-service.yaml b/content/zh/examples/application/job/redis/redis-service.yaml new file mode 100644 index 0000000000..85f2ca2271 --- /dev/null +++ b/content/zh/examples/application/job/redis/redis-service.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis diff --git a/content/zh/examples/application/job/redis/rediswq.py b/content/zh/examples/application/job/redis/rediswq.py new file mode 100644 index 0000000000..ceda8bd1e3 --- /dev/null +++ b/content/zh/examples/application/job/redis/rediswq.py @@ -0,0 +1,130 @@ +#!/usr/bin/env python + +# Based on http://peter-hoffmann.com/2012/python-simple-queue-redis-queue.html +# and the suggestion in the redis documentation for RPOPLPUSH, at +# http://redis.io/commands/rpoplpush, which suggests how to implement a work-queue. + + +import redis +import uuid +import hashlib + +class RedisWQ(object): + """Simple Finite Work Queue with Redis Backend + + This work queue is finite: as long as no more work is added + after workers start, the workers can detect when the queue + is completely empty. + + The items in the work queue are assumed to have unique values. + + This object is not intended to be used by multiple threads + concurrently. + """ + def __init__(self, name, **redis_kwargs): + """The default connection parameters are: host='localhost', port=6379, db=0 + + The work queue is identified by "name". The library may create other + keys with "name" as a prefix. + """ + self._db = redis.StrictRedis(**redis_kwargs) + # The session ID will uniquely identify this "worker". + self._session = str(uuid.uuid4()) + # Work queue is implemented as two queues: main, and processing. + # Work is initially in main, and moved to processing when a client picks it up. + self._main_q_key = name + self._processing_q_key = name + ":processing" + self._lease_key_prefix = name + ":leased_by_session:" + + def sessionID(self): + """Return the ID for this session.""" + return self._session + + def _main_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._main_q_key) + + def _processing_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._processing_q_key) + + def empty(self): + """Return True if the queue is empty, including work being done, False otherwise. + + False does not necessarily mean that there is work available to work on right now, + """ + return self._main_qsize() == 0 and self._processing_qsize() == 0 + +# TODO: implement this +# def check_expired_leases(self): +# """Return to the work queueReturn True if the queue is empty, False otherwise.""" +# # Processing list should not be _too_ long since it is approximately as long +# # as the number of active and recently active workers. +# processing = self._db.lrange(self._processing_q_key, 0, -1) +# for item in processing: +# # If the lease key is not present for an item (it expired or was +# # never created because the client crashed before creating it) +# # then move the item back to the main queue so others can work on it. +# if not self._lease_exists(item): +# TODO: transactionally move the key from processing queue to +# to main queue, while detecting if a new lease is created +# or if either queue is modified. + + def _itemkey(self, item): + """Returns a string that uniquely identifies an item (bytes).""" + return hashlib.sha224(item).hexdigest() + + def _lease_exists(self, item): + """True if a lease on 'item' exists.""" + return self._db.exists(self._lease_key_prefix + self._itemkey(item)) + + def lease(self, lease_secs=60, block=True, timeout=None): + """Begin working on an item the work queue. + + Lease the item for lease_secs. After that time, other + workers may consider this client to have crashed or stalled + and pick up the item instead. + + If optional args block is true and timeout is None (the default), block + if necessary until an item is available.""" + if block: + item = self._db.brpoplpush(self._main_q_key, self._processing_q_key, timeout=timeout) + else: + item = self._db.rpoplpush(self._main_q_key, self._processing_q_key) + if item: + # Record that we (this session id) are working on a key. Expire that + # note after the lease timeout. + # Note: if we crash at this line of the program, then GC will see no lease + # for this item a later return it to the main queue. + itemkey = self._itemkey(item) + self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session) + return item + + def complete(self, value): + """Complete working on the item with 'value'. + + If the lease expired, the item may not have completed, and some + other worker may have picked it up. There is no indication + of what happened. + """ + self._db.lrem(self._processing_q_key, 0, value) + # If we crash here, then the GC code will try to move the value, but it will + # not be here, which is fine. So this does not need to be a transaction. + itemkey = self._itemkey(value) + self._db.delete(self._lease_key_prefix + itemkey, self._session) + +# TODO: add functions to clean up all keys associated with "name" when +# processing is complete. + +# TODO: add a function to add an item to the queue. Atomically +# check if the queue is empty and if so fail to add the item +# since other workers might think work is done and be in the process +# of exiting. + +# TODO(etune): move to my own github for hosting, e.g. github.com/erictune/rediswq-py and +# make it so it can be pip installed by anyone (see +# http://stackoverflow.com/questions/8247605/configuring-so-that-pip-install-can-work-from-github) + +# TODO(etune): finish code to GC expired leases, and call periodically +# e.g. each time lease times out. + diff --git a/content/zh/examples/application/job/worker.py b/content/zh/examples/application/job/worker.py new file mode 100644 index 0000000000..a20884515d --- /dev/null +++ b/content/zh/examples/application/job/worker.py @@ -0,0 +1,7 @@ +#!/usr/bin/env python + +# Just prints standard out and sleeps for 10 seconds. +import sys +import time +print("Processing " + sys.stdin.lines()) +time.sleep(10) diff --git a/content/zh/examples/application/mysql/mysql-configmap.yaml b/content/zh/examples/application/mysql/mysql-configmap.yaml new file mode 100644 index 0000000000..46d34e422c --- /dev/null +++ b/content/zh/examples/application/mysql/mysql-configmap.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: mysql + labels: + app: mysql +data: + master.cnf: | + # Apply this config only on the master. + [mysqld] + log-bin + slave.cnf: | + # Apply this config only on slaves. + [mysqld] + super-read-only + diff --git a/content/zh/examples/application/mysql/mysql-deployment.yaml b/content/zh/examples/application/mysql/mysql-deployment.yaml new file mode 100644 index 0000000000..518457777e --- /dev/null +++ b/content/zh/examples/application/mysql/mysql-deployment.yaml @@ -0,0 +1,43 @@ +apiVersion: v1 +kind: Service +metadata: + name: mysql +spec: + ports: + - port: 3306 + selector: + app: mysql + clusterIP: None +--- +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + strategy: + type: Recreate + template: + metadata: + labels: + app: mysql + spec: + containers: + - image: mysql:5.6 + name: mysql + env: + # Use secret in real usage + - name: MYSQL_ROOT_PASSWORD + value: password + ports: + - containerPort: 3306 + name: mysql + volumeMounts: + - name: mysql-persistent-storage + mountPath: /var/lib/mysql + volumes: + - name: mysql-persistent-storage + persistentVolumeClaim: + claimName: mysql-pv-claim diff --git a/content/zh/examples/application/mysql/mysql-pv.yaml b/content/zh/examples/application/mysql/mysql-pv.yaml new file mode 100644 index 0000000000..6f4e692f3b --- /dev/null +++ b/content/zh/examples/application/mysql/mysql-pv.yaml @@ -0,0 +1,26 @@ +kind: PersistentVolume +apiVersion: v1 +metadata: + name: mysql-pv-volume + labels: + type: local +spec: + storageClassName: manual + capacity: + storage: 20Gi + accessModes: + - ReadWriteOnce + hostPath: + path: "/mnt/data" +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mysql-pv-claim +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi diff --git a/content/zh/examples/application/mysql/mysql-services.yaml b/content/zh/examples/application/mysql/mysql-services.yaml new file mode 100644 index 0000000000..f538992566 --- /dev/null +++ b/content/zh/examples/application/mysql/mysql-services.yaml @@ -0,0 +1,30 @@ +# Headless service for stable DNS entries of StatefulSet members. +apiVersion: v1 +kind: Service +metadata: + name: mysql + labels: + app: mysql +spec: + ports: + - name: mysql + port: 3306 + clusterIP: None + selector: + app: mysql +--- +# Client service for connecting to any MySQL instance for reads. +# For writes, you must instead connect to the master: mysql-0.mysql. +apiVersion: v1 +kind: Service +metadata: + name: mysql-read + labels: + app: mysql +spec: + ports: + - name: mysql + port: 3306 + selector: + app: mysql + diff --git a/content/zh/examples/application/mysql/mysql-statefulset.yaml b/content/zh/examples/application/mysql/mysql-statefulset.yaml new file mode 100644 index 0000000000..e0c04007a8 --- /dev/null +++ b/content/zh/examples/application/mysql/mysql-statefulset.yaml @@ -0,0 +1,167 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + serviceName: mysql + replicas: 3 + template: + metadata: + labels: + app: mysql + spec: + initContainers: + - name: init-mysql + image: mysql:5.7 + command: + - bash + - "-c" + - | + set -ex + # Generate mysql server-id from pod ordinal index. + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + echo [mysqld] > /mnt/conf.d/server-id.cnf + # Add an offset to avoid reserved server-id=0 value. + echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf + # Copy appropriate conf.d files from config-map to emptyDir. + if [[ $ordinal -eq 0 ]]; then + cp /mnt/config-map/master.cnf /mnt/conf.d/ + else + cp /mnt/config-map/slave.cnf /mnt/conf.d/ + fi + volumeMounts: + - name: conf + mountPath: /mnt/conf.d + - name: config-map + mountPath: /mnt/config-map + - name: clone-mysql + image: gcr.io/google-samples/xtrabackup:1.0 + command: + - bash + - "-c" + - | + set -ex + # Skip the clone if data already exists. + [[ -d /var/lib/mysql/mysql ]] && exit 0 + # Skip the clone on master (ordinal index 0). + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + [[ $ordinal -eq 0 ]] && exit 0 + # Clone data from previous peer. + ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql + # Prepare the backup. + xtrabackup --prepare --target-dir=/var/lib/mysql + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + containers: + - name: mysql + image: mysql:5.7 + env: + - name: MYSQL_ALLOW_EMPTY_PASSWORD + value: "1" + ports: + - name: mysql + containerPort: 3306 + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + resources: + requests: + cpu: 500m + memory: 1Gi + livenessProbe: + exec: + command: ["mysqladmin", "ping"] + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + readinessProbe: + exec: + # Check we can execute queries over TCP (skip-networking is off). + command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] + initialDelaySeconds: 5 + periodSeconds: 2 + timeoutSeconds: 1 + - name: xtrabackup + image: gcr.io/google-samples/xtrabackup:1.0 + ports: + - name: xtrabackup + containerPort: 3307 + command: + - bash + - "-c" + - | + set -ex + cd /var/lib/mysql + + # Determine binlog position of cloned data, if any. + if [[ -f xtrabackup_slave_info ]]; then + # XtraBackup already generated a partial "CHANGE MASTER TO" query + # because we're cloning from an existing slave. + mv xtrabackup_slave_info change_master_to.sql.in + # Ignore xtrabackup_binlog_info in this case (it's useless). + rm -f xtrabackup_binlog_info + elif [[ -f xtrabackup_binlog_info ]]; then + # We're cloning directly from master. Parse binlog position. + [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 + rm xtrabackup_binlog_info + echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ + MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in + fi + + # Check if we need to complete a clone by starting replication. + if [[ -f change_master_to.sql.in ]]; then + echo "Waiting for mysqld to be ready (accepting connections)" + until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done + + echo "Initializing replication from clone position" + # In case of container restart, attempt this at-most-once. + mv change_master_to.sql.in change_master_to.sql.orig + mysql -h 127.0.0.1 < + # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log + # The /var/log directory on the host is mapped to the /var/log directory in the container + # running this instance of Fluentd and we end up collecting the file: + # /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # This results in the tag: + # var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # The record reformer is used is discard the var.log.containers prefix and + # the Docker container ID suffix and "kubernetes." is pre-pended giving the tag: + # kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr + # Tag is then parsed by google_cloud plugin and translated to the metadata, + # visible in the log viewer + + # Example: + # {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"} + + type tail + format json + time_key time + path /var/log/containers/*.log + pos_file /var/log/gcp-containers.log.pos + time_format %Y-%m-%dT%H:%M:%S.%N%Z + tag reform.* + read_from_head true + + + + type parser + format /^(?\w)(? + + + type record_reformer + enable_ruby true + tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')} + + + # Detect exceptions in the log output and forward them as one log entry. + + @type copy + + + @type prometheus + + + type counter + name logging_line_count + desc Total number of lines generated by application containers + + tag ${tag} + + + + + @type detect_exceptions + + remove_tag_prefix raw + message log + stream stream + multiline_flush_interval 5 + max_bytes 500000 + max_lines 1000 + + + system.input.conf: |- + # Example: + # Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script + + type tail + format syslog + path /var/log/startupscript.log + pos_file /var/log/gcp-startupscript.log.pos + tag startupscript + + + # Examples: + # time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json" + # time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404 + + type tail + format /^time="(?