Kubernetes is a control system, not a magic deployment command. Start with the desired state you declare and the signals the platform uses.
Work through the path
Open a card when you need it. Marking a lesson complete is optional and stays only in this browser.
1Separate Pod, Deployment and Service
A Pod runs containers, a Deployment manages replica rollout and a Service gives clients a stable network identity.
Applications normally declare a Deployment rather than creating Pods directly. The Deployment creates ReplicaSets and replaces Pods when the template changes.
A Service selects Pods by labels and provides a stable endpoint while individual Pods are replaced.
Try it
Change the image tag and observe a new ReplicaSet while the Service remains stable.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-api
spec:
replicas: 2
selector:
matchLabels:
app: orders-api
template:
metadata:
labels:
app: orders-api
spec:
containers:
- name: api
image: registry.example/orders-api:1.0.0
---
apiVersion: v1
kind: Service
metadata:
name: orders-api
spec:
selector:
app: orders-api
ports:
- port: 80
targetPort: 80802Use ConfigMaps and Secrets with clear boundaries
Keep non-secret configuration and sensitive values separate, then inject them into the container at runtime.
A ConfigMap suits non-sensitive settings. A Secret provides a different access model, but base64 in a manifest is encoding, not a complete secrecy strategy.
Limit which service accounts can read secrets and prefer an external secret manager when your platform supports it.
Try it
List which values are safe in a deployment diff and which should only be referenced by name.
env:
- name: ASPNETCORE_ENVIRONMENT
value: Production
- name: ConnectionStrings__Default
valueFrom:
secretKeyRef:
name: orders-db
key: connection-string3Give the scheduler a resource contract
Requests influence placement; limits cap usage. Both need values based on observation rather than copied defaults.
A request tells the scheduler what the container normally needs. A limit constrains how far it can use node resources.
Measure startup, steady-state and burst behavior, then revisit values as the application changes.
Try it
Compare observed memory use with the limit under representative load.
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"4Use probes to describe health, not hope
Readiness controls traffic, liveness detects a stuck process and startup probes protect slow-starting applications.
A readiness failure should remove a Pod from service without necessarily restarting it. A liveness failure is a stronger signal that the process cannot recover.
Probe endpoints should be cheap and intentional. A deep dependency check in liveness can restart every replica when one downstream system is unavailable.
Try it
Decide which dependencies belong in readiness and which should not affect liveness.
startupProbe:
httpGet:
path: /health/startup
port: 8080
failureThreshold: 30
periodSeconds: 2
readinessProbe:
httpGet:
path: /health/ready
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /health/live
port: 8080
periodSeconds: 10No lesson matches that phrase.
Related tools
Turn the concept into a working example with the browser-based tools.