🔭Really Getting to Grips with Kubernetes Ingress: A Hands-On Guide with Minikube

Hello, and welcome to your Aiden's Lab Notebook.

In our last post, we took a look at minikube.

We covered why you'd want to use it, what to keep in mind before diving in, and even went through the installation process together.

But just installing minikube and calling it a day would be a shame, right? So this time, we're going to try a hands-on exercise: deploying and exposing an Nginx app using Ingress on the Kubernetes cluster we created with minikube.

With this guide, you'll get to use Ingress, a core Kubernetes feature that's widely used these days, directly on your local minikube cluster and understand how it works.

I've tried to make this guide as intuitive as possible so you can follow along easily. Let's dive in!

Deploying and Exposing an Nginx App with Ingress on Minikube

First, let's walk through a basic yet essential Ingress exercise on our minikube cluster.

Then this is perfect for you! As I show you how to expose a simple app deployed on our minikube cluster using Ingress, I'll also give you a concise explanation of when Ingress comes in handy.

Ingress receives incoming HTTP or HTTPS requests from outside the cluster and then, based on predefined routing rules, forwards those requests to the appropriate internal cluster services (Pods).

Notably, Ingress allows you to use a single IP address and port while distributing traffic to different applications based on the URL's path.

Since each service is assigned a unique URL path for differentiation, you can optimize resource usage and simplify the management of external access points.

To give a simple example with minikube, HTTP requests coming into the minikube cluster's IP on port 80 could be routed as follows based on predefined rules:

• /app1 -> Internal Service A in the cluster

• /app2 -> Internal Service B in the cluster

Actually, the Kubernetes Ingress resource itself is more like a 'manual of routing rules' that describes how external requests should be connected to internal services.

You declaratively specify in an Ingress YAML file which service to forward to when a request comes to a specific URL path.

So, who actually does the work of forwarding traffic based on the rules defined in the Ingress resource?

That would be the Ingress Controller.

Therefore, to use the Ingress feature in a Kubernetes cluster, you need to install an Ingress Controller separately and then define an Ingress resource.

The minikube we're using offers various additional features as add-ons, and the Ingress Controller can also be easily installed as one.

Let's start by enabling the Ingress addon in minikube for our practice.

1. Enabling the Ingress Addon in Minikube

After starting the minikube cluster we created in the previous post (using the minikube start command), let's check the list of currently installed and available addons with the minikube addons -p {your_minikube_cluster_name} list command.

As you can see in the image, the Ingress addon is currently disabled in our minikube cluster. Let's enable it with the following command:

minikube addons -p {your_minikube_cluster_name} enable ingress

When you run the command, the Ingress addon installation will proceed as shown below. (This might take a little while to install.)

After the installation is complete, if you run the minikube addons -p {your_minikube_cluster_name} list command again...

It shows that Ingress is now enabled✅!

Now, let's create the services that will route traffic via Ingress using Kubernetes Deployment and Service resources, and also create the Ingress resource that specifies the traffic routing rules.

2. Creating Deployment, Service, and Ingress Resources

For an intuitive exercise, we'll configure each service that will receive traffic as an Nginx server.

Here are the two test services we'll deploy in this exercise:

• user-nginx: An Nginx server that receives traffic ending in /user

• product-nginx: An Nginx server that receives traffic ending in /product

The key thing to note in each Deployment is that the Nginx image version used by the user service (1.23) is different from the one used by the product service (1.25).

This is so we can verify if traffic is being routed as expected when we test after everything is deployed.

First, let's write the Kubernetes resource manifest for deploying the user-nginx service.

# 1. Deployment for user-nginx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user-nginx
  template:
    metadata:
      labels:
        app: user-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23 # Using a different version from the product service for Ingress testing clarity
        ports:
        - containerPort: 80

---
# 2. Service for user-nginx
apiVersion: v1
kind: Service
metadata:
  name: user-nginx-service
spec:
  selector:
    app: user-nginx
  ports:
  - protocol: TCP
    port: 80 # Port the Service will expose
    targetPort: 80 # Container port on the Pod

# Since Ingress routes external traffic to internal Services in the minikube cluster, the Service Type is set to ClusterIP.
# The default Type for a Kubernetes Service is ClusterIP, so we don't explicitly specify it in the manifest.

