Kubernetes

Architecture

The lab uses k3s (Lightweight Kubernetes from Rancher) for container orchestration across the infrastructure:

• <strong>k3s\_server</strong>: Master node running k3s control plane (host: head2, referenced but unreachable in current audit)
• <strong>k3s\_agent</strong>: Worker nodes that register with the server and receive workloads
• <strong>GPU nodes</strong>: Specialized workers for NVIDIA container runtime and compute workloads

Version Pinning

k3s version is pinned to the 2.1.x series (specifically 2.1.5 as of the latest network\_update.sh). This prevents surprise breakage from upstream k3s releases. The pinning policy follows:

\begin{lstlisting}[style=mystyle]

K3S_VERSION="2.1.5"

curl -sfL https://get.k3s.io | sh -s - \

--write-kubeconfig-mode 644

    \end{lstlisting}

Container Runtime

k3s uses containerd as the default runtime, with NVIDIA Container Toolkit for GPU workloads:

• <strong>nvidia-container-toolkit</strong>: Installed on GPU nodes via the network\_update.sh automation
• <strong>containerd config</strong>: Located at \texttt{/var/lib/rancher/k3s/agent/etc/containerd/config.toml}
• NVIDIA runtime configured in containerd to expose GPU devices to containers

Cluster Topology

tabularx}{}{l l X}

<strong>Node Role</strong> & <strong>Target Hosts</strong> & <strong>Notes</strong> \\

---

k3s\_server & head2 (planned) & Control plane; not yet online\\

k3s\_agent & node900, node901, node903 & Jetson nodes as workers\\

nvidia\_nodes & GPU-equipped hosts & Container Toolkit + k3s agent

tabularx}

kubeconfig Access

After installation, kubeconfig is written to /etc/rancher/k3s/k3s.yaml} with mode 644. Cluster access requires:

• SSH key auth to the k3s\_server host
• Reading the kubeconfig file (or copying it securely)
• \texttt{kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml cluster-info} to verify connectivity

The k3s_server role and k3s_agent role in lab-franklin handle the installation and configuration of these nodes via Ansible.