Container Orchestration
debt(d7/e9/b9/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list tools like kubectl, k9s, helm, terraform — these are operational tools, not automated linters. Detecting misuse (missing resource limits, no network policies, running PHP on self-managed k8s without platform team) requires manual review or runtime incidents. No automated detection is explicitly noted (automated: no).
Closest to 'architectural rework' (e9). The quick_fix suggests moving from self-hosted to managed Kubernetes, which is an infrastructure migration affecting deployment pipelines, networking, secrets management, and operational procedures. Fixing common_mistakes like proper persistent storage, resource limits across all pods, or implementing probes requires cross-cutting changes to all deployment manifests and potentially application code.
Closest to 'defines the system's shape' (b9). Container orchestration is a foundational infrastructure choice that applies to all PHP contexts (web, cli per applies_to). Once adopted, Kubernetes shapes how every service is deployed, scaled, monitored, and networked. Every future maintainer must understand K8s concepts. The choice has maximum gravitational pull — you're either all-in on K8s or migrating away from it.
Closest to 'serious trap' (t7). The misconception explicitly states 'Kubernetes is required for production' — this contradicts how simpler deployment models work elsewhere (managed PaaS, serverless). Developers familiar with traditional hosting or simpler platforms will assume K8s is necessary and adopt it prematurely, adding significant operational complexity when alternatives would serve better.
Also Known As
TL;DR
Explanation
Kubernetes (K8s) manages containerised workloads: Pods (one or more containers), Deployments (desired replica count), Services (stable network endpoint), Ingress (HTTP routing), ConfigMaps/Secrets (configuration), and PersistentVolumes (storage). The control plane schedules and monitors; worker nodes run containers. Key operations: rolling updates, health checks, automatic restarts, horizontal pod autoscaling. For PHP: PHP-FPM runs in containers behind an nginx sidecar, scaled by HPA based on CPU or request rate.
Diagram
flowchart TD
subgraph Kubernetes Cluster
API[API Server]
subgraph Node 1
P1[Pod: PHP-FPM]
P2[Pod: Worker]
end
subgraph Node 2
P3[Pod: PHP-FPM]
P4[Pod: Nginx]
end
end
SVC[Service - stable DNS] --> P1 & P3
ING[Ingress - routes traffic] --> SVC
HPA[HPA - auto-scales pods<br/>on CPU or custom metrics] --> P1 & P3
CM[ConfigMap - env config] -.-> P1 & P2 & P3
SEC[Secret - credentials] -.-> P1 & P2 & P3
style ING fill:#d29922,color:#fff
style HPA fill:#238636,color:#fff
style SVC fill:#1f6feb,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Running a database in Kubernetes without understanding persistent storage — container restarts lose data without PVCs.
- Not setting resource requests and limits — containers without limits steal CPU/memory from neighbours.
- Not implementing readiness and liveness probes — Kubernetes cannot route traffic away from broken pods without them.
- Storing secrets in ConfigMaps — use Kubernetes Secrets or an external secrets manager.
Code Examples
# Deployment without resource limits or health probes:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: php-fpm
image: myapp:latest
# No resources: limits — can consume all node CPU/memory
# No readinessProbe — traffic sent to broken pods
# No livenessProbe — dead pods never restartedspec:
containers:
- name: php-fpm
image: myapp:1.2.3 # Pinned version, not 'latest'
resources:
requests: { cpu: 250m, memory: 256Mi }
limits: { cpu: 500m, memory: 512Mi }
readinessProbe:
httpGet: { path: /health, port: 80 }
initialDelaySeconds: 5
livenessProbe:
httpGet: { path: /ping, port: 80 }
periodSeconds: 10