Favour Lawrence

Posted on Feb 8

Kubernetes Services vs. Ingress: What You Need to Know.

#devops #kubernetes #container #beginners

Ever tried accessing a containerized application running inside Kubernetes and realized it wasn’t as simple as running a server on your local machine? Unlike traditional setups where an app binds to a port and is instantly reachable, Kubernetes operates in a world of dynamic, ever-changing pods. If a pod dies and gets recreated, it might get a new IP, breaking direct access.

So, how do applications running inside a Kubernetes cluster communicate reliably? And how do we expose these applications to the outside world? This is where Kubernetes Services and Ingress come in.

Services ensure that even if pods come and go, your application remains accessible via a stable endpoint.
Ingress provides a smarter way to manage external access, acting as a traffic controller to route requests to the right service.

In this article, we’ll break down Kubernetes Services and Ingress, explaining when and why you need them with practical examples. Let's dive in!

🔹What is a Kubernetes Service?

In Kubernetes, a Service is an abstraction that provides a stable network endpoint to access a group of pods. Since pods are dynamic (they can be created, deleted, or rescheduled), their IPs keep changing. A Service ensures that applications can communicate reliably without worrying about changing pod IPs.

🔸 Why Do We Need Services?

🚀 Pods are ephemeral—they can restart or move to another node, getting a new IP.

🚀 Directly accessing a pod’s IP is unreliable since it might change at any moment.

🚀 A Service creates a fixed Cluster IP that stays the same, ensuring stable communication between pods and external users.

🔹 Types of Kubernetes Services

Kubernetes offers different types of Services based on how you want your application to be accessible. Let’s break them down:

🔸 ClusterIP (Default & Internal-Only)

✅ The default service type in Kubernetes.

✅ Creates an internal-only IP, meaning it’s only accessible inside the cluster.

✅ Perfect for internal communication between microservices.
Example: A backend API serving a frontend within the cluster.

🔸 NodePort (Basic External Access)

✅ Exposes the service on every node using a high-numbered port (30000–32767).

✅ You can access it via NodeIP:NodePort.

✅ Easy to set up but not ideal for production—managing ports can get messy!

🔸 LoadBalancer (Cloud-Managed External Access)

✅ Works in cloud environments like AWS, GCP, or Azure.

✅ Automatically provisions a cloud load balancer to handle traffic.

✅ The best option for production-grade external access.

🔸 Headless Service (For Direct Pod Access)

✅ Used when you don’t need a stable Cluster IP.

✅ Instead of routing traffic, it helps apps discover individual pods via DNS.

✅ Useful for databases, stateful applications, and custom service discovery.

🔹 Practical Example: ClusterIP Service YAML

Here’s a simple YAML configuration for a ClusterIP Service that exposes an Nginx pod:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80      # The Service's Port
      targetPort: 80 # The Pod's Port

✅ selector: Matches pods with the label app: nginx, so the Service knows where to send traffic.

✅ port: The port where the Service is exposed inside the cluster.

✅ targetPort: The actual port inside the pod where traffic should go.

Understanding Ingress

Kubernetes gives us multiple ways to expose applications, but Ingress is the smartest option. Instead of creating separate external access points for each service, Ingress acts as a single entryway, efficiently routing traffic to the right service inside your cluster.

🔹 What is Ingress in Kubernetes?

Ingress is a traffic manager for your cluster. It controls external access to services using rules based on domains, paths, and protocols like HTTP/HTTPS. Think of it as a router that directs requests to the correct backend service.

🔹 Why Use Ingress Instead of NodePort or LoadBalancer?

While NodePort and LoadBalancer work, they have limitations:

❌ NodePort exposes each service on a random high-numbered port—not ideal for production.

❌ LoadBalancer works better but creates a new cloud load balancer per service, which can get expensive and complex.

✅ Ingress solves both problems by allowing multiple services to share a single entry point, reducing cost and simplifying management.

🔹 How Ingress Routes External Traffic

1️⃣ A user sends an HTTP/HTTPS request to your cluster.

2️⃣ The Ingress resource checks its rules to decide which service should handle the request.

3️⃣ Traffic is forwarded to the correct pod inside the cluster.

🔹 The Role of an Ingress Controller

An Ingress Controller is needed to process Ingress rules. Popular choices include:

✔ NGINX Ingress Controller (most common)

✔ Traefik, HAProxy, AWS ALB, Istio, etc.

🔹 Setting Up Ingress: Simple Example

Here’s a basic Ingress configuration that routes traffic based on a hostname:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

✅ host: myapp.local → Requests to myapp.local are routed.

✅ path: / → All requests are sent to the backend service.

✅ backend.service.name: my-service → Traffic goes to my-service.

✅ port.number: 80 → The port where the service listens.

🔹 How to Apply and Test Ingress in Minikube

1️⃣ Enable the NGINX Ingress Controller in Minikube:

minikube addons enable ingress

2️⃣ Apply the Ingress YAML file:

kubectl apply -f my-ingress.yaml

3️⃣ Modify /etc/hosts to point to Minikube’s IP (Linux/macOS):

echo "$(minikube ip) myapp.local" | sudo tee -a /etc/hosts

4️⃣ Test it in a browser or with curl:

curl http://myapp.local

🚀 Service vs. Ingress: When to Use Each

Choosing between a Service (NodePort/LoadBalancer) and Ingress depends on how you want to expose your applications. Here’s the breakdown:

Use a Service when you need direct access to a single service, either internally or externally. However, each exposed service requires its own endpoint, which can get expensive and inefficient if you have many services.
Use Ingress when you want to manage multiple services under one entry point. It routes traffic based on domain names or paths, reducing complexity and cost.
A Service is simple but lacks advanced traffic control. Ingress, on the other hand, supports routing, TLS termination, and virtual hosts, making it ideal for large-scale apps.

Thanks for reading! If you found this helpful, please like and follow for more DevOps content. Feel free to comment with any questions or topics you'd like to see next!

DEV Community