Setting Up a Kubernetes Cluster: Complete Step-by-Step Guide (2026)

Q: Which container runtime should I use?

Modern Kubernetes clusters typically use containerd or CRI-O because they implement the Kubernetes Container Runtime Interface (CRI) and are actively supported.

Setting up a Kubernetes cluster is the foundation of running containerized applications at scale. Whether you're building a local development environment, an on-premises production platform, or preparing for cloud-native deployments, understanding the cluster setup process is essential.

In this guide, you'll learn:

What a Kubernetes cluster consists of
The hardware and software prerequisites
When to use kubeadm, Kind, K3s, or managed Kubernetes
How to prepare Linux nodes correctly
Modern 2026 best practices for container runtimes, networking, and security

This tutorial focuses on a self-managed Kubernetes cluster using kubeadm, which remains the recommended approach for learning Kubernetes internals and building production-ready clusters on your own infrastructure.

Introduction

Kubernetes has become the standard platform for orchestrating containerized workloads across private data centers, public clouds, and hybrid environments. Instead of manually deploying and managing containers on individual servers, Kubernetes automates scheduling, scaling, self-healing, networking, and application lifecycle management.

Although managed Kubernetes platforms reduce operational overhead, every Kubernetes administrator benefits from understanding how a cluster is built from the ground up. Installing a cluster yourself provides valuable insight into how core components interact, how nodes communicate, and how to troubleshoot issues when applications fail.

A modern Kubernetes installation is also different from guides written several years ago. Current releases use the Container Runtime Interface (CRI) with runtimes such as containerd or CRI-O, modern Container Network Interface (CNI) plugins, and updated security defaults. Deprecated practices and terminology have largely disappeared from official documentation.

This guide assumes you're deploying a Linux-based cluster with one control plane node and one or more worker nodes. The same concepts also apply when building highly available production clusters with multiple control plane nodes.

Why Kubernetes Clusters Matter

A Kubernetes cluster provides a centralized platform for deploying, managing, and scaling applications across multiple machines. Instead of treating servers individually, Kubernetes pools compute resources into a single platform where workloads are scheduled automatically.

Some of the key capabilities include:

Automatic container scheduling
Horizontal application scaling
Service discovery and internal networking
Rolling updates and automated rollbacks
Self-healing workloads through health checks
Secret and configuration management
High availability for critical applications

Without Kubernetes, administrators typically manage servers individually, update applications manually, and rely on custom automation scripts. As infrastructure grows, this approach becomes increasingly difficult to maintain.

A properly configured Kubernetes cluster enables:

Consistent development, testing, and production environments
Efficient resource utilization
Simplified deployment pipelines
Improved application resilience
Easier adoption of GitOps and Infrastructure as Code practices

For organizations embracing cloud-native architectures, Kubernetes acts as the orchestration layer that connects applications, networking, storage, security, and observability into a unified platform.

Kubernetes Architecture Overview

Before installing Kubernetes, it's important to understand the major components of a cluster.

A Kubernetes cluster consists of two primary node types:

Control Plane Node
Worker Nodes

Control Plane

The control plane manages the entire cluster. It receives API requests, schedules workloads, maintains cluster state, and coordinates communication between components.

Core services include:

API Server — The central entry point for all Kubernetes operations.
etcd — A distributed key-value database that stores cluster configuration and state.
Scheduler — Determines where Pods should run based on available resources and scheduling policies.
Controller Manager — Continuously reconciles the desired cluster state with the actual state.

Because these services manage the cluster itself, protecting and backing up the control plane is critical.

Worker Nodes

Worker nodes run application workloads.

Each worker includes:

kubelet — Communicates with the control plane and manages Pods on the node.
Container Runtime — Executes containers using a CRI-compatible runtime such as containerd.
kube-proxy — Implements Kubernetes Service networking and traffic routing.

When a new application is deployed, the scheduler selects an appropriate worker node, and kubelet ensures the required containers are running.

Container Networking

Unlike standalone Docker containers, Kubernetes requires networking across multiple nodes.

This functionality is provided by a Container Network Interface (CNI) plugin.

Popular CNI implementations include:

Calico
Cilium
Flannel

Each offers different networking capabilities, security features, and scalability characteristics.

Cluster Communication

At a high level, the workflow looks like this:

