Configuration as code represents system configuration in files managed like source code. For Kubernetes, declarative YAML makes deployments repeatable, reviewable, and easier to reproduce across staging and production. section 11.0 section 11.5
Apply the practice by:
- Storing Kubernetes object definitions in Git rather than changing the live cluster directly. section 11.2 section 11.5
- Reviewing configuration changes like code changes, helping catch operational mistakes before rollout and enabling history inspection or rollback. section 11.2
- Organizing files by namespace or environment so similar staging and production systems can be maintained and reproduced. section 11.0 section 11.2
- Automating rollout with a deployment pipeline or continuous reconciliation, while keeping sensitive values in restricted Kubernetes Secrets. section 11.5
A maintenance task as configuration
Instead of running python3 add_tasks.py with kubectl exec inside an existing Pod, define a Kubernetes Job. The Job creates its own Pod, resource allocation, environment variables, retry limit, and completion status, making the task repeatable and suitable for review and rollout through Git. section 10.2.1
Listing 10.9 Chapter10/10.2.1_Job/job_addwork.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: addwork
spec:
backoffLimit: 2
template:
spec:
containers:
- name: pi-container
image: docker.io/wdenniss/pi_worker:2 #1
command: ["python3", "add_tasks.py"] #2
env:
- name: REDIS_HOST
value: redis-0.redis-service
- name: PYTHONUNBUFFERED
value: "1"
restartPolicy: Never
Inspect a complete Job manifest showing the image, command, environment variables, retry limit, and non-restarting completion policy. section 10.2.1
