deployment

一、更新运行在pod内的应用程序

1. pod在创建后，不允许直接修改镜像，只能通过删除原有pod并使用新的镜像创建新的pod替换
2. 更新方式：
   1）直接删除现有pod，然后创建新的pod（会导致服务在一定时间内不可用）
   2）先创建新的pod，在删除旧的pod（新旧版本同时运行时，在旧版本未完全退出前，新版本不可对数据库进行写操作，否则导致数据库数据异常）

 

二、更新pod的三种方式（使用ReplicationController管理pod）

1. 删除旧的，创建新的（允许服务出现短暂的不可用状态）
   1）直接将pod的模板镜像修改为新版本的镜像
   2）删除旧的pod，ReplicationController会检测到pod未达到预期状态，使用pod模板重建新的pod
2. 先创建新版本的pod再删除旧版本的pod（服务不允许停止服务，但是允许不同版本同时运行，在短时间会使用双倍的资源）
   1）创建新的pod，但是labels与原来的不一样
   2）service将labels从旧的指向新的labels
3. 滚动升级
   1）通过伸缩两个RC将旧pod替换为新的pod（新的RC创建一个pod，旧的RC旧缩减一个pod）
   2）升级过程中Service将请求同时负载到新旧两个版本的pod
   3）滚动升级已过时：原因：ReplicationController副本数的伸缩请求由kubectl客户端执行的，若升级过程中网络中断，升级过程将会中断，pod和replicationController最终会处于中间状态
    

 

三、Deployment简介

1. deployment是一种更高阶资源，用于部署应用程序并以声明的方式升级应用
2. 创建deployment时会跟随创建replicaSet（RC的替代升级版）
3. 实际的pod是由deployment的replicaSet创建和管理
4. 实际功能：
   1）在滚动升级过程从会使用两个RC（ReplicationController缩写）
   2）deployment用于协调两个RC，使他们根据彼此不断修改
5. 注意：
   1）在extensions/v1beta1中找到Deployment资源的旧版本
   2）在apps/v1beta2中找到新版本；他们有不同的必须字段和不同的默认值
   3）kubectl explain 显示的是旧版本
6. 在创建deployment时使用--record参数：记录历史版本号（用于回滚）
7. pod的命名：由Controller的名称+随机字符串

四、Deployment更新策略

1. 默认：RollingUpdate：滚动更新：逐步删除旧的pod，并创建新的pod
   1）升级过程中服务不中断（中途可以同时访问新旧两个版本）
   2）升级过程中pod的数量会在一定区间浮动（上限和下限可配置）
   3）应用允许同时以多个版本对外提供服务
2. Recreate：删除旧的，再创建新的
   1）程序不支持多个版本同时对外提供服务的场景
   2）服务会出现短暂的不可用）

 

 

备注：如果Deployment中的pod模板引用了一个ConfigMap（或Secret），那么更改ConfigMap资源本身将不会触发升级操作；

若想修改configMap触发更新，可以通过创建一个新的Config并修改pod模板引用新的configMap

 

五、滚动升级和回滚

1、更新指定deploy的镜像

kubectl set image deploy kubia nodejs=luksa/kubia:v3    

 

2、显示升级的版本

kubectl rollout history deploy kubia    

 

3、显示版本1的详细信息

kubectl rollout history deploy kubia --revision=1    

 

4、回滚升级，回滚到上个版本（取消升级）

kubectl rollout undo deploy kubia    

 

5、回滚到特定版本

kubectl rollout undo deploy kubia --to-revision=1   

 

6、暂停滚动升级，这不会触发超过deadline的状态

kubectl rollout pause deployment kubia    

 

7、恢复滚动升级

kubectl rollout resume deployment kubia

 

8、查看回滚状态

kubectl rollout status deployment kubia    

 

注意：deployment的依赖replicaSet，如果删除replicaSet则无法正常回滚

 

maxUnavailabel属性

 

 

六、模拟金丝雀升级

1. 金丝雀发布：将升级发布到小部分用户，大部分用户依旧使用旧版本
2. 在滚动升级过程中暂停升级，此时有大部分pod处于新版本，小部分处于旧版本（可以模拟金丝雀）
3. 恢复滚动升级：将根据之前的更新继续进行更新操作
4. 正确的金丝雀方式：
   1）第一个deploy运行旧版本的pod
   2）第二个deploy运行新版本的pod（控制数量及访问方式）

 

七、就绪探针：阻止出错版本的升级

1. HTTP GET：
   1）对容器的IP地址（指定端口和路径）执行HTTP GET请求
   2）若返回响应码不代表错误(2xx或3xx），则认为成功
   3）若返回错误代码，或无响应则重启容器
2. TCP套接字：
   1）尝试与容器指定端口建立TCP链接，
   2）链接成功则检测成功
   3）链接失败则重启容器
3. Exec：
   1）在容器内执行任意命令，并检测命令的退出状态码
   2）返回状态码为0，则检测成功
   3）返回状态码非0，则检测失败，重启容器
4. 当pod启动时，就绪探针会每隔一秒发起请求

八、小结：本章内容

1.  通过更新deployment的模板来更新pod
2. 回滚deployment、回滚到指定版本、暂停回滚、恢复回滚、查看回滚状态