CAPD: make the kindest/haproxy image configurable

[joshrosso]

User Story

As an operator, I'd like to use a custom HA proxy image for my CAPD-based cluster's API server loadbalancer.

Detailed Description

Today, the haproxy image is hard coded and not configurable:

cluster-api/test/infrastructure/docker/third_party/forked/loadbalancer/const.go

Lines 19 to 20 in bfc6f80

	// Image defines the loadbalancer image:tag
	const Image = "kindest/haproxy:2.1.1-alpine"

Making this configurable would allow CAPD users to reference custom images and/or registries where they can pull this image from.

/kind feature

[vincepri]

/area provider/docker
/milestone v0.4

[fabriziopandini]

What about implementing something like

// DockerClusterSpec defines the desired state of DockerCluster.
type DockerClusterSpec struct {
	...

	// LoadBalancer allows to define configurations for the cluster load balancer.
	// +optional
	LoadBalancer DockerLoadBalancer `json:"loadBalancer,omitempty"`
}

// DockerLoadBalancer allows to define configurations for the cluster load balancer.
type DockerLoadBalancer struct {
	// ImageMeta allows to customize the image used for image used for the cluster load balancer
	ImageMeta `json:",inline"`
}

// ImageMeta allows to customize the image used for components that are not
// originated from the Kubernetes/Kubernetes release process.
type ImageMeta struct {
	// ImageRepository sets the container registry to pull the haproxy image from.
	// if not set, "kindest" will be used instead.
	// +optional
	ImageRepository string `json:"imageRepository,omitempty"`

	// ImageTag allows to specify a tag for the haproxy image.
	// if not set, "2.1.1-alpine" will be used instead.
	// +optional
	ImageTag string `json:"imageTag,omitempty"`
}

So we have something that mimics what we have in kubeadm config types?

[joshrosso]

@fabriziopandini should ImageMeta actually contain 3 fields, as follows?

// ImageMeta allows to customize the image used for components that are not
// originated from the Kubernetes/Kubernetes release process.
type ImageMeta struct {
	// ImageRepository sets the container registry to pull the haproxy image from.
	// if not set, "kindest" will be used instead.
	// +optional
	ImageRepository string `json:"imageRepository,omitempty"`

        // Image specifies the image name inside the ImageRepository
        // if not set, "haproxy" will be used instead.
        Image string

	// ImageTag allows to specify a tag for the haproxy image.
	// if not set, "2.1.1-alpine" will be used instead.
	// +optional
	ImageTag string `json:"imageTag,omitempty"`
}

if your suggestion is more "standard" in how kubeadm/kubernetes/etc does things, i'm OK with your suggestion.

[stmcginnis]

/assign

Will take a crack at the suggested change.

[vincepri]

We usually don't allow overwriting the ImageName, keeping that fixed and consistent with all the other places where ImageMeta is used

[joshrosso]

cool, makes sense -- thanks 👍

[vincepri]

@fabriziopandini One thing to note though is that we're not calling out anywhere in the proposed API addition that the load balancer is haproxy

[stmcginnis]

@vincepri should that be in a code comment calling that out, or are you thinking somewhere more visible?

[vincepri]

Code comment could be good, I'm wondering though if we should have Haproxy as a specific field under the DockerLoadBalancer struct

[stmcginnis]

So like @joshrosso was suggesting, but instead of having the field in ImageMeta, move it up a level to the DockerLoadBalancer struct?

[vincepri]

Not the imageName per se, I was more suggesting something like these structs/fields
DockerLoadBalancer -> DockerHaproxyLoadBalancer -> ImageMeta