Kubernetes之蓝绿部署

【编者的话】毋庸置疑,Kubernetes目前已成为业内最炙手可热的容器编排框架。本文主要讲讲怎么用Kubernetes进行蓝绿部署以及如何自动化实现蓝绿部署。更多Kubernetes知识请关注DockOne其他文章。

本文讲的是Kubernetes之蓝绿部署对于那些有更多热情想投入其中的朋友,我已经在GitHub上上传了一个教程和一些示例清单。请访问https://github.com/IanLewis/ku ... orial

Kubernetes有一个非常棒的内置功能即部署(Deployments)。当您将应用程序更新到一个新版本时,部署功能能够帮您对容器进行滚动更新。滚动更新是更新应用程序的一种很好的方法,因为您的应用程序在更新期间使用的资源数量,基本和不更新时所使用的资源相同,而且滚动更新过程中对性能和可用性影响最小。

尽管如此,仍然有许多老式的应用程序在滚动更新中不能很好地运行。一些应用程序只需要部署一个新版本,并需要立即切到这个版本。因此,我们需要执行蓝/绿部署。在进行蓝/绿部署时,应用程序的一个新副本(绿)将与现有版本(蓝)一起部署。然后更新应用程序的入口/路由器以切换到新版本(绿)。然后,您需要等待旧(蓝)版本来完成所有发送给它的请求,但是大多数情况下,应用程序的流量将一次更改为新版本。

Kubernetes不支持内置的蓝/绿部署。目前最好的方式是创建新的部署,然后更新应用程序的服务以指向新的部署。接下来让我们来看看这是啥意思。

蓝部署

Kubernetes部署指定一个应用程序的一组实例。在幕后,它创建一个副本,该副本负责保持指定数量的实例运行。

我们可以通过将以下yaml保存到blue.yaml文件中来创建我们的“蓝色”部署。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-1.10
spec:
replicas: 3
template:
metadata:
  labels:
    name: nginx
    version: "1.10"
spec:
  containers: 
    - name: nginx
      image: nginx:1.10
      ports:
        - name: http
          containerPort: 80

然后可以使用kubectl命令创建部署。

$ kubectl apply -f blue.yaml

一旦我们进行了部署,我们可以通过创建一个服务来提供访问部署实例的方法。服务与部署分离,这意味着您不必在部署时明确指向服务。您需要做的是指定一个标签选择器,它的主要作用是列出构成服务的pods。当你使用部署时,通常会将其设置为与部署的pods相匹配。

在这种情况下,我们有两个标签,name=nginx和version=1.10。我们将这些设置为下面的服务的标签选择器。将下面的内容保存到service.yaml。

apiVersion: v1
kind: Service
metadata: 
name: nginx
labels: 
name: nginx
spec:
ports:
- name: http
  port: 80
  targetPort: 80
selector: 
name: nginx
version: "1.10"
type: LoadBalancer

创建服务将创建一个可在集群外访问的负载均衡器。

$ kubectl apply -f service.yaml

现在我们看看已经部署的服务,如下图。

您可以测试该服务是否可访问并获取该版本。

$ EXTERNAL_IP = $( kubectl get svc nginx -o jsonpath = “{.status.loadBalancer.ingress [*]。ip}” ) 
$ curl -s http:// $ EXTERNAL_IP / version | grep nginx 

创建绿部署

对于“绿”部署,我们将部署“蓝”部署并行的新部署。如果以下是green.yaml……

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-1.11
spec:
replicas: 3
template:
metadata:
  labels:
    name: nginx
    version: "1.11"
spec:
  containers: 
    - name: nginx
      image: nginx:1.11
      ports:
        - name: http
          containerPort: 80

……我可以像这样创建新的部署。

$ kubectl apply -f green.yaml

现在我有两个部署,但服务仍然指向“蓝”部署。接下来我们要怎么做呢?

更新应用程序

要切换到“绿”部署,我们将更新服务的选择器。编辑service.yaml并将选择器版本更改为“1.11”。这将使它与“绿”部署中的pods匹配。

apiVersion: v1
kind: Service
metadata: 
name: nginx
labels: 
name: nginx
spec:
ports:
- name: http
  port: 80
  targetPort: 80
selector: 
name: nginx
version: "1.11"
type: LoadBalancer

执行下面的命令将更新现有的nginx服务。

$ kubectl apply -f service.yaml

现在我们再看看已经部署的,如下图。

