Kubernetes Configmap Vs Secret¶
Introduction¶
This guide explains kubernetes configmap vs secret with practical kubectl commands, realistic output, and production-focused checks. The goal is to connect the concept to what you can observe with kubectl in a real cluster.
What It Means¶
In Kubernetes, this topic is part of the desired-state model: users submit objects to the API server, controllers reconcile actual state, and kubelets run containers on nodes.
Why It Matters¶
Understanding kubernetes configmap vs secret helps you troubleshoot faster because you know which object owns the behavior: pod, workload controller, service, node, scheduler, kubelet, or storage object.
Key Commands¶
kubectl get configmap,secret -n app
kubectl describe pod web-0 -n app
kubectl get pvc,pv,storageclass -n app
kubectl describe pvc data -n app
kubectl get events -n app --sort-by=.lastTimestamp
Expected output:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc/data Bound pvc-1234 10Gi RWO fast 2d
Example Manifest¶
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
stringData:
DATABASE_URL: postgres://db:5432/app
How to Verify It¶
kubectl get all -n app
kubectl describe deployment web -n app
kubectl get events -n app --sort-by=.lastTimestamp
Common Mistakes¶
- Memorizing definitions without checking the real object relationships.
- Confusing desired state in the manifest with actual state running on nodes.
- Ignoring namespace, labels, and owner references when tracing resources.
Quick Checklist¶
- Identify the Kubernetes object involved.
- Check owner references and labels.
- Read events for reconciliation errors.
- Verify actual pods, endpoints, or node placement.
Related Guides¶
- kubectl Get Pods
- Kubernetes Pod Explained
- Kubernetes Deployment Explained
- Kubernetes Service Explained
Summary¶
Kubernetes Configmap Vs Secret is easiest to understand through live objects. Use kubectl to connect the concept to manifests, events, controllers, and running pods.