A NetworkPolicy Takes Time to Reach the Pod

A successful NetworkPolicy create request says the object exists in Kubernetes. It does not say the network plugin has enforced it. The Kubernetes NetworkPolicy documentation describes a gap between creating a policy and the plugin handling it. During that gap, a newly created pod selected by the policy may start without the intended isolation. The documentation gives no deadline for this handoff and says the Kubernetes API cannot tell you when it has finished.

That distinction matters when a deployment creates a workload and its policy together. A manifest can be accepted and visible while the traffic rule is still catching up. The practical question is whether the pod can send or receive traffic before the plugin has applied the rule.

The gap after creation

NetworkPolicy enforcement belongs to the network plugin. A cluster needs a networking solution that supports NetworkPolicy. Without an implementing controller, creating the resource has no effect, even though the resource can exist in the API. The Kubernetes prerequisites make that requirement explicit.

For a conformant implementation, a new policy is handled eventually. If a selected pod is created first, it may initially run unprotected. Isolation arrives when the plugin finishes handling the policy. An operator therefore cannot use a successful kubectl apply response as proof that a new pod has been isolated.

There is also a different starting state. Once the plugin has handled a policy, newly created pods selected by it must be isolated before any container starts. That includes init containers, sidecars, and app containers, because the policy applies at pod level. This guarantee is about pods created after the plugin has handled the policy. It does not erase the earlier gap.

Isolation and access can arrive separately

Isolation does not guarantee that every intended connection is available at startup. Kubernetes says allow rules may arrive after isolation rules, or at the same time. A new pod can therefore start with no network connectivity while the allow rules catch up. That is a service availability problem even when the restrictive part of the policy is already working.

A policy also has two independent directions. Ingress controls connections into a pod. Egress controls connections out of it. By default, a pod is unrestricted in each direction until a policy selects it for that direction. For traffic between two pods, the source pod’s egress rules and the destination pod’s ingress rules both have to allow the connection. Policies that select the same pod add their allowed traffic together. These rules are laid out in the NetworkPolicy model.

These details matter during rollout tests. A blocked request may mean that the intended restriction works. It may also mean that an allow rule has not arrived, or that the other end of the connection blocks traffic. A successful request may mean the intended allow rule works. It may also occur during the initial unprotected interval. One observation cannot establish that the whole policy has taken effect.

Different pods can see different results

NetworkPolicy can be implemented across multiple nodes. Kubernetes warns that pods may briefly see different policy behavior when pods or policies change. Its example is a new pod that can reach one destination pod immediately while another destination pod becomes reachable later. The pod lifecycle section does not promise a cluster-wide instant of completion.

Existing connections add another limit to a simple test. If a policy change would block a connection that was already open, Kubernetes leaves it to the plugin implementation whether that connection is closed. Test a new connection when checking a new restriction. Keep the behavior of established sessions in mind when planning a policy change.

The Kubernetes tutorial demonstrates a useful pair of checks: a client without an allowed label times out, while a client with the label connects. Running both checks from the intended clients helps distinguish an accidental outage from an effective rule. Repeat checks when policy or workload labels change, and include destinations on different nodes where that topology matters.

Startup checks have a narrow job

Kubernetes recommends an init container when an app must reach a destination before its main container starts. The init container can wait for that destination. Init containers finish before app containers begin. A readiness probe can keep a pod out of matching Service endpoints until the application is ready, and it can check required backend services.

These checks help an app tolerate delayed allow rules. They do not prove that unwanted traffic is blocked. A successful connection to an allowed backend is evidence for that path alone. Isolation needs a separate negative test from a client that should be denied. Readiness governs Service routing, while the policy governs pod traffic. Treat each signal as evidence for its own purpose.

What to do

1. Confirm that the cluster’s network plugin implements NetworkPolicy before depending on a policy for isolation. Kubernetes requires plugin support.
2. Create baseline policies before starting the workloads they select. This reduces the chance that a new pod starts during the policy’s initial handoff, though the API provides no completion signal. Check the intended traffic paths before exposing sensitive workloads.
3. Test fresh connections that should be allowed and fresh connections that should be denied. Use the real pod and namespace labels, ports, and any paths across nodes that your workload uses. The Kubernetes tutorial shows the allowed and denied client pattern.
4. Make startup tolerant of temporarily missing access. Use an init container for a required destination before app startup, or a readiness probe to withhold Service traffic until the app can serve it. Neither replaces the denied-client test.
5. Repeat the checks after policy or label changes. Record which paths were tested and whether new connections behaved as intended. The API object alone cannot report that enforcement has finished.