← Problem Library
K8s L6 K8S 1389 · 15 min

A service mesh egress gateway looks healthy and outbound TLS still fails

The gateway is updated, yet a subset of workloads still reject the path because their sidecars ship older trust material.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A mesh trust rotation succeeds in staging and later one production namespace alone cannot reach external TLS destinations through the egress gateway.

What to check first
  • Identify the primary failure signal in the The Gateway Learned the New Trust and One Namespace Stayed in the Old Epoch 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 sidecar image trust bundles before rotating the gateway again or bypassing TLS verification.

Questions worth viewing together
What should you verify first when A service mesh egress gateway looks healthy and outbound TLS still fails appears?

Community-field Kubernetes problem inspired by service mesh and Kubernetes discussions where one namespace kept an older trust bundle after egress gatew... Mesh trust rotations can fail asymmetrically when some namespaces pin older sidecar images.

What usually causes A service mesh egress gateway looks healthy and outbound TLS still fails in production?

Teams often blame gateway cert deployment when the caller sidecar still trusts the old root only.

What should you document after resolving A service mesh egress gateway looks healthy and outbound TLS still fails?

Trust rotations should include sidecar version and root bundle audits across every namespace, not just gateway pods.