Kubernetes for Developers: A Practical Guide to Container Orchestration

As a developer, you might wonder why you need to learn Kubernetes when Docker containers already solve the packaging problem. The answer is scale and reliability. While Docker handles single-container applications, Kubernetes orchestrates complex, multi-container applications across multiple servers.

Kubernetes has become the de facto standard for container orchestration, with 87% of organizations using it in production. Understanding K8s is now essential for modern software development, especially in cloud engineering and DevOps roles.

Unlike traditional deployment models where you SSH into servers and manually deploy applications, Kubernetes follows a declarative model. You describe the desired state of your application (how many replicas, what resources it needs, how it should be exposed), and Kubernetes continuously works to maintain that state.

Kubernetes has many components, but as a developer, you primarily interact with four core objects: Pods, Services, Deployments, and ConfigMaps. Understanding these building blocks is crucial for effective development.

A Pod is like a shared apartment for containers. Most of the time, you'll have one container per Pod, but occasionally you might need helper containers (like a sidecar for logging or monitoring) that share the same network and storage.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: web-server
    image: nginx:1.21
    ports:
    - containerPort: 80
  - name: log-collector
    image: fluentd:latest
    # Sidecar container for log collection

Pods are ephemeral - they can be created, destroyed, and recreated at any time. This is why you never deploy Pods directly in production. Instead, you use Deployments to manage them.

Since Pods can be destroyed and recreated with different IP addresses, you need a stable way to reach your application. That's where Services come in. They provide a consistent endpoint that automatically load balances traffic across healthy Pod replicas.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP  # Internal only
  # type: LoadBalancer  # External access

• ClusterIP: Internal access only (default)
• NodePort: Exposes service on each node's IP
• LoadBalancer: Creates external load balancer (cloud provider dependent)
• Ingress: HTTP/HTTPS routing with domain names

The key to productive Kubernetes development is automation. You shouldn't be manually running kubectl commands every time you make a code change. Modern development tools like Skaffold, Tilt, and Telepresence streamline the development experience.

GitOps represents the evolution of Kubernetes deployment practices. Instead of manually applying configurations, your Git repository becomes the source of truth for your cluster state. Tools like ArgoCD and Flux automatically sync your cluster with your Git repository.

1. Developer pushes code to feature branch
2. CI pipeline builds container image and updates K8s manifests
3. Pull request triggers preview environment deployment
4. Merge to main automatically promotes to staging/production
5. GitOps controller syncs cluster state with Git repository

This approach is fundamental to modern DevOps practices and is expected knowledge for software engineers working with cloud-native applications.

Before deploying to production clusters, you need a local development environment. Several options exist, each with different trade-offs for resource usage and feature completeness.

As a developer, you'll use kubectl (the Kubernetes command-line tool) frequently. Here are the commands you'll use 90% of the time:

# Deploy your application
kubectl apply -f deployment.yaml

# Check if your pods are running
kubectl get pods

# See detailed info about a failing pod
kubectl describe pod my-app-7d4b6c8f9-xz2k8

# View application logs
kubectl logs my-app-7d4b6c8f9-xz2k8

# Execute commands inside a pod
kubectl exec -it my-app-7d4b6c8f9-xz2k8 -- /bin/bash

# Port forward for local testing
kubectl port-forward pod/my-app-7d4b6c8f9-xz2k8 8080:80

# Delete resources
kubectl delete -f deployment.yaml

Debugging in Kubernetes requires a different mindset than traditional application debugging. Issues can occur at multiple layers: container, pod, service, or cluster level. Understanding the debugging hierarchy is crucial.

• ImagePullBackOff: Your container image can't be downloaded. Check image name, tag, and registry credentials.
• CrashLoopBackOff: Your application keeps crashing after startup. Check logs and ensure proper health check endpoints.
• Pending: Pod can't be scheduled. Usually insufficient cluster resources or node selector constraints.
• CreateContainerConfigError: Missing ConfigMaps, Secrets, or volume mounts referenced in your pod spec.
• OOMKilled: Container exceeded memory limits. Increase resource requests or optimize your application.

Following best practices from the start prevents common issues and makes your applications more reliable and maintainable. These practices are essential knowledge for cloud engineering roles.

Always specify resource requests and limits for your containers. Requests ensure your pod gets scheduled on a node with sufficient resources, while limits prevent one application from consuming all available resources.

spec:
  containers:
  - name: my-app
    image: my-app:latest
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
    # Health checks are crucial
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

Never bake configuration into container images. Use ConfigMaps for non-sensitive data and Secrets for passwords, API keys, and certificates. This follows the twelve-factor app methodology and makes your applications portable across environments.

# ConfigMap for application settings
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_host: "postgres.default.svc.cluster.local"
  log_level: "info"
  feature_flags: "new_ui=true,beta_api=false"

---
# Secret for sensitive data
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database_password: cGFzc3dvcmQxMjM=  # base64 encoded
  api_key: YWJjZGVmZ2hpams=

Learning from others' mistakes can save you hours of debugging. Here are the most common issues developers encounter when starting with Kubernetes.

• Not setting resource limits: Leads to resource contention and unstable applications
• Ignoring health checks: Kubernetes can't properly manage unhealthy pods without liveness and readiness probes
• Using latest tags: Makes deployments unpredictable; always use specific version tags
• Storing state in containers: Use persistent volumes or external databases for data that needs to survive pod restarts
• Not understanding labels and selectors: Mismatched labels prevent services from finding pods
• Mixing environment-specific config in manifests: Use Helm templates or Kustomize for environment differences