K8S系列深入解析有状态服务

Posted 颜淡慕潇

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了K8S系列深入解析有状态服务相关的知识，希望对你有一定的参考价值。

目录

序言

1 基本介绍

2 使用介绍

2.1  Headless Service

2.2 PersistentVolume

2.3 StatefulSet

2.4 Init Containers

 3 问题

4 投票

序言

在你想要放弃的时候，想想是什么让你当初坚持走到了这里。

Kubernetes (k8s) 是一个容器编排平台，允许在容器中运行应用程序和服务。今天学习一下有状态服务。

有状态服务是一种特殊类型的服务，它们需要保持数据的状态，以确保可靠性和一致性。在 Kubernetes 中，有状态服务通常是指需要持久化数据存储的服务，如数据库服务。

文章标记颜色说明：

  • 黄色：重要标题
  • 红色：用来标记结论
  • 绿色：用来标记一级论点
  • 蓝色：用来标记二级论点

1 基本介绍

在 Kubernetes 中，有状态服务可以使用 StatefulSet 来进行部署和管理。

StatefulSet 可以确保有状态服务的有序部署和缩放，并在节点失败时自动重新启动实例。

与 Deployment 不同，StatefulSet 提供了稳定的网络标识符和稳定的存储卷名称，以确保有状态服务在重新调度后仍能够保持其身份和数据。

以下是有状态服务在 Kubernetes 中的一些重要概念和实践：

  1. Headless Service：Headless Service 是一种没有 Cluster IP 的 Service，它提供了一个稳定的 DNS 记录，以便有状态服务可以通过 DNS 查找彼此。Headless Service 通常与 StatefulSet 配合使用，以确保每个 Pod 都有唯一的 DNS 记录和稳定的网络标识符。

  2. PersistentVolume：PersistentVolume 是一种 Kubernetes 资源，它表示一个持久化存储卷。有状态服务通常使用 PersistentVolume 来持久化存储数据。

  3. StatefulSet：StatefulSet 是一种 Kubernetes 资源，用于部署有状态服务。StatefulSet 可以确保有序部署和缩放，并在节点故障时自动重新启动实例。StatefulSet 还提供了稳定的网络标识符和稳定的存储卷名称，以确保有状态服务在重新调度后仍能够保持其身份和数据。

  4. Init Containers：Init Containers 是一种特殊类型的容器，它们在应用程序容器启动之前运行，并可以执行一些初始化任务，例如创建数据库或检查数据完整性。有状态服务通常使用 Init Containers 来进行一些必要的初始化操作。

总之，在 Kubernetes 中管理有状态服务需要使用一些特定的概念和实践，例如 Headless Service、PersistentVolume、StatefulSet 和 Init Containers。

这些工具和实践可以确保有状态服务的可靠性和一致性，并使其在节点故障和重新调度时能够正确地恢复和保持状态。

2 使用介绍

2.1  Headless Service

Headless Service 是 Kubernetes 中的一种服务类型，它不会分配 Cluster IP，并且不会进行负载均衡。

相反，它返回与服务中的每个端点相对应的 DNS 记录，这些记录可以用于直接访问这些端点。

Headless Service 通常用于需要直接与 Pod 进行通信的情况，例如 StatefulSet。

下面是一个使用 Headless Service 的示例代码：

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service # 
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset
spec:
  serviceName: my-headless-service
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: my-image
          ports:
            - containerPort: 8080
          env:
            - name: MY_POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
  1. 在上述示例中，定义了一个 Headless Service，名为 my-headless-service，并将其设置为 clusterIP: None，这样它就不会分配 Cluster IP。
  2. 然后，定义了一个 StatefulSet，名为 my-statefulset，并指定了 serviceName: my-headless-service，这意味着 StatefulSet 将使用我们定义的 Headless Service。
  3. 还指定了 replicas: 3，这意味着我们将有三个 Pod。每个 Pod 包含一个名为 my-container 的容器，该容器使用名为 my-image 的映像，并公开端口 8080。
  4. 还将 MY_POD_NAME 环境变量设置为 Pod 的名称，以便容器可以使用该名称来识别自己。
  5. 这是一个基本的 Headless Service 示例，当访问服务时，它将返回每个 Pod 的 DNS 记录，可以使用这些记录来直接访问每个 Pod。

