Add hostname/ip information to VKC loadbalancer status

[robobario]

Type of change

• Enhancement / new feature

#status

Description

When reporting the VKC status for an ingress:

If the ingress is associated with a Service with a loadBalancer object in its status we report each ingress point's ip or hostname in the VKC status.

for example I edit the downstream-tls example KafkaProxyIngress to:

kind: KafkaProxyIngress
apiVersion: kroxylicious.io/v1alpha1
metadata:
  name: cluster-ip
  namespace: my-proxy
spec:
  proxyRef:
    name: simple
  loadBalancer:
    bootstrapAddress: bootstrap.example.com
    advertisedBrokerAddressPattern: broker-$(nodeId).example.com

Then run minikube tunnel and I see in the status

  status:
    ... snip ...
    ingresses:
    - bootstrapServer: bootstrap.example.com:9083
      loadBalancerIngressPoints:
      - ip: 127.0.0.1
      name: cluster-ip
      protocol: TLS
    observedGeneration: 2

which corresponds to the ip from the status of the service:

kubectl get service -nmy-proxy simple-sni -o=jsonpath='{.status.loadBalancer.ingress[0]}'
{"ip":"127.0.0.1","ipMode":"VIP"}

Additional Context

The first time a user sets up a LoadBalancer KafkaProxyIngress they will be responsible for configuring their DNS to resolve some hostnames to the loadbalancer ip/hostname. That means we must instruct users on how to locate the shared SNI service and extract its details. It's a bit fiddly.

With this change, the ip/hostname the user needs to plug into their DNS will be visible on the VirtualKafkaCluster status.

Closes #2295

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• PR raised from a fork of this repository and made from a branch rather than main.
• Write tests
• Update documentation
• Make sure all unit/integration tests pass
• Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
• If applicable to the change, trigger the system test suite. Make sure tests pass.
• If applicable to the change, trigger the performance test suite. Ensure that any degradations to performance numbers are understood and justified.
• Ensure the PR references relevant issue(s) so they are closed on merging.
• For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

NOTE: You must be a member of @kroxylicious/developers to trigger the system test and performance test suites. If you are not part of this group, comment on the PR requesting a trigger, tagging @kroxylicious/developers.

[SamBarker]

LGTM with a couple of nits.

[SamBarker]

I think it would be worth extracting a method reference. Something like bootstrapMatchesIngress or something else descriptive.

[SamBarker]

I think we should be explicit that we expect users to arrange DNS etc based on these values. Though maybe thats too involved for field level documentation?

[robobario]

Yeah it feels too involved, maybe I should remove the second sentence as it's misleading (can be misinterpreted as saying it's a hostname you can plug into a client) and stick to describing what it is, not how we intend people to use it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud