In this article
After deny-all egress, an init container may fail to download artifacts and prevent the Pod from starting its main process. Inspect DNS and preparation dependencies. Kubelet image pulling uses another scope and does not establish connectivity inside the Pod.
After deny-all egress, an init container may fail to download artifacts and prevent the Pod from starting its main process. Inspect DNS and preparation dependencies. Kubelet image pulling uses another scope and does not establish connectivity inside the Pod.
Draw bootstrap dependencies
For each init step, record endpoint, protocol, port and purpose: resolver, artifact storage, configuration service or another confirmed dependency. Keep signed URLs and credentials out of reports. Include redirects and proxy paths, since the original name may lead elsewhere. “Allow the internet” does not explain the required dependency. Record the image registry separately as a node-side kubelet dependency rather than automatically adding it to the Pod allowlist.
Inspect policy application
Preserve Pod labels, namespace selectors and all applicable egress policies. Permissions combine according to Kubernetes semantics, not ordered firewall first-match rules. Confirm CNI support. Standard NetworkPolicy addresses IPs, ports and selectors; it is not a universal external-hostname allowlist. Platform extensions need separate documentation. External address changes can make static permissions fragile even while DNS resolution remains correct.
Examine successful pull and blocked init
Suppose the node has pulled the image and started its container, but init waits to connect to artifact.example.org. That is compatible with blocked Pod egress and is not disproved by image-pull success. Test DNS, then TCP and TLS to the required destination. Use a diagnostic environment with the same policy identity, not an arbitrary unlabeled debug Pod. Otherwise the test can bypass the relevant rule and falsely establish connectivity.
| Stage | Investigation scope |
|---|---|
| Image pulling | Node and kubelet/runtime |
| DNS lookup | Pod network and resolver |
| Artifact connection | Selected workload egress |
| Init completion | Verified download result |
Permit the minimal path
Add necessary DNS TCP/UDP rules and confirmed preparation destinations using platform-supported mechanisms. Do not remove deny-all entirely for one endpoint. Preserve idempotent retry behavior: an interrupted file may remain when init retries. Credentials belong to another boundary. TCP connection success does not establish TLS trust or storage read authorization. Give each stage its own evidence rather than collapsing them into “network works.”
Verify isolation remains
Start a new test Pod with the same labels and repeat bootstrap. Confirm an unrelated destination remains inaccessible under the policy. Retain dependency graph, selectors, CNI version and allowed/denied test results. Recovery includes a verified artifact and completed init, not merely an open port. Repeat after changing storage endpoints or redirect behavior, since the former allowlist may no longer describe the real path. This keeps bootstrap reliability tied to explicit dependencies without silently broadening workload access.
Related operational reading: hardware security; autoscaling gpu cold start.