持续部署入门：基于 Kubernetes 实现滚动发布

前言

软件世界比以往任什么时候候都更快。为了保持竞争力，须要尽快推出新的软件版本，而不会中断活跃用户访问，影响用户体验。愈来愈多企业已将其应用迁移到 Kubernetes。

在 Kubernetes 中有几种不一样的方式发布应用，因此为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就很是重要了，本篇文章将讲解如何在 Kubernetes 使用滚动更新的方式更新镜像。

原理

策略定义为 RollingUpdate 的 Deployment。滚动更新经过逐个替换实例来逐步部署新版本的应用，直到全部实例都被替换完成为止，会有新版旧版同时存在的状况。

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0			# 决定了配置中指望的副本数以外，最多容许超出的 pod 实例的数量
      maxUnavailable: %25	# 决定了在滚动升级期间，相对于指望副本数可以容许有多少 pod 实例处于不可用状态

上述更新策略执行结果以下图所示

实践

使用 Kubernetes 原生方式升级应用

准备

image

bebullish/demo:v1
bebullish/demo:v2

deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-dp
spec:
  selector:
    matchLabels:
      app: demo
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: demo
    spec: 
      containers:
      - name: demo
        image: bebullish/demo:v1
        ports:
        - containerPort: 8080

service

apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  selector:
    app: demo
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

将上述 deployment 以及 service 保存为 yaml 文件，使用 kubectl apply -f 命令建立 yaml 资源，等待建立成功后，使用 kubectl get svc 获取 EXTERNAL-IP。

测试

若是使用浏览器测试的话，你会发现每次调用都会返回同一个 pod 的名字，那是由于浏览器发出的请求包含 keepAlive，因此须要使用 curl 来保证每次发出的请求都是从新建立的。

curl -X GET http://${EXTERNAL-IP}

升级

升级以前先执行命令，以便查看镜像更新过程

while true; do curl -X GET http://${EXTERNAL-IP} ; done

更新镜像

kubectl set image deployment demo-dp demo=bebullish/demo:v2

查看日志

请求流量

结论

首先能够发如今更新过程当中，程序保持一直可用的状态，在出现了 v2 版本以后，还会出现 v1 版本的日志，说明在这个期间 v1 和 v2 版本是同时存在的，等到 v2 版本的 pod 所有处于就绪状态以后，能够看到全部的请求就都是 v2 版本的了。

使用 CODING CD 方式升级应用

配置制品

使用 docker 官方镜像须要以 docker.io 开头

配置 yaml 及绑定制品

deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-dp
spec:
  selector:
    matchLabels:
      app: demo
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: demo
    spec: 
      containers:
      - name: demo
        image: docker.io/bebullish/demo
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30           # 延迟 30 秒检测，以便更好的观察更新过程
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30           # 延迟 30 秒检测，以便更好的观察更新过程
          periodSeconds: 5
      terminationGracePeriodSeconds: 1      # 处于 Terminating 状态多久后，强制杀死 pod

阶段中选择 部署（Manifest） ，输入上述 yaml 文件（主要增长了就绪探针和存活探针），这里须要把镜像的版本删除掉，在须要绑定的制品选择以前配置的制品。这样配置以后，每次执行的时候版本是动态传入的。

发布制品

选择应用和部署流程，输入版本 v1。

查看结果

等待一小段时间后，就能够在部署控制台中看到发布的资源了。

更新镜像版本

再次执行发布，版本输入 v2。

更新过程

能够看到此时 v2 版本的 pod 有一个正在启动，而 v1 版本的 pod 所有处于就绪状态。

v2 版本的 pod 有一个已经就绪，同时正在启动另外一个新的 pod，与此同时 v1 版本的有一个 pod 已经关机了，而另外两个 pod 仍处于就绪状态。

v2 版本的 pod 有两个已经就绪，同时正在启动最后一个新的 pod，与此同时 v1 版本的有两个 pod 已经关机了，而另一个 pod 仍处于就绪状态。

v2 版本的 pod 已经所有处于就绪状态了，同时 v1 版本的 pod 已经所有关机，至此，一次滚动更新结束。

总结

使用 Kubernetes 原生方式实现滚动更新更加简单方便，但也容易出错（人工），推荐使用 coding.net 提供的 CD 功能，配置一次，永久使用。不只能够直观的观察到 pod 更新过程，还提供了很是丰富的 CD 功能，推荐使用哦~

参考文章

Kuerbenetes

CODING 持续部署

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！