做同款的网站,果洛wap网站建设哪家好,wordpress网站统计插件,微网站上的一键导航怎么做Deployment入门到企业实战应用 Deployment控制器#xff1a;概念、原理解读Deployment概述Deployment工作原理#xff1a;如何管理rs和Pod#xff1f;什么叫做更新节奏和更新逻辑呢 Deployment使用案例#xff1a;创建一个web站点,2个副本deploy-demo详细解读 通过k8s实现滚… Deployment入门到企业实战应用 Deployment控制器概念、原理解读Deployment概述Deployment工作原理如何管理rs和Pod什么叫做更新节奏和更新逻辑呢 Deployment使用案例创建一个web站点,2个副本deploy-demo详细解读 通过k8s实现滚动更新滚动更新简介在k8s中实现滚动更新直接修改replicas数量如下变成3测试滚动更新回滚操作如下 自定义滚动更新策略总结recreate这种更新策略会把之前的所有pod都删除再创建新的pod风险很大 生产环境如何实现蓝绿部署什么是蓝绿部署蓝绿部署的优势和缺点优点缺点 通过k8s实现线上业务的蓝绿部署创建绿色部署环境基于第一版代码做的镜像运行的pod创建蓝色部署环境新上线的环境要替代绿色环境 通过k8s完成线上业务的金丝雀发布金丝雀发布简介优缺点 在k8s中实现金丝雀发布 Deployment控制器概念、原理解读 Deployment官方文档 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment概述
Deployment是kubernetes中最常用的资源对象为ReplicaSet和Pod的创建提供了一种声明式的定义方法在Deployment对象中描述一个期望的状态Deployment控制器就会按照一定的控制速率把实际状态改成期望状态通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器通过ReplicaSet创建pod删除Deployment控制器也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性例如滚动升级、金丝雀发布、蓝绿部署和回滚。 扩展声明式定义是指直接修改资源清单yaml文件然后通过kubectl apply -f 资源清单yaml文件就可以更改资源 Deployment控制器是建立在rs之上的一个控制器可以管理多个rs每次更新镜像版本都会生成一个新的rs把旧的rs替换掉多个rs同时存在但是只有一个rs运行。 rs v1控制三个pod删除一个pod在rs v2上重新建立一个依次类推直到全部都是由rs v2控制如果rs v2有问题还可以回滚Deployment是建构在rs之上的多个rs组成一个Deployment但是只有一个rs处于活跃状态. Deployment工作原理如何管理rs和Pod Deployment可以使用声明式定义直接在命令行通过纯命令的方式完成对应资源版本的内容的修改也就是通过打补丁的方式进行修改Deployment能提供滚动式自定义自控制的更新对Deployment来讲我们在实现更新时还可以实现控制更新节奏和更新逻辑。 什么叫做更新节奏和更新逻辑呢 比如说Deployment控制5个pod副本pod的期望值是5个但是升级的时候需要额外多几个pod那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本比方说能多一个但是不能少那么升级的时候就是先增加一个再删除一个增加一个删除一个始终保持pod副本数是5个还有一种情况最多允许多一个最少允许少一个也就是最多6个最少4个第一次加一个删除两个第二次加两个删除两个依次类推可以自己控制更新方式这种滚动更新需要加readinessProbe和livenessProbe探测确保pod中容器里的应用都正常启动了才删除之前的pod。 启动第一步刚更新第一批就暂停了也可以假如目标是5个允许一个也不能少允许最多可以10个那一次加5个即可这就是我们可以自己控制节奏来控制更新的方法。 通过Deployment对象你可以轻松的做到以下事情 1、创建ReplicaSet和Pod 2、滚动升级不停止旧服务的状态下升级和回滚应用将应用回滚到之前的版本 3、平滑地扩容和缩容 4、暂停和继续Deployment
Deployment使用案例
创建一个web站点,2个副本 deployment是一个三级结构deployment管理replicasetreplicaset管理pod 用deployment创建一个pod 把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上传到节点服务器 链接https://pan.baidu.com/s/1lkh76DYEhb4mVfN-xCJCkQ?pwdw69c 提取码w69c ctr -nk8s.io images import myapp-blue-v1.tar.gz
ctr -nk8s.io images import myapp-blue-v2.tar.gzcat deploy-demo.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v1
spec:replicas: 2selector:matchLabels:app: myappversion: v1template:metadata:labels:app: myappversion: v1spec:containers:- name: myappimage: janakiramm/myapp:v1imagePullPolicy: IfNotPresentports:- containerPort: 80startupProbe:periodSeconds: 5initialDelaySeconds: 20timeoutSeconds: 10httpGet:scheme: HTTPport: 80path: /livenessProbe:periodSeconds: 5initialDelaySeconds: 20timeoutSeconds: 10httpGet:scheme: HTTPport: 80path: /readinessProbe:periodSeconds: 5initialDelaySeconds: 20timeoutSeconds: 10httpGet:scheme: HTTPport: 80path: /kubectl apply -f deploy-demo.yamlkubectl apply表示声明式的定义既可以创建资源也可以动态更新资源 查看deploy状态 kubectl get deploy
显示如下
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-v1 2/2 2 2 60s
1.NAME 列出名称空间中deployment的名称。
2.READY显示deployment有多少副本数。它遵循ready/desired的模式。
3.UP-TO-DATE 显示已更新到所需状态的副本数。
4.AVAILABLE 显示你的可以使用多少个应用程序副本。
5.AGE 显示应用程序已运行的时间。
kubectl get rs
显示如下
AME DESIRED CURRENT READY AGE
myapp-v1-67fd9fc9c8 2 2 2 2m35s#创建deploy的时候也会创建一个rsreplicaset67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值 1.NAME 列出名称空间中ReplicaSet资源
2.DESIRED显示应用程序的所需副本数这些副本数是在创建时定义的。这是所需的状态。
3.CURRENT 显示当前正在运行多少个副本。
4.READY 显示你的用户可以使用多少个应用程序副本。
5.AGE 显示应用程序已运行的时间。请注意ReplicaSet的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是随机生成的 kubectl get pods
显示如下
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 3s
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 2m21skubectl get pods -o wide | grep myapp
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 10.244.187.78 k8s2
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 10.244.209.136 k8s1 请求刚才创建的pod资源 curl 10.244.187.78…background-color: blue;
deploy-demo详细解读
apiVersion: apps/v1 #deployment对应的api版本
kind: Deployment #创建的资源是deployment
metadata:name: myapp-v1 #deployment的名字
spec:replicas: 2 #deployment管理的pod副本数selector: #标签选择器matchLabels: # matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致app: myappversion: v1template:metadata:labels:app: myappversion: v1spec: #定义容器的属性containers: - name: myappimage: janakiramm/myapp:v1 #容器使用的镜像imagePullPolicy: IfNotPresent #镜像拉取策略ports:- containerPort: 80 #容器里的应用的端口通过k8s实现滚动更新
滚动更新简介 滚动更新是一种自动化程度较高的发布方式用户体验比较平滑是目前成熟型技术组织所采用的主流发布方式一次滚动发布一般由若干个发布批次组成每批的数量一般是可以配置的可以通过发布模板定义例如第一批1台第二批10%第三批50%第四批100%。每个批次之间留观察间隔通过手工验证或监控反馈确保没有问题再发下一批次所以总体上滚动式发布过程是比较缓慢的 10个pod 第一我更新1个pod 第二次更新1个 第三次更新5个 第四次3个
在k8s中实现滚动更新 首先看下Deployment资源对象的组成 kubectl explain deployment.specKIND: Deployment
VERSION: apps/v1
RESOURCE: spec Object
DESCRIPTION:Specification of the desired behavior of the Deployment.DeploymentSpec is the specification of the desired behavior of theDeployment.
FIELDS:minReadySeconds integerMinimum number of seconds for which a newly created pod should be readywithout any of its container crashing, for it to be considered available.Defaults to 0 (pod will be considered available as soon as it is ready)paused booleanIndicates that the deployment is paused.
#暂停当我们更新的时候创建pod先暂停不是立即更新progressDeadlineSeconds integerThe maximum time in seconds for a deployment to make progress before it isconsidered to be failed. The deployment controller will continue to processfailed deployments and a condition with a ProgressDeadlineExceeded reasonwill be surfaced in the deployment status. Note that progress will not beestimated during the time a deployment is paused. Defaults to 600s.replicas integerNumber of desired pods. This is a pointer to distinguish between explicitzero and not specified. Defaults to 1.revisionHistoryLimit integer
#保留的历史版本数默认是10个The number of old ReplicaSets to retain to allow rollback. This is apointer to distinguish between explicit zero and not specified. Defaults to10.selector Object -required-Label selector for pods. Existing ReplicaSets whose pods are selected bythis will be the ones affected by this deployment. It must match the podtemplates labels.strategy Object
#更新策略支持的滚动更新策略The deployment strategy to use to replace existing pods with new ones.template Object -required-Template describes the pods that will be created.kubectl explain deploy.spec.strategy
KIND: Deployment
VERSION: apps/v1
RESOURCE: strategy Object
DESCRIPTION:The deployment strategy to use to replace existing pods with new ones.DeploymentStrategy describes how to replace existing pods with new ones.
FIELDS:rollingUpdate ObjectRolling update config params. Present only if DeploymentStrategyType RollingUpdate.type stringType of deployment. Can be Recreate or RollingUpdate. Default isRollingUpdate.
#支持两种更新Recreate和RollingUpdate
#Recreate是重建式更新删除一个更新一个
#RollingUpdate 滚动更新定义滚动更新的更新方式的也就是pod能多几个少几个控制更新力度的kubectl explain deploy.spec.strategy.rollingUpdate
KIND: Deployment
VERSION: apps/v1
RESOURCE: rollingUpdate Object
DESCRIPTION:Rolling update config params. Present only if DeploymentStrategyType RollingUpdate.Spec to control the desired behavior of rolling update.
FIELDS:maxSurge stringThe maximum number of pods that can be scheduled above the desired numberof pods. Value can be an absolute number (ex: 5) or a percentage of desiredpods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute numberis calculated from percentage by rounding up. Defaults to 25%. Example:when this is set to 30%, the new ReplicaSet can be scaled up immediatelywhen the rolling update starts, such that the total number of old and newpods do not exceed 130% of desired pods. Once old pods have been killed,new ReplicaSet can be scaled up further, ensuring that total number of podsrunning at any time during the update is at most 130% of desired pods.#我们更新的过程当中最多允许超出的指定的目标副本数有几个
它有两种取值方式第一种直接给定数量第二种根据百分比百分比表示原本是5个最多可以超出20%那就允许多一个最多可以超过40%那就允许多两个maxUnavailable stringThe maximum number of pods that can be unavailable during the update. Valuecan be an absolute number (ex: 5) or a percentage of desired pods (ex:10%). Absolute number is calculated from percentage by rounding down. Thiscan not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is setto 30%, the old ReplicaSet can be scaled down to 70% of desired podsimmediately when the rolling update starts. Once new pods are ready, oldReplicaSet can be scaled down further, followed by scaling up the newReplicaSet, ensuring that the total number of pods available at all timesduring the update is at least 70% of desired pods.
#最多允许几个不可用
假设有5个副本最多一个不可用就表示最少有4个可用deployment是一个三级结构deployment控制replicasetreplicaset控制pod 直接修改replicas数量如下变成3
vim deploy-demo.yaml spec:replicas: 3kubectl apply -f deploy-demo.yaml注意apply不同于createapply可以执行多次create执行一次再执行就会报错有重复 kubectl get pods
显示如下
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 8m18s
myapp-v1-67fd9fc9c8-4bv5n 1/1 Running 0 8m18s
myapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 18s上面可以看到pod副本数变成了3个 查看myapp-v1这个控制器的详细信息 kubectl describe deploy myapp-v1
#显示如下
Name: myapp-v1
Namespace: default
CreationTimestamp: Sun, 21 Mar 2021 18:46:52 0800
Labels: none
Annotations: deployment.kubernetes.io/revision: 1
Selector: appmyapp,versionv1
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
#默认的更新策略rollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
#最多允许多25%个pod25%表示不足一个可以补一个
Pod Template:Labels: appmyappversionv1Containers:myapp:Image: janakiramm/myapp:v1Port: 80/TCPHost Port: 0/TCPEnvironment: noneMounts: noneVolumes: none
Conditions:Type Status Reason---- ------ ------Progressing True NewReplicaSetAvailableAvailable True MinimumReplicasAvailable
OldReplicaSets: none
NewReplicaSet: myapp-v1-67fd9fc9c8 (3/3 replicas created)
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal ScalingReplicaSet 3m26s deployment-controller Scaled down replica set myapp-v1-67fd9fc9c8 to 2Normal ScalingReplicaSet 2m1s (x2 over 10m) deployment-controller Scaled up replica set myapp-v1-67fd9fc9c8 to 3测试滚动更新 在终端执行如下 kubectl get pods -l appmyapp -w 打开一个新的终端窗口更改镜像版本按如下操作 vim deploy-demo.yaml
把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2kubectl apply -f deploy-demo.yaml
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 22m
myapp-v1-67fd9fc9c8-4bv5n 1/1 Running 0 22m
myapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 14m
myapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0s
myapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0s
myapp-v1-75fb478d6c-24tbp 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-24tbp 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-cw59c 1/1 Terminating 0 15m
myapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0s
myapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0s
myapp-v1-75fb478d6c-f52l6 0/1 ContainerCreating 0 0s
myapp-v1-67fd9fc9c8-cw59c 0/1 Terminating 0 15m
myapp-v1-75fb478d6c-f52l6 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-4bv5n 1/1 Terminating 0 23m
myapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0s
myapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0s
myapp-v1-75fb478d6c-jlw28 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-jlw28 1/1 Running 0 1spending表示正在进行调度ContainerCreating表示正在创建一个podrunning表示运 行一个podrunning起来一个pod之后再Terminating停掉一个pod以此类推直 到所有pod完成滚动升级 在另外一个窗口执行
kubectl get rs
显示如下
NAME DESIRED CURRENT READY AGE
myapp-v1-75fb478d6c 3 3 3 2m7s
myapp-v1-67fd9fc9c8 0 0 0 25m上面可以看到rs有两个下面那个是升级之前的已经被停掉但是可以随时回滚 kubectl rollout history deployment myapp-v1
查看myapp-v1这个控制器的滚动历史显示如下
deployment.apps/myapp-v1
REVISION CHANGE-CAUSE
1 none
2 none回滚操作如下
kubectl rollout undo deployment/myapp-v1 --to-revision2 自定义滚动更新策略
maxSurge和maxUnavailable用来控制滚动更新的更新策略
取值范围
数值
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。此配置适用场景是平滑更新、保证服务平稳但也有缺点就是“太慢”了。总结
maxUnavailable和期望的副本数比不可用副本数最大比例或最大值这个值越小越能保证服务稳定更新越平滑 maxSurge和期望的副本数比超过期望副本数最大比例或最大值这个值调的越大副本更新速度越快。 自定义策略 修改更新策略maxUnavailable1maxSurge1 kubectl patch deployment myapp-v1 -p {spec:{strategy:{rollingUpdate: {maxSurge:1,maxUnavailable:1}}}} kubectl describe deployment myapp-v1
查看myapp-v1这个控制器的详细信息
显示如下
RollingUpdateStrategy: 1 max unavailable, 1 max surge
上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge
这个rollingUpdate更新策略变成了刚才设定的因为我们设定的pod副本数是31和1表示最少不能少于2个pod最多不能超过4个pod
这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的把pod更新策略变成Recreate kubectl apply -f deploy-demo.yaml打开新的终端看pod更新过程 kubectl get pods -w
NAME READY STATUS RESTARTS AGE
myapp-v1-59c458cb84-gglnb 1/1 Running 0 5m20s
myapp-v1-59c458cb84-nvjhq 1/1 Running 0 5m20s
myapp-v1-59c458cb84-zslxg 1/1 Running 0 4m59s
############33
myapp-v1-59c458cb84-zslxg 1/1 Terminating 0 5m3s
myapp-v1-59c458cb84-nvjhq 1/1 Terminating 0 5m24s
myapp-v1-59c458cb84-gglnb 1/1 Terminating 0 5m24s
myapp-v1-59c458cb84-gglnb 1/1 Terminating 0 5m24s
myapp-v1-59c458cb84-nvjhq 1/1 Terminating 0 5m24s
myapp-v1-59c458cb84-zslxg 1/1 Terminating 0 5m3s
myapp-v1-59c458cb84-gglnb 0/1 Terminating 0 5m25s
myapp-v1-59c458cb84-gglnb 0/1 Terminating 0 5m25s
myapp-v1-59c458cb84-gglnb 0/1 Terminating 0 5m25s
myapp-v1-59c458cb84-zslxg 0/1 Terminating 0 5m4s
myapp-v1-59c458cb84-zslxg 0/1 Terminating 0 5m4s
myapp-v1-59c458cb84-zslxg 0/1 Terminating 0 5m4s
myapp-v1-59c458cb84-nvjhq 0/1 Terminating 0 5m25s
myapp-v1-59c458cb84-nvjhq 0/1 Terminating 0 5m25s
myapp-v1-59c458cb84-nvjhq 0/1 Terminating 0 5m25s
myapp-v1-6bd64fd79-h668z 0/1 Pending 0 0s
myapp-v1-6bd64fd79-d8v55 0/1 Pending 0 0s
myapp-v1-6bd64fd79-h668z 0/1 Pending 0 0s
myapp-v1-6bd64fd79-wkvmp 0/1 Pending 0 0s
myapp-v1-6bd64fd79-d8v55 0/1 Pending 0 0s
myapp-v1-6bd64fd79-wkvmp 0/1 Pending 0 0s
myapp-v1-6bd64fd79-h668z 0/1 ContainerCreating 0 0s
myapp-v1-6bd64fd79-d8v55 0/1 ContainerCreating 0 0s
myapp-v1-6bd64fd79-wkvmp 0/1 ContainerCreating 0 0s
myapp-v1-6bd64fd79-h668z 0/1 ContainerCreating 0 1s
myapp-v1-6bd64fd79-d8v55 0/1 ContainerCreating 0 1s
myapp-v1-6bd64fd79-wkvmp 0/1 ContainerCreating 0 1s
myapp-v1-6bd64fd79-d8v55 0/1 Running 0 1s
myapp-v1-6bd64fd79-h668z 0/1 Running 0 2s
myapp-v1-6bd64fd79-wkvmp 0/1 Running 0 2srecreate这种更新策略会把之前的所有pod都删除再创建新的pod风险很大
生产环境如何实现蓝绿部署
什么是蓝绿部署
蓝绿部署中一共有两套系统一套是正在提供服务系统标记为“绿色”另一套是准备发布的系统标记为“蓝色”。两套系统都是功能完善的、正在运行的系统只是系统版本和对外服务情况不同。开发新版本要用新版本替换线上的旧版本在线上的系统之外搭建了一个使用新版本代码的全新系统。 这时候一共有两套系统在运行正在对外提供服务的老系统是绿色系统新部署的系统是蓝色系统。 蓝色系统不对外提供服务用来做什么呢 用来做发布前测试测试过程中发现任何问题可以直接在蓝色系统上修改不干扰用户正在使用的系统。注意两套系统没有耦合的时候才能百分百保证不干扰 蓝色系统经过反复的测试、修改、验证确定达到上线标准之后直接将用户切换到蓝色系统 切换后的一段时间内依旧是蓝绿两套系统并存但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统新系统工作状态如果出现问题直接切换回绿色系统。当确信对外提供服务的蓝色系统工作正常不对外提供服务的绿色系统已经不再需要的时候蓝色系统正式成为对外提供服务系统成为新的绿色系统。 原先的绿色系统可以销毁将资源释放出来用于部署下一个蓝色系统。
蓝绿部署的优势和缺点
优点
1、更新过程无需停机风险较少 2、回滚方便只需要更改路由或者切换DNS服务器效率较高
缺点
1、成本较高需要部署两套环境。如果新版本中基础服务出现问题会瞬间影响全网用户如果新版本有问题也会影响全网用户。 2、需要部署两套机器费用开销大 3、在非隔离的机器Docker、VM上操作时可能会导致蓝绿环境被摧毁风险 4、负载均衡器/反向代理/路由/DNS处理不当将导致流量没有切换过来情况出现
通过k8s实现线上业务的蓝绿部署 把镜像压缩包上传到k8s的各个工作节点ctr -nk8s.io images import解压 链接https://pan.baidu.com/s/1Kpip05Foysq19tx0R52sTA?pwddgia 提取码dgia 链接https://pan.baidu.com/s/1dFr-ZDlwivYyG3tdVvMY7Q?pwd13nk 提取码13nk ctr -nk8s.io images import myapp-lan.tar.gz
ctr -nk8s.io images import myapp-lv.tar.gzKubernetes不支持内置的蓝绿部署。目前最好的方式是创建新的deployment然后更新应用程序的service以指向新的deployment部署的应用 创建绿色部署环境基于第一版代码做的镜像运行的pod
cat lv.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v1namespace: blue-green
spec:replicas: 3selector:matchLabels:app: myappversion: v2template:metadata:labels:app: myappversion: v2spec:containers:- name: myappimage: janakiramm/myapp:v2imagePullPolicy: IfNotPresentports:- containerPort: 80可以使用kubectl命令创建部署。 kubectl create ns blue-green
kubectl apply -f lv.yamlkubectl get pods -n blue-green
NAME READY STATUS RESTARTS AGE
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 8s
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 8s
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 8skubectl get pods -n blue-green --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 35s appmyapp,pod-template-hash75d7db5cf7,versionv2
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 35s appmyapp,pod-template-hash75d7db5cf7,versionv2
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 35s appmyapp,pod-template-hash75d7db5cf7,versionv2创建前端service cat service_lanlv.yamlapiVersion: v1
kind: Service
metadata:name: myapp-lan-lvnamespace: blue-greenlabels:app: myapp
spec:type: NodePortports:- port: 80nodePort: 30062name: httpselector:app: myapp
version: v2更新服务 kubectl apply -f service_lanlv.yamlkubectl get svc -n blue-green
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp-lan-lv NodePort 10.107.213.1 none 80:30062/TCP 36s在浏览器访问http://k8s-master节点ip:30062 显示如下 创建蓝色部署环境新上线的环境要替代绿色环境
cat lan.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v2namespace: blue-green
spec:replicas: 3selector:matchLabels:app: myappversion: v1template:metadata:labels:app: myappversion: v1spec:containers:- name: myappimage: janakiramm/myapp:v1imagePullPolicy: IfNotPresentports:- containerPort: 80kubectl apply -f lan.yaml
kubectl get pods -n blue-green
NAME READY STATUS RESTARTS AGE
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 13m
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 13m
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 13mmyapp-v2-85cc897d89-hp5j2 1/1 Running 0 10s
myapp-v2-85cc897d89-jpgbm 1/1 Running 0 10s
myapp-v2-85cc897d89-q94g4 1/1 Running 0 10s修改service_lanlv.yaml 配置文件修改标签让其匹配到蓝程序升级之后的程序 cat service_lanlv.yamlapiVersion: v1
kind: Service
metadata:name: myapp-lannamespace: blue-greenlabels:app: myapp
spec:type: NodePortports:- port: 80nodePort: 30062name: httpselector:app: myappversion: v1更新资源清单文件 kubectl apply -f service_lanlv.yamlkubectl get svc -n blue-green
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp-lan-lv NodePort 10.107.213.1 none 80:30062/TCP 9m50s在浏览器访问http://k8s-master节点ip:30062 显示如下 实验完成之后把资源先删除以免影响后面实验 kubectl delete -f lan.yaml
kubectl delete -f lv.yaml
kubectl delete -f service_lanlv.yaml通过k8s完成线上业务的金丝雀发布
金丝雀发布简介
金丝雀发布的由来17 世纪英国矿井工人发现金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯金丝雀也会停止歌唱当瓦斯含量超过一定限度时虽然人类毫无察觉金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下工人们每次下井都会带上一只金丝雀作为瓦斯检测指标以便在危险状况下紧急撤离。金丝雀发布又称灰度发布、灰度更新金丝雀发布一般先发1台或者一个小比例例如2%的服务器主要做流量验证用也称为金丝雀 (Canary) 测试 国内常称灰度测试。
100个pod: 更新了一个pod用的新的代码做的镜像 99个pod没有更新
简单的金丝雀测试一般通过手工测试验证复杂的金丝雀测试需要比较完善的监控基础设施配合通过监控指标反馈观察金丝雀的健康状况作为后续发布或回退的依据。 如果金丝测试通过则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败则直接回退金丝雀发布失败。
优缺点
优点灵活策略自定义可以按照流量或具体的内容进行灰度(比如不同账号不同参数)出现问题不会影响全网用户缺点没有覆盖到所有的用户导致出现问题不好排查
在k8s中实现金丝雀发布 打开一个标签1监测更新过程 kubectl apply -f lv.yaml
kubectl get pods -l appmyapp -n blue-green -w
NAME READY STATUS RESTARTS AGE
myapp-v1-75d7db5cf7-c7z5d 1/1 Running 0 5s
myapp-v1-75d7db5cf7-km5bg 1/1 Running 0 5s
myapp-v1-75d7db5cf7-p7c8j 1/1 Running 0 5s 打开另一个标签2执行如下操作 kubectl set image deployment myapp-v1 myappdocker.io/xianchao/nginx:v1 -n blue-green kubectl rollout pause deployment myapp-v1 -n blue-green回到标签1观察显示如下 NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86s
myapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 1s
myapp-v1-75fb478d6c-wddds 1/1 Running 0 2s注上面的解释说明把myapp这个容器的镜像更新到docker.io/xianchao/nginx:v1版本 更新镜像之后创建一个新的pod就立即暂停这就是我们说的金丝雀发布如果暂停几个小时之后没有问题那么取消暂停就会依次执行后面步骤把所有pod都升级。 解除暂停回到标签1继续观察 打开标签2执行如下 kubectl rollout resume deployment myapp-v1 -n blue-green
在标签1可以看到如下一些信息下面过程是把余下的pod里的容器都更的版本
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86s
myapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 1s
myapp-v1-75fb478d6c-wddds 1/1 Running 0 2s
myapp-v1-67fd9fc9c8-92mdr 1/1 Terminating 0 10m
myapp-v1-75fb478d6c-z6f5z 0/1 Pending 0 0s
myapp-v1-75fb478d6c-z6f5z 0/1 Pending 0 0s
myapp-v1-75fb478d6c-z6f5z 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-z6f5z 0/1 ContainerCreating 0 1s
myapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10m
myapp-v1-75fb478d6c-z6f5z 1/1 Running 0 2s
myapp-v1-67fd9fc9c8-5fd2f 1/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10mkubectl get rs -n blue-green
可以看到replicaset控制器有2个了
NAME DESIRED CURRENT READY AGE
myapp-v1-67fd9fc9c8 0 0 0 13m
myapp-v1-75fb478d6c 2 2 2 7m28s
