Kubernetes系列(四) - Pod和Pod调度

1. Pod的组成部分
2. Pod的优势
3. Pod的两种分类
- 3.1 普通的pod
- 3.2 静态pod（static pod）
4. 控制器controller的特点

1. Pod的组成部分

一个pod内可以有一到多个用户业务容器
每个pod都会有一个特殊的根容器pause

pause对应的镜像是k8s.gcr.io/pause

2. Pod的优势

由于docker中是没有Pod这个概念的，那为什么会需要pod呢？

一组容器作为一整个单元的情况下，很难对整个单元进行状态判断。引入业务无关且不易死亡的pause作为根容器，它的状态代表了整个整体的状态
pod内多个业务容器共享pause容器的ip和volume。即简化了密切关联的容器之间的通信问题，又解决了文件共享的问题

3. Pod的两种分类

3.1 普通的pod

一旦被创建，会被放入etcd存储中
即控制器管理的pod, 被调度到某一个具体的node
默认情况下如果pod里面的某个container宕机了，k8s会检测到这个问题，并重启这个pod（重启pod里面的所有容器）.如果node直接宕机了，那么就会将该node上的所有pod重新调度到其他的node

3.2 静态pod（static pod）

并没有存放在etcd中
只存放在某个node上的具体文件中

4. 控制器controller的特点

既然前面说到了控制器管理的pod，那么肯定要讲一下controller有什么特点，以及controller管理的pod有什么特点

4.1 Deployment & ReplicaSet & ReplicationController

放到一起说是因为这三者有重复的部分

ReplicaSet (RS)

确保容器应用的副本数达到期望数，即多退少补，比RC多支持了集合式selector。可以独立创建RS，但还是建议通过Deploy创建并管理 RS

Deployment (Deploy)

可以通过Deploy创建并管理RS持续监控副本数量，并维持期望数量, 且deploy可以通过创建多个RS来实现滚动更新以及回滚

ReplicationController (RC)

遗留产物，在新版本被RS取代

4.2 Horizontal Pod Autoscaling (HPA)

翻译：水平pod自动缩放

前言

虽然手动执行kubectl scale也可以实现pod扩容或缩容，但是明显不能满足自动化，智能化的需求

特点

HorizontalPodAutoscaling也是一种资源对象
仅适用与Deployment和RS
HPA有两个版本。V1版本中仅支持根据pod的cpu利用率扩容，在vlalpha中可以根据内存和用户自定义的metric来扩缩容
大概如下的定义，当pod里面的cpu利用率大于80%就扩容，反之亦然

cpu > 80%

min pod: 2

max pod: 10

4.3 StatefulSet

前言

前面介绍的控制器都面向无状态服务。但是现实场景中有很多有状态的，特别是一些复杂的中间件集群，比如mysql集群、mongodb集群、zookeeper集群等，这些集群有一些共同点

每个节点都有共同的身份ID，通过这个ID，集群中的成员可以相互发现并且通信
集群的规模是比较固定的
集群中的每个节点都是有状态的，通常会持久化数据到永久存储中
如果磁盘损坏，集群中的某个节点会损坏，集群功能受损

所以引入了StatefulSet

StatefulSet特性

稳定唯一的网络标识。即重新调度后PodName和HostName不变。给予Headless Service(即没有cluster ip的service)实现的
稳定的持久化存储。通过PV或者PVC来实现。删除Pod时默认不会删除相关联的存储卷
有序部署和收缩。即pod的启动/关闭顺序可以是有序的。给予init containers实现的

4.4 DaemonSet

介绍

DaemonSet确保基本全部(打了污点的除外)node上运行一个副本

DaemonSet特性

DaemonSet也是一种资源
当有node加入集群的时候，DaemonSet会给它创建一个pod，当这个node被移除的时候，这个pod也会被移除
当DaemonSet被移除的时候，所有node上的这个pod都会被移除

DaemonSet经典用法

1.每个节点上都运行一个日志采集程序，比如Logstach等

2.每个节点上都运行一个性能监控程序，比如Prometheis Node Exporter等

4.5 Job

可以通过Job资源对象定义并启动一个批处理任务

4.6 CronJob

特殊的Job