Repository navigation
fix(k8s): inline downward-API label env vars instead of keeping the labels - #18
Merged
Merged
Conversation
InjectCA named the secret "bridge-ca", and Rename only appends the device ID, so every bridge from a device shared bdg-bridge-ca-<device>: - each create generated a new CA and replaced the one the device's other bridges had mounted; - two concurrent creates both found it missing and raced to create it, so the loser failed with AlreadyExists; - each create relabeled it with its own bridge's labels, so removing that bridge deleted the secret out from under the others, whose pods then can't restart. The secret is now named after the bridge (bdg-bridge-ca-<bridge>-<device>), so it carries only its own bridge's labels and is removed with it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…abels A bridge kept every source label a fieldRef env var reads. vercel/api's pods read SERVICE_NAME from app.kubernetes.io/name, which their Services select on, so each proxy bridge joined the real Service and, once its device was gone, took a share of the service's traffic with it. Co-Authored-By: Claude Opus 5.5 (1M context) <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.
Problem
StripUnreferencedLabelsremoves a source Deployment's labels so that existing Services don't select the bridge pod. It keeps any label afieldRefenv var reads (metadata.labels['key']).A common pattern is a pod that reads its service name from
metadata.labels['app.kubernetes.io/name'], with its Service selecting on that same label. A proxy bridge of such a Deployment keeps the label and joins the real Service's endpoints. Once the bridge's device is gone, the Service sends a share of its traffic to the bridge pod, and those requests fail with 502s or hang.Solution
Before stripping,
inlineLabelFieldRefsreplaces each downward-API label env var with the label's value, in both containers and init containers. It resolves values the way the downward API would, so an absent label becomes"". Since nothing reads the labels any more, all source labels are stripped, and the bridge's own labels are injected as before. The pod's env is unchanged.Tests
TestStripUnreferencedLabels_ServiceDoesNotSelectBridge(new): a pod readsSERVICE_NAMEfromapp.kubernetes.io/name. The test checks that the Service's selector no longer matches the bridge pod and thatSERVICE_NAMEis inlined. It fails without this change.PreservesFieldRefLabelsandInitContainerFieldRefnow assert that the values are inlined and the labels stripped.Bridges that already exist keep their labels until they're recreated or deleted.
🤖 Generated with Claude Code