Kubernetes for beginners: what problem it solves

What is Kubernetes and why do we hear so much about it?

If you've been working in the software development and infrastructure world for a few years, you've definitely heard of Kubernetes. Many call it the "cloud operating system," and many others simply know it as a tool for managing containers. But the main question is: what problem does Kubernetes actually solve?

The short answer is: Kubernetes solves the problem of automated management of containerized applications at scale. When you have a few Docker containers, running them is simple. But when you have dozens or hundreds of containers that need to communicate with each other, recover from failures, and scale during traffic spikes, manual management becomes impossible. That's exactly where Kubernetes comes in.

In this article, using simple language and practical examples, we'll explore the core Kubernetes concepts — Pod, Service, and Deployment — and finally answer the question of whether you really need Kubernetes or not.

The Core Problem: Containers Alone Aren't Enough

Imagine you've set up a simple e-commerce website with Docker. One container for the Nginx web server, one for the Node.js application, and one for MySQL. Everything works fine until your site's traffic increases. Now what do you do?

Manually, you'd have to:

• Run a new instance of the application container.
• Modify the Nginx configuration to split traffic between the two instances.
• Make sure both instances connect to the same database.
• If one of the instances crashes, notice it and restart it.

This might be manageable at a small scale, but when the number of services reaches 10 or 20, it becomes practically unmanageable. Kubernetes automates this process: you say "I want 3 instances of this application," and Kubernetes handles the rest itself.

Basic Concepts: What is a Pod?

A Pod is the smallest execution unit in Kubernetes. Contrary to popular belief, a Pod is not equivalent to a container; a Pod can contain one or more containers that share resources. In practice, most of the time each Pod contains just one main container.

A simple example of defining a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: nginx:latest
    ports:
    - containerPort: 80

This YAML file defines a Pod named my-app that uses the Nginx image. But the important point is that Pods are usually not created directly. Why? Because if a Pod crashes, Kubernetes won't automatically bring it back. To manage the lifecycle of Pods, you need a Deployment.

Deployment: The Real Manager of Pods

A Deployment is a Kubernetes resource that describes the desired state of your application. You say "I want 3 replicas of this application," and the Deployment is responsible for creating, updating, and repairing Pods.

Example of a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myapp:v1.2
        ports:
        - containerPort: 8080

With this definition, Kubernetes always keeps 3 Pods with the label app: my-app active. If one of the Pods crashes, the Deployment automatically creates a new Pod. If you want to release a new version of your application, you just change the image in the Deployment, and Kubernetes gradually replaces the old Pods with new ones (Rolling Update).

Service: A Stable Address for Ephemeral Pods

Pods in Kubernetes are temporary. At any moment, a Pod might be deleted and replaced by a new one with a different IP. If your application needs to communicate with another service, it can't depend on the IP of a specific Pod. This is where the Service comes in.

A Service provides a stable address (usually an internal DNS name) that distributes traffic among the Pods of a Deployment. Example:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

With this definition, other services can access your application via the name my-app-service, without worrying about the Pods' IPs. The ClusterIP type means the Service is only accessible within the cluster. If you want the Service to be accessible from outside, you'd use NodePort or LoadBalancer.

When Is Kubernetes Overkill?

Now that you're familiar with the core concepts, we need to honestly answer this question: does your project really need Kubernetes? In many cases, the answer is "no."

Kubernetes is a powerful tool, but it has hidden costs:

• Operational complexity: Setting up and maintaining a Kubernetes cluster requires deep knowledge of networking, security, and resource management.
• Hardware resources: Kubernetes itself requires significant resources for its control plane components. For a small project, these resources are wasted.
• Learning curve: Concepts like Ingress, ConfigMap, Secret, and RBAC take time to learn.

Signs That You Don't Need Kubernetes Yet

If you have the following conditions, Kubernetes is probably overkill for you:

• Your application has only one or two services.
• Your traffic is predictable and doesn't have extreme fluctuations.
• Your team is just one or two people and doesn't have time to learn new tools.
• Your application is stateful (e.g., a database) and depends on local storage.

In these cases, simpler solutions like Docker Compose for development environments, and a simple VPS or cloud service for production, are perfectly sufficient. You could even use managed services like Docker Swarm, which are far less complex.

When Should You Migrate to Kubernetes?

Consider Kubernetes when:

• The number of your services exceeds 5 to 10, and managing them manually becomes difficult.
• You need automatic scaling based on traffic.
• You want to release new versions without service downtime.
• Your team is large enough that someone can focus on infrastructure.

At this point, migrating to Kubernetes makes sense. But my recommendation is to first practice with a small cluster on your local machine (e.g., with Minikube or kind), and then move on to setting up a real cluster.

Common Mistakes When Starting with Kubernetes

Over the years I've worked with Kubernetes, I've repeatedly seen a few common mistakes that beginner teams make:

Mistake #1: Using "latest" for Image Tags

Using image: nginx:latest in a Deployment is a classic mistake. The problem is that when Kubernetes creates a new Pod, it might pull a newer version of the image that isn't compatible with the previous one. Always use specific tags like nginx:1.25.3.

Mistake #2: Ignoring Resource Limits

If you don't set resource limits (CPU and Memory) for Pods, a single Pod can consume all of a node's resources and take down the other Pods. Always define resources.requests and resources.limits:

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Mistake #3: Storing Sensitive Information in ConfigMap

ConfigMap is for non-sensitive configuration. For passwords and API keys, you should use Secret. ConfigMaps are stored as plain text, and anyone with access to the cluster can read them.

Troubleshooting Tips: When Your Pod Stays in Pending State

One of the most common issues beginners face is Pods that stay in Pending state forever. This usually means Kubernetes can't find enough resources to run the Pod. To investigate:

kubectl describe pod my-app-pod

In the output of this command, check the Events section. If you see a message like 0/3 nodes are available: insufficient cpu, it means you need to increase node resources or reduce the Pod's limits.

Another common issue is Pods in CrashLoopBackOff state. This means the Pod starts but crashes immediately. To see the logs:

kubectl logs my-app-pod --previous

This command shows the logs from the Pod's last previous run, which usually reveals the cause of the error.

Conclusion: Kubernetes Is a Tool, Not a Goal

Kubernetes is an incredibly powerful tool for managing containerized applications at scale. The concepts of Pod, Service, and Deployment form the core foundation of this system, and understanding them is essential for anyone who wants to work with Kubernetes.

But the most important point is to choose Kubernetes to solve a real problem, not just because it's "trendy." If your project is small and your team is limited, simpler tools will serve you better. And if you do decide to migrate to Kubernetes, start with a small cluster, learn the basics well, and gradually expand your infrastructure.

If you're looking for infrastructure to run Kubernetes on, ServerNet's cloud services can be a good option to start with — but always clarify your needs first, and then choose the right tool.