In this video, we answer the question of how Ingresses in Kubernetes work. Ingresses manage external access to services and pods within a cluster.

We start with three pods in our cluster, with their IP addresses ending at .9, .17, and .22. These pods use an existing pod network with the CIDR of 10.32.x./16. We then deploy another set of pods on the right with IP addresses ending in .4, .10, and .15.

We group each set of pods using a label known as "svc". Pods .9, .17, and .22 are given the "svc" value of "accounts". Our pods illustrated on the right are given the "svc" value of "products".

Now that we've given our pods their respective labels, we can group them behind a pair of services. One service, Accounts, is bound to any pods labeled "svc=accounts." Another service, Products, associates itself with the "svc=products" tagged pods. Each of these services provides a single endpoint for the pods they are bound to. Any traffic sent to a service is distributed to each of the pods behind it. In the absence of a real load balancer (like an Ingress) a randomizer is used by IP Tables to distribute the traffic amongst the Pod replicas.

Ingresses work on the service level. Ingresses are enabled by two components: Ingress resources and Ingress controllers. Ingress resources bind services to URL endpoints. We'll make one Ingress resource that binds the "Accounts" service to a /accounts endpoint. Then, we make an ingress resource that binds the "Products" service to a /products endpoint.

The final piece that enables ingress is the ingress controller. An ingress controller is a resource much like an API Gateway, deployed into, or in front of, a Kubernetes cluster that watches for any changes made to Ingress resources in the cluster. They are responsible for fulfilling the ingress requests by providing external access to the cluster and routing traffic to their intended destinations.

Once we place an Ingress controller in our hypothetical cluster, the Accounts and Products services (and the pods behind them) are now accessible from the outside world through the /accounts and /products URL endpoints defined by our ingress resources. Now, client requests made to the example.com/accounts endpoint get routed to our Accounts service pods, while client requests made to the example.com/products endpoints get routed to our Products service pods, in both cases, using an actual load balancing algorithm--bypassing the randomizer.

Check it out on our website: [ Ссылка ]

свернуть