详解kubernetes的发布方式

kubernetes,发布,方式 · 浏览次数 : 145

小编点评

* 用户体验影响小,灰度发布过程出现问题只影响部分用户部署。 * 默认maxUnavailable和surge都是25%maxUnavailable:和期望ready的副本数比,不可用副本数最大比例(或最大值)。 * 比例maxUnavailable: [0%, 100%] 向下取整,比如10个副本,5%的话==0.5个,但计算按照0个;maxSurge: [0%, 100%] 向上取整,比如10个副本,5%的话==0.5个,但计算按照1个。 * 建议配置maxUnavailable == 0maxSurge == 1这是我们生产环境提供给用户的默认配置。 * 即“一上一下,先上后下”最平滑原则:1个新版本pod ready(结合readiness)后,才销毁旧版本pod。 * 此配置适用场景是平滑更新、保证服务平稳,但也有缺点,就是“太慢”了自定义策略DeploymentController调整replicaset数量时,严格通过以下公式来控制发布节奏(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)举例:如果期望副本数为10,且至少80%的副本能够正常工作。且建议maxSurge 与maxUnavailable 一致。

正文

项目的发布方式

  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%的副本能够正常工作。且建议maxSurgemaxUnavailable 一致。

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

与详解kubernetes的发布方式相似的内容:

详解kubernetes的发布方式

项目的发布方式 蓝绿发布:不停止旧版本,直接部署新版本 灰度发布:旧版本和新版本共存 滚动更新:平滑地将服务更新 蓝绿发布 蓝绿部署就是不停止旧版本,直接部署新版本 部署过程: 部署v1的应用(初始状态) :所有外部请求都会进入此版本 部署版本2的应用:新版的应用 如果版本2测试正常,就可以将流量切

Kubernetes容器生命周期 —— 钩子函数详解(postStart、preStop)

1、概述 容器生命周期钩子(Container Lifecycle Hooks)监听容器生命周期的特定事件,并在事件发生时执行已注册的回调函数。 钩子函数能够感知自身生命周期中的事件,并在相应的时刻到来时运行用户指定的程序代码。 kubernetes在主容器的启动之后和停止之前提供了两个钩子函数:

[转帖]Kubernetes-15:一文详解Pod、Node调度规则(亲和性、污点、容忍、固定节点)

https://www.cnblogs.com/v-fan/p/13609124.html Kubernetes Pod调度说明 简介 Scheduler 是 Kubernetes 的调度器,主要任务是把定义的Pod分配到集群的节点上,听起来非常简单,但要考虑需要方面的问题: 公平:如何保证每个节点

详解kubernetes五种暴露服务的方式

部署完服务终将是为了访问,那么`kubernetes`中`service`和`ingress`都可以将集群内部的服务能够支持外部访问。`service`可以让一组 Pod(称为“后端”)为集群内的其他 Pod(称为“前端”)提供功能;`ingress`通过对集群中服务的外部访问进行管理,也可以提供负载均衡、SSL 终结和基于名称的虚拟托管。

详解Kubernetes Pod优雅退出

1、概述 Pod优雅关闭是指在Kubernetes中,当Pod因为某种原因(如版本更新、资源不足、故障等)需要被终止时,Kubernetes不会立即强制关闭Pod,而是首先尝试以一种“优雅”的方式关闭Pod。这个过程允许Pod中的容器有足够的时间来响应终止信号(默认为SIGTERM),并在终止前完成

[转帖]kubernetes service 和 kube-proxy详解

https://plantegg.github.io/2020/01/22/kubernetes%20service/ 性能情况.. service 模式 根据创建Service的type类型不同,可分成4种模式: ClusterIP: 默认方式。根据是否生成ClusterIP又可分为普通Servi

Kubernetes(K8S) Deployment 升级和回滚

创建部署详见 Kubernetes(K8S) Deployment 部署 Pod 传统应用升级,一般是V1.0的jar包,有一个应对 1.0 的 shell 启动脚本。升级时,传 2.0 的 jar包,配置 2.0 的 shell 脚本。 执行顺序为,停1.0的服务,启2.0的服务,有问题时,把2.

Kubernetes Pod调度:从基础到高级实战技巧

本文深入探讨了Kubernetes中的Pod调度机制,包括基础概念、高级调度技术和实际案例分析。文章详细介绍了Pod调度策略、Taints和Tolerations、节点亲和性,以及如何在高流量情况下优化Pod调度和资源管理。 关注【TechLeadCloud】,分享互联网架构、云服务技术的全维度知识

深入解读Prometheus Adapter:云原生监控的核心组件

本文详述了Prometheus Adapter的部署与配置,通过三个实践案例展示其在Kubernetes环境中的应用,帮助用户实现基于自定义指标的自动扩展和跨集群统一监控。 关注作者,分享AI全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验,同济本复旦硕,复旦机器人智能实验

Kubernetes 数据存储:从理论到实践的全面指南

本文深入解析 Kubernetes (K8S) 数据存储机制,探讨其架构、管理策略及最佳实践。文章详细介绍了 K8S 数据存储的基础、架构组成、存储卷管理技巧,并通过具体案例阐述如何高效、安全地管理数据存储,同时展望了未来技术趋势。 关注【TechLeadCloud】,分享互联网架构、云服务技术的全