Validate Multi-Container Pod Values

Multi-Container Pod Configuration

Helm charts that deploy pods with multiple containers (sidecars, init containers) have more complex values structures. Each container typically needs its own image and resource configuration.

Common Pattern

image:
  repository: my-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent

sidecar:
  enabled: true
  image:
    repository: envoyproxy/envoy
    tag: "v1.28.0"
    pullPolicy: IfNotPresent
  resources:
    limits:
      cpu: 200m
      memory: 256Mi
    requests:
      cpu: 100m
      memory: 128Mi

initContainers:
  - name: wait-for-db
    image:
      repository: busybox
      tag: "1.36"
    command: ['sh', '-c', 'until nc -z db 5432; do sleep 1; done']
    resources:
      limits:
        cpu: 50m
        memory: 64Mi
      requests:
        cpu: 25m
        memory: 32Mi

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

Validation Points

1. Main container resources: The top-level resources section applies to the main application container
2. Sidecar resources: Each sidecar should have its own resources section; missing resources on sidecars can cause node overcommitment
3. Image configurations: Each container's image should follow the same conventions (repository, tag, pullPolicy)
4. Total resource budget: The sum of all container resources should be reasonable for a single pod

Sidecar Patterns

Pattern	Use Case	Example
Envoy/Istio proxy	Service mesh	envoyproxy/envoy
Log collector	Centralized logging	fluent/fluent-bit
Metrics exporter	Monitoring	prom/statsd-exporter
Cloud SQL proxy	Database access	gcr.io/cloud-sql-connectors/cloud-sql-proxy

Best Practices

• Always define resources for sidecar containers to prevent unbounded resource usage
• Use initContainers for one-time setup tasks (database migration, config fetching)
• Keep sidecar resource requests modest; they share the pod's resource budget