实际场景中，尤其是分布式应用，多个实例之间，往往有依赖关系，比如：主从关系、主备关系。对于数据存储类应用，它的多个实例，往往都会在本地磁盘保存一份数据。导致这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用创建失败。

这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”

StatefulSet将应用状态抽象成了两种情况：

• 拓扑状态。应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样

• 存储状态。应用的多个实例分别绑定了不同存储数据。

Headless Service

---

Service是Kubernetes项目用来将一组Pod暴露给外界访问的一种机制。

Service被访问的方式：

• Service的VIP（Virtual IP）

• Service的DNS方式，只要访问“my-svc.my-namespace.svc.cluster.local”这条DNS记录，就可以访问到名为my-svc的Service所代理的某一个Pod

在第二种Service DNS的方式下，具体还可以分为两种处理方法：

第一种处理方法，是Normal Service。这种情况下，访问“my-svc.my-namespace.svc.cluster.local”解析到的，正是my-svc这个Service 的VIP，后面的流程和VIP一致

第二种处理方法，是Headless Service。这种情况下，访问“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是my-svc代理的某一个Pod的IP地址。这里的区别在于，Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

Headless Service的作用

所谓的Headless Service仍是一个标准的Service的YAML文件，只不过spec.clusterIP的值为None，即这个Service没有一个VIP做为头。这个Service被创建后并不会分配一个VIP，而是以DNS记录的方式暴露它所代理的Pod

当按照这样的方式创建了一个Headless Service后，它所代理的所有Pod的IP地址，都会被绑定一个如下格式的DNS记录，如下：

...svc.cluster.local

这条DNS记录，是Kubernetes为Pod分配的唯一“可解析身份”

StatefulSet如何通过Headless Service维持Pod的拓扑状态

apiVersion: v1

kind: Service

metadata:

name: nginx

labels:

app: nginx

spec:

ports:

• port: 80

name: web

clusterIP: None

selector:

app: nginx

---

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

然后我们创建这个service和statefulset

[root@host1 statefulset]# kubectl create -f nginx-statefulset.yaml

service/nginx created

statefulset.apps/web created

[root@host1 statefulset]# kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 443/TCP 23h

nginx ClusterIP None 80/TCP 9s

[root@host1 statefulset]# kubectl get statefulset

NAME READY AGE

web 2/2 22s

[root@host1 statefulset]# kubectl get pods

NAME READY STATUS RESTARTS AGE

web-0 1/1 Running 0 104s

web-1 1/1 Running 0 103s

StatefulSet给它所管理的所有的Pod的名字进行了编号，编号规则是：-；并且这些编号都是从0开始累加，与StatefulSet的每个Pod实例一一对应；这些Pod的创建也是严格按照编号顺序进行的。比如在web-0进入到running状态，并且Conditions为Ready之前，web-1一直会处于pending状态

使用kubectl exec命令进入到容器内部查看它们的hostname：

[root@host1 statefulset]# kubectl exec web-0 – sh -c ‘hostname’

web-0

[root@host1 statefulset]# kubectl exec web-1 – sh -c ‘hostname’

web-1

并且，就算Pod被删除后重建，重建Pod的网络标识也不会改变，通过这种方式，Kubernetes就可以成功地将Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来，并且Kubernetes为每个Pod提供了一个固定且唯一的访问入口（这个Pod对应的DNS记录）。

StatefulSet控制器的主要作用之一，就是使用Pod模板创建Pod的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。当StatefulSet的控制循环发现Pod的实际状态和期望状态不一致的时候，需要新建或删除Pod进行调谐的时候，它会严格按照这些Pod编号的顺序，逐一完成这些操作。任何Pod的变化都会触发statefulset的滚动更新

存储管理

---

Kubernetes中PV和PVC的设计，类似于“接口”和“实现”的思想。PV和PVC的设计，使得StatefulSet对存储状态的管理成为了可能。

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

volumeMounts:

• name: www

mountPath: /usr/share/nginx/html

volumeClaimTemplates:

• metadata:

name: www

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

写在最后

还有一份JAVA核心知识点整理（PDF）：JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算…

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
etty与RPC**，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算…

[外链图片转存中…(img-kTOa5Kd6-1713397928359)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！