Kubernetes Networking: Services, Ingress and Network Policies

Overview

Kubernetes networking is a fundamental pillar of container orchestration and a critical topic on the Certified Kubernetes Administrator (CKA) exam. This tutorial covers three essential networking components: Services (how pods communicate), Ingress (how external traffic enters the cluster), and Network Policies (how you enforce security boundaries).

Prerequisites:

• Kubernetes cluster (minikube, Kind, or cloud-hosted)
• kubectl CLI installed and configured
• Understanding of pods, deployments, and namespaces
• Familiarity with networking concepts (IP addresses, ports, DNS)

Why This Matters for CKA: The exam heavily tests networking knowledge, including service discovery, load balancing strategies, and traffic control. Questions often require you to troubleshoot connectivity issues or design network architectures under time pressure.

Getting Started

First, verify your cluster is running and kubectl works:

kubectl cluster-info
kubectl get nodes

Create a test namespace for this tutorial:

kubectl create namespace networking-demo
kubectl config set-context --current --namespace=networking-demo

Deploy a simple test application we'll use throughout:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: networking-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Apply this deployment:

kubectl apply -f deployment.yaml
kubectl get pods -o wide

Services: Exposing Your Pods

A Service is a Kubernetes abstraction that defines a logical set of pods and a policy for accessing them. Without services, individual pod IPs are ephemeral and unreliable.

Service Types:

• ClusterIP (default): Exposes the service on an internal IP accessible only within the cluster
• NodePort: Exposes the service on each node's IP at a static port (30000-32767)
• LoadBalancer: Exposes the service externally via cloud provider load balancer
• ExternalName: Maps service to external DNS name

Create a ClusterIP service:

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
  namespace: networking-demo
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Verify the service:

kubectl get svc
kubectl describe svc web-app-service
kubectl get endpoints web-app-service

Test service DNS resolution inside the cluster:

kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup web-app-service

Common Pitfall: Forgetting that targetPort must match the actual container port. If your app listens on 8080 but you set targetPort to 80, the service will fail to route traffic.

Now create a NodePort service for external access:

apiVersion: v1
kind: Service
metadata:
  name: web-app-nodeport
  namespace: networking-demo
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 31000

Apply and test:

kubectl apply -f nodeport-service.yaml
kubectl get svc web-app-nodeport
kubectl get nodes -o wide

On minikube, test with:

minikube service web-app-nodeport --namespace=networking-demo

Ingress: Routing External Traffic Intelligently

Ingress is a Kubernetes API object that manages external HTTP/HTTPS access to services. Unlike NodePort (which exposes on every node), Ingress provides centralized, host-based, and path-based routing.

First, ensure your cluster has an Ingress Controller. Most managed Kubernetes services include one. For local testing with minikube:

minikube addons enable ingress

Create an Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  namespace: networking-demo
spec:
  ingressClassName: nginx
  rules:
  - host: web-app.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80

Apply the Ingress:

kubectl apply -f ingress.yaml
kubectl get ingress
kubectl describe ingress web-app-ingress

Advanced Ingress with Path-Based Routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: advanced-ingress
  namespace: networking-demo
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 80
  - host: web.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80

Best Practice: Always define pathType explicitly. Use Prefix for most cases (matches /path and /path/anything), and Exact only when you need strict matching.

Network Policies: Enforcing Security Boundaries

Network Policies define rules for pod-to-pod communication. By default, Kubernetes allows all traffic (absent policy = allow all). Network Policies change this to a deny-by-default model.

Important: Network Policies only work if your cluster uses a network plugin that supports them (Calico, Weave, Cilium). They don't work with kubenet.

Create a deny-all default policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: networking-demo
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

This blocks all incoming and outgoing traffic. Now allow specific traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-app
  namespace: networking-demo
spec:
  podSelector:
    matchLabels:
      app: web-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

This allows pods with label app: frontend to reach pods labeled app: web-app on port 80.

Allow DNS egress (critical!):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: networking-demo
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53
  - to:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 80

Test policies with kubectl:

kubectl apply -f network-policies.yaml
kubectl get networkpolicies
kubectl describe networkpolicy allow-web-app

Exam Tips for Certified Kubernetes Administrator (CKA)

Key Concepts Tested:

• Service discovery via DNS (format: service-name.namespace.svc.cluster.local)
• Service selector matching with deployment labels
• Port vs targetPort vs nodePort distinctions
• Ingress path matching (Prefix vs Exact)
• Network Policy selector logic (AND/OR behavior)
• Troubleshooting with kubectl logs, describe, exec

Common Exam Scenarios:

1. Pod won't reach service: Check selectors match, endpoints are populated, and networkpolicies don't block it
2. Service accessible inside cluster but not external: You likely need NodePort or Ingress, not ClusterIP
3. Traffic blocked after network policies: Remember DNS (port 53 UDP) must be allowed, and all rules must explicitly permit traffic

Quick Reference Commands:

kubectl get svc,ingress,networkpolicies -A
kubectl describe svc SERVICE_NAME
kubectl get endpoints SERVICE_NAME
kubectl logs -f DEPLOYMENT_NAME
kubectl exec -it POD_NAME -- sh
kubectl port-forward svc/SERVICE_NAME 8080:80
kubectl top nodes
kubectl api-resources | grep -i network

Summary

Key Takeaways:

• Services abstract pod networking and provide reliable endpoints; choose the type based on access scope (ClusterIP, NodePort, LoadBalancer)
• Ingress centralizes external traffic management with host and path-based routing; requires an Ingress Controller
• Network Policies enforce Zero Trust networking; remember the default is allow-all unless policies are applied
• Always test connectivity with kubectl exec and nslookup from inside pods
• Label selectors are the foundation—they must match exactly between workloads and network objects

Next Steps:

• Experiment with service discovery DNS in your cluster
• Deploy multiple Ingress rules with different hosts and paths
• Design a zero-trust network policy architecture for your workloads
• Practice troubleshooting connectivity issues under time constraints
• Review the official Kubernetes networking documentation and practice exam questions

Master these three networking pillars and you'll be well-prepared for the CKA exam's networking domains. Focus on hands-on practice—the exam is practical, and your ability to quickly diagnose and fix connectivity issues is what counts.