Arsitektur Cilium eBPF, BGP Anycast & WireGuard: Panduan Teknis Jaringan Cloud-Native Skala Enterprise

Tuntutan throughput multi-gigabit (10G/40G/100G) dan latensi rendah pada lingkungan Kubernetes skala enterprise memperlihatkan batasan fundamental dari jaringan tradisional berbasis iptables maupun IPVS. Artikel ini membedah secara teknis arsitektur jaringan berbasis eBPF (Extended Berkeley Packet Filter) melalui Cilium, integrasi BGP Anycast untuk ingress load balancing terdistribusi, serta optimasi WireGuard untuk enkripsi mesh berkinerja tinggi.

Anatomi Jalur Paket: iptables vs Cilium eBPF Direct Server Return

Pada arsitektur Kubernetes konvensional yang menggunakan kube-proxy mode iptables, setiap paket TCP/UDP yang ditujukan ke sebuah ClusterIP atau NodePort harus melintasi rantai filter kernel secara sekuensial: PREROUTING (NAT) -> KUBE-SERVICES -> KUBE-SVC-XXX -> KUBE-SEP-XXX -> POSTROUTING (SNAT). Jumlah rule bertambah secara linier $\mathcal{O}(N)$ terhadap jumlah Service dan Endpoint, membebani cache CPU (L1/L2/L3 d-cache thrashing) dan menyebabkan latensi tail ($p99$) membengkak drastis saat skala mencapai ribuan pod.

Meskipun IPVS menurunkan kompleksitas pencarian menjadi $\mathcal{O}(1)$ via IPSET atau hash table, pendekatan ini tetap membutuhkan traversi stack jaringan lengkap Linux kernel—mulai dari alokasi sk_buff, Netfilter hooks, parsing socket layer, hingga interupsi ksoftirqd.

Sebaliknya, Cilium eBPF CNI menggantikan kube-proxy secara total dan mengintersep paket sebelum alokasi buffer kernel penuh terjadi. Berikut diagram alur datapath-nya:

[ NIC Hardware (Ring Buffer / RX Queue) ]
                   │
                   ▼
┌────────────────────────────────────────────────────────┐
│  XDP (eXpress Data Path) Driver Hook                   │
│  - BPF bytecode berjalan langsung di network driver     │
│  - Bypass SKB (sk_buff) allocation entirely            │
│  - Keputusan: XDP_DROP, XDP_TX, XDP_PASS, XDP_REDIRECT  │
└──────────────────┬─────────────────────────────────────┘
                   │ XDP_PASS (Alloc sk_buff)
                   ▼
┌────────────────────────────────────────────────────────┐
│  Linux TC (Traffic Control) Ingress Subsystem          │
│  - Cilium hook: cil_from_netdev                        │
│  - L4 Load Balancing: lookup BPF Map                   │
│  - DNAT langsung di header packet                      │
└──────────────────┬─────────────────────────────────────┘
                   │
         ┌─────────┴─────────┐
         ▼                   ▼
┌──────────────────┐┌────────────────────────────────────┐
│ Remote Node (DSR)││ Local Pod Endpoint (veth pair/XDP) │
│ Bypass SNAT back ││ Tail-call: cil_to_container        │
│ to Client direct ││ Zero-copy socket redirection       │
└──────────────────┘└────────────────────────────────────┘

Komponen Kunci Internal Cilium eBPF Engine

1. BPF Maps (Kernel-to-Userspace Key-Value Storage): Struktur seperti cilium_lb4_services_v2 menyimpan virtual IP service beserta port dan protokol, sementara cilium_ct4_global berfungsi sebagai Connection Tracking map menggunakan 64-bit connection tuple hashing untuk retensi sesi TCP/UDP stateful tanpa overhead nf_conntrack.
2. Socket Layer Enforcement (sock_ops, sk_msg): Untuk komunikasi antar-pod dalam satu node, Cilium melakukan attachment program BPF pada sock_ops (BPF_PROG_TYPE_SOCK_OPS). Ketika Pod A memanggil connect() ke Pod B, program eBPF menulis langsung dari transmit socket buffer Pod A ke receive socket buffer Pod B via bpf_msg_redirect_hash. Paket tidak pernah melintasi TCP/IP stack kernel maupun veth pair.
3. Direct Server Return (DSR) Mode: Node ingress me-rewrite IP tujuan ke Pod IP tanpa mengubah source IP (tanpa SNAT). Pod merespons paket langsung ke klien melewati default gateway, mengeliminasi bottleneck transfer return bandwidth pada node ingress.

