k8s 蓝绿部署之 Service Label

什么是蓝绿部署

蓝绿(blue/green):新版本与旧版本一起存在,然后切换流量

蓝绿部署流程图

K8S中如何实现蓝绿部署

  • 通过k8s service label标签来实现蓝绿发布
  • 通过Ingress 控制器来实现蓝绿发布
  • 通过Istio来实现蓝绿发布,或者像Istio类似的服务

这次先讲通过k8s service label标签来实现蓝绿发布Istio实现蓝绿发布下期再分享。

k8s 蓝绿 yaml 配置

  • service.yaml 文件
apiVersion: v1
kind: Service
metadata:
  name: demo
  namespace: default
  labels:
    app: demo
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  # 注意这里我们匹配 app 和 version 标签,当要切换流量的时候,我们更新 version 标签的值,比如:v2
  selector:
    app: demo
    version: v1
  • 蓝 v1-deploy.yaml 文件

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: demo1-deployment
    namespace: default
    labels:
    app: demo
    version: v1
    spec:
    replicas: 1
    revisionHistoryLimit: 3
    strategy:
    rollingUpdate:
      maxSurge: 30%
      maxUnavailable: 30%
    selector:
    matchLabels:
      app: demo
      version: v1
    template:
    metadata:
      labels:
        app: demo
        version: v1
    spec:
      containers:
      - name: demo1
        image: mritd/demo
        livenessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 30
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        ports:
          - name: http
            containerPort: 80
            protocol: TCP
  • 绿 v2-deploy.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: demo2-deployment
    namespace: default
    labels:
    app: demo
    version: v2
    spec:
    replicas: 1
    revisionHistoryLimit: 3
    strategy:
    rollingUpdate:
      maxSurge: 30%
      maxUnavailable: 30%
    selector:
    matchLabels:
      app: demo
      version: v2
    template:
    metadata:
      labels:
        app: demo
        version: v2
    spec:
      containers:
      - name: demo2
        image: mritd/demo
        livenessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 30
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        ports:
          - name: http
            containerPort: 80
            protocol: TCP
  • 上面定义的资源对象中,最重要的就是Service 中 label selector的定义:
    selector:
    app: demo
    version: v1

部署与测试

  • 部署v1 v2 deploy服务 和 service服务

    $ kubectl  apply -f service.yaml -f v1-deploy.yaml -f v2-deploy.yaml
  • 测试流量是否到v1版本
    
    # 登陆任意一个pod,向 demo service 发起请求
    $ while sleep 0.3; do curl http://demo; done

输出日志

Host: demo1-deployment-b5bd596d8-dw27b, Version: v1
Host: demo1-deployment-b5bd596d8-dw27b, Version: v1


