refactor the kubernetes provider to be provider-agnostic

[shawnh2]

Description:

For now, all the resources related process method in k8s provider are coupling deeply with k8s client, we should free these method from it.

https://github.com/envoyproxy/gateway/blob/e8b8074fc7e9a23e3e12d6ade55307b618f421fa/internal/provider/kubernetes/controller.go#L698

So I propose a refactor: the basic idea is to separate how we process resources and how we retrieve resources.

By defining Operations interface and ResourceProcessor structure, each provider can maintain their own implemention of Operations, and different provider can share the same ResourceProcessor.

type Operations interface {
    ListGateways()
    ListHTTPRoutes()
    FindReferenceGrant()
    ...
}

type ResourceProcessor struct {
    Operations
}

func (r *ResourceProcessor) ProcessGateways() {
    // use r.ListGateways() to retrieve all Gateway resources
}
func (r *ResourceProcessor) ProcessHTTPRoutes() {}
func (r *ResourceProcessor) findReferenceGrant() {}
...

we can

• let k8s provider only foucs on how to retrieve resources, so does file provider
• the k8s and file provider can share the same process logic for resources, and we don't need to maintain two places of code for each provider type

[optional Relevant Links:]

Any extra documentation required to understand the issue.

[Xunzhuo]

Make sense to me, it helps for multi-provider support.

[shawnh2]

will try to first refactor the current existing k8s provider, and then implement for the new coming file provider.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[sky92zwq]

Is it possible with this refactoring that part of the gateway resources come from k8s and another part from files ( Gateway api related)?

[arkodg]

hey @sky92zwq we'll need to update the Custom provider API and add a Aggregate ish resource provider to handle the case you highlighted