ConfigMap

A ConfigMap is a Kubernetes object that stores non-confidential configuration data as key-value pairs, keeping settings separate from container images.

Table of Contents

Table of Contents

Further Reading

No items found.
No items found.
No items found.
No items found.
No items found.
No items found.

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:

apiVersion: v1
kind: ConfigMap
metadata:
  name: checkout-test-config
data:
  BASE_URL: "https://staging.example.com"
  TIMEOUT_SECONDS: "30"
  FEATURE_NEW_CART: "true"

ConfigMap vs. Secret

Aspect ConfigMap Secret
Purpose Non-sensitive configuration Passwords, tokens, and certificates
Storage Plain text Base64-encoded, with encryption at rest available
Access control Standard RBAC Tighter RBAC recommended
Example Base URLs, feature flags, timeouts API keys, database passwords

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

  1. Create: define the ConfigMap in YAML or with kubectl.
  2. Reference: point a pod spec to the ConfigMap.
  3. Consume: read values as environment variables, mounted files, or command arguments.
  4. 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

Frequently Asked Questions (FAQs)

What is the difference between a ConfigMap and a Secret?

A ConfigMap stores non-sensitive configuration in plain text. A Secret is designed for sensitive data like passwords, tokens, or certificates.

Can ConfigMaps be updated without restarting pods?

It depends on how pods consume them. Mounted files update automatically after a short delay, but environment variables require a pod restart.

How large can a ConfigMap be?

A ConfigMap is limited to 1 MiB. Larger configuration should be split or stored in another system.

Can ConfigMaps store binary data?

Yes. ConfigMaps have a binaryData field for base64-encoded binary content, though they are mainly used for text.

How do ConfigMaps improve test execution in Testkube?

Externalized parameters let Testkube tests adapt to different clusters without duplicated definitions. That keeps tests consistent and cuts maintenance.

Related Terms and Concepts