Single responsibility is a magical notion. Whatever it touches, it makes it more manageable and efficient.
With Kubernetes, we have the power to spawn many services. As many of them as we would like. But how inbounds requests are routed among these services?
Ingressing is a powerful way to decouple routing rules with core application logic.
According to kubernetes,
Ingress is a collection of rules that allow inbound connections to reach to reach cluster services.
Overview
In this post, we’ll deploy a couple of services in the kubernetes cluster and then define an ingress to route the requests to one of them according to the rules.
By the end of this post, we’ll have a basic understanding of ingressing and a working demo to showcase its power.
More On Ingress
To allow inbound connections to reach cluster services, ingress configures a layer 7 load balancer and provides the following:
- TLS.
- Path-based routing.
- Name-based virtual routing.
- Custom Rules
With ingress, connections can’t reach our services directly. Instead, they reach the ingress endpoint and then are routed to a service based on rules.
With this in mind, let’s move forward to a working example.
Step 1: Spawn first service and deployment
We’ll be creating two services and deployments, named cats and dogs.
In this step, we’ll be spawning our first service.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: extensions/v1beta1 | |
| kind: Deployment | |
| metadata: | |
| name: cats-deployment | |
| spec: | |
| replicas: 3 | |
| template: | |
| metadata: | |
| labels: | |
| app: cats-deployment | |
| spec: | |
| containers: | |
| – name: cats-deployment | |
| image: nginx:alpine | |
| ports: | |
| – containerPort: 80 | |
| volumeMounts: | |
| – name: hostvol | |
| mountPath: /usr/share/nginx/html | |
| volumes: | |
| – name: hostvol | |
| hostPath: | |
| path: /home/docker/cat_volume |
Above is the .yaml file for our cats-deployment. Run the following command to create the cats-deployment.
kubectl create -f cats-deployment.yaml --validate=false
Now, we’ll create our cats-service.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: v1 | |
| kind: Service | |
| metadata: | |
| name: cats-service | |
| labels: | |
| run: cats-service | |
| spec: | |
| type: NodePort | |
| ports: | |
| – port: 80 | |
| protocol: TCP | |
| selector: | |
| app: cats-deployment |
Run the following command to create our cats-service.
kubectl create -f cats-service.yaml --validate=false
As you can see in the deployment file, we are also specifying a volume associated with the container named /home/docker/cat_volume.
Run the following commands after starting your minikube VM to host a file at that volume’s path.
minikube ssh mkdir cat_volume echo "cat service content
" > "index.html"
Tada! We have our first service and deployment up and running.
Step 2: Create the second service and deployment
We are going to name this one dogs.
Following the steps given, above create the deployment and service for our faithful friends dogs.
Here are the YAML files.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: extensions/v1beta1 | |
| kind: Deployment | |
| metadata: | |
| name: dogs-deployment | |
| spec: | |
| replicas: 3 | |
| template: | |
| metadata: | |
| labels: | |
| app: dogs-deployment | |
| spec: | |
| containers: | |
| – name: dogs-deployment | |
| image: nginx:alpine | |
| ports: | |
| – containerPort: 80 | |
| volumeMounts: | |
| – name: hostvol | |
| mountPath: /usr/share/nginx/html | |
| volumes: | |
| – name: hostvol | |
| hostPath: | |
| path: /home/docker/dog_volume |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: v1 | |
| kind: Service | |
| metadata: | |
| name: dogs-service | |
| labels: | |
| run: dogs-service | |
| spec: | |
| type: NodePort | |
| ports: | |
| – port: 80 | |
| protocol: TCP | |
| selector: | |
| app: dogs-deployment |
Step 3: Hit the endpoints of our services to see the content we just hosted on them.
Run the following command to get port numbers for the services.
kubectl get services
This will list all the services running the in kubernetes cluster along with their post numbers.
We should see something like this.
Get the port numbers and hit the browser to reach the pages of the two services we just hosted.
Use the following command to get base IP of the minikube VM
minikube ip
Here is how our two services cats and dogs are looking.
Step 4: Create the ingress for our services.
Following is the YAML file that we’ll use to create the ingress.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: extensions/v1beta1 | |
| kind: Ingress | |
| metadata: | |
| name: pets-ingress | |
| spec: | |
| rules: | |
| – host: cats.myweb.com | |
| http: | |
| paths: | |
| – backend: | |
| serviceName: cats-service | |
| servicePort: 80 | |
| – host: dogs.myweb.com | |
| http: | |
| paths: | |
| – backend: | |
| serviceName: dogs-service | |
| servicePort: 80 |
First, we need to start the ingress controller.
minikube addons enable ingress
With the following command, create the ingress.
kubectl create -f pets-ingress.yaml --validate=false
As we can see in the YAML file, we are doing name-based virtual routing between cats.myweb.com and dogs.myweb.com, routing them to our cats and dogs service respectively.
For the sake of our demo to work, we’ll have to add these hosts in our /etc/hosts file.
Add the following line in your /etc/hosts file.
192.168.99.100 cats.myweb.com dogs.myweb.com
Step 5: Hit the paths to see the ingress controller in action!
Congrats! Our ingress is working as expected and routing the names to their services like a routing ninja!
Conclusion
In this post, we got to know basics of ingressing and created a working demo to get the feel of its power.
There is a lot that ingress can do, let’s all keep exploring untill we fully learn how to harness its power.
Priyank Verma 
Leave a Reply