Question 97381 in Nginx Question posted in
The official documentation can be found here.

Nginx service of type LoadBalancer vs ingress (using nginx-ingress) vs ingress + nginx service of type ClusterIP

We are moving from standalone docker containers architecture to K3s architecture. The current architecture uses a Nginx container to expose multiple uwsgi and websocket services (for django) that are running in different containers. I’m reading conflicting opinions on the internet over what approach should be used.

The options are:

  1. Nginx service of type LoadBalancer (Most conf from existing architecture can be reused)
  2. Nginx-ingress (All conf from existing architecture will have to be converted to ingress annotations and ConfigMap)
  3. Nginx-ingress + nginx service of type ClusterIP (Most conf from existing architecture can be reused, traffic coming into ingress will simply be routed to nginx service)
Tags:

2

Answers


  1. 0

    In a very similar situation, we used option 3.

    It might be seen as sub-optimal in terms of network, but gave us a much smoother transition path. It also gives the time to see what could be handled by the Ingress afterwards.

    The support of your various nginx configurations would vary on the Ingress implementation, and would be specific to this Ingress implementation (a generic Ingress only handles HTTP routing based on host or path). So I would not advise option 2 except you’re already sure your Ingress can handle it (and you won’t want to switch to another Ingress)

    Regarding option 1 (LoadBalancer, or even NodePort), it would probably work too, but an Ingress is a much better fit when using http(s).

    Login or Signup to reply.
  2. 0

    My opinion about the 3 options is:

    1. You can maintain the existing config but you need to assign one IP from your network to each service that you want to expose. And in bare metals you need to use an adicional service like Metallb.
    2. Could be an option too, but it’s not flexible if you want to rollback your previous configuration, it’s like you are adapting your solution to Kubernetes architecture.
    3. I think that it’s the best option, you maintain your nginx+wsgi to talk with your Django apps, and use Nginx ingress to centralize the exposure of your services, apply SSL, domain names, etc.
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search