Introduction:
The blog provides a demo of domain-based routing using Ingress. It guides readers through creating a ingress.yaml
file that defines the Ingress resource for redirecting traffic to a specific service based on the host and path. The necessary commands for deploying the Ingress resource and setting up the Ingress controller are provided. Since a registered domain is required for the demo, the blog suggests updating the /etc/hosts
file on the local system to map the Ingress address.
Problem Statement:
In the initial phase of Cuba nuts. Cuban nets were introduced without the ingress capabilities. People were using VMs before shifting to k8s. After the introduction of cats, people were shifted from virtual machines to Kubernetes clusters. In Kubernetes clusters, there were services that we discussed in an earlier blog that were capable of functions like load balancing. but the load balancing which was offered by Kubernetes was way more incapable in enterprise-level load balancing. Features like sticky sessions, TLS, path-based load balancing, host best load balancing, ratio based whole balancing was missing in Kubernetes Services.
Also, we saw in. the services section of Kubernetes that if we want to expose our application to the external world, we need to introduce a service type of load balance. But in order to use a service of type load balance, we need to host our Kubernetes clusters on cloud providers, For which cloud providers will charge a certain amount.
Solution:
In order to solve this problem, Kubernetes came up with a solution called Ingress. In Ingress, we can deploy a manifest containing the resource type of Ingress in which we can specify the load balance of our desire. We can specify that we need an ingress controller of path routing type, which will be written by load balancing companies like NGINX, F5, Ambassador, and HAproxy. Ultimately we need to deploy the ingress controller to the k8s cluster in order to use it and this can be done using Helm charts or YAML manifests. Ingress controller is nothing but a combination of load balancer and API gateway. Due to this, the problem Of Kubernetes not having enterprise-level load balancing was solved. In order to use ingress services on the k8s cluster, we need to deploy and set up an ingress controller on our cluster.
Let's say if the user wants a path-based routing that is not provided by default services of K8s Ingress come into the picture to solve this problem. The user simply has to create a new resource of ingress type in which while building the manifest he or she has to mention path-based routing. This is ultimately implemented by ingress controllers. These manifests of ingress resources can be in the form of YAML files or HELM charts.
Demo: Domain-based Routing
Refer my this blog for deploying the service
- First, we will create
ingress.yaml
file which will be manifest for our ingress resource
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: python-app
port:
number: 8000
in this file, we are saying that if the user tries to visit foo.bar.com/demo he or she should be redirected to the service named python-app
which is running on port 80.
- After creating the
ingress.yaml
run the following command to deploy the resources
kubectl apply -f ingress.yaml
- After setting up the resource it is required to set up the ingress controller.
minikube addons enable ingress
Run kubectl logs <ingress_controller_pod> -n <ingress_namespace>
to see if it has picked our earlier created resource or not. Also run kubectl get ingress
to see if the address is assigned or not.
As we are using our local system and do not have a registered domain name which is required to be purchased from sites like GODADDY etc. we need to update
/etc/hosts
file to map our ingress adders i.e.172.31.80.90
in this case to foo.bar.comTo update
/etc/hosts
Go to C:\Windows\System32
Search for etc
In ect update the host file
Now in browse try to access foo.bar.com/demo
Summary:
The blog further explains that Ingress is particularly useful for scenarios like path-based routing, which is not provided by default Kubernetes services. Users can create an Ingress resource specifying path-based routing in the manifest file, which is implemented by the Ingress controller. The manifests for Ingress resources can be in the form of YAML files or HELM charts. Overall, the blog highlights the problem of inadequate load balancing in Kubernetes and presents Ingress as the solution, along with a practical demonstration of its usage for domain-based routing.