Repository navigation
fix: Kubernetes launcher - Treat an unreachable kubelet as a lost log - #418
Open
yuechao-qin wants to merge 1 commit into
Open
yuechao-qin wants to merge 1 commit into
yuechao-qin wants to merge 1 commit into
Conversation
A container log is read through the API server's proxy to the node's kubelet. When the cluster-autoscaler reclaims the node, that proxy fails with a 500 whose body reports a failed dial of port 10250. The log died with the node, so retrying cannot recover it; the read is a lost cause from the first attempt. `_get_log_by_pod_key` now returns None for that error, beside the existing branches for a deleted Pod (404) and a container that has not started (400), and logs a warning carrying the full response body. The match is deliberately narrow: a 500 whose body names the container-log endpoint and a failed dial. Any other 500 still raises, so a reworded or unrelated error surfaces instead of being swallowed.
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
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.
What
A container log is read through the API server's proxy to the node's kubelet. When the
cluster-autoscaler reclaims the node, that proxy fails with a 500 — and the log died with the
node, so every retry is spent on something that cannot succeed.
_get_log_by_pod_keynow returnsNonefor that error, joining the branches that already existfor a deleted Pod and a container that has not started.
The error
Observed response body, with cluster identifiers replaced:
Raised as
ServiceException, a subclass ofApiException, so it arrives at the existingexcept ApiException. The test builds it from a response whosedataisbytes, the way theclient does, because the client decodes the body itself — and older clients store it undecoded,
which is why
_api_exception_bodyaccepts either.Every error on this path, measured
One deployment, 72 hours:
dial tcp <node-ip>:10250: i/o timeoutpods "<pod>" not foundcontainer "main" in pod "<pod>" is waiting to start: PodInitializingThose three are the whole census, so the narrow match costs no coverage. Identifiers are replaced
because this repository is public; the unredacted bodies and the queries behind each count are in
Shopify/oasis-backend#827, an internal
repository.
Why match narrowly
The wording comes from the API server's log proxy and is not a documented contract. A 500 is only
treated as a lost log when its body names the container-log endpoint and a failed dial;
anything else raises, so a reworded error surfaces rather than being silently swallowed. A test
covers that near miss: a kubelet failure reported as a TLS error still propagates.
Verification
pytest --ignore=tests/instrumentation -q→ 433 passed. Neutering the classifier turns exactlythe kubelet case red. The warning logs the full response body, so a wording change is visible in
the logs rather than only in a metric.