Kubernetes第六篇：k8s的四种部署策略

Posted 2022-07-31 毛奇志

文章目录

• 一、前言
• 二、滚动更新
• • 2.1 滚动更新
  • 2.2 实践
  • • 2.2.1 新建两个springboot项目，生成两个镜像
    • 2.2.2 kubectl apply启动
    • 2.2.3 将版本修改为v2.0 ，kubectl apply重新部署
• 三、重新创建
• • 3.1 重新创建
  • 3.2 实践
  • • 3.2.1 kubectl apply启动
    • 3.2.2 将版本修改为v2.0 ，kubectl apply重新部署
• 四、蓝绿部署(一键切换)
• • 4.1 蓝绿部署
  • • 4.1.1 编写 bluegreen.yaml
    • 4.1.2 修改bluegreen.yaml
    • 4.1.3 修改bluegreen-service.yaml
  • 4.2 实践
  • • 4.2.1 部署blue.yaml和green.yaml
    • 4.2.2 部署bluegreenservice.yaml
    • 4.2.3 修改service-selector即可完成一键切换
• 五、金丝雀
• • 5.1 金丝雀灰度部署
  • 5.2 实践
• 六、尾声

一、前言

四种部署方案

滚动更新：切换过程中，存在pod新老版本共存 默认是滚动更新 缺省是滚动更新

重新创建：v1版本都干掉之后，然后再上v2版本，缺点：可能存在服务某段时间服务不可用，这个无法避免。
效果：四个都Terminating 四个都Pending 四个ContainerCreating 四个Running。

蓝绿部署：不是特定类型，而是对滚动更新蓝绿控制，通过selector一键切换

金丝雀：又称为灰度部署或者AB测试，通过selector配置各个版本比例

vi xxx.yaml + kubectl apply -f xxx.yaml == kubectl edit deployment xxx -n ns-name

部署策略和第一次部署本质区别是什么？
第一次部署：之前没有
部署策略：之前有

部署策略不是调度策略，两回事
部署策略是版本切换方式，在yaml中手动指定，调度策略是哪个pod分配到哪个node上，scheduler 组件默认指定
默认的调度策略是不分配主节点
默认的部署策略是yaml文件中不指定，默认是第一种滚动更新。

二、滚动更新

本质：对一个普通的pod （deployment有4个pod的副本）上，增加了一个滚动更新的策略。

2.1 滚动更新

网盘/课堂源码/rollingupdate.yaml

 kubectl apply -f rollingupdate.yaml 
 kubectl get pods 
 kubectl get svc 
 curl cluster-ip/dockerfile 

maxSurge ：滚动升级时先启动的pod数量
maxUnavailable ：滚动升级时允许的最大unavailable的pod数量

修改rollingupdate.yaml文件，将镜像修改成v2.0

# 在w1上，不断地访问观察输出 
while sleep 0.2;do curl cluster-ip/dockerfile;echo "";done 
# 在w2上，监控pod 
kubectl get pods -w 
# 使得更改生效 
kubectl apply -f rollingupdate.yaml 
kubectl get pods 

服务不会停止，但是整个pod会有新旧并存的情况。先停止旧的pod，然后再创建新的pod，这个过程服务是会间断的。 无需停机，风险较小 01-部署v1的应用（一开始的状态） 所有外部请求的流量都打到这个版本上. 02-部署版本2的应用 版本2的代码与版本1不同(新功能、Bug修复等). 03-将流量从版本1切换到版本2。 04-如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。

conclusion ：发现新旧pod是会共存的，并且可以访问测试看一下

kubectl get pods -w 
kubectl get svc 

可以发现，新老版本的确会共存

2.2 实践

2.2.1 新建两个springboot项目，生成两个镜像

docker run -d --name dockerfile1 springboot-demo-dockerfile1:v1.0

同理可以完成 springboot-demo-dockerfile1:v2.0

然后将 rollingupdate.yaml 文件中的 image 设置为 springboot-demo-dockerfile1:v1.0

2.2.2 kubectl apply启动

2.2.3 将版本修改为v2.0 ，kubectl apply重新部署

将版本修改为v2.0

# 更新操作
vi rollingupdate.yaml
kubectl apply -f rollingupdate.yaml 

三、重新创建

停掉 v1 的四个副本，然后再启动 v2 的四个副本。

3.1 重新创建

网盘/课堂源码/recreate.yaml

kubectl apply -f recreate.yaml 
kubectl get pods 

修改recreate.yaml文件

