Add commands to remove advertised routes of tailscale in k3s-killall.sh

[manuelbuil]

Proposed Changes

When k3s gets removed from the node, the tailscale interface should remove the routes that it had advertised:

tailscale set --advertise-routes=

This PR adds those commands to k3s-killall.sh

Types of Changes

Bugfix

Verification

After running k3s-killall.sh, the tailscale interface should not have any IP and running tailscale status --json should not report anything because we logged out

Testing

Linked Issues

#7772

User-Facing Change

Further Comments

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +31.61 🎉

Comparison is base (55db9b1) 19.85% compared to head (d968e64) 51.47%.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #7777       +/-   ##
===========================================
+ Coverage   19.85%   51.47%   +31.61%     
===========================================
  Files          83      143       +60     
  Lines        7686    14509     +6823     
===========================================
+ Hits         1526     7468     +5942     
+ Misses       5930     5854       -76     
- Partials      230     1187      +957     

Flag	Coverage Δ
e2etests	49.33% <ø> (?)
inttests	44.47% <ø> (?)
unittests	19.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 118 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[brandond]

I'm a little concerned that this will be a breaking change for anyone using tailscale standalone. I know from GH issues that there are users that are currently deploying tailscale by hand, and then installing k3s afterwards. Is there anything we can do to avoid breaking things? Is there some way to uniquely configure tailscale to indicate that it is managed by k3s, and check for that when uninstalling?

[manuelbuil]

I'm a little concerned that this will be a breaking change for anyone using tailscale standalone. I know from GH issues that there are users that are currently deploying tailscale by hand, and then installing k3s afterwards. Is there anything we can do to avoid breaking things? Is there some way to uniquely configure tailscale to indicate that it is managed by k3s, and check for that when uninstalling?

Ok, I did not think about this use case TBH. Instead of turning it off, we could remove the configured subnet route instead, which is what we basically do apart from starting and logging. That would still fix the issue. Let me update the PR

[brandond]

Single braces only, this isn't bash. And quote the potentially empty subshell output.

Suggested change

	if [[ -n $(command -v tailscale) ]]; then
	if [ -n "$(command -v tailscale)" ]; then

[DerRockWolf]

I'm a little concerned that this will be a breaking change for anyone using tailscale standalone. I know from GH issues that there are users that are currently deploying tailscale by hand, and then installing k3s afterwards. Is there anything we can do to avoid breaking things? Is there some way to uniquely configure tailscale to indicate that it is managed by k3s, and check for that when uninstalling?

Removing the advertised routes is also somewhat breaking, if one is using manually created advertised routes.

Is the k3s-killall.sh script being executing automatically at some point, or is it always run manually?
If it's only run manually I'm fine with it removing the advertised routes.

[brandond]

It is never run automatically. An administrator has to chose to run the uninstall or killall script, although a killall is also run as part of the uninstall (for obvious reasons).

[manuelbuil]

We have this related issue in the backlog: #8012