- 切换入口流量从v1 到 v2
```bash
$ kubectl patch service demo -p ‘{"spec":{"selector":{"version":"v2"}}}‘
  • 测试流量是否到v2版本

    
    # 登陆任意一个pod,向 demo service 发起请求
    $ while sleep 0.3; do curl http://demo; done

输出日志

Host: demo2-deployment-b5bd596d8-dw27b, Version: v2
Host: demo2-deployment-b5bd596d8-dw27b, Version: v2



## 关注公众号
`欢迎大家关注交流,定期分享自动化运维、DevOps、Kubernetes、Service Mesh和Cloud Native`
![image](https://upload-images.jianshu.io/upload_images/20130960-846b4d77325932f7.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

原文地址:https://blog.51cto.com/yangpeng14/2453425

时间: 2024-11-01 19:16:53

k8s 蓝绿部署之 Service Label的相关文章

如何跨不同版本K8S,为有状态工作负载做蓝绿部署

容器的生态正在爆发!不仅仅应用层在快速变化,还有用于管理应用程序的平台:Kubernetes,也在快速变化.这就为Ops团队带来了一个必须要解决的难题.IT团队如何才能保证一款应用程序能够在各种不同版本的Kubernetes上都能良好运行呢?PX-Motion演示视频:如何跨不同版本Kubernetes,为有状态的工作负载做蓝绿部署 蓝-绿部署是一种专门用于解决这一问题的技术,并能够降低生产环境部署的过程中的停机或错误风险.在蓝绿部署场景下,用户需要构建两个完全相同的生产环境(分别称为蓝与绿),

蓝绿部署、滚动部署、灰度发布、金丝雀发布

微服务部署:蓝绿部署.滚动部署.灰度发布.金丝雀发布 在项目迭代的过程中,不可避免需要"上线".上线对应着部署,或者重新部署:部署对应着修改:修改则意味着风险. 目前有很多用于部署的技术,有的简单,有的复杂:有的得停机,有的不需要停机即可完成部署.本文的目的就是将目前常用的布署方案做一个总结. 一.蓝绿布署 Blue/Green Deployment(蓝绿部署) 1.定义 蓝绿部署是不停老版本,部署新版本然后进行测试,确认OK,将流量切到新版本,然后老版本同时也升级到新版本. 1.特点

什么是蓝绿部署和滚动部署

海豚的秘密 大家都知道海豚这种可爱的海洋动物.但又有多少人知道,海豚可以永远不睡觉. 是什么样的能力,使得海豚可以永远保持清醒呢?依靠的是海豚大脑特殊的运作方式. 像人一样,海豚的大脑也分为左脑和右脑两个部分.在海豚活跃的状态下,左脑和右脑都是清醒的: 当然,海豚也是血肉之躯,也是需要休息的.在海豚休息的状态下,其中一半大脑会进入睡眠,另一半大脑仍然保持清醒,以面对各种外界情况. 每隔两个小时,这种一半睡眠一半清醒的状态会进行交替,比如这一刻左脑睡眠右脑清醒,下一刻左脑清醒右脑睡眠. 这就是海豚

首富带你畅谈:蓝绿部署、滚动发布、灰度发布/金丝雀发布

首富带你畅谈:蓝绿部署.滚动发布.灰度发布/金丝雀发布 笔者: 张首富 时间: 2019-01-24晚 QQ群: 895291458 博客地址: www.zhangshoufu.com 根据2018年的DevOps发展报告来看,目前的DevOps发展速度非常之快,已经逐渐成为企业运维的标准方案.DevOps的核心就是敏捷和高效,敏捷和Scrum开发技术曾被认为是最好的技术.既然公司用到了CI/CD肯定就肯定避免不了持续部署,所以我们就需要考虑一套适合我们的发布方式,这个时候我们就需要了解一下这几

蓝绿部署、滚动发布、灰度发布的介绍以及最佳实践

蓝绿部署.滚动发布.灰度发布的介绍以及最佳实践 在一般情况下,升级服务器端应用,需要将应用源码或程序包上传到服务器,然后停止掉老版本服务,再启动新版本.但是这种简单的发布方式存在两个问题,一方面,在新版本升级过程中,服务是暂时中断的,另一方面,如果新版本有BUG,升级失败,回滚起来也非常麻烦,容易造成更长时间的服务不可用. 为了解决这些问题,人们研究出了多种发布策略,下面我们一一介绍. 蓝绿部署 所谓蓝绿部署,是指同时运行两个版本的应用,如上图所示,蓝绿部署的时候,并不停止掉老版本,而是直接部署

【微服务从入门到精通】:(一)微服务的蓝绿发布及灰度发布

蓝绿部署 基本上,蓝绿部署是一种以可预测的方式发布应用的技术,目的是减少发布过程中服务停止的时间. 简单来说,你需要准备两个相同的环境(基础架构),在蓝色环境运行当前生产环境中的应用,也就是旧版本应用,如图中 App1 version1 . App2 version1 . App3 version3 . 当你想要升级 App2 到 version2 ,在蓝色环境中进行操作,即部署新版本应用,并进行测试.如果测试没问题,就可以把负载均衡器/反向代理/路由指向蓝色环境了. 随后你需要监测新版本应用,

金丝雀发布、滚动发布、蓝绿发布到底有什么差别?关键点是什么?

金丝雀发布.滚动发布.蓝绿发布到底有什么差别?关键点是什么? ? 根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异.技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节. ? 作为技术人员,大家可能听说过"滚动发布"和"蓝绿发布"等术语,但是很多人并不清楚这些术语背后的原理.本文试图总结当前主流的发布策略,每个的优劣,适用性,让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识,让

一文搞懂蓝绿发布、灰度发布和滚动发布

应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务.长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布.灰度发布和滚动发布,目的是尽可能避免因发布导致的流量丢失或服务不可用问题. 7.1 蓝绿发布 项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署.B组仍然继续提供服务.当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署.A组重新提供服务.最后,B组也升级完成,负载均衡重新接入B组,

一文了解蓝绿发布/灰度发布/滚动发布

应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务. 长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布.灰度发布和滚动发布,目的是尽可能避免因发布导致的流量丢失或服务不可用问题. 一. 蓝绿发布 项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署.B组仍然继续提供服务. 当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署.A组重新提供服务. 最后,B组也升级完成,负载均衡重新接入B