mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-10 20:04:36 +00:00
GitBook: No commit message
This commit is contained in:
yeasy
gitbook-bot
@@ -1,6 +1,6 @@
|
||||
# 基本概念
|
||||
|
||||
|
||||
|
||||
|
||||
* 节点（`Node`）：一个节点是一个运行 Kubernetes 中的主机。
|
||||
* 容器组（`Pod`）：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。
|
||||
@@ -59,15 +59,15 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
|
||||
### 节点控制
|
||||
|
||||
在 Kubernetes 主节点中，节点控制器是用来管理节点的组件。主要包含：
|
||||
|
||||
* 集群范围内节点同步
|
||||
* 单节点生命周期管理
|
||||
|
||||
节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。
|
||||
节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。
|
||||
|
||||
## 容器组
|
||||
|
||||
在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。
|
||||
一个容器组使用相同的 Docker 容器并共享卷（挂载点）。一个容器组是一个特定应用的打包集合，包含一个或多个容器。
|
||||
在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。 一个容器组使用相同的 Docker 容器并共享卷（挂载点）。一个容器组是一个特定应用的打包集合，包含一个或多个容器。
|
||||
|
||||
和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，直到容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）。
|
||||
|
||||
@@ -133,50 +133,56 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
|
||||
举例如下。
|
||||
|
||||
* 容器组状态 `running`，有 1 容器，容器正常退出
|
||||
* 记录完成事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：容器组变为 `succeeded`
|
||||
* 从不：容器组变为 `succeeded`
|
||||
* 记录完成事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：容器组变为 `succeeded`
|
||||
* 从不：容器组变为 `succeeded`
|
||||
* 容器组状态 `running`，有1容器，容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，有2容器，有1容器异常退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组保持 `running`
|
||||
* 当有2容器退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，容器内存不足
|
||||
* 标记容器错误中断
|
||||
* 记录内存不足事件
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组保持 `running`
|
||||
* 当有2容器退出
|
||||
* 记录失败事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：记录错误事件，容器组变为 `failed`
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：容器组变为 `failed`
|
||||
* 容器组状态 `running`，容器内存不足
|
||||
* 标记容器错误中断
|
||||
* 记录内存不足事件
|
||||
* 如果重启策略为：
|
||||
* 始终：重启容器，容器组保持 `running`
|
||||
* 失败时：重启容器，容器组保持 `running`
|
||||
* 从不：记录错误事件，容器组变为 `failed`
|
||||
* 容器组状态 `running`，一块磁盘死掉
|
||||
* 杀死所有容器
|
||||
* 记录事件
|
||||
* 容器组变为 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
* 杀死所有容器
|
||||
* 记录事件
|
||||
* 容器组变为 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
* 容器组状态 `running`，对应的节点段溢出
|
||||
* 节点控制器等到超时
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
* 节点控制器等到超时
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
|
||||
## Replication Controllers
|
||||
|
||||
## 服务
|
||||
|
||||
## 卷
|
||||
|
||||
## 标签
|
||||
|
||||
## 接口权限
|
||||
|
||||
## web界面
|
||||
|
||||
## 命令行操作
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
# 基本架构
|
||||
# 架构设计
|
||||
|
||||
任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。
|
||||
|
||||
## 基本考虑
|
||||
|
||||
如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的：
|
||||
|
||||
* 分布式架构，保证扩展性；
|
||||
* 逻辑集中式的控制平面 + 物理分布式的运行平面；
|
||||
* 一套资源调度系统，管理哪个容器该分配到哪个节点上；
|
||||
@@ -13,7 +15,7 @@
|
||||
|
||||
下面这张图完整展示了 Kubernetes 的运行原理。
|
||||
|
||||
|
||||
|
||||
|
||||
可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（Master Node）；一类是属于运行平面的工作节点（Worker Node）。
|
||||
|
||||
@@ -22,6 +24,7 @@
|
||||
从这张图上，我们没有能发现 Kubernetes 中对于控制平面的分布式实现，但是由于数据后端自身就是一套分布式的数据库 Etcd，因此可以很容易扩展到分布式实现。
|
||||
|
||||
## 控制平面
|
||||
|
||||
### 主节点服务
|
||||
|
||||
主节点上需要提供如下的管理服务：
|
||||
@@ -31,6 +34,7 @@
|
||||
* `controller-manager` 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。
|
||||
|
||||
### Etcd
|
||||
|
||||
这里 Etcd 即作为数据后端，又作为消息中间件。
|
||||
|
||||
通过 Etcd 来存储所有的主节点上的状态信息，很容易实现主节点的分布式扩展。
|
||||
@@ -38,7 +42,8 @@
|
||||
组件可以自动的去侦测 Etcd 中的数值变化来获得通知，并且获得更新后的数据来执行相应的操作。
|
||||
|
||||
## 工作节点
|
||||
|
||||
* kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
|
||||
* kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（同一类标签）。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 项目简介
|
||||
# 简介
|
||||
|
||||
|
||||
|
||||
|
||||
Kubernetes 是 Google 团队发起的开源项目，它的目标是管理跨多个主机的容器，提供基本的部署，维护以及应用伸缩，主要实现语言为 Go 语言。Kubernetes 是：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user