Kubernetes Ingress
Hello Every One . In this Blog I would like to explain the basics of kubernetes ingress and what problems it tries to solve that services can't.
Ingress
Using NodePort , Load balancer type we can access pod from outside but in Node port type it opens port on Node which is insecure and in load balancer type it only works when we use kubernetes in cloud .
Although we use kubernetes in cloud if we have many services that are exposed as load balancers then many load balancers are needed which are costly. Fails to provide secure connection ( https).
More Over Kubernetes fails to provide
1 Good Load balancing which means service using kube proxy services provides basic load balancing
Whitelist / black list some ips
Sticky sessions which means redirecting some ips to same pods.
Path based Domain based Routing
People coming from VM to kubernetes has observed many problems that kubernetes could not able to solve are solved by external load balancers like Nginx , HA Proxy , traefik .. .
So it is impossible for kubernetes to build all the features that 3rd party tools have So Kubernetes allowed those 3rd party tools to contribute to kubernetes.
So we have to install the ingress controller which means which any 3rd party load balancer to the cluster.Then we have to define ingress resource these ingress rules are monitored by this ingress controller. Because of Ingress now we can have enterprise level benefits in kubernetes cluster.
Using ingress we can connect to many services so exposing ingress as load balancer requires only one ip through which many services can be accessed. Using Ingress we can access app through any domain like goutham-app.com
ingress - class
As ingress controllers are from different 3rd party tools , ingress rules are kubernetes specific which means any ingress controller can run this rules but the implementaion varies. So without the ingress class ingress controller cannot run the rules. Ingress rules with the ingress class will be run by ingress controller having same ingress class. This is to restrict multiple ingress controller to run the same ingress class.
Path Based Routing
When ever the request comes to controller pod it routes to corresponding service using ingress rules.
When the path is nginx.in/ then it routes to pathsvc service if it is nginx.in/lib then routes to libsvc.
Host Based Routing
But to access the domain name in browser we have to manage the local domains , in /etc/hosts file map the domain name to the node ip.
Path type is required in ingress rules manifest file. Pathtypes can be
prefix
exact
Prefix is path must be prefix of the requested path.
/api/bar is prefix of /api/bar/foo or /api/bar/ and also with /api/barfoo
Exact is requested path must match to path in the manifest file.
Example
In minikube by there is a ingress addons we can enable using
minikube enable addons ingress
We can list all addons in minikube using minikube addons list
Then the necessary ingress controller pod , services .. are deployed to control-plane node in ingress-nginx namespace.
I have created 2 pods and using host volumes I have added some text to those 2 pods .
Now I attached ingress to these services.
Using Path based routing as above configuration. Using curl command I can access the service
But there is a problem when we use curl nginx.o/lib
Though we mentioned when we hit /lib path, request must be routed to libsvc service but the same path is forwarded to the pod but the pod doesnt have the path, so we get this page.
So after the service receives the request the /lib path has to be reomved and forwarded to pod.
Using rewrite-target annotation we can achieve this.
.
So now when I request nginx.o/lib then after the service receives the request /lib is replaced by /.
Success , That's it about basics of kubernetes ingress. Thanks for reading my article.