15 questions found
How do Kubernetes ConfigMaps and Secrets differ, and how are they typically consumed by a Node.js pod?
Intermediate
A ConfigMap stores non-sensitive configuration data (feature flags, non-secret URLs) as key-value pairs that can be injected into a pod as environment variables or mounted files. A Secret stores similar key-value data but intended for sensitive values (passwords, API keys), base64-encoded (not encrypted by default, though can be encrypted at rest with additional configuration) and with tighter default access controls -- both are typically consumed by a Node.js application identically, simply as environment variables, regardless of which Kubernetes object supplied them.
# Deployment spec referencing both
env:
- name: FEATURE_FLAG
valueFrom: { configMapKeyRef: { name: app-config, key: featureFlag } }
- name: DATABASE_PASSWORD
valueFrom: { secretKeyRef: { name: app-secrets, key: dbPassword } }
Real-world example
A Node.js deployment loads its non-sensitive log level and feature flags from a ConfigMap while loading its database password and API keys from a Secret, both surfaced identically to the application as regular environment variables, keeping the Node.js code itself agnostic to which mechanism supplied each value.
Common follow-ups: Why is Kubernetes Secret's default base64 encoding not the same thing as actual encryption?;How would you configure encryption at rest for Kubernetes Secrets in a production cluster?
Environment Variables & Configuration;Security
What is a Kubernetes Deployment's rolling update strategy, and how does it apply to updating a running Node.js application?
Advanced
A rolling update incrementally replaces old pod instances with new ones, controlled by maxUnavailable (how many pods can be down simultaneously during the rollout) and maxSurge (how many extra pods above the desired count can be created temporarily) -- this ensures the application remains available throughout the deployment, with Kubernetes automatically pausing the rollout if new pods fail their readiness probe, preventing a broken new version from fully replacing a working old one.
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
replicas: 5
Real-world example
A five-replica Node.js deployment configured with maxUnavailable: 1 and maxSurge: 1 rolls out a new version one pod at a time, always keeping at least four healthy pods serving traffic, and automatically halting the rollout if the new pods start failing their readiness checks.
Common follow-ups: What happens to a rolling update if the new version's pods never become ready -- does it eventually roll back automatically?;How do maxUnavailable and maxSurge together affect both deployment speed and availability during the rollout?
Cloud & DevOps;Deployment & Process Managers (PM2)
What is the purpose of setting explicit CPU and memory resource requests and limits for a Node.js container in Kubernetes?
Intermediate
A resource request tells Kubernetes the minimum CPU/memory a container needs, used for scheduling decisions (placing the pod only on a node with enough available capacity); a limit caps the maximum a container can consume, with Kubernetes throttling CPU usage above the limit or killing (OOMKilling) the container if it exceeds its memory limit -- setting these appropriately prevents one misbehaving pod from starving others on the same node, and prevents a memory leak from silently degrading the entire node.
resources:
requests:
memory: '256Mi'
cpu: '250m'
limits:
memory: '512Mi'
cpu: '500m'
Real-world example
A team without resource limits on their Node.js pods experienced a memory leak in one service gradually consuming all available memory on a shared node, starving unrelated pods; adding a memory limit ensures that specific pod gets OOMKilled and restarted long before it can impact its neighbors.
Common follow-ups: How do you determine appropriate request and limit values without either wasting capacity or risking throttling/OOMKills under normal load?;What's the difference in behavior between exceeding a CPU limit versus exceeding a memory limit?
Performance Optimization & Profiling;Debugging & Diagnostics
How do you handle running database migrations as part of a Kubernetes-based Node.js deployment pipeline?
Advanced
Running migrations requires care in an environment with multiple replicas, since running the same migration concurrently from every new pod could cause conflicts or duplicate work -- a common pattern uses a Kubernetes Job (a separate, one-off pod that runs to completion rather than staying alive) to run migrations exactly once as a distinct pre-deployment step, only proceeding to roll out the new application pods after the migration Job completes successfully.
apiVersion: batch/v1
kind: Job
metadata: { name: db-migrate }
spec:
template:
spec:
containers:
- name: migrate
image: myapp:v1.2.3
command: ['npm', 'run', 'migrate']
restartPolicy: Never
Real-world example
A CI/CD pipeline runs a Kubernetes Job to apply pending database migrations and waits for it to report success before triggering the actual rolling update of the application deployment, ensuring the new code never runs against a database schema it doesn't yet expect.
Common follow-ups: What happens if the migration Job fails -- how should the pipeline handle that before proceeding with the application deployment?;How do you handle a migration that must remain backward-compatible with the still-running old version of the application during a rolling update?
CI/CD
Publishing & Deployment;Git & Project Management
What does the EXPOSE instruction in a Dockerfile actually do, and what is a common misconception about it?
Beginner
EXPOSE is purely documentation -- it declares which port(s) the containerized application listens on, informing anyone reading the Dockerfile or using tools that introspect it, but it does not actually publish or open that port to the host machine; a common misconception is that EXPOSE alone makes a service reachable, when actually the '-p' flag on 'docker run' (or the 'ports' section in Docker Compose) is what performs the actual port mapping to the host.
# Documents that the app listens on 3000, but doesn't publish it
EXPOSE 3000
# Actual port mapping happens at run time
# docker run -p 3000:3000 myapp
Real-world example
A developer confused why they couldn't reach their containerized app despite an EXPOSE 3000 line in the Dockerfile discovers they'd forgotten to add the corresponding '-p 3000:3000' flag to their 'docker run' command, which is the step that actually maps the container's port to the host.
Common follow-ups: Why does Docker Compose's 'ports' mapping still require the corresponding EXPOSE to be meaningful, or does it?;What's the difference between EXPOSE and actually publishing a port for inter-container communication within the same Docker network?
HTTP & HTTPS Modules;Cloud & DevOps