首页
学习
活动
专区
工具
TVP
发布

Kubernetes业务部署流程与核心概念

建议先阅读:架构 之后,再阅读该文章。 在架构 中,已经从宏观的角度讲解了K8S, 这篇文章更进一步,介绍一下K8S的业务部署流程和相关核心概念,为下一步搭建自己的K8S集群做准备。 BTW, 为提高编写效率,我使用K8S代替Kubernetes, 二者意思完全一样,K8S是业界比较通用的Kubernetes缩写。 任何错误,也请大家指正,邮箱: qiuxincsu@hotmail.com

目录

1.K8S业务部署流程

2.POD

2.1 POD概述

2.2 POD网络

2.3 cgroup

2.4 namespace

3.Deployment/Manifest

4.DNS Service

1. K8S业务部署流程

当你了解K8S的架构之后,你会想知道这个架构对我有什么用?怎样可以将自己的业务部署在这个架构上?

将一个业务部署在K8S上分为如下步骤:

a.将现有业务进行拆解,拆解成一个个子模块。拆解的原则是:尽量减少子模块之间的耦合性,例如:共享存储、共享内存、数据交互等,尽量确保每一个模块可以被单独的开发和维护,这样方便在开发过程中各个团队并行高效工作,最终以搭积木的方式,提供整个业务系统,同时也方便后续的维护,每个团队可以独立升级自己的子模块,而尽量减少对其它团队模块的影响。当然如果是一个规模很小的应用,可以放在容器内进行,也可以不拆解,完全取决于不同的业务。

b.选择合适的开发语言和环境,开发对应的子模块,将每个子模块打包封装在容器中,并上传到容器的镜像仓库。

c.将容器集中部署在POD中。

d.将业务希望部署的集群在部署文件(manifest.yaml)进行描述,并通过kubectl command-line发给K8S的管理平面。

e.K8S的管理平面收到manifest文件之后,对进行身份权限验证和校正等工作,然后解析Manifest描述的期望部署状态。

f.K8S的管理平面将Manifest描述的期望部署状态存储在存储资源中(目前主要是ectd数据库),方便后续实际部署状态和目标状态之间的比对

g.K8S的管理平面按照Manifest描述的期望部署状态在集群中部署业务POD和容器, 包括不限于: 抓取镜像仓库中的镜像、启动容器、构建网络、运行业务等等。

h.K8S的管理平面不断循环检测当前的部署状态,并和目标部署状态进行比对,如果出现一致的情况,进行调整,最大可能确保实际部署状态和目标部署状态是完全一致的。

结合下图理解,可以帮助更好理解如上的部署流程:

如上的流程中有几个专业术语,POD、 Manifest文件等,下面详细展开,帮助大家理解。

2. POD

2.1 POD概述

POD是针对容器(Contianer)的一种封装,POD本身什么都不做,仅仅是封装资源。 POD所封装的资源构成了一种共享的执行环境(Shared Execution Environment),这些共享资源包括:Network(IP地址、端口号、路由表)、 主机名(hostname)、sockets、内存(memory)、存储(volumes)等。在技术实现上,POD也是一个容器,你可以将容器封装在POD里面,理解成:将容器运行在容器中。

POD是K8S的最小调度和部署资源(原子操作,要么部署一个POD,要么不部署),在K8S体系架构中,容器无法脱离POD独立运行,所以当你希望将业务部署在K8S上,你必须要将你已经实现的容器部署在POD里面。 当你需要扩张或者减少业务部署的时候,也是以POD为独立为单位进行扩缩容。对于调度也是一样,当你希望调度业务资源的时候,必须以POD来调度,可以将一个POD从服务器A调度到服务器B,但是你永远不可能脱离POD,直接将容器从服务器A直接调度到服务器B。

在对应关系上,最简单的情况是一个POD里面仅仅封装一个容器,当然在一些业务场景下会出现一个POD里面封装了多个容器。 这就涉及到了POD对资源分配的影响,每个POD拥有独立的IP、内存、存储等资源,当一个容器独占一个POD的时候,就比较简单,这个容器独占了这些资源;当将多个容器封装在一个POD的时候,很可能是业务需要这些容器中的业务需要共享IP、内存、容器、Namespace、Port号范围等资源, 而且多个容器会随着它们所在的POD整体被调度和迁移。举个例子,当2个容器共享一个POD的时候,如下图所展示,它们共享了IP地址10.0.10.10等执行环境,同时被调度和迁移。 此外,如果位于一个POD内的2个容器需要通信的话,可以通过localhost进行数据交互。

如果容器之间不需要共享资源的话,建议还是一个POD中一个容器,这样比较简单,也方便开发和维护。 有关多个容器封装在一个POD的应用,主要的一个场景是Service Mesh.在Service Mesh架构中,在每一个POD里面都增加了Proxy Contianer, 这样就出现了业务容器和Proxy Container共存于一个POD场景,有关Service Mesh后续单独展开,这里不做深入讨论。

