Earlier quoted context omitted.
How difficult is an HA cluster? Because that’s more of a fair test. Setting up a dev-only instance of anything ought to be easy.
I build and maintain large-scale Kubernetes infrastructure for a living the way I put it is: easy to setup, somewhat more challenging to maintain. It's not rocket science, but like any complex computing tool it requires dedicated attention especially if you are going to run more than a handful of clusters. A lot of the tooling in the ecosystem falls flat here, it all solves the Day One: Getting Started problem but of…
Talos: OS for Kubernetes
21–30 of 79 posts
Re: Talos: OS for Kubernetes
#22Earlier quoted context omitted.
Installing Kubernetes has gotten easier since the time you last looked at it then. Having used Kubeadm and then RKE from Rancher, I can get a 3 node (non-HA) cluster up in under 10 minutes. This is on regular RHEL 7.4 machines when I last did this in a non-automated way.
How difficult is an HA cluster? Because that’s more of a fair test. Setting up a dev-only instance of anything ought to be easy.
It gets a bit more complicated when you automate it and support adding/replacing nodes - the uploaded certs are valid only for 2h for example. (IMO the easiest solution to that is manual cert distribution - i.e. just scping them to the joining nodes.)
Re: Talos: OS for Kubernetes
#23while an 'os for kubernetes' would be interesting, the documentation doesn't seem to really explain how: "Talos lets you treat the cluster as the machine, so you can focus on your applications instead of managing the OS." all the examples seem to basically be kubectl, etc. commands with different syntax. How exactly is this an 'operating system' and not 'yet another kubernetes build / deployment utility'? Maybe it's…
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.
Re: Talos: OS for Kubernetes
#24Earlier quoted context omitted.
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.
What if it's mainly but not only k8s that you want installed - wireguard for inter-node networking for example, or something to support GPUs/other hardware?
Re: Talos: OS for Kubernetes
#25Re: Talos: OS for Kubernetes
#26Earlier quoted context omitted.
What if it's mainly but not only k8s that you want installed - wireguard for inter-node networking for example, or something to support GPUs/other hardware?
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.
Re: Talos: OS for Kubernetes
#27Earlier quoted context omitted.
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.
Is this plugin system going to end up being a package manager?
Re: Talos: OS for Kubernetes
#28Re: Talos: OS for Kubernetes
#29Does anyone have a tldr; of how this differentiates from Linuxkit, RancherOS, and CoreOS?
- no SSH/console
- has an API
- not for general use
- runs from squashfs in RAM
- has a custom init system
Re: Talos: OS for Kubernetes
#30https://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?