Kubernetes for Telecom Engineers: Concepts You Actually Need

If you came up through telecom doing VNFs on OpenStack, the move to Kubernetes can feel like a sideways step. It is not. K8s is a different operating model, and the parts that matter for a 5G core are not the parts a typical web shop cares about.

This is the subset you actually need.

The Pod is not a VM

A Pod is a group of containers that share a network namespace and storage volumes. For a 5G NF, the typical pattern is:

• One main container running the NF process (AMF, SMF, UPF control plane, etc.)
• A sidecar for metrics export or service mesh proxy
• Optional init containers for config rendering or dependency checks

What trips engineers up: pods are ephemeral. Kill one and the scheduler creates another, possibly on a different node, with a different IP. A 5G NF that assumes stable IPs will break. This is why every NF must register with NRF on startup and re-register on restart — discovery is dynamic by design.

Deployments, StatefulSets, DaemonSets

For UPF in particular, DaemonSet plus node affinity is the dominant pattern in 2026. You want one UPF data plane pod per worker node bound to specific NICs, not the scheduler making placement decisions for you.

Services and why ClusterIP is not enough

A Kubernetes Service gives you a stable virtual IP and DNS name in front of a set of pods. For SBA traffic between NFs, ClusterIP works fine — AMF talks to SMF over smf.5gc.svc.cluster.local and kube-proxy handles load balancing.

Where it falls apart:

• N2 (gNB to AMF): SCTP, external clients (gNBs are outside the cluster). Needs LoadBalancer with SCTP support, or MetalLB in BGP mode.
• N3 (gNB to UPF): GTP-U over UDP, high throughput, low latency. You bypass kube-proxy entirely — the gNB hits the UPF NIC directly.
• N4 (SMF to UPF): PFCP over UDP. Internal but routed over a dedicated interface, not the cluster pod network.

Which is exactly why Multus exists.

Multus CNI: the reason telecom K8s is different

Vanilla Kubernetes assumes one network interface per pod. The 5G core needs several:

• eth0 — the cluster pod network (SBA traffic, control)
• net1 — N2 signaling VLAN
• net2 — N3 user plane (often SR-IOV with DPDK)
• net3 — N4 PFCP
• net4 — O&M / OAM

Multus is a meta-CNI. It calls the cluster's primary CNI (Calico, Cilium) for eth0, then attaches additional interfaces using other CNIs (SR-IOV CNI, MACVLAN, IPVLAN, host-device). You define NetworkAttachmentDefinition CRDs and reference them in pod annotations:

annotations:
  k8s.v1.cni.cncf.io/networks: |
    [
      {"name":"n3-sriov","interface":"net2"},
      {"name":"n4-macvlan","interface":"net3"}
    ]

Without Multus, you cannot cleanly separate the planes. With it, you can give the UPF a DPDK-bound SR-IOV VF for N3 and a normal kernel interface for N4, in the same pod.

SCTP: still a sore spot

N2 uses SCTP. Linux kernel supports it, but:

• kube-proxy in iptables mode handles SCTP poorly. Use IPVS mode or skip kube-proxy with Cilium.
• Most cloud LoadBalancers do not support SCTP. On-prem, MetalLB in L2 or BGP mode does.
• NodePort services with SCTP need the SCTPSupport feature gate (default-on since 1.20, but worth checking).

If you see AMF-to-gNB connectivity failing intermittently, SCTP multi-homing handling in your CNI is the first place to look.

Helm in one paragraph

Helm is the package manager. A chart is a directory of templated YAML plus a values.yaml. You render it with values, get manifests, apply them. For a 5G core you typically have an umbrella chart with sub-charts per NF family — see the next article in this series for chart structure.

The non-obvious part: Helm hooks (pre-install, post-install) are how you do dependency ordering at install time. NRF must be up before any other NF registers. A post-install hook that waits for NRF readiness before proceeding is standard.

Resources, QoS, and why you must set both requests and limits

Kubernetes has three QoS classes:

• Guaranteed — requests == limits. Pod is killed last under pressure.
• Burstable — requests < limits.
• BestEffort — neither set. Killed first.

For data plane NFs (UPF), always Guaranteed, with CPU manager policy static so you get exclusive cores. For control plane NFs, Burstable is acceptable but set realistic limits — an SMF that gets OOMKilled mid-PFCP-session is a bad day.

Pod Disruption Budgets are not optional

A PDB tells the scheduler the minimum number of replicas that must stay available during voluntary disruptions (node drains, upgrades). For an AMF set with 3 replicas, minAvailable: 2 means a node drain will not take you below 2 active AMFs.

Without PDBs, a routine cluster upgrade can drain all your AMFs at once. This has happened in production. Set them.

What to skip (for now)

• Service Mesh (Istio/Linkerd) — promising for SBA observability and mTLS, but real deployments are still rare in 2026 production cores. Most operators do mTLS at the NF level.
• HPA on data plane — autoscaling UPF on CPU is dangerous. Scale on session count, throughput, or do not autoscale at all.
• GitOps tooling — covered separately, but you do not need ArgoCD to learn K8s. Get kubectl apply muscle memory first.

A minimal mental model

1. NF process runs in a container, in a pod, scheduled to a node.
2. Pod gets a primary cluster interface from the CNI, plus extra interfaces from Multus for N2/N3/N4.
3. Other NFs find it via NRF (not via DNS for SBA discovery — NRF is the source of truth).
4. External traffic (gNBs) reaches it via LoadBalancer or directly to a node interface for data plane.
5. Helm packages the whole thing. ArgoCD or Flux applies it from Git.

Learn that mental model and most of the K8s noise filters out.

> The Kubernetes you need for telecom is mostly the same Kubernetes everyone else uses, with one big exception: the network. Get Multus right and 80% of the telecom-specific complexity disappears.

Kubernetes is not a 5G technology, but in 2026 you cannot deploy 5G without it — learn the network plumbing first and the rest follows.