DEV Community

Yash Sonawane
Yash Sonawane

Posted on

☸️ Kubernetes Networking Explained: What Actually Happens When You Access an Application?

#devops #kubernetes #networking #beginners

You deployed your application. Your Pod is running. Your Service exists. But your application is still not accessible. WHAT WENT WRONG? 💀

If you've worked with Kubernetes, you've probably experienced this situation.

You run:

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

Everything looks perfect.

NAME                       READY   STATUS
nginx-7d8f9c6b5d-abc12     1/1     Running
nginx-7d8f9c6b5d-def34     1/1     Running
Enter fullscreen mode Exit fullscreen mode

Then you check your Service:

kubectl get svc
Enter fullscreen mode Exit fullscreen mode 
NAME         TYPE        CLUSTER-IP
nginx-svc    ClusterIP   10.96.120.15
Enter fullscreen mode Exit fullscreen mode

But when you try to access your application...

Nothing.

Welcome to Kubernetes networking. 😂

The problem is that understanding Pods and Deployments isn't enough. You also need to understand how Kubernetes connects workloads, routes traffic, and exposes applications.

Let's break it down with practical examples.

🧠 1. First, Understand the Four Kubernetes Networking Concepts

Before writing YAML, understand these four concepts.

Component Purpose
Pod Networking Allows Pods to communicate
Service Provides a stable endpoint for a group of Pods
DNS Allows services to be discovered by name
Ingress Manages HTTP and HTTPS access from outside the cluster

Think about the architecture:

             INTERNET
                 |
                 v
             INGRESS
                 |
                 v
              SERVICE
                 |
          +------+------+
          |             |
          v             v
        POD 1         POD 2
          |             |
          +------+------+
                 |
             APPLICATION
Enter fullscreen mode Exit fullscreen mode

Each component has a different responsibility.

Let's understand them individually.

🌐 2. Pod Networking: How Do Pods Communicate?

Every Pod in a Kubernetes cluster gets its own IP address.

For example:

Pod A: 10.244.0.10
Pod B: 10.244.0.11
Pod C: 10.244.1.15
Enter fullscreen mode Exit fullscreen mode

In a properly configured Kubernetes network, Pods can communicate with other Pods using their IP addresses without requiring Network Address Translation between Pods.

However, the actual networking implementation depends on the cluster's Container Network Interface (CNI) plugin.

Examples include:

  • Calico
  • Cilium
  • Flannel
  • Amazon VPC CNI

The CNI plugin is responsible for implementing important parts of Pod networking.

Check Pod IP addresses:

kubectl get pods -o wide
Enter fullscreen mode Exit fullscreen mode

Example:

NAME      READY   STATUS    IP
nginx-1   1/1     Running   10.244.0.10
nginx-2   1/1     Running   10.244.0.11
Enter fullscreen mode Exit fullscreen mode

One important detail: Pod IP addresses are not stable application endpoints. Pods can be replaced, and their IP addresses can change.

That's why Kubernetes Services are important.

🔥 3. Kubernetes Services: The Secret Behind Stable Networking

Imagine your application has three replicas.

          Application
               |
       +-------+-------+
       |       |       |
       v       v       v
     Pod 1   Pod 2   Pod 3
Enter fullscreen mode Exit fullscreen mode

What happens if Pod 1 crashes?

A Deployment can create a replacement Pod, potentially with a different IP address.

If clients connect directly to Pod IPs, they need to discover the replacement.

Kubernetes Services solve this problem by providing a stable virtual IP and DNS name for a group of matching Pods.

Let's create a Deployment.

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Apply it:

kubectl apply -f deployment.yaml
Enter fullscreen mode Exit fullscreen mode

Now create a Service.

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
Enter fullscreen mode Exit fullscreen mode

Apply:

kubectl apply -f service.yaml
Enter fullscreen mode Exit fullscreen mode

Check:

kubectl get svc
Enter fullscreen mode Exit fullscreen mode

Congratulations! You now have a Service that selects your Nginx Pods using the label app: nginx.

