在带有 spring 云船长的 k8s 上附加版本作为 Service/Deployment 名称背后的理性

Rational behind appending versions as Service/Deployment name on k8s with spring cloud skipper

我是 spring 云数据流世界的新手,在使用该框架时,我发现如果我有一个流 = 'test-steram' 和 1 个名为 'app' 的应用程序.当我使用 skipper 部署到 kubernetes 时,我看到它在 kubernetes 上创建了 pod/deployment & 服务,名称为

test-stream-app-v1.

我的问题是为什么我们需要在 k8s 上的 service/deployment 名称中包含 v1?它在使用 spring 云数据流的整个工作流程中扮演什么角色?

------跟进----------

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

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

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

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

@阿南德。恭喜第一个post!

如果 Skipper 与 SCDF 一起使用,则命名约定遵循每个流应用程序都是 "versioned" 的想法。作为用户,当您按需或通过 CI/CD 自动化滚动升级和滚动降级流式应用程序版本或特定于应用程序的属性时,版本会发生变化。

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

由于所有历史版本都位于一个中心位置(即 Skipper 的数据库),您可以通过 SCDF 中的 stream history..stream manifest .. 命令与它们进行交互。

要了解更多信息,请观看此 demo-webinar (starts @ ~41.25), and also have a look at samples in the reference guide

希望对您有所帮助。