BGP Anycast Control Plane: Arsitektur Multi-Homing

BGP Anycast adalah teknik routing di mana prefix IP yang sama (misalnya /32 untuk IPv4) di-advertise oleh beberapa node fisik dari lokasi berbeda ke upstream Top-of-Rack (ToR) switch via eBGP. Pendekatan ini sangat relevan untuk membangun arsitektur High-Availability tanpa bergantung pada single point of failure.

                  ┌──────────────────────┐
                  │    Internet / WAN    │
                  └──────────┬───────────┘
                             │
            ┌────────────────┴────────────────┐
            ▼                                 ▼
   ┌─────────────────┐               ┌─────────────────┐
   │  ToR Switch A   │◄──────iBGP───►│  ToR Switch B   │
   │   AS 65100      │               │   AS 65100      │
   └────────┬────────┘               └────────┬────────┘
            │  ▲                              │  ▲
       eBGP │  │ Anycast VIP             eBGP │  │ Anycast VIP
      ECMP  │  │ 198.51.100.1/32        ECMP  │  │ 198.51.100.1/32
            ▼  │                              ▼  │
      ┌────────┴────────┐               ┌─────┴───────────┐
      │  Edge Node 01   │               │  Edge Node 02   │
      │  AS 65001       │               │  AS 65002       │
      │  Cilium BGP CP  │               │  Cilium BGP CP  │
      │  IP: 10.0.1.11  │               │  IP: 10.0.1.12  │
      └─────────────────┘               └─────────────────┘

Upstream ToR switch melakukan load balancing layer-4 menggunakan 5-tuple hash: Hash(SrcIP, DstIP, SrcPort, DstPort, Protocol) mod N. Jika salah satu Edge Node mengalami kegagalan, router ToR mencabut route tersebut secara otomatis, dan trafik dialihkan ke node tersisa. Penggunaan Maglev Hashing pada Cilium eBPF L4LB memastikan bahwa penambahan atau pengurangan node backend tidak merusak routing koneksi yang masih aktif.

High-Throughput WireGuard Engine

WireGuard beroperasi di kernel space sebagai network device virtual. Dibandingkan IPsec, WireGuard menggunakan kriptografi modern berkecepatan tinggi: ChaCha20 untuk enkripsi simetris, Poly1305 untuk authentication tag, Curve25519 untuk ECDH key exchange, dan BLAKE2s untuk hashing.

Namun, pada jaringan 10Gbps+, terdapat beberapa tantangan teknis:

1. Single-Thread Crypto Queueing: Implementasi standar memproses packet queues menggunakan Workqueues kernel. Tanpa CPU pinning atau interrupt affinity yang optimal, core CPU akan mengalami lock contention.
2. MTU Mismatch & Fragmentation: WireGuard menambahkan overhead enkapsulasi 60 bytes (IPv4) atau 80 bytes (IPv6). Jika MTU fisik 1500 bytes dan interface WireGuard juga diatur 1500 bytes, kernel memecah paket menjadi fragmen IP. Reassembly di sisi remote menguras resource CPU. Perhitungan wajib: $MTU_{wg} = MTU_{phys} - 60 = 1440$ bytes.

Use-Case Arsitektur Nyata: Platform E-Commerce Skala Nasional

Bayangkan sebuah platform e-commerce nasional yang menangani lonjakan trafik saat flash sale. Menggunakan arsitektur konvensional, connection tracking akan kehabisan kapasitas dan memicu silent packet drops. Dengan menggabungkan Cilium eBPF, BGP Anycast, dan WireGuard, arsitektur dirancang sebagai berikut:

• Ingress Layer: Dua Edge Node menjalankan Cilium dengan BGP Control Plane meng-advertise VIP Anycast 198.51.100.1/32 ke ToR Switch. Trafik masuk terdistribusi via ECMP.
• Data Plane: Cilium beroperasi dalam mode DSR. Request dari klien di-DNAT langsung ke Pod backend tanpa SNAT, sehingga response kembali langsung ke klien tanpa membebani Edge Node dua kali.
• Mesh Security: Komunikasi antar-node dienkripsi menggunakan transparent WireGuard yang dikelola Cilium, mengeliminasi kebutuhan sidecar proxy tambahan.
• Resiliensi: Jika Edge Node 01 mati mendadak, BGP session timeout (Hold Time 9 detik) memicu pencabutan route di ToR Switch. Maglev hashing di level eBPF memastikan sesi TCP yang sudah ada di Edge Node 02 tidak ter-reset.

