feat(gateway): add GatewayInstance controller

[michaelbeaumont]

Summary

• Add new controller to handle GatewayInstances.
• Refactor existing Gateway API controller

Blocked by #3469

Issues resolved

Closes #3451
Closes #3446

[codecov-commenter]

Codecov Report

Merging #3476 (34b6bd7) into master (0d1cd23) will decrease coverage by 0.03%.
The diff coverage is 3.35%.

@@            Coverage Diff             @@
##           master    #3476      +/-   ##
==========================================
- Coverage   51.56%   51.53%   -0.04%     
==========================================
  Files         917      917              
  Lines       55482    55551      +69     
==========================================
+ Hits        28611    28628      +17     
- Misses      24584    24640      +56     
+ Partials     2287     2283       -4     

Impacted Files	Coverage Δ
...ime/k8s/controllers/gateway_instance_controller.go	0.00% <0.00%> (ø)
...ns/runtime/k8s/controllers/gatewayapi/condition.go	0.00% <0.00%> (ø)
...e/k8s/controllers/gatewayapi/gateway_controller.go	0.00% <0.00%> (ø)
pkg/plugins/runtime/k8s/plugin.go	1.12% <0.00%> (ø)
pkg/plugins/runtime/k8s/plugin_gateway.go	0.00% <0.00%> (ø)
pkg/core/policy/dataplane_matcher.go	50.87% <100.00%> (+1.78%)	⬆️
pkg/plugins/runtime/gateway/generator.go	78.62% <100.00%> (ø)
pkg/plugins/runtime/gateway/match/gateway.go	70.00% <100.00%> (ø)
pkg/xds/generator/direct_access_proxy_generator.go	85.88% <0.00%> (+1.17%)	⬆️
pkg/dns/vips_allocator.go	73.75% <0.00%> (+1.41%)	⬆️
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0d1cd23...34b6bd7. Read the comment docs.

[jpeach]

This looks good to me. We spin take any remaining items out into separate github issues.

[michaelbeaumont]

This is blocked by #3546 setting the tags correctly on the Dataplane. We can either:

• Lookup the GatewayInstance tags in the PodReconciler, similar to how we look up Services with normal Pods.
• Create the Dataplanes in the GatewayInstanceReconciler

The second option is tricky since we have a number of assumptions that Dataplanes are named after Pods. We would need to maintain spec.replicas Dataplanes and match them to the Pods created by the ReplicaSet.
I prefer the first option, it seems less complex to use the owner reference on the Deployment to fetch the GatewayInstance.

[jpeach]

Lookup the GatewayInstance tags in the PodReconciler, similar to how we look up Services with normal Pods.

When you build the deployment, could you smash the tags into an annotation on the pod (using a JSON blob as the value)?

[michaelbeaumont]

Lookup the GatewayInstance tags in the PodReconciler, similar to how we look up Services with normal Pods.

When you build the deployment, could you smash the tags into an annotation on the pod (using a JSON blob as the value)?

Yes I think so, I decided against this on account of the "hacky" factor but yes, it's worth exploring

[michaelbeaumont]

@jpeach works quite well and perhaps not as ugly as I thought.
Going to merge this, if you see anything in the newest commits, let me know.