首页 > 其他分享 >详解kubernetes的发布方式

详解kubernetes的发布方式

时间：2023-01-09 16:36:51浏览次数：42  
标签：副本 kubernetes 41m update 发布 详解 版本 rolling root

项目的发布方式

  1. 蓝绿发布：不停止旧版本，直接部署新版本
  2. 灰度发布：旧版本和新版本共存
  3. 滚动更新：平滑地将服务更新

蓝绿发布

蓝绿部署就是不停止旧版本，直接部署新版本

部署过程：

  1. 部署v1的应用（初始状态） ：所有外部请求都会进入此版本
  2. 部署版本2的应用：新版的应用
  3. 如果版本2测试正常，就可以将流量切换到版本2
  4. 稳定运行一段时间，没问题就删除版本1正在使用的资源（例如实例），从此正式使用版本2

优点: 无需停机，风险较小

缺点: 切换是全量的，如果版本2有问题，则对用户体验有直接影响, 需要双倍机器资源。

部署服务

创建目录

mkdir /root/bluegreen

部署版本V1的Deployment

cat > /root/bluegreen/blue.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/blue.yaml

部署Service

cat > /root/bluegreen/bluegreenservice.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/bluegreenservice.yaml

部署版本V2的Deployment

cat > /root/bluegreen/green.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v2.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2
        ports:
        - containerPort: 80
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/green.yaml

查看pod和service

[root@kubemaster ~]# kubectl get pod,svc
NAME                        READY   STATUS    RESTARTS   AGE
pod/blue-599dd97cf7-74fqm   1/1     Running   0          95m
pod/blue-599dd97cf7-cs6mc   1/1     Running   0          95m
pod/blue-599dd97cf7-ddcf5   1/1     Running   0          95m
pod/blue-599dd97cf7-z47hv   1/1     Running   0          95m
pod/green-9fd69c4bc-c6jcd   1/1     Running   0          94m
pod/green-9fd69c4bc-grt7x   1/1     Running   0          94m
pod/green-9fd69c4bc-w7tkj   1/1     Running   0          94m
pod/green-9fd69c4bc-zx6pz   1/1     Running   0          94m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/bluegreen    ClusterIP   10.97.172.131   <none>        80/TCP    95m
service/kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   3d17h

验证

检查当前版本

查看到的是V1版本

[root@kubemaster ~]# curl http://10.97.172.131/api/home
Webapplication - V1

修改bluegreenservice.yaml

version: v1.0改为version: v2.0，并重新发布

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/bluegreenservice.yaml

查看是否为V2版本

查看到的是V2版本

