make glooctl check work for kube gateways

[jenshu]

Description

Check Kubernetes Gateway API resources during glooctl check, as long as we detect that the kube gateway integration is enabled in the given gloo installation. We assume kube gateway integration is enabled if 1) we find Gateway CRDs on the cluster and 2) a default GatewayParameters exists in the install namesapce.

Other cleanup:

• Standardized the casing of the glooctl check output and use the actual CRD names, e.g. Checking auth configs... OK is now Checking AuthConfigs... OK
• Removed unused KUBE2E_TESTS var from setup-kind. As of [Migrated] Remove old Istio tests, add new Istio suite with regression values solo-io/gloo#9636 it's not used anymore in the script.

Output :

Checking Deployments... OK
Checking Pods... OK
Checking Upstreams... OK
Checking UpstreamGroups... OK
Checking AuthConfigs... OK
Checking RateLimitConfigs... OK
Checking VirtualHostOptions... OK
Checking RouteOptions... OK
Checking Secrets... OK
Checking VirtualServices... OK
Checking Gateways... OK
Checking Proxies... OK

Detected Kubernetes Gateway integration!
Checking kube GatewayClasses... OK
Checking kube Gateways... OK
Checking kube HTTPRoutes... OK

Skipping Gloo Instance check -- Gloo Federation not detected.
No problems detected.

Checking Deployments... OK
Checking Pods... OK
Checking Upstreams... OK
Checking UpstreamGroups... OK
Checking AuthConfigs... OK
Checking RateLimitConfigs... OK
Checking VirtualHostOptions... OK
Checking RouteOptions... OK
Checking Secrets... OK
Checking VirtualServices... OK
Checking Gateways... OK
Checking Proxies... OK

Skipping Gloo Instance check -- Gloo Federation not detected.
Error: 1 error occurred:
	* unable to determine if kube gateway is enabled: KubeGateway is enabled but the Kubernetes Gateway CRDs are not applied. Please fix this by running `kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml`

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

[solo-changelog-bot]

Issues linked to changelog:
https://github.com/solo-io/solo-projects/issues/5741

[github-actions]

Visit the preview URL for this PR (updated for commit 3d97e2a):

https://gloo-edge--pr9621-glooctl-check-kube-3zxd8mrg.web.app

_{(expires Fri, 28 Jun 2024 19:57:50 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 77c2b86e287749579b7ff9cadb81e099042ef677}

[davidjumani]

I have a similar approach and would like feedback on it :

• First, check the presence of the GatewayParameters CR.
• If found, check the presence of the k8s gateway CRDs.
• If they are not found, error loudly that they are not found and the installation is misconfigured as the GatewayParameters CR is present but the k8s gateway CRDs are not.
• Else proceed with the k8s gateway-related checks

Additionally I think that relying on the presence of the GatewayParameters CR wouldn't be the best way to go about this as users can delete the default CRs and replace them with their own.
Instead, we can label the gloo deployment and check for the presence of that label or the presence of the GG_EXPERIMENTAL_K8S_GW_CONTROLLER env variable something more concrete. I understand that this is tying up the check with the implementation but it seems more robust

[sam-heilbron]

We have some new CRDs:

• https://github.com/solo-io/gloo/blob/main/install/helm/gloo/crds/gateway.solo.io_v1_HttpListenerOption.yaml
• https://github.com/solo-io/gloo/blob/main/install/helm/gloo/crds/gateway.solo.io_v1_ListenerOption.yaml
  They don't report statuses, but I think it would make sense to check them still

[davidjumani]

kick bulldozer

[davidjumani]

We have some new CRDs:

* https://github.com/solo-io/gloo/blob/main/install/helm/gloo/crds/gateway.solo.io_v1_HttpListenerOption.yaml

* https://github.com/solo-io/gloo/blob/main/install/helm/gloo/crds/gateway.solo.io_v1_ListenerOption.yaml
  They don't report statuses, but I think it would make sense to check them still

Will tackle in a followup PR