Kubernetes for Developers: Practice and Debugging

# Practical Introduction to Kubernetes: From Local Cluster to Cloud Deployment

Kubernetes isn't just a container orchestration tool—it's the de facto standard for managing distributed applications. This article is aimed at developers and engineers who want to quickly go from theory to practice: deploy a local cluster, understand the basic objects, and get ready for managed cloud services.

Setting Up Your Working Environment

The first step is installing kubectl, the primary CLI tool for interacting with the Kubernetes API. The client version should differ from the cluster version by no more than one minor release branch. Installation varies by OS:

• Linux: official script from the Kubernetes repository;
• macOS: brew install kubectl;
• Windows: via winget, Chocolatey, or direct binary download.

Important: If using Docker Desktop, its built-in kubectl may conflict with the main one. It's recommended to use a single installation point and manage the PATH variable.

For local development, two solutions work well:

Minikube

Minikube creates a single-node cluster inside a virtual machine or container (depending on the driver). Launch it with one command:

minikube start

After starting, check the node status:

kubectl get nodes

Expected result: one node with Ready status.

Kind (Kubernetes in Docker)

Kind runs nodes as Docker containers. This is especially handy with tight integration into existing Docker workflows:

kind create cluster

Kind's advantages include fast startup and easy cleanup. However, for beginners, Minikube remains the preferred choice due to its extensive documentation and community.

After launching the cluster, verify connectivity:

kubectl cluster-info

If the command returns info on Control Plane components, your environment is ready.

Basic Kubernetes Objects

Any application in Kubernetes is built on three key abstractions: Pod, Deployment, and Service.

Pod — the Minimal Executable Unit

A Pod is a group of one or more containers that share network namespace, volumes, and IPC. All containers in a Pod can reach each other via localhost. However, Pods are ephemeral: they can be deleted at any time due to failures, updates, or scaling. Direct Pod management is not recommended.

Deployment — Declarative Replica Management

A Deployment defines the desired state of an application: number of replicas, container image, update strategy. Example manifest:

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

Apply the manifest:

kubectl apply -f deployment.yaml

Kubernetes automatically creates a ReplicaSet that ensures the specified number of running Pods.

Service — Stable Network Entry Point

A Service provides a stable IP address and DNS name for a group of Pods selected by labels. Example internal service:

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

For local access in Minikube, use:

minikube service my-app-service

The command will automatically open a browser with the correct URL.

Moving to the Cloud: Managed Clusters

After mastering the local environment, it's logical to move to production deployments. Manual cluster setup with kubeadm is possible but impractical for most scenarios. Better to use managed services:

• Amazon EKS — flexible, but requires deep knowledge of AWS IAM and VPC;
• Google GKE — the most mature implementation with automatic node management and built-in security;
• Azure AKS — convenient when using the Microsoft ecosystem and Azure DevOps.

The recommended approach is Infrastructure as Code (IaC). For example, with Terraform, you can declaratively describe the cluster and node group for reproducibility and version control.

After creating the cluster in the cloud, update kubeconfig:

aws eks update-kubeconfig --name my-app-cluster

Now all kubectl commands will target the cloud cluster.

Debugging Common Issues

Kubernetes errors often follow recurring patterns. Follow a systematic approach:

• Check Pod status: kubectl get pods
• Review logs: kubectl logs <pod-name>
• Analyze events: kubectl describe pod <pod-name>
• If needed, enter the container: kubectl exec -it <pod-name> -- /bin/sh

Common issues and fixes:

• ImagePullBackOff: verify image name, tag, and imagePullSecrets for private repos;
• CrashLoopBackOff: check app logs and events for OOMKilled or init errors;
• Service unreachable: ensure Pod labels match the Service selector, and ports (port, targetPort, containerPort) align.

Always specify resources.requests and resources.limits for CPU and memory—this prevents node instability and poor scheduling.

What to Study Next

After grasping the basics, focus on:

• Ingress and Gateway API — external traffic routing;
• ConfigMaps and Secrets — configuration management without hardcoding;
• Jobs and CronJobs — one-off and periodic tasks;
• Horizontal Pod Autoscaler — metric-based auto-scaling.

The Kubernetes ecosystem is dynamic: new standards (like Gateway API) gradually replace outdated ones. Stay updated, but prioritize solving specific problems over learning everything at once.

Key Takeaways

• Kubernetes demands a declarative approach: describe the desired state, and the system works to achieve it.
• Local clusters (Minikube, Kind) provide a safe sandbox for experiments without production risks.
• Managed cloud services (EKS, GKE, AKS) save hundreds of hours on ops.
• Debugging starts with kubectl get, describe, and logs—these solve 90% of issues.
• Always set resource limits to avoid cluster instability.

— Editorial Team