Mereka Bentuk Lab OpenStack dan Kubernetes: MAAS, Kolla-Ansible, RKE2 dan Rancher

Sebelum memasang apa-apa pada tiga server Dell dan satu mesin GPU, saya menulis dokumen reka bentuk. Bukan kerana saya suka dokumen, tetapi kerana setiap keputusan di sini (rangkaian, storan, pengagihan Kubernetes) mahal untuk diubah selepas server berjalan.

Catatan ini ialah versi dokumen itu yang telah dikemas, bersama apa yang akhirnya berubah apabila ia bertembung dengan perkakasan sebenar.

Sasaran: tiga server Dell R440 → MAAS (provisioning bare-metal melalui PXE dan IPMI) → OpenStack dengan Kolla-Ansible (container Docker, control dan compute pada semua node) → kluster Kubernetes di atas VM OpenStack, dengan satu mesin NVIDIA DGX Spark sebagai worker GPU. Pengurusan melalui Rancher.

1. Topologi

Spesifikasi DGX Spark seperti dalam nota saya (semak datasheet NVIDIA sebelum bergantung padanya): cip GB10 Grace Blackwell, memori bersepadu 128 GB, NVMe 4 TB, CPU Arm 20 teras, 10 GbE. Port ConnectX-7 200 Gbps ialah untuk menyambung dua unit DGX Spark sesama sendiri, bukan untuk LAN. Ini penting kerana ia bermakna uplink ke switch ialah port 10 GbE.

2. Kenapa RKE2, bukan k3s atau kubeadm

Ini keputusan yang paling lama saya fikirkan.

Jadual ini daripada nota saya yang merujuk dokumentasi RKE2 (docs.rke2.io). Dakwaan seperti pematuhan CIS dan pilihan FIPS patut disemak semula terhadap dokumentasi dan versi semasa sebelum anda bergantung padanya.

Kenapa RKE2 menang untuk saya:

• Hardened sejak awal. Pod Security Standard “restricted” ialah lalai, dan CIS lulus dengan usaha minimum. Untuk platform multi-tenant, ia bermakna penyewa tidak boleh keluar dari namespace mereka.
• Rapat dengan upstream. Apabila upgrade atau masalah berlaku, dokumentasi dan komuniti K8s upstream terus relevan.
• Static pod. Control plane boleh didebug dengan tooling standard (kubelet, containerd), bukan penyelia khas.
• Laluan sokongan enterprise jika ini menjadi production sebenar.

Pertukaran yang jujur:

• Lebih berat: sekitar 1 GB RAM atau lebih, berbanding sekitar 500 MB untuk k3s. VM server 4 vCPU / 8 GB mencukupi.
• PSS “restricted” bermakna workload lama perlu securityContext yang betul. Untuk multi-tenant ia ciri, bukan beban.
• Memerlukan systemd. Pengerasan SELinux hanya untuk keluarga RHEL, tetapi pengerasan CIS tetap berjalan di Ubuntu.

Memandangkan Rancher mengurus kedua-duanya sama sahaja, tiada kos tambahan untuk memilih yang lebih serius.

3. Platform pengurusan: Rancher

Rancher 2.x (edisi komuniti, percuma) dipilih kerana:

• UI pengurusan multi-kluster
• Multi-tenant: pengguna log masuk, mendapat project atau namespace sendiri, deploy pod, melihat log dan terminal. Itulah antara muka yang saya mahu untuk pengguna platform
• RBAC penuh (pengguna, kumpulan, role setiap project)
• Katalog aplikasi (Helm) dan monitoring terbina dalam
• Provisioning kluster RKE2 secara natif
• Server Rancher berjalan pada VM x86_64 (VM Dell), bukan pada GB10 yang arm64. Kluster downstream arm64 tetap boleh diurus

Alternatif yang saya bandingkan: KubeSphere (workspace dan project, multi-tenant kuat), Headlamp (dashboard ringan, kurang multi-tenant), Kubernetes Dashboard (asas), GPUStack (fokus penyajian model LLM, bukan pengurusan pod am), dan OpenShift (berat dan mahal untuk lab). Cadangan: Rancher, dengan GPUStack boleh ditambah kemudian di atas kluster yang sama.

4. Reka bentuk storan

Soalan yang saya tanya: pada 1 GbE, NFS atau iSCSI?

• Kedua-duanya pada 1 GbE memberi kelajuan hampir sama, sekitar 110 hingga 125 MB/s mengikut anggaran saya. Penghalangnya NIC, bukan protokol.
• NFS ialah peringkat fail dan menyokong RWX (banyak node menulis serentak). Sesuai untuk data pengguna.
• iSCSI ialah peringkat blok dan RWO (satu node sahaja), perlu sistem fail dan initiator. Lebih banyak setup dan kurang fleksibel untuk data kongsi.

Keputusan: NFS CSI (StorageClass dengan RWX) untuk data pengguna dan berat model kongsi. Jumbo frame MTU 9000 pada VLAN storan, kerana ia percuma.

Untuk “gabungkan storan”, dua pilihan:

