Most application developers don’t run Kubernetes themselves — they deploy to a cluster managed by a platform team or a cloud provider. But you still need to understand what Kubernetes does to work effectively in a Kubernetes environment. Here is the mental model.
What Kubernetes Actually Does
Kubernetes (K8s) is a container orchestration system: it manages the scheduling, scaling, networking, and health of containerised applications across a cluster of machines. The problems Kubernetes solves: how to run multiple instances of a service and distribute load between them; how to restart failed containers automatically; how to roll out new versions without downtime; how to scale services up and down based on load; and how to network containers together securely. Kubernetes does not solve: application performance, security within the application, database management, or cost optimisation by itself.
Core Concepts You Must Know
Pod: the smallest deployable unit — one or more containers that run together on the same node, sharing network and storage. You rarely create pods directly; you create higher-level abstractions. Deployment: describes how to run N replicas of a pod, handles rolling updates and rollbacks. Service: a stable network endpoint that forwards traffic to pods — pods come and go, but the Service IP/DNS name is stable. Ingress: the HTTP/HTTPS entry point that routes external traffic to Services (based on host/path rules). ConfigMap and Secret: ways to inject configuration and sensitive data (passwords, API keys) into pods without baking them into the container image. Namespace: a way to logically separate resources within a cluster (common: dev/staging/prod namespaces on the same cluster).
The Developer Workflow
What a developer actually does in a Kubernetes environment: write application code; build a Docker image (docker build); push the image to a container registry (docker push); write or update a Kubernetes manifest (YAML file describing a Deployment, Service, etc.); apply the manifest (kubectl apply -f deployment.yaml) or let CI/CD do it. The kubectl commands you use most: `kubectl get pods` (list running pods), `kubectl logs pod-name` (view pod logs), `kubectl exec -it pod-name — bash` (open a shell in a running pod for debugging), `kubectl describe pod pod-name` (detailed pod status, useful for diagnosing startup failures), and `kubectl rollout status deployment/name` (watch a rolling update).
What to Ask Your Platform Team
Questions every developer in a K8s environment should have answered: What resource limits should I set for my deployment (CPU and memory requests/limits)? What liveness and readiness probe endpoints should I implement in my application? What’s the process for accessing pod logs in production (often through a logging aggregator like Loki, Splunk, or Datadog rather than kubectl)? How are secrets managed (often through HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets with external-secrets operator rather than raw K8s Secrets)? What namespace should I deploy to and what network policies apply? Setting resource limits and implementing proper health check endpoints (readiness: “am I ready to serve traffic?”, liveness: “am I still alive?”) are the developer’s responsibilities that have the most direct impact on cluster stability.
