Kubernetes for Developers: Pods, Deployments, and Service Discovery
A developer-friendly Kubernetes guide covering pods, deployments, services, configuration, health checks, resources, rollouts, and common mistakes.
On this page
Kubernetes schedules and manages containerized workloads. Developers do not need to memorize every resource, but they should understand the lifecycle, configuration, networking, health, and rollout behavior of the services they deploy.
#Pods and deployments
A pod is the smallest scheduling unit and usually contains one application container. A Deployment describes the desired number of replicas and manages rolling replacement when the pod template changes.
Containers are replaceable. Do not store important application state only in a pod filesystem.
#Services and discovery
A Service provides a stable network identity for a changing set of pods. Internal clients should call the service name rather than a pod IP. Ingress or a gateway handles external traffic according to the platform policy.
#Configuration and secrets
Keep configuration separate from the image. Use ConfigMaps for non-sensitive settings and a secret mechanism for credentials. Restrict which workloads can read secrets and avoid printing them in logs.
#Health and resources
Readiness determines whether a pod should receive traffic; liveness indicates whether it needs a restart. Set CPU and memory requests and limits based on measured behavior. A health check that only returns process-up can miss a broken database dependency.
#Rollouts and debugging
Use a gradual rollout, observe errors and latency, and know how to pause or roll back. Debug from events, pod status, logs, and metrics. A restart may hide the symptom without fixing the configuration or dependency failure.
#Common mistakes
Using a pod IP as a stable endpoint.
Putting secrets in images or manifests.
Skipping resource limits.
Confusing readiness with liveness.
Deploying without a rollback plan.
#Frequently asked questions
#Does Kubernetes make an app highly available automatically?
No. Replicas, storage, dependencies, topology, and application behavior all affect availability.
#Do developers need cluster-admin access?
Usually no. Least privilege and namespace-scoped access are safer.
#Conclusion
Kubernetes becomes approachable when you focus on lifecycle and contracts: replaceable pods, stable services, externalized configuration, meaningful health checks, resource boundaries, and observable rollouts.