Cadangan: dua peringkat. Longhorn untuk beban stateful dan data pantas, Synology NFS untuk data pengguna kongsi dan sandaran.

5. Pelan VLAN dan IP

Prinsip yang saya pegang: julat pod dan service tidak bertindih dengan rangkaian infra (10.10.x). Pertindihan CIDR ialah jenis bug yang kelihatan seperti masalah rangkaian misteri berbulan-bulan kemudian.

6. Saiz komponen

Spesifikasi Dell masih “belum disahkan” semasa dokumen ini ditulis. Kemudian disahkan: satu server ada 32 teras, dua lagi 64 teras, semuanya 187 GB RAM, dengan disk 1 TB di belakang PERC H330.

7. Fasa deployment

1. Fasa 0, infra: sahkan VLAN pada switch, NFS share, MTU 9000, DNS, dan kelayakan IPMI iDRAC.
2. Fasa 1, MAAS: pasang region dan rack controller, konfigurasi subnet dan DHCP, daftar iDRAC sebagai BMC, commission dan deploy Ubuntu 24.04 ke tiga Dell. Lihat Provision Server Bare-Metal dengan MAAS.
3. Fasa 2, Docker dan Kolla-Ansible: pasang Docker pada setiap Dell, buat venv Kolla-Ansible pada host penerapan.
4. Fasa 3, OpenStack: deploy dengan Kolla-Ansible (keystone, nova, neutron, glance, cinder, placement, mariadb, rabbitmq). Inventory: tiga node dengan semua peranan. Naik taraf ialah kolla-ansible upgrade.
5. Fasa 4, VM: imej Ubuntu cloud, flavor, lancarkan VM RKE2, VM biasa dan VM Rancher.
6. Fasa 5, Kubernetes: RKE2 dengan tiga server HA dan dua worker; sertakan DGX Spark; label dan taint GPU.
7. Fasa 6, storan: NFS CSI dan StorageClass; Longhorn; ujian PVC RWX.
8. Fasa 7, Rancher: deploy, import kluster, cipta project dan pengguna.
9. Fasa 8, GPU: NVIDIA toolkit dan device plugin; pod ujian.

8. Senarai semak pengesahan

• openstack compute service list: semua servis up
• kubectl get nodes: enam node Ready (3 server, 2 worker, GB10)
• rke2 etcd-snapshot save: sandaran berfungsi, dan latihan restore dibuat
• PVC Bound dan ujian tulis RWX (dua pod pada PV yang sama)
• Pod GPU: nvidia-smi dalam pod, dengan nodeSelector
• Rancher: pengguna log masuk dan deploy pod dalam project sendiri, tanpa disekat PSS

9. Latihan sebelum go-live

Daripada bahagian “kesediaan production” dalam dokumen:

1. Sandaran etcd: rke2 etcd-snapshot save berkala, dan latihan restore. Rancher Backup CRD untuk kluster penuh.
2. Latihan naik taraf: di staging dahulu; Rancher mengawal versi; rolling restart.
3. Kegagalan node: matikan satu server dan sahkan kuorum etcd bertahan (tiga server tahan satu mati).
4. GPU dan arm64: imej mesti multi-arch; uji device plugin pada DGX dahulu.
5. Gangguan storan: tahu laluan pemulihan untuk NFS dan Longhorn.
6. Multi-tenant: RBAC dan PSS bagi setiap project; uji bahawa pengguna tidak boleh keluar dari namespace.

Apa yang berubah apabila ia bertembung dengan realiti

Dokumen reka bentuk ialah hipotesis. Beberapa bahagian saya tidak ikut:

• OpenStack: versi awal dokumen merancang Charmed (Juju/LXD). Ia ditukar kepada Kolla-Ansible, kerana naik taraf dengan satu arahan lebih mudah diselenggara.
• Storan: pelan Synology NFS dan Longhorn tidak menjadi backend utama VM. OpenStack akhirnya menggunakan Ceph RBD untuk Glance, Cinder dan Nova. Ceph itu sendiri ditulis semula: dari container pada node compute ke pemasangan natif (lihat Bare-Metal Ceph as the RBD Backend).
• Rangkaian kluster: kluster RKE2 yang kemudian saya uji beban menggunakan CIDR pod lalai RKE2 (10.42.0.0/16), bukan 10.50.0.0/16 yang dirancang. Dan dalam binaan HA untuk Rancher, RKE2 mesti diletakkan pada rangkaian provider, kerana VXLAN bertindan dua kali (overlay tenant dan overlay flannel) tidak berfungsi (Eight Things That Broke).
• Soalan terbuka dalam dokumen yang saya tangguhkan: jenis port 10 GbE DGX Spark (SFP+ atau 10GBase-T), sama ada mahu memasang Longhorn, dan saluran release RKE2 (stable atau latest).

Nilai dokumen ini bukan kerana ia betul, tetapi kerana ia memberi saya sesuatu untuk dibantah dengan data. Setiap penyimpangan di atas dapat dijelaskan kerana ada keputusan asal untuk dibandingkan dengannya.