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

Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7

Browse Source 
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  whatisk8s - Chinese version (#3243)
  split rows and nest to stack columns (#4129)
  Updates to docs/admin/kubelet-tls-bootstrapping (#3617)
  Replace "Pod Injection Policy" with "Pod Preset" (#3667)
  Change example PersistentVolumeClaim
  add PodNodeSelector to admission-controllers (#3691)
  Get pods using a label selector instead of hardcoded indexes. Use JsonPath instead of go-template.
  correct_init_container_state (#3972)
  kubernetes.github.io/docs/tasks/administer-cluster: operating etcd clusters
  Remove --no-check-certificate flag in bare_metal_offline.md
This commit is contained in:
Andrew Chen
2017-06-22 14:43:14 -07:00
parent 64531da47d 0dbeb6d1bf
commit 6b3c84602d
26 changed files with 1577 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cn/README.md
+18
View File
@@ -0,0 +1,18 @@
## 如何参与 Kubernetes 文档汉化工作
我们非常欢迎，非常希望您参与 Kubernetes 文档汉化做出贡献。
您可以单击屏幕右上角的 **Fork** 按钮，在您的 Github 账户中创建一外名为 *fork* 的存储库副本。在您的分支中进行更改，当您准备好将这些更改发送给我们时，请转到您的仓库创建新的 pull 请求，让我们知道这一点。
关于更多的贡献信息，请参阅:
* [贡献于 Kubernetes 文档](http://kubernetes.io/editdocs/)
* [创建文档拉取请求](http://kubernetes.io/docs/contribute/create-pull-request/)
* [写一个新的话题](http://kubernetes.io/docs/contribute/write-new-topic/)
* [暂停您的文档更改](http://kubernetes.io/docs/contribute/stage-documentation-changes/)
* [更用页面模板](http://kubernetes.io/docs/contribute/page-templates/)
* [文档样式指南](http://kubernetes.io/docs/contribute/style-guide/)
## 谢谢您!
Kubernetes 在社区参与中茁壮成长，我们非常感谢您对我们的网站和文档的贡献！
cn/_includes/user-guide-content-moved.md
+2
View File
@@ -0,0 +1,2 @@
Kubernetes 文档的 [用户指南](/docs/user-guide/) 部分中的主题将被移动到 [任务](/docs/tasks/)、[教程](/docs/tutorials/)和
[概念](/docs/concepts) 部分。 本主题的内容已转移到:
cn/docs/concepts/overview/what-is-kubernetes.md
+119
View File
@@ -0,0 +1,119 @@
---
assignees:
- k8s-merge-robot
title: 认识 Kubernetes?
---
Kubernetes 是一个 [开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) 可以跨主机集群, 提供以容器为中心的基础架构。
使用 Kubernetes, 您可以快速高效地响应客户需求:
- 快速、可预测地部署您的应用程序
- 拥有即时扩展应用程序的能力
- 不影响现有业务的情况下，无缝地发布新功能。
- 优化您的硬件资源，降低您的拥有成本
我们的目标是构建一个软件和工具的生态系统，以减轻您在公共云或私有云运行应用程序的负担。
#### Kubernetes 具有如下特点:
* **便携性**: 无论公有云、私有云、混合云还是多云架构都全面支持
* **可扩展**: 它是模块化、可插拔、可挂载、可组合的，支持各种形式的扩展
* **自修复**: 它可以自保持应用状态、可自重启、自复制、自缩放的，通过声明式语法提供了强大的自修复能力
Kubernetes 项目由 Google 公司在 2014 年启动。Kubernetes 建立在 [Google 公司超过十余年的运维经验基础之上，Google 所有的应用都运行在容器上](https://research.google.com/pubs/pub43438.html), 再与社区中最好的想法和实践相结合，也许它是最受欢迎的容器平台。
##### 准备好 [开始](/docs/getting-started-guides/)?
## 为什么是容器?
查看此文，可以了解为什么您要使用容器 [容器](http://aucouranton.com/2014/06/13/linux-containers-parallels-lxc-openvz-docker-and-more/)?
![为什么是容器?](/images/docs/why_containers.svg)
*传统* 部署应用程序的方式，一般是使用操作系统自带的包管理器在主机上安装应用依赖，之后再安装应用程序。这无疑将应用程序的可执行文件、应用的配置、应用依赖库和应用的生命周期与宿主机操作系统进行了紧耦合。在此情境下，可以通过构建不可改变的虚拟机镜像版本，通过镜像版本实现可预测的发布和回滚，但是虚拟机实在是太重量级了，且镜像体积太庞大，便捷性差。
*新方式* 是基于操作系统级虚拟化而不是硬件级虚拟化方法来部署容器。容器之间彼此隔离并与主机隔离：它们具有自己的文件系统，不能看到彼此的进程，并且它们所使用的计算资源是可以被限制的。它们比虚拟机更容易构建，并且因为它们与底层基础架构和主机文件系统隔离，所以它们可以跨云和操作系统快速分发。
由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定, 因为每一个应用程序不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。
类似地，容器比虚拟机更加透明，这有助于监测和管理。真实的情况是，容器进程的生命周期由基础设施管理，而容器内的进程对外是隐藏的。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。
容器好处摘要:
* **敏捷的应用程序创建和部署**:
与虚拟机镜像相比，容器镜像更容易创建，提升了硬件的使用效率。
* **持续开发、集成和部署**:
提供可靠与频繁的容器镜像构建和部署，可以很方便及快速的回滚 (由于镜像不可变性).
* **关注开发与运维的分离**:
在构建/发布时创建应用程序容器镜像，从而将应用程序与基础架构分离。
* **开发、测试和生产环境的一致性**:
在笔记本电脑上运行与云中一样。
* **云和操作系统的可移植性**:
可运行在 Ubuntu, RHEL, CoreOS, 内部部署, Google 容器引擎和其他任何地方。
* **以应用为中心的管理**:
提升了操作系统的抽象级别，以便在使用逻辑资源的操作系统上运行应用程序。
* **松耦合、分布式、弹性伸缩 [微服务](http://martinfowler.com/articles/microservices.html)**:
应用程序被分成更小，更独立的部分，可以动态部署和管理 - 而不是巨型单体应用运行在专用的大型机。
* **资源隔离**:
通过对应用进行资源隔离，可以很容易的预测应用程序性能。
* **资源利用**:
高效率和高密度。
#### 为什么我们需要 Kubernetes，它能做什么?
最基础的，Kubernetes 可以在物理或虚拟机集群上调度和运行应用程序容器。然而，Kubernetes 还允许开发人员从物理和虚拟机'脱离'，从以**主机为中心**的基础架构转移到以**容器为中心**的基础架构，这样可以提供容器固有的全部优点和益处。Kubernetes 提供了基础设施来构建一个真正以**容器为中心**的开发环境。
Kubernetes 满足了生产中运行应用程序的许多常见的需求，例如：
* [Pod](/docs/user-guide/pods/) 提供复合应用并保留一个应用一个容器的容器模型,
* [挂载外部存储](/docs/user-guide/volumes/),
* [Secret管理](/docs/user-guide/secrets/),
* [应用健康检查](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks),
* [副本应用实例](/docs/user-guide/replication-controller/),
* [横向自动扩缩容](/docs/user-guide/horizontal-pod-autoscaling/),
* [服务发现](/docs/user-guide/connecting-applications/),
* [负载均衡](/docs/user-guide/services/),
* [滚动更新](/docs/user-guide/update-demo/),
* [资源监测](/docs/user-guide/monitoring/),
* [日志采集和存储](/docs/user-guide/logging/overview/),
* [支持自检和调试](/docs/user-guide/introspection-and-debugging/),
* [认证和鉴权](/docs/admin/authorization/).
这提供了平台即服务 (PAAS) 的简单性以及基础架构即服务 (IAAS) 的灵活性，并促进跨基础设施供应商的可移植性。
有关详细信息，请参阅 [用户指南](/docs/user-guide/).
#### 为什么 Kubernetes 是一个平台?
Kubernetes 提供了很多的功能，总会有新的场景会受益于新特性。它可以简化应用程序的工作流，加快开发速度。被大家认可的应用编排通常需要有较强的自动化能力。这就是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。
[Label](/docs/user-guide/labels/) 允许用户按照自己的方式组织管理对应的资源。 [注解](/docs/user-guide/annotations/) 使用户能够以自定义的描述信息来修饰资源，以适用于自己的工作流，并为管理工具提供检查点状态的简单方法。
此外，[Kubernetes 控制面](/docs/admin/cluster-components) 是构建在相同的 [APIs](/docs/api/) 上面，开发员人和用户都可以用。用户可以编写自己的控制器， [调度器](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/scheduler.md)等等，如果这么做，根据新加的[自定义 API](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/extending-api.md) ，可以扩展当前的通用 [CLI 命令行工具](/docs/user-guide/kubectl-overview/)。
这种 [设计](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
#### Kubernetes 不是什么:
Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) 系统。我们保留用户选择的自由，这非常重要。
* Kubernetes 不限制支持的应用程序类型。 它不插手应用程序框架 (例如 [Wildfly](http://wildfly.org/)), 不限制支持的语言运行时 (例如 Java, Python, Ruby)，只迎合符合 [12种因素的应用程序](http://12factor.net/)，也不区分"应用程序"与"服务"。Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。如果应用可以在容器中运行，它就可以在 Kubernetes 上运行。
* Kubernetes 不提供作为内置服务的中间件 (例如 消息中间件)、数据处理框架 (例如 Spark)、数据库 (例如 mysql)或集群存储系统 (例如 Ceph)。这些应用可以运行在 Kubernetes 上。
* Kubernetes 没有提供点击即部署的服务市场
* Kubernetes 从源代码到镜像都是非垄断的。 它不部署源代码且不构建您的应用程序。 持续集成 (CI) 工作流是一个不同用户和项目都有自己需求和偏好的领域。 所以我们支持在 Kubernetes 分层的 CI 工作流，但不指定它应该如何工作。
* Kubernetes 允许用户选择其他的日志记录，监控和告警系统 (虽然我们提供一些集成作为概念验证)
* Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 [jsonnet](https://github.com/google/jsonnet)).
* Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统
另一方面，许多 PaaS 系统*运行*在 Kubernetes 上面，例如 [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。
由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。
此处，Kubernetes 不仅仅是一个 "编排系统"；它消除了编排的需要。 "编排"技术定义的是工作流的执行: 从 A 到 B，然后到 C。相反，Kubernetes 是包括一套独立、可组合的控制过程，通过声明式语法使其连续地朝着期望状态驱动当前状态。 不需要告诉它具体从 A 到 C 的过程，只要告诉到 C 的状态即可。 也不需要集中控制；该方法更类似于"编舞"。这使得系统更容易使用并且更强大、更可靠、更具弹性和可扩展性。
#### *Kubernetes* 是什么意思? K8s?
名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"， 且是英文 "governor" 和 ["cybernetic"](http://www.etymonline.com/index.php?term=cybernetics)的词根。 **K8s** 是通过将 8 个字母 "ubernete" 替换为 8 而导出的缩写。另外，在中文里，k8s 的发音与 Kubernetes 的发音比较接近。
cn/docs/tutorials/kubernetes-basics/cluster-interactive.html
Executable
+35
View File
@@ -0,0 +1,35 @@
---
title: 交互式教程 - 创建集群
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-intro/" role="button">Continue to Module 2<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/cluster-intro.html
Executable
+110
View File
@@ -0,0 +1,110 @@
---
redirect_from:
- "/docs/tutorials/getting-started/create-cluster/"
- "/docs/tutorials/getting-started/create-cluster.html"
title: 使用 Minikube 创建一个集群
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>了解什么是 Kubernetes 集群</li>
<li>了解什么是 Minikube</li>
<li>使用在线终端启动 Kubernetes 集群</li>
</ul>
</div>
<div class="col-md-8">
<h3>Kubernetes 集群</h3>
<p>
<b>Kubernetes 用于协调高度可用的计算机集群，这些计算机群集被连接作为单个单元工作。</b> Kubernetes 中的抽象允许您将容器化的应用程序部署到集群，而不必专门将其绑定到单个计算机。为了利用这种新的部署模型，应用程序需要以将它们与各个主机分离的方式打包: 它们需要被容器化。容器化应用程序比过去的部署模型更灵活和可用，其中应用程序直接安装到特定机器上，作为深入集成到主机中的软件包。 <b>Kubernetes 以更有效的方式自动化、跨集群的容器应用程序的分发和调度。</b> Kubernetes 是一个 <a href="https://github.com/kubernetes/kubernetes">开源</a> 平台，为生产环境准备的。
</p>
<p>Kubernetes 集群由两种类型的资源组成:
<ul>
<li>一个 <b>Master</b> 调度节点</li>
<li><b>Nodes</b> 应用程序实际运行的地方</li>
</ul>
</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>概要:</h3>
<ul>
<li>Kubernetes 集群</li>
<li>Minikube</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>
Kubernetes 是一个生产级的开源平台，用于协调计算机集群内部和跨计算机集群的应用程序容器的分发(调度)和运行。
</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">集群图</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p><b>Master 负责管理集群。</b> master 协调集群中的所有活动，例如调度应用程序、维护应用程序的所需状态、扩展应用程序和滚动更新。</p>
<p><b>node 是 Kubernetes 集群中的工作机器，可以是物理机或虚拟机。</b> 每个工作节点都有一个 Kubelet，它是管理 node 并与 Kubernetes Master 节点进行通信的代理。node 上还应具有处理容器操作的工作，例如 <a href="https://www.docker.com/">Docker</a> 或 <a href="https://coreos.com/rkt/">rkt</a>。一个 Kubernetes 工作集群至少有三个 node 节点。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> Master 管理集群和 Nodes 用于托管正在运行的应用程序。 </i></p>
</div>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p>当您在 Kubernetes 上部署应用程序时，您可以告诉 master 启动应用程序容器。Master 调度容器在集群的 Node 上运行。<b> Nodes 使用 Master 公开的 Kubernetes API 与 Master 通信</b>。最终用户还可以直接使用 Kubernetes 的 API 与集群交互。</p>
<p>Kubernetes 集群可以部署在物理机或虚拟机上。要开始使用 Kubernetes 开发，您可以使用 <a href="https://github.com/kubernetes/minikube">Minikube</a>。Minikube 是一个轻量级的 Kubernetes 实现，在本机创建一台虚拟机，并部署一个只包含一个节点的简单集群。 Minikube 适用于 Linux, Mac OS 和 Windows 系统。Minikube CLI 提供了集群的基本引导操作，包括启动、停止、状态和删除。但是，对于此基础训练，您将使用预先安装了 Minikube 的在线终端。</p>
<p>现在您已经知道 Kubernetes 是什么，让我们使用在线教程，开始我们的第一个集群!</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/cluster-interactive/" role="button">启动交互教程 <span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/deploy-interactive.html
Executable
+39
View File
@@ -0,0 +1,39 @@
---
title: 交互式教程 - 部署应用程序
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<br>
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore-intro/" role="button">Continue to Module 3<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/deploy-intro.html
Executable
+108
View File
@@ -0,0 +1,108 @@
---
title: 使用 kubectl 创建部署
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>了解应用程序部署</li>
<li>使用 kubectl 在 Kubernetes 上部署您的第一个应用程序</li>
</ul>
</div>
<div class="col-md-8">
<h3>Kubernetes 部署</h3>
<p>
一旦运行了 Kubernetes 集群，您可以在其上部署容器化应用程序。为此，您可以创建一个 Kubernetes <b>Deployment</b>。Deployment 负责创建和更新应用程序实例。创建 Deployment 后， Kubernetes master 会将 Deployment 创建的应用程序实例调度到集群中的各个节点。
</p>
<p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。如果托管它的节点不可用或删除，则 Deployment 控制器将替换实例。 <b>这提供了一种解决机器故障或维护的自愈机制。</b></p>
<p>在编排前的世界中，通常会使用安装脚本启动应用程序，但是它们并不能从机器故障中恢复。通过创建应用程序实例并使其运行在跨节点的机器之间，Kubernetes Deployments 提供了截然不同的应用管理方法。 </p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>概要:</h3>
<ul>
<li>Deployments</li>
<li>Kubectl</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>
Deployment 负责创建和更新应用程序的实例
</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">在 Kubernetes 上部署您的第一个应用程序</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>您可以使用 Kubernetes 命令行工具 <b>Kubectl</b>创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本模块中，您将学习在 Kubernetes 集群上运行应用程序部署所需的最常见 Kubectl 命令。</p>
<p>创建部署时，您需要为应用程序指定容器镜像以及要运行的副本数。您可以稍后通过更新部署来更改该信息；模块 <a href="/docs/tutorials/kubernetes-basics/scale-intro/">5</a> 和 <a href="/docs/tutorials/kubernetes-basics/update-intro/">6</a> 是一个基础训练讨论如何扩展和更新您的部署。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> 应用程序需要打包成支持的容器格式之一，以便部署在 Kubernetes 上。</i></p>
</div>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p>对于我们的第一个部署，我们将使用 <a href="https://nodejs.org">Node.js</a> 应用程序打包到 Docker 容器。源代码和 Dockerfile 可在 Kubernetes Bootcamp <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub 存储库</a> 中找到。</p>
<p>现在您已经知道部署是什么，我来再来看看在线教程，并部署我们的第一个应用程序!</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-interactive/" role="button">启动交互式教程 <span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/explore-interactive.html
Executable
+39
View File
@@ -0,0 +1,39 @@
---
title: 交互式教程 - 应用程序探索
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<br>
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-intro/" role="button">Continue to Module 4<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/explore-intro.html
Executable
+142
View File
@@ -0,0 +1,142 @@
---
title: 查看 Pods 和 Nodes
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>了解 Kubernetes Pods</li>
<li>了解 Kubernetes Nodes</li>
<li>已部署应用故障排除</li>
</ul>
</div>
<div class="col-md-8">
<h2>Kubernetes Pods</h2>
<p>当您在模块 <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>中创建部署时，Kubernetes 创建了一个 <b>Pod</b> 来托管您的应用程序实例。Pod 是一个 Kubernetes 的资源抽象，表示一个或多个应用容器 (例如 Docker 或 rkt) 组，以及一些用于这些容器的共享资源。这些资源包括:</p>
<ul>
<li>共享存储，如卷</li>
<li>网络，作为唯一的集群 IP 地址</li>
<li>每个容器如何运行的信息，例如容器镜像版本或要使用的特定端口</li>
</ul>
<p>Pod 模型可以理解为应用程序特定的 "逻辑主机"，并且可以包含相对紧密耦合的不同应用程序容器。例如，Pod 可能包含带有 Node.js 应用程序的容器以及用于提供要由 Node.js Web 服务器发布数据的不同容器。Pod 中的容器共享 IP 地址和端口空间，始终位于同一位置并且统一调度，并在相同的节点上运行，共享上下文环境。</p>
<p>Pods 是 Kubernetes 平台上的原子单元。当我们在 Kubernetes 上创建一个部署时，该部署将在其中创建包含容器的 Pod (而不是直接创建容器)。每个 Pod 绑定到它被调度的节点，并且保持在那里，直到终止 (根据重启策略) 或删除。在节点故障的情况下，在集群中的其他可用节点上调度相同的 Pod。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>概要:</h3>
<ul>
<li>Pods</li>
<li>Nodes</li>
<li>Kubectl 主要命令</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>
Pod 是一组或多个应用程序容器 (例如 Docker 或 rkt)，包含共享存储 (卷)，IP 地址以及有关如何运行它们的信息。
</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Pods 概览</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2>Nodes</h2>
<p>Pod 总是运行在 <b>Node</b>上。Node 是 Kubernetes 的工作机器，可以是一个虚拟机或物理，这取决于在集群的安装情况。每个 Node 由 Master 管理。一个 Node 上可以有多个 Pod, Kubernetes master 会自动处理调度集群各个 Node 上的 Pod。 Master 在自动调度时，会考虑每个 Node 上的可用资源。</p>
<p>每个 Kubernetes Node 节点至少运行以下组件:</p>
<ul>
<li>Kubelet 是负责 Kubernetes Master 和 所有 Node 节点之间通信的进程，它管理机器上运行的 Pod 和容器。</li>
<li>容器运行时(例如 Docker, rkt) 负责从镜像仓库中拉取容器镜像，解包容器并运行应用程序。</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> 如果一些容器强耦合并且需要共享资源(例如 磁盘)，那么这些容器应该放到单个 Pod 中一起调度。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Node 概述</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2>使用 kubectl 进行故障排除</h2>
<p>在模块 <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>中，您使用了 Kubectl 命令行接口。您将在模块 3 中继续使用它来获取有关已部署应用程序及其环境信息。最常见的操作可以通过以下 kubectl 命令完成:</p>
<ul>
<li><b>kubectl get</b> - 列出可用资源</li>
<li><b>kubectl describe</b> - 显示有关资源的详细信息</li>
<li><b>kubectl logs</b> - 从 Pod 中的容器打印日志</li>
<li><b>kubectl exec</b> - 在 Pod 中的容器执行命令</li>
</ul>
<p>您可以使用这些命令来查看应用程序部署的时间，它们当前的状态，运行的位置及其配置。</p>
<p>现在我们更多地了解了集群组件和命令行交互，接下来，一起来探索分析我们的应用程序。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> Node 是 Kubernetes 中的工作机器，可能是物理机或虚拟机，具体取决于集群的安装配置。多个 Pod 可以在一个 Node 上运行。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/expose-interactive.html
Executable
+36
View File
@@ -0,0 +1,36 @@
---
title: 交互性教程 - 应用外部可见
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-intro/" role="button">Continue to Module 5<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/expose-intro.html
Executable
+138
View File
@@ -0,0 +1,138 @@
---
title: 使用服务让您的应用程序外部可见
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>了解 Kubernetes 服务</li>
<li>了解 Kubernetes 标签</li>
<li>应用程序在 Kubernetes 外部可见</li>
</ul>
</div>
<div class="col-md-8">
<h3>Kubernetes Services</h3>
<p>虽然每个 Pod 在所在的集群中拥有自己独立的 IP 地址，但这些 IP 地址不会暴露在 Kubernetes 集群外部。考虑到 Pod 可能随时会被终止、删除或被其他 Pod 替换，我们需要一种方法让其他 Pod 和应用程序自动发现彼此。Kubernetes 通过 Service 对 Pods 进行分组来解决此问题。一个 Kubernetes <b>Service</b> 是一个抽象层，它定义了一组逻辑的 Pods，并让这些 Pods 对外部流量可见，可以被负载均衡和服务发现。 </p>
<p>此抽象允许我们将 Pods 暴露给集群外部的流量访问。Services 具有自己的唯一集群专用 IP 地址，并显示一个端口以接收流量。如果选择在集群外公开 Service，则有如下选项:</p>
<ul>
<li>LoadBalancer - 提供公有 IP 地址 (在 GCP 或 AWS 上运行 Kubernetes 通常使用此方式)</li>
<li>NodePort - 使用 NAT 在集群的每个 Node 节点的同一端口让服务可见。(所有 Kubernetes 集群和 Minikube 中都可用此方式)</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>摘要:</h3>
<ul>
<li>Pod 流量外部可见</li>
<li>Pods 流量负载均衡</li>
<li>使用标签</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>
Kubernetes Service 是一个抽象层，它定义了一组逻辑的 Pods，并为这些 Pods 启用了外部流量访问、负载均衡和服务发现。
</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Services 概述</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>一个 Service 提供了一组 Pods 的流量负载均衡。通过创建服务以对来自特定部署的所有 Pods 进行分组时，这是有用的(当我们有多个实例运行时，我们的应用程序将在下一个模块中使用这一点)。</p>
<p>Services 还负责集群内部的服务发现 (包含在 <a href="/docs/user-guide/connecting-applications/#accessing-the-service">访问服务</a>中)。 例如，这将允许前端服务 (如 web 服务器) 从后端服务 (如 数据库) 接收流量，而不必考虑 Pod。 </p>
<p>Services 使用标签选择器匹配一组 Pods，标签选择器支持在标签上进行原始逻辑分组的能力。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> 您可以通过添加 --expose 作为 kubectl 运行命令的参数，在创建 Deployment 的同时创建 Service。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p><b>Labels</b> 是附加到对象的 键/值对，例如 Pods，您可以将它们视为社交媒体的标签符号。它们用于以对用户有意义的方式组织相关对象，如:</p>
<ul>
<li>生产环境 (生产、测试、开发)</li>
<li>应用程序版本 (beta、v1.3)</li>
<li>服务类型 (前端、后端、数据库)</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> Labels 是附加到对象的键/值对。</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Labels</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>Labels 可以在创建时或以后附加到对象，并可以随时修改。
在使用 kubectl run 命令新建 Pods/Deployment 时，会设置一些默认的 Labels/Label。标签和标签选择器之间的链接定义了 Deployment 及其创建 Pod 之间的关系。</p>
<p>现在，让我们在 Service 的帮助下公开我们的应用程序，并应用一些新的标签。</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/index.html
Executable
+106
View File
@@ -0,0 +1,106 @@
---
title: 概述
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="./public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-9">
<h2>Kubernetes 基础</h2>
<p>本教程介绍了 Kubernetes 集群编排系统的基础知识。每个模块包含关于 Kubernetes 主要特性和概念的一些背景信息，并包括一个交互式在线教程。这些交互式教程让您可以自己管理一个简单的集群及其容器化应用程序。</p>
<p>使用交互式教程，您可以学习:</p>
<ul>
<li>在集群上部署容器化应用程序</li>
<li>弹性部署</li>
<li>使用新的软件版本，更新容器化应用程序</li>
<li>调试容器化应用程序</li>
</ul>
<p>教程 Katacoda 在您的浏览器中运行一个虚拟终端，在浏览器中运行 Minikube，这是一个可在任何地方小规模本地部署的 Kubernetes 集群。没有安装任何软件或进行任何配置; 每个交互性教程都直接从您的网页浏览器上运行。</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-9">
<h2>Kubernetes 可以为您做些什么?</h2>
<p>现代的 Web 服务，用户希望应用程序能够 24/7 全天候使用，开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包服务于这些目标，使应用程序能够以简单快速的方式发布和更新，而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的地方和时间运行，并帮助应用程序找到它们需要的资源的工具。 <a href="http://kubernetes.io/docs/whatisk8s/">Kubernetes</a> 是一个生产可用的开源平台，具有 Google 容器集群方面的设计与经验积累，拥有来自社区的最佳实践。</p>
</div>
</div>
<div class="content__modules">
<h2>Kubernetes 基础模块</h2>
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/cluster-intro/"><img src="./public/images/module_01.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="cluster-intro/"><h5>1. 创建一个 Kubernetes 集群</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/deploy-intro/"><img src="./public/images/module_02.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="deploy-intro/"><h5>2. 部署应用程序</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/explore-intro/"><img src="./public/images/module_03.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="explore-intro/"><h5>3. 应用程序探索</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/expose-intro/"><img src="./public/images/module_04.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="expose-intro/"><h5>4. 应用外部可见</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/scale-intro/"><img src="./public/images/module_05.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="scale-intro/"><h5>5. 应用可伸缩</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/update-intro/"><img src="./public/images/module_06.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="update-intro/"><h5>6. 应用更新</h5></a>
</div>
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/cluster-intro/" role="button">开始教程<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/scale-interactive.html
Executable
+38
View File
@@ -0,0 +1,38 @@
---
title: 交互式教程 - 扩展您的应用程序
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update-intro/" role="button">Continue to Module 6<span class="btn__next">›</span></a>
</div>
</div>
</main>
<a class="scrolltop" href="#top"></a>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/scale-intro.html
Executable
+120
View File
@@ -0,0 +1,120 @@
---
title: 运行应用程序的多个实例
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>使用 kubectl 缩放应用程序</li>
</ul>
</div>
<div class="col-md-8">
<h3>缩放应用程序</h3>
<p>在之前的模块中，我们创建了一个 <a href="http://kubernetes.io/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="http://kubernetes.io/docs/user-guide/services/">Service</a>让应用程序外部可见。Deployment 仅为我们的应用程序创建了一个 Pod。 当流量增加时，我们将需要扩展应用程序以跟上用户需求。</p>
<p><b>Scaling</b> 是通过更改 Deployment 中的副本数量实现的。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>摘要:</h3>
<ul>
<li>Deployment 的缩放</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i> 您可以使用 kubectl run 命令的 --replicas 参数，在创建 Deployment 时指定多个实例。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Scaling 概述</h2>
</div>
</div>
<div class="row">
<div class="col-md-1"></div>
<div class="col-md-8">
<div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
<ol class="carousel-indicators">
<li data-target="#myCarousel" data-slide-to="0" class="active"></li>
<li data-target="#myCarousel" data-slide-to="1"></li>
</ol>
<div class="carousel-inner" role="listbox">
<div class="item active">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
</div>
<div class="item">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
</div>
</div>
<a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
<span class="sr-only ">Previous</span>
</a>
<a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
<span class="sr-only">Next</span>
</a>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>扩展 Deployment 将确保新创建的 Pods 会调度到可用资源的 Node 节点上，收缩会保证 Pods 数量减少至新的所需状态。 Kubernetes 还支持 Pods 的 <a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/"> 自动缩放版 </a> ，但不在本教程范围之内。收缩到零也是可以的，此时它将终止指定 Deployment 的所有 Pod。 </p>
<p>运行应用程序的多个实例需要一种将流量分发给所有实例的方法。服务有内置的负载均衡器，可将网络流量分配给 Deployment 暴露的所有 Pods。服务通过使用 endpoints 持续监控运行的 Pods，以确保流量仅发送到可用的 Pods。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>通过更改 Deployment 中的副本数可以实现伸缩应用程序。</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p> 一旦您有应用程序的多个实例，您将能够滚动更新而不会停止服务。我们将在下一个模块中介绍。现在，我们去在线终端扩展我们的应用程序。</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">启动交互式教程 <span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/update-interactive.html
Executable
+31
View File
@@ -0,0 +1,31 @@
---
title: 交互式教程 - 更新您的应用程序
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
To interact with the Terminal, please use the desktop/tablet version
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/tutorials/kubernetes-basics/update-intro.html
Executable
+135
View File
@@ -0,0 +1,135 @@
---
title: 执行滚动更新
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<h3>目标</h3>
<ul>
<li>使用 kubectl 执行滚动更新</li>
</ul>
</div>
<div class="col-md-8">
<h3>更新应用程序</h3>
<p>用户期望应用程序始终可用，并且开发人员有望每天部署新版本。这就是 Kubernetes 的滚动更新。 <b>Rolling updates</b> 允许通过使用新的 Pods 实例逐个更新来实现零停机的更新部署。新的 Pods 会被调度到可用资源的 Node 节点上。</p>
<p>在上一个模块中，我们将应用程序扩展为运行多个实例。这是执行更新但不影响应用可用性的要求。默认情况下，更新期间最大数量的 Pods 可能不可用，此时创建和更新 Pod 的最大数量是一。 这两个选项可以配置为数字或百分比(Pods)。
在 Kubernetes 中，更新已版本化，任何部署更新都可以恢复到以前的 (稳定) 版本。</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>摘要:</h3>
<ul>
<li>更新应用程序</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>滚动更新允许通过使用新的 Pods 实例逐个更新来实现零停机的部署更新。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">滚动更新概述</h2>
</div>
</div>
<div class="row">
<div class="col-md-1"></div>
<div class="col-md-8">
<div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
<ol class="carousel-indicators">
<li data-target="#myCarousel" data-slide-to="0" class="active"></li>
<li data-target="#myCarousel" data-slide-to="1"></li>
<li data-target="#myCarousel" data-slide-to="2"></li>
<li data-target="#myCarousel" data-slide-to="3"></li>
</ol>
<div class="carousel-inner" role="listbox">
<div class="item active">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg" >
</div>
<div class="item">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg">
</div>
<div class="item">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg">
</div>
<div class="item">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg">
</div>
</div>
<a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
<span class="sr-only ">Previous</span>
</a>
<a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
<span class="sr-only">Next</span>
</a>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>与应用程序缩放类似，如果 Deployment 外部可见，则 Service 将在更新期间将流量负载均衡到可用的 Pod。可用的 Pod 指的是应用程序用户可用的实例。</p>
<p>滚动更新允许以下操作:</p>
<ul>
<li>将应用程序从一个环境升级到另一个环境 (通过容器镜像更新)</li>
<li>回滚到以前的版本</li>
<li>持续集成和持续交付，实现应用程序零故障</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>如果部署外部可见，则服务将在更新期间将流量负载均衡到可用的 Pod。 </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p> 在下面的交互式教程中，我们将把应用程序更新到一个新版本，并执行回滚。</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
cn/docs/whatisk8s.md
+9
View File
@@ -0,0 +1,9 @@
---
assignees:
- k8s-merge-robot
title: 认识 Kubernetes?
---
{% include user-guide-content-moved.md %}
[认识 Kubernetes?](/docs/concepts/overview/what-is-kubernetes/)
docs/admin/admission-controllers.md
+30
View File
@@ -257,6 +257,36 @@ storage classes and how to mark a storage class as default.
This plug-in sets the default forgiveness toleration for pods, which have no forgiveness tolerations, to tolerate
the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes.
### PodNodeSelector
This plug-in defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
#### Configuration File Format
PodNodeSelector uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend.
Note that the configuration file format will move to a versioned file in a future release.
This file may be json or yaml and has the following format:
```yaml
podNodeSelectorPluginConfig:
clusterDefaultNodeSelector: <node-selectors-labels>
namespace1: <node-selectors-labels>
namespace2: <node-selectors-labels>
```
#### Configuration Annotation Format
PodNodeSelector uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
```yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
scheduler.alpha.kubernetes.io/node-selector: <node-selectors-labels>
name: namespace3
```
### PodSecurityPolicy
This plug-in acts on creation and modification of the pod and determines if it should be admitted
docs/admin/kubelet-tls-bootstrapping.md
+52 -52
View File
@@ -10,87 +10,87 @@ title: TLS bootstrapping
## Overview
This document describes how to set up TLS client certificate bootstrapping for kubelets.
Kubernetes 1.4 introduces an experimental API for requesting certificates from a cluster-level
Certificate Authority (CA). The first supported use of this API is the provisioning of TLS client
certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
and progress on the feature is being tracked as [feature #43](https://github.com/kubernetes/features/issues/43).
Kubernetes 1.4 introduced an API for requesting certificates from a cluster-level Certificate Authority (CA). The original intent of this API is to enable provisioning of TLS client certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
and progress on the feature is being tracked as [feature #43](https://github.com/kubernetes/features/issues/43).
## apiserver configuration
## kube-apiserver configuration
You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group.
This group will later be used in the controller-manager configuration to scope approvals in the default approval
controller. As this feature matures, you should ensure tokens are bound to an RBAC policy which limits requests
using the bootstrap token to only be able to make requests related to certificate provisioning. When RBAC policy
is in place, scoping the tokens to a group will allow great flexibility (e.g. you could disable a particular
bootstrap group's access when you are done provisioning the nodes).
controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
(using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes).
### Token auth file
Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example:
### Token authentication file
Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example:
`head -c 16 /dev/urandom | od -An -t x | tr -d ' '`
`head -c 16 /dev/urandom | od -An -t x | tr -d ' '`
will generate tokens that look like `02b50b05283e98dd0fd71db496ef01e8`
will generate tokens that look like `02b50b05283e98dd0fd71db496ef01e8`
The token file will look like the following example, where the first three values can be anything and the quoted group
name should be as depicted:
The token file should look like the following example, where the first three values can be anything and the quoted group
name should be as depicted:
```
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
```
```
Add the `--token-auth-file=FILENAME` flag to the apiserver command to enable the token file.
See docs at http://kubernetes.io/docs/admin/authentication/#static-token-file for further details.
Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
See docs [here](http://kubernetes.io/docs/admin/authentication/#static-token-file) for further details.
### Client certificate CA bundle
Add the `--client-ca-file=FILENAME` flag to the apiserver command to enable client certificate authentication,
referencing a certificate authority bundle containing the signing certificate.
Add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable client certificate authentication,
referencing a certificate authority bundle containing the signing certificate (e.g. `--client-ca-file=/var/lib/kubernetes/ca.pem`).
## controller-manager configuration
The API for requesting certificates adds a certificate-issuing control loop to the KCM. This takes the form of a
[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using assets on disk.
Currently, all certificates issued have one year validity and a default set of key usages.
## kube-controller-manager configuration
The API for requesting certificates adds a certificate-issuing control loop to the Kubernetes Controller Manager. This takes the form of a
[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using assets on disk. Currently, all certificates issued have one year validity and a default set of key usages.
### Signing assets
You must provide a Certificate Authority in order to provide the cryptographic materials necessary to issue certificates.
This CA should be trusted by the apiserver for authentication with the `--client-ca-file=SOMEFILE` flag. The management
### Signing assets
You must provide a Certificate Authority in order to provide the cryptographic materials necessary to issue certificates.
This CA should be trusted by kube-apiserver for authentication with the `--client-ca-file=FILENAME` flag. The management
of the CA is beyond the scope of this document but it is recommended that you generate a dedicated CA for Kubernetes.
Both certificate and key are assumed to be PEM-encoded.
Both certificate and key are assumed to be PEM-encoded.
The kube-controller-manager flags are:
The new controller-manager flags are:
```
--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"
```
```
### Auto-approval
To ease deployment and testing, the alpha version of the certificate request API includes a flag to approve all certificate
### Automatic approval
To ease deployment and testing, there is an experimental flag in the certificate bootstrapping API to approve all certificate
requests made by users in a certain group. The intended use of this is to whitelist only the group corresponding to the bootstrap
token in the token file above. Use of this flag circumvents makes the "approval" process described below and is not recommended
for production use.
token in the token file above. Use of this flag circumvents the approval process described below and is not recommended
for production use.
The flag is:
The flag is:
```
--insecure-experimental-approve-all-kubelet-csrs-for-group="system:kubelet-bootstrap"
```
```
## kubelet configuration
To use request a client cert from the certificate request API, the kubelet needs a path to a kubeconfig file that contains the
bootstrap auth token. If the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a
client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate
is written to the path specified by `--kubeconfig`. The certificate and key file will be stored in the directory pointed
by `--cert-dir`. The new flag is:
## kubelet configuration
To request a client certificate from kube-apiserver, the kubelet first needs a path to a kubeconfig file that contains the
bootstrap authentication token. You can use `kubectl config set-cluster`, `set-credentials`, and `set-context` to build this kubeconfig. Provide the name `kubelet-bootstrap` to `kubectl config set-credentials` and include `--token=<token-value>` as follows:
```
kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig
```
When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.
The flag to enable this bootstrapping when starting the kubelet is:
```
--experimental-bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
```
```
## kubectl approval
The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an
## kubectl approval
The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an
"Approved" status by an appropriately-privileged user. This is intended to eventually be an automated process handled by an external
approval controller, but for the alpha version of the API it can be done manually by a cluster administrator using kubectl.
An administrator can list CSRs with `kubectl get csr`, describe one in detail with `kubectl describe <name>`. There are
[currently no direct approve/deny commands](https://github.com/kubernetes/kubernetes/issues/30163) so an approver will need to update
the Status field directly. A rough example of how to do this in bash which should only be used until the porcelain merges is available
at [https://github.com/gtank/csrctl](https://github.com/gtank/csrctl).
approval controller, but for the alpha version of the API it can be done manually by a cluster administrator using kubectl.
An administrator can list CSRs with `kubectl get csr` and describe one in detail with `kubectl describe csr <name>`. Before the 1.6 release there were
[no direct approve/deny commands](https://github.com/kubernetes/kubernetes/issues/30163) so an approver had to update
the Status field directly ([rough how-to](https://github.com/gtank/csrctl)). Later versions of Kubernetes offer `kubectl certificate approve <name>` and `kubectl certificate deny <name>` commands.
docs/concepts/workloads/pods/init-containers.md
+8 -6
View File
@@ -199,7 +199,9 @@ Init Containers:
[...]
init-mydb:
[...]
State: Running
State: Waiting
Reason: PodInitializing
Ready: False
[...]
Containers:
myapp-container:
@@ -209,13 +211,13 @@ Containers:
Ready: False
[...]
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201
16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox"
16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox"
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox"
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
```
docs/getting-started-guides/coreos/bare_metal_offline.md
+10 -10
View File
@@ -5,7 +5,7 @@ assignees:
title: Offline
---
Deploy a CoreOS running Kubernetes environment. This particular guide is made to help those in an OFFLINE system, wither for testing a POC before the real deal, or you are restricted to be totally offline for your applications.
Deploy a CoreOS running Kubernetes environment. This particular guide is made to help those in an OFFLINE system, whether for testing a POC before the real deal, or you are restricted to be totally offline for your applications.
* TOC
{:toc}
@@ -214,15 +214,15 @@ rm /etc/httpd/conf.d/welcome.conf
cd /var/www/html/
wget -O kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.2/kube-register-0.0.2-linux-amd64
wget -O setup-network-environment https://github.com/kelseyhightower/setup-network-environment/releases/download/v1.0.0/setup-network-environment
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubernetes --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-controller-manager --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-scheduler --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubectl --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubecfg --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubelet --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-proxy --no-check-certificate
wget -O flanneld https://storage.googleapis.com/k8s/flanneld --no-check-certificate
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubernetes
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-controller-manager
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-scheduler
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubectl
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubecfg
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubelet
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-proxy
wget -O flanneld https://storage.googleapis.com/k8s/flanneld
```
This sets up our binaries we need to run Kubernetes. This would need to be enhanced to download from the Internet for updates in the future.
docs/tasks/administer-cluster/configure-upgrade-etcd.md
+189 -31
View File
@@ -2,7 +2,7 @@
assignees:
- mml
- wojtek-t
title: Configure, Upgrade, and Roll Back etcd
title: Operating etcd clusters for Kubernetes
redirect_from:
- "/docs/concepts/storage/etcd-store-api-object/"
- "/docs/concepts/storage/etcd-store-api-object.html"
@@ -16,9 +16,7 @@ redirect_from:
- "/docs/concepts/cluster-administration/etcd-upgrade.html"
---
[etcd](https://coreos.com/etcd/docs/latest/) is a highly-available key value
store which Kubernetes uses for persistent storage of all of its REST API
objects.
etcd is a strong, consistent, and highly-available key value store which Kubernetes uses for persistent storage of all of its API objects. This documentation provides specific instruction on operating, upgrading, and rolling back etcd clusters for Kubernetes. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
<!-- TODO(mml): Write this doc.
@@ -27,36 +25,196 @@ see _some doc_.
-->
## Important assumptions
## Prerequisites
* Run etcd as a cluster of odd members.
* etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable.
* Ensure that no resource starvation occurs.
Performance and stability of the cluster is sensitive to network and disk IO. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled.
* Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations).
## Resource requirements
Operating etcd with limited resources is suitable only for testing purposes. For deploying in production, advanced hardware configuration is required. Before deploying etcd in production, see [resource requirement reference documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#example-hardware-configurations).
## Starting Kubernetes API server
This section covers starting a Kubernetes API server with an etcd cluster in the deployment.
### Single-node etcd cluster
Use a single-node etcd cluster only for testing purpose.
1. Run the following:
``` bash
./etcd --client-listen-urls=http://$PRIVATE_IP:2379 --client-advertise-urls=http://$PRIVATE_IP:2379
```
2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`.
Replace `PRIVATE_IP` with your etcd client IP.
### Multi-node etcd cluster
For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ Documentation](https://github.com/coreos/etcd/blob/master/Documentation/faq.md#what-is-failure-tolerance).
Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd Clustering Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md).
For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server:
1. Run the following:
./etcd --client-listen-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --client-advertise-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379
2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`.
Replace `IP` with your client IP addresses.
### Multi-node etcd cluster with load balancer
To run a load balancing etcd cluster:
1. Set up an etcd cluster.
2. Configure a load balancer in front of the etcd cluster.
For example, let the address of the load balancer be `$LB`.
3. Start Kubernetes API Servers with the flag `--etcd-servers=$LB:2379`.
## Securing etcd clusters
Access to etcd is equivalent to root permission in the cluster so ideally only the API server should have access to it. Considering the sensitivity of the data, it is recommended to grant permission to only those nodes that require access to etcd clusters.
To secure etcd, either set up firewall rules or use the security features provided by etcd. etcd security features depend on x509 Public Key Infrastructure (PKI). To begin, establish secure communication channels by generating a key and certificate pair. For example, use key pairs `peer.key` and `peer.cert` for securing communication between etcd members, and `client.key` and `client.cert` for securing communication between etcd and its clients. See the [example scripts](https://github.com/coreos/etcd/tree/master/hack/tls-setup) provided by the etcd project to generate key pairs and CA files for client authentication.
### Securing communication
To configure etcd with secure peer communication, specify flags `--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use https as URL schema.
Similarly, to configure etcd with secure client communication, specify flags `--key-file=peer.key` and `--cert-file=peer.cert`, and use https as URL schema.
### Limiting access of etcd clusters
After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API server. Use TLS authentication to do so.
For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trust-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`.
Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert` and `--etcd-keyfile=k8sclient.key`.
**Note**: etcd authentication is not currently supported by Kubernetes. For more information, see see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
## Replacing a failed etcd member
etcd cluster achieves high availability by tolerating minor member failures. However, to improve the overall health of the cluster, replace failed members immediately. When multiple members fail, replace them one by one. Replacing a failed member involves two steps: removing the failed member and adding a new member.
Though etcd keeps unique member IDs internally, it is recommended to use a unique name for each member to avoid human errors. For example, consider a three-member etcd cluster. Let the URLs be, member1=http://10.0.0.1, member2=http://10.0.0.2, and member3=http://10.0.0.3. When member1 fails, replace it with member4=http://10.0.0.4.
1. Get the member ID of the failed member1:
`etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list`
The following message is displayed:
8211f1d0f64f3269, started, member1, http://10.0.0.1:12380, http://10.0.0.1:2379
91bc3c398fb3c146, started, member2, http://10.0.0.1:2380, http://10.0.0.2:2379
fd422379fda50e48, started, member3, http://10.0.0.1:2380, http://10.0.0.3:2379
2. Remove the failed member:
`etcdctl member remove 8211f1d0f64f3269`
The following message is displayed:
Removed member 8211f1d0f64f3269 from cluster
3. Add the new member:
`./etcdctl member add member4 --peer-urls=http://10.0.0.4:2380`
The following message is displayed:
Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
4. Start the newly added member on a machine with the IP `10.0.0.4`:
```bash
export ETCD_NAME="member4"
export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380"
export ETCD_INITIAL_CLUSTER_STATE=existing
etcd [flags]
```
5. Do either of the following:
1. Update its `--etcd-servers` flag to make Kubernetes aware of the configuration changes, then restart the Kubernetes API server.
2. Update the load balancer configuration if a load balancer is used in the deployment.
For more information on cluster reconfiguration, see [etcd Reconfiguration Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member).
## Backing up an etcd cluster
All Kubernetes objects are stored on etcd. Periodically backing up the etcd cluster data is important to recover Kubernetes clusters under disaster scenarios, such as losing all master nodes. The snapshot file contains all the Kubernetes states and critical information. In order to keep the sensitive Kubernetes data safe, encrypt the snapshot files.
Backing up an etcd cluster can be accomplished in two ways: etcd built-in snapshot and volume snapshot.
### Built-in snapshot
etcd supports built-in snapshot, so backing up an etcd cluster is easy. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) that is not currently used by an etcd process. `datadir` is located at `$DATA_DIR/member/snap/db`. Taking the snapshot will normally not affect the performance of the member.
Below is an example for taking a snapshot of the keyspace served by `$ENDPOINT` to the file `snapshotdb`:
```sh
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb
# exit 0
# verify the snapshot
ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 | 10 | 7 | 2.1 MB |
+----------+----------+------------+------------+
```
### Volume snapshot
If etcd is running on a storage volume that supports backup, such as Amazon Elastic Block Store, back up etcd data by taking a snapshot of the storage volume.
## Scaling up etcd clusters
Scaling up etcd clusters increases availability by trading off performance. Scaling does not increase cluster performance nor capability. A general rule is not to scale up or down etcd clusters. Do not configure any auto scaling groups for etcd clusters. It is highly recommended to always run a static five-member etcd cluster for production Kubernetes clusters at any officially supported scale.
A reasonable scaling is to upgrade a three-member cluster to a five-member one, when more reliability is desired. See [etcd Reconfiguration Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member) for information on how to add members into an existing cluster.
## Restoring an etcd cluster
etcd supports restoring from snapshots that are taken from an etcd process of the [major.minor](http://semver.org/) version. Restoring a version from a different patch version of etcd also is supported. A restore operation is employed to recover the data of a failed cluster.
Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir). `datadir` is located at `$DATA_DIR/member/snap/db`. For more information and examples on restoring a cluster from a snapshot file, see [etcd disaster recovery documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster).
If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD__ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD__ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.
If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.
## Upgrading and rolling back etcd clusters
### Important assumptions
The upgrade procedure described in this document assumes that either:
1. The etcd cluster has only a single node, or
1. The etcd cluster has multiple nodes. In this case, the upgrade procedure requires shutting down the
etcd cluster. During the time the etcd cluster is shutdown, the Kubernetes API Server
will be read only.
1. The etcd cluster has only a single node
2. The etcd cluster has multiple nodes.
In this case, the upgrade procedure requires shutting down the
etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.
**Warning**: Deviations from the assumptions are untested by continuous
integration, and deviations might create undesirable consequences. Additional
information about operating an etcd cluster is available [from the etcd
maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
## etcd for Kubernetes: high-level goals
Access control: Give only kube-apiserver read/write access to etcd. You do not
want the API server's etcd exposed to every node in your cluster, or worse, to the
internet at large. Access to etcd is equivalent to root access in your
cluster.
Data reliability: For reasonable safety, either etcd needs to be run as a
[cluster](/docs/admin/high-availability/#clustering-etcd), or etcd's data directory
should be located on durable storage, for example, a Google Compute Engine persistent disk.
In either case, if high availability is
required--as it might be in a production cluster--the data directory ought to be
[backed up periodically](https://coreos.com/etcd/docs/latest/op-guide/recovery.html)
to reduce downtime in case of corruption.
## Background
### Background
As of Kubernetes version 1.5.1, we are still using etcd from the 2.2.1 release with
the v2 API. Also, we have no pre-existing process for updating etcd, as we have
@@ -79,9 +237,9 @@ There are requirements on how an etcd cluster upgrade can be performed. The prim
#### One minor release at a time
Upgrade only one minor release at a time. For example, we cannot upgrade directly from 2.1.x to 2.3.x.
Within patch releases it is possible to upgrade and downgrade between arbitrary versions. Starting a cluster for
Within patch releases it is possible to upgrade and downgrade between arbitrary versions. Starting a cluster for
any intermediate minor release, waiting until the cluster is healthy, and then
shutting down the cluster down will perform the migration. For example, to upgrade from version 2.1.x to 2.3.y,
shutting down the cluster down will perform the migration. For example, to upgrade from version 2.1.x to 2.3.y,
it is enough to start etcd in 2.2.z version, wait until it is healthy, stop it, and then start the
2.3.y version.
@@ -193,7 +351,7 @@ script works as follows:
in v2 format.
1. Finally update the contents of the version file.
## Upgrade procedure
### Upgrade procedure
Simply modify the command line in the etcd manifest to:
1. Run the migration script. If the previously run version is already in the
docs/tasks/configure-pod-container/task-pv-claim.yaml
+1
View File
@@ -9,3 +9,4 @@ spec:
resources:
requests:
storage: 3Gi
storageClassName: ""
docs/tasks/inject-data-application/podpreset.md
+6 -6
View File
@@ -74,7 +74,7 @@ of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
### Simple Pod Spec Example
This is a simple example to show how a Pod spec is modified by the Pod
Injection Policy.
Preset.
**User submitted pod spec:**
@@ -148,8 +148,8 @@ spec:
### Pod Spec with `ConfigMap` Example
This is an example to show how a Pod spec is modified by the Pod Injection
Policy that defines a `ConfigMap` for Environment Variables.
This is an example to show how a Pod spec is modified by the Pod Preset
that defines a `ConfigMap` for Environment Variables.
**User submitted pod spec:**
@@ -266,7 +266,7 @@ spec:
### ReplicaSet with Pod Spec Example
The following example shows that only the pod spec is modified by the Pod
Injection Policy.
Preset.
**User submitted ReplicaSet:**
@@ -460,8 +460,8 @@ spec:
### Conflict Example
This is a example to show how a Pod spec is not modified by the Pod Injection
Policy when there is a conflict.
This is an example to show how a Pod spec is not modified by the Pod Preset
when there is a conflict.
**User submitted pod spec:**
docs/tutorials/kubernetes-basics/index.html
+48 -40
View File
@@ -41,51 +41,59 @@ title: Overview
<div class="content__modules">
<h2>Kubernetes Basics Modules</h2>
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/cluster-intro/"><img src="./public/images/module_01.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="cluster-intro/"><h5>1. Create a Kubernetes cluster</h5></a>
<div class="col-md-12">
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/cluster-intro/"><img src="./public/images/module_01.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="cluster-intro/"><h5>1. Create a Kubernetes cluster</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/deploy-intro/"><img src="./public/images/module_02.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="deploy-intro/"><h5>2. Deploy an app</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/explore-intro/"><img src="./public/images/module_03.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="explore-intro/"><h5>3. Explore your app</h5></a>
</div>
</div>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/deploy-intro/"><img src="./public/images/module_02.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="deploy-intro/"><h5>2. Deploy an app</h5></a>
<div class="col-md-12">
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/expose-intro/"><img src="./public/images/module_04.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="expose-intro/"><h5>4. Expose your app publicly</h5></a>
</div>
</div>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/explore-intro/"><img src="./public/images/module_03.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="explore-intro/"><h5>3. Explore your app</h5></a>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/scale-intro/"><img src="./public/images/module_05.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="scale-intro/"><h5>5. Scale up your app</h5></a>
</div>
</div>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/expose-intro/"><img src="./public/images/module_04.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="expose-intro/"><h5>4. Expose your app publicly</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/scale-intro/"><img src="./public/images/module_05.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="scale-intro/"><h5>5. Scale up your app</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/update-intro/"><img src="./public/images/module_06.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="update-intro/"><h5>6. Update your app</h5></a>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/update-intro/"><img src="./public/images/module_06.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="update-intro/"><h5>6. Update your app</h5></a>
</div>
</div>
</div>
</div>
</div>
docs/tutorials/stateful-application/basic-stateful-set.md
+8 -8
View File
@@ -491,10 +491,10 @@ web-0 1/1 Running 0 3s
Get the Pods to view their container images.
```shell{% raw %}
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
gcr.io/google_containers/nginx-slim:0.7
gcr.io/google_containers/nginx-slim:0.8
gcr.io/google_containers/nginx-slim:0.8
kubectl get pod -l app=nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
web-0 gcr.io/google_containers/nginx-slim:0.7
web-1 gcr.io/google_containers/nginx-slim:0.8
web-2 gcr.io/google_containers/nginx-slim:0.8
{% endraw %}```
`web-0` has had its image updated. Complete the update by deleting the remaining
@@ -532,10 +532,10 @@ web-2 1/1 Running 0 36s
Get the Pods to view their container images.
```shell{% raw %}
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
gcr.io/google_containers/nginx-slim:0.7
gcr.io/google_containers/nginx-slim:0.7
gcr.io/google_containers/nginx-slim:0.7
kubectl get pod -l app=nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
web-0 gcr.io/google_containers/nginx-slim:0.7
web-1 gcr.io/google_containers/nginx-slim:0.7
web-2 gcr.io/google_containers/nginx-slim:0.7
{% endraw %}```
All the Pods in the StatefulSet are now running a new container image.