Some 20% of developers already use Kubernetes. It offers everything from scalability and security to a strong user community, but it also comes with drawbacks. Without the right tools, Kubernetes infrastructures can be expensive, resource-intensive, and complex. It’s often difficult to find the necessary expertise, and even if you do find the right people, cluster management is likely to be time-consuming. Vendor lock-in only aggravates the situation, driving up costs and making optimization difficult. As a result, even though many businesses are looking to implement Kubernetes or modernize their existing infrastructure, it isn’t easy.
That’s why we built Talos Linux and Omni. We wanted to change the way businesses view Kubernetes, transforming it from a complex and intimidating necessity into an accessible, easy-to-use product for technical and non-technical users alike. Whether you’re a Kubernetes specialist or simply the person running that single edge node, you should have a positive, easy experience.
We wanted Talos Linux and Omni to provide:
-
- Simplified operations
-
- Reliable updates and reprovisioning
-
- Easy and reliable edge cluster management
-
- Vendor flexibility and no more lock-in
During the development process, we looked at several tools, including Cluster API, but found they were all missing key components. CAPI is a fantastic toolbox that enables you to build faster, but we didn’t need to build faster. We needed to build differently. We had to find the tools that fully supported our goal of removing complexity and making Kubernetes easy to run for anyone. To do this, we chose not to utilize CAPI and, instead, built functionalities in-house.
Here’s what Talos and Omni provide that would not have been possible with CAPI and similar existing tools.
Simplified Operations
To make operations easy for users, we needed to lower the barrier to entry, and that meant getting rid of Kubernetes as a dependency. Cluster API, however, requires a full Kubernetes cluster just to get started. We assume that, while not everyone is a Kubernetes expert, every customer should be able to run and manage something as easy as a container. This is why Omni is built as a single binary and distributed as a single container, so users don’t need to be skilled in Kubernetes from the beginning. This cuts down on the technical skills required to run Kubernetes and makes it easy for non-technical users to both get started and manage the ongoing processes.
On top of this, we see that many teams using tools like CAPI put off upgrades to their management cluster as the process can be risky and complex. This causes compatibility as well as security issues and makes it difficult to leverage new features. We find it critical that users are confident in managing their upgrades, and this is why we make upgrades and maintenance as easy as possible.
Reliable Updates and Reprovisioning
While immutable infrastructure has its benefits, not everything is software defined. Your physical servers are not immutable. You will run them for years without ordering replacements, and this is perfectly functional for many scenarios. Swapping machines can be costly, time-consuming, and unnecessary. You can’t buy a new machine every time you need to update your software, but Cluster API expects users to do just that. It assumes machines are disposable or you have a spare pool of machines available for configuration changes.
Instead, we built our products to support in-place upgrades as the default option, making it faster to reprovision the OS and less prone to errors. With Talos Linux and Omni, an OS upgrade can be done in a matter of seconds and a Kubernetes upgrade doesn’t even require a reboot. Just pull a new container and restart the service.
No more running at scale in the cloud and hitting capacity limits. This is helpful for both cloud and bare metal.
Easy and Reliable Edge Cluster Management
We know teams often build architectures that would not function on traditional networking VPNs and cloud restrictions, especially at the edge. We also knew that using Cluster API in these scenarios would lead to unnecessary complexity and make it difficult for users to manage and scale clusters.
CAPI assumes providers are running inside a Kubernetes cluster, and it relies on RBAC for authentication. Therefore, provider APIs should be reachable from the network where the controller runs and any connectivity requirements are handled outside of CAPI. This is difficult in environments with network segmentation between management traffic and application traffic.
By building in-house, we were able to design a solution that provides numerous benefits at the edge, including:
-
- Secure, remote management right at boot through SideroLink, which establishes a secure wireguard connection to Omni.
-
- Increased stability through KubeSpan, a node-to-node wireguard, which connects nodes from different networks at a layer below the Kubernetes CNI, allowing users to build remote clusters without a management control plane.
-
- Streamlined processes through: in-place upgrades, which enable the deployment, maintenance, and troubleshooting of single node clusters from anywhere in the world; and Omni Infrastructure Providers, which can be deployed close to your machines–wherever that may be–while retaining a central point of control.
The result is edge cluster management that is manageable and reliable.
Vendor Flexibility and No More Lock-In
Infrastructure inflexibility costs money. We’ve seen bare metal combined with bursting to the cloud save millions of dollars in hardware and personnel. The ability to deploy across providers and environments gives teams the ability to streamline their processes, cut complexity, and increase performance by having complete control over their clusters.
With Cluster API, mixing and matching compute from cloud providers such as AWS and on-prem is possible, but it isn’t easy. It requires you to put all the machines on the same logical network and extend your machine identity in the form of IAM agents or credentials.
On the other hand, Omni is completely cloud agnostic, with built-in seamless connectivity thanks to KubeSpan, and with identity handled via trusted certificates. If a node can run Talos and connect to Omni, it can join a Kubernetes cluster. This allows teams to quickly build and optimize their infrastructure in ways that once required a huge amount of resources.
Conclusion
If you’ve never restored etcd from a backup, you probably don’t want to use tools like CAPI. If you want complete control over your clusters with minimal complexity, you should use a product purpose-built for Kubernetes. By focusing on our goal and building in-house specifically to make Kubernetes easy for everyone, we were able to create products that do just this–and not something else.
Omni makes it easy to stay flexible, reduce operations overhead, and manage your clusters with the absolute lowest barrier to entry possible, and our team is working continuously to make sure it adds unique value on top of solving day-to-day problems.