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: KEP-5237: watch-based route controller reconciliation using informers #5289
• Discussion Link:
  • meeting notes
  • KEP TL;DR
  • Google docs KEP draft
• Primary contact (assignee): @lukasmetzner @apricote
• Responsible SIGs: cloud-provider
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.35
  • Beta release target (x.y): 1.36
  • Stable release target (x.y): 1.37
• Alpha
  • KEP (k/enhancements) update PR(s): KEP-5237: watch-based route controller reconciliation using informers #5289
  • Code (k/k) update PR(s): feat(ccm): watch-based route controller reconciliation kubernetes#131220
  • Docs (k/website) update PR(s): feat: add feature gate CloudControllerManagerWatchBasedRoutesReconciliation website#52872 feat(blog): feature blog for watch based routes reconciliation website#52973

[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?

[lukasmetzner]

@elmiko @cheftako @JoelSpeed

I've put together a TL;DR summary of the KEP for easier review. It’s also linked in the issue description.

At the end of the document, I’ve outlined a few open questions where I’d really appreciate input from the SIG.

Thanks in advance for your feedback!

Best regards,
Lukas

[elmiko]

thanks @lukasmetzner , apologies for the delay getting back here. i am putting this in my queue for the week.

[elmiko]

@lukasmetzner i think the draft is looking good in terms of the core details. i'm not sure the best way to answer the open questions, but we should definitely bring this up again at the next sig cloud provider meeting.

i think it would be good to start formatting this kep using the template from the enhancements repo, and perhaps we want to answer the open questions during review?

[apricote]

Thanks for looking into it! Lukas is going to be back on monday, and at least one of us will be at the next sig meeting :)

The draft doc is following the template besides the "Release Signoff Checklist". Should we add that in the Google Doc or move it to a PR now and also add the kep.yaml?