A user submits a deployment using kubectl.
The API Server validates the request.
The Scheduler selects a worker node.
kubelet starts the required containers.
kube-proxy configures network routing.
The CNI plugin enables Pod-to-Pod communication.

Understanding this workflow makes troubleshooting significantly easier later.

Prerequisites

Before setting up a Kubernetes cluster, verify that both your hardware and operating system meet the necessary requirements.

Hardware Requirements

For a small learning environment:

One control plane node
One or more worker nodes
2 vCPUs minimum per node
4 GB RAM recommended per node
At least 20 GB of available disk space
Reliable network connectivity between all nodes

Production environments should allocate considerably more CPU, memory, and storage depending on workload requirements.

Operating System

Kubernetes is best deployed on modern Linux distributions such as:

Ubuntu Server LTS
Debian
Rocky Linux
AlmaLinux
Red Hat Enterprise Linux

Using identical operating system versions across nodes simplifies maintenance and upgrades.

Required Software

Install the following components on every node:

kubeadm
kubelet
kubectl (required on the control plane and optional on workers)
A CRI-compatible container runtime such as containerd
Required networking packages

Always install compatible Kubernetes component versions to avoid version skew issues.

Network Requirements

Nodes must communicate without interruption.

Ensure:

DNS resolution works correctly.
Hostnames are unique.
Required Kubernetes ports are open.
Firewall rules permit node-to-node communication.
Time synchronization is configured using NTP or chrony.

Reliable networking prevents many common installation failures.

Choosing an Installation Method

There are multiple ways to deploy Kubernetes depending on your goals.

kubeadm

kubeadm is the standard tool for bootstrapping self-managed Kubernetes clusters.

Choose kubeadm if you want:

A production-capable installation
Full control over cluster configuration
Hands-on Kubernetes administration experience
On-premises deployments

This guide uses kubeadm throughout.

Kind

Kind (Kubernetes in Docker) creates lightweight clusters inside Docker containers.

It is ideal for:

Local testing
CI pipelines
Kubernetes development
Learning basic concepts

Kind is not intended for production workloads.

Minikube

Minikube runs a single-node Kubernetes cluster on a local workstation.

It's well suited for:

Beginners
Local application testing
Classroom environments
Feature exploration

K3s

K3s is a lightweight Kubernetes distribution optimized for resource-constrained environments.

Common use cases include:

Edge computing
IoT deployments
Home labs
Small production clusters

Managed Kubernetes Services

Cloud providers also offer fully managed Kubernetes platforms.

Examples include:

Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE)

Managed services reduce operational complexity by handling control plane provisioning, upgrades, availability, and infrastructure management. They are often the preferred choice for enterprise production environments.

Preparing Linux Nodes

Most Kubernetes installation problems originate from incomplete operating system preparation rather than Kubernetes itself.

Before running kubeadm, configure every node consistently.

Update the Operating System

Install the latest security patches and package updates before installing Kubernetes components.

Keeping nodes current improves stability and reduces compatibility issues.

Configure Hostnames

Assign a unique hostname to every server.

For example:

control-plane
worker-01
worker-02

Consistent naming makes administration and troubleshooting much easier.

Disable Swap

Kubernetes expects swap to be disabled unless explicitly configured otherwise.

Verify that swap is disabled both temporarily and permanently before initializing the cluster.

Configure the Container Runtime

Modern Kubernetes installations should use containerd or another CRI-compatible runtime.

Verify that:

The container runtime starts automatically.
The runtime uses the systemd cgroup driver when appropriate.
Kubernetes can communicate with the runtime through the CRI interface.

Enable Required Kernel Features

Linux must support Kubernetes networking.

Enable:

IP forwarding
Bridge network packet processing
Required kernel modules

These settings allow Pods and Services to communicate correctly across nodes.

Verify Time Synchronization

Certificates, authentication, and distributed systems rely on accurate system time.

Configure NTP or chrony so that every node maintains synchronized clocks.

Confirm Node Connectivity

Before initializing the cluster, verify:

Nodes can reach one another.
DNS resolution functions correctly.
Required firewall ports are accessible.
Hostnames resolve consistently.
The container runtime is healthy.

Completing these preparation steps significantly reduces installation failures and provides a stable foundation for the Kubernetes control plane and worker nodes.

