Skip to content

Kubernetes Ingress

Links: 110 Kubernetes Index

Load Balancer

  • If you want to directly expose a service, this is the default method.
    • attachments/Pasted image 20220829210218.jpg
  • All traffic on the port you specify will be forwarded to the service.
  • There is no filtering, no routing, etc.
  • This means you can send almost any kind of traffic to it, like HTTP, TCP, UDP, Websockets, gRPC, or whatever.
  • The big downside is that each service you expose with a LoadBalancer will get its own IP address, and you have to pay for a LoadBalancer per exposed service, which can get expensive!


  • Ingress is NOT a type of service it is of kind: Ingress.
  • Instead, it sits in front of multiple services and act as a "smart router" or entrypoint into your cluster.
  • You can do a lot of different things with an Ingress, and there are many types of Ingress controllers that have different capabilities.
  • The default GKE (Google Kubernetes Engine) ingress controller will spin up a HTTP(S) Load Balancer for you.
    • This will let you do both path based and subdomain based routing to backend services.
    • For example, you can send everything on to the foo service, and everything under the path to the bar service.
  • Ingress example
    • attachments/Pasted image 20220829210524.jpg

When should you use ingress?

  • Ingress is probably the most powerful way to expose your services, but can also be the most complicated.
  • There are many types of Ingress controllers, from the Google Cloud Load BalancerNginxContourIstio, and more.
  • There are also plugins for Ingress controllers, like the cert-manager, that can automatically provision SSL certificates for your services.
  • Ingress is the most useful if you want to expose multiple services under the same IP address, and these services all use the same L7 protocol (typically HTTP).
  • You only pay for one load balancer if you are using the native GCP integration, and because Ingress is “smart” you can get a lot of features out of the box (like SSL, Auth, Routing, etc)
To make ingress accessible from outside it needs to be published as NodePort or LoadBalancer

Ingress Controller & Resource

  • There are multiple reverse proxies like traefik, nginx, haproxy etc.
  • We can deploy any of these solutions and the solution we deploy is known as the ingress controller.
  • The rules we configure are known as ingress resources.
    • attachments/Pasted image 20220909191019.jpg
A k8s cluster doesn't come with an ingress controller by default.

So we just create ingress resources it won't work.

  • Ingress controller is deployed as pod with ConfigMaps and secrets passed to it.
    • attachments/Pasted image 20220909191259.jpg
  • Service to link ingress controller to the outside world
    • attachments/Pasted image 20220909191357.jpg
Ingress controllers have additional intelligence built into them to monitor the k8s cluster and configure the underlying nginx server when something changes.

But for ingress controller to do this it requires a service account with right set of permissions with correct role and role bindings. attachments/Pasted image 20220909191626.jpg

Ingress controller is a type of deployment.

It is just a regular deployment.

  • Things required to deploy an ingress controller

    • attachments/Pasted image 20220909191657.jpg
  • Difference between ingress controller & resource

    • attachments/Pasted image 20220909203102.jpg
If you are using an ingress controller in any cloud platform then it needs to have proper permissions to deploy load balancers.

attachments/Pasted image 20220909203224.jpg


Last updated: 2022-09-09