While the Ingress Controller is the "engine" (the software doing the work), the Ingress Resource is the "Configuration Map" or the "Rulebook".
Its primary purpose is to define how external traffic should reach the services inside your cluster. Here are the specific roles it plays:
1. Host-Based Routing (Virtual Hosting)
It allows you to use one single IP address to host multiple domain names.
- Traffic for
api.example.comgoes to the Backend Service A. - Traffic for
web.example.comgoes to the Backend Service B. - In your current lab, you are defining a rule for
test.local.
2. Path-Based Routing
It can route traffic based on the URL path.
example.com/images→ Image-Serviceexample.com/payment→ Payment-Service
3. Decoupling Configuration from Infrastructure
The Ingress Resource is a standard Kubernetes object. This means developers can define how their app should be accessed (via YAML) without needing to know the technical details of the underlying Load Balancer (like AWS ELB, Google Cloud Load Balancer, or Nginx).
4. Conserving Resources (and Money)
Instead of creating a "Service Type: LoadBalancer" for every single app (which usually creates a new, expensive cloud IP/Load Balancer for each), the Ingress Resource lets you share one single Load Balancer across many different apps.
Summary Comparison:
| Feature | Ingress Resource (YAML) | Ingress Controller (Pod) |
|---|---|---|
| What is it? | A set of rules (The Manifest). | The actual server (The Traffic Warden). |
| Purpose | To define where traffic goes. | To execute the routing of traffic. |
| Visual | The Spreadsheet/Instructions. | The Engine/Nginx server. |
In short: The Resource provides the Instructions, and the Controller follows them!