【大话云原生】kubernetes灰度发布篇-从步行到坐缆车的自
2022-04-25 本文已影响0人
字母哥课堂
此文系【大话云原生】系列第四篇,该系列文章期望用最通俗、简单的语言说明白云原生生态系统内的组成、架构以及应用关系。从这篇开始我们要开始针对Kubernetes进行介绍了,本文内容如下:
一、Kubernetes的Pod概念解析
前文说到老婆过生日了我们一起出去旅游,上了团体服务班车,小娜同学(老婆)闲聊到:“这服务还不错哈,2个跟车导游,1个司机”。三句不离老本行,我无聊的说到:“他们三个人就是一个Pod,提供一天的旅游服务内容,有主有次不可分割"。
file小娜同学又上套了:“什么是Pod啊?英文单词豌豆荚?”,让老婆增加对老公崇拜感的机会不可多得,那就开讲,反正坐车也是闲着。
- 一般来说一个Pod提供一种服务(微服务),“哎?之前说容器的时候你也是这么说的”。是的,容器是提供服务的最小单元,那么Pod是什么概念?这是因为我们现在讨论的是k8s,Pod是k8s服务调度的最小单元。
- “为什么引入Pod的概念?”,因为有的时候你会发现:一个服务通常包含辅助它的服务。比如这个车上,一个导游长得漂亮口才好作为主导游提供核心讲解服务,还有一个辅助她的导游负责发帽子、统计人数、统计消费等。同理回到架构技术角度,一个nginx提供web服务容器作为核心服务容器,负责收集nginx日志的服务容器作为辅助服务和它部署在一起,这样方便日志收集与连接。
- 一个Pod存在一个基础容器Infra,基础容器Infra提供了网络共享的能力,就像主导游和辅助导游必须在一辆车(基础容器Infra)上,或者基于这辆车组成了一个组合,否则他们之间无法对话及资源共享。
- 一个Pod下的容器共享网络及数据卷,所以将容器服务间具有相当强的捆绑关系的服务容器放到一个Pod里面,通常一个容器提供核心服务,其他的容器提供辅助服务,如:日志收集、监控告警等。
二、Pod标签与Service服务
聊着聊着很快车就到了旅游目的地,一下车发现X公司的团队还真不少。导游都统一都带上了深红色的帽子(游客带上蓝色遮阳帽),浩浩荡荡出发。深红色的帽子为导游打上了标签,他们面向游客(用户)提供了统一的一种服务叫做:“导游服务”。
file对于K8s中的服务架构也是一样的:
- 一个Pod通常提供一种服务,如nginx web访问服务
- 多个提供同样服务的Pod通常打上一样的标签
- 创建Service:具备同一种标签的Pod组成一个Service,对外提供服务。
三、自动化服务升级-灰度发布
我们今天的项目是爬山,提供了两种方式:一是直接爬(即步行),二是坐缆车,当然如果你中途爬不动了也可以在缆车换乘站上缆车。
- 步行到缆车可以理解为一次服务升级(1.0版本服务升级为2.0版本服务)。从技术角度,服务升级等同于新版本服务的部署被称为Deployment。K8s同样使用Deployment这个术语代表服务升级部署。
- ReplicaSet代表一个版本的Pod服务组合,1.0步行版本的Pod服务组合,2.0为缆车版本的Pod服务组合,这样理解是不是容易多了呢?
- 在服务容器部署Deployment的过程中,不希望服务中断(即:不希望对步行1.0的用户的服务出现中断情况),所以停掉一个1.0的Pod,再启动一个2.0的Pod2.0,这个过程被称为灰度发布。整个过程高度依赖Kubernetes提供的自动化运维能力。
上面的图每个RS只有2个Pod,还不能那么直观的理解灰度发布,看下面这张图
- 圆形代表Pod,分为v1版本和v2版本,虚线标识的Pod表示即将下线的Pod
- v1版本的Pod减一,v2版本的pod加一
- 逐渐ReplicaSet:v1的Pod全部销毁,ReplicaSet:v2的Pod逐渐被创建并启动提供服务
- 整个的灰度发布过程,在k8s种通过一个Deployment进行定义。
此专栏《大话云原生》的前三篇文章如下
- 《【大话云原生】煮饺子与docker、kubernetes之间的关系》
- 《【大话云原生】负载均衡篇-小饭馆的流量变大了》
- 《【大话云原生】微服务篇-五星级酒店的服务方式》
如果您读完了觉得有收获,期待您能转发分享,您的支持是我不竭的创作动力!
欢迎关注我的博客,更多精品知识合集
本文转载注明出处(必须带连接,不能只转文字):字母哥博客 - zimug.com
觉得对您有帮助的话,帮我点赞、分享!您的支持是我不竭的创作动力!。另外,笔者最近一段时间输出了如下的精品内容,期待您的关注。