Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allows specifying k3s version #1436

Merged
merged 3 commits into from
Aug 9, 2024
Merged

Conversation

gmautner
Copy link
Contributor

Sometimes a cluster operator might prefer to specify the k3s version (e.g. v1.29.6+k3s2) instead of the channel (e.g. v1.29, stable etc.)

Reasons for that could be not wanting the system upgrade controller to run at unpredictable times, or having more fine-grained control over the running version.

This PR introduces a new variable install_k3s_version in kube.tf. If undefined, the present behavior is preserved such that current installations are not affected. However, when defined, this variable takes precedence over initial_k3s_channel.

The mechanism for upgrades in either case continues to be the system upgrade controller.

gmautner added 3 commits July 30, 2024 14:03
Signed-off-by: Gilberto Mautner <[email protected]>
Signed-off-by: Gilberto Mautner <[email protected]>
Signed-off-by: Gilberto Mautner <[email protected]>
@gmautner
Copy link
Contributor Author

By the way, the following scenarios were tested and worked according to expected:

  • Created a new cluster with default settings and initial k3s channel was used
  • Configured install k3s version on above cluster and plan was changed to refer to k3s version and executed properly
  • Created a new cluster with install_k3s_version and it was installed with the desired k3s version
  • Deleted install_k3s_version variable on above cluster, plan changed to use initial k3s channel instead and executed properly

Copy link
Collaborator

@mysticaltech mysticaltech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good!

@mysticaltech mysticaltech merged commit db1a260 into kube-hetzner:master Aug 9, 2024
3 checks passed
@mysticaltech
Copy link
Collaborator

Sorry @gmautner, I had to revert the PR as it did not did not deploy on my test. If you manage to fix it with or without channel and with or without version, please don't hesitate to submit a new one.

Screenshot from 2024-08-09 03-36-09

@gmautner
Copy link
Contributor Author

gmautner commented Aug 9, 2024

I think this was caused by a network connectivity issue unrelated to my PR.

When the server https://update.k3s.io/v1-release/channels is down, the behaviour of the k3s installation script is to return the input channel instead of the release, because curl follows all redirects and uses the called URL when there are no redirects.

I manually tested and was able to reproduce the problem with the following commands:

version_url='https://update.k3s.io/v1-release/channels/v1.29'
curl -w '%{url_effective}' -L -s -S ${version_url} -o /dev/null | sed -e 's|.*/||'
v1.29.7+k3s1

Turning off the network:

curl -w '%{url_effective}' -L -s -S ${version_url} -o /dev/null | sed -e 's|.*/||'
curl: (6) Could not resolve host: update.k3s.io
v1.29

This behaviour has been documented by other users of kube-hetzner, like:

k3s-io/k3s#10578 (comment)

So probably it has no relationship to the PR. Could you please test it again?

@mysticaltech
Copy link
Collaborator

@gmautner Thanks for the info. This is a crazy coincidence because I've ever seen this very error before.

@mysticaltech
Copy link
Collaborator

Ok, I see it's a new feature to allow specifying the version. Please let's wait a bit until it's more stable then we can try again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants