Infrastructure basics

Beginner

25-40 min

Kubernetes Basics for Frontend Engineers

Understand the core objects, the deployment flow, and the minimum commands you need to ship a frontend app with confidence.

Learn what Kubernetes actually does, how a frontend app moves from image to cluster to domain, and which objects matter when you first deploy a real project.

Why this matters

What you gain from this lesson

A frontend engineer who understands Kubernetes can ship staging and production deployments without treating the platform like a black box.

The basic objects map cleanly to real team concerns: uptime, config, routing, and safe updates.

This lesson gives you the vocabulary to discuss deployment problems with backend and platform teammates.

At a glance

Lesson map

Focus

Infrastructure basics

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

The mental model: desired state, not manual server babysitting

Kubernetes is a control loop. You describe the desired state, and the cluster keeps nudging reality back toward that state.

That is why Kubernetes feels different from running a process on one VM. You do not manage one machine; you manage a set of rules. The cluster decides where pods should run, how many should exist, and what to do when one dies.

For a frontend team, this means deployments become repeatable. If the desired state says three replicas of a given image should be available, Kubernetes keeps working until that is true.

Cluster = the whole Kubernetes environment.
Node = a machine that runs workloads.
Pod = the smallest deployable unit, usually one app container.
Deployment = keeps the desired number of pods alive and handles updates.

The core objects you must know first

A good first lesson is not every object in the ecosystem; it is the few objects you will use all the time.

Service gives pods a stable internal address even when individual pods change. Ingress exposes the app to the outside world and routes a domain to the right Service. ConfigMap holds non-secret configuration, while Secret holds sensitive values like tokens and passwords.

You will also see Namespace early. It is a practical way to separate environments, teams, or experiments without mixing everything together.

Service = stable networking for pod-to-pod or app-to-app traffic.
Ingress = public HTTP entry point for a domain.
ConfigMap = environment config that is safe to expose.
Secret = values that must not live in plain text.
Namespace = a logical boundary inside a cluster.

How a frontend app moves through the platform

The deployment flow is easier to understand if you follow one request from build time all the way to the browser.

A CI pipeline builds a container image and pushes it to a registry. A Deployment then references that image and creates pods. A Service gives those pods a stable name inside the cluster, and an Ingress maps a real domain to that Service.

The key lesson is separation of concerns. The image is immutable, the Deployment manages replicas, the Service handles internal traffic, and the Ingress handles public routing.

Build once, deploy many times.
Do not rely on the `latest` tag for production.
Keep the app image reusable across staging and production.

The day-one commands you actually need

When something goes wrong, start with visibility before guessing.

`kubectl get pods` shows status at a glance. `kubectl describe pod` shows events and the reason behind a failure. `kubectl logs` shows app output. `kubectl rollout status` tells you whether a deployment is progressing, and `kubectl rollout undo` gives you a fast rollback path.

If a teammate asks what is broken, these commands are your first-response toolkit. You will look much more senior if you can explain the failure from pod status, events, and logs instead of from intuition alone.

Use `get` to scan the cluster.
Use `describe` when status alone is not enough.
Use `logs` for application behavior.
Use `rollout status` and `rollout undo` for deployment control.

Config and secrets are runtime concerns

A clean Kubernetes setup keeps the image generic and injects environment-specific values at runtime.

This is one of the easiest ways to avoid rebuilds for every environment. Keep public values like API base URLs in a ConfigMap and keep private values in Secrets. That lets the same image run in staging and production with different settings.

For frontend apps, this matters because build-time and runtime configuration are not always the same thing. Decide early which values are baked into the image and which values should be injected when the pod starts.

Use ConfigMap for public runtime settings.
Use Secret for tokens, keys, and passwords.
Do not commit secrets to the repository.

Visual model

Practical examples

Deploy a Next.js app with a Deployment, Service, and Ingress

This is the minimum shape most frontend teams need in a real cluster.

Request or current behavior

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: web
          image: ghcr.io/org/web:1.2.3

Better response

Service + Ingress expose the pods

- Service gives the pods a stable internal name
- Ingress maps app.example.com to that Service
- Deployment keeps replicas alive and rolls out new images

Lesson: The app is not deployed by one object alone; Deployment, Service, and Ingress each solve a different problem.

Change config without rebuilding the image

ConfigMap and Secret let you reuse the same image across environments.

Request or current behavior

envFrom:
  - configMapRef:
      name: web-config
  - secretRef:
      name: web-secrets

Better response

The pod starts with environment-specific values injected at runtime

Lesson: If the image is generic, you can keep releases small and move environment differences out of the build.

Inspect a failing pod before guessing

The fastest path to a root cause is usually events + logs.

Request or current behavior

kubectl get pods
kubectl describe pod web-7f9d9
kubectl logs web-7f9d9

Better response

You can usually tell whether the failure is image, config, permissions, or app code

Lesson: Status tells you where to look; describe and logs tell you why it failed.

Common pitfalls

Thinking a Pod is the same thing as a container; a Pod is the unit Kubernetes schedules, and it can contain more than one container.

Using the `latest` image tag in production, which makes rollbacks and debugging much harder.

Putting secrets into plain ConfigMaps or into the git repository.

Exposing everything directly without a Service or Ingress plan.

Assuming running a pod means the app is ready to serve traffic immediately.

Treating Kubernetes as a deployment shortcut instead of an operating model with rules and lifecycle.