OpenShift OVN-Kubernetes Network Policy Guide

OpenShift's default network provider, OVN-Kubernetes, implements pod networking, services, and NetworkPolicy on top of OVN. The practical difference from a CNI that only does connectivity is that policy enforcement is done in the OVN data path, so a policy can be evaluated exactly rather than emulated with iptables rules. This guide covers the policy model, the difference between NetworkPolicy and AdminNetworkPolicy, and the verification commands that tell you whether traffic is blocked by policy or by routing.

The pieces

• ClusterNetwork — the pod CIDR, configured at install time and not changeable afterwards without a rebuild.
• OVN logical switches and routers — each node and namespace maps to logical topology; policies are translated into ACLs on those objects.
• NetworkPolicy — namespace-scoped, additive, and namespace-isolated by default when the provider supports it.
• AdminNetworkPolicy — cluster-scoped, ordered, can override namespace policies; the right tool for platform-mandated rules.

oc get network.operator cluster -o yaml | yq '.spec.defaultNetwork'
oc get network.config cluster -o yaml | yq '.spec'
oc get pods -n openshift-ovn-kubernetes -o wide

Start with default deny, then allow

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend
      podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8443

A policy with podSelector: {} and no rules denies all selected traffic in the stated direction. Policies are additive: any matching allow rule opens a path, and there is no notion of deny-within-allow except through AdminNetworkPolicy precedence.

Egress with DNS in mind

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-dns-and-upstream
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-dns
    ports:
    - {protocol: UDP, port: 5353}
    - {protocol: TCP, port: 5353}
  - to:
    - ipBlock:
        cidr: 10.20.0.0/16
        except: ["10.20.99.0/24"]
    ports:
    - {protocol: TCP, port: 443}

Blocking egress without allowing DNS is the single most common cause of "the policy broke my app" tickets. In OpenShift, cluster DNS runs on port 5353 via the DNS operator's service, not only on 53.

Verifying behaviour

# Which policies apply to a namespace?
oc get networkpolicy -n payments
oc describe networkpolicy default-deny-ingress -n payments

# Test from a debug pod on the same node / different node
oc run nettest --image=registry.access.redhat.com/ubi9/ubi-minimal --restart=Never \
  -n frontend -- sleep 3600
oc exec -n frontend nettest -- curl -sk --max-time 3 https://payments-api.payments.svc:8443

# OVN-level view of ACLs and flows
oc exec -n openshift-ovn-kubernetes ds/ovnkube-node -- ovn-sbctl lflow-list | head
oc exec -n openshift-ovn-kubernetes ds/ovnkube-node -- ovn-nbctl acl-list

If curl times out identically from a pod in an allowed namespace and a pod in a denied namespace, the problem is not policy: check the service target port and endpoint readiness before touching policy again.

Operational notes

• Test the same flow from two nodes — datapath bugs and MTU/encapsulation problems surface only cross-node.
• Keep policy in Git with the workload manifests; orphaned policies after namespace deletion are invisible drift.
• Use AdminNetworkPolicy for rules that must hold regardless of team-managed namespace policies, and document its precedence explicitly.

Related reading: K3s lightweight Kubernetes cluster install, Kubernetes CNI comparison: Calico, Cilium and Flannel, and Helm charts for Kubernetes deployments.

原文链接：https://docs.openshift.com/container-platform/latest/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.html