我正在构建一个服务,用户可以在其中构建 Web 应用程序 - 这些应用程序将托管在虚拟 DNS 名称 *.laska.io 下
例如,如果 Tom 和 Jerry 都构建了一个应用程序,他们会将其托管在:
tom.laska.io
jerry.laska.io
现在,假设我有 1000 个用户。 我应该创建一个看起来像这样的大入口吗?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: tom.laska.io
http:
paths:
- backend:
serviceName: nginx-service
servicePort: 80
- host: jerry.laska.io
http:
paths:
- backend:
serviceName: nginx-service
servicePort: 80
...and so forth
我担心停机 - 例如,如果我有一个带有 websockets 的应用程序。此外,该文件将变得巨大,有 1000 个用户。重新加载入口会足够快吗?另外,我应该如何重新加载它?
我的第二个选择是只需为每个 Web 应用程序创建一个入口 .我担心的是,ingress-nginx 可以处理很多入口吗?或者这是一种反模式?
哪一个更好?
最佳答案
您可以为每个 Web 应用程序创建一个入口资源。如果您搜索官方公共(public)图表存储库,您会看到 many of the charts define an ingress resource within them .每个应用程序定义自己的入口资源是正常的。
值得一提的是,入口资源只是路由规则的定义。 (它不会添加额外的入口 Controller 或任何其他额外的运行时组件。)因此,应用程序定义自己的路由规则非常有意义。
您给出的示例在一个资源定义中包含所有入口路由。当您拥有多个相关应用程序时,这种方法很容易掌握并且很有意义,因为您可能希望一起查看它们的路由配置。您也可以在 fanout ingress example in the kubernetes docs 中看到这一点。 .
我看不出在不同资源中单独定义规则有任何性能问题。入口 Controller 将 listen for new rules并仅在创建新规则时更新其配置,因此读取资源不应该有问题。而且我希望组合选项与分离选项会导致在 nginx 的后台设置相同的路由规则。
官方图表存储库中最常见的模式是每个应用程序的图表定义其入口资源,并通过 values.yaml 公开它,以便用户可以根据需要选择启用或自定义它。然后,您可以将多个图表组合在一起,并在 values.yaml 的相关部分中为每个图表配置规则。 (这里是带有通配符 dns 的 example I've worked on that does this。)或者您可以在其自己的 Helm 版本下单独部署每个应用程序。
关于kubernetes - ingress-nginx - 每个主机创建一个入口?或者将许多主机合并到一个入口并重新加载?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52382658/