更新服务的选择器将立即被应用,因此您应该看到新版本的nginx正在提供服务。

$ EXTERNAL_IP = $( kubectl get svc nginx -o jsonpath = “{.status.loadBalancer.ingress [*]。ip}” ) 
$ curl -s http:// $ EXTERNAL_IP / version | grep nginx

自动化

您可以通过一些脚本来自动化跑您的蓝/绿部署。以下脚本将使用服务的名称,要部署的版本以及绿色部署的yaml文件的路径,并使用kubectl运行完整的蓝/绿部署,以从API中输出原始JSON,并使用jq进行解析。通过status.conditions在更新服务定义之前检查部署对象,等待绿部署准备就绪。

脚本为简单起见做出了一些假设,例如期望部署的名称为形式 - 并且存在用于选择器的name和version标签。kubectl是超级灵活的,你可以用它写你自己需要的任何东东。

#!/bin/bash

bg-deploy.sh <servicename> <version> <green-deployment.yaml>

Deployment name should be <service>-<version>

DEPLOYMENTNAME=$1-$2
SERVICE=$1
VERSION=$2
DEPLOYMENTFILE=$3

kubectl apply -f $DEPLOYMENTFILE

Wait until the Deployment is ready by checking the MinimumReplicasAvailable condition.

READY=$(kubectl get deploy $DEPLOYMENTNAME -o json | jq '.status.conditions[] | select(.reason == "MinimumReplicasAvailable") | .status' | tr -d '"')
while [[ "$READY" != "True" ]]; do
READY=$(kubectl get deploy $DEPLOYMENTNAME -o json | jq '.status.conditions[] | select(.reason == "MinimumReplicasAvailable") | .status' | tr -d '"')
sleep 5
done

Update the service selector with the new version

kubectl patch svc $SERVICE -p "{\"spec\":{\"selector\": {\"name\": \"${SERVICE}\", \"version\":\"${VERSION}\"\}\}\}"
echo "Done."

最后,真心希望Kubernetes可以原生支持蓝/绿部署,但这美好时刻来临之前,您可以通过上面的方式来实现自动化。如需要联系那些关心Kubernetes应用程序部署的童鞋,请查看Kubernetes Slack中的#sig-apps频道 。

原文链接:Blue/Green Deployments on Kubernetes(译者:ds_sky2008)

原文发布时间为:2017-09-20

本文作者:ds_sky2008

本文来自合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:Kubernetes之蓝绿部署

时间: 2024-08-26 04:00:38

Kubernetes之蓝绿部署的相关文章

DevOps与阿里云容器服务(四)- 复杂拓扑应用的蓝绿发布

前言 在上一篇文章中,我们演示了如何使用蓝绿发布来实现热部署,但是在实际生产的场景中,应用的拓扑结构会复杂很多.在本篇文章中我们将会讨论下复杂应用拓扑中的蓝绿发布方案以及蓝绿发布适用的场景. 场景分析 大于大多数场景而言,对客户提供服务的软件的形态有三种.一种是前端类服务,用户可以直接或者间接通过网页.接口调用使用该服务提供的能力:一种是后端类服务,用户无法直接使用该服务提供的功能,该服务主要的使用者是其他服务,并通过其他服务最终将处理后的结果反馈给用户:第三种是调度任务类服务,即不被用户使用也

Photoshop通道磨皮:蓝绿通道强光叠加法

导言:这个磨皮方式可以简单的叫:蓝绿通道强光叠加法.方法比较简单实用,配合调色等后期手法,相信你也能修出精美的作品! MM的原照片 效果图 对比上面两张照片看看MM手臂,真的是年轻了十岁的皮肤啊,而且纤毛毕现,可以透出光了,不能再P了,再P我会喜欢上这个MM的. 说下这个磨皮方式的原理:人像里脸部的瑕疵一般都是在蓝色和绿色通道,这个方式其实是选择这些通道,用设置滤镜设置和强光叠加的方式,把这些瑕疵放大出来,然后选择后用高光的方式减少这些瑕疵的显示----这个是偶分析的. [1] [2] [3] 

PhotoShop蓝绿通道强光叠加法为MM磨皮

