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

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 

Everything looks perfect.

NAME READY STATUS nginx-7d8f9c6b5d-abc12 1/1 Running nginx-7d8f9c6b5d-def34 1/1 Running 

Then you check your Service:

kubectl get svc 

NAME TYPE CLUSTER-IP nginx-svc ClusterIP 10.96.120.15 

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.

Think about the architecture:

 INTERNET | v INGRESS | v SERVICE | +------+------+ | | v v POD 1 POD 2 | | +------+------+ | APPLICATION 

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 

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 

Example:

NAME READY STATUS IP nginx-1 1/1 Running 10.244.0.10 nginx-2 1/1 Running 10.244.0.11 

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 

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 

Apply it:

kubectl apply -f deployment.yaml 

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 

Apply:

kubectl apply -f service.yaml 

Check:

kubectl get svc 

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 

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

Example:

Frontend Pod | v Backend ClusterIP Service | v Backend Pods 

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 

Access it using:

http://NODE_IP:30080 

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 

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 

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 

The general format is:

SERVICE_NAME.NAMESPACE.svc.cluster.local 

You can test DNS resolution from a temporary Pod:

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

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 

🚪 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 

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 

This configuration defines a routing rule:

User Request | v myapp.example.com | v Ingress Controller | v nginx-service | v Nginx Pods 

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 

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 

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 

Check Services

kubectl get svc 

Check Service details

kubectl describe svc nginx-service 

Check EndpointSlices

kubectl get endpointslices 

Check Ingress

kubectl get ingress 

Check DNS components

kubectl get pods -n kube-system 

Check NetworkPolicies

kubectl get networkpolicies -A 

Inspect recent events

kubectl get events --sort-by=.metadata.creationTimestamp 

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? 

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 

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.