The network layer: Calico, installed from a manifest
Kubernetes deliberately ships without a network. You choose a CNI plugin and install it. I used Calico, applied from its plain manifest:
kubectl apply -f https://.../calico/<version>/manifests/calico.yaml
A couple of deliberate choices:
- Manifest, not the operator. Calico can be installed via its Tigera operator (a controller that manages Calico for you) or via a single flat manifest. I chose the manifest. For a lab, the manifest is legible — it's one file you can read top to bottom and see exactly what lands on the cluster (a DaemonSet, RBAC, CRDs). The operator is the right call when you want lifecycle management; the manifest is the right call when you want to learn.
- It matches the pod CIDR I gave
kubeadm(192.168.0.0/16), so there's nothing to reconcile.
Within a minute the calico-node pods come up on every node and the nodes flip to Ready. That moment — watching NotReady become Ready right after the CNI lands — is the clearest demonstration of what a CNI actually does.
Why we use this: Calico is boring in the best way. It's widely used, it does straightforward L3 networking with sane defaults, and "install one manifest" is hard to beat for a lab. The choice of manifest over operator is itself a teachable habit: prefer the version you can read and reason about until you specifically need the automation.
No comments to display
No comments to display