网库网(www.wangkuwang.com)精品网站源码,织梦建站模版,游戏源代码分享平台

模板户源码

当前位置:首页 -> 下载中心 -> 软件工具 正文

应用程序之Kubernetes和Spring Boot自我修复

时间:2019-03-16 08:25:19 [整站源码]作者:zhaopulei


影宸风洛 时速云


在本篇文章中,我们将讨论Kubernetes的探测器,并演示如何利用Actuator的HealthIndicator准确查看应用程序的状态。由于本教程的目的,我们将假设Spring Boot Actuator,Kubernetes和Docker已预先存在。


本文作者:Daniel Barrigas

来源:SpringForAll社区

 

Kubernetes Probes


Kubernetes定义了两种不同的探针-Liveness and Readiness (活跃度和就绪检查度),我们可以用它来定期检查一切是否按预期工作。


1. Liveness and Readiness


通过Liveness和Readiness探测器,Kubelet可以在检测到某些东西时立即响应,并最大限度地减少应用程序的停机时间。


两者都以相同的方式配置,但它们具有不同的语义,Kubelet根据触发的操作来执行:


  • Readiness – 就绪检查验证Pod是否已准备好开始接收流量。当pod的所有容器都准备就绪时,Pod也已准备好。

  • Liveness – 与就绪检查相反,活跃度检查Pod是否应该重新启动。它可以获取正在运行但处于无法取得进展的状态的应用程序;例如,它处于死锁状态


我们在容器级别配置两种探测器类型:


  1. apiVersion: v1

  2. kind: Pod

  3. metadata:

  4.  name: goproxy

  5.  labels:

  6.    app: goproxy

  7. spec:

  8.  containers:

  9.  - name: goproxy

  10.    image: k8s.gcr.io/goproxy:0.1

  11.    ports:

  12.    - containerPort: 8080

  13.    readinessProbe:

  14.      tcpSocket:

  15.        port: 8080

  16.      initialDelaySeconds: 5

  17.      periodSeconds: 10

  18.      timeoutSeconds: 2

  19.      failureThreshold: 1

  20.      successThreshold: 1

  21.    livenessProbe:

  22.      tcpSocket:

  23.        port: 8080

  24.      initialDelaySeconds: 15

  25.      periodSeconds: 20

  26.      timeoutSeconds: 2

  27.      failureThreshold: 1


我们可以通过配置更多字段来更精确地控制探针的行为:


  • initialDelaySeconds – 创建容器后,在启动探测之前须等待的秒树

  • periodSeconds –探测器每次运行时长,默认为10秒;最小值是1秒

  • timeoutSeconds – 探测超时时长,默认为1秒;最小值再次为1秒

  • failureThreshold – 失败重试次数。在准备就绪的情况下,pod将被标记为未准备好,而在活跃的情况下失败意味着重新启动Pod。此处的默认值为3次失败,最小值为1

  • successThreshold – 探测失败后最小连续成功数。默认为1成功,最小值为1


在本篇文章中,我们选择了tcp探测器,但是,我们也可以使用其他类型的探测器。


2. Probe Types(探测器类型)


根据使用场景,某种特定的探针类型可能比另一种更有用。例如,如果我们的容器是Web服务器,则使用http探测器可能比tcp探测器更可靠。


幸运的是,Kubernetes提供三种不同类型的探针可供我们选择:


  • exec – 在容器中执行bash指令。例如,检查特定文件是否存在。如果指令返回失败码,则探测失败

  • tcpSocket – 尝试使用指定的端口建立与容器的tcp连接。如果无法建立连接,则探测失败

  • httpGet – 发送HTTP GET请求到容器中运行的服务器并侦听指定的端口。任何大于或等于200且小于400的返回码表示成功


值得注意得是HTTP探测器除了前面提到的那些之外还有以下字段:


  • host – 要连接的主机名,默认为pod的IP

  • scheme – HTTP或HTTPS的连接方案,默认为HTTP

  • path – 在Web服务器上访问的路径

  • httpHeaders – 请求中设置的自定义标头

  • port – 在容器中访问的端口的名称或编号


Spring Actuator and Kubernetes Self-Healing Capabilities


现在我们已经了解了Kubernetes如何检测我们的应用程序是否处于损坏状态,让我们看看我们如何利用Spring的Actuator来监视我们的应用程序以及它的依赖jar!


为了达到示例的目的,我们将依赖于Minikube。


1. Actuator and its HealthIndicators


考虑到Spring有许多HealthIndicators可以使用,应用程序依赖于Kubernetes的探测器的返回状态就像在我们的pom.xml中添加Actuator依赖一样简单:


  1. <dependency>

  2.    <groupId>org.springframework.boot</groupId>

  3.    <artifactId>spring-boot-starter-actuator</artifactId>

  4. </dependency>


2. Liveness Example


让我们正常启动一个应用程序,30秒后将转换为一个非正常的状态。


我们将通过创建HealthIndicator,通过验证布尔变量是否为真,来模拟一个非正常状态。我们将变量初始化为true,然后我们将安排任务在30秒后将其更改为false:


  1. @Component

  2. public class CustomHealthIndicator implements HealthIndicator {


  3.    private boolean isHealthy = true;


  4.    public CustomHealthIndicator() {

  5.        ScheduledExecutorService scheduled =

  6.          Executors.newSingleThreadScheduledExecutor();

  7.        scheduled.schedule(() -> {

  8.            isHealthy = false;

  9.        }, 30, TimeUnit.SECONDS);

  10.    }


  11.    @Override

  12.    public Health health() {

  13.        return isHealthy ? Health.up().build() : Health.down().build();

  14.    }

  15. }


