andrewrynhard

It is not. The specifics are still a WIP to be honest, but the plugin system will almost certainly have a scope to it.

We're working through a plugin system that might allow for things like this. GPUs/other hardware will obviously not be pluggable, but we have had requests for both and we are interested in adding support for them. We have really powerful tooling that makes building kernels with modifications simple.

Agree 100%. Part of the value add we feel we bring is going to be an OS that keeps pace with Kubernetes. Also, automated upgrades. Making the maintenance of a cluster a little easier over time.

We are working with a number of users currently. Please see our README for community meeting times if you'd like to chat some more!

The idea is that since

- we go to great lengths to make the OS secure and immutable

- we have an API

- we will have automated upgrades

We can allow those who are operating clusters to care far less about the OS. Managing SSH, packages, auditing requirements, etc. at the host layer is a job in itself. We aim to remove that concern and allow you to focus on Kubernetes.

We indeed integrate with CAPI, but the OS itself is not a CAPI implementation. We have a CAPI provider that works hand-in-hand with the OS.

I think you might be pleasantly surprised about our approach to security. Security is very machine a priority and built into the OS.

Hey folks, Talos creator here. Happy to answer any questions you guys may have. Sounds like some confusion about exactly what Talos is. A lot of good feedback here that we will take and improve our documentation.

Talos is a Linux distribution built specifically for Kubernetes. The short version is that we have stripped out absolutely everything that is not required to make a machine a Kubernetes node, including SSH and console access (I will explain why).

Here goes the long version. We have done a number of things to improve security, including a read-only filesystem, except for what the Kubelet needs (/var/lib/kubelet, /etc/cni, etc.). It runs entirely in RAM from a Squashfs, and only Kubernetes makes use of a disk. We have stripped SSH/Console access and added a gRPC API that gives engineers the ability to debug and remediate issues.

We didn't just stop at this. We are writing everything, including the init system, in Golang, which allows us to integrate deeply with Kubernetes. Everything about Talos is API driven.

Some of the highlights include:

- SSH/console access replaced with gRPC API that is secured via mutual TLS.

- Immutable. Immutability prevents drift, making the cluster consistent across the board.

- Automated upgrades that can be orchestrated in an intelligent way. By using Kubernetes events, and our API, we can roll out upgrades from an operator (currently a WIP and planned for release in 0.3 Talos) and do safe in a safe manner.

- Cluster API (CAPI) integration that allows rapid creation of Kubernetes clusters using Kubernetes style declarative YAML.

- Support for AWS, GCP, Azure, Packet, vSphere, Bare Metal, and Docker. The experience for each is consistent, making it easy to reason about Talos regardless of where you run it.

- CIS and KSPP security configuration enforcements.

- Keeping current by supporting the latest and greatest version of Kubernetes, while writing upgrade paths into the system.

- Support for local Docker based clusters, easily created using our CLI. This is super useful for creating CI pipelines where you might want to run integration tests against the same Talos/Kubernetes versions running in production.

- Installs and upgrades are performed via containers.

We feel that by removing SSH/console, making the core of Talos read-only, and treating the nodes as ephemeral machines, we are creating a much more secure way to run Kubernetes. A really good talk was given on these ideas at Blackhat this year: https://swagitda.com/speaking/us-19-Shortridge-Forsgren-Cont.... We feel we align with the recommendations made there.

In addition to security, we envision a system that will be self-healing and intelligent. By having an API and integrating with Kubernetes, the sky is really the limit on the tooling we can build to create this self-healing system.

Our goal with Talos is to allow engineers to more or less forget about each individual node. Managing the OS alongside Kubernetes is a lot of work.

I will address the questions and comments as replies. Feel free to ask more as a reply to this comment.

Feel free to join our meetings every Monday and Thursday at 17:00 UTC on https://zoom.us/j/3595189922. Also, join our slack and I'd be more than happy to talk some more about Talos! https://slack.dev.talos-systems.io

Hi. I am writing up a response now :)

Interesting. Sounds a lot like my OSS project Talos: https://github.com/talos-systems/talos. Very similar goals too.

LinuxKit is really neat. Don't get me wrong. I think each have their benefits. LinuxKit is great if you need that flexibility. With Talos we would rather focus on building a Kubernetes-centric distro.

We want to build a great community. So I have taken note and we will look into supporting that!

Really good question. The short version is that CoreOS is a generic container based distro. Talos is not. It is designed with the goal of making a machine a Kubernetes node in a fast and reliable way. We don't use systemd, but a pure Golang init that is Kubernetes aware.

We actually had matrix up on running on a cluster built with Talos in AWS. We decided to focus our efforts on Talos instead of maintaining infrastructure. There is a convenience factor for us since it is only three of us.

It is indeed very similar. Talos does a few things differently. The biggest being that it does not allow any host-level access and exposes a gRPC API for things like querying the processes, or restarting a node.

Fair point :) But that does work. andrew@andrewrynhard.com

For anyone interested in joining our slack, feel free to PM me!