The Service provides a stable endpoint even when individual Pods are replaced.

🧩 4. The Three Kubernetes Service Types You Must Know

This is an important topic for CKA preparation.

1. ClusterIP

Default Service type

ClusterIP exposes an application inside the cluster.

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080
Enter fullscreen mode Exit fullscreen mode

Use it when internal applications need to communicate with each other.

Example:

Frontend Pod
     |
     v
Backend ClusterIP Service
     |
     v
Backend Pods
Enter fullscreen mode Exit fullscreen mode

2. NodePort

NodePort exposes a Service on a port on each eligible node.

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080
Enter fullscreen mode Exit fullscreen mode

Access it using:

http://NODE_IP:30080
Enter fullscreen mode Exit fullscreen mode

The default NodePort range is 30000–32767, unless the cluster is configured differently.

3. LoadBalancer

LoadBalancer requests an external load balancer from an infrastructure provider that supports this integration.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
Enter fullscreen mode Exit fullscreen mode

On a supported cloud platform, this can provision an external load balancer.

Remember: Creating a LoadBalancer Service does not guarantee an external load balancer will appear in every local cluster. The environment must support the integration.

🔎 5. Kubernetes DNS: Access Services Without Remembering IP Addresses

Imagine you have 50 microservices.

Would you remember every Service IP address?

Of course not.

That's why Kubernetes provides service discovery through DNS.

For example:

frontend-service
backend-service
database-service
payment-service
Enter fullscreen mode Exit fullscreen mode

A Pod can access a Service using its DNS name.

For a Service named backend-service in namespace default:

backend-service.default.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

The general format is:

SERVICE_NAME.NAMESPACE.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

You can test DNS resolution from a temporary Pod:

kubectl run dns-test \
  --image=busybox:1.36 \
  --restart=Never \
  --rm -it \
  -- nslookup nginx-service
Enter fullscreen mode Exit fullscreen mode

This helps verify whether the Service name resolves inside the cluster.

If DNS fails, investigate:

  • CoreDNS Pods.
  • DNS configuration inside the Pod.
  • Service and namespace names.
  • Network policies.
  • Cluster networking.

Useful command:

kubectl get pods -n kube-system
Enter fullscreen mode Exit fullscreen mode

🚪 6. Ingress: How Does External HTTP Traffic Reach Your Application?

Imagine you've deployed an application and want users to access:

https://myapp.example.com
Enter fullscreen mode Exit fullscreen mode

You could expose a Service using NodePort or LoadBalancer.

But what if you have multiple applications and domains?

This is where Ingress becomes useful.

An Ingress resource defines HTTP and HTTPS routing rules. It requires an Ingress controller to implement those rules.

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-service
                port:
                  number: 80
Enter fullscreen mode Exit fullscreen mode

This configuration defines a routing rule:

User Request
     |
     v
myapp.example.com
     |
     v
Ingress Controller
     |
     v
nginx-service
     |
     v
Nginx Pods
Enter fullscreen mode Exit fullscreen mode

Important: Creating an Ingress resource alone does not make the application accessible. You need an installed and configured Ingress controller, plus appropriate DNS and network connectivity.

Also, Kubernetes Gateway API is an increasingly important alternative for implementing more advanced traffic-management use cases.

🔐 7. Network Policies: Control Who Can Talk to Whom

Here's an important security question.

Should every Pod be allowed to communicate with every other Pod?

Not necessarily.

Imagine a three-tier application:

Frontend
   |
   v
Backend
   |
   v
Database
Enter fullscreen mode Exit fullscreen mode

You may want:

  • Frontend to communicate with Backend.
  • Backend to communicate with Database.
  • Frontend to have no direct access to Database.

Kubernetes NetworkPolicies help define these traffic restrictions.

Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
spec:
  podSelector:
    matchLabels:
      app: database

  policyTypes:
    - Ingress

  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432
Enter fullscreen mode Exit fullscreen mode

This policy allows selected ingress traffic to database Pods from backend Pods in the same namespace, assuming your CNI supports NetworkPolicy enforcement.

