Support customization of health check attributes for the LB's target groups for both Load Balancers

[mtulio]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Currently the health check attributes for the target groups created for each listener from Primary and Secondary load balancers are static defined. For the API it have const attributes, and the additional listeners does not provide the interface to customize the health check attributes.

In OpenShift we using the different health check attributes than delivered by default by CAPA for Kube apiserver, and additional health checks. Exposing the following health check attributes would help to keep our standard and broadly tested health check attributes:

• Protocol
• Path
• IntervalSeconds
• TimeoutSeconds
• ThresholdCount
• UnhealthyThresholdCount

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

This is the proposed fields that would be interesting to expose in AWSLoadBalancerSpec stanza.

• Kube apiserver target group attributes:

HealthCheckProtocol: "HTTPS"
HealthCheck: &capa.TargetGroupHealthCheck{
	IntervalSeconds:         ptr.To(int64(10)),
	TimeoutSeconds:          ptr.To(int64(10)),
	ThresholdCount:          ptr.To(int64(2)),
	UnhealthyThresholdCount: ptr.To(int64(2)),
}

• Additional listeners's target group attributes:

AdditionalListeners: []capa.AdditionalListenerSpec{
	{
		Port:     22623,
		Protocol: capa.ELBProtocolTCP,
		HealthCheck: &capa.TargetGroupHealthCheck{
			Protocol:                ptr.To("HTTPS"),
			Path:                    ptr.To("/healthz"),
			IntervalSeconds:         ptr.To(int64(10)),
			TimeoutSeconds:          ptr.To(int64(10)),
			ThresholdCount:          ptr.To(int64(2)),
			UnhealthyThresholdCount: ptr.To(int64(2)),
		},
	},
},

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.