 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Conventionally, we run Kubernetes on top of a standard Linux distribution. For example, there’s Red Hat with OpenShift running on Red Hat Enterprise Linux (RHEL) and SUSE with Rancher and SUSE Container as a Service Platform running with SUSE Linux Enterprise Server (SLES). But, you don’t have to do it that way. Talos Systems takes a radically different approach. Its opinionated container-specific operating system (CSOS), Talos OS, is driven entirely by application programming interfaces (API)s. And, now Talos wants to standardize what an API-driven OS should like under the new Common Operating System Interface (COSI) project.
Talos demonstrated the latest on this technology at KubeCon+CloudNativeCon 2021, being held this week, virtually.
Before diving into COSI, you need to understand what Talos OS is all about. According to Steve Francis, Talos OS’s CEO, it’s better to run Kubernetes on a CSOS than a general-purpose Linux because it avoids their unnecessary overhead and the lack of any built-in coordination with Kubernetes.
A CSOS, on the other hand, avoids these problems. And as the National Institute of Standards and Technology (NIST) states: “A container-specific host OS is a minimalist OS explicitly designed to only run containers, with all other services and functionality disabled, and with read-only file systems and other hardening practices employed. When using a container-specific host OS, attack surfaces are typically much smaller than they would be with a general-purpose host OS, so there are fewer opportunities to attack and compromise a container-specific host OS. Accordingly, whenever possible, organizations should use container-specific host OSs.”
Talos OS, following in the footsteps of the original CoreOS, takes immutable infrastructure to its logical extreme. There is no SSH or console access. Everything — and I mean everything — is API-driven and designed expressly for running Kubernetes. Even the Linux init system has been rewritten to do just one thing: Launch Kubernetes. Everything else, like user-defined services, must be managed via APIs or Kubernetes.
With COSI, Talos wants to standardize the next generation of Linux distributions for distributed systems using Talos OS as a model.
In it, COSI aims to define a new API interface for operating system interactions. By using a Kubernetes-style API that enables declarative configuration of the operating system, you’ll be able to control the settings for DNS resolution, kernel parameters, mount points, network configuration, and so on. Like other declarative models, you define your desired operating system configuration in a COSI model and your operating system controllers will drive its setup to your desired state.
Kris Nóva, Twilio senior principal software engineer, explained, “There is a clear void in userland with inconsistency in the pillars of management (storage, networking, runtime). COSI is our opportunity to define a clear interface for an operating system running in a distributed environment. In doing so we take the first step into claiming complete control over userland in Kubernetes, instead of partial control of pillars of the operating system as we see it today.”
If that sounds familiar, it should. As Sean McCoy, a Talos software engineer explained, “One of the main concepts in COSI is the use of resources and controllers. Resources (static or dynamic) are used by controllers to continually try to reach the desired state. This concept is core to Kubernetes itself, and it is an important design concept for self-healing and distributed systems. It also happens to offer very nice things to an operating system.”
Other, traditional methods such as kubeadm and controller-manager, because they’re inherently more brittle and fragile. Neither gets feedback from your running Kubernetes configuration. With kubeadm this makes reproducing running configuration difficult. And, with controller-manager, you can run into situations where “updates are rolled out and continue to be rolled out, replacing the good components with bad ones all before the bad replacements have a chance to signal that they are actually bad.”
Now taking those same concepts to the underlying Linux operating system makes it easier to quickly build secure Kubernetes clusters. In a blog post, Frances said:
With the Talos (COSI) managed control plane, even single control plane node clusters are now rock solid, and Kubernetes can be upgraded safely and simply. All your control plane configurations are managed declaratively, and COSI will drive the state continually to match the declared configurations. Another benefit COSI brings to Talos is that Talos OS is now reactive on parts of the machine configuration: the Kubernetes control plane can be reconfigured without a reboot, and bad changes can be reverted back easily.
Will others join Talos in taking its COSI approach to both Kubernetes and Linux stacks? Stay tuned. We’ll find out soon.
