A Namespace is a virtual cluster within a Kubernetes cluster. It provides an isolated scope for resource names — two teams can each have a payment-service Deployment without conflicting, as long as they live in different namespaces. Namespaces are the primary way to organise resources by team, application, or environment (e.g., payments-dev, payments-prod). They also act as the boundary for RBAC permissions and resource quotas.

Labels are arbitrary key-value pairs attached to any Kubernetes object. They are not just metadata — Kubernetes uses them actively: a Service finds the pods it should route to by matching labels, an HPA targets a Deployment by label, and kubectl get pods -l app=payment-service filters by label. Consistent labelling across all your manifests is essential for manageability.

A Deployment is the standard Kubernetes resource for running a stateless application. You describe the desired state — which container image to run, how many replicas to keep alive, what environment variables and resource limits to apply — and Kubernetes continuously reconciles the actual cluster state to match it. If a pod crashes or a node goes down, the Deployment controller automatically schedules a replacement. The manifest below shows a production-ready setup with JVM container-aware flags, health probes, and topology spread to distribute pods across nodes for high availability.

Correctly sizing resource requests and limits is critical for reliable scheduling and avoiding OOMKilled pods.

Pods are ephemeral — they are created and destroyed constantly, and each gets a different IP address every time. A Service sits in front of your pods and gives your application a stable, permanent DNS name and IP address that other services (or external clients) can rely on regardless of how many times pods have been restarted or rescheduled.

Kubernetes offers several Service types. The two most common are:

• ClusterIP (the default) — exposes the Service on an internal cluster IP. Reachable only from within the cluster. Use this for service-to-service communication.
• LoadBalancer — provisions an external load balancer from the cloud provider (AWS ELB, GCP LB, Azure LB). Gives the Service a public IP. Use sparingly — each LoadBalancer costs money and consumes a public IP. Prefer a single Ingress instead (see the next section).

An Ingress is a Kubernetes resource that manages external HTTP and HTTPS traffic into your cluster. The key advantage over a LoadBalancer Service is that a single Ingress can route traffic to many backend services using host-based or path-based rules — api.example.com/payments goes to the payment service, api.example.com/orders goes to the order service — all through one external IP address, which is significantly cheaper and simpler to manage at scale.

An Ingress Controller (a separate pod running in the cluster, commonly nginx-ingress or Traefik) watches for Ingress resources and configures the actual reverse proxy. The example below uses cert-manager to automatically provision and renew a TLS certificate from Let's Encrypt.

Kubernetes performs a rolling update by default when you change a Deployment's image or configuration. Rather than stopping all old pods and starting new ones simultaneously (which causes downtime), it gradually replaces them — starting new pods, waiting for them to pass the readiness probe, then terminating old ones. The result is a zero-downtime deployment.

Two settings control the pace: maxSurge — how many extra pods are allowed above the desired count during the update — and maxUnavailable — how many pods can be unavailable. Setting maxUnavailable: 0 means capacity never drops below the desired replica count, which is the safest choice for production. If anything goes wrong, a single kubectl rollout undo reverts to the previous working version within seconds.

The HorizontalPodAutoscaler (HPA) watches your Deployment's resource utilisation and automatically adjusts the replica count to match demand. When traffic spikes and average CPU climbs above your threshold, the HPA adds pods to spread the load. When traffic drops, it removes pods to reduce cost. This removes the need to manually scale and ensures your application is always right-sized.

The behavior block is important for production: scaleUp.stabilizationWindowSeconds prevents the HPA from adding pods too eagerly in response to a momentary spike, and scaleDown.stabilizationWindowSeconds prevents it from removing pods too quickly after a burst — giving traffic time to settle before cutting capacity.

kubectl is the command-line tool for interacting with a Kubernetes cluster. The commands below cover the most common day-to-day operations you'll use when deploying, inspecting, and debugging your Spring Boot application — from applying manifests and watching rollouts to tailing logs and opening a shell inside a running pod.