[cloud-provider-yandex] Set provider ID if empty - #195
Open
unholyFigaro wants to merge 1 commit into
Open
Conversation
Signed-off-by: Vladislav Denisov <vlad144denisov@gmail.com>
pabateman
self-requested a review
June 29, 2026 06:15
m1ron0xFF
added a commit
that referenced
this pull request
Aug 19, 2026
An empty spec.providerID hides two causes that need different fixes, and
skipping the Node without saying which one it is turns a real capacity loss
into a silent one. The node.cloudprovider.kubernetes.io/uninitialized taint
tells them apart at no cost:
- taint present: kubelet did hand the Node to a cloud provider and
cloud-node has not initialized it yet, normally a matter of seconds;
- taint absent: the Node was never offered to a cloud provider, so it is
either a genuine static Node or a cloud VM whose kubelet is missing
--cloud-provider=external, and it stays out of the target groups until
that is fixed.
Raised while reviewing #195, which hit the second case in production and
proposed backfilling providerID instead. Backfilling writes an immutable
field from a Node-name lookup, so a wrong match becomes permanent, and the
root cause is cluster configuration that also affects Node addresses, zones
and instance types. Reporting which cause it is, is the part that belongs
in the target group syncer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Egor Balakin <me@mironoff.msk.ru>
m1ron0xFF
added a commit
that referenced
this pull request
Aug 20, 2026
An empty spec.providerID hides two causes that need different fixes, and
skipping the Node without saying which one it is turns a real capacity loss
into a silent one. The node.cloudprovider.kubernetes.io/uninitialized taint
tells them apart at no cost:
- taint present: kubelet did hand the Node to a cloud provider and
cloud-node has not initialized it yet, normally a matter of seconds;
- taint absent: the Node was never offered to a cloud provider, so it is
either a genuine static Node or a cloud VM whose kubelet is missing
--cloud-provider=external, and it stays out of the target groups until
that is fixed.
Raised while reviewing #195, which hit the second case in production and
proposed backfilling providerID instead. Backfilling writes an immutable
field from a Node-name lookup, so a wrong match becomes permanent, and the
root cause is cluster configuration that also affects Node addresses, zones
and instance types. Reporting which cause it is, is the part that belongs
in the target group syncer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Egor Balakin <14162703+m1ron0xFF@users.noreply.github.com>
m1ron0xFF
added a commit
that referenced
this pull request
Aug 20, 2026
An empty spec.providerID hides two causes that need different fixes, and
skipping the Node without saying which one it is turns a real capacity loss
into a silent one. The node.cloudprovider.kubernetes.io/uninitialized taint
tells them apart at no cost:
- taint present: kubelet did hand the Node to a cloud provider and
cloud-node has not initialized it yet, normally a matter of seconds;
- taint absent: the Node was never offered to a cloud provider, so it is
either a genuine static Node or a cloud VM whose kubelet is missing
--cloud-provider=external, and it stays out of the target groups until
that is fixed.
Raised while reviewing #195, which hit the second case in production and
proposed backfilling providerID instead. Backfilling writes an immutable
field from a Node-name lookup, so a wrong match becomes permanent, and the
root cause is cluster configuration that also affects Node addresses, zones
and instance types. Reporting which cause it is, is the part that belongs
in the target group syncer.
The bookkeeping behind that report is a rendered string rather than a set,
so the accumulation loop, the nil guard and a duplicate join disappear and
the zero value means "nothing skipped before" on its own. Reasons are
sorted, which is what makes the comparison correct at all - Node order from
the informer is not stable - and keeps the logged line stable between
reports. cleanUpTargetGroups resets it alongside lastVisitedNodes: both
describe target groups that have just been removed.
Signed-off-by: Egor Balakin <14162703+m1ron0xFF@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a patch to the Yandex cloud-controller-manager to handle nodes with an empty providerID during load balancer target group
synchronization.
Why do we need it, and what problem does it solve?
In some cases, a node may reach CCM reconciliation with an empty providerID, which causes target group sync to fail and breaks load balancer reconciliation. This change resolves the instance by node name, backfills the missing providerID, and allows reconciliation to proceed normally