This is a very good presentation. Is there a way for viewers of this video to reproduce your steps on their own machine? If not, is there a tutorial somewhere online that is comparable? - Also, is there a presentation that shows: setting up a mother ship, then using flux and a git repository to setup the additional clusters and use flux to manage the applications in those additional clusters.. Thanks.
Yes, we actually have a series of tech talks presented by our principal solutions architect on this: watch?v=ag573HbdkDo. There's also assets in the techtalk github repo that allows you to deploy k0smotron on your environment. I don't believe there's one revolving flux, but that would be an interesting topic to present, will look into it.
@@kevng9 Thank you for this link and for considering a K0S+Flux tutorial. In the near future I hope to try and use use something link Nix/NixOS to declaratively define the operating system instances that hosts the K0S cluster and K0S workers, and then use Flux for the declarative configuration inside K0S. I see there is a Nix Package for K0sctl, so maybe I can install using that. I also need to figure out how to declaratively setup an identity management infrastructure (such as KeyCloak) to manage the GitLab CE + K0S users. One complication being can the open source GitLab CE and KeyCloak themselves be reliably hosted in the K0S infrastructure, or do they need to be independently hosted to prevent common mode failure. It seems like GitLab CE and KeyCloak might be hostable in the K0S Mothership, so long as there is the equivalent of a root/admin user can log into K0S, GitLab and Kloak without requiring those services so that any faults in those subsystems can be remedied. Maybe it needs to be a tiny Min.IO server outside the mothership to host the configuration for the K0S mothership, and then full blown GitLab CE+Min.Io+KeyCloak+ on or more SQLDatabase instances hosted in the K0S mothership to manage the rest of the K0smotron cluster in a scalable way.
k0s uses the konnectivity service which provides a better performance in terms of latency and throughput, that will help with the latency issue between controllers and workers. You can find some of the metrics in the How to choose a lightweight Kubernetes Distribution video from earlier. Apart from that the typical network latency considerations such as proximity, topology, and monitoring will apply. So depending on whether you have a central controller cluster running multiple edge workers, cloud controller + edge worker clusters, or controller+worker at the edge, k0s supports all that. It would also be useful to monitor metrics such as http_request.duration or latency centrally through an interface such as Lens. Happy to discuss more.
This is a very good presentation. Is there a way for viewers of this video to reproduce your steps on their own machine? If not, is there a tutorial somewhere online that is comparable? - Also, is there a presentation that shows: setting up a mother ship, then using flux and a git repository to setup the additional clusters and use flux to manage the applications in those additional clusters.. Thanks.
Yes, we actually have a series of tech talks presented by our principal solutions architect on this: watch?v=ag573HbdkDo. There's also assets in the techtalk github repo that allows you to deploy k0smotron on your environment. I don't believe there's one revolving flux, but that would be an interesting topic to present, will look into it.
@@kevng9 Thank you for this link and for considering a K0S+Flux tutorial. In the near future I hope to try and use use something link Nix/NixOS to declaratively define the operating system instances that hosts the K0S cluster and K0S workers, and then use Flux for the declarative configuration inside K0S. I see there is a Nix Package for K0sctl, so maybe I can install using that. I also need to figure out how to declaratively setup an identity management infrastructure (such as KeyCloak) to manage the GitLab CE + K0S users. One complication being can the open source GitLab CE and KeyCloak themselves be reliably hosted in the K0S infrastructure, or do they need to be independently hosted to prevent common mode failure. It seems like GitLab CE and KeyCloak might be hostable in the K0S Mothership, so long as there is the equivalent of a root/admin user can log into K0S, GitLab and Kloak without requiring those services so that any faults in those subsystems can be remedied. Maybe it needs to be a tiny Min.IO server outside the mothership to host the configuration for the K0S mothership, and then full blown GitLab CE+Min.Io+KeyCloak+ on or more SQLDatabase instances hosted in the K0S mothership to manage the rest of the K0smotron cluster in a scalable way.
how do you manage the latency between Central Controller and Remote Worker? are there any quirks, requiements, dependencies etc?
k0s uses the konnectivity service which provides a better performance in terms of latency and throughput, that will help with the latency issue between controllers and workers. You can find some of the metrics in the How to choose a lightweight Kubernetes Distribution video from earlier.
Apart from that the typical network latency considerations such as proximity, topology, and monitoring will apply. So depending on whether you have a central controller cluster running multiple edge workers, cloud controller + edge worker clusters, or controller+worker at the edge, k0s supports all that. It would also be useful to monitor metrics such as http_request.duration or latency centrally through an interface such as Lens.
Happy to discuss more.