有关POD的原子性,另外一个理解就是POD状态,当一个POD内部的所有的容器全部处于Ready状态的时候,整个POD才处于Ready状态,才可以对外提供业务访问。当POD中的一部分容器处于非ready状态,一部分容器处于ready状态,整个POD是非ready状态,无法对外提供业务访问。

有关POD的生命周期,和人的生命周期很类似,就是一旦翘辫子了,就不可能再复活了。POD也是一样,如果一个POD故障了或者被删除了,可以启动一个新的POD替换它,但是挂掉的那个POD就再也回不来了,新的POD拥有全新的IP地址,端口号等信息。

BTW, POD这个名词的由来,在英语中将a group of whales称之为a pod of whales, 而whales(鲸鱼)是docker中承载容器的logo标志,因为这个原因开源社区选择了POD做为专业术语。

2.2 POD网络

每一个POD有自己的独立的IP地址,TCP和UDP端口的范围,localhost以及一个自己的路由表(routing table)。如果一个POD里面仅仅有一个容器,那么这个容器就完全独占这个POD里面的这些资源。如果是一个POD里面有多个容器,那么这些资源就被多个容器所共享。

如下图所展示,当希望访问Container A的时候,使用 10.0.10.10: 80, 当希望访问Container B的时候,使用10.0.10.10: 90。 Container A 和Container B都共享了POD的IP地址10.0.10.10以及同一个端口范围,但是使用不同的端口号,使用“IP+端口号”的方式来访问POD中的一个容器。 如果POD内Contioner A和Container B希望互相访问,可以采用localhost+端口号的方式,访问Contioner A 采用localhost:80,访问Contioner B采用localhost:90.

对于POD之间的通信就比较好理解,每一个POD有自己的独立IP地址,POD会组成一个IP网络进行通信。

2.3 cgroups

Control Groups(cgroups)是Linux内核的技术,用于避免一个容器消耗节点中的所有CPU,内存,带宽等资源。每一个容器都有自己的cgoups, cgroups配置为每一个容器配置了一个最大限额,规定每一个容器最多消耗多少资源。

2.4 namespace

Namespace是逻辑上将一个K8S的集群划分为多个虚拟集群,这样虚拟划分是为了管理上更加方便。

3. Deployment/Manifest

Deployment是名为Manifest的yaml文件,我们将部署要求(也就是部署目标, Desired States)写在manifest.yaml的文件中,manifest.yaml文件包括了需要使用的容器镜像(Contioner Image)、具体需要运行容器数量(Replica)、监听端口、升级方法等等,然后将这个manifest.yaml文件发送给K8S管理面的API Service,然后K8S就会根据你描述的部署目标来部署你想要的业务集群。

当然K8S的管理面不是简单的执行部署就完了,这中间还有很多复杂的内容, 在部署之后,K8S的管理面(watch loop)会对部署的业务集群的运行状态进行实时的监控,这些监控会得到业务的集群的一个当前状态current states. 然后K8S的管理面(watch loop)对于二者进行比对,如果出现current states和desired states不一致的情况,K8S的管理面(watch loop)会针对这种差异进行调整,最大可能确保实际部署和目标部署之间是一致的。

举一个例子,在Manifest.yaml文件中描述的副本(Replica)的数量为10, 而当前的集群中实际运行的数量为8, 这种“目标状态”和“现实状态”之间的差异,会被K8S管理面(watch loop)发现,然后K8S的管理面对重新启动2个副本,确保k8s集群中运行的副本数量为10。

这也是k8s最大价值所在,你只需要告诉K8S管理面你希望一个怎么样的集群(通过manifest.yaml描述),然后K8S管理面就自动帮你完成部署和管理等工作,这样大幅减少了开发者和运维者的工作量,更多时间和精力可以放到具体业务实现上。

Deployment在K8S 1.2版本中就有出现,正式被集成的稳定版本是在1.9的版本中。

4. DNS Service

在上面POD的章节中讲了POD的生命周期,当一个POD挂了,替换它的新POD会有全新的IP地址和端口号,那么POD的变化是否会影响业务访问的IP和端口号呢? 答案当然是否定的,POD并不很稳定,如果POD挂了,引起服务访问的IP等信息变化的话,那不是天天都要改服务访问的IP地址。 K8S提供了类似DNS的服务,你可以理解类比前段和后端的概念来理解。 前端就是服务的访问IP地址和端口号等信息,这部分信息是稳定不变的,后端就是一个一个提供这种服务的POD信息,DNS Server提供了前端对外访问接口和后端POD的之间的映射,有效保证了服务访问接口的稳定,同时还提供了负荷分担等功能,确保访问流量可以平均分配到不同的POD上,实现资源的高效利用。

有关负荷分担(Load Balance)的实现使用Label和Lable Selector等知识,这里暂时不做深入展开,后续详细章节单独描述。

到此为止,已经介绍了K8S基础知识,知道了这些知识,就可以搭建K8S的集群了。 更多知识内容可以通过实际动手,不断来深入学习。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20200209A04AMN00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券