DevOps Kubernetes Networking and Storage

Pods in Kubernetes start, stop, and move all the time. Each change alters the pod address and can wipe the pod disk. Kubernetes solves both problems with stable network names and with storage that outlives a pod. Services, Ingress, and network policies handle traffic. Volumes and claims handle data.

The Apartment Building Example

Think of an apartment building where tenants move in and out. Visitors do not memorize tenant room numbers. They call the reception desk, and the desk connects them to whoever lives there now. A Kubernetes Service acts as that reception desk. The pods are the tenants. Storage works like a rented storage unit in the basement, which keeps belongings safe when a tenant leaves.

Pod Networking Basics

Every pod receives its own IP address. Any pod can reach any other pod in the cluster without extra address translation. These addresses change when a pod restarts, so applications should never depend on them directly.

Services

A Service gives a group of pods one stable name and address. The Service finds its pods by matching labels and shares traffic among them.

 Client --> Service "shop-svc" (stable IP + DNS name)
                |-----> Pod shop-1 (label app=shop)
                |-----> Pod shop-2 (label app=shop)
                +-----> Pod shop-3 (label app=shop)
apiVersion: v1
kind: Service
metadata:
  name: shop-svc
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8080
Service TypeWho Can Reach ItTypical Use
ClusterIPOnly pods inside the clusterInternal APIs and databases
NodePortOutside users through a port on every nodeSimple tests
LoadBalancerOutside users through a cloud load balancerPublic web applications

Cluster DNS

Kubernetes runs a built-in DNS service. A pod reaches the Service above by the name shop-svc inside the same namespace. The full name shop-svc.default.svc.cluster.local works from any namespace. Applications use names, and Kubernetes handles the addresses.

Ingress

A LoadBalancer for every Service costs money and clutters the setup. Ingress offers one entry point that routes web traffic to many Services by host name or path. An Ingress controller, such as the Nginx Ingress Controller, performs the routing.

                          /shop  --> shop-svc
 Internet --> Ingress --- /blog  --> blog-svc
                          /api   --> api-svc
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: shop-svc
                port:
                  number: 80

Network Policies

All pods talk to each other by default. A network policy restricts that freedom, much like a firewall rule. The policy below lets only pods labeled app=api reach the database pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api

The network plugin in the cluster must support policies. Calico and Cilium both do.

Storage: Volumes, Claims, and Classes

Data inside a container disappears when the pod dies. Kubernetes separates storage into three objects:

  • PersistentVolume (PV): a piece of real storage, such as a cloud disk.
  • PersistentVolumeClaim (PVC): a request for storage by an application.
  • StorageClass: a recipe that creates volumes on demand.
 Pod --uses--> PVC "data-claim" --binds--> PV (cloud disk)
                    ^
              StorageClass creates the disk when the claim appears
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi

The access mode ReadWriteOnce lets one node mount the disk for reading and writing. The mode ReadWriteMany lets many nodes share it and needs a file-based storage system.

StatefulSets for Databases

A StatefulSet runs pods that need stable names and their own disks. Pods receive names such as db-0, db-1, and db-2. Each pod keeps its claim after a restart, so a database finds its data again.

ConfigMaps and Secrets as Volumes

A ConfigMap stores plain settings, and a Secret stores sensitive values. Pods read them as environment variables or as files mounted into the container. Changing a mounted ConfigMap updates the file without rebuilding the image.

Debugging Commands

CommandPurpose
kubectl get svcList services and addresses
kubectl get endpoints shop-svcShow the pods behind a service
kubectl describe ingress siteCheck routing rules
kubectl get pvcCheck claim status
kubectl exec -it pod -- nslookup shop-svcTest cluster DNS

Key Points

  • Services give pods a stable name and address.
  • Ingress routes web traffic from one entry point to many Services.
  • Network policies limit which pods may talk.
  • Persistent volume claims keep data safe across pod restarts.

Leave a Comment

Your email address will not be published. Required fields are marked *