假设我有一个有两个部署的应用程序：
- 应用程序部署，以及实际的应用程序本身
- Redis 部署，供应用程序部署用于缓存
Redis 缓存由名为“redis”的服务公开。应用程序使用服务主机名（“redis”）连接到 Redis 服务。
假设应用程序从版本 1 更新到版本 2。部署容器规范已更新，因此现在它基于容器app:2映像。
问题在于：在更新过程中，应用程序的两个版本使用相同的 Redis 服务。新应用程序在达到就绪状态时会预热缓存，这实际上会破坏仍在运行的版本 1 的缓存。
Kubernetes 是否有助于构建一种结构，使 Deployment 的新修订版本获得自己的 Redis 服务，该服务可以在达到就绪状态之前预热，并且不受当前修订版本的影响？当 Kubernetes 由于新修订版本达到就绪状态而终止当前修订版本时，它应该同时终止与该修订版本关联的 Redis 服务。
答案1
Kubernetes 是否有助于构建一个新版本的 Deployment，让其拥有自己的 Redis 服务
您是否考虑过将您的应用程序放在一个带有两个容器的 Pod 中运送，其中一个是您的 Redis？
在更新过程中，应用程序的两个版本使用相同的 Redis 服务
也许可以考虑将部署策略更改为重新创建，如果您可以承受暂时关闭服务，它将确保在启动下一个应用程序之前，应用程序的前一个副本已关闭。
如果我们想不惜一切代价避免中断服务，那么也许可以研究蓝绿部署：始终拥有应用程序的两个副本（redis + app），仅在一侧重新部署，然后重新配置入口以将客户端发送到新版本。