Kubernetes Runtime Dependencies

Runtime dependencies are the resources and configurations that Pods need to function correctly. Kubernetes provides specific primitives for declaring these dependencies, making them explicit and manageable rather than hardcoded or environmental.

Categories of Dependencies

File Storage

PersistentVolumeClaims (PVCs) provide persistent storage that survives Pod restarts. Since Pods are ephemeral, any data that must persist requires a PVC.

PVCs decouple storage requests (what the application needs) from storage provisioning (how the cluster provides it), enabling portable configurations across different storage backends.

Networking and Ports

Port Bindings define how Pods expose services. Rather than using hostPort (which creates tight coupling to specific nodes), applications should:

1. Declare container ports in the Pod specification
2. Expose ports through Services
3. Let Kubernetes handle port mapping and routing

hostPort Limitations - Binding directly to host ports creates scheduling constraints and port conflicts. It prevents multiple Pods with the same hostPort from running on the same node, limiting scalability and high availability.

Services solve this by providing stable network entry points with automatic load balancing, decoupling Pods from specific nodes and ports.

Configuration

ConfigMaps store non-sensitive configuration data:

• Application settings
• Feature flags
• Environment-specific parameters
• Configuration files

Secrets store sensitive data:

• Database passwords
• API keys
• TLS certificates
• OAuth tokens

Both ConfigMaps and Secrets inject configuration into Pods via:

• Environment variables
• Command-line arguments
• Mounted volumes

This externalized configuration follows twelve-factor app principles, enabling the same container image to run in different environments with different configurations.

Declarative Dependency Management

Rather than runtime discovery or environment assumptions, Kubernetes makes dependencies explicit in Pod specifications:

spec:
  containers:
  - name: app
    env:
    - name: DATABASE_URL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: db-url
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: api-secrets
          key: key
    volumeMounts:
    - name: data
      mountPath: /var/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: app-data-pvc

This declarative approach enables:

• Clear understanding of what each Pod requires
• Validation before scheduling (missing dependencies = Pod won’t start)
• Portable configurations across environments

Service Dependencies

Applications discover other services through Services rather than direct Pod IP addresses. Service DNS names (like database.production.svc.cluster.local) abstract away the ephemeral nature of Pods.

Within Namespaces, services use short DNS names, enabling environment-specific resolution while keeping application code unchanged.

Resource Dependencies

Resource profiles declare computational dependencies - how much CPU, memory, and storage a Pod needs. These profiles ensure Pods only schedule on nodes with sufficient resources.