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

问题描述

我正在构建一项服务，用户可以在其中构建Web应用程序-这些应用程序将以虚拟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.

在不同的资源中分别定义规则时，我看不到任何性能方面的问题.入口控制器将监听新规则，并仅在以下情况下更新其配置创建了新规则，因此读取资源应该没有问题.而且我希望组合的vs分开的选项会导致在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的相关部分中为每个图表配置规则. (下面是一个示例I (使用通配符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屋！