Container Orchestration

---
name: container-orchestration
description: "Container Orchestration automates deploying, scaling, networking, and lifecycle management of containerized apps across clusters; use it to run reliable, scalable services."
metadata:
  tags: "technology-engineering, container-orchestration, devops, kubernetes, rolling-updates, autoscaling, service-discovery"
  source: "https://skilldb.dev/skills/devops-cloud-skills/container-orchestration"
  pack: "devops-cloud-skills"
  category: "Technology & Engineering"
---

# Container Orchestration

## When to use this skill
Use when the user says things like:
- "how do i orchestrate containers at scale"
- "deploy with rolling updates and autoscaling"
- "configure service discovery and load balancing"
- "manage namespaces and resource quotas"
- "set resource requests and limits for pods"


## Core Philosophy
Container orchestration automates the deployment, scaling, networking, and
lifecycle management of containerized applications across clusters of machines.
The core insight is that individual containers are ephemeral and disposable —
orchestration ensures that the desired state of the system (number of replicas,
resource allocation, networking rules) is continuously maintained regardless of
individual container failures.

## Key Techniques
- **Declarative Configuration**: Define the desired state of your application
  (replicas, resources, networking) in manifests. The orchestrator continuously
  reconciles actual state with desired state.
- **Service Discovery and Load Balancing**: Automatically register containers
  as they start and route traffic to healthy instances through internal DNS and
  load balancers.
- **Rolling Updates**: Replace containers incrementally, ensuring zero-downtime
  deployments by maintaining minimum available replicas throughout the process.
- **Horizontal Pod Autoscaling**: Automatically adjust replica counts based on
  CPU, memory, or custom metrics to handle variable traffic loads.
- **Resource Quotas and Limits**: Set CPU and memory requests (guaranteed minimum)
  and limits (hard ceiling) to prevent noisy neighbors and ensure fair scheduling.
- **Namespace Isolation**: Partition cluster resources into logical boundaries
  for teams, environments, or applications with independent access controls.

## Best Practices
- Set resource requests and limits on every container. Without them, scheduling
  is unpredictable and a single pod can starve the node.
- Use liveness and readiness probes to let the orchestrator detect and recover
  from application-level failures automatically.
- Store configuration in ConfigMaps and secrets in Secrets objects, not baked
  into container images.
- Use Helm charts or Kustomize for templating and managing environment-specific
  configuration variations.
- Implement pod disruption budgets to prevent rolling updates from taking down
  too many replicas simultaneously.
- Run stateless workloads whenever possible. Use managed databases and object
  storage rather than persistent volumes for data.
- Monitor cluster health, node utilization, and pod scheduling metrics continuously.

## Common Patterns
- **Sidecar Pattern**: Attach helper containers (logging agents, proxies, config
  reloaders) alongside the main application container in the same pod.
- **Init Containers**: Run setup tasks (database migrations, config fetching)
  before the main application container starts.
- **DaemonSets**: Run exactly one instance of a pod on every node for
  cluster-wide concerns like log collection or monitoring agents.
- **StatefulSets**: Manage stateful applications that need stable network
  identities and persistent storage, like databases and message queues.
- **Job and CronJob**: Run batch processing tasks to completion or on a schedule.

## Anti-Patterns
- Running containers as root. Use non-root users and read-only filesystems
  to minimize the blast radius of container escapes.
- Not setting resource limits, allowing a single misbehaving pod to consume
  all node resources and evict other workloads.
- Using latest tags for container images, making deployments non-reproducible
  and rollbacks impossible.
- Storing persistent state inside containers. When the container restarts,
  the data is gone.
- Overcomplicating with microservices when a simpler architecture would suffice.
  Orchestration complexity should be justified by operational needs.
- Neglecting cluster upgrades. Running outdated orchestrator versions accumulates
  security vulnerabilities and missing features.