Kubernetes（K8s）_08_Pod升级
Kubernetes（K8s）_08_Pod升级
- Pod升级
- Pod升级
-
- Deployment
-
- 创建Deployment
- Deployment优点
- StatefulSet
-
- 创建StatefulSet
Pod升级
Pod升级方式分为3种：
（1）删除所有的旧Pod，再创建新Pod
1）缺陷：导致应用在一定时间内的不可用
如：实现RS控制的Pod升级
Pod升级
Pod升级方式分为3种：
（1）删除所有的旧Pod，再创建新Pod
1）缺陷：导致应用在一定时间内的不可用
如：实现RS控制的Pod升级
（2）先创建所有新Pod（待成功运行后），再删除所有旧Pod（蓝绿部署）
1）缺陷：应用需同时支持两个版本的Pod，占用较多资源；
2）一般通过修改SVC的标签选择器实现（将SVC转移到新Pod）；
如：实现RS和SVC控制的Pod升级
（3）按顺序创建新Pod，并逐渐删除旧Pod（滚动升级）
1）缺陷：应用需同时支持两个版本的Pod
如：通过多个RS实现Pod的升级
rolling-update命令：通过自动扩缩容实现自动滚动升级
指令格式：kubectl rolling-update 旧控制器 新控制器 --image=新镜像
1）控制器可为RC、RS或DS
2）通过rolling-update命令升级时：新旧Pod都会添加不同的deployment标签，对应控制器的标签选择器，新旧标签选择器都会添加不同的deployment值，对应控制Pod的标签
3）该扩缩容过程是由kubectl客户端执行的；
4）若升级时，其他因素影响导致升级中断，则Pod和控制器处于中间态
//如：网络中断后再恢复网络，Pod和控制器就处于不可用状态
Deployment
Deployment：声明式更新
1）Deployment属于Kubernetes的一种资源类型；
2）Deployment是基于ReplicaSet实现；
3）Deployment只需指定Pod所需到达的状态，由Kubernetes处理中间过程；
Deployment的升级策略分为两种：
（1）RollingUpdate策略（默认）：
1）渐进地删除旧Pod，并同时创建新Pod；
2）确保应用在整个升级过程中都处于可用状态；
3）应用需能够支持多个版本同时运行
4）升级过程中Pod数量在期望值的指定区间内浮动（可配置）；
（2）Recreatece策略：
1）先删除所有旧Pod，再创建新Pod；
2）会导致应用一段时间的不可用；
创建Deployment
创建一个Deployment时，会自动创建一个ReplicaSet
1）升级Pod时，Pod是由ReplicaSet共同创建和管理的
2）由Deployment声明创建的Pod和RS名称都含有Pod模板的哈希值
//哈希值的位置为：Pod名称的中间，RS名称的后缀
创建Deployment格式（其他部分省略），升级策略为RollingUpdate：
apiVersion： apps/v1
kind： Deployment
metadata：
name： Deployment名称
spec：
replicas： 期望值
minReadySeconds： 数值
startegy：
rollingUpdate：
maxSurge： 数值
maxUnavailable： 数值
type： RollingUpdate
template：
metadata：
name： Pod的名称
labels：
标签名： 标签值
spec：
containers：
- image： 容器基于的镜像
name： 容器的名称
（1）minReadySeconds字段指定Pod至少运行多长时间，才视为可用
1）单位为秒；
2）升级过程中，一个Pod不能正常运行，则滚动升级不会继续；
（2）通过maxSurge字段和maxUnavailable字段可控制升级速率；
1）maxSurge字段：指定相对于期望值，最多可超出Pod数量；
2）maxUnavailable字段：指定相对于期望值，最多可有不可用Pod数量；
（3）新版中必须指定spec.selector字段
如：创建Deployment，以实现滚动升级
1）编写YAML文件
2）调用create命令生成Deployment，并记录历史版本
3）列出所创建的Pod和ReplicaSet
//若创建Pod的标签和之前的SVC的标签选择器匹配，则可使用SVC访问
Deployment优点
当Pod模板被修改时，Deployment会调用RS指向新的Pod模板，并生成Pod
1）会生成新的RS以生成新Pod，且旧的RS会保留（RS记录历史版本）；
2）可通过rollout命令，控制滚动升级的流程
rollout命令：控制滚动升级过程
指令参数：kubectl rollout 选项 Deployment名称
| 选项 | 含义 |
|---|---|
| status | 列出升级过程/状态 |
| undo | 回滚升级（取消最近一次的滚动升级） |
| history | 显示升级的历史版本 |
| pause | 暂停滚动升级（金丝雀发布） |
| resume | 恢复滚动升级 |
1）undo可通过“–to-revision=版本号”回滚到指定版本
2）可通过Deployment的YAML文件中的revisionHistoryLimit字段指定最多可含有历史版本数（若不指定，默认为2）
3）若历史版本被删除，则连同RS一起删除；
4）暂停滚动升级，可使部分Pod被升级，其他Pod还旧版本；
5）当恢复滚动升级时，将把所有旧Pod更替为新Pod
如：通过修改Pod模板，触发滚动升级
1）修改Pod模板，并验证
2）查看是否升级成功
如：通过修改Pod模板，触发滚动升级，并回滚
1）修改Pod，列出升级过程
2）回滚上一次的升级
如：回滚到指定历史版本
//最大的数代表的是当前版本（如：第一次显示的10，第二次显示的11）
Deployment定义中的Pod模板可包含就绪探针
1）实现自动阻止出错版本的滚动升级；
//就绪探针检测失败，则Pod无法正常运行，导致升级失败
2）默认情况下，10分钟中不能完成滚动升级，则回滚到上一个版本；
3）可通过progressDeadlineSeconds（位于spec字段下）指定超时时间；
如：创建含有就绪探针的Deployment
StatefulSet
**StatefulSet：**管理/创建有状态的Pod
1）StatefulSet可指定Pod的期望值和Pod模板；
2）根据Pod模板创建的Pod并不完全一致（每个Pod拥有独立的数据卷）
3）创建StatefulSet时，要求创建headless SVC用于记录每个Pod网络标识；
4）StatefulSet必须确保有且仅有一个有状态的Pod在运行（at-most-one）；
StatefulSet创建的Pod名称具有规律：
1）每个Pod都有一个从零开始的顺序索引；
2）Pod的名称是由StatefulSet名称加上顺序索引值组成；
3）Pod的主机名和数据卷也具有该效果（确保不丢失状态）；
//RC、RS和DS则是根据控制器名称，再随机命名Pod
如：StatefulSet创建具有规律的Pod名称
StatefulSet管理的Pod所在节点宕机时，StatefulSet会在其他节点上重建该Pod
1）新Pod和旧Pod拥有相同的名称、网络标识和状态；
2）即使新Pod被调度到其他节点上，同样可通过主机名访问；
如：当StatefulSet管理的Pod所在节点宕机时
StatefulSet管理的Pod进行扩缩容时，可明确对Pod的处理
1）当缩容时，优先删除顺序索引值最高的Pod；
2）当扩容时，则添加比当前最高索引值还高的Pod；
//若缩容后再扩容，则优先创建被缩容的Pod（使用其名称和状态等）
3）当有Pod不健康时，不允许进行缩容操作（防止数据丢失）；
如：StatefulSet管理的Pod进行缩容
StatefulSet定义中具有1个或多个PVC模板
1）PVC会在Pod创建前，根据PVC模板进行创建；
2）当扩容Pod时，会自动根据PVC模板创建PVC；
3）当缩容/删除Pod时，仅删除Pod，保留PVC（需手动删除该PVC）；
//由于PVC和PV是一对一绑定的关系，所以PV也会被保留；
4）当缩容后再进行扩容，新Pod会绑定到被保留的PVC（确保状态一致）；
如：StefulSet根据1个或多个PVC模板创建PVC
如：StatefulSet缩容是不删除PVC，等扩容时优先选择该PVC
创建StatefulSet
1）部署StatefulSet前，必须先创建headless SVC以提供Pod的网络标识
2）StatefulSet创建Pod时，需前一个创建成功并运行，才会创建下一个
创建StatefulSet格式：
apiVersion： apps/v1
kind： StatefulSet
metadata：
name： StatefulSet名称
spec：
serviceName： headless SVC的名称
replicas： 期望值
template：
Pod模板
volumeClaimTemplates：
PVC模板
如：部署Statefulset
1）创建headless SVC
2）编写StatefulSet的YAML文件
3）调用create命令生成StatefulSet，并验证