2.2 PersistentVolume

PersistentVolume (PV)是 Kubernetes 中的一种资源对象，用于将存储系统的抽象层提升到Kubernetes平台上

它提供了一种独立于 Pod 的方式来管理和使用存储资源，以使应用程序在不同的节点上运行时能够使用相同的存储资源，使得 Pod 可以在多个节点之间移动而不会丢失数据。

以下是一个使用 PersistentVolume 的示例：

PersistentVolume提供了一种抽象机制，用于将存储资源分配给应用程序，而无需关心底层存储系统的细节。

下面是一个PersistentVolume的示例：

apiVersion: v1
kind: PersistentVolume #资源类型
metadata:
  name: pv-nfs
spec:
  storageClassName: nfs-storage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /mnt/data
    server: nfs.example.com

在这个示例中，创建了一个名为pv-nfs的PersistentVolume对象，它使用了nfs-storage存储类。

它有一个10GB的存储容量，可以同时被多个节点以读写方式访问。底层存储是一个NFS服务器，挂载点为/mnt/data。

接下来是一个使用PersistentVolume的示例Deployment：

apiVersion: apps/v1
kind: Deployment #资源类型
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
        - name: nginx-persistent-storage
          persistentVolumeClaim:
            claimName: nginx-pvc
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-persistent-storage
              mountPath: /usr/share/nginx/html

在这个示例中，创建了一个名为nginx-deployment的Deployment对象，它有三个副本。

这个Deployment对象使用了一个名为nginx-pvc的PersistentVolumeClaim对象。

Deployment中的Pod可以通过名为nginx-persistent-storage的卷来访问该PersistentVolumeClaim。Pod中的容器使用了这个卷，并将它挂载到容器的/usr/share/nginx/html目录中。

最后，下面是一个PersistentVolumeClaim的示例：

apiVersion: v1
kind: PersistentVolumeClaim #资源类型
metadata:
  name: nginx-pvc
spec:
  storageClassName: nfs-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

在这个示例中，创建了一个名为nginx-pvc的PersistentVolumeClaim对象，它使用了nfs-storage存储类。它请求10GB的存储空间，并且可以同时被多个节点以读写方式访问。

以上是PersistentVolume的示例和使用方式，通过这些示例，你可以了解到如何在Kubernetes中使用PersistentVolume资源对象。

2.3 StatefulSet

StatefulSet是Kubernetes中的一种资源对象，用于管理有状态应用程序的部署。与Deployment等其他部署对象不同，StatefulSet提供了有状态应用程序所需的唯一标识符和稳定的网络标识符。

以下是一个StatefulSet的示例，用于运行一个具有持久化存储的mysql数据库。

apiVersion: apps/v1
kind: StatefulSet #资源类型
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "password"
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

让我们逐个解释上面的代码：

  • apiVersion：指定使用的Kubernetes API版本。
  • kind：指定要创建的资源类型。
  • metadata.name：为StatefulSet指定唯一的名称。
  • spec.serviceName：为StatefulSet中所有Pods指定唯一的服务名称，以便其他应用程序可以通过DNS解析器访问它们。
  • spec.replicas：指定要创建的Pod副本数。
  • spec.selector：指定要部署的Pod的标签。
  • spec.template：为要部署的Pod定义一个模板。
  • spec.template.metadata.labels：为Pod定义标签，这些标签将用于将Pod与StatefulSet相关联。
  • spec.template.spec.containers：为要部署的容器定义一个列表。
  • spec.template.spec.containers.name：为容器指定一个名称。
  • spec.template.spec.containers.image：指定要使用的容器映像。
  • spec.template.spec.containers.env：定义容器的环境变量。
  • spec.template.spec.containers.ports：为容器指定要公开的端口。
  • spec.template.spec.containers.volumeMounts：定义要将持久卷挂载到容器的路径。
  • volumeClaimTemplates：为每个Pod创建一个持久卷声明，这些声明将指向上面定义的PersistentVolumeClaim（PVC）。

