Kubernetes 部署模式和 REST API 版本答案

【问题标题】：Kubernetes deployment patterns & REST API versionsKubernetes 部署模式和 REST API 版本
【发布时间】：2020-01-18 22:13:33
【问题描述】：

我有一个带有多个 API 版本的 REST API。每个 API 后端由多个微服务组成。可以公平地假设只有最新的 REST API 资源/代码的流失率最高。由于功能向后移植（很少）或错误修复（大部分），旧版本会出现流失。我想获得关于哪种 DevOps 模式最适合这种情况的建议 - 假设我们正在使用 Kubernetes 对我们的服务网格进行建模。

请注意，我们的 API 大多是异步的，因此可以在同一个代码库中支持多个 API 版本（打包在一个容器中）。

鉴于以上情况，这些配置都是可能的

每个 API 版本的服务 yaml。
具有多个 pod 模板（每个 API 版本一个）的单一服务 yaml。
Functional Service yamls - 一个用于前端和其他每个微服务（用于消息代理、处理工作人员等的 POD）。

需要思考的其他要点：

是否建议将部署部署到单独的集群或同一集群（对于 API 版本）。如果是，这是否会影响特定 API 版本的更新？

我正在根据您之前的经验寻找任何规定的模式或建议。

【问题讨论】：

标签： rest kubernetes devops

【解决方案1】：

一般来说，Deployment 管理 Pod 的副本，每个 Pod 运行一个特定的容器镜像。如果您的 API 后端由多个微服务组成，那么每个微服务都是一个部署。处理 API 请求的微服务通过（面向客户端的）服务公开。

对于多个 API 版本，您可以为每个版本复制此内容，您可以在服务前面放置一个入口，根据请求的 API 版本将流量路由到其中一个。

如果将所有 API 版本放在同一个容器中，可能会出现更新时状态不一致的问题： 1）在一个 Deployment 内部，短时间内两个 Pod 版本并排存在（如果使用默认滚动更新）; 2) 在短时间内，您可能已经更新和尚未更新的微服务彼此相邻。

【讨论】：

如果我理解这一点，您的建议是将每个微服务作为一个单独的部署（以便它们可以独立地使用副本进行扩展）和一组服务，用于处理客户端的微服务的每个 API 版本入口网关前面的请求。这是有道理的。如果有多容器PODS会不会有问题？我希望我们的大多数部署和服务至少包含一个 FluentD/Logging sidecar。
是的，没错。请注意，不处理客户端请求的微服务也需要一个服务（类型为 ClusterIP），以便其他微服务可以访问它们。 Pod 中的 sidecar 容器没有问题。它只是 Pod 的一部分，Pod 是一个单元。