OKE Networking Explained

Networking is the part of OKE that trips up the most teams, because Kubernetes networking and OCI networking meet here and you have to understand both. Get it right and pods, services and external traffic all flow cleanly with security you can reason about. Get it wrong and you face exhausted IP ranges, services that will not expose, and network policy that does not behave as expected. This article explains how OKE networking actually works, from how a pod gets its address up to how external traffic reaches it.

It is part of our OKE and containers series and builds on the cluster design in OKE cluster architecture.

The starting point: the VCN

Every OKE cluster runs inside an OCI virtual cloud network. The VCN provides the address space, the subnets, the routing and the security controls. OKE places different cluster components in different subnets: one for the Kubernetes API endpoint, one or more for the worker nodes, and one for the load balancers that expose services. Keeping these separate lets you apply different security rules to each, which matters because they have very different exposure profiles.

The big decision: pod networking model

OKE supports two ways for pods to get network addresses, and this is the single most consequential networking choice you make.

VCN native pod networking is the modern default for most production clusters because it makes every pod a real network citizen that you can secure and route to with the same tools you use for any other OCI resource. The trade off is IP consumption: every pod takes an address from the pod subnet, so that subnet must be sized generously. Running out of pod IPs stops new pods from scheduling, which is a sharp and avoidable failure. The flannel overlay model conserves IPs by hiding pods behind their nodes, which suits clusters with very large pod counts and limited address space, at the cost of some integration and policy capability.

Services: how pods become reachable

Pods come and go, so you never address them directly. Kubernetes services give a stable address in front of a set of pods. Three service types matter. ClusterIP exposes a service only inside the cluster, which is right for internal components. NodePort opens a port on every node, which is rarely the right choice on its own. LoadBalancer provisions an OCI load balancer and points it at the service, giving an external address. When you create a LoadBalancer service, OKE talks to OCI and stands up a real load balancer automatically, which is the integration that makes exposing applications on OKE feel native.

Ingress: many services behind one entry point

Provisioning a separate load balancer for every service gets expensive and unwieldy. An ingress controller solves this by sitting behind a single load balancer and routing incoming requests to different services based on the host name or the path. This is how most production clusters expose web traffic: one load balancer, one ingress controller, many applications routed by rules. The full treatment of exposing services, including load balancer configuration and ingress patterns, is in ingress and load balancing on OKE.

Network policy: controlling pod to pod traffic

By default, any pod in a cluster can talk to any other pod. That is rarely what you want. Network policy lets you define which pods may communicate, so a compromised pod cannot freely reach the rest of the cluster. With VCN native pod networking, you get fuller network policy capability because pods are real VCN citizens. Defining policy that allows only the traffic each workload needs, and denying the rest, is a core part of cluster security, covered alongside the other layers in OKE security best practices.

Connecting to the rest of OCI and beyond

Clusters rarely live in isolation. Workloads need to reach databases, object storage, other VCNs and sometimes on premises systems. OCI provides the connectivity: service gateways for reaching OCI services like object storage without traversing the internet, local and remote peering for connecting VCNs, and FastConnect or VPN for on premises links. Designing these connections so the cluster reaches what it needs over private paths, rather than the public internet, is both a performance and a security gain.

A networking checklist

Common networking failures and how to avoid them

Three failures recur. Pod IP exhaustion stops scheduling and is avoided by sizing the pod subnet for growth. Services that will not get an external address usually trace to load balancer subnet or security rule misconfiguration, so check those first. And network policy that does not behave as expected often comes from the overlay model's limitations, which is one more reason VCN native is the production default. None of these are mysterious once you know the model, which is the whole point of understanding networking before you depend on it.

Where networking fits

Networking is the connective tissue that ties an OKE cluster to your applications and your wider estate. The model you choose shapes security, scaling and integration for the life of the cluster, so it is worth getting right early. With the network designed, the remaining disciplines of scaling, security and delivery sit on top of it. Continue with ingress and load balancing on OKE and autoscaling OKE workloads.

The OCI networking solution and the OKE solution practices design and build cluster networking to this model on a fixed project fee.