Belajar Cilium - Cilium Service Mesh & Gateway API

#Pendahuluan

Service mesh selama ini identik dengan sidecar: proxy yang disisipkan di setiap pod, memakan CPU dan memory tambahan. Cilium Service Mesh menawarkan arah berbeda: karena Cilium sudah memiliki dataplane eBPF di setiap node, ia bisa menyediakan fungsi service mesh — mTLS, routing L7, dan observability — tanpa perlu menyuntikkan sidecar ke setiap pod.

Episode 15 membedah arsitektur Cilium Service Mesh, mekanisme mTLS berbasis identity, implementasi Gateway API dengan HTTPRoute dan TLSRoute, serta langkah integrasi dengan cluster yang sudah memakai Cilium untuk networking. Setelah episode ini, kalian bisa membandingkannya secara adil dengan Istio — yang akan kita lakukan di episode 22.

Sebelum masuk detail, perjelas satu perbedaan yang sering membingungkan: Cilium Service Mesh bukan pengganti atau peniru Istio secara literal. Ia mengambil pendekatan yang berbeda — memanfaatkan dataplane yang sudah ada — sehingga kompromi antara fitur dan efisiensi pun berbeda. Perbandingan keduanya akan kita bahas lebih panjang di episode 22.

#Service Mesh Tanpa Sidecar

Konsep dasarnya sederhana: alih-alih proxy per pod, Cilium memakai L7 proxy (Envoy) yang berjalan sebagai daemonset per node. Semua pod di sebuah node berbagi proxy yang sama, dan dataplane eBPF mengarahkan traffic yang butuh pemrosesan L7 ke proxy tersebut. Pod tidak diubah, tidak ada init container tambahan, tidak ada pembengkakan resource per pod.

Aktifkan komponen service mesh saat install:

cilium install --set l7Proxy=true --set envoy.enabled=true

--set l7Proxy=true mengaktifkan proxy L7 dan envoy.enabled=true memastikan komponen Envoy per node terpasang. Dengan ini, fitur routing L7 dan mTLS sudah bisa dipakai tanpa menyuntikkan sidecar.

Pada versi terbaru, Cilium juga menguji ztunnel — jalur data layer yang lebih ringan untuk memproses traffic mesh tanpa overhead Envoy penuh. Detail implementasi ztunnel akan kita singgung lagi saat membahas rilis 1.19 dan 1.20 di episode 20.

Pola daemonset ini membawa konsekuensi penting: kapasitas proxy per node harus direncanakan, karena semua pod di node tersebut berbagi Envoy yang sama. Pod dengan traffic L7 yang sangat tinggi bisa memengaruhi tetangganya di node yang sama. Untuk workload dengan kebutuhan L7 ekstrem, pertimbangkan menempatkannya di node terpisah atau memberi lebih banyak resource pada Envoy.

#mTLS berbasis Identity

mTLS (mutual TLS) memastikan dua arah: klien memverifikasi server, dan server memverifikasi klien — semuanya dengan kriptografi. Di Cilium Service Mesh, identitas yang dipakai untuk sertifikat bukan CN atau service account, melainkan identity Cilium yang kita pelajari di episode 5. Artinya, kebijakan akses berbasis identity otomatis selaras dengan mekanisme mTLS.

Konsekuensinya menarik: jika sebuah pod mencuri IP pod lain sekalipun, mTLS tetap menolaknya karena identity-nya berbeda. Ini menutup salah satu kelemahan terbesar policy berbasis jaringan murni. Enkripsi antar service ditangani transparan — aplikasi tidak perlu tahu, mirip dengan transparent encryption di episode 14, tapi kali ini di level service.

Sertifikat yang dipakai untuk mTLS diterbitkan secara otomatis dan dirotasi oleh Cilium. Kalian tidak perlu menyuntikkan secret atau mengelola CA secara manual untuk kasus umum. Integrasi dengan trust domain ClusterMesh (episode 17) membuat sertifikat ini berlaku lintas cluster, sehingga mTLS dan policy tetap konsisten di seluruh mesh.

#Gateway API: HTTPRoute dan TLSRoute