[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2

灰度发布(金丝雀)

灰度发布，就是将一部分新版服务部署到线上环境，有些用户的请求会进入新版的服务，这会出现两种情况

  1. 如果用户反馈不好，会将新版服务停止或者重做
  2. 如果代码质量有问题，也只会影响部分的用户

部署过程:

  1. 准备好部署各个阶段的工件

  2. 从负载均衡列表中移除掉“金丝雀”服务器

  3. 升级“金丝雀”应用（排掉原有流量并进行部署）

  4. 对应用进行自动化测试

  5. 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）

    如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

优点: 用户体验影响小，灰度发布过程出现问题只影响部分用户

部署

cat > /root/canary/canary.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 6
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v2.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/canary/canary.yaml

验证

[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2
[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2
[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V1

滚动更新

取出部分服务器停止服务，更新后重新投入使用。直到集群中所有实例都是最新版本。默认maxUnavailable和surge都是25%

  • maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
  • maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。可以部分部署，例如每次只取出集群的25%进行升级

部署

创建Deployment

mkdir /root/rollingUpdate

cat > /root/rollingUpdate/rollingUpdate.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update
  labels:
    app: rolling-update-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rolling-update-pod
  template:
    metadata:
      labels:
        app: rolling-update-pod
    spec:
      containers:
      - name: rolling-update-container
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: rolling-update-pod
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/rollingUpdate/rollingUpdate.yaml

监控Deployment的状态

新启一个bash窗口

[root@kubemaster ~]# kubectl get deployment rolling-update -w

开始滚动更新

[root@kubemaster ~]# kubectl set image deployment/rolling-update rolling-update-container=registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2 --record

验证

Deployment状态

[root@kubemaster ~]# kubectl get deployment rolling-update -w
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
rolling-update   3/3     3            3           41m
rolling-update   3/3     3            3           41m
rolling-update   3/3     3            3           41m
rolling-update   3/3     0            3           41m
rolling-update   3/3     1            3           41m
rolling-update   4/3     1            4           41m
rolling-update   3/3     1            3           41m
rolling-update   3/3     2            3           41m
rolling-update   4/3     2            4           41m
rolling-update   3/3     2            3           41m
rolling-update   3/3     3            3           41m
rolling-update   4/3     3            4           41m
rolling-update   3/3     3            3           41m

其他命令

查看Deployment滚动配置

kubectl describe deployment rolling-update

检查 Deployment 修订历史

kubectl rollout history deployment rolling-update

回滚到之前的修订版本

## 回滚到上一个版本
kubectl rollout undo deployment rolling-update
##回滚到指定版本
kubectl rollout undo deployment rolling-update --to-revision=1

取值范围

数值

  1. maxUnavailable: [0, 副本数]
  2. maxSurge: [0, 副本数]

注意：两者不能同时为0。

比例

  1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
  2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；

注意：两者不能同时为0。

建议配置

  1. maxUnavailable == 0
  2. maxSurge == 1

这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了

自定义策略

DeploymentController调整replicaset数量时，严格通过以下公式来控制发布节奏

(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)

举例：

如果期望副本数为10，且至少80%的副本能够正常工作。且建议maxSurge 与maxUnavailable 一致。

由此可以设定目标副本数为10，线上实际Ready副本数为8，从此可以得出maxUnavailable = 10 - 2 = 8，即8 ≤ 线上实际Ready副本数 ≤ 12

标签：副本,kubernetes,41m,update,发布,详解,版本,rolling,root
From： https://www.cnblogs.com/reim/p/17037411.html

相关文章

  • xss.haozi.me靶场通关详解
    xss.haozi.me靶场详解一、模块介绍1.inputcode输入的内容2.servercode服务端代码，告诉我们程序如何处理输入的内容3.html通过处理程序（servercode）渲染完的代码4.......
  • Java工作流详解(附6大工作流框架对比)​
    ​目录​1.什么是工作流​2.工作流应用场景​3.工作流实现方式​4.有哪些工作流框架?​5.1.Activiti6.2.Flowable7.3.Camunda8.4.jBPM9.5.osworkflow，6.jflow.​10.工作流......
  • Model-Agnostic Meta-Learning （MAML）模型介绍及算法详解
    paper:​​​https://link.zhihu.com/?target=https%3A//arxiv.org/pdf/1703.03400.pdf​​ MAML在学术界已经是非常重要的模型了，论文Model-AgnosticMeta-LearningforFa......
  • minio kubernetes快速搭建
    pod.yamlapiVersion:v1kind:Podmetadata:labels:app:minioname:minionamespace:minio-dev#Changethisvaluetomatchthenamespacemetadata......
  • 详解 Kruskal 最小生成树算法
     求最小生成树算一般有两种算法：Prim和Kruskal。Prim的时间复杂度为\(O(|V|^{2})\)，更适合稠密图。而Kruskal的时间复杂度为\(O(logV)\)或\(O(logE)\)。更适......
  • 跨屏建站网发布kpcom企业专属响应式模板
    跨屏建站网发布企业专属响应式模板kpcom，这是一套针对企业而专门制定的一套响应式网站模板，包含了公司介绍、公司新闻、公司产品、联系我们等企业网站标配的栏目，它几乎适用于......
  • 【跨屏建站网】kpvip模板2023.1.6发布更新
    跨屏建站网kpvip模板2023.1.6发布更新，修复了已知bug，优化了代码，调整了新闻版块，之前的新闻缩略图有图的时候会显示图片，没有图片则显示一张占位图，而调整以后，我们去掉了缩略图......
  • 线上发布会AR互动形式体验感升级，增强品牌记忆点
    突如而来的疫情，让各行各业都受到了不同程度的影响，线下活动也无法举办，在这种情况下，线上发布会成为了大多数品牌在疫情之下的新选择。广州华锐互动通过VR、AR、MR等虚拟现实......
  • rwctf体验赛-Snake详解
    首先展示一下apk中的内容，一个简单的贪吃蛇游戏静态分析蛇撞墙会有提示，直接去看定位到com.example.ct_sanke.SnakeView.i()i()方法只有一处调用，随着蛇吃食物进行逻......
  • 【首场重磅亮相】KaiwuDB 1.0 时序数据库线上发布会明日开启！邀您共同见证
    首场重磅亮相KaiwuDB是浪潮集团控股的数据库企业，以多模数据库为核心，面向工业物联网、数字能源、交通车联网、智慧城市、数字政务等多种场景，提供领先创新的数据服务软件......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99