Kubernetes Is Useful, but Only After These Basics Hurt

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

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

Apply it:

kubectl apply -f deployment.yaml
kubectl get pods

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

The service gives stable networking inside the cluster.

client -> service -> matching pods

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

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"

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?