Deployment 和 StatefulSets 概述

Posted lubanseven

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Deployment 和 StatefulSets 概述相关的知识,希望对你有一定的参考价值。


这篇概述是看文章提到的一段话 xxx is not targeted to be horizontally scalable 引发的,遂整理记录在这里。

起因是有两个应用,一个是无状态的,可以 horizontally scalable,另一个是有状态的,和数据库绑定,horizontally scalable。无状态的应用配成 Deployment, 有状态的应用配成 StatefulSets。

引发的思考是:有状态的应用怎么和数据库绑定以及扩展有状态应用会发生什么?带着这个问题开始了学习,并且整理如下。

Deployment 和 StatefulSets 控制器

介绍这两种控制器之前,先说下 Pod。Pod 是对 container 的一层封装,它的结构体定义可以看 这里:

// Pod is a collection of containers that can run on a host. This resource is created
// by clients and scheduled onto hosts.
type Pod struct 
	metav1.TypeMeta `json:",inline"`
	...

直接对 container 控制是很难控制的,比如扩展伸缩,网络管理等。所以,kubernetes 引入了 Pod 结构体作为最小的细粒度单元进行管理。在
深入剖析 Kubernetes 中将 container 比喻为集装箱,将 Pod 比喻为集装箱上的"抓手",这个比喻是很合理的。

那对于"抓手"用什么去抓呢?所谓的,起重机是哪个?

控制器就是这个起重机,在 Kubernetes 中控制器负责 Pod 的扩展伸缩等一系列控制,之所以是一系列是因为控制器不是一种,每种控制器负责不同的控制操作,它们都属于 kube controller manager
组件下定义的控制器,不同控制器可看 这里。控制器遵循通用的循环控制编排模式,其伪代码实现如下:

for 
	acutalStatus := x.getPodActualStatus
	expectStatus := x.getPodExpectStatus
	
	if acutalStatus != expectStatus 
		doControllerAction(...)  // change the actual status to expected status
	else
		doNothing
	

对于 Pod 的扩展伸缩,编排控制器有 replicationcontrollers,它直接对 Pod 进行控制,当 Pod 期望数量和实际数量不一致时,扩展 Pod 实际数量到期望数量。反之亦然。

不过在用 replicationcontrollers 进行控制时有个问题,就是无法做到对 Pod 滚动更新的支持。试想 replicationcontrollers 控制器 A 直接控制 pod b,当 pod b 更新到
pod c 时,A 直接控制 c。如果此时想回去 b 就回不去了,因为 A 直接控制的是 c。

Kubernetes 引入了 Deployment 和 ReplicaSets 来支持滚动更新。Deployment 控制 replicasets,再由 ReplicaSets 控制 pod。ReplicaSets 对 pod 的控制是直接的,Deployment 对于
pod 的控制是间接的(可以通过 ownerReference field 查看对象所属的 owner)。

可由一张图解释这一控制过程:

Deployment 控制 ReplicaSet(v1), ReplicaSet(v1) 控制 pod。当做滚动更新时,Deployment 创建新的 ReplicaSet(v2),由 v2 创建新版本 pod,并且 v1 删除旧版本 pod(这里涉及到 pod
滚动更新策略,不细讲)。最终,滚动更新的新 pod 由 v2 控制,而旧的 ReplicaSet v1 还在,当需要回滚时,旧的 pod 会再次被 ReplicaSet 创建。

至此,Pod 的扩展伸缩和滚动更新都做好了。

不过,还有一个问题。不管 Deployment 还是 ReplicationController 其管理的 pod 都是无状态的。默认 pod 都是一样的,而实际应用往往对 pod 的要求是有状态的。
比如 Pod 需要依赖特定数据库,比如 pod 有主备之分等情况,都没办法让这类 pod 由 Deployment 管理。

基于此,kubernetes 引入了 StatefulSets 控制器,顾名思义,它是对有状态 Pod 的管理。

StatefulSets 通过两点实现有状态 Pod 的管理:

  1. 拓扑状态:通过 service + pod 的形式找到每个 pod 的 ip,当 pod 删掉再重建之后 Kubernetes 还是能给它配置原来的 ip。
  2. 存储状态:通过 pvc 的形式将 pod 和 pvc 绑定,当 pod 扩展伸缩时,相应的 pvc 也会动态扩展伸缩。

对于第一点和第二点,在扩展讲一点,详细内容可看这里

拓扑状态

# nslookup yyy.luban.svc.cluster.local
Server:         172.17.7.2
Address:        172.17.7.2#53

Name:   yyy.luban.svc.cluster.local
Address: 10.10.xxx.xxx

# kubectl get endpoints  -n luban | grep yyy
yyy                        10.10.xxx.xxx  

其中, yyy 是创建的 headless service,通过 DNS 解析出它对应的 endpoints,10.10.xxx.xxx 是对应的 pod ip。

存储状态

在 yaml 文件中添加 volumeClaimTemplates 模板定义 pod 绑定的 pvc:


apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  ...
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

其中,pvc 将和 pod 一一绑定,扩展 pod 数,相应的 pvc 也会扩展:

$ kubectl get statefulsets.apps 
NAME   READY   AGE
web    2/2     2m16s

$ kubectl edit statefulsets.apps 
statefulset.apps/web edited

$ kubectl get pods
NAME    READY   STATUS              RESTARTS   AGE
web-0   1/1     Running             0          2m38s
web-1   1/1     Running             0          90s
web-2   0/1     ContainerCreating   0          4s

$ kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-web-0   Bound    pvc-53b1361a-dc5f-4722-ae92-48dafd0717cb   1Gi        RWO            standard       2m43s
www-web-1   Bound    pvc-332fa158-ecd9-4d3a-ada4-497b2bae1b3a   1Gi        RWO            standard       95s
www-web-2   Bound    pvc-d5c1eb0c-ad91-4095-9da7-1876b1dfa135   1Gi        RWO            standard       9s

芝兰生于空谷,不以无人而不芳。

以上是关于Deployment 和 StatefulSets 概述的主要内容,如果未能解决你的问题,请参考以下文章

k8s集群StatefulSets的Pod优雅调度问题思考

k8sKubernetes存储之 StatefulSet 控制器通过 Headless Service 管理Pod

k8sKubernetes存储之 StatefulSet 控制器通过 Headless Service 管理Pod

K8SRCRS和Deployment

K8SRCRS和Deployment

K8SRCRS和Deployment