- drop versions < 1.22 in the etcd map
- use 3.5.9-0 for >= 1.22 versions
- make the minimum version for external etcd 3.4.13-4 and max 3.5.9-0
- update images_test to not rely on a pinned etcd version in tests
note: the image 3.4.18-0 was never released in registry.k8s.io!
Kubeadm no longer supports kube-dns and CoreDNS is the only
supported DNS server. Remove ClusterConfiguration.DNS.Type
from v1beta3 that is used to set the DNS server type.
- Uses correct pause image for Windows
- Omits systemd specific flags
- Common build flags function to be used by Linux and Windows
- Uses user configured image repository for Windows pause image
The PR introducing 5bb8069 got merged accidentally (the CI robot not
respecting a hold). Hence, the feedback to that PR is merged separately.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
As the hyperkube image is itself deprecated and moved out of tree, its use with
kubeadm gets deprecated too. Hence, deprecation messages will be printed when
it is used.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
The kubelet allows you to set `--pod-infra-container-image`
(also called `PodSandboxImage` in the kubelet config),
which can be a custom location to the "pause" image in the case
of Docker. Other CRIs are not supported.
Set the CLI flag for the Docker case in flags.go using
WriteKubeletDynamicEnvFile().
Up until now UnifiedControlPlaneImage existed as a string value as part of the
ClusterConfiguration. This provided an override for the Kubernetes core
component images with a single custom image. It is mostly used to override the
control plane images with the hyperkube image. This saves both bandwith and
disk space on the control plane nodes.
Unfortunately, this specified an entire image string (complete with its prefix,
image name and tag). This disables upgrades of setups that use hyperkube.
Therefore, to enable upgrades on hyperkube setups and to make configuration
more convenient, the UnifiedControlPlaneImage option is replaced with a boolean
option, called UseHyperKubeImage. If set to true, this option replaces the
image name of any Kubernetes core components with hyperkube, thus allowing for
upgrades and respecting the image repository and version, specified in the
ClusterConfiguration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
As kube-dns transitioned to fat manifests, it's no longer required to use arch
suffixed images. This change makes use of fat manifests for kube-dns and
removes the last few calls to the GetGenericArchImage function, thus removing
GetGenericArchImage too.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
This change removes arch suffixes from control plane images (etcd,
kube-apiserver, kube-scheduler, kube-proxy, etc.). These are not needed, as
almost all control plane images have a fat manifest now.
We have arch suffixes only for kube-dns images now.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Replace the unnecessary use of InitConfiguration in images.go with
ClusterConfiguration. This changes the interfaces of the following functions:
- GetKubeControlPlaneImage
- GetEtcdImage
- GetAllImages
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Until now, kube-proxy image was handled in two separate places:
- In images.go along with the pre-pull code and without having the image
override capabilities (via UnifiedControlPlaneImage)
- In the kube-proxy manifest, where image override was possible.
This duplicates the kube-proxy image logic and makes it prone to errors.
Therefore, this change aims to deduplicate it and make it more straightforward.
This is achieved in the following ways:
- GetKubeControlPlaneImage is used for kube-proxy image fetching, thus allowing
for the image to be overriden by UnifiedControlPlaneImage.
- Remove duplicated logic from the manifest and use GetKubeControlPlaneImage to
generate the image for the manifest.
Additionally, GetKubeControlPlaneImageNoOverride is removed as the only use case
for the function is now invalid.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
It appears that sidecar and dnsmasq-nanny images are now required for
kube-dns deployment to work correctly. Thus the following default kube-dns
images are used now:
- k8s.gcr.io/k8s-dns-kube-dns-amd64:1.14.10
- k8s.gcr.io/k8s-dns-sidecar-amd64:1.14.10
- k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.10
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
