Skip to content
This repository was archived by the owner on Jul 30, 2021. It is now read-only.

📖 Update default behavior for kubernetesVersion field in the readme #261

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,6 +136,7 @@ CABPK will fill in some values if they are left empty with sensible defaults:

| `KubeadmConfig` field | Default |
| ----------------------------------------------- | ------------------------------------------------------------ |
| `clusterConfiguration.KubernetesVersion` | `Machine.Spec.Version` [1] |
| `clusterConfiguration.clusterName` | `Cluster.metadata.name` |
| `clusterConfiguration.controlPlaneEndpoint` | `Cluster.status.apiEndpoints[0]` |
| `clusterConfiguration.networking.dnsDomain` | `Cluster.spec.clusterNetwork.serviceDomain` |
Expand All @@ -145,6 +146,9 @@ CABPK will fill in some values if they are left empty with sensible defaults:

> IMPORTANT! overriding above defaults could lead to broken Clusters.

[1] if both `clusterConfiguration.KubernetesVersion` and `Machine.Spec.Version` are empty, the latest Kubernetes
version will be installed (as defined by the default kubeadm behavior).
Copy link
Contributor

Choose a reason for hiding this comment

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

😬 I'm not sure we can guarantee this... Since we are using pre-baked images the version deployed would require some type of defaulting in place on the infrastructure provider side to choose the right image...

Copy link
Contributor

Choose a reason for hiding this comment

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

kubeadm's default is stable-1 for the control plane images ever since at least 1.13. It's different before (approximately) that version and specified a specific version, but do we really need to worry about older versions?

Copy link
Contributor

Choose a reason for hiding this comment

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

My comment was more indicating that we cannot necessarily ensure a "Kubernetes Version" from the bootstrap provider. Especially since we expect the binaries on disk to already exist in the infrastructure providers.

Copy link
Contributor

Choose a reason for hiding this comment

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

oh, yeah, I think that's a very fair point.

We can ensure the field is set, but we cannot guarantee you'll get that kubernetes version installed.

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm but i think it should mostly be ok if kubeadm gets configured with the right version...it could get a little weird spanning large minor versions, but generally i think we'll be ok here. Just in the edge cases it could be confusing. Such as a user specifies 1.10 but uses a kubeadm v1.16. kubeadmv1.16 init looks VERY different from a kubeadmv1.10 init which may or may not produce the right manifests and will most certainly produce the wrong systemd unit files.

Copy link
Contributor

Choose a reason for hiding this comment

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

Between that and the uncertainty around lookup behavior per provider, I think I would rather force that the version be declared "somewhere" rather than having odd and inconsistent behavior otherwise.


#### Examples
Valid combinations of configuration objects are:
- at least one of `InitConfiguration` and `ClusterConfiguration` for the first control plane node only
Expand Down