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 的管理:
- 拓扑状态:通过 service + pod 的形式找到每个 pod 的 ip,当 pod 删掉再重建之后 Kubernetes 还是能给它配置原来的 ip。
- 存储状态:通过 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 概述的主要内容,如果未能解决你的问题,请参考以下文章
k8sKubernetes存储之 StatefulSet 控制器通过 Headless Service 管理Pod