将Docker化的Spring Cloud Netflix项目部署到Kubernetes

Question

我正在研究微服务项目，该项目是dockerized的Spring Cloud Netflix项目，除3个微服务之外，其中包括涡轮，zipkin，发现，configserver等，它包含3个微服务。

（它现在仅在本地工作。）

很快，我决定使用业务流程管理工具将项目部署到云提供商。

经过研究，我决定使用Kuberenetes。

但是，Spring Cloud Netflix和Kubernetes都为分布式系统提供了一些解决方案：服务发现，负载平衡，容错等。

在这种情况下，请使用Netflix库。 Kubernetes似乎不必要。

我读了this和this。我认为Spring Cloud Kubernetes看起来是一种解决方法。

所以我的问题是：

1. 让我们假设将启动一个新的dockerized微服务项目，我们决定使用Kubernetes进行编排。我们可以说Netflix-OSS绝对不必要吗？
2. 让我们假设我们在同一个项目上工作了一段时间，并且使用了Netflix-OSS，但是我们想使用Kubernetes。在那种情况下，如果那两种选择的工作量没有太大差异，那么哪个是更好的解决方案：
   1. 使用Spring Cloud Kubernetes
   2. 删除所有Netflix库。来自微服务，并尝试转换纯Kubernetes解决方案。

Answer 1

我认为您提到的Christian Posta文章非常好。正如他所说，您可以使用开箱即用的Kubernetes解决方案（kub dns），负载平衡（使用Services）和边缘服务/网关（Ingress）来处理最常见的用例。

正如Christian指出的那样，如果您需要通过主动查询来动态发现服务，而不是知道自己在寻找什么，那么Spring Cloud Kubernetes可能比直接去Kubernetes Apis更好。如果您需要从配置更改中刷新您的应用程序并看到它快速更新而无需进行滚动更新（如果您将configmap批量安装，则需要滚动更新），那么Spring cloud Kubernetes配置客户端可能很有价值。如果需要客户端负载平衡，则功能区集成也可能很有价值。因此，您可以在没有Spring Cloud Kubernetes的情况下开始，并在有帮助时添加其中的一部分。我认为最好将项目视为增加额外的选项和便利，而不是使用Kubernetes原生解决方案的替代方案。

还值得注意的是，您可以将Netflix Stack应用程序部署到Kubernetes（包括使用Zuul和eureka），但这并不一定有什么问题。它的优点是您可以在Kubernetes之外使用它，并且如果您的特定团队是Java团队，那么对于您的特定团队来说可能更方便。主要缺点是Netflix堆栈与Java紧密相连，而Kubernetes与语言无关。