Kubernetes 子域供应

Question

我正在开发一个将在 Kubernetes 中运行的 SaaS 应用程序。我们使用 Helm 图表将所有组件部署到集群中(为简单起见，我们假设它是前端服务、后端和数据库)。应用程序架构是 Multi-Tenancy 的(我们有一个由所有租户共享的每个服务的单个实例)我们希望保持这种状态 .我目前正在努力解决的问题并想寻求建议/最佳实践是如何为租户自动配置自定义子域？

想象一下，该应用程序托管在 exampleapp.com .
一个全新的客户来注册一个新的组织some-company .此时，除了在系统中创建新租户外，我还想配置一个新的子域 some-company.exampleapp.com .我希望这种配置能够自动完成，不需要任何手动干预。

在 Kubernetes 中实现自动子域配置有哪些选择？

我们的 ( exampleapp.com ) 域注册商/域名服务器提供商如何适应该解决方案？
它是否必须为动态 DNS 记录创建/修改提供 API？

我很欣赏我问的问题非常广泛，所以我不期待任何比高级概念答案或一些可能帮助我实现这一目标的服务/库/工具的指针。

Answer 1

注:由于这更像是一个理论问题，我会从 Kubernetes 工程师那里给你一些观点，我将你的问题分成 block 以方便理解。

关于您的 Multi-Tenancy 架构:
保持“那样”是可以实现的。它简化了 Kubernetes 结构，另一方面它更多地依赖于您的应用程序。

问题一:

Imagine the app is hosted at exampleapp.com. A brand new customer comes and registers a new organisation some-company. At that moment, in addition to creating new tenant in the system, I would also like to provision a new subdomain some-company.exampleapp.com. I would like this provisioning to be done automatically and not require any manual intervention.

建议:

为此，您必须授予您的应用管理员权限以及在添加新客户端时将 Ingress 规则条目添加到您的 Ingress 所需的工具。使用 kubectl patch 的脚本从我的角度来看，这是更简单的解决方案。

对于这种方法，我建议安装 Nginx Ingress Controller因为它的多功能性。

这是一个示例:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
spec:
  rules:
  - host: client1.exampleapp.com
    http:
      paths:
      - path: /client1
        backend:
          serviceName: <main-service>
          servicePort: <main-service-port>

  - host: client2.exampleapp.com
    http:
      paths:
      - path: /client2
        backend:
          serviceName: <main-service>
          servicePort: <main-service-port>

这是使用 kubectl patch 的单行命令关于如何添加新规则:

kubectl patch ingress demo-ingress --type "json" -p '[{"op":"add","path":"/spec/rules/-","value":{"host":"client3.exampleapp.com","http":{"paths":[{"path":"/client3","backend":{"serviceName":"main-service","servicePort":80}}]}}}]'

POC:

$ kubectl get ingress
NAME           HOSTS                                           ADDRESS         PORTS   AGE
demo-ingress   client1.exampleapp.com,client2.exampleapp.com   192.168.39.39   80      15m

$ kubectl patch ingress demo-ingress --type "json" -p '[{"op":"add","path":"/spec/rules/-","value":{"host":"client3.exampleapp.com","http":{"paths":[{"path":"/client3","backend":{"serviceName":"main-service","servicePort":80}}]}}}]'
ingress.extensions/demo-ingress patched

$ kubectl describe ingress demo-ingress
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  client1.exampleapp.com  
                          /client1   main-service:80 (<none>)
  client2.exampleapp.com  
                          /client2   main-service:80 (<none>)
  client3.exampleapp.com  
                          /client3   main-service:80 (<none>)

此规则将从子域传入的流量重定向到主应用程序内的子路径。

此外，要添加 TLS 处理，请参阅:Nginx Ingress TLS Guide

问题2:

How does our (exampleapp.com) domain registrar/nameserver provider fit into the solution? Does it have to provide an API for dynamic DNS record creation/modification?

建议:

我相信您已经有了类似的东西，但是您需要在 DNS 中使用通配符记录来指向 *.example.app到入口的IP，我不相信你需要更多的东西，因为它将所有重定向到入口，入口在内部转发它。

问题3:

If there are some strong arguments why multi-tenancy + Kubernetes don't go along very well, those are welcome as well.

意见:

我看不出它会成为问题的任何主要原因。您只需再次让您的应用程序能够处理扩展，因为我相信从长远来看，您希望您的应用程序能够扩展到多 pod 结构以提供弹性可用性。

这些是我对您的问题的 2 美分，希望对您有所帮助!