Building a Multinode Cluster for High Availability

Running Kubernetes locally with multiple nodes gives you a realistic cluster experience without needing cloud infrastructure. In this guide, I will guide with the set up a multinode Kubernetes cluster using Minikube on your local machine .

Architecture

What You’ll Need

Before we begin, make sure you have the following installed on your machine:

Tools Minikube, Kubectl, RAM(8 GB+), CPU (4+ core)

Key Concept: Each Node Has Its Own Network Stack

One of the most important things to understand about a multinode cluster is that each node has its own network stack — its own IP address, routing table, iptables rules, and network interfaces. This is what makes inter-node communication non-trivial, and why a Container Network Interface (CNI) plugin is essential.

Lets get started with setting up Multinode cluster.

Step 1: Start the Multinode Cluster

Use the --nodes flag to specify the total number of nodes (1 control plane + N workers):

minikube start \
  --nodes 3 \
  --driver=virtualbox \
  --cpus=2 \
  --memory=2048 \
  --cni=calico

Tip: Use --memory=4096 if you have enough RAM. Memory-starved nodes can cause intermittent failures

Step 2: Verify Node Status

kubectl get nodes -o wide

Step 3: Label Your Worker Nodes

kubectl label node minikube-m02 node-role.kubernetes.io/worker=worker
kubectl label node minikube-m03 node-role.kubernetes.io/worker=worker

Step 4: Deploy a Test Workload Across Nodes

Let’s deploy an Nginx app spread across both worker nodes:

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-multinode
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: nginx
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Apply it

kubectl apply -f nginx-deployment.yaml

You should see pods distributed across minikube-m02 and minikube-m03.

Networking: How Nodes Communicate (CNI with Calico)

Why CNI Is Needed

Since each node has its own network stack and IP range, Pods on different nodes cannot communicate by default. That means nginx in node 02 cannot communicate with nginx in node 03. The CNI plugin bridges this gap by:

1. Assigning each node a Pod CIDR (subnet for Pods on that node)
2. Creating overlay or BGP routes so Pods on Node A can reach Pods on Node B
3. Managing network policies to control traffic between Pods

Calico in Action

When you start Minikube with --cni=calico, it automatically deploys Calico as a DaemonSet on every node:

kubectl get pods -n kube-system | grep calico

Expected Output

calico-kube-controllers-xxx   1/1   Running
calico-node-abc12             1/1   Running   # on minikube
calico-node-def34             1/1   Running   # on minikube-m02
calico-node-ghi56             1/1   Running   # on minikube-m03

calico-node runs on every node and is responsible for programming the routing rules on that node's network stack.

Pod-to-Pod Communication Across Nodes

Here’s what happens when a Pod on Node 1 talks to a Pod on Node 2:

Pod A (Node 1: 10.244.1.5)
  → Calico routes packet to Node 2 (192.168.49.3)
    → Node 2's Calico receives it
      → Delivers to Pod B (10.244.2.7)

Each node’s Pod CIDR is visible via:

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

Network Policy Example

With Calico, you can enforce network policies. For example, to allow only frontend pods to talk to backend pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

kubectl apply -f network-policy.yaml

Testing Cross-Node Connectivity

Verify Pods on different nodes can communicate:

# Get IPs of pods on different nodes
kubectl get pods -o wide

# Exec into a pod on Node 1
kubectl exec -it <pod-on-node1> -- sh

# Ping a pod on Node 2
ping <pod-ip-on-node2>

If Calico is correctly configured, the ping should succeed across nodes.

Useful Commands for Managing Your Multinode Cluster

# Check cluster status
minikube status

# SSH into a specific node
minikube ssh --node minikube-m02

# Stop the cluster
minikube stop

# Delete the cluster
minikube delete --all

# Add a node later
minikube node add

# Remove a node
minikube node delete minikube-m03

✋ follow for more such articles.

💬 Enjoyed this post or found it helpful? Leave a comment and clap.

About Sakshi: A cloud & DevOps Engineer and technical writer with 5 + years of experience. Sakshi helps organisation implement with cost-effective infrastructure setup with security implementation.