Skip to content
LatchkeyLatchkey home

kubectl create configmap: Usage, Options & Common CI Errors

Build a ConfigMap from literals or files without writing YAML.

kubectl create configmap turns flags into a ConfigMap, sourcing keys from inline literals, files, directories, or an env file. It is the fastest way to inject non-secret config into a workload from CI.

What it does

kubectl create configmap NAME populates data from --from-literal=key=value, --from-file=path (file name becomes the key, or dir contents become many keys), or --from-env-file=.env (each KEY=VAL line becomes a key). Add --dry-run=client -o yaml to scaffold the manifest instead of creating it.

Common usage

Terminal
kubectl create configmap app-cfg --from-literal=LOG_LEVEL=info
kubectl create configmap app-cfg --from-file=./config/
kubectl create configmap app-cfg --from-env-file=./.env
kubectl create configmap app-cfg --from-literal=k=v \
  --dry-run=client -o yaml | kubectl apply -f -

Common errors in CI

"Error from server (AlreadyExists): configmaps \"app-cfg\" already exists" is the re-run trap - create is not idempotent. The idiom that fixes it is to generate-then-apply: kubectl create configmap ... --dry-run=client -o yaml | kubectl apply -f -. Also note a ConfigMap key must be a valid env-var-ish name ([-._a-zA-Z0-9]); a --from-file whose filename has odd characters fails with "is not a valid key name". And a mounted ConfigMap updates pods lazily - restart the workload (rollout restart) if pods read the value only at start.

Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes

Frequently asked questions

kubectl create configmap: Usage, Options & Common CI Errors?
kubectl create configmap turns flags into a ConfigMap, sourcing keys from inline literals, files, directories, or an env file. It is the fastest way to inject non-secret config into a workload from CI.
What it does?
kubectl create configmap NAME populates data from --from-literal=key=value, --from-file=path (file name becomes the key, or dir contents become many keys), or --from-env-file=.env (each KEY=VAL line becomes a key). Add --dry-run=client -o yaml to scaffold the manifest instead of creating it.
Common errors in CI?
"Error from server (AlreadyExists): configmaps \"app-cfg\" already exists" is the re-run trap - create is not idempotent. The idiom that fixes it is to generate-then-apply: kubectl create configmap ... --dry-run=client -o yaml | kubectl apply -f -.

Related guides

References

Run this faster and cheaper on Latchkey managed runners - self-healing included. Start free → 30-day trial · No credit card