Introduction
In Kubernetes, pods are the smallest deployable units. However, manually managing pods is impractical. Kubernetes offers controllers like ReplicationControllers, ReplicaSets, DaemonSets, Jobs, and CronJobs to automate pod management. These controllers ensure pods are healthy, scalable, and resilient to failures. Let’s explore each tool and its use cases.
1. Keeping Pods Healthy with Liveness Probes
Kubernetes automatically restarts failed containers, but some failures (e.g., deadlocks) require manual intervention. Liveness probes periodically check container health and restart unhealthy pods.
Types of Liveness Probes:
HTTP GET Probe: Checks if a web server responds (e.g.,
http://:8080/health
).TCP Socket Probe: Tests if a port is open.
Exec Probe: Runs a command inside the container (e.g.,
check_health.sh
).
Example:
A Node.js app crashes after 5 requests. Configure a liveness probe to restart it:
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 15 # Wait 15s before first check
If the app returns HTTP 500 errors, Kubernetes restarts the container.
2. ReplicationControllers and ReplicaSets
ReplicationControllers (Legacy)
ReplicationControllers ensure a specified number of pod replicas run at all times.
Example:
Create a ReplicationController to manage 3 replicas:
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- image: luksa/kubia
name: kubia
If a pod crashes, the controller replaces it.
ReplicaSets (Modern Replacement)
ReplicaSets improve ReplicationControllers with expressive label selectors.
Example:
A ReplicaSet using matchExpressions
:
apiVersion: apps/v1
kind: ReplicaSet
spec:
selector:
matchExpressions:
- key: app
operator: In
values: [kubia]
This selects pods with app=kubia
.
Key Differences:
ReplicaSets support
In
,NotIn
,Exists
, andDoesNotExist
operators.Always prefer ReplicaSets over ReplicationControllers.
3. DaemonSets: One Pod Per Node
DaemonSets ensure every node runs a copy of a pod, which is ideal for system services (e.g., log collectors).
Example:
Deploy an SSD monitor on nodes labeled disk=ssd
:
apiVersion: apps/v1
kind: DaemonSet
spec:
selector:
matchLabels:
app: ssd-monitor
template:
spec:
nodeSelector:
disk: ssd
containers:
- name: main
image: luksa/ssd-monitor
If a node loses the label, the pod is terminated.
4. Jobs: Running Completable Tasks
Jobs manage pods that run until completion (e.g., data export tasks).
Example:
A Job running a 2-minute task:
apiVersion: batch/v1
kind: Job
metadata:
name: batch-job
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: main
image: luksa/batch-job
After completion, the pod stops and isn’t restarted.
Parallel Jobs
Run multiple pods in parallel:
spec:
completions: 5 # Run 5 times
parallelism: 2 # 2 pods at a time
5. CronJobs: Scheduled Tasks
CronJobs run Jobs at specific times, similar to Unix cron.
Example:
Run a Job every 15 minutes:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: batch-job-every-15m
spec:
schedule: "0,15,30,45 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: main
image: luksa/batch-job
Cron Syntax: Minute Hour Day Month Weekday
0 3 * * 0
= Run at 3 AM every Sunday.
Conclusion
Kubernetes controllers automate pod management, reducing manual intervention:
Liveness Probes: Restart unhealthy pods.
ReplicaSets: Maintain pod replicas; replace ReplicationControllers.
DaemonSets: Run one pod per node for system services.
Jobs: Execute completable tasks (e.g., batch processing).
CronJobs: Schedule recurring tasks (e.g., nightly backups).
By leveraging these tools, you ensure applications are resilient, scalable, and efficient—whether running web servers, batch jobs, or node-level utilities. Kubernetes handles the heavy lifting, letting you focus on building robust systems.