Kubernetes_部署_k8s的四种部署策略(滚动更新、重新创建、金丝雀部署、蓝绿部署)

祖母绿宝石

已于 2024-03-31 20:28:12 修改

阅读量5k

点赞数 5

分类专栏： # Kubernetes部署文章标签： kubernetes 容器云原生

于 2022-06-05 09:04:06 首次发布

本文链接：https://blog.csdn.net/qq_36963950/article/details/125128594

版权

Kubernetes部署专栏收录该内容

7 篇文章 3 订阅

订阅专栏

本文详细介绍了Kubernetes中的四种部署策略：滚动更新、重新创建、蓝绿部署和金丝雀部署。滚动更新在不停止服务的情况下逐步替换旧版本；重新创建则先删除旧版本再创建新版本，可能导致短暂服务中断；蓝绿部署通过切换Service选择器实现无缝升级和回退；金丝雀部署通过调整Service标签比例进行部分流量测试。每种策略都有其适用场景和优缺点。

摘要由CSDN通过智能技术生成

一、前言

四种部署方案

滚动更新：先上v2版本，然后慢慢干掉v1版本 (每当一个v2版本的Pod变成Running，再干掉一个v1版本的Pod)
优点：不存在某段时间内服务不可用
缺点：切换过程中，存在pod新老版本共存 (解决：v2代码需要做兼容性)
补充：默认是滚动更新缺省是滚动更新

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

蓝绿部署：不是特定类型，而是对滚动更新蓝绿控制，通过selector一键切换，解决pod新老版本共存的问题

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

注意：本文中， vi xxx.yaml + kubectl apply -f xxx.yaml == kubectl edit deployment xxx -n ns-name

本文资源文件
https://download.csdn.net/download/qq_36963950/85997797
在这里插入图片描述

二、滚动更新

本质：对一个普通的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

在这里插入图片描述

2.3 两个参数

https://blog.csdn.net/qq_34556414/article/details/109603303
在这里插入图片描述

三、重新创建

定义：先停掉 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 即可完成一键切换，不需要停止原来的服务

在这里插入图片描述

五、金丝雀(按Pod个数比例)

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

为什么叫金丝雀部署？
回答：就是一种探测方式，金丝雀发布这个术语源自20世纪初期，当时英国的煤矿工人在下井采矿之前，会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类表现的更加敏感快速，金丝雀中毒之后，煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前，先发布给部分用户，用真实的客户流量来测试，以保证软件不会出现严重问题，降低发布风险。

查看 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 实践

在这里插入图片描述

六、尾声

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

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

从来就只有两种策略，蓝绿部署只是通过 svc - pod标签来来实现，一键切换，解决滚动更新，新老pod共存的问题，可以滚动更新，也可以是重新创建 (但一般是滚动更新)

金丝雀只是通过 svc - label 标签来实现按 pod 数量分流，可以滚动更新，也可以是重新创建 (但一般是滚动更新)

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate

  strategy:
    type: Recreate

两种部署方式的本质区别在于滚动更新在再次部署过程中，保持的 pod 的数量是不确定的 (但是一定会至少有一个pod，不会无法对外提供服务)
(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)

重新创建则刚好相反，一定是先删掉之前所有pod，然后再新建指定数量的pod ，中间有时间 pod 数量为 0

滚动更新更好，所以作为了默认的方式

蓝绿部署和金丝雀部署只是一个项目部署方式，根本就没有关键字
从来就只有两种策略，滚动更新的关键字是 type: RollingUpdate ，重新创建的关键字是 type: Recreate

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

天天打码，天天进步！！

本文资源文件
https://download.csdn.net/download/qq_36963950/85997797
在这里插入图片描述

祖母绿宝石

关注

5
点赞
踩
22

收藏

觉得还不错? 一键收藏
打赏
0
评论
Kubernetes_部署_k8s的四种部署策略(滚动更新、重新创建、金丝雀部署、蓝绿部署)

k8s的四种部署策略(滚动更新、重新创建、金丝雀部署、蓝绿部署)
复制链接

扫一扫

专栏目录

Kubernetes_部署_k8s的四种部署策略(滚动更新、重新创建、金丝雀部署、蓝绿部署)

文章目录

一、前言

二、滚动更新

2.1 滚动更新

2.2 实践

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

2.2.2 kubectl apply启动

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

2.3 两个参数

三、重新创建

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即可完成一键切换

五、金丝雀(按Pod个数比例)

5.1 金丝雀灰度部署

5.2 实践

六、尾声