Step-by-Step: Set Up a Kubernetes Cluster with kubeadm

Once your Linux nodes are prepared, you can bootstrap the Kubernetes cluster using kubeadm. The following workflow reflects current Kubernetes installation practices and provides a solid foundation for both learning and production deployments.

Step 1: Initialize the Control Plane

Run the initialization command on the control plane node:

sudo kubeadm init \
  --pod-network-cidr=192.168.0.0/16

Note: The --pod-network-cidr value depends on the Container Network Interface (CNI) plugin you plan to use. Always follow your chosen CNI's official documentation.

Initialization performs several tasks automatically:

Creates Kubernetes certificates
Starts the control plane components
Initializes the etcd database
Generates an administrator kubeconfig
Produces a kubeadm join command for worker nodes

Keep the generated join command—you'll use it later when adding worker nodes.

Configure kubectl

After initialization, configure kubectl for your current user:

mkdir -p $HOME/.kube

sudo cp /etc/kubernetes/admin.conf \
$HOME/.kube/config

sudo chown $(id -u):$(id -g) \
$HOME/.kube/config

Verify connectivity:

kubectl cluster-info

Then check the control plane:

kubectl get nodes

Initially, the control plane will usually report NotReady until networking is installed.

Install a Container Network Interface (CNI)

Kubernetes requires a CNI plugin so Pods can communicate across nodes.

Three of the most common choices are:

Calico

Best for:

Production environments
Network Policies
Enterprise deployments
Hybrid cloud

Cilium

Best for:

eBPF networking
High-performance networking
Advanced observability
Modern Kubernetes clusters

Flannel

Best for:

Learning Kubernetes
Small labs
Simple networking requirements

Although Flannel remains useful for education, Calico and Cilium are generally preferred for production because they provide stronger networking and security capabilities.

Install the CNI plugin according to its official documentation. After installation, wait a few moments and verify node readiness:

kubectl get nodes

A successful installation should display the control plane node with a Ready status.

Join Worker Nodes

On each worker node, execute the join command generated during initialization.

It typically resembles:

sudo kubeadm join CONTROL_PLANE_IP:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

If the token expires, generate a new one from the control plane:

kubeadm token create \
--print-join-command

After joining, return to the control plane and verify:

kubectl get nodes

You should now see both the control plane and worker nodes listed.

As your environment grows, additional workers can be added using the same process.

Verify Cluster Health

Before deploying applications, validate that the cluster is operating correctly.

Useful commands include:

kubectl get nodes

kubectl get pods -A

kubectl get events

kubectl version

Healthy clusters should show:

All nodes in the Ready state
System Pods running successfully
No repeated scheduling failures
No persistent CrashLoopBackOff errors

Resolving issues early prevents larger deployment problems later.

Deploy a Sample Application

A simple deployment confirms that scheduling, networking, and Services are functioning correctly.

Create an NGINX deployment:

kubectl create deployment nginx \
--image=nginx

Expose it as a Service:

kubectl expose deployment nginx \
--port=80 \
--type=NodePort

Verify the deployment:

kubectl get deployments

Check the Pods:

kubectl get pods

View the Service:

kubectl get svc

If everything is healthy, Kubernetes has successfully scheduled the workload and exposed it through a Service.

Storage Basics

Most real-world applications require persistent storage.

Kubernetes separates compute from storage using several abstractions.

Important concepts include:

Persistent Volumes (PV) provide storage resources.
Persistent Volume Claims (PVC) request storage.
Storage Classes dynamically provision storage.
CSI Drivers integrate Kubernetes with cloud and on-premises storage systems.

Examples of storage backends include:

AWS EBS
Azure Managed Disks
Google Persistent Disk
NFS
Ceph
Longhorn

Avoid relying on local node storage for production databases unless your architecture explicitly supports it.

Security Hardening

Cluster security should be considered from the beginning rather than added later.

Recommended practices include:

Enable Role-Based Access Control (RBAC).
Use least-privilege permissions.
Encrypt Kubernetes Secrets at rest.
Enable audit logging.
Keep Kubernetes components updated.
Restrict API Server access.
Use Network Policies to isolate workloads.
Scan container images before deployment.
Rotate certificates and credentials regularly.

Also consider implementing:

