Rafael Natali
- Feb 5
- 2 min read

Kubernetes Network In Action - 3/3

Updated: Feb 20

This is the third and final articles explaining and detailing the Kubernetes Network model with a hands-on approach. In the first article, I spoke about Pod-to-Pod communication and in the second article about Pod-to-Service communication.

In this one, I will discuss Ingress / Ingress Controllers.

These articles are based on a repository I created which contains more examples and content. I invite you to review the repo at https://github.com/rafaelmnatali/kubernetes.

Ingress/Ingress Controllers

What is Ingress?

Ingress exposes HTTP and HTTPS routes from outside the cluster to Services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.

What is an Ingress Controller?

An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.

Ingress in real-life

1. To enable the NGINX Ingress controller, run the following command:

minikube addons enable ingress

2. Verify that the NGINX Ingress controller is running

kubectl get pods -n ingress-nginx

The output is similar to:

NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-6hbld       0/1     Completed   0          41s
ingress-nginx-admission-patch-bnrsb        0/1     Completed   1          41s
ingress-nginx-controller-77669ff58-x55s2   1/1     Running     0          41s

3. Create a Deployment using the following command:

kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0

4. Expose the Deployment:

kubectl expose deployment web --type=NodePort --port=8080

5. Verify the Service is created and is available on a node port:

kubectl get service web

6. Create the Ingress object by applying the following manifest file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: hello-world.info
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 8080

7. Verify the IP address is set:

kubectl get ingress

8. Verify that the Ingress controller is directing traffic:

curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info

if you can't communicate with the minikube ip, open the minikube tunnel in another terminal and use 127.0.0.1 instead of the $( minikube ip ).

You should see:

Hello, world!
Version: 1.0.0
Hostname: web-68487bc957-57rb7

Summary

This article provided a guide on how to use Ingress in Kubernetes to make applications accessible to external users. Ingress and Ingress Controller are two vital components that work together to offer a reliable solution for scenarios where external users need to access applications within the K8s cluster.

As we conclude our blog series on Kubernetes networking, I want to take a moment to thank you for joining me on this journey. Throughout this series, we’ve aimed to demystify Kubernetes networking, breaking down complex concepts into digestible pieces. We’ve covered how Pods communicate within a cluster, how Services enable communication between Pods, and how Ingress allows external access to your applications.

What topics would you like to see covered in future articles? Are there any concepts that are still unclear, or areas where you’d like more clarification? Let’s continue this conversation and keep learning together.

Rafael Natali