首页 > 解决方案 > 使用spring cloud skipper在k8s上附加版本作为服务/部署名称背后的合理性

问题描述

我是春天云数据流世界的新人,在玩框架时,我发现如果我有一个流 = 'test-steram' 和 1 个名为'app' 的应用程序。当我使用船长部署到 kubernetes 时,我看到它在 kubernetes 上创建了 pod/deployment & service,名称为

测试流应用程序-v1。

我的问题是为什么我们需要在 k8s 上的服务/部署名称中使用 v1?它在使用spring cloud dataflow的整体工作流程中起到什么作用?

- - - 跟进 - - - - - -

只是想确认几点以确保我在正确的轨道上理解流程

如果我的上述理解是正确的,我有以下后续问题......

  1. 我看到船长可以部署和打包(并且不必是传统的流)来使用。这是长期计划还是 Skipper 仅适用于 spring-cloud-dataflow 流?

  2. 在非传统流包的情况下,一个包在一个组中有多个应用程序(其余微服务),这种版本控制模型将如何工作?我的意思是当我想从其他微服务调用微服务时,我不可能知道或不太理想地知道应用程序的发布版本?

标签: spring-cloud-dataflowspring-cloud-skipper

解决方案


@阿南德。恭喜第一个帖子!

命名约定的理念是,如果 Skipper 与 SCDF 一起使用,则每个流应用程序都是“版本化的”。作为用户,当您按需或通过 CI/CD 自动化滚动升级和滚动降级流应用程序版本或特定于应用程序的属性时,版本会受到影响。

它与持续交付和持续部署工作流非常相关,我们通过 和 等命令分别在 SCDF 中提供本机stream update ..选项stream rollback ..。对于这些操作中的任何一个,应用程序都将在 K8s 中滚动更新,并且每个操作都会增加应用程序名称中的数字。在您的示例中,您会将它们视为test-stream-app-v1`test-stream-app-v2 等。

将所有历史版本放在一个中心位置(即,Skipper 的数据库),您将能够通过SCDF 中的命令stream history..和它们进行交互。stream manifest ..

要了解有关这一切的更多信息,请观看此演示网络研讨会(开始 @ ~41.25),并查看参考指南中的示例。

我希望这有帮助。


推荐阅读