Kubernetes in Depth: Networking, Storage, and Deployment Strategies

The networking, storage, deployment strategies, and access control needed to run Kubernetes in production.

The basic Kubernetes objects (Pod, Deployment, Service) do not cover production requirements on their own. Running a stable cluster requires the advanced features that operations depends on: external traffic routing, network policy, storage management, and security configuration.

Networking and services

Service types

Type	Access scope	Use case
ClusterIP	Inside the cluster	Communication between microservices
NodePort	Node IP and port	Development and test environments
LoadBalancer	External load balancer	External exposure in production

Ingress

Defines routing rules for HTTP and HTTPS traffic.

yaml

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

Ingress controllers: Nginx, HAProxy, Traefik, Istio Gateway, and others

Namespace

Logically partitions the cluster to isolate and manage resources.

bash

kubectl create namespace dev
kubectl create namespace prod

NetworkPolicy

Gives fine-grained control over traffic flow between Pods.

podSelector picks the Pods the policy applies to, and ingress.from specifies the sources allowed to send traffic into them. The example below restricts Pods labeled app: backend to inbound traffic from Pods labeled app: frontend only.

yaml

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

Storage

Volume versus PV versus PVC

Concept	Description
Volume	A mount directory inside a Pod (emptyDir, hostPath, and so on)
PersistentVolume (PV)	A cluster-level storage resource
PersistentVolumeClaim (PVC)	A Pod's request for storage

PV/PVC example

yaml

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/my-pv
 
---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

ConfigMap and Secret

yaml

# ConfigMap - ordinary configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db:5432"
  LOG_LEVEL: "info"
 
---
# Secret - sensitive data
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64 encoded

Deployment strategies

Rolling update (the default)

maxSurge is the number of Pods that may run beyond the target replica count, and maxUnavailable is the number of Pods that may be down simultaneously during the update. Setting maxUnavailable: 0 as below takes old Pods down only after new ones are ready, so available capacity never drops.

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # extra Pods allowed
      maxUnavailable: 0  # Pods allowed down at once

bash

# deploy
kubectl apply -f deployment.yaml
 
# roll back
kubectl rollout undo deployment my-deployment
 
# check history
kubectl rollout history deployment my-deployment

Canary deployment

Expose only part of the traffic (5 to 10%) to the new version, confirm stability, then expand gradually

yaml

# v1: 9 replicas
# v2: 1 replica (roughly 10% of traffic)

A Service balances load across endpoints, so the replica ratio is only an approximation of traffic distribution. Precise weight control requires Ingress weights or a service mesh such as Istio.

Blue/green deployment

Run two environments (blue and green) side by side and switch traffic in one step

bash

# Blue environment is serving
# Deploy and test the new version in the Green environment
# Point the Service selector at Green

StatefulSet

For deploying stateful applications such as databases and caches

Assigns a stable identity to each Pod
Guarantees ordering on creation and deletion
Binds a dedicated PVC per Pod

volumeClaimTemplates is a template that creates a separate PVC for each replica, giving every Pod its own persistent storage.

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    # ...
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Security and access control

RBAC (role-based access control)

RBAC controls which users or service accounts may perform which actions on which resources.

yaml

# Role - permissions within a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
---
# RoleBinding - binds the Role to a user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: developer
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole versus Role

Kind	Scope
Role	Within a specific namespace
ClusterRole	Across the whole cluster

Security context

Security settings at the Pod and container level

yaml

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Summary

Topic	Key points
Networking	Service, Ingress, NetworkPolicy
Storage	PV/PVC, ConfigMap, Secret
Deployment	Rolling, canary, blue/green, StatefulSet
Security	RBAC, security context

Operating Kubernetes comes down to declarative configuration and automation. Define the desired state in a YAML manifest, and a controller detects the gap against the current state and reconciles it automatically. Networking, storage, deployment, and access control all follow that same declarative model.