我有一个包含5个微服务（iam，课程...）的应用程序。我想知道哪种是将它们迁移到kubernetes的最佳方法。我在考虑通过Google创建的环境创建名称空间： 1.产品 2.开发 3.分期
然后我认为最好通过环境和微服务创建名称空间。 1. iam-prod 2. iam-dev 3. IAM分期 1.课程 2.课程开发 3.课程分期 ... 但是这种方法可能很难处理。因为我需要互相交流。
您认为哪种方法更好？
答案 0 :(得分：2)
就像其他答案一样，您应该为prod, dev and staging创建名称空间隔离。这将确保照顾到一些细微差别...
答案 1 :(得分：1)
以上都不是理想的解决方案。我将讨论原因。
命名空间是用于管理RBAC权限的最简单边界。通常，您将需要使用预先设置的admin和editor集群角色来限制用户使用命名空间的访问权限。这意味着共享名称空间的人员和服务也共享秘密的可见性。因此，名称空间成为损害机密的爆炸半径。
为了减少秘密泄露的爆炸半径，您可以微管理资源级角色绑定（这不需要额外的自动化和工具，这是不合理的开销），也可以在名称空间之间隔离服务，以便只有紧密耦合的服务才能共享名称空间。
名称空间之间的Kubernetes资源隔离相对较差。没有其他方法，如果没有自定义接纳控制器，就无法强制将名称空间部署到另一个节点池中。因此，有效地选择资源隔离是不安全且不可执行的。
因此，实际上是更安全和更好的资源被隔离，以在单独的K8集群中具有不同的环境（开发，登台，生产）。但这显然更昂贵，并且管理开销更大。因此，只有当您拥有许多服务和足够的资源使用量来证明增加的开销时，它才具有成本效益。
资源隔离差的结果是，您的开发和暂存工作负载仅使用共享资源就可以有效地DOS生产产品工作负载。 CPU /内存/磁盘是明显的罪魁祸首。这些可以由自定义准入控制器强制执行。但是，更隐蔽的问题是共享入口代理，负载平衡器和网络，这很难在名称空间之间进行隔离。
隔离性差的另一个结果是，安全性较差的开发服务可能会受到损害，从而允许横向访问产品服务。实际上，没有人将开发应用部署为生产就绪且安全的部署。因此，如果没有严格隔离，您的安全性也会受到威胁。
配额在名称空间级别进行管理。因此，如果您想按环境和团队隔离配额，则不能同时使用名称空间。而且，如果您想按项目分配配额，则每个命名空间都需要一个项目。处理这三个问题的唯一方法是使用多个群集，多个名称空间和多个节点池，并对其实施自定义部署/许可实施，从而创建临时的层次结构或矩阵。
命名空间是平坦的。如果将它们用于环境，则不能将它们用于组织或团队级别的访问控制。如果将它们用于团队级别的访问控制，则工程师可以将它们用于组件/项目/系统级别的抽象边界。您只能选择一个，否则混乱将变得难以处理。
不幸的是，在Kubernetes社区中，名称空间抽象被用于3或4个用例，对于任何一个用例来说，这都不是理想的选择。因此，要么选择一个非理想的用例进行优化，要么管理多个集群并编写一堆自定义自动化来处理所有用例。
答案 2 :(得分：0)
您可以在同一名称空间上运行多个微服务。因此，我将使用prod，dev和staging命名空间，其中每个微服务可以具有一个或多个实例。
但是，如果您想为单独的微服务环境使用单独的名称空间，它们仍然可以使用service进行通信。 DNS URL将为SERVICE_NAME.NAMESPACE.SVC。
参考：https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
答案 3 :(得分：0)
如果采用第二种方法，则会造成不必要的复杂性，而不会带来任何好处。还要考虑一下如果您的微服务不断增长，您是否会为每个微服务创建新集群。完全不建议这样做。
命名空间的概念不应链接到应用程序，而应与用户相关。请参阅以下k8文档
“命名空间旨在用于用户分散的环境中 跨多个团队或项目。对于只有几到几十个用户的集群， 您完全不需要创建或考虑名称空间。需要名称空间提供的功能时，请开始使用它们。”
即使建议采用第一种方法，也请使用单独的群集进行生产，因为这样应该更安全并且具有较高的可用性，并且已准备好并测试了适当的灾难恢复计划。
答案 4 :(得分：0)
为每个环境使用一个名称空间。您还可以按名称进度定义资源配额。这样，每个应用程序环境都可以独立管理