kubectl apply -f recreate.yaml 
kubectl get pods 

conclusion ：发现pod是先停止，然后再创建新的

NAME READY STATUS RESTARTS AGE 
recreate-655d4868d8-5dqcz 0/1 Terminating 0 2m31s 
recreate-655d4868d8-sb688 0/1 Terminating 0 2m31s 

NAME READY STATUS RESTARTS AGE 
recreate-6f74f4686d-4xkgl 1/1 Running 0 13s 
recreate-6f74f4686d-blrt7 1/1 Running 0 13s 

Have a try

kubectl rollout pause deploy rollingupdate 
kubectl rollout resume deploy rollingupdate 
kubectl rollout undo deploy rollingupdate # 回到上一个版本 

3.2 实践

3.2.1 kubectl apply启动

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: recreate
  replicas: 4
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: recreate
        image: springboot-demo-dockerfile1:v1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080

部署方式使用重新创建，唯一的配置是 spec 下一级的 strategy ，如下：

  strategy:
    type: Recreate

3.2.2 将版本修改为v2.0 ，kubectl apply重新部署

将 image: springboot-demo-dockerfile1:v1.0 修改为 image: springboot-demo-dockerfile1:v2.0

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: recreate
  replicas: 4
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: recreate
        image: springboot-demo-dockerfile1:v2.0
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080

四、蓝绿部署(一键切换)

蓝绿部署：蓝绿部署，service-selector选择器，一键切换

核心：先将v1 v2 都启动起来，然后一键切换，不要 Terminating 原来的（保证deployment name不同即可做到）

滚动更新 的缺点是：切换过程中，可能会出现访问到 v1 的情况
重新创建 的缺点是：切换过程中，可能出现服务端无响应的情况
蓝绿部署就是滚动更新提供的另一种方案，就是v2都启动之后，然后一键切过去，不存在切换过程中访问到v1的情况，可以无缝升级，可以无缝回退。

蓝绿部署 = 无缝切换 + 不会无响应

4.1 蓝绿部署

4.1.1 编写 bluegreen.yaml

resources/deploy-strategy/bluegreen-service.yaml

kubectl apply -f bluegreen.yaml 
kubectl get pods 

kubectl apply -f bluegreen-service.yaml 
kubectl get svc 
# 在w1上不断访问观察 
while sleep 0.3;do curl cluster-ip/dockerfile;echo "";done 

4.1.2 修改bluegreen.yaml

01-deployment-name:blue ---> green 
02-image:v1.0---> v2.0 
03-version:v1.0 ---> v2.0 

kubectl apply -f bluegreen.yaml 
kubectl get pods 
# 同时观察刚才访问的地址有没有变化
可以发现，两个版本就共存了，并且之前访问的地址没有变化 

4.1.3 修改bluegreen-service.yaml

# 也就是把流量切到2.0的版本中 
selector: 
   app: bluegreen 
   version: v2.0 

kubectl apply -f bluegreen-service.yaml 
kubectl get svc 
# 同时观察刚才访问的地址有没有变化 
发现流量已经完全切到了v2.0的版本上

4.2 实践

4.2.1 部署blue.yaml和green.yaml

蓝绿部署deployment这里需要修改三个地方：

name: green 表示不要覆盖掉原来的四个pod
version 表示service和deployment绑定
image 表示程序

将deployment的名称修改为了保存原有的pod不会被删除 (kubectl apply -f xxx.yaml 不会删除之前的blue)，不修改deployment name之前的会被删除的

4.2.2 部署bluegreenservice.yaml

4.2.3 修改service-selector即可完成一键切换

修改service-selector变成 2.0 即可完成一键切换，不需要停止原来的服务

五、金丝雀

金丝雀灰度部署：接上面蓝绿，就是 v1 和 v2 都启动着，service 变动 selector ，分配两种pod 的流量占比

金丝雀

查看 describe 后面八个pod

应用场景： AB 测试 50% v1 50% v2
80% v1 20% v2

5.1 金丝雀灰度部署

修改 bluegreen-service.yaml

selector: 
   app: bluegreen 
   version: v2.0 # 把version删除掉，只是根据bluegreen进行选择

kubectl apply -f bluegreen-service.yaml 
# 同时观察刚才访问的地址有没有变化，istio中就更方便咯 
此时新旧版本能够同时被访问到，AB测试，新功能部署少一些的实例

5.2 实践

六、尾声

k8s的四种部署策略，完成了。

天天打码，天天进步！！