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启动时,就绪探针会每隔一秒发起请求