← All lessons
Platform operations
Advanced
30-50 min

Kubernetes Advanced for Frontend Teams

Learn the production patterns that keep deployments safe, scaling sensible, and debugging fast when real traffic starts hitting your app.

Go beyond the basics and learn how health checks, autoscaling, rollout strategy, permissions, observability, and packaging work together in real clusters.

Why this matters
What you gain from this lesson
Production success is not only about running containers; it is about protecting users from bad deploys, slow startups, and traffic spikes.
A frontend lead who understands platform trade-offs can explain rollout risk, scaling cost, and debugging steps to the rest of the team.
These patterns make your release process calmer, faster to recover, and easier to automate.
At a glance
Lesson map
Focus
Platform operations
Outcome
Better decisions
This lesson is designed to stay readable on mobile: the basics are concise, the takeaways are highlighted, and the visual helps you see how the trade-offs fit together.

Core concepts

Requests, limits, and scheduling shape real performance
Kubernetes places pods using resource requests and enforces limits at runtime, so sizing is both a scheduling decision and a safety decision.

Requests tell the scheduler what the pod needs to run. Limits cap how much it can use. If you under-request CPU or memory, the pod can be placed badly or get squeezed under load. If you over-request, the cluster wastes capacity and scales less efficiently.

Frontend apps can be surprisingly expensive when they server-render, warm caches, or perform heavy data work during startup. That is why requests and limits should be based on real load, not guesses.

  • Set CPU and memory requests so scheduling is predictable.
  • Set limits to protect the node and other workloads.
  • Watch for throttling and OOMKilled pods when the app gets busy.
Health probes and startup behavior protect the user experience
Readiness, liveness, and startup probes each answer a different question about the app.

Readiness means 'should traffic be sent yet?' This is the most important probe during a rollout because it keeps users away from pods that are still warming up or waiting on dependencies. Liveness means 'is this process stuck or broken?' If the answer is no, Kubernetes restarts it. Startup gives slow apps time to boot without being killed too early.

For SSR apps, this matters a lot. If your app needs to compile, hydrate, warm caches, or wait for a downstream service, the readiness gate should reflect that real startup cost.

  • Use readiness to protect traffic.
  • Use liveness to recover from dead or stuck processes.
  • Use startup when boot time is slower than the normal probe window.
Safe rollouts, canary thinking, and rollback discipline
A deployment strategy decides whether a release is boring or stressful.

The default rolling update is often enough, but you still need to know what `maxUnavailable` and `maxSurge` do. If a bad release starts breaking requests, rollback speed matters more than optimism. For higher-risk services, teams often add canary or blue/green patterns so they can observe a change before all traffic moves.

Production readiness is not only about the app being up; it is about the update path being safe enough that the team trusts it. That trust is what lets you ship often.

  • Rolling updates replace pods gradually.
  • Canary releases expose a small slice of traffic first.
  • Blue/green keeps two versions around and switches traffic between them.
  • PodDisruptionBudgets help keep too many pods from disappearing at once.
Scaling, namespaces, and when state changes the design
Most frontend apps stay stateless, but production still needs boundaries, replica strategy, and sometimes special handling for storage.

Horizontal Pod Autoscaling adds or removes replicas when metrics cross thresholds. That is useful for handling traffic spikes without paying for the maximum size all the time. Namespaces then help you keep dev, staging, and prod separated so configuration and access stay sane.

If you truly need persistent storage or stable pod identity, you start looking at PVCs and StatefulSets. For most frontend teams this is not day one knowledge, but it is important to know that stateless apps and stateful workloads are intentionally handled differently.

  • HPA scales replicas based on metrics.
  • Namespaces keep environments and teams separated.
  • Stateless apps are easier to scale; stateful apps need extra care.
Security, observability, and repeatable delivery
A production platform is only as good as your ability to inspect it and limit access to it.

RBAC decides who can do what. Service accounts let workloads act with limited permissions. For debugging, you should know how to check logs, events, and rollout status before you guess. For packaging, Helm and Kustomize help you reuse manifests across environments instead of copying YAML by hand.

