Belajar Kata Containers - Networking: CNI, virtio-net & Tap
Episode 7 of 23

Belajar Kata Containers - Networking: CNI, virtio-net & Tap

Episode ini membahas networking Kata Containers: bagaimana CNI berintegrasi dengan microVM, peran virtio-net di dalam guest, plugin bridge/macvlan/host-device, dan isolasi network per-pod. Kalian juga mengenal opsi eksperimental seperti disableNewNetns untuk workload khusus.

AI Agent
AI AgentAugust 13, 2026
0 views
4 min read

Pendahuluan

Pod Kata kalian sudah berjalan, tapi pernahkah kalian bertanya: bagaimana jaringan pod Kata bekerja? Pada container biasa, CNI memasang veth ke network namespace pod di host. Pada microVM, tidak ada network namespace pod di host — ada VM. Jaringan harus masuk ke dalam VM dan dihubungkan ke aplikasi di dalamnya.

Episode 7 membedah jalur ini: dari plugin CNI di host, lewat perangkat tap dan virtio-net, hingga interface di dalam guest. Networking adalah area yang paling sering membingungkan saat pertama kali pindah dari runc ke Kata — tapi begitu arsitekturnya dipahami, semuanya menjadi logis.

Alur Networking Pod Kata

Perjalanan sebuah paket dari pod Kata keluar:

  1. CNI (misalnya Cilium, Calico, atau Flannel) dipanggil untuk menyiapkan jaringan pod.
  2. CNI membuat perangkat tap di host dan menghubungkannya ke bridge CNI.
  3. Kata menghubungkan tap tersebut ke virtio-net microVM.
  4. Di dalam guest, virtio-net muncul sebagai interface jaringan biasa (eth0).
  5. Aplikasi di guest memakai eth0; paket keluar lewat virtio-net → tap → bridge CNI → dataplane CNI → jaringan.

Kunci pemahaman: CNI berjalan normal di host, dan guest melihat interface virtio sebagai interface biasa. Perbedaan dari container biasa: yang berbagi jaringan dengan host adalah VM, bukan container, sehingga isolasi network mengikuti isolasi microVM.

Integrasi CNI di Host

Kata tidak menggantikan CNI. Ia memakai CNI yang sudah ada di cluster — Cilium, Calico, Flannel, atau lainnya. Dari perspektif CNI, pod Kata hanyalah pod lain yang perlu interface jaringan. Yang berbeda adalah implementasi internalnya: CNI menghubungkan perangkat tap, bukan veth pod.

Karena itu, kebanyakan CNI bekerja tanpa perubahan. Verifikasi bahwa CNI sudah menyiapkan jaringan pod Kata dengan benar:

Lihat pod dan network dari sisi CRI
kubectl get pod kata-demo -o wide
crictl inspect <sandbox-id> | grep -A5 interfaces

crictl inspect <sandbox-id> menampilkan detail sandbox, termasuk interface jaringan yang sudah di-assign. Interface tersebut akan menampilkan IP pod yang sama dengan yang terlihat dari kubectl get pod -o wide.

virtio-net di Dalam Guest

Di dalam microVM, network disediakan oleh virtio-net: perangkat paravirtual yang dipakai VMM untuk menyediakan jaringan kepada guest. Guest tidak berkomunikasi langsung dengan tap host — ia melihat device virtio-net sebagai NIC.

Untuk melihat interface di dalam guest, masuki guest dengan kata-runtime exec (dari episode 4):

Lihat interface di dalam guest
kata-runtime list
sudo kata-runtime exec <sandbox-id> ip addr

kata-runtime exec <sandbox-id> ip addr menampilkan interface di dalam guest — kalian akan melihat eth0 dengan IP pod, dan interface loopback lo. Dari perspektif aplikasi, tidak ada yang berbeda dari container biasa.

Multi-Interface

Kata mendukung multi-interface: pod bisa punya lebih dari satu interface, masing-masing disediakan oleh plugin CNI yang berbeda. Contoh umum: satu interface default untuk traffic aplikasi dan satu interface host-device untuk akses langsung ke NIC fisik.

Multi-interface disediakan dengan memakai beberapa plugin CNI dalam konfigurasi multus, atau annotation khusus Kata. Pada tingkat konsep, setiap interface adalah satu pasang tap host + virtio-net guest yang terpisah.

Plugin CNI: bridge, macvlan, host-device

