Mission Parameters & Architectural Vision

The objective of this engineering initiative is to transition the Squirrelworks lab ecosystem away from legacy virtualization models and establish a hardened, production-grade Multi-Node Kubernetes cluster. By leveraging the security and efficiency profiles of enterprise-tier Open Source utilities, this bare-metal platform is built to deliver highly stable, self-healing runtime behaviors under rigorous bare-metal constraints.

Primary Infrastructure Targets

The Entropy Reduction Blueprint

This cluster setup functions as a technical playbook for predictable, scalable operations. Eliminating intermediate application abstractions and decoupling the underlying container runtime networking guarantees deterministic performance behaviors across the entire compute host layer.

1. Provisioning the Rocky Linux 9 Base

To establish a resilient cloud-native control plane, the master node was deployed on a minimal Rocky Linux 9 virtual instance within Proxmox. Standard network plumbing was locked down via SSH key integration, providing a stable foundation for the enterprise-grade Rancher Kubernetes Engine (RKE2).

2. Decoupling the Network Layer (CNI Switch)

During initial orchestration, a custom manifest was staged at /etc/rancher/rke2/config.yaml to inject the directive cni: none. This intentional override completely bypassed the default Canal network plugin, preventing the cluster API from establishing standard routing mechanisms and placing the control plane into a deliberate network holding pattern.

The Intentional NotReady Safe-State

By running kubectl get nodes post-initialization, the node safely defaults to a NotReady state. This is not an error—it is an expected architectural behavior proving the API server is up, running, and securely waiting for an advanced eBPF network fabric to claim its interface.

1. Static Token Authentication

Expanding the multi-node infrastructure required staging the secondary machine, rocky-worker-01. By linking the cryptographic joint token from the primary supervisor log into the worker's configuration path at 192.168.0.198, an ironclad hardware-to-host handshake was verified.

2. Remediation: Post-Crash State Alignment

Following a system-level interruption right after package deployment, a forensic review showed that while the rke2-agent.service was enabled, it had never actively executed. Resolving this discrepancy involved executing a live daemon state change on the worker host CLI:

The node cleanly entered the runtime cluster matrix, aligning its age telemetry in the control plane database without throwing a single TLS handshake anomaly.

1. Minimal OS Path Constraints

Because RKE2 strips internal runtime folders down to raw core mechanics, an investigation of the internal path structure revealed that standard utilities like helm were excluded from the binary profile layer. Attempts to establish quick symlinks failed due to the nonexistent target paths within the core orchestration directories.

2. Restoring the Upstream Binary Matrix

To bypass the minimal OS constraints of Rocky Linux without cluttering environment path files, the pure vanilla upstream binary for Helm v3 was downloaded. Because the minimal OS profile lacked native archive decompression capabilities, the package manager was used to inject the toolset required to place and flag the execution rights:

The Happy Helming Milestone

With the physical binary safely bound into /usr/local/bin/helm, index tables updated flawlessly. Injecting the official Cilium stable repository securely hooks our local system straight into the eBPF staging yard...