Mengaktifkan Jaringan Virtual

Sebelum OVN diaktifkan, halaman Network > OVN tidak menampilkan apa pun: Vapor belum mengetahui di mana database OVN berada atau peran apa yang dijalankan host ini. Aktivasi menetapkan keduanya dan langsung berlaku tanpa perlu me-restart Vapor.

Buka Network > OVN dan jalankan wizard aktivasi. Pada host yang sudah diaktifkan, wizard yang sama tersedia sebagai Reconfigure.

---

Tempat Pengaturan Disimpan

Data aktivasi disimpan di dalam database milik Vapor sendiri, sehingga tetap bertahan setelah restart dan dapat diubah kapan saja. Tiga sumber dapat menyediakan alamat database, dan sumber pertama yang memiliki nilai akan diprioritaskan:

1. Environment variables — VAPOR_OVN_NB_DB dan VAPOR_OVN_SB_DB
2. Database Vapor — yang ditulis oleh wizard
3. vapor.conf — ovn_nb_db dan ovn_sb_db, berguna untuk pra-konfigurasi host sebelum siapa pun membuka antarmuka pengguna (UI)

Jika tidak ada yang disetel, kakas (tools) OVN akan kembali menggunakan socket lokal, yang hanya tepat pada host yang menjalankan database itu sendiri.

Kartu status menampilkan sumber mana yang sedang digunakan. Jika perubahan tampaknya tidak berpengaruh, periksa kartu status terlebih dahulu — variabel lingkungan yang disetel pada service akan menimpa apa pun yang disimpan oleh wizard.

---

Langkah-demi-Langkah Wizard

1. Mode

Pilih bentuk deployment. Tiga mode dijelaskan di bawah; perbedaannya sangat penting, jadi pelajari mode yang ingin Anda gunakan sebelum melanjutkan.

2. Discovery

Vapor memeriksa host dan menampilkan apa yang ditemukannya: program OVN dan OVS apa saja yang terpasang beserta versinya, service mana yang berjalan, system-id yang ada jika sudah dikonfigurasi, kandidat alamat tunnel beserta subnet masing-masing, dan — jika kubeconfig dapat dijangkau — apakah host ini adalah node Kubernetes dan apakah kube-ovn tersedia.

Discovery hanya membaca. Tidak ada yang diubah sampai Anda mencapai langkah penerapan (apply).

Satu entri dapat terlihat kontradiktif pada node Kubernetes: ovn-controller mungkin dilaporkan tidak terpasang tetapi pada saat yang sama berstatus berjalan. Hal ini wajar karena kube-ovn menjalankannya di dalam pod, bukan sebagai service host langsung.

3. Addresses and peers

Untuk deployment eksternal atau kube-ovn, di sinilah alamat northbound dan southbound dimasukkan. Untuk deployment Vapor-native, di sinilah Anda menentukan apakah host ini adalah central (menjalankan database) atau chassis (hypervisor yang terhubung ke central), dan untuk central, apakah memulai klaster baru atau bergabung dengan klaster yang sudah ada.

4. Local chassis

system-id, tipe enkapsulasi serta alamat tunnel, dan pemetaan bridge (bridge mappings) opsional.

Pilih alamat tunnel dari kandidat yang ditawarkan oleh tahap discovery, dan pilih alamat pada subnet yang dapat dijangkau oleh semua host lain dalam deployment. Chassis dengan alamat yang tidak dapat dijangkau oleh rekannya (peers) akan berhasil terdaftar tetapi tidak pernah dapat membentuk tunnel, yang terlihat seperti deployment berjalan normal tetapi lalu lintas antar-host terputus tanpa pesan kesalahan.

Bridge mapping hanya diperlukan jika Anda berniat memberikan jalur dari logical router ke jaringan fisik — lihat Perutean dan konektivitas eksternal.

5. Preflight

Vapor menjalankan serangkaian pemeriksaan dan menampilkan masing-masing hasil beserta alasannya. Status fail akan memblokir penerapan; status warning mengharuskan Anda menyetujuinya secara eksplisit.

Pemeriksaan	Arti
ovs_installed	ovs-vsctl tersedia. Tanpanya, pemasangan mesin virtual ke logical switch akan gagal saat mesin dinyalakan
ovn_tools_installed	ovn-nbctl dan ovn-sbctl tersedia, beserta versinya
nb_reachable / sb_reachable	Database merespons. Dilewati untuk Vapor-native central yang membuat databasenya sendiri
central_capable	Host ini memiliki unit systemd yang dibutuhkan oleh OVN central. ovn-ctl saja tidak cukup — file tersebut juga disertakan dalam paket host biasa
cluster_remote_reachable	Untuk central yang bergabung ke klaster, anggota yang akan dihubungi dapat dijangkau
encap_ip_valid	Alamat tunnel tersedia pada host ini
system_id_valid	System ID belum disetel atau sudah sesuai dengan yang dimaksudkan
no_stale_chassis	Tidak ada sisa pendaftaran chassis lama untuk host ini dengan ID yang berbeda
kube_ovn_external_vpc	kube-ovn dikonfigurasi untuk tidak menghapus objek yang tidak dikenalnya
kube_ovn_node_match	Host ini adalah node Kubernetes

6. Review and apply

