Overview
- 1Kubernetes 1.31 (Aug 2024) brings multiple long-awaited features to stable status.
- 2Sidecar Containers (stable): lifecycle-aware init containers that run alongside the main container.
- 3Gateway API (stable): the successor to Ingress — more expressive, extensible routing rules.
- 4In-place Pod resource updates (beta): change CPU/memory limits without pod restart.
- 5Kubernetes is the de facto standard for container orchestration in production.
Key Features in 1.31
Use Cases
- →Running microservices at scale with rolling deployments and auto-scaling
- →Multi-tenant platforms with namespace isolation and RBAC
- →CI/CD pipelines running on ephemeral pods (GitHub Actions self-hosted, Tekton)
- →Stateful applications (databases, message queues) with StatefulSets and PVCs
Kubernetes 1.31 Highlights
- Sidecar Containers: `initContainers` with `restartPolicy: Always` — stays alive for app lifetime
- Gateway API v1 stable: replace Ingress with HTTPRoute + GatewayClass + Gateway
- In-place Pod Resize (beta): `kubectl patch pod --patch '{"spec":{"containers":[{"name":"c","resources":{...}}]}}'`
- PersistentVolume resize: expand PVC `resources.requests.storage` — no pod restart needed
- Custom resource field selectors: `kubectl get myresource --field-selector spec.region=us-east-1`
- AppArmor annotations promoted to official `securityContext.appArmorProfile` field
Core Architecture
- Control plane: kube-apiserver, etcd, kube-scheduler, kube-controller-manager
- Node components: kubelet (pod lifecycle), kube-proxy (iptables/IPVS rules), container runtime
- Pod: smallest deployable unit — one or more containers sharing network namespace and volumes
- Deployment: manages ReplicaSets for rolling updates and rollbacks
- Service: stable DNS name + VIP that load-balances across pod endpoints
- Namespace: virtual cluster for resource isolation, quota, and RBAC scoping
- ConfigMap + Secret: inject configuration and sensitive data into pods
Workloads & Networking
- Deployment: stateless workloads with rolling update strategy and minReadySeconds
- StatefulSet: stable pod identity and ordered scaling/updates for databases
- DaemonSet: run one pod per node — logging agents, monitoring, CNI plugins
- HPA (HorizontalPodAutoscaler): scale replicas on CPU/memory or custom metrics
- KEDA: event-driven autoscaling — scale to zero on queue depth, HTTP RPS, cron
- NetworkPolicy: deny-all default then allow-list rules between pods and namespaces
- Gateway API HTTPRoute: path-based routing, header matching, traffic weighting
Helm & GitOps
- Helm 3: package manager for Kubernetes — charts define templated resource manifests
- ArgoCD: GitOps CD tool — syncs cluster state to a Git repo continuously
- Flux 2: CNCF GitOps toolkit with Kustomize and Helm controller
- Kustomize: overlay-based manifest customisation without templating
- cert-manager: automated TLS certificate issuance via Let's Encrypt and ACME
- External Secrets Operator: sync secrets from AWS Secrets Manager, Vault, Azure Key Vault
- Prometheus + Grafana: monitoring stack; kube-prometheus-stack Helm chart deploys both
Frequently Asked Questions
What is the difference between Deployment and StatefulSet?
Deployment manages stateless pods — all replicas are identical and interchangeable, pods can start/stop in any order. StatefulSet is for stateful workloads like databases — each pod has a stable network identity (pod-0, pod-1), persistent storage bound to that pod identity, and ordered startup/shutdown. Use StatefulSet for databases, ZooKeeper, Kafka, and similar ordered services.
What is the Gateway API and why is it replacing Ingress?
The Gateway API is the successor to Kubernetes Ingress. It separates cluster infrastructure concerns (GatewayClass, Gateway) from application routing (HTTPRoute, GRPCRoute). It supports advanced features like traffic weighting, header-based routing, cross-namespace reference, and TLS passthrough that Ingress could not express. It went stable in Kubernetes 1.31.
What is GitOps and how does ArgoCD implement it?
GitOps is a deployment model where the desired state of your Kubernetes cluster is declared in Git. ArgoCD continuously compares the live cluster state to the Git repo and automatically applies or alerts on drift. Every change goes through Git (PR, review, merge) — no kubectl apply in CI/CD pipelines. This gives you a full audit trail and easy rollback via git revert.