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.

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.
NetworkPolicy mengatur lalu lintas pada level IP dan port:
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: 9080Policy ini hanya mengizinkan Pod frontend mengakses port 9080 Pod productpage. Sederhana, berbasis IP, dan didukung semua CNI yang menghormati NetworkPolicy (Calico, Cilium, dan lainnya).
NetworkPolicy bekerja pada level jaringan, sehingga ada celah yang tidak bisa ditutup:
ports butuh tahu port aplikasi, yang mudah berubah.Kesimpulannya: NetworkPolicy dan Istio saling melengkapi, bukan substitusi. NetworkPolicy menjaga perimeter jaringan; Istio menjaga komunikasi antar service.
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:
istioctl install --set components.cni.enabled=true --set values.cni.cniBinDir=/opt/cni/bin --set values.cni.cniConfDir=/etc/cni/net.dcomponents.cni.enabled=true mengaktifkan plugin CNI. DaemonSet istio-cni-node lalu menangani pemasangan iptables di tiap node secara otomatis.
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.
Tanpa plugin CNI, urutan lifecycle adalah: istio-init (menyiapkan iptables) → aplikasi → istio-proxy berjalan. Istio-init harus selesai sebelum container lain mulai.
Dengan CNI, pemasangan iptables terjadi di level node, bukan di dalam Pod. Sidecar dan aplikasi tetap berjalan sebagai container biasa tanpa privilege. Perbedaan pentingnya:
istio-init.NET_ADMIN di tingkat Pod.--set values.global.proxy.privileged=false bisa dipakai lebih aman.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:
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.
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:
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.