总的来说，以上示例中定义了一个MySQL StatefulSet，它包括3个Pods，每个Pod都挂载了一个10GB的持久卷，用于存储MySQL数据库。这些Pods具有唯一的名称（例如，mysql-0，mysql-1，mysql-2），并具有稳定的网络标识符（例如，mysql-0.mysql，mysql-1.mysql，mysql-2.mysql），使它们可以轻松地与其他应用程序进行通信。

2.4 Init Containers

Kubernetes (k8s) Init Containers是一种特殊类型的容器，它们用于在Pod中的主容器启动之前执行一些初始化任务。这些初始化任务可以包括预装软件、下载数据、初始化数据库等操作。

Init Containers会按照定义的顺序运行，并且只有在每个Init容器完成其任务后才会继续启动主容器。

这使得Kubernetes可以更好地控制和管理容器应用程序的生命周期和依赖关系。

下面是一个Init容器的示例定义：

apiVersion: v1
kind: Pod #资源类型
metadata:
  name: mypod
spec:
  containers:
    - name: main-container
      image: nginx:latest
  initContainers:
    - name: init-myservice
      image: busybox:latest
      command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']

在这个示例中，定义了一个Pod，其中包含一个名为main-container的容器和一个名为init-myservice的Init容器。

Init容器使用busybox镜像，并使用命令nslookup检查名为myservice的服务是否可以解析。

如果它无法解析，它将等待2秒钟并重试，直到成功为止。一旦Init容器完成它的任务，Kubernetes将继续启动主容器。

Init容器的代码示例如下：

apiVersion: v1
kind: Pod #资源类型
metadata:
  name: mypod
spec:
  initContainers:
    - name: init-myservice
      image: busybox:latest
      command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
    - name: init-mydbservice
      image: busybox:latest
      command: ['sh', '-c', 'until nc -zv mydb 3306; do echo waiting for mydb; sleep 2; done;']
  containers:
    - name: main-container
      image: nginx:latest

在这个示例中，定义了两个Init容器：init-myservice和init-mydbservice。

  • 第一个容器检查是否可以解析myservice服务，
  • 第二个容器检查是否可以连接到mydb数据库的3306端口。

一旦两个Init容器都完成它们的任务，Kubernetes将继续启动主容器。

 3 问题

思考一下这几个问题：

  1. 什么是有状态服务？如何与无状态服务区分开来？
  2. 有哪些常见的有状态服务？它们的特点是什么？
  3. 如何在 Kubernetes 中管理有状态服务？
  4. 如何进行有状态服务的伸缩？
  5. 如何实现有状态服务的高可用性？
  6. 如何进行有状态服务的备份和恢复？
  7. 如何进行有状态服务的数据持久化？
  8. 如何进行有状态服务的版本控制和滚动升级？
  9. 如何进行有状态服务的监控和故障排查？
  10. 有没有使用过 StatefulSet，能介绍一下它的特点和用法？

下篇文章，会解答这几个问题。

4 投票

死磕 java线程系列之线程池深入解析——生命周期

技术图片

（手机横屏看源码更方便）

注：java源码分析部分如无特殊说明均基于 java8 版本。

注：线程池源码部分如无特殊说明均指ThreadPoolExecutor类。

简介

上一章我们一起重温了下线程的生命周期（六种状态还记得不？），但是你知不知道其实线程池也是有生命周期的呢？！

问题

（1）线程池的状态有哪些？

（2）各种状态下对于任务队列中的任务有何影响？

先上源码

其实，在我们讲线程池体系结构的时候，讲了一些方法，比如shutDown()/shutDownNow()，它们都是与线程池的生命周期相关联的。

我们先来看一下线程池ThreadPoolExecutor中定义的生命周期中的状态及相关方法：

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3; // =29
private static final int CAPACITY   = (1 << COUNT_BITS) - 1; // =000 11111...

