Kubernetes（K8s）_08_Pod升级

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，并验证