Deployment实际上并不足以覆盖所有的应用编排问题,原因在于Deployment对应用做了一个简单化的假设:一个应用的所有Pod,是完全一样的。所以,它们互相之间没有顺序,也无所谓运行在哪台宿主机上。需要的时候,Deployment就可以通过Pod模板创建新的Pod;不需要的时候,Deployment就可以“杀掉”任意一个Pod。
但是,在实际的场景中,并不是所有的应用都可以满足这样的要求。尤其是分布式应用,它的多个实例之间,往往有依赖关系,比如:主从关系、主备关系。还有数据存储类应用,它的多个实例,往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉,即便重建出来,实例与数据之间的对应关系也已经丢失,从而导致应用失败。
这种实例之间有不对等关系,以及实例对外部数据有依赖关系的应用,就被称为“有状态应用”(Stateful Application)。
容器技术,可以很好地用来封装“无状态应用”(Stateless Application),尤其是Web服务。但是,一旦你想要用容器运行“有状态应用”,其困难程度就会直线上升。而且,这个问题解决起来,单纯依靠容器技术本身已经无能为力。
得益于“控制器模式”的设计思想,Kubernetes项目很早就在Deployment的基础上,扩展出了对“有状态应用”的初步支持。这个编排功能,就是:StatefulSet。
StatefulSet对应用状态做了两种情况的抽象:
StatefulSet的核心功能,就是通过某种方式记录这些状态,然后在Pod被重新创建时,能够为新Pod恢复这些状态。
在之前对Kubernetes架构的介绍中提到,Service是Kubernetes项目中用来将一组Pod暴露给外界访问的一种机制。比如,一个Deployment有3个Pod,那么我就可以定义一个Service。然后,用户只要能访问到这个Service,它就能访问到某个具体的Pod。
通过以下方式可以访问该service:
具体来看标准的Headless Service对应的YAML文件:
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
所谓的Headless Service,其实仍是一个标准Service的YAML文件。只不过,它的clusterIP字段的值是:None,即:这个Service,没有一个VIP作为“头”。这也就是Headless的含义。所以,这个Service被创建后并不会被分配一个VIP,而是会以DNS记录的方式暴露出它所代理的Pod。它所代理的Pod是采用Label Selector机制选择出来的,即:所有携带了app=nginx标签的Pod,都会被这个Service代理起来。
当按照这样的方式创建了一个Headless Service之后,它所代理的所有Pod的IP地址,都会被绑定一个这样格式的DNS记录,如下所示:
<pod-name>.<svc-name>.<namespace>.svc.cluster.local
这个DNS记录,正是Kubernetes项目为Pod分配的唯一的“可解析身份”(Resolvable Identity)。有了这个“可解析身份”,只要你知道了一个Pod的名字,以及它对应的Service的名字,你就可以非常确定地通过这条DNS记录访问到Pod的IP地址。
我们来看一个StatefulSet的YAML文件:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.1
ports:
- containerPort: 80
name: web
这个YAML文件,和我们在前面文章中用到的nginx-deployment的唯一区别,就是多了一个serviceName=nginx字段。这个字段的作用,就是告诉StatefulSet控制器,在执行控制循环(Control Loop)的时候,请使用nginx这个Headless Service来保证Pod的“可解析身份”。
当通过kubectl create创建了上面这个Service和StatefulSet之后,就会看到如下两个对象:
$ kubectl create -f svc.yaml
$ kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 10s
$ kubectl create -f statefulset.yaml
$ kubectl get statefulset web
NAME DESIRED CURRENT AGE
web 2 1 19s
可以实时查看这个StatefulSet创建过程中的Events信息:
$ kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 19s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 20s
StatefulSet给它所管理的所有Pod的名字,进行了编号,编号规则是:statefulset name-ordinal index。
这些编号都是从0开始累加,与StatefulSet的每个Pod实例一一对应,绝不重复;这些Pod的创建,也是严格按照编号顺序进行的。比如,在web-0进入到Running状态、并且细分状态(Conditions)成为Ready之前,web-1会一直处于Pending状态。当这两个Pod都进入了Running状态之后,你就可以查看到它们各自唯一的“网络身份”了。
使用kubectl exec命令进入到容器中查看它们的hostname:
$ kubectl exec web-0 -- sh -c 'hostname'
web-0
$ kubectl exec web-1 -- sh -c 'hostname'
web-1
可以看到,这两个Pod的hostname与Pod名字是一致的,都被分配了对应的编号。
我们以DNS的方式,访问一下这个Headless Service:
$ kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh
$ nslookup web-0.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-0.nginx
Address 1: 10.244.1.7
$ nslookup web-1.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-1.nginx
Address 1: 10.244.2.7
从nslookup命令的输出结果中,我们可以看到,在访问web-0.nginx的时候,最后解析到的,正是web-0这个Pod的IP地址;而当访问web-1.nginx的时候,解析到的则是web-1的IP地址。
如果你在另外一个Terminal里把这两个“有状态应用”的Pod删掉:
$ kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
再在当前Terminal里Watch一下这两个Pod的状态变化
$ kubectl get pod -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 32s
可以看到,当我们把这两个Pod删除之后,Kubernetes会按照原先编号的顺序,创建出了两个新的Pod。并且,Kubernetes依然为它们分配了与原来相同的“网络身份”:web-0.nginx和web-1.nginx。
通过这种严格的对应规则,StatefulSet就保证了Pod网络标识的稳定性。
再用nslookup命令,查看一下这个新Pod对应的Headless Service的话:
$ kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
$ nslookup web-0.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-0.nginx
Address 1: 10.244.1.8
$ nslookup web-1.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-1.nginx
Address 1: 10.244.2.8
在这个StatefulSet中,这两个新Pod的“网络标识”(比如:web-0.nginx和web-1.nginx),再次解析到了正确的IP地址(比如:web-0 Pod的IP地址10.244.1.8)。
通过这种方法,Kubernetes就成功地将Pod的拓扑状态(比如:哪个节点先启动,哪个节点后启动),按照Pod的“名字+编号”的方式固定了下来。此外,Kubernetes还为每一个Pod提供了一个固定并且唯一的访问入口,即:这个Pod对应的DNS记录。这些状态,在StatefulSet的整个生命周期里都会保持不变,绝不会因为对应Pod的删除或者重新创建而失效。
不过,尽管web-0.nginx这条记录本身不会变,但它解析到的Pod的IP地址,并不是固定的。这就意味着,对于“有状态应用”实例的访问,你必须使用DNS记录或者hostname的方式,而绝不应该直接访问这些Pod的IP地址。
StatefulSet这个控制器的主要作用之一,就是使用Pod模板创建Pod的时候,对它们进行编号,并且按照编号顺序逐一完成创建工作。而当StatefulSet的“控制循环”发现Pod的“实际状态”与“期望状态”不一致,需要新建或者删除Pod进行“调谐”的时候,它会严格按照这些Pod编号的顺序,逐一完成这些操作。所以,StatefulSet其实可以认为是对Deployment的改良。
与此同时,通过Headless Service的方式,StatefulSet为每个Pod创建了一个固定并且稳定的DNS记录,来作为它的访问入口。
实际上,在部署“有状态应用”的时候,应用的每个实例拥有唯一并且稳定的“网络标识”,是一个非常重要的假设。
此文章为3月Day18学习笔记,内容来源于极客时间《深入剖析Kubernetes》