// runState is stored in the high-order bits
private static final int RUNNING    = -1 << COUNT_BITS; // 111 00000...
private static final int SHUTDOWN   =  0 << COUNT_BITS; // 000 00000...
private static final int STOP       =  1 << COUNT_BITS; // 001 00000...
private static final int TIDYING    =  2 << COUNT_BITS; // 010 00000...
private static final int TERMINATED =  3 << COUNT_BITS; // 011 00000...

// 线程池的状态
private static int runStateOf(int c)     { return c & ~CAPACITY; }
// 线程池中工作线程的数量
private static int workerCountOf(int c)  { return c & CAPACITY; }
// 计算ctl的值，等于运行状态“加上”线程数量
private static int ctlOf(int rs, int wc) { return rs | wc; }

从上面这段代码，我们可以得出：

（1）线程池的状态和工作线程的数量共同保存在控制变量ctl中，类似于AQS中的state变量，不过这里是直接使用的AtomicInteger，这里换成unsafe+volatile也是可以的；

（2）ctl的高三位保存运行状态，低29位保存工作线程的数量，也就是说线程的数量最多只能有(2^29-1)个，也就是上面的CAPACITY；

（3）线程池的状态一共有五种，分别是RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED；

（4）RUNNING，表示可接受新任务，且可执行队列中的任务；

（5）SHUTDOWN，表示不接受新任务，但可执行队列中的任务；

（6）STOP，表示不接受新任务，且不再执行队列中的任务，且中断正在执行的任务；

（7）TIDYING，所有任务已经中止，且工作线程数量为0，最后变迁到这个状态的线程将要执行terminated()钩子方法，只会有一个线程执行这个方法；

（8）TERMINATED，中止状态，已经执行完terminated()钩子方法；

流程图

下面我们再来看看这些状态之间是怎么流转的：

技术图片

（1）新建线程池时，它的初始状态为RUNNING，这个在上面定义ctl的时候可以看到；

（2）RUNNING->SHUTDOWN，执行shutdown()方法时；

（3）RUNNING->STOP，执行shutdownNow()方法时；

（4）SHUTDOWN->STOP，执行shutdownNow()方法时【本文由公从号“彤哥读源码”原创】；

（5）STOP->TIDYING，执行了shutdown()或者shutdownNow()后，所有任务已中止，且工作线程数量为0时，此时会执行terminated()方法；

（6）TIDYING->TERMINATED，执行完terminated()方法后；

源码分析

你以为贴个状态的源码，画个图就结束了嘛？那肯定不能啊，下面让我们一起来看看源码中是怎么控制的。

（1）RUNNING

RUNNING，比较简单，创建线程池的时候就会初始化ctl，而ctl初始化为RUNNING状态，所以线程池的初始状态就为RUNNING状态。

// 初始状态为RUNNING
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

（2）SHUTDOWN

执行shutdown()方法时把状态修改为SHUTDOWN，这里肯定会成功，因为advanceRunState()方法中是个自旋，不成功不会退出。

public void shutdown() {
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    try {
        checkShutdownAccess();
        // 修改状态为SHUTDOWN
        advanceRunState(SHUTDOWN);
        // 标记空闲线程为中断状态
        interruptIdleWorkers();
        onShutdown();
    } finally {
        mainLock.unlock();
    }
    tryTerminate();
}
private void advanceRunState(int targetState) {
    for (;;) {
        int c = ctl.get();
        // 如果状态大于SHUTDOWN，或者修改为SHUTDOWN成功了，才会break跳出自旋
        if (runStateAtLeast(c, targetState) ||
            ctl.compareAndSet(c, ctlOf(targetState, workerCountOf(c))))
            break;
    }
}

（3）STOP

执行shutdownNow()方法时，会把线程池状态修改为STOP状态，同时标记所有线程为中断状态。

public List<Runnable> shutdownNow() {
    List<Runnable> tasks;
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    try {
        checkShutdownAccess();
        // 修改为STOP状态
        advanceRunState(STOP);
        // 标记所有线程为中断状态
        interruptWorkers();
        tasks = drainQueue();
    } finally {
        // 【本文由公从号“彤哥读源码”原创】
        mainLock.unlock();
    }
    tryTerminate();
    return tasks;
}

