spring-cloud-dataflow - 使用spring cloud skipper在k8s上附加版本作为服务/部署名称背后的合理性
问题描述
我是春天云数据流世界的新人,在玩框架时,我发现如果我有一个流 = 'test-steram' 和 1 个名为'app' 的应用程序。当我使用船长部署到 kubernetes 时,我看到它在 kubernetes 上创建了 pod/deployment & service,名称为
测试流应用程序-v1。
我的问题是为什么我们需要在 k8s 上的服务/部署名称中使用 v1?它在使用spring cloud dataflow的整体工作流程中起到什么作用?
- - - 跟进 - - - - - -
只是想确认几点以确保我在正确的轨道上理解流程
我的理解是与传统的流(通过 kafka 主题绑定)服务(kubernetes 上的对象)没有发挥重要作用。
滚动更新(红/黑)模式在船长中以以下方式实现,部署/服务中的版本控制在以下方式中发挥作用。
假设 app-v1 部署已经存在并且请求升级。Skipper 创建 app-v2 部署并等待它准备好。一旦准备就绪,它就会破坏 app-v1
如果我的上述理解是正确的,我有以下后续问题......
我看到船长可以部署和打包(并且不必是传统的流)来使用。这是长期计划还是 Skipper 仅适用于 spring-cloud-dataflow 流?
在非传统流包的情况下,一个包在一个组中有多个应用程序(其余微服务),这种版本控制模型将如何工作?我的意思是当我想从其他微服务调用微服务时,我不可能知道或不太理想地知道应用程序的发布版本?
解决方案
@阿南德。恭喜第一个帖子!
命名约定的理念是,如果 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),并查看参考指南中的示例。
我希望这有帮助。
推荐阅读
- spring - 如何分配线程来处理请求?特别是如果请求大约每秒 10K
- javascript - 在 JavaScript 中,当 value 本身是一个对象时,如何记录对象的 {key:value} 对的值?可能有递归函数吗?
- angular - 分配的表达式类型“X”不能分配给类型“X”| “是”
- laravel - 如何使用下拉菜单从数据库下载 dynamci 文件
- objective-c - 在 NSArray 中按顺序运行 TTS
- firebase - 将 drupal 用户迁移到 Firebase 身份验证
- git - 是否可以使用事件阻止合并按钮?
- php - 是否可以在 mysql 表中按日期(时间戳)为每个组选择 10 行?如何进行?
- python - Calculating Quantiles based on a column value?
- asp.net-mvc - 切换到 {controller}/{id}/{action} 会中断 Redirec