Merge branch 'master' into release-1.13
This commit is contained in:
Jim Angel
@@ -1,3 +1,5 @@
|
||||
# See the OWNERS docs at https://go.k8s.io/owners
|
||||
|
||||
# This is the localization project for Chinese.
|
||||
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
|
||||
|
||||
|
||||
@@ -17,8 +17,8 @@ cid: "home"
|
||||
<div class="image-wrapper"><img src="https://d33wubrfki0l68.cloudfront.net/33a12d8be0bc50be4738443101616e968c7afb8f/2c641/_common-resources/images/scalable.png" alt="images/scalable.png"></div>
|
||||
<div class="content">
|
||||
|
||||
<h4>星际尺度</h4>
|
||||
<p>根据同样的原则设计，允许 Google 每周运行数十亿个容器，Kubernetes 可以在不增加您的 ops 团队的情况下进行弹性扩展。</p>
|
||||
<h4>全球规模</h4>
|
||||
<p>基于允许 Google 每周运行数十亿个容器的原则进行设计，Kubernetes 可以在不增加您的运维团队的情况下进行弹性扩展。</p>
|
||||
</div>
|
||||
</main>
|
||||
<main>
|
||||
@@ -60,7 +60,7 @@ cid: "home"
|
||||
<div>
|
||||
|
||||
<h4><a href="/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller">自我修复</a></h4>
|
||||
<p>重新启动失败的容器，在节点不可用时，替换和重新编排节点上的容器，终止不对用户定义的健康检查做出响应的容器，并且不会在客户端准备投放之前将其通告给客户端。</p>
|
||||
<p>重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-box">
|
||||
@@ -150,4 +150,4 @@ cid: "home"
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/of45hYbkIZs?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
<button id="closeButton"></button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
layout: blog
|
||||
title: '新贡献者工作坊上海站'
|
||||
date: 2018-12-05
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
title: 'New Contributor Workshop Shanghai'
|
||||
date: 2018-12-05
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Authors**: Josh Berkus (Red Hat), Yang Li (The Plant), Puja Abbassi (Giant Swarm), XiangPeng Zhao (ZTE)
|
||||
-->
|
||||
|
||||
**作者**: 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 Shanghai New Contributor Summit attendees. Photo by Jerry Zhang" >}}
|
||||
-->
|
||||
|
||||
{{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/attendees.png" caption="KubeCon 上海站新贡献者峰会与会者，摄影：Jerry Zhang" >}}
|
||||
|
||||
<!--
|
||||
We recently completed our first New Contributor Summit in China, at the first KubeCon in China. It was very exciting to see all of the Chinese and Asian developers (plus a few folks from around the world) interested in becoming contributors. Over the course of a long day, they learned how, why, and where to contribute to Kubernetes, created pull requests, attended a panel of current contributors, and got their CLAs signed.
|
||||
-->
|
||||
|
||||
最近，在中国的首次 KubeCon 上，我们完成了在中国的首次新贡献者峰会。看到所有中国和亚洲的开发者（以及来自世界各地的一些人）有兴趣成为贡献者，这令人非常兴奋。在长达一天的课程中，他们了解了如何、为什么以及在何处为 Kubernetes 作出贡献，创建了 PR，参加了贡献者圆桌讨论，并签署了他们的 CLA。
|
||||
|
||||
<!--
|
||||
This was our second New Contributor Workshop (NCW), building on the one created and led by SIG Contributor Experience members in Copenhagen. Because of the audience, it was held in both Chinese and English, taking advantage of the superb simultaneous interpretation services the CNCF sponsored. Likewise, the NCW team included both English and Chinese-speaking members of the community: Yang Li, XiangPeng Zhao, Puja Abbassi, Noah Abrahams, Tim Pepper, Zach Corleissen, Sen Lu, and Josh Berkus. In addition to presenting and helping students, the bilingual members of the team translated all of the slides into Chinese. Fifty-one students attended.
|
||||
-->
|
||||
|
||||
这是我们的第二届新贡献者工作坊（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 explains Kubernetes communications channels. Photo by Jerry Zhang" >}}
|
||||
-->
|
||||
|
||||
{{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/noahabrahams.png" caption="Noah Abrahams 讲解 Kubernetes 沟通渠道。摄影：Jerry Zhang" >}}
|
||||
|
||||
<!--
|
||||
The NCW takes participants through the stages of contributing to Kubernetes, starting from deciding where to contribute, followed by an introduction to the SIG system and our repository structure. We also have "guest speakers" from Docs and Test Infrastructure who cover contributing in those areas. We finally wind up with some hands-on exercises in filing issues and creating and approving PRs.
|
||||
-->
|
||||
|
||||
NCW 让参与者完成了为 Kubernetes 作出贡献的各个阶段，从决定在哪里作出贡献开始，接着介绍了 SIG 系统和我们的代码仓库结构。我们还有来自文档和测试基础设施领域的「客座讲者」，他们负责讲解有关的贡献。最后，我们在创建 issue、提交并批准 PR 的实践练习后，结束了工作坊。
|
||||
|
||||
<!--
|
||||
Those hands-on exercises use a repository known as [the contributor playground](https://github.com/kubernetes-sigs/contributor-playground), created by SIG Contributor Experience as a place for new contributors to try out performing various actions on a Kubernetes repo. It has modified Prow and Tide automation, uses Owners files like in the real repositories. This lets students learn how the mechanics of contributing to our repositories work without disrupting normal development.
|
||||
-->
|
||||
|
||||
这些实践练习使用一个名为[贡献者游乐场](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 talks about getting your PRs reviewed. Photo by Josh Berkus" >}}
|
||||
-->
|
||||
|
||||
{{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/yangli.png" caption="Yang Li 讲到如何让你的 PR 通过评审。摄影：Josh Berkus" >}}
|
||||
|
||||
<!--
|
||||
Both the "Great Firewall" and the language barrier prevent contributing Kubernetes from China from being straightforward. What's more, because open source business models are not mature in China, the time for employees work on open source projects is limited.
|
||||
-->
|
||||
|
||||
「防火长城」和语言障碍都使得在中国为 Kubernetes 作出贡献变得困难。而且，中国的开源商业模式并不成熟，员工在开源项目上工作的时间有限。
|
||||
|
||||
<!--
|
||||
Chinese engineers are eager to participate in the development of Kubernetes, but many of them don't know where to start since Kubernetes is such a large project. With this workshop, we hope to help those who want to contribute, whether they wish to fix some bugs they encountered, improve or localize documentation, or they need to work with Kubernetes at their work. We are glad to see more and more Chinese contributors joining the community in the past few years, and we hope to see more of them in the future.
|
||||
-->
|
||||
|
||||
中国工程师渴望参与 Kubernetes 的研发，但他们中的许多人不知道从何处开始，因为 Kubernetes 是一个如此庞大的项目。通过本次工作坊，我们希望帮助那些想要参与贡献的人，不论他们希望修复他们遇到的一些错误、改进或本地化文档，或者他们需要在工作中用到 Kubernetes。我们很高兴看到越来越多的中国贡献者在过去几年里加入社区，我们也希望将来可以看到更多。
|
||||
|
||||
<!--
|
||||
"I have been participating in the Kubernetes community for about three years," said XiangPeng Zhao. "In the community, I notice that more and more Chinese developers are showing their interest in contributing to Kubernetes. However, it's not easy to start contributing to such a project. I tried my best to help those who I met in the community, but I think there might still be some new contributors leaving the community due to not knowing where to get help when in trouble. Fortunately, the community initiated NCW at KubeCon Copenhagen and held a second one at KubeCon Shanghai. I was so excited to be invited by Josh Berkus to help organize this workshop. During the workshop, I met community friends in person, mentored attendees in the exercises, and so on. All of this was a memorable experience for me. I also learned a lot as a contributor who already has years of contributing experience. I wish I had attended such a workshop when I started contributing to Kubernetes years ago."
|
||||
-->
|
||||
|
||||
「我已经参与了 Kubernetes 社区大约三年」，XiangPeng Zhao 说，「在社区，我注意到越来越多的中国开发者表现出对 Kubernetes 贡献的兴趣。但是，开始为这样一个项目做贡献并不容易。我尽力帮助那些我在社区遇到的人，但是，我认为可能仍有一些新的贡献者离开社区，因为他们在遇到麻烦时不知道从哪里获得帮助。幸运的是，社区在 KubeCon 哥本哈根站发起了 NCW，并在 KubeCon 上海站举办了第二届。我很高兴受到 Josh Berkus 的邀请，帮助组织这个工作坊。在工作坊期间，我当面见到了社区里的朋友，在练习中指导了与会者，等等。所有这些对我来说都是难忘的经历。作为有着多年贡献者经验的我，也学习到了很多。我希望几年前我开始为 Kubernetes 做贡献时参加过这样的工作坊」。
|
||||
|
||||
<!--
|
||||
{{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/panel.png" caption="Panel of contributors. Photo by Jerry Zhang" >}}
|
||||
-->
|
||||
|
||||
{{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/panel.png" caption="贡献者圆桌讨论。摄影：Jerry Zhang" >}}
|
||||
|
||||
<!--
|
||||
The workshop ended with a panel of current contributors, featuring Lucas Käldström, Janet Kuo, Da Ma, Pengfei Ni, Zefeng Wang, and Chao Xu. The panel aimed to give both new and current contributors a look behind the scenes on the day-to-day of some of the most active contributors and maintainers, both from China and around the world. Panelists talked about where to begin your contributor's journey, but also how to interact with reviewers and maintainers. They further touched upon the main issues of contributing from China and gave attendees an outlook into exciting features they can look forward to in upcoming releases of Kubernetes.
|
||||
-->
|
||||
|
||||
工作坊以现有贡献者圆桌讨论结束，嘉宾包括 Lucas Käldström、Janet Kuo、Da Ma、Pengfei Ni、Zefeng Wang 和 Chao Xu。这场圆桌讨论旨在让新的和现有的贡献者了解一些最活跃的贡献者和维护者的幕后日常工作，不论他们来自中国还是世界各地。嘉宾们讨论了从哪里开始贡献者的旅程，以及如何与评审者和维护者进行互动。他们进一步探讨了在中国参与贡献的主要问题，并向与会者预告了在 Kubernetes 的未来版本中可以期待的令人兴奋的功能。
|
||||
|
||||
<!--
|
||||
After the workshop, XiangPeng Zhao chatted with some attendees on WeChat and Twitter about their experiences. They were very glad to have attended the NCW and had some suggestions on improving the workshop. One attendee, Mohammad, said, "I had a great time at the workshop and learned a lot about the entire process of k8s for a contributor." Another attendee, Jie Jia, said, "The workshop was wonderful. It systematically explained how to contribute to Kubernetes. The attendee could understand the process even if s/he knew nothing about that before. For those who were already contributors, they could also learn something new. Furthermore, I could make new friends from inside or outside of China in the workshop. It was awesome!"
|
||||
-->
|
||||
|
||||
工作坊结束后，XiangPeng Zhao 和一些与会者就他们的经历在微信和 Twitter 上进行了交谈。他们很高兴参加了 NCW，并就改进工作坊提出了一些建议。一位名叫 Mohammad 的与会者说：「我在工作坊上玩得很开心，学习了参与 k8s 贡献的整个过程。」另一位与会者 Jie Jia 说：「工作坊非常精彩。它系统地解释了如何为 Kubernetes 做出贡献。即使参与者之前对此一无所知，他（她）也可以理解这个过程。对于那些已经是贡献者的人，他们也可以学习到新东西。此外，我还可以在工作坊上结识来自国内外的新朋友。真是棒极了！」
|
||||
|
||||
<!--
|
||||
SIG Contributor Experience will continue to run New Contributor Workshops at each upcoming KubeCon, including Seattle, Barcelona, and the return to Shanghai in June 2019. If you failed to get into one this year, register for one at a future KubeCon. And, when you meet an NCW attendee, make sure to welcome them to the community.
|
||||
-->
|
||||
|
||||
贡献者体验 SIG 将继续在未来的 KubeCon 上举办新贡献者工作坊，包括西雅图站、巴塞罗那站，然后在 2019 年六月回到上海。如果你今年未能参加，请在未来的 KubeCon 上注册。并且，如果你遇到工作坊的与会者，请务必欢迎他们加入社区。
|
||||
|
||||
<!--
|
||||
Links:
|
||||
-->
|
||||
|
||||
链接：
|
||||
|
||||
<!--
|
||||
* English versions of the slides: [PDF](https://gist.github.com/jberkus/889be25c234b01761ce44eccff816380#file-kubernetes-shanghai-english-pdf) or [Google Docs with speaker notes](https://docs.google.com/presentation/d/1l5f_iAFsKg50LFq3N80KbZKUIEL_tyCaUoWPzSxColo/edit?usp=sharing)
|
||||
* Chinese version of the slides: [PDF](https://gist.github.com/jberkus/889be25c234b01761ce44eccff816380#file-kubernetes-shanghai-cihinese-pdf)
|
||||
* [Contributor playground](https://github.com/kubernetes-sigs/contributor-playground)
|
||||
-->
|
||||
|
||||
* 中文版幻灯片：[PDF](https://gist.github.com/jberkus/889be25c234b01761ce44eccff816380#file-kubernetes-shanghai-cihinese-pdf)
|
||||
* 英文版幻灯片：[PDF](https://gist.github.com/jberkus/889be25c234b01761ce44eccff816380#file-kubernetes-shanghai-english-pdf) 或 [带有演讲者笔记的 Google Docs](https://docs.google.com/presentation/d/1l5f_iAFsKg50LFq3N80KbZKUIEL_tyCaUoWPzSxColo/edit?usp=sharing)
|
||||
* [贡献者游乐场](https://github.com/kubernetes-sigs/contributor-playground)
|
||||
@@ -1,4 +1,3 @@
|
||||
---
|
||||
title: Home
|
||||
weight: 5
|
||||
title: 文档
|
||||
---
|
||||
|
||||
@@ -237,11 +237,12 @@ rules:
|
||||
|
||||
以下云服务供应商为自己的云部署了CCM。
|
||||
|
||||
* [Digital Ocean]()
|
||||
* [Oracle]()
|
||||
* [Azure]()
|
||||
* [GCE]()
|
||||
* [AWS]()
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
|
||||
## 群集管理
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ content_template: templates/concept
|
||||
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。
|
||||
|
||||
操作 Kubernetes 对象 —— 是否创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
|
||||
操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
|
||||
，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用
|
||||
|
||||
当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
|
||||
当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。
|
||||
**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
|
||||
**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
|
||||
`kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。
|
||||
|
||||
这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约：
|
||||
@@ -95,5 +95,3 @@ deployment "nginx-deployment" created
|
||||
|
||||
* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -398,7 +398,7 @@ $ kubectl rollout undo deployment/nginx-deployment
|
||||
deployment "nginx-deployment" rolled back
|
||||
```
|
||||
|
||||
Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
|
||||
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
|
||||
|
||||
```shell
|
||||
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
|
||||
|
||||
@@ -1,33 +1,34 @@
|
||||
---
|
||||
# title: Overview of kubeadm
|
||||
title: kubeadm概述
|
||||
title: kubeadm 概述
|
||||
weight: 10
|
||||
---
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">
|
||||
<!-- Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. -->
|
||||
Kubeadm是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建kubernetes集群的最佳实践。
|
||||
Kubeadm 是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。
|
||||
|
||||
<!-- kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. -->
|
||||
kubeadm通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是之前的节点准备工作。同样的，诸如安装各种各样的可有可无的插件，例如Kubernetes 控制面板、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
|
||||
kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是之前的节点准备工作。同样的，诸如安装各种各样值得拥有的插件，例如 Kubernetes Dashboard、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
|
||||
|
||||
<!-- Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. -->
|
||||
相反，我们期望由一个基于kubeadm从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用kubeadm作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
相反，我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
|
||||
<!-- ## What's next -->
|
||||
## 接下可以做什么
|
||||
|
||||
<!-- * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node -->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个Kubernetes主节点
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个 Kubernetes 主节点
|
||||
<!-- * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster -->
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个Kubernetes工作节点并且将其加入到集群
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个 Kubernetes 工作节点并且将其加入到集群
|
||||
<!-- * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version -->
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个Kubernetes集群到新版本
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本
|
||||
<!-- * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -->
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用kubeadm v1.7.x或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果使用 v1.7.x 或者更低版本的 kubeadm 初始化集群，您需要对集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
|
||||
* [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) to revert any changes made to this host by `kubeadm init` or `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) to print the kubeadm version -->
|
||||
* [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) to preview a set of features made available for gathering feedback from the community -->
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈
|
||||
|
||||
@@ -78,23 +78,31 @@ If these values are not unique to each node, the installation process
|
||||
may [fail](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
-->
|
||||
一般来讲，硬件设备会拥有独一无二的地址，但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一，可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。
|
||||
|
||||
<!--
|
||||
## Check network adapters
|
||||
-->
|
||||
|
||||
## 检查网络适配器
|
||||
|
||||
<!--
|
||||
If you have more than one network adapter, and your Kubernetes components are not reachable on the default
|
||||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
-->
|
||||
|
||||
如果您有一个以上的网络适配器，同时您的 Kubernetes 组件通过默认路由不可达，我们建议您预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。
|
||||
|
||||
<!--
|
||||
## Check required ports
|
||||
-->
|
||||
|
||||
## 检查所需端口
|
||||
|
||||
<!--
|
||||
### Master node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Master 节点
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
|----------|-----------|------------|-------------------------|---------------------------|
|
||||
@@ -107,6 +115,7 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
|
||||
### Worker node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Worker 节点
|
||||
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
@@ -116,6 +125,7 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
|
||||
<!--
|
||||
** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
|
||||
** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。
|
||||
|
||||
<!--
|
||||
@@ -230,6 +240,11 @@ apt-get update
|
||||
apt-get install -y kubelet kubeadm kubectl
|
||||
apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
<!--
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
-->
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```bash
|
||||
@@ -244,9 +259,6 @@ gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cl
|
||||
exclude=kube*
|
||||
EOF
|
||||
|
||||
<!--
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
-->
|
||||
# 将 SELinux 设置为 permissive 模式(将其禁用)
|
||||
setenforce 0
|
||||
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
|
||||
|
||||
@@ -133,6 +133,8 @@ In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the
|
||||
|
||||
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
|
||||
|
||||
`grep/cut` 方法实现：
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
|
||||
@@ -151,6 +153,26 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
}
|
||||
```
|
||||
|
||||
`jsonpath` 方法实现：
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The above examples use the `--insecure` flag. This leaves it subject to MITM
|
||||
attacks. When kubectl accesses the cluster it uses a stored root certificate
|
||||
|
||||
+105
-69
@@ -1,33 +1,52 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
title: 配置你的云平台防火墙
|
||||
content_template: templates/task
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
许多云服务商（比如 Google Compute Engine）定义防火墙以防止服务无意间暴露到 internet 上。
|
||||
<!--
|
||||
Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
|
||||
exposure to the internet. When exposing a service to the external world, you may need to open up
|
||||
one or more ports in these firewalls to serve traffic. This document describes this process, as
|
||||
well as any provider specific details that may be necessary.
|
||||
-->
|
||||
许多云服务提供商（比如 谷歌计算引擎）定义防火墙以防止服务无意间暴露到互联网上。
|
||||
当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。
|
||||
本文描述了这个过程，以及其他云服务商的具体信息。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
## Restrict Access For LoadBalancer Service
|
||||
-->
|
||||
## 负载均衡（LoadBalancer）服务的访问限制
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。
|
||||
这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Kubernetes Engine 和 AWS。
|
||||
如果云服务商不支持这个功能，这个字段会被忽略。
|
||||
<!--
|
||||
When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer
|
||||
by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
|
||||
This feature is currently supported on Google Compute Engine, Google Kubernetes Engine, AWS Elastic Kubernetes Service, and Azure Kubernetes Service. This field will be ignored if the cloud provider does not support the feature.
|
||||
-->
|
||||
当以 `spec.type: LoadBalancer` 方式配置服务时，你可以使用 `spec.loadBalancerSourceRanges` 来指定允许访问负载均衡器的 ip 段。
|
||||
这个字段采用 CIDR 的 IP 段， kubernetes 使用该段配置防火墙。目前只有 谷歌计算引擎，谷歌云原生引擎，亚马逊弹性原生云服务 和 微软云原生平台支持此功能。
|
||||
如果云服务提供商不支持这个功能，这个字段将被忽略。
|
||||
|
||||
|
||||
|
||||
假设 10.0.0.0/8 是内部的子网。在下面这个例子中，会创建一个只有集群内部 ip 可以访问的负载均衡器。
|
||||
集群外部的客户端是无法访问这个负载均衡器的。
|
||||
<!--
|
||||
Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
|
||||
This will not allow clients from outside of your Kubernetes cluster to access the load balancer.
|
||||
-->
|
||||
假设内部子网为假设10.0.0.0/8，在下面这个例子中，将创建一个仅能由群集内部IP访问的负载均衡器。此负载均衡器不允许来自 kubernetes 集群外部客户端的访问。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -36,17 +55,18 @@ metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
loadBalancerSourceRanges:
|
||||
- 10.0.0.0/8
|
||||
```
|
||||
|
||||
|
||||
这个例子中，会创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
|
||||
<!--
|
||||
In the following example, a load balancer will be created that is only accessible to clients with IP addresses from 130.211.204.1 and 130.211.204.2.
|
||||
-->
|
||||
在下面这个例子中，将创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -55,8 +75,8 @@ metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
@@ -64,63 +84,79 @@ spec:
|
||||
- 130.211.204.1/32
|
||||
- 130.211.204.2/32
|
||||
```
|
||||
<!--
|
||||
## Google Compute Engine
|
||||
-->
|
||||
## 谷歌计算引擎 （Google Compute Engine）
|
||||
|
||||
<!--
|
||||
When using a Service with `spec.type: LoadBalancer`, the firewall will be
|
||||
opened automatically. When using `spec.type: NodePort`, however, the firewall
|
||||
is *not* opened by default.
|
||||
-->
|
||||
当以 `spec.type: LoadBalancer` 方式配置服务时，该服务的防火墙将自动打开。
|
||||
当以 `spec.type: NodePort` 方式配置服务时，该服务的防火墙在默认情况下不会打开。
|
||||
|
||||
### 谷歌计算引擎（Google Compute Engine）
|
||||
<!--
|
||||
Google Compute Engine firewalls are documented [elsewhere](https://cloud.google.com/compute/docs/networking#firewalls_1).
|
||||
-->
|
||||
谷歌计算引擎的防火墙会进行记录 [他处] (https://cloud.google.com/compute/docs/networking#firewalls_1)。
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，防火墙会被自动打开。
|
||||
然而，当以 `spec.type: NodePort` 使用服务时，防火墙默认 *不会* 被打开。
|
||||
|
||||
|
||||
Google Compute Engine 的防火墙文档在[别处](https://cloud.google.com/compute/docs/networking#firewalls_1)。
|
||||
|
||||
|
||||
你可以使用 `gcloud` 命令行工具添加一个防火墙：
|
||||
<!--
|
||||
You can add a firewall with the `gcloud` command line tool:
|
||||
-->
|
||||
你也可以使用 gcloud 命令行工具自行添加防火墙：
|
||||
|
||||
```shell
|
||||
$ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
```
|
||||
|
||||
|
||||
|
||||
**注意**
|
||||
使用 Google Compute Engine 平台的防火墙时有一个重要的关于安全的注意点：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在 Kubernetes v1.0.0 版本，GCE 防火墙是定义按虚拟机（VM）来的，而不是按 ip 来的。
|
||||
{{< note >}}
|
||||
<!--
|
||||
GCE firewalls are defined per-vm, rather than per-ip address. This means that
|
||||
when you open a firewall for a service's ports, anything that serves on that
|
||||
port on that VM's host IP address may potentially serve traffic. Note that this
|
||||
is not a problem for other Kubernetes services, as they listen on IP addresses
|
||||
that are different than the host node's external IP address.
|
||||
-->
|
||||
GCE 防火墙是按照虚拟机来定义的，而不是通过ip地址来定义的。
|
||||
这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务
|
||||
都有被外部访问的潜在可能。注意，这对于其他 Kubernetes 服务来说不是问题，因为他们监
|
||||
听的 IP 地址与主机节点的外部 IP 地址不同。
|
||||
都有被外部访问的潜在可能。需要注意的是，对于其他的 kubernetes 服务而言，这不是问题。
|
||||
因为他们监听的ip 地址与主机节点外部的 ip 地址并不相同。
|
||||
|
||||
<!--
|
||||
Consider:
|
||||
-->
|
||||
试想一下：
|
||||
|
||||
考虑一下:
|
||||
<!--
|
||||
* You create a Service with an external load balancer (IP Address 1.2.3.4)
|
||||
and port 80
|
||||
-->
|
||||
* 你建立一个（ ip 地址为1.2.3.4）端口为80的外部负载均衡器
|
||||
|
||||
* 你创建了一个服务，使用了外部服务均衡 (IP 地址为 1.2.3.4) 和 80 端口。
|
||||
* 你在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
|
||||
<!--
|
||||
* You open the firewall for port 80 for all nodes in your cluster, so that
|
||||
the external Service actually can deliver packets to your Service
|
||||
-->
|
||||
* 因为在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
|
||||
服务发送数据包。
|
||||
* 你又在虚拟机（IP 为2.3.4.5）上使用 80 端口启动了一台 nginx 服务器.
|
||||
这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了 internet 上。
|
||||
|
||||
<!--
|
||||
* You start an nginx server, running on port 80 on the host virtual machine
|
||||
(IP Address 2.3.4.5). This nginx is also exposed to the internet on
|
||||
the VM's external IP address.
|
||||
-->
|
||||
* 最后你又虚拟机上的80端口启动 nginx 服务器（ip地址2.3.4.5）。
|
||||
这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了互联网上。
|
||||
|
||||
<!--
|
||||
Consequently, please be careful when opening firewalls in Google Compute Engine
|
||||
or Google Kubernetes Engine. You may accidentally be exposing other services to
|
||||
the wilds of the internet.
|
||||
-->
|
||||
因此请务必小心，在谷歌计算引擎或者谷歌云原生引擎中打开防火墙时，可能无意间把其他服务也暴露给了互联网。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
因此，在 Google Compute Engine 或者 Google Kubernetes Engine 上开启防火墙端口时请
|
||||
小心。你可能无意间把其他服务也暴露给了 internet。
|
||||
|
||||
|
||||
这个问题会在 Kubernetes 后续版本中被修复。
|
||||
|
||||
|
||||
### 其他云服务商
|
||||
|
||||
|
||||
即将更新
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -44,13 +44,17 @@ content_template: templates/task
|
||||
|
||||
2. 选择你的 PersistentVolumes 中的一个并更改它的回收策略：
|
||||
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
|
||||
```shell
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
这里的 `<your-pv-name>` 是你选择的 PersistentVolume 的名字。
|
||||
|
||||
3. 验证你选择的 PersistentVolume 拥有正确的策略：
|
||||
|
||||
kubectl get pv
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
输出类似于这样：
|
||||
|
||||
|
||||
@@ -40,9 +40,9 @@ metadata:
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“acme.local”: [“1.2.3.4”]}
|
||||
{"acme.local": ["1.2.3.4"]}
|
||||
upstreamNameservers: |
|
||||
[“8.8.8.8”, “8.8.4.4”]
|
||||
["8.8.8.8", "8.8.4.4"]
|
||||
```
|
||||
|
||||
|
||||
@@ -130,17 +130,15 @@ apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“consul.local”: [“10.150.0.1”]}
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{"consul.local": ["10.150.0.1"]}
|
||||
```
|
||||
|
||||
|
||||
注意，集群管理员不希望覆盖节点的上游域名服务器，所以他们不会指定可选的 `upstreamNameservers` 字段。
|
||||
|
||||
|
||||
|
||||
### 示例：上游域名服务器
|
||||
|
||||
在这个示例中，集群管理员不希望显式地强制所有非集群 DNS 查询进入到他们自己的域名服务器 172.16.0.1。
|
||||
@@ -151,10 +149,10 @@ apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
[“172.16.0.1”]
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
["172.16.0.1"]
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+27
-11
@@ -34,34 +34,48 @@ content_template: templates/task
|
||||
{{< code file="commands.yaml" >}}
|
||||
|
||||
1. 基于YAML文件创建一个Pod：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
2. List the running Pods:
|
||||
-->
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息：
|
||||
|
||||
kubectl get pods
|
||||
获取正在运行的 pod
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
查询结果显示在command-demo这个Pod下运行的容器已经启动完成
|
||||
|
||||
1. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
|
||||
3. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
|
||||
|
||||
kubectl logs command-demo
|
||||
```shell
|
||||
kubectl logs command-demo
|
||||
```
|
||||
|
||||
日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值：
|
||||
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
|
||||
|
||||
```shell
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
```
|
||||
|
||||
## 使用环境变量来设置入参
|
||||
|
||||
在上面的示例中，我们直接将一串字符作为命令的入参。除此之外，我们还可以
|
||||
将环境变量作为命令的入参。
|
||||
|
||||
```shell
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "hello world"
|
||||
command: ["/bin/echo"]
|
||||
args: ["$(MESSAGE)"]
|
||||
```
|
||||
|
||||
这样一来，我们就可以将那些用来设置环境变量的方法应用于设置命令的入参，其
|
||||
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
@@ -78,8 +92,10 @@ content_template: templates/task
|
||||
有时候，需要通过shell来执行命令。 例如，命令可能由多个命令组合而成，抑或包含
|
||||
在一个shell脚本中。这时，就可以通过如下方式在shell中执行命令：
|
||||
|
||||
```shell
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
```
|
||||
|
||||
## 注意
|
||||
|
||||
|
||||
+23
-11
@@ -30,32 +30,44 @@ content_template: templates/task
|
||||
|
||||
1. 基于YAML文件创建一个Pod:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml
|
||||
```
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息:
|
||||
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
```shell
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
```
|
||||
|
||||
查询结果应为:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
```log
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
1. 进入该Pod下的容器并打开一个命令终端:
|
||||
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```shell
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```
|
||||
|
||||
1. 在命令终端中通过执行`printenv`打印出环境变量。
|
||||
|
||||
root@envar-demo:/# printenv
|
||||
```shell
|
||||
root@envar-demo:/# printenv
|
||||
```
|
||||
|
||||
打印结果应为:
|
||||
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
```log
|
||||
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`退出命令终端。
|
||||
|
||||
|
||||
@@ -20,8 +20,10 @@ content_template: templates/task
|
||||
假设用户想要有两条 secret 数据：用户名 `my-app` 和密码
|
||||
`39528$vdg7Jb`。 首先使用 [Base64 编码](https://www.base64encode.org/) 将用户名和密码转化为 base-64 形式。 这里是一个 Linux 示例：
|
||||
|
||||
```shell
|
||||
echo -n 'my-app' | base64
|
||||
echo -n '39528$vdg7Jb' | base64
|
||||
```
|
||||
|
||||
结果显示 base-64 形式的用户名为 `bXktYXBw`，
|
||||
base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
@@ -30,26 +32,32 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
|
||||
这里是一个配置文件，可以用来创建存有用户名和密码的 Secret:
|
||||
|
||||
{{< code file="secret.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret.yaml" >}}
|
||||
|
||||
1. 创建 Secret
|
||||
|
||||
kubectl create -f secret.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**注意：** 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
|
||||
{{< /note >}}
|
||||
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```shell
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```
|
||||
|
||||
1. 查看 Secret 相关信息：
|
||||
|
||||
kubectl get secret test-secret
|
||||
|
||||
输出：
|
||||
|
||||
NAME TYPE DATA AGE
|
||||
test-secret Opaque 2 1m
|
||||
|
||||
```shell
|
||||
NAME TYPE DATA AGE
|
||||
test-secret Opaque 2 1m
|
||||
```
|
||||
|
||||
1. 查看 Secret 相关的更多详细信息：
|
||||
|
||||
@@ -57,97 +65,127 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
|
||||
输出：
|
||||
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
```shell
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
```
|
||||
|
||||
## 创建可以通过卷访问 secret 数据的 Pod
|
||||
|
||||
这里是一个可以用来创建 pod 的配置文件：
|
||||
|
||||
{{< code file="secret-pod.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret-pod.yaml" >}}
|
||||
|
||||
1. 创建 Pod：
|
||||
|
||||
kubectl create -f secret-pod.yaml
|
||||
```shell
|
||||
kubectl create -f secret-pod.yaml
|
||||
```
|
||||
|
||||
1. 确认 Pod 正在运行：
|
||||
|
||||
kubectl get pod secret-test-pod
|
||||
|
||||
```shell
|
||||
kubectl get pod secret-test-pod
|
||||
```
|
||||
|
||||
输出：
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-test-pod 1/1 Running 0 42m
|
||||
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-test-pod 1/1 Running 0 42m
|
||||
```
|
||||
|
||||
1. 在 Pod 中运行的容器中获取一个 shell：
|
||||
|
||||
kubectl exec -it secret-test-pod -- /bin/bash
|
||||
|
||||
```shell
|
||||
kubectl exec -it secret-test-pod -- /bin/bash
|
||||
```
|
||||
|
||||
1. secret 数据通过挂载在 `/etc/secret-volume` 目录下的卷暴露在容器中。
|
||||
在 shell 中，进入 secret 数据被暴露的目录：
|
||||
|
||||
root@secret-test-pod:/# cd /etc/secret-volume
|
||||
|
||||
```shell
|
||||
root@secret-test-pod:/# cd /etc/secret-volume
|
||||
```
|
||||
1. 在 shell 中，列出 `/etc/secret-volume` 目录的文件：
|
||||
|
||||
root@secret-test-pod:/etc/secret-volume# ls
|
||||
|
||||
```shell
|
||||
root@secret-test-pod:/etc/secret-volume# ls
|
||||
```
|
||||
|
||||
输出显示了两个文件，每个对应一条 secret 数据：
|
||||
|
||||
password username
|
||||
```shell
|
||||
password username
|
||||
```
|
||||
|
||||
1. 在 shell 中，显示 `username` 和 `password` 文件的内容：
|
||||
|
||||
root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
|
||||
```shell
|
||||
root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
|
||||
```
|
||||
|
||||
输出为用户名和密码：
|
||||
|
||||
my-app
|
||||
39528$vdg7Jb
|
||||
```shell
|
||||
my-app
|
||||
39528$vdg7Jb
|
||||
```
|
||||
|
||||
## 创建通过环境变量访问 secret 数据的 Pod
|
||||
|
||||
这里是一个可以用来创建 pod 的配置文件：
|
||||
|
||||
{{< code file="secret-envars-pod.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret-envars-pod.yaml" >}}
|
||||
|
||||
1. 创建 Pod：
|
||||
|
||||
kubectl create -f secret-envars-pod.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
|
||||
```
|
||||
|
||||
1. 确认 Pod 正在运行：
|
||||
|
||||
kubectl get pod secret-envars-test-pod
|
||||
|
||||
```shell
|
||||
kubectl get pod secret-envars-test-pod
|
||||
```
|
||||
|
||||
输出：
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-envars-test-pod 1/1 Running 0 4m
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-envars-test-pod 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
1. 在 Pod 中运行的容器中获取一个 shell：
|
||||
|
||||
kubectl exec -it secret-envars-test-pod -- /bin/bash
|
||||
|
||||
```shell
|
||||
kubectl exec -it secret-envars-test-pod -- /bin/bash
|
||||
```
|
||||
|
||||
1. 在 shell 中，显示环境变量：
|
||||
|
||||
root@secret-envars-test-pod:/# printenv
|
||||
|
||||
```shell
|
||||
root@secret-envars-test-pod:/# printenv
|
||||
```
|
||||
|
||||
输出包括用户名和密码：
|
||||
|
||||
...
|
||||
SECRET_USERNAME=my-app
|
||||
...
|
||||
SECRET_PASSWORD=39528$vdg7Jb
|
||||
```shell
|
||||
...
|
||||
SECRET_USERNAME=my-app
|
||||
...
|
||||
SECRET_PASSWORD=39528$vdg7Jb
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -163,5 +201,3 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
* [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
+5
-2
@@ -43,7 +43,7 @@ content_template: templates/task
|
||||
**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
{{< /note >}}
|
||||
|
||||
创建Pod：
|
||||
创建 Pod：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/cn/docs/tasks/inject-data-application/dapi-volume.yaml
|
||||
@@ -61,7 +61,10 @@ kubectl get pods
|
||||
kubectl logs kubernetes-downwardapi-volume-example
|
||||
```
|
||||
|
||||
输出显示`labels`和`annotations`文件的内容：
|
||||
<!--
|
||||
The output shows the contents of the labels file and the annotations file:
|
||||
-->
|
||||
输出显示 `labels` 和 `annotations` 文件的内容：
|
||||
|
||||
```shell
|
||||
cluster="test-cluster1"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 概述
|
||||
linkTitle: Try Our Interactive Tutorials
|
||||
title: 学习 Kubernetes 基础知识
|
||||
linkTitle: 学习 Kubernetes 基础知识
|
||||
---
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
@@ -147,7 +147,7 @@ MySQL 和 WordPress pod 配置引用了这个 secret，所以这些 pods 就可
|
||||
|
||||
## 部署 MySQL
|
||||
|
||||
<--
|
||||
<!--
|
||||
Now that the persistent disks and secrets are defined, the Kubernetes
|
||||
pods can be launched. Start MySQL using
|
||||
[mysql-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/mysql-deployment.yaml).
|
||||
|
||||
@@ -12,7 +12,7 @@ title: Docker 用户使用 kubectl 命令指南
|
||||
|
||||
#### docker run
|
||||
|
||||
如何运行一个 nginx Deployment 并将其暴露出来？ 查看 [kubectl run](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 。
|
||||
如何运行一个 nginx Deployment 并将其暴露出来？ 查看 [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run) 。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -26,22 +26,30 @@ a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago
|
||||
|
||||
使用 kubectl 命令：
|
||||
|
||||
```shell
|
||||
<!--
|
||||
# start the pod running nginx
|
||||
-->
|
||||
|
||||
```shell
|
||||
# 启动运行 nginx 的 pod
|
||||
$ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
|
||||
deployment "nginx-app" created
|
||||
```
|
||||
|
||||
在 1.2 及以上版本的 Kubernetes 集群中，使用`kubectl run` 命令将创建一个名为 "nginx-app" 的 Deployment。如果您运行的是老版本，将会创建一个 replication controller。
|
||||
如果您想沿用旧的行为，使用 `--generation=run/v1` 参数，这样就会创建 replication controller。查看 [`kubectl run`](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 获取更多详细信息。
|
||||
如果您想沿用旧的行为，使用 `--generation=run/v1` 参数，这样就会创建 replication controller。查看 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 获取更多详细信息。
|
||||
|
||||
<!--
|
||||
# expose a port through with a service
|
||||
-->
|
||||
|
||||
```shell
|
||||
# expose a port through with a service
|
||||
# 通过服务暴露端口
|
||||
$ kubectl expose deployment nginx-app --port=80 --name=nginx-http
|
||||
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) 获取更多信息。
|
||||
在 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 ...` 类似，如果您想在前台运行，使用：
|
||||
|
||||
@@ -56,7 +64,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
|
||||
#### docker ps
|
||||
|
||||
如何列出哪些正在运行？查看 [kubectl get](/docs/user-guide/kubectl/{{< param "version" >}}/#get)。
|
||||
如何列出哪些正在运行？查看 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -76,7 +84,7 @@ nginx-app-5jyvm 1/1 Running 0 1h
|
||||
|
||||
#### docker attach
|
||||
|
||||
如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/user-guide/kubectl/{{< param "version" >}}/#attach)。
|
||||
如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -100,7 +108,7 @@ $ kubectl attach -it nginx-app-5jyvm
|
||||
|
||||
#### docker exec
|
||||
|
||||
如何在容器中执行命令？查看 [kubectl exec](/docs/user-guide/kubectl/{{< param "version" >}}/#exec)。
|
||||
如何在容器中执行命令？查看 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -138,11 +146,11 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
更多信息请查看 [获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。
|
||||
更多信息请查看[获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。
|
||||
|
||||
#### docker logs
|
||||
|
||||
如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/user-guide/kubectl/{{< param "version" >}}/#logs)。
|
||||
如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -168,11 +176,12 @@ $ kubectl logs --previous nginx-app-zibvs
|
||||
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/) 获取更多信息。
|
||||
查看[记录和监控集群活动](/docs/concepts/cluster-administration/logging/)获取更多信息。
|
||||
|
||||
#### docker stop 和 docker rm
|
||||
|
||||
如何停止和删除运行中的进程？查看 [kubectl delete](/docs/user-guide/kubectl/{{< param "version" >}}/#delete)。
|
||||
|
||||
如何停止和删除运行中的进程？查看 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -201,15 +210,15 @@ $ kubectl get po -l run=nginx-app
|
||||
# Return nothing
|
||||
```
|
||||
|
||||
请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除pod，Deployment 将会重新创建该 pod。
|
||||
请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod，Deployment 将会重新创建该 pod。
|
||||
|
||||
#### docker login
|
||||
|
||||
在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅 [使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。
|
||||
在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅[使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。
|
||||
|
||||
#### docker version
|
||||
|
||||
如何查看客户端和服务端的版本？查看 [kubectl version](/docs/user-guide/kubectl/{{< param "version" >}}/#version)。
|
||||
如何查看客户端和服务端的版本？查看 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -237,7 +246,7 @@ Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4
|
||||
|
||||
#### docker info
|
||||
|
||||
如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/user-guide/kubectl/{{< param "version" >}}/#cluster-info)。
|
||||
如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
||||
* 要分别指定多种资源类型: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
|
||||
例: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-config-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
|
||||
使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-configuration-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
|
||||
例：$ kubectl get pod -f ./pod.yaml
|
||||
|
||||
* flags：指定可选标志。例如，您可以使用`-s`或`--serverflags`来指定Kubernetes API服务器的地址和端口。
|
||||
|
||||
Reference in New Issue
Block a user