Kubernetes Fundamentals: Workloads, Networking, and Reliability

A practical introduction to Pods, controllers, Services, probes, resources, safe rollouts, and systematic cluster troubleshooting.

The Kubernetes object model

Kubernetes is a control system for running containerized workloads across a cluster. You declare a desired state through API objects, and controllers continuously compare it with reality and make changes to close the gap.

A Pod is the smallest scheduling unit and contains one or more tightly coupled containers. Pods are disposable, so applications normally use higher-level controllers rather than creating Pods directly.

Deployment manages stateless replicas and rolling updates.
StatefulSet gives stateful replicas stable identities and ordered operations.
DaemonSet runs a Pod on every eligible node.
Job runs work to completion; CronJob starts Jobs on a schedule.

Networking and configuration

A Service gives a changing group of Pods a stable virtual address and DNS name. ClusterIP exposes it within the cluster, while LoadBalancer requests an external load balancer from a supported platform.

ConfigMaps hold non-sensitive configuration and Secrets hold sensitive values, although Secrets must also be protected with encryption, access controls, and careful delivery. Ingress or a Gateway implementation routes external HTTP traffic to Services.

Health checks and resource management

A startup probe protects slow-starting applications from premature restarts.
A readiness probe controls whether a Pod receives Service traffic.
A liveness probe restarts a process that is running but cannot recover.
Resource requests guide scheduling and reserve expected capacity.
Resource limits cap usage, but overly tight memory limits can cause OOM termination.

A failing dependency should usually make a Pod unready, not dead. If liveness depends on an external database, an outage can restart every application Pod without fixing the cause.

Safe deployments and troubleshooting

Use rolling updates with realistic readiness probes and enough spare capacity. Pod disruption budgets protect availability during voluntary maintenance, while horizontal autoscaling changes replica count using observed metrics.

Troubleshoot from the desired state outward: inspect the workload, events, Pod status, logs, resource pressure, Service selectors, and network policy. Avoid changing a running container manually because the controller may replace it.

A basic diagnostic sequence

kubectl get deploy,pods,svc
kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous
kubectl get events --sort-by=.metadata.creationTimestamp

Key Takeaways

Controllers reconcile declared desired state instead of relying on manual server changes.
Services provide stable discovery for disposable Pods.
Readiness, liveness, and startup probes solve different problems.
Requests, limits, rollout settings, and disruption budgets determine production reliability.

Frequently Asked Questions

Is a Pod the same as a container?: No. A Pod wraps one or more containers that share networking and selected storage. Most application Pods contain one main container plus occasional sidecars.
Why is my Service not sending traffic to a Pod?: Check that the Service selector matches the Pod labels, the target port is correct, the Pod is ready, and no network policy blocks the path.
Do I need Kubernetes for every application?: No. A simpler managed platform or container service is often better for small systems. Kubernetes pays off when its scheduling, policy, extensibility, and multi-service operations justify the added complexity.