Belajar Istio - Network Policies & CNI Integration
Episode 13 of 23

Belajar Istio - Network Policies & CNI Integration

Episode 13 membandingkan Kubernetes NetworkPolicy dengan kebijakan Istio, membedah cara kerja Istio CNI plugin yang menggantikan init-container istio-init, dan implikasinya terhadap lifecycle sidecar serta capture traffic.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Sejauh ini kalian mengamankan komunikasi di level aplikasi: mTLS, JWT, dan otorisasi. Tapi ada satu lapisan yang lebih rendah — lapisan jaringan itu sendiri. Episode 13 ini membahas dua hal yang saling berkaitan: Kubernetes NetworkPolicy sebagai kontrol jaringan dasar, dan Istio CNI plugin yang mengubah cara traffic diarahkan ke sidecar.

Kubernetes NetworkPolicy dan Batasannya

Contoh NetworkPolicy

NetworkPolicy mengatur lalu lintas pada level IP dan port:

NetworkPolicy allow ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: productpage
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 9080

Policy ini hanya mengizinkan Pod frontend mengakses port 9080 Pod productpage. Sederhana, berbasis IP, dan didukung semua CNI yang menghormati NetworkPolicy (Calico, Cilium, dan lainnya).

Kenapa Tidak Cukup

NetworkPolicy bekerja pada level jaringan, sehingga ada celah yang tidak bisa ditutup:

  • Tidak memahami aplikasi: aturan ports butuh tahu port aplikasi, yang mudah berubah.
  • Tidak memahami identitas: berbasis IP/Pod label, bukan identitas workload atau JWT.
  • Tidak bisa mengatur retry, routing, atau mTLS — semua itu level service mesh.
  • Pod sidecar membuat alamat asal berubah: karena Envoy mem-forward traffic, alamat IP yang terlihat bisa berbeda dari Pod asli.

Kesimpulannya: NetworkPolicy dan Istio saling melengkapi, bukan substitusi. NetworkPolicy menjaga perimeter jaringan; Istio menjaga komunikasi antar service.

Istio CNI Plugin

Kenapa Istio Punya CNI

Tanpa CNI plugin, Istio memakai init-container istio-init untuk menaruh iptables yang mengarahkan traffic Pod ke sidecar. Masalahnya: init-container butuh kemampuan NET_ADMIN dan NET_RAW pada setiap Pod — risiko keamanan dan hambatan bagi cluster yang melarang kemampuan tersebut.

Istio CNI plugin memindahkan kerja ini ke daemonSet yang berjalan sebagai root di node. Ia memasang iptables pada namespace network Pod saat Pod dibuat, sehingga Pod tidak lagi butuh privilege tinggi:

Install Istio dengan CNI
istioctl install --set components.cni.enabled=true --set values.cni.cniBinDir=/opt/cni/bin --set values.cni.cniConfDir=/etc/cni/net.d

components.cni.enabled=true mengaktifkan plugin CNI. DaemonSet istio-cni-node lalu menangani pemasangan iptables di tiap node secara otomatis.

Cara Kerja

Alurnya: kubelet memanggil CNI plugin saat Pod dibuat; plugin istio-cni-node memasang aturan iptables untuk menangkap traffic Pod ke port 15001 sidecar; traffic aplikasi lalu diarahkan ke Envoy. Karena pemasangan terjadi di node, container aplikasi tidak perlu kemampuan network khusus.

Implikasi CNI terhadap Lifecycle Sidecar

Tanpa CNI

Tanpa plugin CNI, urutan lifecycle adalah: istio-init (menyiapkan iptables) → aplikasi → istio-proxy berjalan. Istio-init harus selesai sebelum container lain mulai.

Dengan CNI

Dengan CNI, pemasangan iptables terjadi di level node, bukan di dalam Pod. Sidecar dan aplikasi tetap berjalan sebagai container biasa tanpa privilege. Perbedaan pentingnya:

  • Pod tidak lagi memakai init-container istio-init.
  • Tidak ada kemampuan NET_ADMIN di tingkat Pod.
  • Opsi --set values.global.proxy.privileged=false bisa dipakai lebih aman.
  • Restart daemonSet CNI bisa memengaruhi traffic mesh baru — pantau node secara keseluruhan.

Aturan iptables yang dipasang plugin tetap mengarahkan traffic Pod ke port 15001, tempat Envoy mendengarkan — hanya saja pemasangannya tidak lagi membutuhkan container khusus di dalam Pod.

Verifikasi bahwa CNI aktif dan Pod tidak memakai init-container:

Verifikasi CNI
kubectl get pods -n istio-system -l k8s-app=istio-cni-node
kubectl get pod productpage-abc123 -o jsonpath="{.spec.initContainers}"

Output kedua menampilkan array kosong jika CNI aktif — tidak ada istio-init. Sebagai gantinya, konfigurasi iptables dipasang oleh plugin di node.

Warning

Setelah mengaktifkan CNI, workload yang sudah ada harus di-restart agar mendapatkan konfigurasi baru. Perencanaan saat upgrade dan restart Pod menjadi bagian penting dari operasional harian.

Penutup

Episode 13 memperjelas peran dua lapisan network: NetworkPolicy mengontrol jaringan berbasis IP dan melengkapi, bukan menggantikan, kebijakan mesh; sedangkan Istio CNI plugin mengubah cara traffic diarahkan ke sidecar dengan memindahkan pemasangan iptables dari init-container ke daemonSet di node.

Inti yang harus dibawa pulang:

  • NetworkPolicy bekerja pada level IP dan port, tidak paham identitas aplikasi.
  • NetworkPolicy dan Istio melengkapi: perimeter jaringan dan komunikasi service.
  • init-container istio-init butuh NET_ADMIN; CNI plugin tidak.
  • Istio CNI memasang iptables di node lewat daemonSet istio-cni-node.
  • CNI menghapus init-container dan memudahkan kebijakan Pod non-privileged.
  • Workload lama harus di-restart setelah CNI aktif.
  • CNI membantu memenuhi persyaratan keamanan cluster yang ketat.

Di episode 14 selanjutnya kita akan mengukur dan mempercepat mesh: performance tuning dan scalability — scaling istiod, mengurangi xDS churn, ukuran resource sidecar, serta tuning connection pool dan jalur TCP versus HTTP.

Belajar Istio - Network Policies & CNI Integration | Belajar Istio