Issue

The email worker deployment failed with a CreateContainerConfigError and Kubernetes events indicated the error couldn't find key postgres-db in Secret name/api-secret. This caused the pod to remain stuck in a pending state, unable to start its containers. The issue arose because the deployment manifest referenced secret keys (postgres-db, postgres-user) that did not match the keys defined in the actual secret (DATABASE_URL, JWT_SECRET).

Culprit

The root cause was an inconsistency in environment variable naming introduced during the migration to FastMCP 2.0. The email worker deployment used individual env.valueFrom.secretKeyRef entries with hardcoded key names that did not align with the actual secret contents. Specifically:

The deployment manifest referenced keys like postgres-db and postgres-user.
The actual secret contained differently named keys such as DATABASE_URL and JWT_SECRET.

This inconsistency occurred because the email worker was not updated to use the more efficient envFrom pattern, which was already implemented in the API deployment. The verbose approach of explicitly referencing secret keys led to key mismatch errors and increased complexity in the deployment YAML.

Solution

The solution involved replacing the individual environment variable references with the envFrom pattern. This pattern automatically loads all keys from the referenced secret and configmap, ensuring consistency and reducing complexity:

Before (Verbose Approach)

The deployment used individual environment variable references, resulting in a lengthy and error-prone configuration:

Each environment variable required explicit key references, leading to a high risk of key mismatch errors.
The configuration was harder to maintain and extended.

After (Simplified Approach)

The deployment was refactored to use envFrom for loading all keys from the secret and configmap:

Automatic Key Loading: All keys from the referenced secret and configmap are loaded automatically, eliminating the risk of key mismatch errors.
Consistency: Aligns with the pattern already used by the API deployment, ensuring uniformity across the codebase.
Maintainability: Adding new environment variables only requires updating the secret or configmap, reducing the need for manual changes in the deployment YAML.
Reduced Complexity: The YAML configuration was reduced by 97%, from 150 lines to just 5 lines.

Benefits Achieved

Eliminated CreateContainerConfigError by removing explicit key references.
Improved maintainability and reduced the risk of configuration errors.
Aligned deployment patterns across the application, promoting consistency.

This change was validated by successfully deploying the email worker pod and verifying that environment variables were correctly loaded. The solution established envFrom as the default pattern for all Kubernetes deployments, with individual env references reserved for specific cases requiring variable renaming or combining multiple sources.