Table of Contents
Table of Contents
Further Reading
What Does ConfigMap Mean?
A ConfigMap is a Kubernetes object that stores non-confidential configuration data as key-value pairs. Teams externalize settings into ConfigMaps instead of hardcoding them into container images.
Here is a simple example for a checkout test suite:
ConfigMap vs. Secret
Why ConfigMaps Matter
ConfigMaps make Kubernetes applications more portable and manageable. Separating configuration from code means:
- One image everywhere: reuse the same container image across environments
- No rebuilds for config: adjust settings without rebuilding images
- Kubernetes-native control: ops teams manage behavior with standard resources
- Version control: configuration can live in Git beside manifests
How ConfigMaps Work in Kubernetes
- Create: define the ConfigMap in YAML or with kubectl.
- Reference: point a pod spec to the ConfigMap.
- Consume: read values as environment variables, mounted files, or command arguments.
- Update: change values without touching the image.
Common uses include feature flags, service URLs, default job parameters, and integration settings.
Real-World Example
A B2B SaaS team runs the same checkout tests in dev, staging, and a production mirror. Each cluster has its own ConfigMap with the right base URL and timeouts.
The test definition never changes. Only the ConfigMap differs, so drift between environments drops and maintenance stays low.
How ConfigMaps Work with Testkube
Testkube workflows can read values from ConfigMaps to configure test executions. Teams can:
- Pass environment parameters: give tests the right URLs and settings per cluster
- Reuse definitions: run one test definition across multiple clusters
- Separate secrets: combine ConfigMaps with Secrets for sensitive values
Best Practices for ConfigMaps
- Never store secrets: use Secrets for anything sensitive
- Name clearly: tie names to the app and environment
- Keep them small: the size limit is 1 MiB
- Version in Git: manage ConfigMaps with GitOps
- Plan for updates: env vars need a pod restart, while mounted files update over time



