k3s-io / k3s-ansible

Apache License 2.0
2.08k stars 822 forks source link

k3s --version : Command not found #374

Closed dheurtev closed 2 weeks ago

dheurtev commented 2 weeks ago

When running the playbooks, I get an error k3s -- version : Command not found Fix : In your roles source code, the version should be checked as /usr/local/bin/k3s --version instead of k3s --version My system is Almalinux 9.

/k3s/orchestration/roles/k3s_agent/tasks/main.yml 3c3 < ansible.builtin.command: k3s --version

ansible.builtin.command: /usr/local/bin/k3s --version /k3s/orchestration/roles/k3s_server/tasks/main.yml 3c3 < ansible.builtin.command: k3s --version

ansible.builtin.command: /usr/local/bin/k3s --version 246c246 < k3s kubectl get nodes -l "node-role.kubernetes.io/control-plane=true" -o=jsonpath="{.items[*].metadata.name}"

      /usr/local/bin/k3s kubectl get nodes -l "node-role.kubernetes.io/control-plane=true" -o=jsonpath="{.items[*].metadata.name}"

/k3s/orchestration/roles/k3s_upgrade/tasks/main.yml 5c5 < ansible.builtin.command: k3s --version

ansible.builtin.command: /usr/local/bin/k3s --version

dereknola commented 2 weeks ago

We cannot assume that the k3s install location is at /usr/local/bin/k3s. Depending on the operations system, the binary may be located else (this is often the case in read only/atomic OSes). The assumption for that line is that K3s will already have been installed on the system, and the PATH will include the location that k3s is in (as should be standard for most programs).

It is expected for that command to fail on instances where K3s has never been installed. Thats why we ignore_errors: true for that check.

dheurtev commented 2 weeks ago

In my case, I had it fail on upgrade even though k3s was installed on the remote server system.

In roles/k3s_upgrade/tasks/main.yml, ignore_errors:true is not set. Shouldn't it be added there too ?

In addition for roles/k3s_server/tasks/main, assumption about the location of k3s and kubectl is made.

Shouldn't that be consistent and set with a variable ?

dereknola commented 2 weeks ago

~Your correct those are both problems with the current repo. I will open a PR to address them.~

So the second problem is valid. There is no reason to even try and symlink it as K3s already does that on install. As for the first issue with

In roles/k3s_upgrade/tasks/main.yml, ignore_errors:true is not set. Shouldn't it be added there too ?

No, because if you are upgrading, we explicitly need the previous version of k3s to exist. If you don't have K3s installed, why are you trying to run the upgrade is the logic. We use the K3s installed version to validate that you are not "downgrading" to a previous version which is not supported by K3s and will break your cluster.

For your setup, where is your K3s getting installed to that your PATH does not include it?

dereknola commented 2 weeks ago

I just tested with the official vagrant almalinux 9 box and I see the PATH as /home/vagrant/.local/bin:/home/vagrant/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin which seems pretty standard. K3s is found no problem when installed with the ansible playbook.

dheurtev commented 2 weeks ago

Thank for looking into it. Must be an issue with my system then. We can consider the first problem closed for now, and I let you remove the unnecessary symlink on the other.