DevOps / Intermediate: controlled delivery systems / Lesson 12
Kubernetes workload and health boundaries
Read the desired-state model and distinguish controller, Pod, container, Service, and probe behavior without operating a cluster.
On this page
Lesson goals
- Distinguish Deployment, Pod, container, and Service evidence.
- Assign separate purposes to startup, readiness, and liveness.
- Review platform resources, identity, and ownership limits.
Understand the object boundaries
Kubernetes reconciles declared objects through controllers and node components. A Deployment manages a desired set of Pods through ReplicaSets; a Pod groups containers sharing selected resources and lifecycle context. A Service selects endpoints and provides a networking abstraction. These are different objects with different failure evidence. Kubernetes does not automatically understand your business transaction or make an application resilient to every dependency failure. The lesson uses stable core concepts and apps/v1 Deployment semantics; feature availability and exact defaults must be checked against the installed server, client, admission policy, and distribution versions.
Separate desired, scheduled, running, and ready
An accepted manifest can remain unscheduled, fail image retrieval, start and crash, or run without becoming ready. CrashLoopBackOff describes repeated container failure with restart backoff rather than a complete root cause. The first synthetic timeline shows why status must be connected to termination reason, events, and safe application logs. Exit information, missing configuration, permissions, and resource pressure can point to different repairs. A Pod phase is a coarse summary; it should not replace detailed container state. Never interpret a running process as proof that the Service has a ready endpoint.
t0: manifest accepted
t1: Pod scheduled
t2: container started
t3: process exited with configuration error
t4: restart backoff displayed
conclusion: inspect the startup error before changing probes
The sequence explains a repeated startup failure. It is not captured cluster output, and CrashLoopBackOff alone does not identify the missing setting or justify a rollback.
Give probes different jobs
A startup probe protects a slow legitimate startup before liveness and readiness begin according to configured behavior. Readiness controls eligibility for new service traffic; liveness can trigger container restart. A readiness failure should not itself be used to restart an otherwise healthy process. The second manifest fragment separates endpoints and deliberately omits the workload wrapper, so it is non-runnable. Probe thresholds and timing need measured startup and failure behavior. A liveness endpoint that depends on a shared database can restart every instance during a database incident and make recovery harder.
startupProbe:
httpGet: {path: /startup, port: 8080}
periodSeconds: 5
failureThreshold: 24
readinessProbe:
httpGet: {path: /ready, port: 8080}
periodSeconds: 5
livenessProbe:
httpGet: {path: /live, port: 8080}
periodSeconds: 10
The fragment belongs inside a container specification. Its illustrative startup allowance is about 120 seconds, subject to probe execution and timing; it is not a universal safe setting or a complete manifest.
Review storage, resources, and access
Requests influence scheduling while limits constrain runtime resource usage according to resource and platform behavior. Memory pressure and CPU throttling require different investigation. PersistentVolume claims, configuration references, service accounts, network policy, and security context add boundaries beyond an image. Do not copy a privileged manifest merely to bypass a permission error. Verify the intended namespace and ownership before reading diagnostic data, because logs and object descriptions can contain sensitive information. Avoid printing Secret values; references, version identifiers, and missing-key names usually provide safer initial evidence.
Choose Kubernetes only with ownership
An orchestrator adds controllers, policies, upgrades, networking, storage integration, and operational expertise requirements. A simpler service platform can be appropriate when the workload does not need those capabilities. If Kubernetes is selected, define responsibility for cluster lifecycle separately from application release responsibility, while keeping escalation clear. Rehearse graceful termination, disruption, and mixed-version behavior in an authorized isolated environment. Record which guarantees the platform supplies and which remain application obligations, such as idempotency and data consistency. No kubectl command, cluster connection, manifest application, or service restart is performed by this course.
Common errors and fixes
A readiness failure triggers needless restarts
- Why it happens
- Health endpoints mixed admission and restart semantics.
- How to fix it
- Separate readiness from liveness and measure startup.
- Prevent it next time
- Test dependency outages without restart storms.
CrashLoopBackOff is treated as the cause
- Why it happens
- A backoff symptom replaced termination evidence.
- How to fix it
- Inspect safe startup logs, termination reason, and recent changes.
- Prevent it next time
- Preserve first-failure evidence before repeated replacement.
A manifest works only with broad privilege
- Why it happens
- File, identity, or platform assumptions were unexamined.
- How to fix it
- Correct the narrow access contract rather than disabling boundaries.
- Prevent it next time
- Review security context and required permissions together.
Check your understanding
1. The Deployment is accepted but no Pod is ready. What evidence chain is needed?
Show worked solution
Inspect controller progress, scheduling and image events, container startup and termination, then readiness and Service endpoint selection. Keep namespace and revision fixed. This separates admission, placement, execution, and traffic eligibility instead of assuming one successful API request completed the release.
2. A shared database outage makes liveness fail on every instance. What policy change is indicated?
Show worked solution
Make liveness reflect a condition where restarting this process is useful, and put dependency-based admission in bounded readiness logic where appropriate. Rehearse the outage in isolation. Avoid blindly increasing restart frequency or declaring every database wait a dead process.
Key takeaways
- Kubernetes reconciles declared objects through controllers and node components.
- A startup probe protects a slow legitimate startup before liveness and readiness begin according to configured behavior.
- An orchestrator adds controllers, policies, upgrades, networking, storage integration, and operational expertise requirements.