Why I should use Ingress instead of simple reverse proxy?

General Discussions
,
1

Kubernetes version: 1.27 (on Bare Metal)

I’m migrating our small infrastructure from the “docker compose” approach to K8s. I launched the Cluster and deployed Pods with Services. And now it’s time to make proxy things from the public network to my K8s cluster.

Previously, I did it on a central Nginx server using quite simple proxy rules. It worked fine. And the first idea was to deploy such a reverse proxy to the K8s cluster as a separate Service, shared with the public network by NodePort Service type. I think I would be able to direct all requests to this “Nginx Service” and do all request management across my services in clusters inside internal nginx. All my internal services will be accessible from the newly created Nginx Service via internal DNS names. I would manage all requests using Nginx’s standard configuration files.

But according to official documentation, the Ingress (with Ingress Controller) is the common way to do those things.
I can’t figure out why I should implement Ingress instead of simple Nginx deployed as a standalone Service on the K8s cluster? It is posiible to implement Ingress in simple Nginx Service (standard nginx docker image with custom config files), deployed inside Cluster?

2

Well, I’ve dug deeper into the Ingress Controller zone and realized that under the hood, it is exactly the same as a simple Nginx server. The core of the Ingress Controller consists of a containerized Nginx server. But instead of direct installation and management, I can do those things via “k8s-style” manifests. And more, it has some additional options and features for living in a K8s cluster. And I suppose that I could do all request management via traditional nginx with standard nginx`s config files. But I think it is a good idea to choose the Ingress Nginx controller instead of plain Nginx to follow Kubernetes’s declaration manner principles.
There are two popular Ingress controllers based on Nginx:

  1. Ingress Nginx Controller
  2. NGINX Ingress Controller

And I chose the first one to start with.