Docker 如何在kubernetes中归档微服务应用程序的多个独立实例？

我们开发了一个应用程序，它由几个go/java服务、一个mongoDB和一个反向代理组成，后者将REST调用转发给特定的服务。每个服务都在自己的docker容器中运行。 整个应用程序可以通过一个docker compose文件进行部署

我们成功地在kubernetes集群中部署了该应用程序

现在是“棘手”部分：我们希望为每个客户部署一个独立的应用程序实例。（请记住，一个实例包含大约10个容器）

在过去，我们通过部署docker compose文件的多个实例来实现这一目标

在库伯内特斯，达到这一目标的推荐方法是什么

---

非常感谢。

在kuberenetes中，您可以将所有资源打包到

掌舵图中

（），以便部署每个资源的不同实例并管理其生命周期。如果需要，还可以为每个实例传递参数

---

另一种方法是使用

kubernetes操作符部署应用程序实例。这也有助于管理应用程序组件。
应用程序可以通过简单的命名和标签或名称空间进行分离。分离可以进一步限制实例可能运行的节点，甚至可以限制运行单独集群的节点

可以在部署的基础上应用网络策略，以改进网络隔离。这需要模拟docker compose“每个实例的网桥”设置

“孤立”可能意味着很多事情，因为这个词可以以各种方式应用

命名
只要每个kubernetes资源的命名不冲突，部署的许多实例可以在集群上混合运行。这包括应用的标签（有时还有注释），用于选择或报告应用程序，以便您可以唯一地标识客户资源

kubectl create -f deployment-customer1.yaml
kubectl create -f deployment-customer2.yaml

这种类型的命名更易于使用部署机制进行管理，如。Helm描述了一个发行版，并且是使用变量“release name”的基本概念构建的，因此yaml模板可以依赖它。平均舵释放量为：

helm install -f customer1-values.yaml customer1-app me/my-app-chart
helm install -f customer2-values.yaml customer2-app me/my-app-chart

名称空间
是群集中资源的逻辑分组。名称空间本身只提供命名隔离，但许多其他k8s资源可以依赖于名称空间应用于：


到k8s



每个客户/实例的名称空间可能很有用，例如，如果您有一个“高级”客户可以获得更大的资源配额。它还可以使标记和选择实例更容易，这是网络策略将使用的

环境可能非常适合命名空间，因此类似的部署可以转到dev/test/prod ns。如果您允许用户自己管理或查询Kubernetes资源，那么名称空间将使管理更加容易

管理名称空间资源可能如下所示：

kubectl create ns customer1
kubectl create -f deployment.yaml -n customer1
kubectl create ns customer2
kubectl create -f deployment.yaml -n customer2

同样，
helm
同样适用于命名空间部署

DNS可能也值得一提，默认情况下，容器将在自己的名称空间中查找主机名。在命名空间
customer1
中，查找主机名
service name
将解析为
service name.customer1.svc.cluster.local

类似地，在命名空间
customer2
中：
服务名称的查找是
服务名称.customer2.svc.cluster.local

节点
客户可以固定到特定节点（VM或物理节点），以提供与其他客户的安全性和/或资源隔离

簇
集群分离可以提供完全的安全性、资源和网络隔离，而无需依赖kubernetes进行管理

大型应用程序通常会在每个“分组”中使用一个完整的集群。这会给每个集群带来巨大的管理开销，但允许实例之间更接近完全独立。安全性可能是一个很大的驱动因素，因为您可以在Kubernetes masters之外的集群之间提供一层隔离

网络策略
A允许您通过标签选择器限制POD/服务之间的网络访问。Kubernetes将在集群中计划POD的任何位置主动管理防火墙规则。这将需要提供类似于docker compose的网络隔离，以便为每个实例创建网络

群集将需要使用支持网络策略的（CNI），如。
如何“隔离”？k8s中有很多安全问题，因此如果您担心安全问题，可以将其提升到第n级