search

techno-tim / k3s-ansible

The easiest way to bootstrap a self-hosted High Availability Kubernetes cluster. A fully automated HA k3s etcd install with kube-vip, MetalLB, and more. Build. Destroy. Repeat.
https://technotim.live/posts/k3s-etcd-ansible/
Apache License 2.0
2.41k stars 1.05k forks source link

System upgrade #192

Closed irish1986 closed 1 year ago

irish1986 commented 1 year ago

Proposed Changes

Following PR #191 , I am proposing new feature to be added, although this slightly customize this project adding a none essentially feature it is very useful mechanism.

I proposed to add system-upgrade workload as part of the default configuration. System-upgrade allows to automated K3S image update via various means. Also it is a good use case on why splitting manifest could be useful

System-upgrade allows multiple optional feature such as label selector and cordon\drain. I haven't tested this but it seem we can even use it for host OS upgrade strategies and plans TO BE CONFIRMED.

For instance, this would help someone less experience to learn about K3S system-upgrade instead of nuking and reinstalling the whole thing went upgrading K3S version. Also for those using GitOps approach, it is nice to have it already installed and control K3S version upgrade via FluxCD or ArgoCD.

Checklist

timothystewart6 commented 1 year ago

I do like this, however I need to think about this a little more. My goal was to provide a platform to build and HA cluster and not take on too many dependencies so that I don't have to keep them up to date, nor worry about changes with kubernetes. Another reason is so that people can use helm / gitops / install however they want later. This also makes upgrades challenging later too, because now you have to reinstall / edit in place in cluster, neither of which are great options.

irish1986 commented 1 year ago

Agreed providing a lean and clutter free template for k3s HA playbook is indeed a great idea and guideline.

Although given system upgrades is a rancher "product" and plug right in, I had found it useful in my own cluster to include it during the initial deployment so my downstream GitOps plan just run whatever Plan to upgrade the cluster version.

Plus it is a good exposure for newcomers to learn about that mechanism for in place upgrade. I know that personally before finding out about it, I did nuke a few times my home cluster just to upgrade. And it flows well into learning a our GitOps which emphasize on the learning aspect your channel has. In the end, I think it be a nice feature but in does create more complexity so I can understand if this PR does not get merged.

timothystewart6 commented 1 year ago

After thinking about this some more, as much as I would like to accept this, I am going to close this PR. I really appreciate the thought and work that went into this. The reason I am going to close this is because I want this to be used to bootstrap a minimum cluster and then use other GitOps tools to do the rest (Flux, ArgoCD, etc). I don't feel like ansible is the right tool to install and maintain additional services in kubernetes.

You might be asking why MetalLB is included, as some have asked, and that's really just how this all got started. Soon there will be an option not to include it so others can install it via helm, kubectl, Flux, ArgoCD, or anything really.

Again I appreciate it and stay tuned for what's next!