Make Kubernetes version configurable

[st3v]

As the title suggests, I wanted to have a way to configure the Kubernetes version for the Minikube cluster.

This also fixes a few formatting issues and broken TOC links in the README. Happy to submit that as a separate PR if you prefer.

Thanks for creating this module to begin with!

[scholzj]

If you really want, I can probably merge this. I do not see any harm it would do.

But I'm also not sure this would work well. There is no real effort for backwards compatibility testing etc. I really use this only for development and testing with the latest Kubernetes version. So when new version is released, I just bump the setup script, networking or add-ons as needed and see that it works with the new version. And that is it. I do not do any testing with older versions and TBH, I do not have any plans to do so because of limited time I have for this.

So if it would work with some older versions, it would be more coincidence rather than intention. So sometimes, it might allow you to change the version. But in other cases it would simply fail on something what is not backwards compatible.

As I said, I don't mind merging this change if you still want it. But I wanted to set the expectations right.

[st3v]

Thanks, this is valuable context! Personally, I'd be okay with this caveat. That being said, though, adding this variable makes the Kubernetes version fully configurable not just for me but everyone else, and I really do not want to speak for anyone but myself. Chances are there will be folks that do not share the expectations you laid out above. If they run into problems, they might open an issue which in turn would put an unnecessary burden on you.

That got me thinking about whether there was some sort of middle ground between not being able to choose the Kubernetes version at all and choosing a version at random while hoping for the best.

How would you feel about creating a matching Github tag every time you upgrade the module to use the latest K8s version? I.e.:

$ git tag v1.25.0 5e014cb
$ git tag v1.24.4 29caddd
$ git tag v1.24.3 a5f3385
...

That way we would keep the version of the module in lock-step with whatever was the latest patch of the latest minor for K8s at a given time. If I wanted to create a v1.24.4 of Minikube, I could specify ref=v1.24.4 when pulling in the module. E.g.:

module "minikube" {
  source = "git::https://github.com/scholzj/terraform-aws-minikube.git?ref=v1.24.4"
  ...
}

To be clear, I would not expect you to branch and bump patch versions on older K8s minors. E.g. I would not expect there ever to be a tag/branch for v1.24.5 now that v1.25.0 is out. For my specific use case, this would be acceptable I think. Like you, I also only use this for testing. I consider the risk of my tests breaking in between two patches of the same K8s minor as relative low. Hence, I care less about being able to choose a specific patch version and more about having a way to test against the current and the previous minors.

If this kind of approach sounds palatable to you, I'd simply close this PR and submit a separate one for the README fixes. WDYT?

[scholzj]

Thanks, this is valuable context! Personally, I'd be okay with this caveat. That being said, though, adding this variable makes the Kubernetes version fully configurable not just for me but everyone else, and I really do not want to speak for anyone but myself. Chances are there will be folks that do not share the expectations you laid out above. If they run into problems, they might open an issue which in turn would put an unnecessary burden on you.

Well, from my point of view, maybe you can add some explanatory comments and add it to the README.md as well.

That got me thinking about whether there was some sort of middle ground between not being able to choose the Kubernetes version at all and choosing a version at random while hoping for the best.

How would you feel about creating a matching Github tag every time you upgrade the module to use the latest K8s version? I.e.:

$ git tag v1.25.0 5e014cb
$ git tag v1.24.4 29caddd
$ git tag v1.24.3 a5f3385
...

That way we would keep the version of the module in lock-step with whatever was the latest patch of the latest minor for K8s at a given time. If I wanted to create a v1.24.4 of Minikube, I could specify ref=v1.24.4 when pulling in the module. E.g.:

module "minikube" {
  source = "git::https://github.com/scholzj/terraform-aws-minikube.git?ref=v1.24.4"
  ...
}

To be clear, I would not expect you to branch and bump patch versions on older K8s minors. E.g. I would not expect there ever to be a tag/branch for v1.24.5 now that v1.25.0 is out. For my specific use case, this would be acceptable I think. Like you, I also only use this for testing. I consider the risk of my tests breaking in between two patches of the same K8s minor as relative low. Hence, I care less about being able to choose a specific patch version and more about having a way to test against the current and the previous minors.

If this kind of approach sounds palatable to you, I'd simply close this PR and submit a separate one for the README fixes. WDYT?

TBH, this sounds a bit too complicated to me and beats the purpose for which I have this. But in a way:

• The tags already exist, they just don't align to the Kubernetes version. You need to find the right version in releases.
• If you want, you can install the addons through the GitHub URLs from the tag.
• The only issue is the Calico networking which is hardcoded. Maybe we can make it configurable and then you can make it more easier to customize.

[scholzj]

PS: Unfortunately, there is no easy way to push the addons to the EC2 instance directly and not through GitHub. At some point, even the Calico networking did not fit anymore into the cloud data. The downloading of the files from GitHub is a bit akward.

[st3v]

Alright. I added a bit of a disclaimer to both the README as well as the variable itself.