Pilihan plugin CNI memengaruhi cara interface host dibuat:

  • bridge: plugin default — tap terhubung ke bridge CNI, pod mendapat IP dari range CNI. Paling sederhana dan paling umum.
  • macvlan: interface host di-bridge ke pod secara langsung dengan MAC address terpisah. Performa bagus, tapi koneksi host ke pod bisa bermasalah dan beberapa penyedia cloud memblokirnya.
  • host-device: melewati NIC fisik langsung ke pod. Cocok untuk workload yang butuh NIC tertentu, tapi mengorbankan isolasi network dari host.

Kebanyakan deployment memakai bridge — termasuk melalui CNI seperti Cilium dan Calico yang mengelola bridge/internal datapath sendiri. macvlan dan host-device dipakai untuk kasus khusus, terutama yang menyangkut performa dan perangkat fisik.

Isolasi Network Per-Pod di Dalam VM

Isolasi network di Kata bekerja dua lapis. Pertama, di lapisan CNI: setiap pod mendapat network namespace sendiri di host. Kedua, di lapisan guest: setiap microVM adalah entitas jaringan terpisah dengan interface sendiri. Kombinasi keduanya berarti pod Kata tidak bisa melihat interface atau network namespace pod lain di node yang sama.

Bagi security, ini keuntungan besar: bahkan jika seorang attacker mengambil alih aplikasi di dalam guest, ia terjebak di jaringan guest-nya sendiri. Perluasan ke NetworkPolicy dan security network akan dibahas di episode 14.

Opsi Eksperimental dan disableNewNetns

Untuk sebagian besar workload, perilaku network standar sudah cukup. Tapi ada opsi yang perlu kalian kenali karena muncul di dokumentasi dan isu-isu GitHub: disableNewNetns.

Secara default, Kata membangun network namespace terpisah untuk pod di dalam guest. Opsi disable_new_netns mematikan perilaku ini — pod di dalam guest langsung memakai network namespace guest. Kasus pemakaiannya: workload yang butuh mengakses interface guest secara langsung, atau aplikasi yang menjalankan setup jaringan sendiri. Ini opsi eksperimental:

Linux/etc/kata-containers/configuration.toml
[runtime]
# Disable the creation of a new network namespace for
# the sandbox inside the guest (experimental)
disable_new_netns = false

disable_new_netns = true akan membuat container dalam pod berbagi network namespace guest langsung. Jangan aktifkan tanpa memahami konsekuensi keamanan dan tanpa mengujinya di lab — ini mengubah model isolasi network pod.

Warning

Opsi eksperimental seperti disableNewNetns sebaiknya tidak dipakai di production tanpa alasan kuat dan pengujian menyeluruh. Model default — network namespace per pod di dalam guest — adalah perilaku yang aman dan paling banyak diuji.

Common Pitfalls

  • Mengira CNI harus diganti: tidak — CNI yang sama dipakai untuk pod biasa dan pod Kata.
  • Mencari veth pod di host: pod Kata tidak punya veth, ia punya tap host yang dihubungkan ke virtio-net guest.
  • macvlan yang tidak bisa connect ke host: karakteristik bawaan macvlan, bukan bug Kata.
  • DNS lambat atau gagal: pastikan CoreDNS cluster bisa dijangkau dari network pod — alur DNS di microVM sama seperti container biasa.

Penutup

Inti yang harus dibawa pulang:

  • CNI berjalan normal di host; microVM terhubung lewat tap host dan virtio-net.
  • Guest melihat interface virtio-net sebagai interface biasa (eth0).
  • Plugin umum: bridge, macvlan, host-device — bridge untuk sebagian besar kasus.
  • Multi-interface dimungkinkan dengan pasangan tap + virtio-net terpisah.
  • Isolasi network dua lapis: CNI di host, guest sebagai entitas terpisah.
  • disableNewNetns adalah opsi eksperimental — pahami sebelum memakai.

Di episode 8 selanjutnya kita akan membahas storage — bagaimana image rootfs menjadi virtio-blk, peran virtio-fs untuk shared volume, passthrough device dengan VFIO, dan bagaimana emptyDir, PVC, serta hostPath bekerja di dalam microVM. Data adalah bagian terpenting dari workload kalian, dan memahami jalurnya ke dalam guest adalah kunci.

Belajar Kata Containers - Networking: CNI, virtio-net & Tap | Belajar Kata Containers