Writable was added to HostPathMount in v1alpha1 in order to control if an extra
volume is mounted in read only or writable mode.
Usually, in Kubernetes, this option is referred to as ReadOnly, instead of
Writable and is defaulted to `false`. However, at the time, all extra volumes
to pods were defaulted to read-only. Therefore, to avoid changes to existing
v1alpha1 configs, this option had to be added with reversed meaning.
Hence, it's called `writable`.
Now, with the migration towards v1beta1, we can safely change this to ReadOnly
and get it in sync with the reset of Kubernetes.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
In v1alpha3's, control plane component config options were nested directly into
the ClusterConfiguration structure. This is cluttering the config structure and
makes it hard to maintain. Therefore the control plane config options must be
separated into different substructures in order to graduate the format to beta.
This change does the following:
- Introduces a new structure called ControlPlaneComponent, that contains fields
common to all control plane component types. These are currently extra args
and extra volumes.
- Introduce a new structure called APIServer that contains
ControlPlaneComponent and APIServerCertSANs field (from ClusterConfiguration)
- Replace all API Server, Scheduler and Controller Manager options in
ClusterConfiguration with APIServer, ControllerManager and Scheduler fields
of APIServer and ControlPlaneComponent types.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
In the past the discovery configuration expected, that we can support multiple
API server endpoints. In practice, we always end up with a single API server
endpoint, because, even in HA setups, we use a load balancer scheme for API
servers.
Therefore, to reduce complexity and improve readability of the config, the
multiple API server endpoints support is removed from the bootstrap token
discovery join method and configuration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Order of Volumes and VolumeMounts in the pod objects created by
kubeadm is undefined as they're represended as maps in the
controlPlaneHostPathMounts struct.
This influences 'kubeadm upgrade' logic in a way that even when
manifest of the component is not changed kubeadm tries to upgrade
it because most of the time current and new pods are not equal
due to the different order of Volumes and VolumeMounts.
For example 'kubeadm apply diff' almost always shows difference
in Volumes and VolumeMounts because of this:
volumeMounts:
+ - mountPath: /etc/kubernetes/pki
+ name: k8s-certs
+ readOnly: true
- mountPath: /etc/ssl/certs
name: ca-certs
+ readOnly: true
+ - mountPath: /etc/pki
+ name: etc-pki
+ readOnly: true
+ - mountPath: /usr/share/ca-certificates
+ name: usr-share-ca-certificates
readOnly: true
- mountPath: /etc/ca-certificates
name: etc-ca-certificates
readOnly: true
- - mountPath: /etc/pki
- name: etc-pki
- readOnly: true
- - mountPath: /etc/kubernetes/pki
- name: k8s-certs
- readOnly: true
- - mountPath: /usr/share/ca-certificates
- name: usr-share-ca-certificates
- readOnly: true
Sorting Volumes and VolumeMounts should fix this issue and help
to avoid unnecessary upgrades.
When doing upgrades kubeadm generates new manifest and
waits until kubelet restarts correspondent pod.
However, kubelet won't restart pod if there are no changes
in the manifest. That makes kubeadm stuck waiting for
restarted pod.
Skipping upgrade if new component manifest is the same as
current manifest should solve this.
Fixes: kubernetes/kubeadm#1054
This change splits out discovery fields from JoinConfiguration by performing
the following changes:
- Introduce a BootstrapTokenDiscovery structure, that houses configuration
options needed for bootstrap token based discovery.
- Introduce a FileDiscovery structure, that houses configuration options
(currently only a single option) needed for KubeConfig based discovery.
- Introduce a Discovery structure, that houses common options (such as
discovery timeout and TLS bootstrap token) as well as pointer to an instance
of either BootstrapTokenDiscovery or FileDiscovery structures.
- Replace the old discovery related JoinConfiguration members with a single
Discovery member.
This change is required in order to cleanup the code of unnecessary logic and
make the serialized JoinConfiguration more structured (and therefore, more
intuitive).
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
This change allows mixing InitConfiguration/ClusterConfiguration with
JoinConfiguration in a single YAML file, by performing the following changes:
- Replace the explicit error in `DetectUnsupportedVersion` with a warning.
- Modify `NodeConfigFileAndDefaultsToInternalConfig` to use only
`JoinConfiguration`.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
The default version in kubeadm is now `stable-1`. This will
pull a version from the `stable-1.txt` endpoint which might
end up being newer than the version of the client by a magnitude
of MINOR or even a MAJOR release.
To be able to prevent this scenario add the new helper function:
validateStableVersion()
This function determines if the remote version is newer than the
local client version and if that's the case it returns `stable-X.xx`
that conforms with the version of the client. If not it returns
the remote version.
A previous commit updated 17.xx -> 18.xx without considering
that some systems still use 17.xx.
Add handling for 17.0[3,6,9] as validated versions.
Also re-format the error message because the version is not validated
per maximum basis, but rather based on existing validation.
