Kubernetes
We build Kubernetes platforms on your own servers or in the cloud, with configuration in Git and a distribution chosen for your requirements. A scoped pilot can validate the workload and integrations.
Which Kubernetes fits you?
For every platform we build, we compare the options and choose the one that fits, on your own servers or in the cloud. On your own servers, that is often Talos Linux.
- Talos LinuxA small operating system for Kubernetes. You choose storage, networking and tooling.
- OpenShiftAn integrated application platform, with more built in.
- RancherManagement of many clusters from one place.
- vSphere Kubernetes ServiceKubernetes in your VMware environment. If you are leaving VMware, the clusters move with the servers.
- EKS, AKS and GKEKubernetes run as a service in AWS, Azure or Google Cloud.
A node with nothing to log in to
We choose Talos for Kubernetes on your own infrastructure when security and predictable operations weigh heavily. A small, read-only system has fewer parts to protect and keep updated.
- How it differs from a regular Linux nodeThere, software is installed and changed by hand while the node runs, so nodes drift apart. Every node has a login, and with it a way in.
- The same Kubernetes on topWorkload security is handled in Kubernetes, with network policies, roles and secrets that we set up with you.
- No license cost for the operating systemThe community edition of Talos Linux is open source. Your budget goes to hardware, implementation and operations, and if needed vendor support and Omni.
- An environment you can recreateNodes are managed through an API and versioned configuration, so your team can rebuild the environment and track what changed. If NIS2 applies to you, we also work on access control, traceable changes and documented restores.
- One machine configurationA declarative document for Talos and Kubernetes, with no scripts or manual steps.
- Read-only systemRuns from a SquashFS image. No shell, no SSH, no package manager.
- A/B upgradesIf the new version fails to boot, the node falls back to the previous one.
- One APIEverything is managed through the Talos API with talosctl, encrypted and key-authenticated.
Every change through Git
Everything on the nodes is managed through an API and configuration. So the platform changes the same way your code does: through pull requests, review and CI, from development and test to production.
- Your pipelines, as todayYour development team builds and tests container images as before.
- Secrets stay out of GitSecrets are encrypted or fetched from a separate system, and never sit in plain text in Git.
- Tested from pull request to clusterA change goes from pull request to cluster, and a revert undoes it. We also rebuild a test cluster from the repository alone.
- Your Git repositoryPull request, review and CI before every change.
- Terraform or OpenTofuThe Talos provider creates and applies the machine configuration.
- Talos APIConfigures and upgrades the nodes.
- Flux or Argo CDSyncs manifests and Helm releases from Git.
- Kubernetes APIRolls out the resources in the cluster.
Your workloads and tools on Talos
Talos Linux has no shell and no package manager. Drivers and tools are therefore built into the image, set in the machine configuration or run in Kubernetes, as in these examples. The figure shows what NVIDIA GPUs change in each layer.
- NVIDIA GPUsInference, training and CUDA jobs in Kubernetes. The driver is built into the image, and a test pod runs a CUDA job on the GPU.
- StorageReplicated volumes on the nodes' own disks with Longhorn, Rook/Ceph or CSI against an existing SAN or NAS, and S3-compatible object storage such as Garage, running as an ordinary application in the cluster.
- Private accessYour team reaches the Kubernetes API and selected services privately, for example through Tailscale, with nothing exposed to the internet.
- Multiple sitesOne cluster per site across data center, cloud and edge. Omni can create, upgrade and oversee the clusters, and GitOps delivers the applications.
- On servers or in ProxmoxDirectly on servers when the cluster needs dedicated hardware or GPUs, installed from ISO, PXE or disk image with SecureBoot. Or in Proxmox VMs, to share hardware and quickly create separate test and production clusters.
- ServersGPU in the server, or PCI passthrough to a Talos VM in Proxmox.
- Talos imageSystem extensions: NVIDIA kernel modules and Container Toolkit.
- Machine configKernelModuleConfig loads the NVIDIA modules.
- KubernetesNVIDIA GPU Operator and RuntimeClass nvidia.
- WorkloadPods request nvidia.com/gpu.
Fixed-price pilot cluster
We agree on the workload, number of nodes and integrations, then give you a fixed-price quote.
Hardware advice is available as an option: we help you choose servers, GPUs, storage and networking, and review the vendors' proposals.
- A cluster with your workloadTalos and Kubernetes on servers or in Proxmox, with a representative containerized application.
- Integrations in placeNetworking, access, storage and monitoring, within the pilot's scope.
- Tested upgrade and restoreOf the cluster and the workload's data, with the result documented.
- A basis for productionConfiguration, documentation and a walkthrough of what it takes to go further.
Will you depend on us?
No. Your applications run on standard Kubernetes, and everything that controls the cluster stays with you.
- Upgrade a node with talosctl
- Restore etcd from a snapshot in the test cluster
- Deploy a change through a pull request
- The platform as codeConfiguration and automation in your repositories, with secrets protected.
- Architecture and decisionsCluster, networking, storage and lifecycle, with the reasons behind the choices.
- RunbooksPractical instructions for operations, upgrades and restores.
- Restore test resultsetcd and application data, tested and saved next to the test code.
- Keys to the APIsAccess to the Talos API and Kubernetes stays with you.