这个磨皮方式可以简单的叫 蓝绿通道强光叠加法,如果知道这个方式的,下面的内容可以不用看了,嘿嘿. 首先是炜摄影贴中间的一个MM的原照片. 对比 对比上面两张照片看看MM手臂,真的是年轻了十岁的皮肤啊,而且纤毛毕现,可以透出光了. 不能再P了,再P我会喜欢上这个MM的. 说下这个磨皮方式的原理. 人像里脸部的瑕疵一般都是在蓝色和绿色通道,这个方式其实是选择这些通道,用设置滤镜设置和强光叠加的方式,把这些瑕疵放大出来,然后选择后用高光的方式减少这些瑕疵的显示----这个是偶分析的 第一步,按 CTR

Weaveworks是如何利用Kubernetes来构建多级部署解决方案的?

本文讲的是Weaveworks是如何利用Kubernetes来构建多级部署解决方案的,[编者的话]Weave Scope是Weaveworks公司推出的一个面向容器化App和服务的虚拟化及监测的开源解决方案.本文介绍了通过Kubernetes构建Weave Scope的整个历程. 今天,我们听到Peter Bourgon的(Weaveworks公司软件工程师)介绍,Weaveworks为软件开发人员提供在Docker容器中的基于微服务的网络.监测和控制服务.Peter告诉我们这涉及到选择和部署K

乾照光电收购蓝绿光芯片计划夭折后来者难立足

因筹划重大不确定事项,自2014年3月20日停牌至今的乾照光电(行情,问诊)6月9日晚间公告了终止筹划重大资产重组事项的消息,公司采取并购重组方式实现LED蓝绿光芯片领域外延式增长的计划告吹.乾照光电称,本次筹划重大资产重组,即为寻找在LED蓝绿光芯片领域具有一定的技术实力.客户基础和竞争实力的企业,希望能和公司产生协同效应.但在股票停牌期间,公司会同中介机构结合标的公司的尽职调查的初步结果,与相关交易各方进行了积极的磋商,就合作条件进行了深入讨论与沟通,最终仍未能就相关重要交易条款达成一致 意

红帽OpenStack平台部署云环境提供新型服务

日前,红帽公司宣布,包括FreeBit.KazTransCom和Turkcell在内的全球多家通信行业领先企业已部署具有高度扩展能力的基础架构即服务(IaaS)解决方案-红帽OpenStack平台-作为其现代化云举措的基础. 在受数字化服务.新设备和用户大量增长而驱动的世界中,全球领先通信企业正在实现其基础架构现代化,以支持先进的云服务,并加快推出新服务.凭借全面扩展性和无需大量增加物理基础架构即可满足实时应用需求的能力,OpenStack已经成为企业和通信行业云部署的必选平台.据2016年4月

DockOne微信分享(一四二):容器云在万达的落地经验

本文讲的是DockOne微信分享(一四二):容器云在万达的落地经验[编者的话]容器生态是现在非常火热的技术生态之一,个人认为它主要囊括着四个方面的技术栈:一是容器核心技术栈(包括 Docker.rkt 及第三方公司自主研发的容器 Engine 等):二是容器基础技术栈(包括容器网络.存储.安全及服务发现等):三是容器编排技术栈(包括 Mesos/Marathon.Swarm.Kubernetes 及 OpenShift 等):四是容器应用技术栈(主要包括 CI/CD.监控.日志及微服务框架等).

评估容器安全的现状,解你心中疑惑

任何理性的企业都希望能在容器上运行关键任务型服务,但他们会有这样的疑问:"容器真的安全吗?我们真的可以把数据和应用程序放心地交给容器吗?" 在技术人员当中,这常常导致容器与虚拟机之争,并讨论虚拟机中的虚拟机管理程序层提供的保护.虽然这可能是一种有趣而翔实的讨论,但容器与虚拟机这种对立本身就是错的:有关方应在虚拟机里面运行容器,目前这一幕出现在大多数云提供商身上.一个显著的例外是来自Joyent的Triton,它使用SmartOS Zones,确保租户相互隔离.还有一个日益壮大的社区认为

DockOne微信分享(一二九):聊聊Service Mesh:linkerd

本文讲的是DockOne微信分享(一二九):聊聊Service Mesh:linkerd[编者的话]随着企业逐渐将传统的单体应用向微服务或云原生应用的转变,虽然微服务或者云原生应用能给企业带来更多的好处,但也会带来一些具有挑战的问题,如怎么管理从单体应用转向微服务所带来的服务间通讯的复杂性,怎么实现微服务间安全,高效,可靠的访问,如何满足多语言多环境的透明通讯,服务发现.熔断,动态流量迁移,金丝雀部署,跨数据中心访问等等.本次分享给大家引入一新概念服务网格(Service Mesh)以及介绍业界