当前位置: 首页 > 知识库问答 >
问题:

如何重新启动kubernetes服务的多个spring boot应用程序实例

宗政坚白
2023-03-14

我有一个负载平衡的Spring boot service A部署,比如在3节点kubernetes集群上。

我还需要启用快速配置管理,而无需重新构建和部署完整的重新绑定映像。

为此,我构建了一个Spring Boot配置服务器,并在服务a上实现了执行器重启,当在本地单实例部署上调用其/重启endpoint时,它会刷新并加载从配置服务器获取的属性。

到目前为止还不错,但是...

当服务A部署在具有3个、30个或300个服务A实例的更大规模k8s部署上时,如何实现上述目标?

调用/刷新endpoint必须像集群上的任何其他REST调用一样由负载平衡器处理,这意味着它被路由到其中一个服务实例。

在springboot-on-k8s中有没有一种标准的方法可以忽略LB调用每个服务实例

共有2个答案

莫英卓
2023-03-14

我不知道这样做的标准模式。

与服务选择器匹配的每个应用程序pod都将注册为该服务的endpoint。如果运行kubectl get endpoints,您应该会看到支持服务的pod的所有内部集群。

可以创建一些逻辑来为每个服务终结点调用 /refresh终结点。

诸福
2023-03-14

我们并没有真正使用执行器的重新启动,相反,我们所做的是利用RollingUpdate部署策略。当我们想要“重新启动”pod时,我们会发布kubectl补丁。

kubectl patch deployment web -p  "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

升级策略的良好文档。

https://www.google.com/url?sa=t

 类似资料:
  • 问题内容: 我在3节点kubernetes集群上进行了Spring Boot服务A的负载均衡部署。 我还要求启用快速配置管理,而无需重建和部署完整的重新烘焙映像。 为此,我组合了一个Spring Boot配置服务器,并在服务A上实现了Actuator重新启动,当在本地单实例部署中调用其/ restart端点时,它会刷新并加载从配置服务器获取的属性。 到目前为止一切顺利,但是… 当将服务A部署在具有

  • 下面是在没有fxml的情况下重新启动JavaFX应用程序的代码。 但是,我想用fxml实现这一点。 我不知道如何使用fxml应用此代码。 我的代码。 Main.java 控制器。JAVA 样品fxml 我想重新启动我的JavaFX应用程序。 我不知道如何使用fxml应用此代码。 如何使用fxml重新启动JavaFX应用程序?

  • 问题内容: 如何重新启动Java AWT应用程序?我有一个附加了事件处理程序的按钮。我应该使用什么代码来重新启动应用程序? 我想做与应用程序中相同的事情。 问题答案: 当然,可以重新启动Java应用程序。 以下方法显示了一种重新启动Java应用程序的方法: 基本上,它执行以下操作: 查找Java可执行文件(我在这里使用了Java二进制文件,但这取决于您的要求) 查找应用程序(在我的情况下是一个ja

  • 为了效率和成本,我不想将这些标志存储在memcache或Datastore中。 我正在寻找一种向所有实例发送消息的方法(请参阅我之前的文章GAE向所有活动实例发送请求): 1)向我的应用程序或服务的所有实例发送关闭消息/命令 2)向我的应用程序或服务的所有实例发送重新启动消息/命令 我只使用自动缩放,所以我不能发送针对特定实例的请求(我可以使用GAE管理API获得活动实例的列表)。 有没有办法在P

  • 我创建了一个运行docker容器的Azure应用服务。 但是容器似乎一直在重新启动:2020-01-09 07:21:56.543INFO-用于站点xxx的容器xxx初始化成功,并准备好服务请求。2020-01-09 07:22:01.559错误-用于站点xxx的容器不健康,停止站点。2020-01-09 07:22:01.559INFO-停止站点xxx,因为它是不健康的。 由于它是一个资源密集型

  • 问题内容: 我愿意在应用程序中添加一个按钮,单击该按钮将重新启动该应用程序。我搜索谷歌,但没有发现任何有用的,除了这一个。但是,此处遵循的过程违反了Java的WORA概念。 是否有其他以Java为中心的方法来实现此功能?是否可以只派生另一个副本然后退出? 提前致谢。我感谢您的帮助。 @deporter我已经尝试过您的解决方案,但是它不起作用:( @mKorbel我写的,采取的概念下面的代码,你曾在