DEV Community

Cover image for Kubernetes Is Useful, but Only After These Basics Hurt
Mark Yu
Mark Yu

Posted on • Edited on

Kubernetes Is Useful, but Only After These Basics Hurt

#kubernetes #cloud #devops #containers

Kubernetes is not the first tool I reach for.

That may sound strange in 2026, but I still think many teams adopt Kubernetes before their deployment pain is real enough.

Kubernetes helps when you need orchestration. It hurts when you just wanted a place to run one container.

What Kubernetes Actually Gives You

Kubernetes helps manage:

  • container scheduling
  • restarts
  • scaling
  • service discovery
  • rollout strategy
  • configuration
  • workload isolation

The basic shape:

Deployment
   |
   v
ReplicaSet
   |
   v
Pods
   |
   v
Containers
Enter fullscreen mode Exit fullscreen mode

Most beginner confusion comes from mixing up those layers.

The Smallest Useful Deployment 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: nginx:1.27
          ports:
            - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Apply it:

kubectl apply -f deployment.yaml
kubectl get pods
Enter fullscreen mode Exit fullscreen mode

This does not expose the app yet. It only runs pods.

Add a Service 

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP
Enter fullscreen mode Exit fullscreen mode

The service gives stable networking inside the cluster.

client -> service -> matching pods
Enter fullscreen mode Exit fullscreen mode

Pods can die and come back with different IPs. The service keeps the route stable.

The Debug Commands I Use First 

kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl get events --sort-by=.lastTimestamp
kubectl rollout status deployment/api
Enter fullscreen mode Exit fullscreen mode

If a pod is stuck in CrashLoopBackOff, I look at logs first.

If it is stuck in Pending, I look at describe/events because it may be scheduling, resources, or image pulling.

Config and Secrets

Do not bake environment-specific config into images.

Use ConfigMaps for normal config:

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:
  LOG_LEVEL: "info"
Enter fullscreen mode Exit fullscreen mode

Use Secrets for sensitive values, but remember: Kubernetes Secrets are not magic encryption by default. Treat cluster access seriously.

When Kubernetes Is Worth It

I would consider Kubernetes when:

  • you run many services
  • rollouts need control
  • autoscaling matters
  • workloads need scheduling
  • multiple teams share a platform
  • you already have observability

I would avoid it when:

  • one app can run fine on managed PaaS
  • nobody owns cluster operations
  • logs and metrics are weak
  • the team has no deployment discipline yet

Cloud-native 3.0 is making Kubernetes more platform-like, especially with internal developer portals and AI-assisted operations. Still, the fundamentals have not changed: a confusing cluster is not a platform.

Final Thought

Kubernetes is powerful because it standardizes operational patterns. It is painful because it exposes every weak operational habit your team already had.

What was your first Kubernetes failure: image pull, config, networking, or resources?

Top comments (0)