Penerapan bersifat idempoten: menjalankannya kembali dengan konfigurasi yang sama akan melaporkan bahwa tidak ada yang perlu diubah. Jika suatu langkah gagal di tengah jalan, Vapor akan mengembalikan (rollback) apa yang diubahnya dan memberi tahu Anda apa yang dipulihkan, sehingga kegagalan aktivasi tidak membuat kondisi host lebih buruk dari sebelumnya.

---

Mode 1: Vapor-native

Vapor menjalankan database OVN sendiri. Ini adalah bentuk yang direkomendasikan untuk deployment yang belum menjalankan OVN, karena tidak ada sistem lain yang memiliki database tersebut dan tidak ada yang akan menghapus konfigurasi yang Anda buat.

Sebuah host bertindak sebagai central atau chassis:

• central menjalankan ovn-northd serta database northbound dan southbound, dan juga berfungsi sebagai chassis.
• chassis hanya menjalankan ovn-controller dan terhubung ke central.

Satu central adalah deployment lengkap yang berfungsi tanpa redundansi. Untuk ketersediaan tinggi (high availability), gunakan tiga atau lebih. Dua central lebih berisiko daripada satu: dua node tidak dapat membentuk kuorum mayoritas, sehingga kehilangan salah satu host akan menghentikan seluruh deployment.

Pembentukan klaster, token bergabung (join token), dan penambahan host dibahas dalam Klaster Vapor-native.

Mode 2: Existing external OVN

Sistem lain menjalankan ovn-central. Masukkan alamat northbound dan southbound miliknya; Vapor akan bergabung sebagai klien dan mengonfigurasi host ini sebagai chassis. Vapor tidak akan mencoba mengonfigurasi ulang central tersebut.

Ini adalah mode yang paling sederhana. Jika alamat merespons dan alamat tunnel sudah benar, tidak ada keputusan lain yang perlu diambil.

Mode 3: Existing kube-ovn cluster

Vapor berbagi database OVN milik CNI Kubernetes. Mode ini dapat berjalan, tetapi kube-ovn menganggap dirinya sebagai pemilik database tersebut, sehingga ada beberapa syarat ketat. Vapor memeriksa ketiga syarat ini selama tahap preflight.

kube-ovn harus diinstruksikan agar tidak mengumpulkan objek eksternal

kube-ovn merekonsiliasi OVN dengan resource Kubernetes dan menghapus apa pun yang tidak dapat diatribusikannya. Dengan pengaturan default, satu kali restart kube-ovn-controller akan menghapus setiap logical switch dan router yang dibuat oleh Vapor, dan pembersihan periodiknya akan menghapus port logical switch dalam dua siklus.

Setel --enable-external-vpc=true pada deployment kube-ovn-controller. Dengan flag tersebut, objek yang tidak membawa penanda milik kube-ovn akan dikecualikan sepenuhnya dari garbage collection.

Vapor membaca flag ini selama tahap discovery dan memberikan peringatan mencolok jika flag belum disetel. Jangan abaikan peringatan tersebut pada deployment penting Anda.

Mengaktifkan flag tersebut memiliki konsekuensi

Dengan --enable-external-vpc=true, kube-ovn membuat custom resource Vpc bertaraf klaster (cluster-scoped) untuk setiap logical router yang tidak dimilikinya, termasuk milik Vapor. Menghapus custom resource tersebut akan menghapus router di OVN.

Lindungi resource ini sebelum Anda menggunakannya:

• kecualikan resource Vpc dari proses pruning GitOps apa pun, dan
• pertimbangkan admission policy yang menolak penghapusan resource Vpc berlabel ovn.kubernetes.io/vpc_external=true untuk siapa pun kecuali service account milik kube-ovn sendiri.

Resource bertaraf klaster yang tidak dideklarasikan oleh siapa pun biasanya menjadi sasaran pembersihan oleh kakas otomasi.

Setiap hypervisor Vapor juga harus menjadi node Kubernetes

kube-ovn menghapus pendaftaran chassis apa pun yang tidak berkorespondensi dengan node Kubernetes, dan flag di atas tidak mengubah perilaku ini. Hypervisor yang bukan node akan kehilangan pendaftaran chassis-nya saat controller me-restart berikutnya, dan bersamanya seluruh tunnel akan hilang.

Preflight memperlakukan hal ini sebagai kegagalan mutlak (hard failure), bukan sekadar peringatan.

Catatan versi

Pengecualian di atas bergantung pada pemberian tag oleh kube-ovn pada objek miliknya sendiri, yang dilakukan sejak versi v1.15.0 ke atas. Pada klaster yang lebih lama, atau yang di-upgrade tanpa menjalankan migrasi penandaan, mengaktifkan flag ini juga dapat memengaruhi migrasi live KubeVirt yang menggunakan filter yang sama untuk menemukan port mesin virtual. Pastikan port yang ada membawa penanda vendor=kube-ovn sebelum mengaktifkannya.

---

Menonaktifkan (Deactivating)

Deactivate menghentikan ovn-controller host ini, menghapus pointer database-nya, dan menandainya sebagai tidak aktif. Tindakan ini tidak menghapus logical switch, router, ACL, atau apa pun dari database OVN, karena pada deployment bersama objek-objek tersebut milik seluruh klaster.

Pada host yang beban kerjanya sedang menggunakan OVN, penonaktifan akan memutus jaringan beban kerja tersebut. Perlakukan tindakan ini sebagai operasi pemeliharaan (maintenance).