Spring boot2.3.0 碰见 Kubernetes

Spring Boot 是经常使用 Java 微服务框架之一。Spring Cloud 拥有一组丰富的、良好集成的 Java 类库，用于应对 Java 应用程序堆栈中发生的运行时问题；而 Kubernetes 则提供了丰富的功能集来运行多语言微服务。这些技术彼此互补，为 Spring Boot 应用程序提供了强大的平台。

本文不是讲述如何将Spring Boot 程序部署到Kubernetes中，网上已经有大量的部署实践文章，你们有兴趣的能够查阅。主要讲述Spring Boot社区为了进一步简化和规范Spring Boot on k8s而作出的一些功能加强。你们彻底能够将这些新功能实践到本身项目中。

Liveness 和 Readiness

首先咱们简单介绍一下，kubernetes 中 Liveness 和 Readiness的含义。

在Kubernetes中，Liveness 和 Readiness表明了应用程序状态的各个方面。

应用程序的Liveness状态代表内部状态是否有效，若是Liveness 失败，则意味着应用程序自己处于故障状态而且没法从中恢复，在这种状况下，最佳的操做方法是从新启动应用程序例如，若是本地缓存已损坏且没法修复，则依赖本地缓存的应用程序应使其Liveness检测失败。

Readiness状态告诉应用程序是否准备好接受客户端请求;若是Readiness状态还没有就绪，则Kubernetes不该将流量路由到该实例;若是应用程序正忙于处理任务队列，则它能够将本身声明为繁忙，直到其执行负载能够再次管理。

那么接下来咱们看下Spring Boot怎么支持Liveness 和 Readiness。

Liveness 和 Readiness 成为 Spring Boot 核心概念

Liveness 和 Readiness概念不只适用于Kubernetes，并且不管部署平台如何，它们一般都有用。引入了LivenessState和ReadinessState，它们是这些概念的不可变表示形式。您能够随时从ApplicationAvailability中获取它们：

// Available as a component in the application context
ApplicationAvailability availability;

LivenessState livenessState = availabilityProvider.getLivenessState();
ReadinessState readinessState = availabilityProvider.getReadinessState()

经过轮询,获取应用程序的状态是不完整的。只有应用程序知道其生命周期（启动，关闭），或者能够提供有关运行时错误的上下文（在处理任务时以中断状态结束）。Spring Boot应用程序上下文在应用程序的生命周期内发布这些事件，您的应用程序代码也应对此作出适配。

这就是为何咱们选择使用Spring Application Event模型来更改可用性状态并监听更新的缘由：

/**
 * Component that checks that the local cache is in a valid state.
 */
@Component
public class LocalCacheVerifier {

    private final ApplicationEventPublisher eventPublisher;

    public LocalCacheVerifier(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void checkLocalCache() {
        try {
            //...
        }
        catch (CacheCompletelyBroken ex) {
            AvailabilityChangeEvent.publish(this.eventPublisher, LivenessState.BROKEN);
        }
    }

}

组件还可使用@EventListener监听这些事件（或经过实现ApplicationListener）。请查阅参考文档以获取更多信息。

该支持直接与spring-boot模块一块儿提供，并已为全部Spring Boot应用程序激活；这使其可用于全部类型的应用程序（Web，批处理等），并容许您实现不必定与HTTP绑定的探针。

使用Spring Boot Actuator公开Kubernetes探针

可能会对一个很是常见的用例感兴趣：在Kubernetes上部署Web应用程序并配置HTTP探针，将Spring Boot Actuator依赖项添加到您的应用程序是惟一的要求！Actuator将使用Health支持配置Liveness和Readiness HTTP探针。

Actuator将从ApplicationAvailability收集“Liveness”和“Readiness”信息，并将其用于专用的健康指标：LivenessStateHealthIndicator和ReadinessStateHealthIndicator。这些指标将暴露在"/actuator/health"路径上。若是须要进一步了解“Liveness”和“Readiness”信息，能够经过"/actuator/health/liveness" 和 "/actuator/health/readiness"访问得到。

在Kubernetes上运行的应用程序将显示如下运行情况报告：

// http://localhost:8080/actuator/health
// HTTP/1.1 200 OK

{
  "status": "UP",
  "components": {
    "diskSpace": {
      "status": "UP",
      "details": { //...
      }
    },
    "livenessProbe": {
      "status": "UP"
    },
    "ping": {
      "status": "UP"
    },
    "readinessProbe": {
      "status": "UP"
    }
  },
  "groups": [
    "liveness",
    "readiness"
  ]
}

调用Liveness组时，Kubernetes将得到如下信息：

// http://localhost:8080/actuator/health/liveness
// HTTP/1.1 200 OK

{
  "status": "UP",
  "components": {
    "livenessProbe": {
      "status": "UP"
    }
  }
}

标记为未就绪的应用程序将为“就绪”组报告如下内容：

// http://localhost:8080/actuator/health/readiness
// HTTP/1.1 503 SERVICE UNAVAILABLE

{
  "status": "OUT_OF_SERVICE",
  "components": {
    "readinessProbe": {
      "status": "OUT_OF_SERVICE"
    }
  }
}

HTTP探针仅针对Kubernetes上运行的应用程序进行配置。您能够经过使用management.health.probes.enabled = true配置属性手动启用探针在本地进行尝试。因为探针是运行情况组，所以您将得到许多其余功能例如配置HTTP状态映射器，安全性，详细信息可见性…

固然，您能够将其余运行情况指示器配置为探针的一部分，以检查外部系统的状态：数据库，Web API，共享缓存。给定现有的CacheCheckHealthIndicator，您可使用如下方法扩充活动性探针：

management.endpoint.health.group.liveness.include=livenessProbe,cacheCheck

Graceful shutdown

因为运行在Kubernetes中的Pod存在动态的特性，这就要求咱们的应用程序要作相应的适配。优雅关闭就是其中重要的一个。须要应用程序监听SIGTERM信号，中止接受新的连接，处理已有的连接等等。此时框架提供了该功能，那么咱们的业务代码能够更加简单。

下面讲了Spring boot 框架是怎么实现的？

全部四个嵌入式Web服务器（Jetty，Reactor Netty，Tomcat和Undertow）以及基于响应的和基于Servlet的Web应用程序都支持正常关闭。启用后，应用程序关闭将包括可配置持续时间的宽限期。宽限期内，现有请求将被容许完成，但新请求将被禁止。不容许新请求的确切方式因所使用的Web服务器而异，Jetty，Reactor Netty和Tomcat将中止接受请求Undertow将接受请求，但会当即以服务不可用（503）响应进行响应。

正常关闭是在应用程序关闭处理期间以及销毁任何Bean以前的第一步，这确保了容许在运行中请求完成时发生的任何处理均可以使用这些Bean。 配置server.shutdown.grace-period 属性，如如下示例所示：

server.shutdown.grace-period=30s

理论上该值应该和Kubernetes 部署yaml中的terminationGracePeriodSeconds设定的值相等。

固然除了这两个比较重要的特性，还有Docker镜像建立这个点，感兴趣的能够去了解一下，这里再也不阐述。