The big difference seems to be removing SSH. I understand the theoretical rationale, but in practice it seems like this would complicate troubleshooting quite a bit. Yes, maybe you shouldn't be SSHing into prod ever, but how do you keep the environment consistent if you do want to allow SSH in dev/test?
We have added an API to help with the practical issues in removing SSH. In doing that it has also opened up interesting opportunities in automation that we are currently fleshing out.
The difference here is that Talos is purpose-built for Kubernetes. What that means is that we will pour resources into automated upgrades paths for our users. Tighter integration with Kubernetes, where we envision a self-healing system that makes use of the Kubernetes and Talos APIs to make decisions.
Comments
Can somebody give me(/HN) a TL;DR of how this differs from existing OSs targeted for Kubernetes, like GCP's Container-Optimized OS?
https://cloud.google.com/container-optimized-os/
The big difference seems to be removing SSH. I understand the theoretical rationale, but in practice it seems like this would complicate troubleshooting quite a bit. Yes, maybe you shouldn't be SSHing into prod ever, but how do you keep the environment consistent if you do want to allow SSH in dev/test?
We have added an API to help with the practical issues in removing SSH. In doing that it has also opened up interesting opportunities in automation that we are currently fleshing out.
The difference here is that Talos is purpose-built for Kubernetes. What that means is that we will pour resources into automated upgrades paths for our users. Tighter integration with Kubernetes, where we envision a self-healing system that makes use of the Kubernetes and Talos APIs to make decisions.
Also the things I mentioned in https://news.ycombinator.com/item?id=21066732