← Problem Library
K8s L5 K8S 1417 · 13 min

A Cilium FQDN policy allows image pulls and blocks a later gRPC dependency

Bootstrap traffic works, yet the later workload uses a different DNS path that yields IPs outside the policy's learned set.

K8sPlatform ReliabilityLevel 5Pro13 min
Scenario

Init pulls and startup checks pass while steady-state service calls begin failing under the same FQDN policy.

What to check first
  • Identify the primary failure signal in the The Pod Asked DNS Through One Mouth at Startup and Through Another Once the Sidecar Took Over scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Compare bootstrap and runtime DNS paths before adding broad CIDRs or removing FQDN enforcement.

Questions worth viewing together
What should you verify first when A Cilium FQDN policy allows image pulls and blocks a later gRPC dependency appears?

Community-field Kubernetes problem inspired by Cilium discussions where bootstrap DNS learning differed from steady-state resolver behavior. FQDN policies can diverge when different stages of the pod lifecycle query through different resolvers and get different answers.

What usually causes A Cilium FQDN policy allows image pulls and blocks a later gRPC dependency in production?

Teams often blame gRPC retries when the allowed IP set was learned from an earlier resolver path only.

What should you document after resolving A Cilium FQDN policy allows image pulls and blocks a later gRPC dependency?

Clusters with node-local DNS or sidecar resolver changes should validate FQDN policy behavior across startup and steady state.