Gateway API yang kita sentuh di episode 12 menjadi fondasi routing service mesh Cilium. HTTPRoute mengatur routing berbasis path dan header, sedangkan TLSRoute menangani terminasi passthrough TLS. Contoh route yang memisahkan traffic berdasarkan path:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-api
spec:
  parentRefs:
    - name: gw-utama
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /v2
      backendRefs:
        - name: api-v2
          port: 8080

path: {type: PathPrefix, value: /v1} mencocokkan request dengan prefix /v1 dan meneruskannya ke backend api-v1. Ini contoh routing L7 yang dieksekusi oleh proxy Cilium di jalur masuk cluster — tidak perlu rewrite ingress terpisah.

Selain HTTPRoute dan TLSRoute, Gateway API juga mendukung GRPCRoute untuk routing berbasis gRPC. Kalian bisa memilih tipe route yang sesuai dengan protokol aplikasi: HTTPRoute untuk REST, GRPCRoute untuk gRPC, dan TCPRoute untuk L4. Pilihan tipe route ini menentukan cara Cilium memproses dan merutekan traffic di gateway.

#Integrasi dengan Cluster Eksisting

Cilium Service Mesh tidak memaksa kalian memilih semua atau tidak sama sekali. Karena service mesh berdiri di atas dataplane yang sudah ada, kalian bisa mengadopsinya bertahap:

1. Pastikan Cilium networking sudah stabil (episode 3-4).
2. Aktifkan L7 proxy dan Envoy, lalu jalankan cilium connectivity test.
3. Terapkan HTTPRoute atau policy L7 untuk satu service pilot.
4. Amati dampak performa dengan Hubble sebelum memperluas cakupan.

Keunggulan adopsi bertahap ini penting: tidak ada "big bang" yang biasanya terjadi saat memakai service mesh berbasis sidecar, di mana semua pod harus di-restart sekaligus.

#Memverifikasi Komponen Mesh dan mTLS

Setelah mengaktifkan komponen service mesh, pastikan semuanya benar-benar berjalan sebelum menulis route pertama:

kubectl get ds -n kube-system cilium-envoy
cilium status | grep -i envoy
kubectl get pods -n kube-system -l k8s-app=cilium-envoy -o wide

kubectl get ds -n kube-system cilium-envoy menampilkan DaemonSet Envoy per node — jumlah pod harus sama dengan jumlah node. cilium status | grep -i envoy menampilkan status L7 proxy dari perspektif agent. Jika komponen ini belum siap, HTTPRoute dan mTLS tidak akan berfungsi meskipun sudah diterapkan.

Untuk membuktikan mTLS bekerja, amati traffic L7 yang terenkripsi:

hubble observe --type l7 --since 10m

hubble observe --type l7 --since 10m menampilkan flow L7 yang diproses proxy. Flow ini menampilkan method HTTP, path, dan status code — jendela langsung ke apa yang sebenarnya dilakukan aplikasi di layer tujuh, bukan sekadar IP dan port.

Sebelum mengaktifkan mTLS untuk seluruh mesh, jalankan eksperimen kecil: terapkan policy mTLS untuk satu pasang service, amati koneksi dari Hubble, lalu perluas. Pola pilot-service seperti ini sama dengan pola canary policy di episode 18 — mengurangi risiko perubahan global yang sulit di-rollback jika ternyata ada workload yang tidak kompatibel.

#Penutup

Inti yang harus dibawa pulang:

• Cilium Service Mesh bersifat sidecarless: proxy Envoy berjalan per node, bukan per pod.
• mTLS memakai identity Cilium, sehingga sinkron dengan policy berbasis label.
• l7Proxy dan envoy.enabled mengaktifkan komponen mesh.
• HTTPRoute dan TLSRoute adalah alat routing utama dari Gateway API.
• Adopsi bisa bertahap karena mesh berdiri di atas dataplane yang sudah ada.
• Ukur overhead dengan connectivity test sebelum memperluas cakupan.

Di episode 16 selanjutnya kita akan membahas runtime security dengan Tetragon — keamanan berbasis eBPF untuk monitoring eksekusi proses, akses file, dan deteksi perilaku mencurigakan. Kalian akan menginstall Tetragon, menulis TracingPolicy, dan menghubungkannya dengan Cilium untuk security posture yang menyeluruh.