Kubernetes系列(四) - Pod和Pod调度
目录
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