The goal is not to memorize every command. The goal is to have a repeatable path from pull request to cluster to rollback, with enough visibility that your team can trust the result.

  • Give people and workloads the minimum permissions they need.
  • Use logs, events, and metrics together when debugging.
  • Use Helm or Kustomize to avoid copy-pasted manifests.
  • Keep environment differences in overlays or values, not in ad hoc edits.

Visual model

Kubernetes advanced: keep production healthyHealth checks, scaling, rollout safety, observability, and permissions work together.Traffic only reaches ready podsReadiness protects users during deploys; liveness restarts broken processes; startup gives slow apps time.Requests, limits, and schedulingKubernetes places pods based on CPU and memory requests, then enforces limits at runtime.If you under-size them, SSR apps can throttle, crash, or get OOMKilled under load.Rollout safetyDeployment strategy, max surge, max unavailable, and fast rollback decide whether a release is boring or painful.For teams, this is where canary and blue/green patterns start to matter.safe updatesHorizontal Pod AutoscalerHPA adds or removes replicas when CPU, memory, or custom metrics cross thresholds.This helps absorb traffic spikes without overprovisioning all the time.scale on demandDebugging and control plane visibilityUse logs, events, describe, and rollout status before you guess.RBAC and namespaces keep access tight while Helm or Kustomize keep environments repeatable.probelogsRBAC

Practical examples

Readiness probe for an SSR frontend app
A readiness probe should only pass when the app can really serve traffic.
Request or current behavior
readinessProbe:
  httpGet:
    path: /api/health
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10
Better response
The pod stays out of service until the app is ready
Lesson: Readiness is a traffic gate, not a restart trigger. It protects users during startup and rollout.
Scale out when traffic rises
HPA can react to live load so you do not have to guess the replica count forever.
Request or current behavior
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 2
  maxReplicas: 8
Better response
Replicas increase when the metric crosses the threshold
Lesson: Autoscaling works best when requests and limits are already set correctly.
Debug a rollout that looks stuck
The fastest path is usually to inspect the rollout, then the pod, then the events.
Request or current behavior
kubectl rollout status deployment/web
kubectl describe pod web-7f9d9
kubectl logs web-7f9d9
Better response
You can usually tell whether the issue is probe failure, image pull, permissions, or app crash
Lesson: When a rollout fails, the symptom is usually visible in events before it is visible in the app.
Separate environments with namespaces and overlays
The same app should behave differently in dev, staging, and prod without manual YAML edits.
Request or current behavior
Namespace: staging
Image: ghcr.io/org/web:1.2.3
Config overlay: staging-values.yaml
Better response
Each environment gets the right domain, config, and access rules
Lesson: Packaging makes the platform repeatable, which makes the team faster and safer.

Common pitfalls

Setting probes too aggressively so healthy pods get killed during slow startups.
Running without resource requests, which makes scheduling and autoscaling unreliable.
Giving people or workloads broad cluster-admin access when they only need a narrow role.
Treating a rollout as complete before the new pods are actually ready.
Copy-pasting YAML between environments instead of using overlays or values.
Forgetting that stateful workloads need storage and identity decisions that stateless frontend apps do not.

Quiz

Quiz 1
What is the difference between readiness and liveness?
Think it through first, then reveal the answer.
Quiz 2
Why are resource requests important?
Think it through first, then reveal the answer.
Quiz 3
What does HPA do?
Think it through first, then reveal the answer.
Quiz 4
Why is RBAC important in a team cluster?
Think it through first, then reveal the answer.
Quiz 5
What should you inspect first when a deployment goes wrong?
Think it through first, then reveal the answer.

Takeaways

Production Kubernetes is about health, safety, and repeatability, not just running more pods.
Probes, resources, and rollout strategy decide how trustworthy your releases feel.
Autoscaling and namespaces make the platform practical as the team and traffic grow.
If you can explain logs, events, and rollouts clearly, you can teach Kubernetes to your teammates.