Belajar Telecom Engineer - Cloud-Native Telecom (Telco Cloud)

#Pendahuluan

Setelah di episode 13 kita menguasai slicing dan QoS, ada pertanyaan infrastruktur yang menggantung sejak episode 5: di mana sesungguhnya AMF/SMF/UPF itu berjalan? Jawabannya mengubah wajah industri sepuluh tahun terakhir: bukan lagi di kotak hardware khusus vendor, melainkan di telco cloud — pusat data standar tempat fungsi jaringan hidup sebagai VM atau container.

Mengapa telecom engineer wajib paham topik ini? Karena migrasi NFV/telco cloud adalah proyek terbesar operator saat ini, dan profil engineer yang dicari persis seperti hasil series ini: paham telecom DAN cloud-native. Engineer core yang tidak bisa membaca kubectl akan kehilangan akses ke setengah jaringan yang ia kelola.

#Dari Monolit Hardware ke NFV

Dulu: tiap fungsi jaringan = appliance khusus. MME punya raknya sendiri, firewall punya raknya sendiri — mahal, lambat upgrade, terkunci vendor. Ide NFV (Network Functions Virtualization, dipelopori ETSI ISG 2012): jalankan fungsi jaringan sebagai software biasa di atas server commodity.

Arsitektur kerangka NFV ETSI:

Tiga komponen MANO yang sering tertukar: VIM mengelola infrastruktur (contoh nyata: OpenStack, Kubernetes), VNFM mengelola siklus hidup satu VNF (deploy/scale/heal), NFVO menyusun layanan end-to-end dari banyak VNF (NS = network service).

#VNF vs CNF

Dua gelombang implementasi:

Realita operator 2026: keduanya hidup berdampingan. Data plane berat (misal UPF throughput puluhan Gbps) kadang tetap VM dengan passthrough; control plane hampir selalu sudah CNF. Arah pastinya: cloud-native penuh.

#Kubernetes Sebagai Platform Telco

Kubernetes standar tidak langsung cocok untuk telecom — ada tuntutan khusus:

#Tantangan Data Plane

Fungsi jaringan telecom (terutama UPF) butuh throughput tinggi dan latency stabil. Solusi tipikal:

• SR-IOV / DPDK: bypass kernel untuk paket — NIC dibagi langsung ke pod, throughput Gbps-class.
• Multus CNI: pod telco butuh beberapa interface (S1/N3, N4, N6) → Multus melampirkan banyak net-attach.
• CPU pinning & hugepages: isolasi core untuk worker packet processing, memory besar untuk buffer.
• NUMA alignment: NIC dan CPU harus satu socket agar tak melintasi interconnect.

Manifest contoh UPF dengan resource khusus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: upf
spec:
  replicas: 1
  template:
    spec:
      nodeSelector:
        telco.node/upf: "true"        # hanya host data-plane khusus
      containers:
        - name: upf
          image: ghcr.io/example/open5gs-upf:v2.7
          securityContext:
            privileged: true          # akses DPDK/VF
          resources:
            requests:
              cpu: "8"
              memory: 16Gi
              hugepages-2Mi: 4Gi
            limits:
              cpu: "8"
              memory: 16Gi
              hugepages-2Mi: 4Gi

#Ketahanan Carrier-Grade

Operator mensyaratkan availability 99.999% — Kubernetes memberi fondasi, tapi engineer harus menyetel sisanya: anti-affinity antar replica (jangan satu host), PodDisruptionBudget, liveness/readiness probe benar, dan stateful storage (StatefulSet + PV) bagi NF berstate.

#Praktik: Deploy Network Function di Lab K8s

Kita deploy Open5GS (subset NF) ke Kubernetes lokal — microk8s/k3d cukup.

#Langkah 1 — Siapkan cluster dan namespace

kubectl create namespace telco-lab
kubectl config set-context --current --namespace=telco-lab

#Langkah 2 — Deploy via Helm chart

helm repo add open5gs https://gradiant.github.io/open5gs-charts
helm install mycore open5gs/open5gs \
  --set amf.enabled=true \
  --set nrf.enabled=true \
  --set smf.enabled=true \
  --set mongodb.enabled=true
kubectl get pods -w

Tunggu semua Running. Perhatikan betapa cepatnya dibanding provisioning appliance: dari nol ke core network dalam hitungan menit.

#Langkah 3 — Uji lifecycle ala telco

Simulasi insiden: matikan paksa pod SMF dan saksikan self-healing:

SMF_POD=$(kubectl get pods -o name | grep smf)
kubectl delete $SMF_POD
kubectl get pods -w        # pod baru muncul otomatis

Inilah inti janji telco cloud: resiliency via orchestration — failure ditangani sistem, bukan oleh teknisi yang bangun tengah malam.

#Langkah 4 — Skala horizontal

kubectl scale deployment/amf --replicas=2
kubectl get pods -o wide     # cek tersebar di node beda

Pola scaling semacam ini adalah mekanisme di balik slice enterprise dedicated (episode 13): instance tambahan dideploy di namespace/node pool terpisah secara on-demand.

#Edge Cloud dan Distribusi

Telco cloud tidak hanya di DC pusat. Pola distribusi umum:

Konsekuensi engineering: manajemen ribuan cluster edge → butuh GitOps fleet management (ArgoCD/Rancher) dan observability terpusat — topik lanjutan yang sangat diminati pasar kerja.

#Common Pitfalls

• Menyalin pola IT umum mentah-mentah: web app boleh restart bebas; NF signaling punya timer ketat (T3xxx). Restart acak bisa membuat UE mass-reattach — uji dampak sebelum set aggressive liveness probe.
• Mengabaikan jaringan underlay: performa CNF ditentukan infrastruktur jaringannya (MTU jumbo, MTU mismatch GTP, QoS fabric). Masalah aplikasi sering ternyata masalah underlay.
• Vendor lock-in versi baru: chart/image tanpa versioning rapi menyulitkan rollback; perlakukan manifest seperti kode produksi (git + tag).

#Penutup

Inti yang harus dibawa pulang:

• NFV memisahkan fungsi jaringan dari hardware; MANO (NFVO/VNFM/VIM) mengelola siklus hidupnya.
• Gelombang kedua: CNF di Kubernetes, dengan kebutuhan telco spesifik — SR-IOV/DPDK, Multus, CPU pinning, hugepages.
• HA carrier-grade di cloud-native adalah desain eksplisit: anti-affinity, PDB, probing yang hati-hati.
• Kalian sudah men-deploy, mematikan, dan me-scale network function di Kubernetes — pengalaman yang langsung relevan dengan proyek 5G SA operator mana pun.

Di episode 15 kita menyelesaikan sisi operasional: network automation telecom — NETCONF/YANG, Ansible, dan zero-touch provisioning untuk ribuan perangkat. Sampai jumpa!