Refine the kubernetes chapter's structure
Baohua Yang
parent
0e87b70fbf
commit
c5a5656220
|
|
@ -1,7 +1,7 @@
|
|||
Docker —— 从入门到实践
|
||||
===============
|
||||
|
||||
v0.4.1
|
||||
v0.4.2
|
||||
|
||||
[Docker](docker.com) 是个伟大的项目，它彻底释放了虚拟化的威力，极大降低了云计算资源供应的成本，同时让应用的分发、测试、部署和分发都变得前所未有的高效和轻松！
|
||||
|
||||
|
|
@ -25,11 +25,12 @@ v0.4.1
|
|||
* 添加 Compose 项目
|
||||
* 添加 Machine 项目
|
||||
* 添加 Swarm 项目
|
||||
* 完善 Kubernetes 项目内容
|
||||
* 0.4: 2015-05-08
|
||||
* 添加 Etcd 项目
|
||||
* 添加 Fig 项目
|
||||
* 添加 CoreOS 项目
|
||||
* 添加 Kuberetes 项目
|
||||
* 添加 Kubernetes 项目
|
||||
* 0.3: 2014-11-25
|
||||
* 完成仓库章节；
|
||||
* 重写安全章节；
|
||||
|
|
|
|||
|
|
@ -102,8 +102,9 @@
|
|||
* [Kubernetes 项目](kubernetes/README.md)
|
||||
* [简介](kubernetes/intro.md)
|
||||
* [快速上手](kubernetes/quickstart.md)
|
||||
* [架构设计](kubernetes/design.md)
|
||||
* [基本概念](kubernetes/concepts.md)
|
||||
* [kubectl 使用](kubernetes/kubectl.md)
|
||||
* [架构设计](kubernetes/design.md)
|
||||
* [附录一：命令查询](appendix_command/README.md)
|
||||
* [附录二：常见仓库介绍](appendix_repo/README.md)
|
||||
* [Ubuntu](appendix_repo/ubuntu.md)
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 217 KiB |
|
|
@ -1,12 +1,13 @@
|
|||
# Kubernetes
|
||||
*注意：目前 Kubernetes 还处于 beta 状态，不推荐生产环境使用。部分概念和设计还可能会有后续调整。*
|
||||
|
||||
Kubernetes 是 Google 团队发起并维护的基于Docker的开源容器集群管理系统，它不仅支持常见的云平台，而且支持内部数据中心。
|
||||
|
||||
建于Docker之上的Kubernetes可以构建一个容器的调度服务，其目的是让用户透过Kubernetes集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作。系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。其核心概念是Container Pod（容器仓）。一个Pod是有一组工作于同一物理工作节点的容器构成的。这些组容器拥有相同的网络命名空间/IP以及存储配额，可以根据实际情况对每一个Pod进行端口映射。此外，Kubernetes工作节点会由主系统进行管理，节点包含了能够运行Docker容器所用到的服务。
|
||||
建于 Docker 之上的 Kubernetes 可以构建一个容器的调度服务，其目的是让用户透过Kubernetes集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作。系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。其核心概念是Container Pod（容器仓）。一个Pod是有一组工作于同一物理工作节点的容器构成的。这些组容器拥有相同的网络命名空间/IP以及存储配额，可以根据实际情况对每一个Pod进行端口映射。此外，Kubernetes工作节点会由主系统进行管理，节点包含了能够运行Docker容器所用到的服务。
|
||||
|
||||
本章将分为5节介绍Kubernetes。包括
|
||||
本章将分为 5 节介绍 Kubernetes。包括
|
||||
* 项目简介
|
||||
* 基本架构和基本概念
|
||||
* 快速入门
|
||||
* 基本概念
|
||||
* 实践例子
|
||||
* 深入分析和高级话题。
|
||||
* 架构分析等高级话题
|
||||
|
|
|
|||
|
|
@ -0,0 +1,182 @@
|
|||
# 基本概念
|
||||
|
||||
|
||||
|
||||
* 节点（Node）：一个节点是一个运行 Kubernetes 中的主机。
|
||||
* 容器组（Pod）：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。
|
||||
* 容器组生命周期（pos-states）：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及replication controllers。
|
||||
* Replication Controllers（replication-controllers）：主要负责指定数量的pod在同一时间一起运行。
|
||||
* 服务（services）：一个Kubernetes服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。
|
||||
* 卷（volumes）：一个卷就是一个目录，容器对其有访问权限。
|
||||
* 标签（labels）：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
|
||||
* 接口权限（accessing_the_api）：端口，ip地址和代理的防火墙规则。
|
||||
* web 界面（ux）：用户可以通过 web 界面操作Kubernetes。
|
||||
* 命令行操作（cli）：`kubecfg`命令。
|
||||
|
||||
|
||||
## 节点
|
||||
在 Kubernetes 中，节点是实际工作的点，以前叫做 Minion。节点可以是虚拟机或者物理机器，依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组，并且它们都可以通过主节点来管理。必要服务包括 Docker，kubelet 和代理服务。
|
||||
|
||||
### 容器状态
|
||||
|
||||
容器状态用来描述节点的当前状态。现在，其中包含三个信息：
|
||||
|
||||
#### 主机IP
|
||||
|
||||
主机IP需要云平台来查询，Kubernetes把它作为状态的一部分来保存。如果Kubernetes没有运行在云平台上，节点ID就是必需的。IP地址可以变化，并且可以包含多种类型的IP地址，如公共IP，私有IP，动态IP，ipv6等等。
|
||||
|
||||
#### 节点周期
|
||||
|
||||
通常来说节点有 `Pending`，`Running`，`Terminated`三个周期，如果Kubernetes发现了一个节点并且其可用，那么Kubernetes就把它标记为 `Pending`。然后在某个时刻，Kubernetes将会标记其为 `Running`。节点的结束周期称为 `Terminated`。一个已经terminated的节点不会接受和调度任何请求，并且已经在其上运行的容器组也会删除。
|
||||
|
||||
#### 节点状态
|
||||
|
||||
节点的状态主要是用来描述处于 `Running`的节点。当前可用的有 `NodeReachable` 和 `NodeReady` 。以后可能会增加其他状态。`NodeReachable` 表示集群可达。`NodeReady`表示kubelet返回 StatusOk并且HTTP状态检查健康。
|
||||
|
||||
### 节点管理
|
||||
|
||||
节点并非Kubernetes创建，而是由云平台创建，或者就是物理机器、虚拟机。在Kubernetes中，节点仅仅是一条记录，节点创建之后，Kubernetes会检查其是否可用。在Kubernetes中，节点用如下结构保存：
|
||||
|
||||
```
|
||||
{
|
||||
"id": "10.1.2.3",
|
||||
"kind": "Minion",
|
||||
"apiVersion": "v1beta1",
|
||||
"resources": {
|
||||
"capacity": {
|
||||
"cpu": 1000,
|
||||
"memory": 1073741824
|
||||
},
|
||||
},
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node",
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Kubernetes校验节点可用依赖于id。在当前的版本中，有两个接口可以用来管理节点：节点控制和Kube管理。
|
||||
|
||||
### 节点控制
|
||||
|
||||
在Kubernetes主节点中，节点控制器是用来管理节点的组件。主要包含：
|
||||
* 集群范围内节点同步
|
||||
* 单节点生命周期管理
|
||||
|
||||
节点控制有一个同步轮寻，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮寻。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在Kubernetes启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl`来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步，你也可以使用api/kubectl 命令行来增删节点。
|
||||
|
||||
## 容器组
|
||||
|
||||
在Kubernetes中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。
|
||||
一个容器组使用相同的Dokcer容器并共享卷（挂载点）。一个容器组是一个特定运用的打包集合，包含一个或多个容器。
|
||||
|
||||
和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，知道容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）。
|
||||
|
||||
### 容器组设计的初衷
|
||||
|
||||
### 资源共享和通信
|
||||
|
||||
容器组主要是为了数据共享和它们之间的通信。
|
||||
|
||||
在一个容器组中，容器都使用相同的网络地址和端口，可以通过本地网络来相互通信。每个容器组都有独立的ip，可用通过网络来和其他物理主机或者容器通信。
|
||||
|
||||
容器组有一组存储卷（挂载点），主要是为了让容器在重启之后可以不丢失数据。
|
||||
|
||||
### 容器组管理
|
||||
|
||||
容器组是一个运用管理和部署的高层次抽象，同时也是一组容器的接口。容器组是部署、水平放缩的最小单位。
|
||||
|
||||
### 容器组的使用
|
||||
|
||||
容器组可以通过组合来构建复杂的运用，其本来的意义包含：
|
||||
|
||||
* 内容管理，文件和数据加载以及本地缓存管理等。
|
||||
* 日志和检查点备份，压缩，快照等。
|
||||
* 监听数据变化，跟踪日志，日志和监控代理，消息发布等。
|
||||
* 代理，网桥
|
||||
* 控制器，管理，配置以及更新
|
||||
|
||||
### 替代方案
|
||||
|
||||
为什么不在一个单一的容器里运行多个程序？
|
||||
|
||||
* 1.透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。
|
||||
* 2.解偶软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes必须支持热发布和热更新（将来）。
|
||||
* 3.方便使用。用户不必运行独立的程序管理，也不用担心每个运用程序的退出状态。
|
||||
* 4.高效。考虑到基础设施有更多的职责，容器必须要轻量化。
|
||||
|
||||
### 容器组的生命状态
|
||||
|
||||
包括若干状态值：pending、running、succeeded、failed。
|
||||
|
||||
#### pending
|
||||
|
||||
容器组已经被节点接受，但有一个或多个容器还没有运行起来。这将包含某些节点正在下载镜像的时间，这种情形会依赖于网络情况。
|
||||
|
||||
#### running
|
||||
|
||||
容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态（或者处于重启状态）。
|
||||
|
||||
#### succeeded
|
||||
|
||||
所有的容器都正常退出。
|
||||
|
||||
#### failed
|
||||
|
||||
容器组中所有容器都意外中断了。
|
||||
|
||||
### 容器组生命周期
|
||||
|
||||
通常来说，如果容器组被创建了就不会自动销毁，除非被某种行为出发，而触发此种情况可能是人为，或者复制控制器所为。唯一例外的是容器组由 succeeded状态成功退出，或者在一定时间内重试多次依然失败。
|
||||
|
||||
如果某个节点死掉或者不能连接，那么节点控制器将会标记其上的容器组的状态为 `failed`。
|
||||
|
||||
举例如下。
|
||||
|
||||
* 容器组状态 `running`，有 1 容器，容器正常退出
|
||||
* 记录完成事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：容器组变为 `succeeded`
|
||||
* 从不：容器组变为 `succeeded`
|
||||
* 容器组状态 `running`，有1容器，容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，有2容器，有1容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组保持 `running`
|
||||
* 当有2容器退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，容器内存不足
|
||||
* 标记容器错误中断
|
||||
* 记录内存不足事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：记录错误事件，容器组变为 `failed`
|
||||
* 容器组状态 `running`，一块磁盘死掉
|
||||
* 杀死所有容器
|
||||
* 记录事件
|
||||
* 容器组变为 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
* 容器组状态 `running`，对应的节点段溢出
|
||||
* 节点控制器等到超时
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
|
||||
## Replication Controllers
|
||||
## 服务
|
||||
## 卷
|
||||
## 标签
|
||||
## 接口权限
|
||||
## web界面
|
||||
## 命令行操作
|
||||
|
|
@ -1,193 +1,10 @@
|
|||
# 基本架构和基本概念
|
||||
# 基本架构
|
||||
|
||||
任何优秀的项目都离不开好的架构和设计蓝图，在本小节，我们将来看一看Kubernetes是如何规划它的架构。为了理解和使用Kubernets，我们需要了解Kubernetes的基本概念和作用。
|
||||
任何优秀的项目都离不开好的架构和设计蓝图，在本小节，我们将来看一看Kubernetes 是如何规划它的架构。
|
||||
|
||||
## 架构设计
|
||||
|
||||
|
||||
* [节点](#nodes)：一个节点是一个运行 Kubernetes 中的主机。
|
||||
* [容器组](#pods)：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。
|
||||
* [容器组生命周期](#pos-states)：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及replication controllers。
|
||||
* [Replication Controllers](#replication-controllers)：主要负责指定数量的pod在同一时间一起运行。
|
||||
* [服务](#services)：一个Kubernetes服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。
|
||||
* [卷](#volumes)：一个卷就是一个目录，容器对其有访问权限。
|
||||
* [标签](#labels)：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
|
||||
* [接口权限](#accessing_the_api)：端口，ip地址和代理的防火墙规则。
|
||||
* [web界面](#ux)：用户可以通过web界面操作Kubernetes。
|
||||
* [命令行操作](#cli)：`kubecfg`命令。
|
||||
|
||||
|
||||
|
||||
<h3 id="nodes">节点</h3>
|
||||
|
||||
### 什么是节点
|
||||
|
||||
在Kubernetes中，节点是实际工作的点，以前叫做Minion。节点可以是虚拟机或者物理机器，依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组，并且它们都可以通过主节点来管理。必要服务包括docker，kubelet和网络代理。
|
||||
|
||||
### 容器状态
|
||||
|
||||
容器状态用来描述节点的当前状态。现在，其中包含三个信息：
|
||||
|
||||
##### 主机IP
|
||||
|
||||
主机IP需要云平台来查询，Kubernetes把它作为状态的一部分来保存。如果Kubernetes没有运行在云平台上，节点ID就是必需的。IP地址可以变化，并且可以包含多种类型的IP地址，如公共IP，私有IP，动态IP，ipv6等等。
|
||||
|
||||
##### 节点周期
|
||||
|
||||
通常来说节点有 `Pending`，`Running`，`Terminated`三个周期，如果Kubernetes发现了一个节点并且其可用，那么Kubernetes就把它标记为 `Pending`。然后在某个时刻，Kubernetes将会标记其为 `Running`。节点的结束周期称为 `Terminated`。一个已经terminated的节点不会接受和调度任何请求，并且已经在其上运行的容器组也会删除。
|
||||
|
||||
##### 节点状态
|
||||
|
||||
节点的状态主要是用来描述处于 `Running`的节点。当前可用的有 `NodeReachable` 和 `NodeReady` 。以后可能会增加其他状态。`NodeReachable` 表示集群可达。`NodeReady`表示kubelet返回 StatusOk并且HTTP状态检查健康。
|
||||
|
||||
##### 节点管理
|
||||
|
||||
节点并非Kubernetes创建，而是由云平台创建，或者就是物理机器、虚拟机。在Kubernetes中，节点仅仅是一条记录，节点创建之后，Kubernetes会检查其是否可用。在Kubernetes中，节点用如下结构保存：
|
||||
|
||||
```
|
||||
{
|
||||
"id": "10.1.2.3",
|
||||
"kind": "Minion",
|
||||
"apiVersion": "v1beta1",
|
||||
"resources": {
|
||||
"capacity": {
|
||||
"cpu": 1000,
|
||||
"memory": 1073741824
|
||||
},
|
||||
},
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node",
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Kubernetes校验节点可用依赖于id。在当前的版本中，有两个接口可以用来管理节点：节点控制和Kube管理。
|
||||
|
||||
##### 节点控制
|
||||
|
||||
在Kubernetes主节点中，节点控制器是用来管理节点的组件。主要包含：
|
||||
* 集群范围内节点同步
|
||||
* 单节点生命周期管理
|
||||
|
||||
节点控制有一个同步轮寻，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮寻。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在Kubernetes启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl`来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步，你也可以使用api/kubectl 命令行来增删节点。
|
||||
|
||||
<h3 id="pods">容器组</h3>
|
||||
|
||||
在Kubernetes中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。
|
||||
|
||||
#### 什么是容器组
|
||||
|
||||
一个容器组使用相同的Dokcer容器并共享卷（挂载点）。一个容器组是一个特定运用的打包集合，包含一个或多个容器。
|
||||
|
||||
和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，知道容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）。
|
||||
|
||||
### 容器组设计的初衷
|
||||
|
||||
#### 资源共享和通信
|
||||
|
||||
容器组主要是为了数据共享和它们之间的通信。
|
||||
|
||||
在一个容器组中，容器都使用相同的网络地址和端口，可以通过本地网络来相互通信。每个容器组都有独立的ip，可用通过网络来和其他物理主机或者容器通信。
|
||||
|
||||
容器组有一组存储卷（挂载点），主要是为了让容器在重启之后可以不丢失数据。
|
||||
|
||||
#### 容器组管理
|
||||
|
||||
容器组是一个运用管理和部署的高层次抽象，同时也是一组容器的接口。容器组是部署、水平放缩的最小单位。
|
||||
|
||||
### 容器组的使用
|
||||
|
||||
容器组可以通过组合来构建复杂的运用，其本来的意义包含：
|
||||
|
||||
* 内容管理，文件和数据加载以及本地缓存管理等。
|
||||
* 日志和检查点备份，压缩，快照等。
|
||||
* 监听数据变化，跟踪日志，日志和监控代理，消息发布等。
|
||||
* 代理，网桥
|
||||
* 控制器，管理，配置以及更新
|
||||
|
||||
### 替代方案
|
||||
|
||||
为什么不在一个单一的容器里运行多个程序？
|
||||
|
||||
* 1.透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。
|
||||
* 2.解偶软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes必须支持热发布和热更新（将来）。
|
||||
* 3.方便使用。用户不必运行独立的程序管理，也不用担心每个运用程序的退出状态。
|
||||
* 4.高效。考虑到基础设施有更多的职责，容器必须要轻量化。
|
||||
|
||||
<h3 id="pos-states">容器组生命周期</h3>
|
||||
|
||||
本小结将会简单描述容器状态类型，容器组生命周期，事件，重启策略和复制控制器。
|
||||
|
||||
### 状态值
|
||||
|
||||
#### pending
|
||||
|
||||
容器组已经被节点接受，但有一个或多个容器还没有运行起来。这将包含某些节点正在下载镜像的时间，这种情形会依赖于网络情况。
|
||||
|
||||
#### running
|
||||
|
||||
容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态（或者处于重启状态）。
|
||||
|
||||
#### succeeded
|
||||
|
||||
所有的容器都正常退出。
|
||||
|
||||
#### failed
|
||||
|
||||
容器组中所有容器都意外中断了。
|
||||
|
||||
### 容器组生命周期
|
||||
|
||||
通常来说，如果容器组被创建了就不会自动销毁，除非被某种行为出发，而触发此种情况可能是人为，或者复制控制器所为。唯一例外的是容器组由 succeeded状态成功退出，或者在一定时间内重试多次依然失败。
|
||||
|
||||
如果某个节点死掉或者不能连接，那么节点控制器将会标记其上的容器组的状态为 `failed`。
|
||||
|
||||
### 举例
|
||||
|
||||
* 容器组状态 `running`，有1容器，容器正常退出
|
||||
* 记录完成事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：容器组变为 `succeeded`
|
||||
* 从不：容器组变为 `succeeded`
|
||||
* 容器组状态 `running`，有1容器，容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，有2容器，有1容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组保持 `running`
|
||||
* 当有2容器退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，容器内存不足
|
||||
* 标记容器错误中断
|
||||
* 记录内存不足事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：记录错误事件，容器组变为 `failed`
|
||||
* 容器组状态 `running`，一块磁盘死掉
|
||||
* 杀死所有容器
|
||||
* 记录事件
|
||||
* 容器组变为 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
* 容器组状态 `running`，对应的节点段溢出
|
||||
* 节点控制器等到超时
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
|
||||
<h3 id="replication-controllers">Replication Controllers</h3>
|
||||
<h3 id="services">服务</h3>
|
||||
<h3 id="volumes">卷</h3>
|
||||
<h3 id="labels">标签</h3>
|
||||
<h3 id="accessing_the_api">接口权限</h3>
|
||||
<h3 id="ux">web界面</h3>
|
||||
<h3 id="cli">命令行操作</h3>
|
||||
* ref: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/architecture.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue