Spring boot 如何正确配置Kubernetes探针计时（用于Spring引导应用程序）

我们有一个简单的SpringBootWeb应用程序，启动不到30秒。因此，我将探测器配置为如下所示：

    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 1
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 1

据我所知，readiness probe会等待30秒，然后会成功（如果应用程序启动）。另外，具有30秒延迟的liveness probe（从部署开始）启动并将在准备就绪probe成功的同时成功（如果应用程序准备就绪）。但我在日志中看到的是准备就绪探测等待30秒，然后成功，但之后还有30秒的等待时间，然后旧pod关闭：

develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:07.378Z","logger":"org.springframework.boot.web.embedded.tomcat.TomcatWebServer","level":"INFO","thread":"main","message":"Tomcat started on port(s): 8080 (http) with context path ''"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:07.387Z","logger":"org.springframework.data.repository.config.DeferredRepositoryInitializationListener","level":"INFO","thread":"main","message":"Triggering deferred initialization of Spring Data repositories…"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:09.441Z","logger":"org.springframework.data.repository.config.DeferredRepositoryInitializationListener","level":"INFO","thread":"main","message":"Spring Data repositories initialized!"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:09.469Z","logger":"com.example.Application","level":"INFO","thread":"main","message":"Started Application in 23.918 seconds (JVM running for 25.343)"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:14.251Z","logger":"org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/]","level":"INFO","thread":"http-nio-8080-exec-1","message":"Initializing Spring DispatcherServlet 'dispatcherServlet'"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:14.258Z","logger":"org.springframework.web.servlet.DispatcherServlet","level":"INFO","thread":"http-nio-8080-exec-1","message":"Initializing Servlet 'dispatcherServlet'"}
develop/demo-57c8984866-6v5sl[demo]: {"ts":"2020-10-08T17:33:14.292Z","logger":"org.springframework.web.servlet.DispatcherServlet","level":"INFO","thread":"http-nio-8080-exec-1","message":"Completed initialization in 30 ms"}
develop/demo-79cc9bc757-xlg6z[demo]: 2020-10-08T17:33:44.590172 Shutting down...
develop/demo-79cc9bc757-xlg6z[demo]: {"ts":"2020-10-08T17:33:44.658Z","logger":"org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean","level":"INFO","thread":"SpringContextShutdownHook","message":"Closing JPA EntityManagerFactory for persistence unit 'default'"}
develop/demo-79cc9bc757-xlg6z[demo]: {"ts":"2020-10-08T17:33:44.664Z","logger":"org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor","level":"INFO","thread":"SpringContextShutdownHook","message":"Shutting down ExecutorService 'applicationTaskExecutor'"}
develop/demo-79cc9bc757-xlg6z[demo]: {"ts":"2020-10-08T17:33:44.667Z","logger":"com.zaxxer.hikari.HikariDataSource","level":"INFO","thread":"SpringContextShutdownHook","message":"HikariPool-1 - Shutdown initiated..."}
develop/demo-79cc9bc757-xlg6z[demo]: {"ts":"2020-10-08T17:33:44.680Z","logger":"com.zaxxer.hikari.HikariDataSource","level":"INFO","thread":"SpringContextShutdownHook","message":"HikariPool-1 - Shutdown completed."}

第二个30秒等待时间的原因是什么（请参阅第一个“关机…”）？作为记录，没有SIGTERM问题（应用程序正确响应SIGTERM）

更多信息
如果我对这些探针的工作方式有错误，请纠正我：容器启动，此时准备就绪初始延迟计时器也启动。25秒后，应用程序准备就绪。5秒后，就绪探测开始命中应用程序/容器并成功，因此应用程序已就绪（对吗？）。在这一点上，我希望K8将sigterm发送到旧pod，要求其关闭。但如日志所示，在新容器准备就绪后，旧的pod仍在运行30秒。
也许，重新表述这个问题会有所帮助。我想在应用程序准备好后立即关闭旧pod。应用程序在30秒内就准备好了。换句话说，我需要整个部署只需要30秒（考虑到启动时间不到30秒，关闭时间不到一秒）。为什么上面的配置不能做到这一点？

---

谢谢。

根据你的描述，你做的一切都很好

我们观察到，与第一次记录启动信息的pod不同，另一个pod正在关闭。 如果没有更多的信息，这看起来像是一个滚动更新，等待关闭旧的播客，直到新的播客可用并正常运行

---

您可以通过查看日志消息来判断：pod名称在每行的前面。

根据您的描述，您做的一切都很好

我们观察到，与第一次记录启动信息的pod不同，另一个pod正在关闭。 如果没有更多的信息，这看起来像是一个滚动更新，等待关闭旧的播客，直到新的播客可用并正常运行

---

您可以通过查看日志消息来判断：pod名称在每一行的前面。

好的，我们用来管理k8s清单的工具（）和库对

minReadySeconds

属性（30秒）有不同的默认值。我改变了这一点，一切正常。

好的，我们用来管理k8s清单的工具（）和库对

minReadySeconds

属性（30秒）有不同的默认值。我改变了这一点，一切都按预期进行。

我不确定是否理解你的观点。吊舱的名字很清楚。但问题是为什么K8S需要30秒才能发送sigterm（第一个关闭日志）。同样，应用程序完全响应信号，几乎立即关闭。顺便说一句，只有一个吊舱。我还需要分享其他信息吗？这取决于第一个pod接收sigterm的原因。你是怎么触发的？好吧，让我澄清一下。我有

xlg6z

pod，它工作得很好。我启动部署（使用上述配置）创建新pod（

6v5sl

），准备就绪探测等待30秒，然后探测并成功。现在是时候杀死

xlg6z

pod了。但它发生在30秒之后。这意味着新pod准备就绪30秒后，

xlg6z

pod接收到sigterm。如果现在天气晴朗，请告诉我。谢谢。回答你的问题，我不会触发任何事情。我只是更新部署（部署应用程序的新版本）。我认为sigterm（或任何信号）是由k8s发送的。您有一个pod“a”正在运行并开始新的部署。k8s总是有足够的副本准备就绪，从而防止应用程序停机。pod“b”已创建，但尚未准备就绪，因此“a”仍在运行。30秒后，“b”的准备就绪探测器启动，确定“b”舱已准备好为请求服务，并停止“a”。我不确定是否理解您的观点。吊舱的名字很清楚。但问题是为什么K8S需要30秒才能发送sigterm（第一个关闭日志）。同样，应用程序完全响应信号，几乎立即关闭。顺便说一句，只有一个吊舱。我还需要分享其他信息吗？这取决于第一个pod接收sigterm的原因。你是怎么触发的？好吧，让我澄清一下。我有

xlg6z

pod，它工作得很好。我启动部署（使用上述配置）创建新pod（

6v5sl

），准备就绪探测等待30秒，然后探测并成功。现在是时候杀死

xlg6z

pod了。但它发生在30秒之后。这意味着新pod准备就绪30秒后，

xlg6z

pod接收到sigterm。如果现在天气晴朗，请告诉我。谢谢。回答你的问题，我不会触发任何事情。我只是更新部署（部署应用程序的新版本）。我认为sigterm（或任何信号）是由k8s发送的。您有一个pod“a”正在运行并开始新的部署。k8s总是有足够的副本准备就绪，从而防止应用程序停机。pod“b”已创建，但尚未准备就绪，因此“a”仍在运行。30秒后，“b”的准备就绪探测器启动，确定吊舱“b”准备好服务请求，并停止“a”。