OCPBUGS-7621-health-Ex-LB: Adding h. check for vSphere external LB se…

[dfitzmau]

OCPBUGS-7621

Version(s):
4.14 through to 4.10

Link to docs preview:
Configuring an external load balancer

QE review:

• QE has approved this change.

Additional information:

• GCP

[ocpdocs-previewbot]

🤖 Updated build preview is available at:
https://62828--docspreview.netlify.app

Build log: https://circleci.com/gh/ocpdocs-previewbot/openshift-docs/20582

[dfitzmau]

Pod object or health check resource?

[dfitzmau]

@rvanderp3

[rvanderp3]

I'm not sure about this one. @cybertron do you have any thoughts on this(or know someone who would)?

[cybertron]

I'm a little confused about what's going on here. We're creating a health-check pod (from what image?) and then adding probes on it? Is the probe config below being consumed by something in the pod? Health checking the pod itself isn't going to work, unless it's got some mechanism to forward the checks to the external LB. I guess I'm unfamiliar with this resource and there's not enough here for me to connect the dots.

My assumption has been that external loadbalancers need to be monitored externally. I suppose you could run the monitoring in the cluster, but if something does fail then your monitoring is unavailable too.

Edit: I see this is based on a KCP which is equally vague about what is happening here. I think we need a bunch more clarification from the bug reporter about what they're asking for. The KCP is missing a lot of context, like where do these health check snippets go? I assume it was obvious to the writer, but as someone who isn't familiar with this I have no idea what to do with them.

[clarkhale]

This doesn't make sense to me around health check pod.

When configuring an external load balancer for an OpenShift cluster, it is not sufficient to just determine whether a backend (e.g. the api, machine config or ingress) is up or down just by the port.

All commercial load balancers, including HAProxy, support the idea of "health probes." These need to be configured IN the external load balancer. The solutions article provides the examples of what these should be.

For example, the ingress controller. If we were to configure that in say, an F5, we would configure the F5 to have each of the ingress controllers as backends. In addition, we would configure a health probe.

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

The F5 would then use two data points to determine if the F5 is available:

First, it would use the ingress controller ports (default 80 and 443).

Second, it would do an HTTP GET to the backend IP and port 1936. If that returns back successful, then the ingress controller is healthy.

Only if both of these points are true will the F5 send traffic to that ingress controller.

I've attached a visual to show what this would look like.

This only shows around the ingress controller, but the similar setup would be for the API and the Machine Config API.

HTH,

-CFH

[dfitzmau]

Health check probes or connection requests?

[dfitzmau]

@rvanderp3

[dfitzmau]

/hold

[clarkhale]

@dfitzmau Here are the diagrams we talked about. In draw.io format (zipped, so github would accept them). There are in three tabs for each of the three cases: API, Machine Config API, and Ingress.

OCPBUGS-7621-LB-Diagrams.zip

[dfitzmau]

Closing PR. Work moved to #65501