Idempotent create-or-update (the pattern to use in automation): kubectl create secret generic <name> --from-literal=KEY=value --dry-run=client -o yaml | kubectl apply -f - — works whether or not the object exists
Read a secret value back: kubectl get secret <name> -o jsonpath='{.data.KEY}' | base64 --decode
Roll it out: pods consume Secrets/ConfigMaps at startup (env) or via volume; after an update, restart consumers: kubectl rollout restart deployment/<consumer>
Official docs: https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/ and https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
Known gotchas
Secret data is base64-ENCODED, not encrypted — anyone who can get the object can read the values; real protection needs RBAC plus encryption-at-rest configured on the cluster
kubectl create errors with AlreadyExists on a second run — that's why the --dry-run=client -o yaml | kubectl apply -f - pipe is the standard update pattern
Trailing newlines sneak into values: file contents are stored verbatim (including a final newline), and echo without -n adds one to piped literals — a classic cause of auth failures with 'correct' credentials
Env-var consumers never see updates and subPath mounts don't refresh; only whole-volume mounts update in place (with kubelet sync delay). When in doubt, rollout restart the consumers
Objects marked immutable: true cannot be updated in place — delete and recreate
Size limit is ~1MiB per object (etcd limit); split bigger payloads or use a volume/external store
Give your agent this knowledge — and 17,100+ more routes
One MCP install gives any agent live access to the full route map across 5,900+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?