Choosing and Installing a CNI Plugin

Installation and Cluster Builds / Guide 11 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 30 min

Interface names, block boundaries and VXLAN device IDs are generated per cluster and will differ on yours. The shape of the output is what to compare.

• Calicov3.32.1
• Pod CIDR10.244.0.0/16

This guide includes

Use this when a fresh cluster's nodes are NotReady and nothing will schedule. This matters because Kubernetes defines a network model and deliberately refuses to implement it, so a new cluster is incomplete until you choose a plugin.

• reading the node condition that says exactly why a fresh cluster is not Ready
• choosing between Calico, Cilium and Flannel on what each one actually gives you
• installing Calico as an operator, waiting for its CRDs before configuring it
• finding what a CNI writes to a node - a conflist, a binary, and one address block per node
• reading the routes and the unused VXLAN device, then proving Pods on different nodes can reach each other

Before you start

• A cluster built with kubeadm init --pod-network-cidr=..., with or without a CNI already installed.
• kubectl access, and SSH to at least one node for the on-disk parts.
• Knowing your node subnet. It changes which encapsulation mode does anything.

1. 1

   Why the cluster does not ship with one

2. 2

   Choosing: Calico, Cilium or Flannel

3. 3

   Install Calico, CRDs first

4. 4

   What it wrote to disk

5. 5

   One address block per node

6. 6

   The routes, and the encapsulation it is not using

7. 7

   What Calico runs, and where

8. 8

   Prove pods on different nodes can talk

Official sources

• Cluster networking and the Kubernetes network model
• Network plugins (CNI)
• Calico: configure IP pools and encapsulation
• Cilium: getting started