What Is Ingress Controller in Networking?
Also known as: Ingress Controller, Kubernetes Ingress Controller, CKA exam networking, Ingress vs Ingress Controller, NGINX Ingress Controller
On This Page
Quick Definition
An Ingress Controller is like a smart traffic cop for a Kubernetes cluster. It reads configuration rules called Ingress resources and then directs incoming web traffic to the correct services inside the cluster. This allows you to expose multiple applications using a single external IP address and manage routing, SSL, and load balancing without complex networking setups.
Must Know for Exams
The Ingress Controller is a key concept in the CNCF Kubernetes Administrator (CKA) exam and appears in the Networking section under the topic of Services and Networking. According to the official CKA curriculum, candidates must be able to demonstrate an understanding of how to configure and manage Ingress resources and Ingress Controllers. The exam tests your ability to deploy an Ingress Controller, create Ingress resources, and validate that traffic is routed correctly.
You may be asked to expose a web application using host-based routing where two different domains point to two different services. For example, you might need to create an Ingress so that app1.example.
com goes to the frontend service and app2.example.com goes to the backend service. The exam also tests TLS configuration, where you need to create a Secret containing a certificate and reference it in the Ingress resource.
You should know how to use annotations to customize the Ingress Controller behaviour, such as rewriting paths or setting timeout limits. Another important objective is understanding the difference between Ingress and Ingress Controller. The exam may present a scenario where a candidate creates an Ingress resource but traffic does not reach the service.
The solution is that no Ingress Controller is running. This is a common troubleshooting scenario. The CKA exam expects you to know how to install the NGINX Ingress Controller from the official Kubernetes documentation or using a Helm chart.
You should be aware that the Ingress Controller itself must be exposed via a Service of type LoadBalancer or NodePort. If the cluster is on-premises or a local environment like minikube, you might need to use NodePort or port forwarding. The exam also tests your knowledge of networking in the context of Ingress, including how DNS resolution works and how the controller interacts with the Kubernetes API.
While the CKA is the primary exam, the Certified Kubernetes Security Specialist (CKS) exam also covers Ingress Controller security, such as enforcing network policies and TLS hardening. The Certified Kubernetes Application Developer (CKAD) exam does not focus on Ingress Controllers, but application developers should understand how their applications are exposed. Being able to answer multiple-choice questions about Ingress resource fields like spec.
rules.host, spec.tls, and spec.rules.http.paths is essential.
Simple Meaning
Imagine you live in a large apartment building with many different offices on each floor. The building has only one main entrance door. Visitors arriving at the building need to know exactly which office to visit and how to get there.
An Ingress Controller is like a concierge desk placed right inside that main entrance. When a visitor arrives and says, I need to go to the accounting office on the third floor, the concierge checks a directory and gives clear directions. The directory is the Ingress resource, which contains the rules about which visitor goes to which office.
The concierge is the Ingress Controller that reads those rules and makes the routing happen. Without the Ingress Controller, you would need a separate entrance door for every single office, which is costly and messy. In Kubernetes, your applications run in pods inside the cluster.
The Ingress resource defines rules based on hostnames like app.example.com or URL paths like /api. The Ingress Controller is the actual software that implements these rules. It watches for changes to Ingress resources and configures a reverse proxy (like Nginx, HAProxy, or Traefik) to route traffic correctly.
This simplifies the networking layer because you only need one entry point into your cluster for HTTP and HTTPS traffic. The Ingress Controller also handles advanced features such as SSL termination, name-based virtual hosting, and path-based routing. By centralizing these tasks, it reduces the complexity of managing multiple load balancers and service exposures.
Full Technical Definition
In Kubernetes, an Ingress Controller is a daemon that runs as a pod (or set of pods) and implements the actual traffic routing defined by Ingress resources. An Ingress resource is a Kubernetes API object that specifies rules for inbound HTTP and HTTPS traffic. However, the Ingress resource itself is only a configuration declaration.
It does not do anything until an Ingress Controller is deployed to process it. The controller continuously watches the Kubernetes API server for changes to Ingress resources, Services, and Endpoints. When a new Ingress rule is created or updated, the controller programs a reverse proxy (also called a load balancer) to enforce those rules.
Common commercial and open-source Ingress Controllers include NGINX Ingress Controller (maintained by the Kubernetes community and also by NGINX Inc.), HAProxy Ingress, Traefik, Kong, Istio, and AWS Load Balancer Controller. The NGINX Ingress Controller is the most widely used in CNCF environments and is commonly tested on the CKA exam.
An Ingress Controller typically works by generating a configuration file for the underlying proxy (e.g., nginx.conf for NGINX). It reloads the proxy configuration whenever rules change.
The controller is also responsible for managing SSL certificates, session affinity, rate limiting, and rewrite rules. It can be exposed externally via a Kubernetes Service of type LoadBalancer or NodePort, or via a host network daemonset. Ingress Controllers are flexible and can be customized with annotations on the Ingress resource.
For example, the annotation nginx.ingress.kubernetes.io/rewrite-target allows URL path rewriting. The Ingress resource itself supports two main routing patterns: host-based and path-based.
Host-based routing directs traffic for different domains (e.g., app1.example.com, app2.example.com) to different backend Services. Path-based routing directs traffic for different URL paths (e.
g., /api, /web) to different Services. Ingress Controllers can also handle TLS termination, meaning they decrypt HTTPS traffic before forwarding it to backend services. This offloads the cryptographic work from application pods.
The Ingress specification is defined in the networking.k8s.io/v1 API group. A single Ingress resource can route traffic to multiple Services, reducing the number of load balancers needed.
In cloud environments, the Ingress Controller often integrates with the cloud provider's native load balancer to obtain a public IP address. For example, the AWS Load Balancer Controller creates an Application Load Balancer (ALB) in AWS and syncs Ingress rules to it. The controller then manages target groups and listener rules automatically.
For the CKA exam, you should be able to explain the difference between Ingress and Ingress Controller, describe how to deploy a basic NGINX Ingress Controller, and verify that Ingress rules are correctly routed.
Real-Life Example
Think about a large hospital with a single main reception desk. The hospital has many departments: emergency, cardiology, radiology, and pharmacy. When a patient arrives, they approach the receptionist.
The patient might say, I have an appointment with Dr. Smith in cardiology. The receptionist checks a computer system that lists which doctor is in which room and on which floor. This computer system is like the Ingress resource.
The receptionist is the Ingress Controller. The receptionist then tells the patient to take the elevator to the third floor and go to room 312. In this analogy, the patient is an incoming HTTP request.
The hospital building is the Kubernetes cluster, with a single external entrance. Without the receptionist, each department would need its own separate entrance, which would be confusing and expensive. The receptionist also handles special cases.
If a patient arrives and says, I have a package for the radiology department, the receptionist checks the rules and updates the directions accordingly. This is like path-based routing where /package/radiology goes to one service, and /appointment/cardiology goes to another. The receptionist also manages security badges for doctors, which is like SSL termination.
A doctor arriving with a special keycard can access restricted areas. Similarly, an Ingress Controller can decrypt HTTPS traffic and then forward it as plain HTTP to internal services, which reduces the workload on those services. If the hospital expands and adds a new outpatient wing, the receptionist updates the computer system and can now direct patients to the new wing.
In Kubernetes, when you add a new Ingress rule, the Ingress Controller automatically updates its configuration and starts routing traffic to the new service. This happens without any manual network changes. The receptionist is always on duty, watching for new patients (requests) and new departments (services).
This constant monitoring is analogous to the controller watching the API server. The hospital reception desk is a single point of entry, which is efficient and easy to manage. In Kubernetes, the Ingress Controller provides that same efficiency by consolidating external access through one or a few load balancers.
Why This Term Matters
In real-world IT work, managing how external traffic reaches applications inside a Kubernetes cluster is one of the most common and critical tasks. Without an Ingress Controller, you would need to expose each service with its own cloud load balancer, which quickly becomes expensive and hard to manage. For example, if you have ten microservices, each requiring a separate load balancer, your cloud costs skyrocket, and you have ten public IP addresses to secure and maintain.
An Ingress Controller solves this by allowing you to expose many services through a single external endpoint. This matters for network security because you can centralize SSL certificate management, rate limiting, and authentication at a single point. Instead of configuring these features for each service individually, you set them once in the Ingress resource or controller configuration.
This reduces the attack surface and simplifies compliance auditing. In cybersecurity, the Ingress Controller acts as a first line of defense. It can block malicious traffic based on IP addresses, enforce HTTP methods, and integrate with Web Application Firewalls (WAF).
It also handles TLS termination, ensuring that traffic between clients and the cluster is encrypted, while internal traffic within the cluster can remain unencrypted for performance. For system administrators and DevOps engineers, the Ingress Controller provides a standardized way to manage routing. Teams can define routing rules in YAML files and apply them with kubectl, which integrates into CI/CD pipelines.
This automation reduces human error and speeds up deployments. In cloud infrastructure, Ingress Controllers often integrate with cloud-native services like AWS ALB, Google Cloud HTTP Load Balancer, or Azure Application Gateway. This allows you to leverage the cloud provider's global load balancing and DDoS protection.
The Ingress Controller also supports canary deployments and blue-green deployments by routing a percentage of traffic to a new version of a service. This is critical for modern production systems where zero-downtime deployments are expected. Without the Ingress Controller, implementing such traffic splitting would require complex load balancer configurations outside Kubernetes.
In summary, the Ingress Controller is not just a convenience. It is essential for cost management, security, automation, and operational efficiency in Kubernetes environments.
How It Appears in Exam Questions
In the CKA exam, questions about Ingress Controllers appear in several formats. The most common is the configuration question, where you are given a cluster and asked to create an Ingress resource that routes traffic to a specific service. For example, you might be told: Create an Ingress named my-ingress in the default namespace that routes traffic from the host example.
com to the service web-service on port 80. You must write the YAML manifest and apply it. Another type is the troubleshooting question. You might be given a cluster where an Ingress resource exists but the application is not accessible from outside.
You need to diagnose whether an Ingress Controller is deployed, whether the controller's Service has an external IP, and whether the backend Service has endpoints. For example, you could be asked: A user reports that app.example.
com returns a 502 error. The Ingress resource and Service exist. What is the most likely cause? The answer might be that the Ingress Controller pod is not running, or the backend pods are not healthy.
There are also architecture questions that test your understanding of the relationship between Ingress and Ingress Controller. For instance: Which component is responsible for actually implementing the routing rules defined in an Ingress resource? The correct answer is the Ingress Controller.
You might also see a comparison question: What is the difference between a Service of type NodePort and an Ingress? The correct answer highlights that NodePort exposes a single service on a high port, while Ingress can expose multiple services on standard ports (80/443) with host and path rules. In the CKA performance-based exam, you will often have to deploy the NGINX Ingress Controller using a provided manifest from the Kubernetes documentation.
You need to understand the steps: download the deployment file, modify it if necessary (e.g., change the Service type to NodePort if the cluster has no load balancer), apply it, and verify that the controller pods are running.
Then you create an Ingress resource and test it using curl with the appropriate Host header. Another common pattern is the scenario where you must rewrite a URL path. For example, you have a service that expects requests on /app, but the Ingress receives requests on /api.
You need to use an annotation like nginx.ingress.kubernetes.io/rewrite-target: / to strip the prefix. This is often tested indirectly by asking you to configure an Ingress so that traffic to /api reaches the backend at /.
Finally, TLS-related questions appear frequently. You might be given a certificate and key and asked to create a Secret, then reference that Secret in the Ingress spec under spec.tls.
You also need to specify the hosts that the TLS certificate covers.
Study cncf-cka
Test your understanding with exam-style practice questions.
Example Scenario
Scenario: A small e-commerce company runs its online store on a Kubernetes cluster. The store has two parts: a public website that customers browse, and an admin dashboard for employees. Both are separate services named store-front and store-admin.
The company wants to expose both services using a single external IP address. Customers should reach the store at shop.example.com, and employees should reach the admin at admin.example.
com. The company also wants HTTPS for both. How does the Ingress Controller help here? First, the DevOps team deploys an NGINX Ingress Controller in the cluster. They expose it via a cloud load balancer that provides a single public IP.
Then they create an Ingress resource with two rules. The first rule matches the host shop.example.com and routes traffic to the store-front service. The second rule matches admin.example.
com and routes to store-admin. The Ingress resource also references a Secret containing TLS certificates for both domains. The Ingress Controller watches this resource and automatically configures NGINX to accept HTTPS connections, decrypt the traffic, and forward it to the correct internal service.
When a customer opens shop.example.com in their browser, the DNS resolves to the load balancer IP, which forwards to the Ingress Controller. The controller sees the host header, matches the rule, and sends the request to store-front.
The customer is unaware that the request passed through an intelligent router. The same process happens for the admin dashboard, but requests go to a different internal service. If the company later adds a blog at blog.
example.com, they simply update the Ingress resource with a new host rule, and the controller picks up the change without any manual network reconfiguration. This scenario demonstrates how the Ingress Controller provides a single entry point for multiple services, simplifies TLS management, and enables automatic configuration updates.
Common Mistakes
Thinking that creating an Ingress resource automatically makes your service accessible from outside the cluster without deploying an Ingress Controller.
The Ingress resource is only a configuration object. It has no built-in networking logic. Without a running Ingress Controller, the Ingress resource does nothing, and traffic will not be routed.
Always verify that an Ingress Controller is deployed and running in your cluster before creating Ingress resources. Check for the controller pods and ensure their Service is properly exposed.
Configuring an Ingress to route traffic to a Service but forgetting to define the correct port in the Ingress resource.
The Ingress resource requires the service port to be specified under spec.rules.http.paths.backend.service.port. If the port is missing or incorrect, the controller will not know which port to forward traffic to, causing a connection failure.
Always check the port number of the target Service (the one defined in the Service manifest) and match it exactly in the Ingress resource under service.port.number.
Assuming that the Ingress Controller automatically handles SSL termination for all hosts without creating a TLS Secret.
SSL certificates must be stored in Kubernetes Secrets and referenced in the Ingress resource under spec.tls. Without a proper Secret, the Ingress Controller will not be able to serve HTTPS traffic and may fall back to HTTP or return an error.
Create a TLS Secret containing the certificate and private key, then reference it in the Ingress resource. Ensure the Secret is in the same namespace as the Ingress.
Not adding the Host header when testing an Ingress with curl, resulting in traffic going to a default backend or failing.
Ingress rules often rely on host-based routing. If you use curl without specifying the host header (e.g., curl http://cluster-ip), the Ingress Controller may not match any rule and will either route to a default backend or return a 404.
Always use the --header flag in curl to include the correct host. Example: curl -H 'Host: app.example.com' http://<controller-ip>
Exam Trap — Don't Get Fooled
In a CKA exam scenario, you are asked to create an Ingress that routes traffic to a Service. You create the Ingress resource, but you forget to check whether an Ingress Controller is deployed. The cluster does not have one.
You apply the Ingress, test it, and it does not work. The exam expects you to recognize that the Ingress Controller is missing. Before creating an Ingress, always check for the existence of an Ingress Controller using kubectl get pods --all-namespaces | grep ingress.
If no pods are found, you must deploy one. In the exam, always read the entire scenario carefully. If the question does not mention that an Ingress Controller is present, assume it is not.
Deploy the controller first using the official manifest. Then create the Ingress. This systematic approach ensures you do not miss the critical prerequisite.
Commonly Confused With
The Ingress resource is a Kubernetes API object that defines routing rules. It is a YAML configuration. The Ingress Controller is the actual software that runs in the cluster and implements those rules. One is a definition, the other is a running process. You cannot expose a service with just an Ingress resource; you need the controller to make it work.
Think of the Ingress resource as a recipe written on paper. The Ingress Controller is the chef who reads the recipe and actually cooks the meal. The paper alone does not feed anyone.
A NodePort Service exposes a single service on a static port across all cluster nodes. An Ingress Controller can route multiple services on standard ports (80/443) and supports host and path-based routing. NodePort is simpler but less flexible and requires knowing the port number. Ingress provides a more sophisticated and unified entry point.
NodePort is like each apartment in a building having its own separate doorbell with a specific number. Ingress is like a single reception desk that directs visitors to the correct apartment based on the name they give.
A Load Balancer Service provisions an external cloud load balancer for each service. This creates one load balancer per service, which is expensive and hard to manage. An Ingress Controller typically uses one load balancer for multiple services, reducing cost and complexity. The Load Balancer Service is a lower-level construct, while Ingress is a higher-level abstraction that can sit on top of a Load Balancer Service.
Load Balancer Service is like renting a separate shuttle bus for each office building employee. Ingress Controller is like a single bus that drops people at the correct building entrances based on where they need to go.
Step-by-Step Breakdown
Deploy an Ingress Controller
First, you must choose and install an Ingress Controller. For example, you can deploy the NGINX Ingress Controller using kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.5/deploy/static/provider/cloud/deploy.yaml. This creates a Deployment, a Service, and necessary RBAC resources. The controller pod will start watching the Kubernetes API for Ingress resources.
Create backend Services and Pods
The Ingress Controller routes traffic to Kubernetes Services. Before creating an Ingress, ensure the target Services exist and have healthy endpoints (i.e., pods are running). Each Service should be of type ClusterIP (or NodePort) and expose a port that the Ingress can target.
Create an Ingress resource YAML
Write a YAML file that defines the routing rules. The Ingress resource specifies a host (e.g., app.example.com) and a path (e.g., /api), then references the backend Service name and port. For example: apiVersion: networking.k8s.io/v1; kind: Ingress; metadata: name: my-ingress; spec: rules: - host: app.example.com; http: paths: - path: /api; pathType: Prefix; backend: service: name: api-service; port: number: 80.
Apply the Ingress resource
Use kubectl apply -f ingress.yaml to submit the Ingress resource to the Kubernetes API server. The Ingress Controller is watching for new or updated Ingress resources and will pick up this change within seconds. It will then program the underlying reverse proxy (e.g., NGINX) with the new routing rules.
Verify the routing configuration
Check that the Ingress Controller has processed the resource. Use kubectl describe ingress my-ingress to see the status; look for an Address field if the controller provides an external IP. Also check the controller logs with kubectl logs -n ingress-nginx <controller-pod> to confirm no errors. Finally, test the routing using curl with the correct Host header or by configuring DNS.
Expose the Ingress Controller externally (if needed)
If the Ingress Controller's Service is of type LoadBalancer, the cloud provider assigns a public IP. In a local environment like minikube, use minikube tunnel to get an external IP. Alternatively, use NodePort and access the cluster node IP on the specified port. Without external exposure, only internal cluster traffic can reach the Ingress Controller.
Practical Mini-Lesson
To work effectively with Ingress Controllers in a Kubernetes environment, you need to understand three layers: the Ingress resource, the Ingress Controller software, and the underlying proxy configuration. Let us walk through a practical deployment using the NGINX Ingress Controller, which is the most common choice in exam and production contexts. First, you need to deploy the controller.
The official documentation provides a set of YAML manifests that include a Deployment, a Service, a ConfigMap, and RBAC roles. You can deploy the controller with a single kubectl apply command pointing to the official deployment file. After applying, check that the controller pod is running in the ingress-nginx namespace.
The controller pod runs an NGINX process and a Lua script that watches for changes. When you create an Ingress resource, the controller reads it and generates an nginx.conf configuration file.
This file includes server blocks for each host, location blocks for each path, and proxy_pass directives pointing to the backend Service's ClusterIP and port. The controller then reloads NGINX to apply the new configuration. This reload happens seamlessly, but heavy reloads can cause brief connection drops.
For production, use the controller's built-in load balancing and health checks. To test your setup, create a simple web application and expose it via a Service. Then create an Ingress that routes traffic to that Service.
Use curl with the -H 'Host: yourhost.com' flag to simulate a request. If you get a response, the Ingress Controller is working. If you get a timeout or 404, start debugging. Common issues include the Ingress Controller not having an external IP, the Service name or port being wrong, or the Ingress resource being in a different namespace than the target Service.
Ingress Controllers also support advanced features like sticky sessions, rate limiting, and custom error pages. These are configured via annotations. For example, nginx.ingress.kubernetes.
io/affinity: cookie enables session persistence. Always check the documentation for your chosen controller because annotation names vary. Another important aspect is TLS termination.
To enable HTTPS, create a Secret with the certificate and private key, then reference it in the Ingress spec. The controller will automatically serve the certificate and decrypt incoming HTTPS traffic. For the CKA exam, you should become comfortable with these tasks: deploying the NGINX Ingress Controller from the official manifest, creating Ingress resources with host and path rules, creating TLS Secrets, and verifying routing using curl or other tools.
This practical knowledge is directly applicable to real-world Kubernetes administration.
Memory Tip
The Ingress resource is the rulebook, the Ingress Controller is the referee who enforces the rules. Without the referee, the rulebook is just paper.
Covered in These Exams
Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
Frequently Asked Questions
Can I have multiple Ingress Controllers in the same Kubernetes cluster?
Yes, you can run multiple Ingress Controllers simultaneously. Each controller is typically configured to watch Ingress resources with a specific IngressClass. Use the spec.ingressClassName field in the Ingress resource to specify which controller should handle it.
What happens if I create an Ingress resource but no Ingress Controller is running?
The Ingress resource will be stored in the Kubernetes API but will have no effect. Traffic will not be routed because there is no software to implement the rules. You must deploy an Ingress Controller for the Ingress to work.
Does an Ingress Controller support TCP and UDP traffic?
Standard Kubernetes Ingress is designed for HTTP and HTTPS traffic only. Some Ingress Controllers (like NGINX) can be extended to handle TCP/UDP traffic using custom resources or configuration. For pure TCP/UDP services, consider using a Load Balancer Service or a NodePort.
How does the Ingress Controller know which service to route traffic to?
The Ingress Controller reads the backend definition in the Ingress resource, which specifies the Service name and port. It then queries the Kubernetes API to get the ClusterIP of that Service and the IPs of the pods behind it. The controller configures the reverse proxy to forward traffic to those pod IPs.
What is the default backend in an Ingress?
The default backend is a fallback service that handles requests that do not match any rule in the Ingress resource. It is defined under spec.defaultBackend. Some Ingress Controllers also have a built-in default backend that returns a 404 page.
Can an Ingress Controller automatically generate SSL certificates?
Yes, many Ingress Controllers integrate with cert-manager to automatically request and renew SSL certificates from Let's Encrypt or other ACME providers. This is done by adding annotations to the Ingress resource, such as cert-manager.io/cluster-issuer.
Summary
An Ingress Controller is a fundamental component in Kubernetes that brings Ingress resources to life by routing external HTTP and HTTPS traffic to the correct services inside a cluster. It acts as a smart gateway, consolidating multiple services behind a single external entry point, which reduces cost and simplifies management. The Ingress Controller handles advanced tasks like SSL termination, host-based and path-based routing, and integration with cloud load balancers.
For IT professionals, understanding the Ingress Controller is essential for building secure, scalable, and maintainable Kubernetes deployments. In the CKA exam, you will be tested on your ability to deploy an Ingress Controller, create Ingress resources with correct configurations, and troubleshoot common issues like missing Controllers or incorrect host and path settings. Remember that the Ingress resource is only a rule set, and the Ingress Controller is the engine that enforces those rules.
Avoid the common mistake of assuming an Ingress resource alone exposes your service. Always verify that the Ingress Controller is running and properly exposed. Mastering this concept will help you pass the exam and excel in real-world Kubernetes administration.