Cloud Container Orchestration

Cloud container orchestration is the automation of deploying, scaling, and managing containerized applications across clusters of compute resources. This becomes essential when applications require dynamic resource allocation, service discovery, rolling updates, or self-healing capabilities beyond simple container deployment.

Deploying Applications

Deploy a new application by creating a deployment manifest that defines desired state:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Deploy with kubectl apply -f deployment.yaml. The system will create pods according to the replica count. A deployment without a service definition will not expose the application externally.

Scaling Applications

Scale deployments using the scale subcommand:

kubectl scale deployment web-app --replicas=5

Or update the manifest directly and reapply:

spec:
  replicas: 5

Scaling is asynchronous. A pod may be in "ContainerCreating" state for several minutes while pulling images. The system enforces resource limits; containers exceeding their CPU or memory limits will be terminated.

Rolling Updates

Update application images with rolling updates:

kubectl set image deployment/web-app web=nginx:1.22

The orchestration system creates new pods with the updated image and terminates old ones gradually. During update, the system maintains availability by ensuring at least one replica is running during each phase.

A failed update may leave pods in "ImagePullBackOff" state. Check pod status with kubectl describe pod <pod-name> to see image pull errors. The rollout can be paused with kubectl rollout pause deployment/web-app and resumed with kubectl rollout resume deployment/web-app.

Managing Services

Expose deployments using services:

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Create a LoadBalancer service for external access:

spec:
  type: LoadBalancer

The orchestration system automatically assigns external IP addresses to LoadBalancer services. Service endpoints are updated automatically when pods come and go.

Resource Management

Define resource requests and limits in pod specifications:

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Misconfigured limits cause containers to be killed with OOMKilled or CPU throttling. Requests determine scheduling decisions; if all nodes lack sufficient resources, pods remain in "Pending" state.

Health Checks

Configure liveness and readiness probes:

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

A pod marked as not ready will not receive traffic from services. Liveness probes restart containers that become unresponsive, while readiness probes prevent traffic from reaching unhealthy instances.

Troubleshooting

Check pod status with kubectl get pods. Pods in "CrashLoopBackOff" state typically have startup failures. Use kubectl logs <pod-name> to view container logs. The system will keep restarting failed containers indefinitely unless configured otherwise.

Inspect node status with kubectl get nodes. Nodes in "NotReady" state may cause pod evictions. Check node conditions with kubectl describe node <node-name>.

Configuration Management

Mount configuration data using ConfigMaps:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.json: |
    {"debug": true, "port": 8080}

Reference in pod spec:

volumeMounts:
- name: config
  mountPath: /etc/app
volumes:
- name: config
  configMap:
    name: app-config

Secrets store sensitive information:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  password: cGFzc3dvcmQ=

Secrets are mounted as volumes or injected as environment variables. The system does not automatically rotate secrets; updates require pod recreation.

Node Scheduling

Control pod placement with node selectors:

spec:
  nodeSelector:
    disktype: ssd

Use taints and tolerations for node affinity:

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

Pods will not schedule on nodes with matching taints unless they have corresponding tolerations. Unschedulable pods show status "Pending" with events indicating why scheduling failed.

Network Policies

Restrict network access using network policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-app-policy
spec:
  podSelector:
    matchLabels:
      app: web-app
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

Network policies are enforced by the container runtime. Misconfigured policies may block all traffic to pods.

Resource Quotas

Limit resource consumption per namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: app-quota
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Exceeding quotas causes new pods to remain in "Pending" state until resources become available.

Backup and Restore

Orchestration systems do not automatically back up cluster state. Use kubectl get all -o yaml to capture current configuration. Store these manifests in version control for disaster recovery.

Common Failures

Silent Resource Exhaustion

Pods may silently stop responding when they exceed memory limits. The system kills containers with OOMKilled status. No automatic restart policy is configured by default; pods must be explicitly configured to restart.

Image Pull Issues

Containers may remain in "ImagePullBackOff" state due to missing or invalid image references. Check registry authentication and image names carefully. The system retries image pulls indefinitely unless the image reference is completely malformed.

Node Failure Impact

Pods on failed nodes will be rescheduled automatically. However, applications without persistent storage may lose state during rescheduling. The orchestration system does not guarantee immediate rescheduling of all pods; it schedules according to available resources and node constraints.

Update Rollback

Rollbacks are not automatic. If an update fails, the system leaves the deployment in a partially updated state. Manual rollback requires specifying the previous revision with kubectl rollout undo deployment/web-app --to-revision=1.

Service Discovery Failure

Services may not route traffic correctly if pod labels don't match selectors. The system does not validate service-to-pod relationships at creation time, leading to runtime failures.

Resource Limit Violations

Pods exceeding CPU limits will be throttled but not killed. Memory limits cause immediate termination with exit code 137. The system does not provide automatic resource autoscaling without explicit configuration.

Configuration Errors

Misconfigured ConfigMaps or Secrets may cause pods to fail at startup. Environment variables from secrets are injected as plain text in pod descriptions, exposing sensitive data in logs unless properly secured.

Network Policy Conflicts

Policies that conflict with each other may cause unpredictable traffic routing. The system applies policies in order; later policies may override earlier ones, but the behavior is not immediately obvious to operators.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.