A NetworkPolicy does not automatically secure your entire cluster. You must understand selectors, namespaces, ingress, egress, and the behavior of your network plugin.

🛠️ 8. Kubernetes Networking Troubleshooting Cheat Sheet

When networking breaks, don't randomly restart everything.

Use these commands to investigate.

Check Pods and their IPs

kubectl get pods -o wide
Enter fullscreen mode Exit fullscreen mode

Check Services

kubectl get svc
Enter fullscreen mode Exit fullscreen mode

Check Service details

kubectl describe svc nginx-service
Enter fullscreen mode Exit fullscreen mode

Check EndpointSlices

kubectl get endpointslices
Enter fullscreen mode Exit fullscreen mode

Check Ingress

kubectl get ingress
Enter fullscreen mode Exit fullscreen mode

Check DNS components

kubectl get pods -n kube-system
Enter fullscreen mode Exit fullscreen mode

Check NetworkPolicies

kubectl get networkpolicies -A
Enter fullscreen mode Exit fullscreen mode

Inspect recent events

kubectl get events --sort-by=.metadata.creationTimestamp
Enter fullscreen mode Exit fullscreen mode

A useful troubleshooting sequence 

Application Not Accessible
          |
          v
    Is Pod Running?
          |
          v
    Is Pod Ready?
          |
          v
    Does Service Exist?
          |
          v
    Does Service Have Endpoints?
          |
          v
    Does DNS Resolve?
          |
          v
    Is Network Policy Blocking Traffic?
          |
          v
    Is External Routing Configured?
Enter fullscreen mode Exit fullscreen mode

Follow the path instead of guessing.

🧪 9. Your Kubernetes Networking Challenge

Now it's time to practice.

Build a simple application with:

  • One frontend Deployment.
  • One backend Deployment.
  • One database Deployment.
  • ClusterIP Services.
  • DNS-based service discovery.
  • NetworkPolicies restricting database access.
  • An Ingress controller for external access.

Your architecture should look like this:

             INTERNET
                 |
                 v
               INGRESS
                 |
                 v
              FRONTEND
                 |
                 v
              BACKEND
                 |
                 v
              DATABASE
Enter fullscreen mode Exit fullscreen mode

Then deliberately introduce these failures:

  1. Change a Service selector so it no longer matches its Pods.
  2. Configure an incorrect targetPort.
  3. Use the wrong Service DNS name.
  4. Apply a NetworkPolicy that blocks required traffic.
  5. Remove or misconfigure the Ingress controller in a local test environment.

Try to identify each problem using only Kubernetes commands and logs.

Document the failure, root cause, and solution in your GitHub repository.

This is the kind of practical experience that makes Kubernetes concepts easier to understand.

🎯 Final Thoughts

Kubernetes networking is not just about memorizing ClusterIP, NodePort, and LoadBalancer.

It's about understanding how traffic moves through your cluster.

You should be comfortable explaining:

  • How Pods communicate.
  • Why Services are necessary.
  • How Kubernetes DNS works.
  • How Ingress routes HTTP traffic.
  • How NetworkPolicies restrict communication.
  • How to troubleshoot broken connectivity.

Once you understand these concepts, Kubernetes networking becomes much less mysterious.

Don't just deploy applications on Kubernetes. Understand how those applications communicate.

👇 Let's discuss!

Which Kubernetes networking concept took you the longest to understand?

  1. Pod networking and CNI
  2. ClusterIP vs NodePort vs LoadBalancer
  3. CoreDNS and service discovery
  4. Ingress
  5. NetworkPolicies

Share your experience in the comments. Your answer might help someone preparing for their Kubernetes certification!

📘 Preparing for the Certified Kubernetes Administrator (CKA) Exam?

If you're serious about learning Kubernetes and preparing for the CKA certification, check out my:

☸️ CKA Complete Study Guide — Certified Kubernetes Administrator

Build your Kubernetes knowledge, practice important concepts, and strengthen your preparation with a structured study resource.

Don't just memorize Kubernetes commands. Understand the technology behind them.

Top comments (0)