至于线程是否响应中断其实是在队列的take()或poll()方法中响应的，最后会到AQS中，它们检测到线程中断了会抛出一个InterruptedException异常，然后getTask()中捕获这个异常，并且在下一次的自旋时退出当前线程并减少工作线程的数量。

private Runnable getTask() {
    boolean timedOut = false; // Did the last poll() time out?

    for (;;) {
        int c = ctl.get();
        int rs = runStateOf(c);

        // 如果状态为STOP了，这里会直接退出循环，且减少工作线程数量
        // 退出循环了也就相当于这个线程的生命周期结束了
        if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
            decrementWorkerCount();
            return null;
        }

        int wc = workerCountOf(c);

        // Are workers subject to culling?
        boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

        if ((wc > maximumPoolSize || (timed && timedOut))
            && (wc > 1 || workQueue.isEmpty())) {
            if (compareAndDecrementWorkerCount(c))
                return null;
            continue;
        }

        try {
            // 真正响应中断是在poll()方法或者take()方法中
            Runnable r = timed ?
                workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
                workQueue.take();
            if (r != null)
                return r;
            timedOut = true;
        } catch (InterruptedException retry) {
            // 这里捕获中断异常
            timedOut = false;
        }
    }
}

这里有一个问题，就是已经通过getTask()取出来且返回的任务怎么办？

实际上它们会正常执行完毕，有兴趣的同学可以自己看看runWorker()这个方法，我们下一节会分析这个方法。

（4）TIDYING

当执行shutdown()或shutdownNow()之后，如果所有任务已中止，且工作线程数量为0，就会进入这个状态。

final void tryTerminate() {
    for (;;) {
        int c = ctl.get();
        // 下面几种情况不会执行后续代码
        // 1. 运行中
        // 2. 状态的值比TIDYING还大，也就是TERMINATED
        // 3. SHUTDOWN状态且任务队列不为空
        if (isRunning(c) ||
            runStateAtLeast(c, TIDYING) ||
            (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty()))
            return;
        // 工作线程数量不为0，也不会执行后续代码
        if (workerCountOf(c) != 0) {
            // 尝试中断空闲的线程
            interruptIdleWorkers(ONLY_ONE);
            return;
        }

        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            // CAS修改状态为TIDYING状态
            if (ctl.compareAndSet(c, ctlOf(TIDYING, 0))) {
                try {
                    // 更新成功，执行terminated钩子方法
                    terminated();
                } finally {
                    // 强制更新状态为TERMINATED，这里不需要CAS了
                    ctl.set(ctlOf(TERMINATED, 0));
                    termination.signalAll();
                }
                return;
            }
        } finally {
            mainLock.unlock();
        }
        // else retry on failed CAS
    }
}

实际更新状态为TIDYING和TERMINATED状态的代码都在tryTerminate()方法中，实际上tryTerminated()方法在很多地方都有调用，比如shutdown()、shutdownNow()、线程退出时，所以说几乎每个线程最后消亡的时候都会调用tryTerminate()方法，但最后只会有一个线程真正执行到修改状态为TIDYING的地方。

修改状态为TIDYING后执行terminated()方法，最后修改状态为TERMINATED，标志着线程池真正消亡了。

（5）TERMINATED

见TIDYING中分析。

彩蛋

本章我们一起从状态定义、流程图、源码分析等多个角度一起学习了线程池的生命周期，你掌握的怎么样呢？

下一章我们将开始学习线程池执行任务的主流程，对这一块内容感到恐惧的同学可以先看看彤哥之前写的“手写线程池”的两篇文章，对接下来学习线程池的主要流程非常有好处。

以上是关于K8S系列深入解析有状态服务的主要内容，如果未能解决你的问题，请参考以下文章

K8S系列深入解析无状态服务

K8S系列深入解析滚动升级

2021百度Java岗面试真题收录解析，带你碾压面试官！

kubernetes常见故障

详解kubernetes备份恢复利器 Velero - 深入了解Carina系列第三期

kubernetes 中Pod的状态