集群介绍

首先，用自然语言来描述一下我们想要部署的“有状态应用”。

1. 是一个“主从复制”（Maser-Slave Replication）的 MySQL 集群；

2. 有 1 个主节点（Master）；

3. 有多个从节点（Slave）；

4. 从节点需要能水平扩展；

5. 所有的写操作，只能在主节点上执行；

6. 读操作可以在所有节点上执行。

背景

无状态应用

一个应用的所有 Pod，是完全一样的。它们互相之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Deployment 就可以通过 Pod 模板创建新的 Pod；不需要的时候，Deployment 就可以“杀掉”任意一个 Pod。这种情况就被称为 “无状态应用”（Stateless Application）

有状态应用

在分布式应用中，它的多个实例之间，往往有依赖关系，比如：主从关系、主备关系。

还有就是数据存储类应用，它的多个实例，往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用失败。

这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就被称为“有状态应用”（Stateful Application）。

简介

Pod 这个看似复杂的 API 对象，实际上就是对容器的进一步抽象和封装而已。

Pod 对象，其实就是容器的升级版。它对容器进行了组合，添加了更多的属性和字段。这就好比给容器集装箱四面安装了吊环，使得 Kubernetes 这架“吊车”，可以更轻松地操作它。

而操作这些“集装箱”的逻辑，都由控制器（Controller）完成

基本概念

Pod，不是容器，是 Kubernetes 项目中的最小编排单位。将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里的一个普通的字段。

Pod 扮演的是传统部署环境里“虚拟机”的角色。这样的设计，是为了使用户从传统环境（虚拟机环境）向 Kubernetes（容器环境）的迁移，更加平滑。

而如果你能把 Pod 看成传统环境里的“机器”、把容器看作是运行在这个“机器”里的“用户程序”，那么很多关于 Pod 对象的设计就非常容易理解了。

到底哪些属性属于 Pod 对象，而又有哪些属性属于 Container 呢？

为什么我们会需要 Pod

Pod，是 Kubernetes 项目中最小的 API 对象。如果换一个更专业的说法，我们可以这样描述：Pod，是 Kubernetes 项目的原子调度单位。

简介

Kubernetes 跟 Docker 等很多项目最大的不同，就在于它不推荐你使用命令行的方式直接运行容器（虽然 Kubernetes 项目也支持这种方式，比如：kubectl run），而是希望你用 YAML 文件的方式，即：把容器的定义、参数、配置，统统记录在一个 YAML 文件中，然后用这样一句指令把它运行起来：

kubectl create -f 我的配置文件

简介

很多时候我们需要用数据卷（Volume）把外面宿主机上的目录或者文件挂载进容器的 Mount Namespace 中，从而达到容器和宿主机共享这些目录或者文件的目的。容器里的应用，也就可以在这些数据卷中新建和写入文件。

准备工作

修改hostsname

1
2
3
4

$ vi /etc/hosts
172.16.198.102 master
172.16.198.103 node1
172.16.198.104 node2

Web 界面 (Dashboard)

Kubernetes Dashboard 是基于网页的 Kubernetes 用户界面。

你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源 （如 Deployment，Job，DaemonSet 等等）。 例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。

Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。