Admission controllers
Pod Security Admission
Image signature verification
Runtime threat detection

Security is a continuous process, not a one-time configuration.

Monitoring and Observability

Production clusters require comprehensive visibility into system health.

A typical monitoring stack includes:

Prometheus for metrics collection
Grafana for dashboards
Alertmanager for notifications
OpenTelemetry for telemetry
Loki or Elasticsearch for centralized logging

Monitor key metrics such as:

Node CPU and memory utilization
Pod restart counts
API Server latency
etcd health
Disk usage
Network performance

Establish alerts before production workloads are deployed to reduce incident response times.

Common Pitfalls

Even experienced administrators encounter issues during cluster setup.

The most common problems include:

Nodes Remain NotReady

Usually caused by:

Missing CNI plugin
Network configuration errors
Container runtime issues

Pods Stuck in Pending

Possible causes include:

Insufficient resources
Missing Storage Class
Node scheduling constraints
Taints and tolerations

ImagePullBackOff

Typically indicates:

Incorrect image name
Registry authentication failure
Network connectivity issues

Certificate Errors

Often caused by:

Incorrect system time
Expired certificates
Cluster upgrades that were not completed correctly

Version Compatibility

Keep these components within the supported version skew policy:

kubeadm
kubelet
kubectl

Mixing incompatible versions can lead to unexpected cluster behavior.

Self-Managed vs Managed Kubernetes

Self-managed Kubernetes provides maximum flexibility but also requires ongoing operational responsibility.

Choose a self-managed cluster when you need:

Full infrastructure control
Custom networking
On-premises deployments
Specialized security requirements

Managed Kubernetes services such as Amazon EKS, Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE) reduce operational overhead by handling:

Control plane management
Automatic upgrades
High availability
Infrastructure maintenance
Integrated cloud services

For many organizations, managed Kubernetes is the preferred production option, while self-managed clusters remain valuable for edge deployments, private infrastructure, and learning Kubernetes internals.

Best Practices

To build a reliable Kubernetes environment:

Standardize operating system images.
Use Infrastructure as Code for cluster provisioning.
Automate upgrades and patch management.
Back up etcd regularly.
Monitor cluster health continuously.
Implement GitOps workflows for deployments.
Apply resource requests and limits.
Use namespaces to organize workloads.
Enable Network Policies where appropriate.
Test disaster recovery procedures regularly.

Treat the cluster itself as critical infrastructure that requires ongoing maintenance and operational discipline.

Conclusion

Setting up a Kubernetes cluster is more than running a few installation commands—it involves preparing the operating system, selecting the appropriate container runtime, configuring networking, validating cluster health, and implementing security and monitoring from day one.

Using kubeadm provides valuable insight into Kubernetes internals and remains an excellent choice for administrators who want full control over their infrastructure. For production environments, pairing a well-designed cluster with automation, observability, regular upgrades, and strong security practices results in a resilient platform capable of supporting modern cloud-native applications.

Whether you're building a development lab or deploying enterprise workloads, mastering Kubernetes cluster setup establishes the foundation for scalable, reliable, and maintainable container orchestration.

Frequently Asked Questions

What is the easiest way to set up a Kubernetes cluster?

For local development, Kind and Minikube provide the quickest experience. For learning production concepts or deploying on your own infrastructure, kubeadm is the recommended option.

How many nodes are required?

A basic cluster consists of one control plane and one worker node. Production deployments commonly use multiple control plane nodes and several worker nodes to improve availability and scalability.

Which container runtime should I use?

Modern Kubernetes clusters typically use containerd or CRI-O because they implement the Kubernetes Container Runtime Interface (CRI) and are actively supported.

Which CNI plugin is best?

There is no universal best choice. Calico is widely used for enterprise networking and Network Policies, while Cilium is popular for eBPF-based networking and advanced observability. The right option depends on your operational requirements.

Can Kubernetes run on Windows?

The Kubernetes control plane is generally deployed on Linux. Windows can host compatible worker nodes for Windows containers, while developers can use WSL2, Docker Desktop, or virtual machines for local learning.

Is a self-managed Kubernetes cluster free?

Kubernetes itself is open source. Running a self-managed cluster does not require licensing fees, but infrastructure, storage, networking, monitoring, and operational costs still apply.