我正在构建一个用户可以构建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 应用创建一个入口资源。如果搜索官方公共图表存储库，则会看到许多图表在其中定义了入口资源。每个应用定义自己的入口资源是正常的。
值得明确的是，入口资源只是路由规则的定义。(它不会添加额外的入口控制器或任何其他额外的运行时组件。因此，应用定义自己的路由规则非常有意义。
您给出的示例将所有入口路由都包含在一个资源定义中。这种方法很容易掌握，并且当您有多个相关的应用程序时非常有意义，因为您可能希望同时查看它们的路由配置。您也可以在 kubernetes 文档的扇出入口示例中看到这一点。
我看不出在不同资源中单独定义规则有任何性能问题。入口控制器将侦听新规则，并仅在创建新规则时更新其配置，因此读取资源应该不会出现问题。我希望组合选项与分离选项会导致在 nginx 的后台设置相同的路由规则。
官方图表存储库中最常见的模式是，每个应用的图表定义其入口资源，并通过 values.yaml 公开它，以便用户可以根据需要选择启用或自定义它。然后，您可以将多个图表组合在一起，并在 values.yaml 的相关部分中为每个图表配置规则。(这是我使用通配符 dns 执行此操作的示例。或者，可以在其自己的 helm 版本下单独部署每个应用。
ingress资源只是一个规则。最好将ingress资源拆分到不同的文件中，然后重新应用需要更改的资源。 在应用资源时，我从未注意到停机时间。