Next is the Kubernetes resource manifest for deploying the product-nginx service.

# 1. Deployment for product-nginx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: product-nginx
  template:
    metadata:
      labels:
        app: product-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25 # Using a different version from the user service for Ingress testing clarity
        ports:
        - containerPort: 80

---
# 2. Service for product-nginx
apiVersion: v1
kind: Service
metadata:
  name: product-nginx-service
spec:
  selector:
    app: product-nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Finally, here's the Ingress resource that will route the traffic.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  # The class name of the Ingress to use (specify 'nginx' when using minikube's Ingress addon)
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /user # Path to apply the routing rule
        pathType: Prefix # Route if the URI starts with the path value
        backend:
          service:
            name: user-nginx-service # Name of the user-nginx Service
            port:
              number: 80 # Port number exposed by this Service
      - path: /product
        pathType: Prefix
        backend:
          service:
            name: product-nginx-service # Name of the product-nginx Service
            port:
              number: 80

I created a new arbitrary folder (e.g., ingress-test) and then created each manifest file within it, like so:

Once you've written all the manifests, it's time to deploy them to your minikube cluster.

3. Deploying the Kubernetes Resources to the Minikube Cluster

We use kubectl to deploy resources to a Kubernetes cluster, and our minikube cluster is no exception.

Specifically, using the kubectl apply -f {filename_or_foldername} command allows you to deploy multiple manifests at once. In my case, I can deploy all the necessary resources for this exercise by specifying the folder containing the manifests, like this:

kubectl apply -f ingress-test

Navigate to the directory containing your ingress-test folder in your terminal, and then run the command. You'll see all the Kubernetes resources defined in the manifests being deployed:

Since we didn't specify a namespace when writing our manifests, all these resources have been deployed to the default namespace. You can verify the deployed resources using the kubectl get all command.

With all the resources for our Ingress practice deployed, let's now test if the traffic routing is working correctly.

4. Testing Ingress Traffic Routing

So far, we've enabled the Ingress Controller addon and deployed all the necessary Kubernetes resources, including the Ingress resource itself, to our cluster.

Remember, Ingress is responsible for routing external traffic that approaches the cluster. This external traffic refers to HTTP/HTTPS requests accessing the cluster via the minikube cluster's IP address.

So, to test our Ingress setup, we need to know the IP address of our minikube cluster. The command to find it is:

minikube -p {your_minikube_cluster_name} ip

Run this command in your terminal, and you'll see the IP address of your minikube cluster, like this:

Simple enough, right? Now, let's try accessing a URL in the terminal, combining the minikube cluster IP with the paths we defined in our Ingress resource.

The curl command is perfect for testing access to a specific URL. Since we want to test traffic to two different services, let's enter these commands separately:

• curl http://{minikube_ip}/user

• curl http://{minikube_ip}/product

The key thing to look at here is the Nginx version displayed below the 404 Not Found error for each.

You should see the different Nginx versions we specified in each Deployment, like so:

• Nginx image version for the user service: 1.23

• Nginx image version for the product service: 1.25

If you see messages like these, it means the Ingress Controller, as intended for this exercise, has correctly routed the external traffic to the appropriate Service based on the URI, and each Nginx server received its respective request.

The 404 Not Found error appears because the default Nginx server images we used in each Deployment don't have actual pages at the /user and /product paths.

I skipped creating those pages to keep this exercise compact while still clearly demonstrating Ingress's traffic routing capabilities.

Wrapping Up

In this hands-on session, we've routed external traffic using Ingress on a minikube cluster.

As you went through the exercise, you've likely naturally grasped why Ingress is used and how to route traffic with it on a Kubernetes cluster.

This shows how minikube makes it easy to test and practice Kubernetes features right in your local environment.

In the next post, we'll move on to practicing with cloud-native tools on our minikube cluster.

There are tons of cloud-native tools out there, but we'll be focusing on Kustomize, a tool that helps manage Kubernetes resources systematically and conveniently, right on our minikube cluster.

So, stay tuned for the next one!

✨Enjoyed this issue?

How about this newsletter? I’d love to hear your thought about this issue in the below form!

👉 Feedback Form

Your input will be help improve Aiden’s Lab Notebook and make it more useful for you.

Thanks again for reading this notebook from Aiden’s Lab :)