A VPN Sidecar Needs a Start Rule and a Fail Rule

A pod starts the tunnel container before the application and the first requests succeed, which is exactly the case that hides the problem. Ordering fixes one race and says nothing about the traffic the application starts four hours later, after the tunnel has failed. Those are two separate decisions. Only one of them usually gets designed.

Ordering Only Gates the First Request

Kubernetes supports a sidecar lifecycle built from restartable init containers. Within that model a startup probe can hold back the next initialisation step until the tunnel reports ready. That is a genuine improvement, and it is worth using deliberately rather than by adding a sleep to an entrypoint script. The gate is only as good as the condition it tests.

Outside that model, the ordering semantics belong to whatever runtime or dependency system you are using, and they need not match. A deployment copied from a different platform may appear to wait for the tunnel because the application happens to start slowly. That is not the same guarantee, and it fails under load.

State what the gate observes: a process exists, an interface exists, a handshake completed. Each of those is a weaker claim than "the data path to the destinations this pod needs works".

Enforce the Data Path Instead of Assuming It

A probe is a check at one moment and a firewall is a property that holds between moments. If the requirement is that application traffic never leaves outside the tunnel, it has to be expressed in the shared network namespace as an accept-or-drop rule. Container start order cannot carry that requirement. Only a rule can.

Containers in one pod share that namespace, so the enforcement point is the namespace itself. Whatever you write has to leave the tunnel's own outer connection available, because blocking it to protect the application cuts the path the application needs.

Decide the failure policy explicitly: should application traffic stop entirely when the tunnel is unhealthy, or continue and be marked as unprotected? Both are defensible, and neither is what you get by starting containers in a particular order.

Test the Traffic You Did Not Mention

Take a new request during a controlled tunnel failure and see whether it leaves. Then repeat the check for the paths an exit-address test never touches: DNS resolution inside the cluster, IPv6 destinations, and services reached through cluster-internal addresses rather than the public internet. Those are the paths that quietly keep working after the tunnel dies.

An exit-address page proves that one request went where you expected at that moment. It cannot inventory the other paths, and the gap between what you tested and what the pod can reach is where the interesting failures live.

Repeat the test after a sidecar restart rather than only after a clean start. A restarted tunnel container can leave the namespace with routes and policy in an intermediate state.

Write the Deployment Record

Three facts belong in the deployment notes: the readiness test and what it observes, the recovery action when that test fails, and the enforcement rule that governs egress. The sidecar container documentation covers the lifecycle mechanics and leaves that policy decision to you. That division is correct, and it is also why the policy is usually missing.

A health check mistaken for protection is the most expensive kind of green indicator, because it stops people asking questions. Naming it accurately in the documentation costs one sentence and prevents that.

Finally, test the recovery path once with the application running. A design that requires the pod to be recreated to restore egress is a decision, and it should be one you made rather than one you discovered.