Konfigurasi Production-Ready

Berikut adalah chassis konfigurasi Helm untuk menerapkan arsitektur di atas pada klaster Kubernetes production. Simpan sebagai values-production.yaml:

cluster:
  name: k8s-enterprise-prod
  id: 1

kubeProxyReplacement: "true"
k8sServiceHost: "10.0.0.10"
k8sServicePort: 6443

bpf:
  masquerade: true
  tproxy: true
  mapDynamicSizeRatio: 0.005
  preallocateMaps: false
  clockSource: "ktime"

loadBalancer:
  mode: "dsr"
  algorithm: "maglev"
  maglev:
    tableSize: 16381
    hashSeed: "supersecretmaglevseedk8sprod2026"
  acceleration: "native"

devices:
  - "eth0"
  - "enp+"

socketLB:
  enabled: true
  hostNamespaceOnly: false

encryption:
  enabled: true
  type: wireguard
  wireguard:
    persistentKeepalive: "25s"

tunnelProtocol: ""
routingMode: "native"
autoDirectNodeRoutes: true
ipv4NativeRoutingCIDR: "10.244.0.0/16"

bgpControlPlane:
  enabled: true

Untuk kebijakan peering BGP agar VIP ter-advertise ke ToR Switch, terapkan CRD berikut:

apiVersion: cilium.io/v2alpha1
kind: CiliumBGPPeeringPolicy
metadata:
  name: rack-tor-bgp-peering
spec:
  nodeSelectors:
    - matchLabels:
        topology.kubernetes.io/role: edge-worker
  virtualRouters:
    - localASN: 65001
      exportPodCIDR: false
      neighbors:
        - peerASN: 65100
          peerAddress: "10.0.1.1/32"
          peerPort: 179
          holdTimeSeconds: 9
          keepaliveTimeSeconds: 3
          gracefulRestart:
            enabled: true
            restartTimeSeconds: 120
      serviceSelector:
        matchLabels:
          bgp-advertise: "true"

Sementara itu, parameter kernel Linux wajib di-tuning untuk mendukung throughput tinggi. Terapkan via sysctl.d:

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.netdev_max_backlog = 500000
net.core.bpf_jit_enable = 1
net.core.bpf_jit_harden = 0
net.core.bpf_jit_limit = 1073741824
net.bridge.bridge-nf-call-iptables = 0
net.ipv4.conf.all.rp_filter = 0
vm.max_map_count = 2621440

Troubleshooting: eBPF Map Exhaustion

Salah satu insiden paling umum pada skala besar adalah exhaustion pada tabel Connection Tracking (cilium_ct4_global). Secara default, tabel ini hanya menampung 262.144 koneksi simultan. Saat active TCP flows melebihi batas ini, fungsi eBPF ct_create4() mengembalikan error -ENOSPC dan kernel mengeksekusi TC_ACT_SHOT—paket dibuang tanpa log error di level aplikasi.

Metrik dapat diperiksa melalui perintah berikut:

cilium-dbg metrics list | grep drop_count
# Output indikasi masalah:
# cilium_drop_count_total{reason="CT: Map insertion failed"} 481920

Mitigasinya adalah memperbesar limit map melalui Helm values dan memperpendek timeout idle:

bpf:
  ctGlobalMaxEntries: 1048576
  ctTimeoutTCPFin: "10s"
  ctTimeoutTCPIdle: "600s"

Ringkasan Sintesis

Penggantian kube-proxy warisan dengan Cilium eBPF bukan sekadar pergantian alat, melainkan pergeseran paradigma pemrosesan paket dari user-space traversal menjadi kernel-level programmable datapath. Dikombinasikan dengan BGP Anycast untuk resiliensi routing dan WireGuard untuk enkripsi transparan berkinerja tinggi, arsitektur ini mampu menyentuh angka mendekati wire-speed (hingga ~96 Gbps pada pengujian 100G link), jauh melampaui batas maksimal arsitektur iptables konvensional yang tertahan di kisaran ~28 Gbps akibat bottleneck conntrack.

Seluruh alamat IP dan topologi jaringan yang digunakan dalam artikel ini merujuk pada ruang alamat dokumentasi sintetis sesuai standar RFC 5737 (198.51.100.0/24, 203.0.113.0/24) dan RFC 3849 untuk memastikan keamanan serta kepatuhan terhadap praktik terbaik infrastruktur.