Перейти до вмісту
Kubernetes Core • Pod Lifecycle & Health • Networking From DevOps Production & Interview Perspective (6+ years)
Source: Dev.to | Jan 11, 2026 (UTC)
PART 1 — KUBERNETES CORE (WHAT REALLY HAPPENS)
1. What Kubernetes Actually Does (Behavioral View)
Kubernetes is not running containers.
Kubernetes is constantly comparing:
Desired State (YAML)
vs
Current State (Reality)
If they differ → Kubernetes acts.
Example
You say:
replicas: 3
Enter fullscreen mode
Exit fullscreen mode
Reality:
Kubernetes behavior:
- Creates 1 new Pod automatically
DevOps responsibility:
You describe intent, Kubernetes enforces it.
2. Kubernetes Control Loop (THIS IS CORE)
Every controller does this loop:
- Read desired state from API
- Compare with current state
- Take action
- Repeat forever
Why this matters in production
- You do not “fix” pods manually
- You fix YAML
- Kubernetes re-fixes runtime
Interview question:
Why deleting a Pod “fixes” things temporarily?
Answer: Controller recreates it.
3. Core Objects — Real Behavior, Not Definitions
Pod (Runtime Unit)
Behavior
- Gets ONE IP
- Lives on ONE node
- Dies easily
- Never self-heals
DevOps attention
- Pods are disposable
- Never depend on Pod IP
- Never debug by “fixing inside Pod”
Production debugging
kubectl describe pod kubectl logs
Enter fullscreen mode
Exit fullscreen mode
ReplicaSet (Safety Net)
Behavior
- Watches Pods
- Ensures exact count
- Recreates missing Pods
DevOps reality
- You almost never touch it
- It exists to protect you
Production insight
- If Pods keep coming back → ReplicaSet is doing its job
Deployment (CONTROL CENTER)
Behavior
- Owns ReplicaSets
- Manages rollouts
- Controls version changes
DevOps responsibility
- Choose update strategy
- Protect uptime
- Enable rollback
Critical rule
spec.selector is immutable
Why
- Kubernetes must know which Pods belong forever
Production failure
- Wrong selector → Service sends traffic to nothing
Namespace (BOUNDARY)
Behavior
- Logical isolation
- Same cluster, separate worlds
DevOps responsibility
- Separate environments
- Apply RBAC
- Prevent accidental cross-access
Production issue
- Wrong namespace = “nothing works”
4. kubectl — Your Stethoscope
DevOps does NOT guess.
DevOps observes behavior.
Debug order (ALWAYS):
kubectl getkubectl describekubectl logskubectl exec
PART 2 — POD LIFECYCLE & HEALTH (WHERE MOST OUTAGES COME FROM)
1. Pod Lifecycle — Real Meaning
Pending
Means
- Scheduler cannot place Pod
DevOps checks
- Nodes available?
- CPU/memory?
- PVC bound?
Production example
- New deployment stuck
- Cluster is full
Running
Means
- Container started
- DOES NOT mean healthy
Running ≠ Ready
CrashLoopBackOff
Behavior
- App starts
- App crashes
- Kubernetes retries
- Backoff increases
DevOps responsibility
- Identify app error
- NOT Kubernetes bug
Debug
kubectl logs --previous
Enter fullscreen mode
Exit fullscreen mode
2. Init Containers — Dependency Control
Behavior
- Run before main container
- Block startup if failing
DevOps use cases
- DB readiness
- Secrets availability
- Migrations
Production mistake
- App crashes because DB not ready
- Init container would prevent it
3. Probes — TRAFFIC & RECOVERY CONTROL
Liveness Probe
Behavior
- Checks if container should be restarted
- Failure → restart container
DevOps attention
- Do NOT use for dependencies
- Only check if app is stuck
Bad usage
Readiness Probe (MOST IMPORTANT)
Behavior
- Controls traffic
- Failure → removed from Service
DevOps responsibility
- Prevent broken Pods from serving users
Production failure
- No readiness probe → traffic hits half-ready app
Startup Probe
Behavior
- Protects slow apps
- Delays liveness
DevOps use
4. Termination Behavior (ZERO-DOWNTIME)
Sequence
- Pod marked terminating
- Readiness fails
- Traffic stops
- SIGTERM sent
- App shuts down
- Pod deleted
DevOps responsibility
- Ensure app handles SIGTERM
- Ensure readiness probe exists
PART 3 — NETWORKING (THIS IS WHERE SENIORS WIN)
1. Kubernetes Networking Laws
Rules
- Every Pod has unique IP
- No NAT between Pods
- Services are virtual
- DNS always used
2. Service Behavior (NOT JUST TYPES)
ClusterIP
Behavior
- Internal load balancing
- Stable IP
- Maps to Pod endpoints
DevOps attention
- Selector correctness
- Readiness gating
NodePort
Behavior
- Opens port on every node
- Routes to Service
DevOps use
- Debugging
- Labs
- NOT production
LoadBalancer
Behavior
- Cloud LB created
- Forwards to nodes
- Nodes forward to Pods
DevOps responsibility
- Understand cloud integration
- Security groups / firewalls
3. Service → Pod Mapping (COMMON FAILURE)
Behavior
- Service selects Pods by labels
- Builds endpoint list
Failure
- Labels mismatch
- No endpoints
- Traffic black hole
Debug
kubectl get endpoints
Enter fullscreen mode
Exit fullscreen mode
4. DNS — HOW PODS TALK
Behavior
- Pod resolves Service name
- Never Pod IP
DevOps rule
5. Ingress — HTTP CONTROL
Ingress
Ingress Controller
DevOps responsibility
- Controller health
- TLS certs
- Routing rules
6. Network Policies (ADVANCED)
Behavior
- Default allow
- Policy = firewall
DevOps use
- Zero trust
- Compliance
- Isolation
7. Production Debug Flow (REAL)
User reports: “App down”
DevOps steps
- Is Ingress reachable?
- Is Service healthy?
- Are endpoints present?
- Are Pods ready?
- Are probes passing?
- Are logs clean?
WHAT IS DEVOPS ACTUALLY RESPONSIBLE FOR?
NOT
- Writing business logic
- Fixing code bugs
YES
- Platform reliability
- Deployment safety
- Traffic protection
- Recovery automation
- Security boundaries
- Fast debugging
DevOps ensures failures are safe, isolated, and recoverable.
FINAL INTERVIEW TRUTH
A 6-year DevOps Engineer is judged on:
- How they think under failure
- How they protect users
- How they explain system behavior
- How fast they isolate root cause
For further actions, you may consider blocking this person and/or reporting abuse
Залишити відповідь