我正在构建一个用户可以构建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应用程序创建一个入口资源。如果你搜索官方的公共图表回购,你会看到many of the charts define an ingress resource within them。每个应用程序定义自己的入口资源是正常的。
值得注意的是,入口资源只是路由规则的定义。 (它不会添加额外的入口控制器或任何其他额外的运行时组件。)因此,应用程序定义自己的路由规则很有意义。
您给出的示例在一个资源定义中具有所有入口路由。这种方法很容易掌握,当你有几个相关的应用程序时很有意义,因为你可能希望将它们的路由配置放在一起。你也可以在fanout ingress example in the kubernetes docs看到这个。
在不同的资源中分别定义规则时,我看不出任何性能问题。入口控制器将listen for new rules并仅在创建新规则时更新其配置,因此读取资源应该没有问题。并且我希望组合vs分离的选项导致在nginx的后台设置相同的路由规则。
官方图表仓库中最常见的模式是每个应用程序的图表定义其入口资源,并通过values.yaml公开它,以便用户可以选择根据需要启用或自定义它。然后,您可以将多个图表组合在一起,并在values.yaml的相关部分中为每个图表配置规则。 (这是带有通配符dns的example I've worked on that does this。)或者您可以在自己的helm版本下单独部署每个应用程序。
一个ingress
资源只是一个规则。最好将ingress
资源分成不同的文件,然后重新应用需要更改的资源。我在应用资源时从未注意到停机时间。