Giving back: understanding Kubernetes with kubeadm

VoiceRAG connected my networking background with software and AI infrastructure. Kubernetes was part of that work, but the platform still depended on ordinary fundamentals: reachable machines, correct names, usable storage, and a functioning network.

The kubeadm lab makes those layers visible. Terraform provisions Ubuntu guests on Proxmox; Ansible prepares the operating systems and Kubernetes components. The example uses one control plane and two workers, which is a learning topology rather than a highly available control plane.

Start before the first pod

Choose node addresses and pod and service CIDRs that do not overlap with your LAN or other connected networks. Check routing, time, name resolution, and access from the administrator's machine. Those choices affect whether a cluster can communicate with its own services and the systems around it.

The networking configuration is not an invitation to disable the firewall until installation succeeds. Read the ports and traffic paths, then permit the paths you actually need. The example's CNI configuration is part of that design.

Test the path, not just the status

A Ready node is useful evidence, but it does not answer every networking question. Test pod-to-pod traffic across nodes, service resolution, and the intended external dependency. A cluster can show healthy components while an application still cannot reach its database.

The same idea applies to storage. This lab does not magically provide a durable storage system. A workload that requests a persistent volume needs an appropriate provisioner and an explicit recovery plan.

Keep management choices separate

You can maintain the cluster's code and delivery in GitHub or GitLab. GitLab users can later configure the Kubernetes agent for authorized CI access; GitHub users do not need that agent to follow their own deployment path. Neither agent access nor a one-time pipeline is continuous reconciliation. The series guide explains where a GitOps controller can fit.

The benefit I want readers to get is confidence in the layers underneath a workload. That understanding transfers to platform, SRE, and AI infrastructure work even when the next cluster is managed by a cloud provider.