k8s 之 滚动更新

背景

公司做的是医院的院内系统,医院存在24小时的急诊,所以需要程序7*24小时不间断;
在程序更新的时候,就需要滚动更新。

Docker Swarm中的滚动更新

目前公司部署使用的是docker swarm,对滚动更新的支持相当不友好;
假设某个服务需要同时启动5个实例才能保证上午高峰期的访问,
一般来说只需要部署一个service加5个replicas即可

version: '3.3'
services:
  svc:
    image: xxx:1.0.0
    deploy:
      # 部署5个副本
      replicas: 5

但是这种部署方式,当我们将服务升级到1.0.1时,会一次性全部重启所有的容器,达不到滚动更新的效果;
不得不将部署方式修改为5个service

version: '3.3'
services:
  svc1:
    image: xxx:1.0.0
  svc2:
    image: xxx:1.0.0
  svc3:
    image: xxx:1.0.0  
  svc4:
    image: xxx:1.0.0
  svc5:
    image: xxx:1.0.0

在配合nginx反向代理

upstream svc {
    server:port1 down;
    server:port2;
    server:port3;
    server:port4;
    server:port5;
}

server {
    listen 80;
    location / {
        proxy_pass http://svc/;
    }
}

在升级svc1时,先修改nginx配置将svc1 down掉,然后修改版本,启动成功后在恢复,在down掉svc2,升级恢复,以此内推。

缺点:需要消耗多个端口且更新过程繁琐。
优点:过程相对可控,假设升级第一个时发现问题,可及时回退。

k8s 滚动升级

k8s滚动升级配置相当简单

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-svc
spec:
  replicas: 5
  selector:
    matchLabels:
      app: svc
  # 服务启动到就绪需要的时间
  minReadySeconds: 30
  strategy:
    rollingUpdate:
      # Pod 数量可以超过定义的数量
      maxSurge: 1               
      # 和期望ready的副本数比,不可用副本数最大比例(或最大值)
      maxUnavailable: 0        
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: svc
    spec:
      restartPolicy: Always
      containers:
      - name: svc
        image: xxx:1.0.0

升级时只需要修改版本号即可,k8s将自动进行滚动更新。

缺点:过程不太可控,假设升级第一个时发现问题,不能及时回退(这个缺点只是我没发现怎么解决,相信有解决方式)。
优点:操作非常简单

posted @ 2023-02-26 23:19  whyfate  阅读(584)  评论(0编辑  收藏  举报