Q294: Kubernetes for Frontend Systems Ingress Scaling and Operability

What Interviewers Want To Evaluate

Interviewers want to know whether you can reason about Kubernetes without turning a frontend interview into infrastructure trivia.

They are checking pods, deployments, services, ingress, config, scaling, rollout behavior, health checks, observability, and when Kubernetes is unnecessary for frontend delivery.

Short Interview Answer

Kubernetes orchestrates containers across a cluster. For frontend systems, it is useful when the app runs server-side code, backend-for-frontend APIs, SSR services, internal tools, or multiple independently scaled services. A good design covers deployments, services, ingress, readiness and liveness probes, config maps, secrets, autoscaling, resource limits, rollout strategy, observability, and rollback. Static-only sites often do not need Kubernetes; CDN/object storage hosting can be simpler and faster.

Detailed Interview Answer

Kubernetes is a platform for running containers.

It manages:

scheduling
replication
service discovery
rollouts
health checks
scaling
configuration
secrets
networking
resource limits

For frontend architecture, the first question is whether the frontend actually needs it.

When Kubernetes Helps

Kubernetes can help when the frontend includes:

SSR app servers
backend-for-frontend services
API aggregation layers
internal admin tools
real-time gateways
PDF generation workers
image transformation services
multi-tenant routing

It is less compelling for a purely static site.

Static assets usually perform better and cost less through CDN and object storage.

Core Objects

Important Kubernetes objects:

Pod -> one or more containers
Deployment -> desired replica set and rollout
Service -> stable internal network identity
Ingress -> external HTTP routing
ConfigMap -> non-secret config
Secret -> sensitive config
HorizontalPodAutoscaler -> scale based on metrics
Namespace -> isolation boundary

You do not need to recite every object.

You need to explain how they support the product.

Deployment

A Deployment says:

run this image
keep this many replicas
roll out changes safely
replace unhealthy pods

For a frontend SSR service, replicas allow traffic to continue when one pod restarts.

Readiness and Liveness

Readiness answers:

Should this pod receive traffic?

Liveness answers:

Should this pod be restarted?

They should not be the same by accident.

A pod may be alive but not ready because it is warming caches, loading config, or unable to reach a dependency.

Ingress

Ingress routes external requests into services.

It may handle:

host routing
path routing
TLS
rate limiting through controller integrations
request size limits
basic redirects

For frontend apps, ingress must support route behavior correctly.

Examples:

/ -> web app
/api -> BFF
/assets -> CDN or static service
/health -> health endpoint

Scaling

Scaling can be horizontal or vertical.

Horizontal means more replicas.

Vertical means more CPU or memory per replica.

Autoscaling signals might include:

CPU
memory
request rate
latency
queue depth
custom business metrics

CPU alone may not represent frontend server pressure well.

SSR latency, event loop lag, and upstream API latency can matter more.

Resource Limits

Pods should define requests and limits.

Requests help the scheduler place workloads.

Limits prevent one workload from consuming the node.

Bad limits can cause:

OOM kills
throttling
slow SSR
flaky builds
unpredictable latency

Config and Secrets

ConfigMaps store non-secret configuration.

Secrets store sensitive values, though external secret managers are often used in production.

Frontend caution:

server-only secrets can exist in the pod
browser-exposed variables are still public

Kubernetes does not make client-side secrets safe.

Rollouts and Rollbacks

Kubernetes supports rolling updates.

During rollout, old and new pods may run at the same time.

Therefore APIs, cache schemas, and local client state should be compatible during the transition.

Rollback should consider:

image version
config version
database migrations
CDN assets
feature flags

Observability

A Kubernetes frontend service should expose:

structured logs
request metrics
error metrics
latency histograms
readiness status
deployment version
pod restart counts
resource usage
traces across BFF and upstream APIs

Without observability, Kubernetes adds complexity without clarity.

Interview Framing

Say:

I would only use Kubernetes if the frontend has server-side runtime needs or multiple services that benefit from orchestration. A static-only app belongs closer to CDN and object storage.

Then add:

For an SSR frontend service, I would define deployments, services, ingress, health probes, config, secrets, resource limits, autoscaling, observability, and rollback.

Common Mistakes

• Using Kubernetes for a static site without a reason.
• Forgetting readiness checks.
• Letting pods receive traffic before warmup.
• Storing browser secrets in Kubernetes and assuming they are safe.
• Scaling only on CPU when latency is the real issue.
• Ignoring old/new pod compatibility during rollout.
• Missing logs, traces, and release identifiers.

Learning Studio Example

Learning Studio might use Kubernetes if it grows into:

web SSR service
code execution sandbox service
PDF worker service
search indexing worker
collaboration gateway
admin API

Each service could scale separately.

But the current static-heavy handbook is simpler on Vercel or CDN-first hosting.

Final Mental Model

Kubernetes is useful when there is something meaningful to orchestrate.

For frontend systems, ask:

Do we need long-running containers, service discovery, autoscaling, rollout control, and operational isolation?

If yes, design the platform carefully.

If no, choose the simpler hosting path.