有了HealthIndicator,我们需要使用dockerize 运行应用程序:


  1. FROM openjdk:8-jdk-alpine

  2. RUN mkdir -p /usr/opt/service

  3. COPY target/*.jar /usr/opt/service/service.jar

  4. EXPOSE 8080

  5. ENTRYPOINT exec java -jar /usr/opt/service/service.jar


接下来,我们创建Kubernetes模板:


  1. apiVersion: apps/v1

  2. kind: Deployment

  3. metadata:

  4.  name: liveness-example

  5. spec:

  6.  ...

  7.    spec:

  8.      containers:

  9.      - name: liveness-example

  10.        image: dbdock/liveness-example:1.0.0

  11.        ...

  12.        readinessProbe:

  13.          httpGet:

  14.            path: /health

  15.            port: 8080

  16.          initialDelaySeconds: 10

  17.          timeoutSeconds: 2

  18.          periodSeconds: 3

  19.          failureThreshold: 1

  20.        livenessProbe:

  21.          httpGet:

  22.            path: /health


  23.          initialDelaySeconds: 20

  24.          timeoutSeconds: 2

  25.          periodSeconds: 8

  26.          failureThreshold: 1


我们正在使用指向Actuator健康端点的httpGet探针。应用程序状态(及其依赖项)的任何更改都将反映在我们部署的健康检查上。


在将我们的应用程序部署到Kubernetes后,我们将能够看到两个探测器在运行:大约30秒后,我们的Pod将被标记为未准备好并从循环中移除;几秒钟后,Pod重新启动。


我们可以看到我们的Pod执行kubectl的事件描述-pod liveness-example:


  1. Warning  Unhealthy 3s (x2 over 7s)   kubelet, minikube  Readiness probe failed: HTTP probe failed ...

  2. Warning  Unhealthy 1s                kubelet, minikube  Liveness probe failed: HTTP probe failed ...

  3. Normal   Killing   0s                kubelet, minikube  Killing container with id ...


3. Readiness Example


在前面的示例中,我们了解了如何使用HealthIndicator来监测部署在Kubernetes的应用程序健康状况。


让我们在不同的场景上使用它:假设我们的应用程序需要一点时间才能接收流量。例如,它需要将文件加载到内存中并验证其内容。


这是一个很好的利用就绪检查探测例子。


让我们修改上一个示例中的HealthIndicator和Kubernetes模板,并使它们适用于这个场景:


  1. @Component

  2. public class CustomHealthIndicator implements HealthIndicator {


  3.    private boolean isHealthy = false;


  4.    public CustomHealthIndicator() {

  5.        ScheduledExecutorService scheduled =

  6.          Executors.newSingleThreadScheduledExecutor();

  7.        scheduled.schedule(() -> {

  8.            isHealthy = true;

  9.        }, 40, TimeUnit.SECONDS);

  10.    }


  11.    @Override

  12.    public Health health() {

  13.        return isHealthy ? Health.up().build() : Health.down().build();

  14.    }

  15. }


我们将变量初始化为false,并在40秒后执行任务并将其设置为true。


接下来,我们使用以下模板对我们的应用程序进行dockerize并部署:


  1. apiVersion: apps/v1

  2. kind: Deployment

  3. metadata:

  4.  name: readiness-example

  5. spec:

  6.  ...

  7.    spec:

  8.      containers:

  9.      - name: readiness-example

  10.        image: dbdock/readiness-example:1.0.0

  11.        ...

  12.        readinessProbe:

  13.          httpGet:

  14.            path: /health

  15.            port: 8080

  16.          initialDelaySeconds: 40

  17.          timeoutSeconds: 2

  18.          periodSeconds: 3

  19.          failureThreshold: 2

  20.        livenessProbe:

  21.          httpGet:

  22.            path: /health

  23.            port: 8080

  24.          initialDelaySeconds: 100

  25.          timeoutSeconds: 2

  26.          periodSeconds: 8

  27.          failureThreshold: 1


虽然很相似,但我们需要指出的探针配置有一些变化:


  • 由于我们知道我们的应用程序需要大约40秒才能准备好接收流量,因此我们将准备探测的initialDelaySeconds增加到40秒

  • 同样,我们将liveness probe的initialDelaySeconds增加到100秒,以避免被Kubernetes过早结束


如果在40秒后仍然没有完成,它大约还有60秒完成。之后,我们的活动探测器将启动并重新启动Pod。


结束语


在本文中,我们讨论了Kubernetes探针以及如何使用Spring的Actuator来改进应用程序的健康监控。

完整示例在Github。https://github.com/eugenp/tutorials/tree/master/spring-cloud/spring-cloud-kubernetes


原文链接:https://www.baeldung.com/spring-boot-kubernetes-self-healing-apps


推荐阅读:


  • 客户案例 | 某大型运营商微服务能力中台落地实践

  • 产品技术多方平衡,企业级容器 PaaS 如何满足用户的多样化需求?

  • 客户案例 | 某大型央企保险资产管理机构的数字化进阶之路


文章转载自公众号

SpringForAll社区 SpringForAll社区

    发送中

    本文标签:AutoTags插件服务端需要您提供购买者的账号和密码才能继续访问  折翼天使  莎莎源码  吾爱源码  其他源码 

    转载请注明来源:PHP手机端发卡多种支付商业版源码

    本文永久链接地址:https://www.suibianlu.com/11942.html

    郑重声明:
    本站所有内容均由互联网收集整理、网友上传,并且以计算机技术研究交流为目的,仅供大家参考、学习,不存在任何商业目的与商业用途。
    若您需要商业运营或用于其他商业活动,请您购买正版授权并合法使用。 我们不承担任何技术及版权问题,且不对任何资源负法律责任。
    如无法链接失效或侵犯版权,请给我们来信:admin@suibianlu.com

    栏目导航
    最新文章
    热门文章
    Top