Report an unpullable image as its own cause, not as an isolation result - #4
Merged
Conversation
…an isolation result An image the cluster cannot download and a cluster whose networking cannot be characterised are different problems with different owners, and the probe reported them identically: "network isolation could not be verified". Observed live, where a stale image reference pointing at a local registry that no longer runs produced a verdict that read as though something were wrong with the cluster's network, sending the reader to the wrong setting entirely. An image pull failure now travels as its own flag, so a surface can name the setting at fault instead of relaying a networking message. Concurrency for the RBAC preflight, unrelated but from the same observation: readiness ran twenty-six `auth can-i` probes one after another, each a process spawn and a round trip, measured at 221 ms apiece — six seconds before the settings page could say anything, paid even by someone using Docker, since readiness checks every provider the platform supports. They now run eight at a time, and every denial is collected rather than only the first, so one message names everything to request from an administrator.
…the workspace one The probe only needs a runtime that can open a TCP connection, but it ran the workspace image: 1.32 GB, against the egress gateway's 329 MB. A cluster meeting either for the first time downloads it before the check can answer, so the check was four times slower than it needed to be on exactly the clusters where someone is most likely to run it — a new one, being set up. Managed egress already requires the gateway image, so nothing new is pulled in the default configuration. External egress keeps the workspace image, which is needed there regardless, and the reference is digest-validated either way. Verified live: enforced verdict unchanged, sixteen seconds against a cluster that already had both images.
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
2 participants
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
Two different problems with two different owners were reported identically as "network isolation could not be verified":
Observed live: a stale image reference pointing at a local registry that no longer runs produced a verdict reading as though something were wrong with the cluster's network. The actual fault was a setting the operator owns, and the message sent them looking in entirely the wrong place.
Change
An image pull failure (
ErrImagePull,ImagePullBackOff,InvalidImageName) now travels as its own flag on the probe result, so a surface can name the setting at fault instead of relaying a networking message.CreateContainerConfigErrorkeeps its existing treatment — it is a pod definition problem, not a registry one.Also: RBAC preflight concurrency
From the same session, unrelated to the above.
Readiness ran 26
kubectl auth can-iprobes one after another, each a process spawn and an API round trip, measured at 221 ms apiece — about six seconds before the settings page could display anything. That cost was paid even by someone using Docker, since readiness checks every provider the platform supports.They now run eight at a time, and every denial is collected rather than only the first, so a single message names everything to request from a cluster administrator.
Measured on the same cluster: full Kubernetes validation 6.3 s → 3.9 s, with the remainder being the namespace, DNS and image checks rather than the permission loop.