Building a sovereign Kubernetes cluster with Talos Linux and Ceph storage

Many organizations today want full control over their infrastructure. They need something secure, easy to manage, and free from vendor lock-in. A combination that works well is Talos Linux for Kubernetes nodes and Ceph for persistent storage. This setup gives you an API driven Kubernetes platform where the operating system is immutable at runtime, combined with scalable open source storage, all running on your own hardware or in a trusted data center.

At Fairbanks we have built several of these sovereign stacks for customers who prioritize data residency and independence. The result is a platform designed with a reduced attack surface, straightforward operations, and readiness for production workloads.

Here is a practical overview of how we approach it and the key decisions that make it work reliably.

Talos Linux is a minimal operating system designed specifically for running Kubernetes. While workloads and storage systems such as Ceph rely on persistent disks, the Talos operating system itself is immutable at runtime and exposes no shell or package manager. Configuration is managed declaratively through the Talos API using YAML based machine configurations, which reduces the attack surface and makes upgrades predictable.

Ceph provides the storage layer. It integrates natively via the Ceph CSI driver and handles block, file, and object storage from the same cluster. Because both components are fully open source, you avoid licensing surprises and keep everything under your control.

• Control plane nodes: Three talos control plane nodes for high availability
• Worker nodes: Scales based on workload requirements
• Ceph cluster: Typically runs on the same worker nodes with co located OSDs, or on dedicated storage nodes for larger environments
• Networking: Standard CNI, currently using Flannel. Calico and OVN are being evaluated for future setups

Getting started step by step

1. Prepare the machines: Boot the nodes from the Talos ISO or use PXE/iPXE. Talos will come up in maintenance mode waiting for configuration.
2. Generate configuration files: Use talosctl to create machine-specific configs: talosctl gen config my-cluster https://kubernetes-api.example.com:6443 Then apply patches for your needs (VIP for control plane, extra endpoints, etc.).
3. Apply configs and bootstrap: On each node: talosctl apply-config –insecure -n <node-ip> –file <config.yaml>Once control plane nodes are ready: talosctl bootstrap -n <first-control-plane-ip>
4. Install Ceph: We usually deploy Ceph with Rook. Create a Rook operator and then a CephCluster CR with your desired OSD placement (on all workers or specific nodes). Enable the CSI drivers for RBD and CephFS.
5. Create storage classes: Define StorageClasses for replicated pools (high performance) and EC pools (cost-efficient). Example for a replicated RBD class:

YAML

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: ceph-rbd-replicated

provisioner: rbd.csi.ceph.com

parameters:

clusterID: rook-ceph

pool: kubernetes-replicated

imageFeatures: layering

reclaimPolicy: Delete

• Use a virtual IP (like MetalLB or keepalived) for the Kubernetes API so the cluster survives node failures.
• Start with replicated pools for stateful apps, then add EC pools once you have enough nodes for proper placement.
• For air-gapped environments, mirror the required container images and Talos binaries beforehand.

This stack gives you a Kubernetes platform that is secure, sovereign, and straightforward to maintain. Upgrades are just a new Talos version and a rolling kubectl cordon/drain/upgrade cycle. Storage scales independently with Ceph.

If you are planning a new cluster or migrating away from proprietary solutions, this approach has proven reliable for many of our customers.

Want to discuss your specific setup or need help with the first steps? Reach out to us at Fairbanks. We offer everything from consultancy to fully managed deployments.

What challenges are you facing with your current infrastructure? Let us know in the comments.

Leaders can improve independence without large transformations. A few practical steps include:

1. Increase visibility across systems and data

Map critical systems, understand where data flows, and identify where the strongest dependencies exist. Visibility creates the foundation for better decisions.

2. Introduce open source components where it adds value

Open source technology increases transparency and control. It provides insight into how systems work and reduces reliance on proprietary formats and commercial constraints.

3. Develop internal skills and architectural knowledge

Internal capability is one of the strongest drivers of independence. Teams that understand how systems operate can troubleshoot, optimize, and evolve them without waiting for external approval.

4. Align long term strategy with the right level of control

Not every system needs the same degree of independence. Some are fine with commercial services. Others benefit from a more sovereign approach. The goal is intentional architecture, not a full replacement of every dependency.

Organizations that take these steps gain more control over their digital environment, better cost predictability, and more room to innovate. They negotiate from a stronger position and design systems that support growth instead of limiting it.

Technical independence is no longer optional. It is becoming a requirement for any organization that wants to remain resilient, efficient, and in control of its digital future.