fix: apply k3s version bumps declaratively through site.yml (#544)

Re-running site.yml with a raised k3s_version replaced the on-disk
binary but left agents and joined servers running the old runtime,
because the install script skips the service start and the roles only
restarted the service on a config change. A version-only bump was
therefore not applied until the services were restarted by hand.

Always restart the k3s service in the server and agent roles on a
site.yml run, so the cluster reliably picks up a new config or runtime
without any logic to detect whether the binary changed. On a
multi-server cluster, run the playbook with --forks=1 so the servers
restart one at a time and the etcd quorum is preserved; document this
in the README.

Keep the dedicated upgrade.yml integration test and add a second
upgrade through site.yml, asserting the running version the kubelet
reports rather than the on-disk binary, so the tests fail if the
restart regresses.



Assisted-By: Claude <noreply@anthropic.com>

Signed-off-by: Aleksei Sviridkin <f@lex.la>

roles/k3s_server/tasks/main.yml

@@ -294,11 +294,15 @@
       ansible.builtin.systemd:
         daemon_reload: true
 
+    # Always restart a joined server so a re-run of site.yml — whether it only
+    # bumped k3s_version or changed config — brings it onto the new runtime, the
+    # same way the first server above always restarts. On a multi-server cluster
+    # run the playbook with --forks=1 so the servers restart one at a time and
+    # the etcd quorum is preserved (see README).
     - name: Restart K3s service
       when:
         - ansible_facts.services['k3s.service'] is defined
         - ansible_facts.services['k3s.service'].state == 'running'
-        - k3s_server_config_result.changed
       ansible.builtin.service:
         name: k3s
         state: restarted