CCM: watch-based route controller reconciliation using informers

[lukasmetzner]

Enhancement Description

The cloud-controller-manager includes several controllers, one of which is the routes controller. Currently, this controller reconciles cloud routes at a fixed interval (default: 10 seconds), resulting in unnecessary API calls to cloud providers.

In contrast, other controllers like the service and node controllers have already adopted a more efficient watch-based approach using informers.

This enhancement proposes introducing a new feature gate in the cloud-controller-manager to enable an informer-based reconciliation mechanism for the routes controller, reducing redundant API traffic and improving efficiency.

• One-line enhancement description (can be used as a release note): Introduce watch-based reconciliation in the cloud-controller-managers route controller
• Kubernetes Enhancement Proposal: TBD
• Discussion Link: meeting notes
• Primary contact (assignee): @lukasmetzner @apricote
• Responsible SIGs: cloud-provider
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.34
  • Beta release target (x.y): 1.35
  • Stable release target (x.y): 1.36
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s): WIP: feat(ccm): watch-based route controller reconciliation kubernetes#131220
  • Docs (k/website) update PR(s):

[lukasmetzner]

/sig cloud-provider

[aojea]

I personally do not think we need a KEP for this, we have made this sort of changes on the past in this area and is how we implement all of our controllers, so this is more about cleaning tech debt.

I'm happy to help with the review since the change seems relatively simple, but I leave the final decision to cloud provider leads @cheftako @elmiko WDYT?

[lukasmetzner]

I have brought this to the sig/cloud-provider meeting and the decision was to create a KEP. The meeting is unfortunetly not yet uploaded, so I have added a link to the meeting notes for now.

Not everyone was present in the meeting, maybe we want to discuss this here?

It is my first contribution, so I am unopinionated if this should have a KEP ^^

[elmiko]

apologies on the late upload for the meeting, it should be available now.

i was not at the meeting in question, but given the scope of this change and what @aojea is saying, i tend to agree that we probably don't need a new KEP for this work.

i would like to see us document the change in the cloud-provider repo somewhere, but we can leave that up to the review process.

[aojea]

i was not at the meeting in question, but given the scope of this change and what @aojea is saying, i tend to agree that we probably don't need a new KEP for this work.

@elmiko my apologies, I was checking the PR and what it seemed a simpler change at first time can have some edges that makes a mini-KEP and a feature gate to rollout safely the change required ... it is not a complex change, but since this is revendored in the cloud providers is better to be safe than sorry

[elmiko]

no worries @aojea , and thank you for double checking. my main goal is to make sure that we fully document this so that users do not experience those edge cases. i tend to default towards making a KEP since that it usually a nice place to document.

i did check the other KEPs in the sig cloud-provider directory and i don't think updating any of those would be sufficient.

so, if we are in agreement, then perhaps @lukasmetzner should continue with the KEP?