Learn Calico - Prerequisite Skills & Environment Setup

#Introduction

Welcome to the Learn Calico series! This series will take you through Project Calico — the CNI and network security engine for Kubernetes — from the core concepts all the way to production-grade architecture. There are 23 episodes in total, organized into six phases.

But before you touch calico at all, there are some core skills and software you must have. Why are these prerequisites important? Because Calico is not just a plugin that assigns IP addresses to pods. It manages routing between nodes via BGP, programs iptables/nftables or eBPF for network policy, and manages IPAM. Without a basic understanding of Kubernetes and Linux networking, all of that machinery will feel like a black box.

Episode 0 is your roadmap: make sure you have the core skills, set up a test cluster, install a stable version of Calico Open Source, and run your first verification. Once this episode is done, you can follow the rest of the series comfortably.

#Prerequisite Skills You Must Master

#Kubernetes: Pod, Service, and NetworkPolicy

You should be comfortable with the core Kubernetes objects: Pod, Service, Namespace, and Node. Also understand that kubelet calls the CNI when a pod is created — that is Calico's entry point into the cluster. The thing most frequently tested in this series is NetworkPolicy, so make sure you understand label selectors and ingress/egress rules.

#Linux Networking, BGP, and Network Namespaces

Calico runs on top of Linux routing and BGP. You need to understand ip route, iptables/nftables, VETH, and network namespaces, because those are what Felix programs. For BGP, you only need the basics: neighbor, peering, AS number, and prefix advertisement.

#CLI: kubectl, Helm, and calicoctl

Three tools are used throughout the series. Verify their versions now:

kubectl version --client
helm version --short
calicoctl version

kubectl version --client confirms kubectl is installed, and calicoctl version will be covered in more detail shortly. If calicoctl is not installed yet, don't worry — how to install it is at the bottom of this episode.

#Software and Environment to Prepare

#Test Cluster with kind

The lightest test cluster is kind (Kubernetes in Docker). We use the pod subnet 192.168.0.0/16 so it stays consistent with Calico's default IPPool:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  podSubnet: 192.168.0.0/16
  serviceSubnet: 10.96.0.0/12
  disableDefaultCNI: true

Save it as kind-config.yaml, then create the cluster:

kind create cluster --name calico-lab --config kind-config.yaml
kubectl get nodes

The disableDefaultCNI: true field disables kind's built-in CNI so Calico can take over later. Until Calico is installed, the nodes will show NotReady — that is normal.

#Install Calico via the Tigera Operator

The official way is the Tigera Operator, which can be installed via Helm:

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm install calico projectcalico/tigera-operator --version v3.32.1
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/custom-resources.yaml
kubectl get pods -n calico-system -w

Wait until the pods in the calico-system namespace reach Running and the nodes turn Ready. The operator will deploy calico-node (DaemonSet), typha (Deployment), and kube-controllers. We dissect each of these components one by one starting in episode 2.

#calicoctl and the calico CLI

calicoctl is the Calico management CLI. Install the stable version:

curl -LO https://github.com/projectcalico/calico/releases/download/v3.32.1/calicoctl-linux-amd64
chmod +x calicoctl-linux-amd64
sudo mv calicoctl-linux-amd64 /usr/local/bin/calicoctl
calicoctl version

Besides calicoctl, there is a newer CLI named calico that can be installed as a kubectl plugin: kubectl krew install calico, then use it as kubectl calico. Both read the same datastore, so pick whichever is most comfortable for you.

#First Environment Verification

Once the cluster is Ready, run a full verification:

calicoctl node status
calicoctl get nodes
calicoctl get ippool

calicoctl node status shows the status of the Calico processes and the BGP status of each peer. On a single-node cluster, you will see a peer of type node-to-node mesh with status Established. calicoctl get ippool confirms that the default 192.168.0.0/16 IPPool has been created.

Also try deploying a pod to confirm networking works:

kubectl run nginx --image=nginx
kubectl get pod nginx -o wide
kubectl exec nginx -- curl -s -o /dev/null -w "%{http_code}" http://nginx

If it returns 200, your test cluster is ready. Final confirmation: make sure all these commands run without error, then note the installed Calico version — this series uses Calico Open Source v3.32.1.

#Conclusion

In episode 0 you set the foundation for the whole series: mastering the Kubernetes, Linux networking, and CLI prerequisites; creating a kind cluster with the CNI disabled; installing Calico via the Tigera Operator; setting up calicoctl; and verifying the dataplane and BGP status.

Key takeaways:

• Main prerequisites: Pod/Service/NetworkPolicy, routing and iptables/nftables, and basic BGP.
• The test cluster uses kind with disableDefaultCNI: true so Calico can take over.
• The official installation uses the Tigera Operator via Helm at version v3.32.1.
• calicoctl node status is the first gateway for checking dataplane health.
• The default 192.168.0.0/16 IPPool should show up in calicoctl get ippool.
• Final confirmation: the nginx pod is reachable and returns HTTP code 200.

In the next episode, episode 1, we'll discuss the history, background, and why you need Calico — from Calico's birth at Metaswitch Networks in 2014, the wire-rate routing mission instead of overlay, to its position as the most widely adopted CNI in Kubernetes. Make sure your environment is ready, because the Learn Calico journey is just beginning!