ingress-nginx - 每台主机创建一个入口?或者将许多主机合并到一个入口并重新加载? [英] ingress-nginx - create one ingress per host? Or combine many hosts into one ingress and reload?

问题描述

我正在构建一个服务，用户可以在其中构建网络应用程序 - 这些应用程序将托管在虚拟 DNS 名称 *.laska.io 下

I'm building a service where users can build web apps - these apps will be hosted under a virtual DNS name *.laska.io

例如，如果 Tom 和 Jerry 都开发了一个应用，他们会将其托管在:

For example, if Tom and Jerry both built an app, they'd have it hosted under:

tom.laska.io
jerry.laska.io

现在，假设我有 1000 个用户.我应该创建一个像这样的大入口吗?

Now, suppose I have 1000 users. Should I create one big ingress that looks like this?

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 个用户.重新加载入口是否足够快?另外，我应该如何重新加载它?

I'm worried about downtime - if I have an app with websockets for example. Also the file will become huge with 1000 users. Will reloading the ingress go fast enough? Also, how should I reload it?

我认为的第二个选择是简单地为每个网络应用创建一个入口.我担心的是，ingress-nginx 可以处理很多入口吗?或者这是一种反模式?

A second option in my mind is to simply create one ingress for every web app. My worry about that is, can ingress-nginx handle many ingresses? Or is this an anti-pattern?

哪个更好?

推荐答案

您可以为每个 Web 应用程序创建一个入口资源.如果您搜索官方公共图表存储库，您会看到 许多图表在其中定义了一个入口资源.每个应用定义自己的入口资源是正常的.

You can create one ingress resource for each web app. If you search the official public charts repo, you'll see that many of the charts define an ingress resource within them. It's normal for each app to define its own ingress resource.

值得明确的是，入口资源只是路由规则的定义.(它不会添加额外的入口控制器或任何其他额外的运行时组件.)因此，应用程序定义自己的路由规则很有意义.

It's worth being clear that an ingress resource is just a definition of a routing rule. (It doesn't add an extra ingress controller or any other extra runtime component.) So it makes a lot of sense for an app to define its own routing rule.

您给出的示例在一个资源定义中包含所有入口路由.当您有几个相关的应用程序时，这种方法很容易掌握并且很有意义，因为您可能希望一起查看它们的路由配置.您也可以在 kubernetes 文档中的扇出入口示例中看到这一点.

The example you've given has all the ingress routing in one resource definition. This approach is easy to grasp and makes a lot of sense when you've got several related applications as then you might want to see their routing configuration together. You can see this also in the fanout ingress example in the kubernetes docs.

我看不到在不同资源中单独定义规则的任何性能问题.入口控制器将监听新规则并仅在以下情况更新其配置创建了一个新规则，因此阅读资源应该没有问题.而且我希望组合和分离的选项会导致在 nginx 的后台设置相同的路由规则.

I can't see any performance concerns with defining the rules separately in distinct resources. The ingress controller will listen for new rules and update its configuration only when a new rule is created so there shouldn't be a problem with reading the resources. And I'd expect the combined vs separated options to result in the same routing rules being set in the background in nginx.

官方图表存储库中最常见的模式是每个应用程序的图表定义其入口资源，并通过 values.yaml 公开它，以便用户可以根据需要选择启用或自定义它.然后，您可以将多个图表组合在一起，并在 values.yaml 的相关部分中为每个图表配置规则.(这是一个 example 使用通配符 dns 做到这一点.)或者您可以在自己的掌舵版本下单独部署每个应用程序.

The most common pattern in the official charts repo is that the chart for each app defines its ingress resource and also exposes it through the values.yaml so that users can choose to enable or customise it as they wish. You can then compose multiple charts together and configure the rules for each in the relevant section of the values.yaml. (Here's an example I've worked on that does this with wildcard dns.) Or you can deploy each app separately under its own helm release.

这篇关于ingress-nginx - 每台主机创建一个入口?或者将许多主机合并到一个入口并重新加载?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！