Insights, news, and Kubernetes field notes.

Most shops did not plan to be mixed. A rack of Dell arrived with one project, HPE with the next, a few Supermicro boxes came in for storage, and now every job starts with the question of which tool to open. iDRAC for the Dells, iLO for the HPEs, SSH everywhere, and a spreadsheet to remember which is which.

Ruckos removes the question. The operating system is the same image on every box, and the node API is the same on every box. The server's own identity — manufacturer, model, board, firmware — is read from its firmware and shown in the tools, and then it stops mattering: the disks are listed, partitioned, formatted and shared the same way; the network card, address, DNS and NTP are set the same way; the role — hypervisor, storage, Kubernetes — is given the same way; the build is upgraded, and rolled back if it fails, the same way. rctl, ruckos-v and Lighthouse are three ways to say the same thing to the same API.

There is nothing to log into. Ruckos has no SSH, no RDP, no VNC on a host, and no vendor agent; the API is the only way in, and it is the same API whether the node is a Dell in the rack, a Supermicro in the storage row or a VM on a hypervisor. A new box is a USB stick and a keystroke; after that it is a row in the console like every other row.

One thing stays with the vendor, on purpose. Powering a dead server on, changing BIOS settings and flashing firmware are the job of the lights-out controller — iDRAC, iLO, XClarity — and Ruckos does not pretend otherwise. Keep the lights-out card. Replace everything after power-on.

Previously in this series: installing Ruckos on bare metal, the seven screens that are the same on every vendor's hardware.

Ruckos Linux installs the way a hypervisor should: boot the image, pick a disk, say how much of it the OS gets, reboot. The whole thing is a 155 MB image and three small partitions. The same image boots from a USB stick, a DVD or PXE; this walkthrough uses USB. Here is every screen you will see on a Dell, HPE or Supermicro box, in order.

1. Pick the disk

Ruckos lists whatever the hardware presents. A RAID controller's virtual disk shows up under its own name (the PERC above), right next to the NVMe drives. Set the controller up however you like in its own menus first; Ruckos installs on what it sees.

2. This screen is skipped on a blank drive.

If the disk already holds a Ruckos install, the installer tells you which host it was and which cluster it was in, and waits for R. Esc reboots without touching anything.

3. Decide how much Ruckos gets

Ruckos needs very little: 1 GB for EFI, a STATE partition for its configuration and logs, and a BIOS boot stub. We give it 10 GB and leave the rest of the disk free. That free space is what becomes the VM store on a hypervisor, or the shares on a storage node, later and from a tool, not from this keyboard. Press Enter on its own and Ruckos takes the whole disk, which is right for a Kubernetes node.

4. Install

The partitions are created, the image is copied, a UEFI boot entry named RuckOS is written (and GRUB for machines that still boot BIOS), and the node reboots on its own. Pull the USB stick.

5. First boot

The node comes up read-only, takes a DHCP address, generates its hostname and sits in the maintenance role. Its API is already listening, so from here on you can leave the console: rctl, Ruckos-V Manager and Lighthouse all see it now.

6. The console menu

Press any key and you get the only menu Ruckos has. Static addressing and NTP if DHCP is not how your data center works; the role and cluster name; a list of anything that went wrong this boot. There is no shell behind it.

7. Give it a role

h makes it a hypervisor; s makes it a storage server that shares the free space over NFS; c, e and w make it a Kubernetes node. You can also set the role from rctl or Lighthouse instead and never open this menu at all.

Next in this series: the hypervisor role, from the free space to the first VM to a three-host cluster, and the storage role, a chassis of NVMe serving every hypervisor.

rctl bootstrap platform --site config/site.yaml

RapidHire pairs a Neo4j graph database with contextual skill extraction and vector search to surface the strongest candidate-to-job matches.

Contextual, weighted matching

Skills are extracted with importance weighting — critical, important, or preferred — based on how they appear in the job description, then matched against candidate profiles using cosine similarity over dimensional embeddings. Matches are ranked by critical-skill coverage first, overall weighted score second.

Built for scale and privacy

PII is scrubbed before any resume text reaches an LLM, bulk uploads are processed independently of job assignment, and the LLM/embedding backend is swappable — Ollama, OpenAI, Gemini, or AWS Bedrock — so teams can run fully on-prem if required.

An Enterprise-grade self-service developer portal that hands each developer their own Kubernetes namespace and a catalog of resources they can provision into it on demand — Postgres, MySQL, Redis, Neo4j, or a ready-to-run .NET API scaffold — without opening a ticket or waiting on a platform engineer.

From provision to IDE in one step

Once a resource is provisioned, the portal can drop the generated project straight into a Git repo through a GitHub App integration and hand you a one-click "open in VS Code" link.

Identity-aware from the start

Access is brokered through OIDC via Keycloak, so every provisioning action is tied to a real identity rather than a shared service account. Internal Developer Portal ships as a Helm chart, so it deploys into your cluster.

rctl.exe bootstrap etcd --site config/raft/raft.yaml

rctl.exe bootstrap --site config/ruckos/ruckos.yaml --type external

Broadcom's acquisition of VMware rebuilt the commercial model around subscription bundles like VMware Cloud Foundation, priced on a per-core basis with a 16-core-per-processor minimum, and pushed customers toward packaged suites instead of à la carte purchasing. The result has been sticker shock: industry surveys put the share of organizations actively shrinking their VMware footprint in the high 80s percent, with some renewal quotes reported north of 1,000% over prior terms once minimum commitments and bundling are factored in.

Microservices and private cloud, not just cost control

The response isn't only a negotiation tactic. Platform teams are using the forced renewal conversation as cover to do work they wanted to do anyway: breaking monolithic, VM-hosted applications into containerized microservices and running them on a self-operated private cloud, so the exit from one vendor doesn't just walk into another one. GitOps delivery (Argo CD, Flux), the Gateway API, and policy-as-code — the same practices in our Kubernetes best-practices list above — are becoming the default operating model in place of click-ops through vCenter.

AI is riding the same wave

That modernization push is colliding with a second one: running AI workloads in-house instead of shipping proprietary data to a third-party API. Open-weight models — Llama, Mistral, Qwen, DeepSeek, and others — are now good enough for a large share of internal use cases, and serving them locally with vLLM, Ollama, or TGI keeps sensitive data inside the perimeter and turns a per-token bill into a fixed infrastructure cost.

The hardware catching up

Server vendors have followed. Dell's PowerEdge R760xa packs up to four double-width GPUs into a mainstream rack form factor, while the XE-series scales to eight GPUs per node for larger models; HPE's ProLiant DL380a Gen11 targets the same workload with validated NVIDIA configurations up to H100/H200 and L40S. Paired with a Kubernetes-based private cloud, that hardware turns local LLM inference into just another workload on the same GitOps-managed clusters running everything else — which is exactly the seam platforms like Ruckos and lighthouse are built to sit in.