Links: 110 Kubernetes Index
- If you want to directly expose a service, this is the default method.
- 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
- 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 foo.yourdomain.com to the foo service, and everything under the
yourdomain.com/bar/path to the bar service.
- Ingress example
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 Balancer, Nginx, Contour, Istio, 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.
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.
- Service to link ingress controller to the outside world
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.
Ingress controller is a type of deployment.
It is just a regular deployment.
Things required to deploy an ingress controller
Difference between ingress controller & resource
If you are using an ingress controller in any cloud platform then it needs to have proper permissions to deploy load balancers.
- Kubernetes Ingress Explained Completely For Beginners - Updated - YouTube
- Kubernetes Ingress in 5 mins - YouTube
- Good explanation of NodePort
- Kubernetes Ingress Simplified | Ingress Vs Service | Ingress Controller Vs Ingress Resource - YouTube
- How ingress works with load balancer
- Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? | by Sandeep Dinesh | Google Cloud - Community | Medium
Last updated: 2022-09-09