干货速递 ▎Kubernetes 有状态集群服务部署与管理(下)
发布于 4个月前 作者 limeflavor 181 次浏览 来自 分享

千呼万唤始出来,《Kubernetes有状态集群服务部署与管理(下)》将着重介绍Kubernetes与有状态集群服务相关的两个新特性:Init ContainerPet Set

Tips: 关注公众号:tenxcloud2(时速云订阅号),回复 “1206” 即可下载现场PPT。

什么是Init Container?

从名字来看就是做初始化工作的容器。可以有一个或多个,如果有多个,这些 Init Container 按照定义的顺序依次执行,只有所有的Init Container 执行完后,主容器才启动。由于一个Pod里的存储卷是共享的,所以 Init Container 里产生的数据可以被主容器使用到。

Init Container可以在多种 K8S 资源里被使用到如 Deployment、Daemon Set, Pet Set, Job等,但归根结底都是在Pod启动时,在主容器启动前执行,做初始化工作。

我们在什么地方会用到 Init Container呢?

第一种场景是等待其它模块Ready,比如我们有一个应用里面有两个容器化的服务,一个是Web Server,另一个是数据库。其中Web Server需要访问数据库。但是当我们启动这个应用的时候,并不能保证数据库服务先启动起来,所以可能出现在一段时间内Web Server有数据库连接错误。为了解决这个问题,我们可以在运行Web Server服务的Pod里使用一个Init Container,去检查数据库是否准备好,直到数据库可以连接,Init Container才结束退出,然后Web Server容器被启动,发起正式的数据库连接请求。

第二种场景是做初始化配置,比如集群里检测所有已经存在的成员节点,为主容器准备好集群的配置信息,这样主容器起来后就能用这个配置信息加入集群。

还有其它使用场景,如将pod注册到一个中央数据库、下载应用依赖等。

这些东西能够放到主容器里吗?从技术上来说能,但从设计上来说,可能不是一个好的设计。首先不符合单一职责原则,其次这些操作是只执行一次的,如果放到主容器里,还需要特殊的检查来避免被执行多次。

这是Init Container的一个使用样例

这个例子创建一个Pod,这个Pod里跑的是一个nginx容器,Pod里有一个叫workdir的存储卷,访问nginx容器服务的时候,就会显示这个存储卷里的index.html 文件。

而这个index.html 文件是如何获得的呢?是由一个Init Container从网络上下载的。这个Init Container 使用一个busybox镜像,起来后,执行一条wget命令,获取index.html文件,然后结束退出。

由于Init Container和nginx容器共享一个存储卷(这里这个存储卷的名字叫workdir),所以在Init container里下载的index.html文件可以在nginx容器里被访问到。

可以看到 Init Container 是在 annotation里定义的。Annotation 是K8S新特性的实验场,通常一个新的Feature出来一般会先在Annotation 里指定,等成熟稳定了,再给它一个正式的属性名或资源对象名。

介绍完Init Container,千呼万唤始出来,主角Pet Set该出场了。

什么是Pet Set? 在数据结构里Set是集合的意思,所以顾名思义Pet Set就是Pet的集合,那什么是Pet呢?我们提到过Cattle和Pet的概念,Cattle代表无状态服务,而Pet代表有状态服务。具体在K8S资源对象里,Pet是一种需要特殊照顾的Pod。它有状态、有身份、当然也比普通的Pod要复杂一些。

具体来说,一个Pet有三个特征。

一是有稳定的存储,这是通过我们前面介绍的PV/PVC 来实现的。

二是稳定的网络身份,这是通过一种叫 Headless Service 的特殊Service来实现的。要理解Headless Service是如何工作的,需要先了解Service是如何工作。我们提到过Service可以为多个Pod实例提供一个稳定的对外访问接口。这个稳定的接口是如何实现的的呢,是通过Cluster IP来实现的,Cluster IP是一个虚拟IP,不是真正的IP,所以稳定。K8S会在每个节点上创建一系列的IPTables规则,实现从Cluster IP到实际Pod IP的转发。同时还会监控这些Pod的IP地址变化,如果变了,会更新IP Tables规则,使转发路径保持正确。所以即使Pod IP有变化,外部照样能通过Service的ClusterIP访问到后面的Pod。

普通Service的Cluster IP 是对外的,用于外部访问多个Pod实例。而Headless Service的作用是对内的,用于为一个集群内部的每个成员提供一个唯一的DNS名字,这样集群成员之间就能相互通信了。所以Headless Service没有Cluster IP,这是它和普通Service的区别。

Headless Service为每个集群成员创建的DNS名字是什么样的呢?右下角是一个例子,第一个部分是每个Pet自己的名字,后面foo是Headless Service的名字,default是PetSet所在命名空间的名字,cluser.local是K8S集群的域名。对于同一个Pet Set里的每个Pet,除了Pet自己的名字,后面几部分都是一样的。所以要有一个稳定且唯一的DNS名字,就要求每个Pet的名字是稳定且唯一的。

三是序号命名规则。 Pet是一种特殊的Pod,那么Pet能不能用Pod的命名规则呢?答案是不能,因为Pod的名字是不稳定的。Pod的命名规则是,如果一个Pod是由一个RC创建的,那么Pod的名字是RC的名字加上一个随机字符串。为什么要加一个随机字符串,是因为RC里指定的是Pod的模版,为了实现高可用,通常会从这个模版里创建多个一模一样的Pod实例,如果没有这个随机字符串,同一个RC创建的Pod之间就会由名字冲突。

如果说某个Pod由于某种原因死掉了,RC会新建一个来代替它,但是这个新建里的Pod名字里的随机字符串与原来死掉的Pod是不一样的。所以Pod的名字跟它的IP一样是不稳定的。

为了解决名字不稳定的问题,K8S对Pet的名字不再使用随机字符串,而是为每个Pet分配一个唯一不变的序号,比如 Pet Set 的名字叫 mysql,那么第一个启起来的Pet就叫 mysql-0,第二个叫 mysql-1,如此下去。

当一个Pet down 掉后,新创建的Pet 会被赋予跟原来Pet一样的名字。由于Pet名字不变所以DNS名字也跟以前一样,同时通过名字还能匹配到原来Pet用到的存储,实现状态保存。

这些是Pet Set 相关的一些操作:

  • Peer discovery,这和我们上面的Headless Service有密切关系。通过Pet Set的 Headless Service,可以查到该Service下所有的Pet 的 DNS 名字。这样就能发现一个Pet Set 里所有的Pet。当一个新的Pet起来后,就可以通过Peer Discovery来找到集群里已经存在的所有节点的DNS名字,然后用它们来加入集群。

  • 更新Replicas的数目、实现扩容和缩容。

  • 更新Pet Set里Pet的镜像版本,实现升级。

  • 删除 Pet Set。 删除一个Pet Set 会先把这个Pet Set的Replicas数目缩减为0,等到所有的Pet都被删除了,再删除 Pet Set本身。注意Pet用到的存储不会被自动删除。这样用户可以把数据拷贝走了,再手动删除。

以上,与有状态服集群服务相关的K8S特性就介绍完了。

把这些特性和有状态集群服务关联起来串一下,我们可以用Pet Set来管理一个有状态服务集群,Pet Set里每个Pet对应集群的一个成员,集群的初始化可以用 Init Container来完成。集群里每个成员的状态由Volume, Persistent Volume来存储,集群里每个Pet 唯一的DNS名字通过Headless Service来提供,集群里的成员之间就可以通过这个名字,相互通信。

回到顶部