OpenShift Networking & Storage

A Route is OpenShift's ingress object. It predates the Kubernetes Ingress API, and OpenShift supports both — an Ingress is silently converted into a Route by the ingress operator, which is worth knowing because the object you debug is the Route even when the object you created was an Ingress.

What a Route gives you that plain Ingress does not: per-route TLS policy, weighted backends for canary splits, and configuration knobs (timeouts, balance algorithm, rate limits) as annotations that the router actually honours.

The four TLS modes, and which one you want

passthrough cannot do path-based routing. The router never decrypts, so it cannot read the path — it routes on SNI alone. A passthrough Route with a path: set is a configuration that silently does not do what it says.

OVN-Kubernetes is the default CNI on modern OpenShift. Each node gets a slice of the cluster CIDR; pods get an address from their node's slice; traffic between nodes is encapsulated in Geneve over the node network.

Three consequences that matter operationally:

• MTU is not negotiable. Geneve adds ~100 bytes of header. If the node network MTU is 1500, the pod MTU must be ~1400. Get this wrong and small packets work perfectly while large ones vanish — which presents as "TLS handshakes fine, large responses hang", the single most misdiagnosed cluster networking fault there is.
• NetworkPolicy is enforced in OVS flows, not iptables. iptables -L on the node tells you nothing about why a pod was blocked.
• The cluster CIDR cannot be changed after install. Sizing it too small is permanent; the node subnet size caps pods per node.

A Service is a stable name and VIP; the real destination list is the EndpointSlice. An endpoint appears there only when the pod is Ready. So the single most common "the service returns 503" cause is not networking at all — it is a readiness probe failing, which silently empties the slice.

Cluster DNS is CoreDNS, and names resolve as <service>.<namespace>.svc.cluster.local. Short names work inside the same namespace through the search path — which is also why a pod resolving db in the wrong namespace gets a confusing answer rather than an error.

An empty cluster allows every pod to reach every other pod, in every namespace. NetworkPolicy is additive allow-listing with an unusual trigger: a pod is unrestricted until at least one policy selects it, and from that moment only traffic explicitly allowed by some policy reaches it.

That produces the classic self-inflicted outage. You add one policy allowing frontend → backend. The backend is now isolated, so its egress to the database — never mentioned in the policy — is unaffected (egress is a separate policyType) but the monitoring scrape from the openshift-monitoring namespace is now blocked, and your dashboards go blank without a single error.

A StorageClass is the policy: which provisioner, what parameters, what happens to the volume when the claim is deleted, and — critically — when the volume gets created.

On any cluster whose nodes span failure domains, WaitForFirstConsumer is the right default and Immediate is a latent scheduling bug.

Two other fields decide whether you can recover later, and neither can be changed on an existing volume: reclaimPolicy (Delete destroys the backend volume when the PVC goes; Retain keeps it) and allowVolumeExpansion (false means you can never grow it without a migration).

Access modes are a contract the driver enforces, not a lock Kubernetes applies:

• ReadWriteOnce (RWO) — mountable read-write by one node. Several pods on that same node can share it. This surprises people in both directions: they expect exclusivity and do not get it, or they expect to scale to 2 replicas and the second pod hangs in ContainerCreating because it landed elsewhere.
• ReadWriteOncePod (RWOP) — genuinely one pod. This is the one people usually meant.
• ReadWriteMany (RWX) — many nodes at once. Needs a filesystem that supports it (CephFS, NFS, Azure Files). Most block drivers cannot do it at all.
• ReadOnlyMany (ROX) — many nodes, read-only.

Why your Deployment rollout hangs on RWO

A Deployment with the default RollingUpdate strategy starts the new pod before terminating the old one. With an RWO volume and the new pod on a different node, the new pod cannot attach until the old one releases — and the old one will not terminate until the new one is ready. It deadlocks until the progress deadline expires.

CSI splits the work across sidecars, and each one fails in its own log. Knowing which is which turns a storage incident from an afternoon into ten minutes:

The pattern to internalise: provisioning and attaching are cluster-level, mounting is node-level. A FailedMount is a node problem — go to that node. A ProvisioningFailed is a backend problem — go to the controller and then to the storage system itself.

Expansion works if allowVolumeExpansion: true was on the StorageClass at creation time. Edit the PVC's requested size and the resizer grows the backend volume, then the filesystem — online, for most drivers. Some need a pod restart to finish the filesystem step, which shows as capacity updated on the PV but not inside the container.

Shrinking is not supported. Not by Kubernetes, not by any CSI driver. The only route is create-new, copy, swap.

reclaimPolicy is the one that ends careers. With Delete, removing a PVC destroys the backing volume immediately and irreversibly — including when the PVC is removed as a side effect of deleting a namespace or a Helm release. With Retain, the PV survives in Released state holding the data, and you can rebind it.