So‘nggi yarim yil davomida VMware’dan ketish haqidagi deyarli har bir suhbat bitta ssenariy bo‘yicha o‘tadi. Bir soat virtual mashinalarni muhokama qilamiz: qayerga ko‘chirish, nechta tugun, nima bilan himoya qilish. Oxirida esa ishlab chiqish jamoasidan kimdir so‘raydi: «Kuber bilan nima bo‘ladi?» Va buyurtmachida allaqachon ikkinchi qavat borligi ma’lum bo‘ladi — vSphere virtual mashinalaridagi Kubernetes, ba’zan Tanzu, ba’zan turli jamoalar turli yillarda yig‘gan bir nechta vanil klasterlar.
Birinchi qavat — virtuallashtirish, ikkinchisi — uning ustidagi konteyner platformasi. Ikkinchisini eng oxirida eslashadi, holbuki u har qanday holatda ham ko‘chishi kerak. 09-sonda biz virtual mashinalarni qayerga olib ketishni ko‘rib chiqqan edik. Bu yerda — ularning ustiga nima qurish, qavatlarning qaysi birikmalari ishlaydi va yillar sarflangan avtomatlashtirish nega vSphere bilan birga yo‘qolmasligi haqida.
Bog‘liqliklar
vSphere bilan birga nima ketadi
Virtual mashinalardagi Kubernetes oson ko‘chadi. Uning hech kim eslamaydigan platformaga bog‘liqliklari qiyin ko‘chadi.
Tanzu bilan hammasi aniq. Alohida TKG Standalone liniyasi 2.5.x versiyasida tugadi, VKS esa faqat vSphere ichidagi Supervisor ustida ishlaydi. vSphere ketadi — Tanzu ham ketadi, o‘rniga boshqasini tanlash kerak.
Vanil Kubernetes bilan qiziqroq. Klasterning o‘ziga gipervizorning farqi yo‘q, ammo yillar davomida uning atrofida vSphere’ga mahkam bog‘langan atrof-muhit vositalari to‘planadi: vSphere CSI drayveri, bulut provayderi, NSX yoki vCenter bilan integratsiyalangan tashqi ADC’dagi balanslagich, tugun shablonlari va ularni yaratadigan avtomatlashtirish. Persistent tomlar esa boshqa platformada ma’lumotlarni ko‘chirmasdan ochilmaydigan formatda yotadi.
Buyurtmachidan bog‘liqliklarni eslashni so‘raganimizda, ro‘yxat deyarli har doim haqiqiysidan qisqaroq bo‘ladi. CSI haqida hamma eslaydi, balanslagich haqida — yarmi, tomlar haqida — bir-ikki kishi. Shuning uchun ikkinchi qavat migratsiyasining birinchi qadami — platforma tanlash emas, balki bog‘liqliklarni inventarizatsiya qilish. Busiz ko‘chish muddatlari doim optimistik bo‘ladi.
Arxitekturalar
Ikkinchi qavatni qurishning beshta usuli
Birinchi va ikkinchi qavatning ishchi birikmalari beshtadan kam emas. Quyida — loyihalarda eng ko‘p uchraydiganlari.
Ishchi birikmalar beshtadan kam emas. Ikkala qavatda Nutanix: virtual mashinalar AHV’da, konteynerlar o‘sha AHV’dagi NKP’da. Ikkala qavatda Red Hat: OpenShift to‘g‘ridan-to‘g‘ri fizik serverlarda, virtual mashinalar uning ichida. Nutanix va Red Hat gibridi: infratuzilma va virtual mashinalar Nutanix’da, konteynerlar AHV virtual mashinalaridagi OpenShift’da. Ikkala qavatda SUSE: fizik serverlarda SUSE Virtualization va uning ustida Rancher. Va Nutanix va SUSE gibridi: Rancher boshqaruvi ostida AHV’dagi RKE2 klasterlari.
Birikmalar beshtadan ko‘p: Rancher’ga boshqa distributivlarning mavjud klasterlarini ulash, vanil Kubernetes’ni esa istalgan gipervizorda yig‘ish mumkin. Ammo bu beshtasi biz banklar va telekomda ko‘radigan loyihalarning ko‘pchiligini qamrab oladi, shuning uchun keyin ularni birma-bir ko‘rib chiqamiz.
Nutanix
Nutanix va NKP: ikkala qavat uchun bitta vendor
Kubernetes klasteri virtual mashinalar bilan bir xil konsoldan yaratiladi, qavatlar tutashuvi uchun esa bitta vendor javob beradi.
NKP Cluster API va upstream Kubernetes asosida qurilgan: tarmoq qatlami sifatida Cilium, AHV’da balanslash uchun MetalLB, har bir klasterda CSI drayveri va standart saqlash sinfi. 2.17-versiyadan boshlab NKP Prism Central’dagi Marketplace’dan joylashtiriladi — Kubernetes klasteri virtual mashinalar bilan bir xil konsoldan yaratiladi. Stateful yuklamalar uchun NKP katalogida ilova darajasida replikatsiya va tiklash imkoniyatiga ega NDK bor — o‘tgan sondagi o‘sha asinxron replikatsiya, faqat podlar va tomlar uchun.
Asosiy dalil — mas’uliyat chegarasi. Agar pod tomni olmasa, bu kimning muammosi ekanini aniqlash shart emas: CSI, saqlash va platforma bitta vendorda. Ikkinchi qavatni ikki-uch kishi kuzatib boradigan bank uchun bu har qanday funksiyalar ro‘yxatidan salmoqliroq.
Cheklov ham tushunarli: NKP’da sertifikatlangan operatorlar ekotizimi OpenShift’nikidan kichikroq. Agar amaliy dastur vendori mahsulotni OpenShift uchun operator sifatida yetkazib bersa, bu dalil bitta konsol qulayligidan ustun keladi.
Red Hat
To‘liq OpenShift
Virtual mashina Kubernetes obyektiga aylanadi. Ba’zi jamoalar uchun bu tabiiy, boshqalari uchun — kasbni almashtirish.
Bu yerda modelning o‘zi o‘zgaradi. OpenShift Virtualization’da virtual mashina manifest bilan tavsiflanadi, namespace’da yashaydi va podlar bilan bir xil RBAC va tarmoq siyosatlariga bo‘ysunadi. Kubernetes kategoriyalarida fikrlaydigan jamoa uchun bu tabiiy. vCenter tajribasiga ega administratorlar uchun esa — vositani yangilash emas, kasbni almashtirish.
Talab qat’iy: fizik serverlar, alohida uskunalar puli. Saqlash — tugunlar disklaridagi OpenShift Data Foundation yoki uning vendori CSI’si orqali tashqi massiv. Avvaliga faqat virtual mashinalar kerak bo‘lganlar uchun Red Hat’da OpenShift Virtualization Engine nashri bor — konteyner funksiyalarisiz, faqat bare metal’da, keyinchalik to‘liq nashrga o‘tish imkoniyati bilan. Ko‘pincha e’tibordan chetda qoladigan bir tafsilot: mehmon tizimlar uchun RHEL obunalari unga kirmaydi, ular alohida sotib olinadi.
Tashkilot butunlay Kubernetes’ga standartlashtirilganda va amaliy tizimlar operatorlar ko‘rinishida kelganda variant kuchli. Parkda hech kim qayta yozmaydigan Windows va Oracle’li yuzlab klassik mashinalar bo‘lganda — zaif.
Gibrid
Gibrid: pastda Nutanix, yuqorida OpenShift
Bank rejalaridagi eng ko‘p uchraydigan variant. Qavatlar orasidagi chegara to‘g‘ri o‘tkazilsa, ishlaydi.
Bu variant banklarning 2–3 yil oldinga mo‘ljallangan rejalarida eng ko‘p uchraydi. Virtual mashinalar vSphere’dan AHV’ga ko‘chadi, tarqoq vanil klasterlar esa o‘sha Nutanix’ning virtual mashinalaridagi OpenShift’ga yig‘iladi.
Qo‘llab-quvvatlash bilan hammasi joyida. AHV — Red Hat tomonidan sertifikatlangan gipervizor, RHEL va OpenShift unda to‘liq qo‘llab-quvvatlanadi. OpenShift 4.11’dan boshlab Nutanix’ga o‘rnatish avtomatlashtirilgan: o‘rnatuvchi mashinalarni Prism Central orqali o‘zi yaratadi. Podlarga tomlarni Nutanix CSI beradi — blokli tomlar Volumes orqali, umumiy fayl tomlari Files orqali.
Chegarani to‘g‘ri o‘tkazish muhim. Bu yerda OpenShift faqat konteynerlar uchun javob beradi, virtual mashinalar AHV’da yashaydi va Nutanix vositalari bilan himoyalanadi. Agar slaydda virtual mashinalar «ham Prism’da, ham OpenShift’da» chizilgan bo‘lsa, bu bitta rasmga yopishtirilgan ikki xil arxitektura.
Bu yerda OpenShift faqat konteynerlar uchun javob beradi, virtual mashinalar AHV’da yashaydi va Nutanix vositalari bilan himoyalanadi.
Gibrid uchun to‘lov — qo‘llab-quvvatlashning ikkita shartnomasi va oldindan ajratilgan mas’uliyat zonalari. Nutanix va Red Hat tandemi allaqachon yaxshi sinovdan o‘tgan, ikkala vendor muhandislari tutashuvni yaxshi bilishadi. Ammo agar buyurtmachida ikkala qavatni tushunadigan o‘z mutaxassisi bo‘lsa, murojaatlar tezroq hal qilinadi: u darhol ikkala tomondan diagnostika to‘playdi va muammo qaysi vendorning zonasiga tegishli bo‘lsa, o‘shanda murojaat ochadi.
SUSE
SUSE: butun stek yoki faqat Rancher
Red Hat’dagi o‘sha ayriliq: hammasini fizik serverlarda qurish yoki boshqa infratuzilma ustiga faqat boshqaruvni o‘rnatish.
To‘liq stek — 09-sonda biz ko‘rib chiqqan bare metal’dagi SUSE Virtualization: KubeVirt orqali virtual mashinalar, Longhorn taqsimlangan saqlash tizimi. Rancher uni boshqaruv obyekti sifatida ulaydi va uning mashinalarida RKE2 mehmon klasterlarini yaratadi, balanslagich va tomlarni esa ularga platformaning o‘zi beradi.
Ikkinchi yo‘l — Nutanix ustida faqat Rancher. Nutanix’da Rancher uchun tugunlar drayveri va interfeys kengaytmasi bor: Prism Central loyihasini, tarmoqni va tugunlar pullarini tanlaysiz, RKE2 yoki K3s klasteri uchun mashinalar esa AHV’da avtomatik yaratiladi. Nutanix CSI Rancher katalogidan hamkor chart sifatida o‘rnatiladi, tandem bo‘yicha Nutanix va SUSE’ning qo‘shma qo‘llanmasi bor.
OpenShift’li gibriddan bu roli bilan farq qiladi. Rancher talablar bo‘yicha yengilroq va o‘z ilova modelini tiqishtirmaydi. Klasterlar ko‘p bo‘lganda, ular turli kelib chiqishga ega bo‘lganda va ularni har birini qayta yig‘masdan yagona huquqlar, monitoring va siyosatlar tizimiga keltirish kerak bo‘lganda u yaxshi. Turli yillardagi beshta klasterdan iborat «hayvonot bog‘i»da Rancher ko‘pincha tartib sari birinchi qadamga aylanadi, distributiv esa keyin tanlanadi.
Atrof-muhit vositalari
Saqlash, tarmoq va kirish
vSphere’da sukut bo‘yicha hal qilingan, yangi platformada esa javob talab qiladigan uchta savol.
Persistent tomlar turli platformalarning CSI drayverlari orasida boricha ko‘chmaydi — ma’lumotlar zaxira nusxalash yoki ilova replikatsiyasi orqali ko‘chiriladi. Bu joriy etish tafsiloti emas, balki migratsiya rejasining alohida qatori.
vSphere’da ko‘pincha NSX bergan balanslagich yangi platformada — NKP’dagi MetalLB, SUSE Virtualization’ning o‘rnatilgan balanslagichi yoki tashqi ADC. Kiruvchi HTTP-trafikni darhol tekshirish kerak: 2026-yil martida Kubernetes hamjamiyati Ingress NGINX’ni — eng keng tarqalgan ingress-kontrollerni — qo‘llab-quvvatlashdan chiqardi, unga xavfsizlik tuzatishlari endi chiqmaydi. Agar siz baribir kirish konturini qayta qurayotgan bo‘lsangiz, darhol Gateway API’ga qarash mantiqan to‘g‘ri.
Kirish bilan oddiyroq: LDAP yoki OIDC orqali AD bilan integratsiya hammada bor, obrazlar reestri — NKP’da Harbor, OpenShift’da o‘rnatilgan, Rancher uchun alohida Harbor.
Himoya
Ikkinchi qavatni himoya qilish
Git’dagi manifestlar — bu ma’lumotlarni emas, konfiguratsiyani himoya qilish.
Ko‘pchilik manifestlar Git’da yotgani uchun klaster himoyalangan deb hisoblaydi. Git Deployment va Service’ni tiklaydi, ammo podda ishlagan ma’lumotlar bazasining tomi tarkibini tiklamaydi. etcd zaxira nusxasi ilovalar ma’lumotlarini emas, klaster holatini qaytaradi.
Haqiqiy himoya ham manifestlarni, ham tomlarni tushunadigan vositalarga quriladi: Velero va uning asosida qurilgan OpenShift’dagi OADP, Nutanix’da NDK, Commvault kabi korporativ tizimlar, ularda Kubernetes — o‘z litsenziyalashiga ega alohida yuklama turi. Keyin o‘tgan sondagi RPO, RTO va nusxalarni saqlash joyi haqidagi o‘sha suhbat, faqat himoya obyekti — mashina emas, tomlari bilan birga namespace.
Avtomatlashtirish
Dunyo VMware bilan tugamaydi
Terraform va Ansible’ga sarflangan yillar vSphere bilan birga yo‘qolmaydi.
Deyarli har bir uchrashuvda eshitadigan qo‘rquvimiz: Terraform modullari, Ansible pleybuklari va obraz shablonlariga yillar ketgan, hammasi vSphere uchun yozilgan va ko‘chishda tashlab yuboriladi.
Tashlab yuborilmaydi. Terraform istalgan holatni tavsiflaydi, platforma bilan esa provayder ishlaydi. U vSphere’da ham, Nutanix’da ham bor — rasmiy, Nutanix’ning o‘zidan. SUSE Virtualization’ning versiyalari platforma bilan hamqadam boradigan o‘z provayderi bor, Rancher rancher2 provayderi orqali boshqariladi. OpenShift Virtualization virtual mashinalari — bu manifestlar, va Terraform ularni Kubernetes provayderi orqali yaratadi.
Yadrolar, disklar, tarmoq va cloud-init bilan mashina yaratadigan modul resurs tavsifi va provayder blokida o‘zgaradi. Mantiq, o‘zgaruvchilar, pipeline va kelishuvlar qoladi. Bu qayta yozish emas, bir necha kunlik ish. Ansible bilan ham xuddi shunday — har bir platforma uchun kolleksiyalar bor. Argo CD va Flux esa klaster nimada turganini umuman sezmaydi.
Mantiq, o‘zgaruvchilar, pipeline va kelishuvlar qoladi. Bu qayta yozish emas, bir necha kunlik ish.
Nutanix’ni hozir avtomatlashtirishni boshlayotganlar uchun bir tafsilot: 2026-yilning to‘rtinchi choragiga rejalashtirilgan provayder relizida Nutanix API v0.8–v3 dagi eski resurslarni qo‘llab-quvvatlashdan chiqaradi. Darhol API v4 ustidagi v2 resurslariga yozing.
To‘g‘ri qurilgan avtomatlashtirish gipervizor almashinuvidan omon chiqadi. vCenter’dagi kliklarga qurilgani — omon chiqmaydi, lekin u holda u umuman bo‘lmagan.
Tekshirish ro‘yxati
Ikkinchi qavatni tanlashdan oldin nima so‘rash kerak
Platforma tanlovini afzallik emas, hisob-kitobga aylantiradigan o‘nta savol.
Yakun
Xulosa o‘rniga
Ikkinchi qavat kamdan-kam hollarda VMware’dan ketish sababiga aylanadi, ammo deyarli har doim kechikish sababiga aylanadi. Platformaga bog‘liqliklar ko‘z oldida emas, drayverlar va tomlarda yashiringan.
Ishchi variantlar beshtadan kam emas, umumiy holda ular orasida eng yaxshisi yo‘q. Ikkala qavat uchun bitta vendor — kamroq tutashuvlar. Ikkita vendor — ko‘proq tanlov erkinligi va mas’uliyat zonalarining aniq taqsimlanishi.
Agar siz vSphere’dan ketishni rejalashtirayotgan bo‘lsangiz va rejada Kubernetes haqida hozircha bitta qator bo‘lsa — keling, muhokama qilamiz. Bog‘liqliklarni inventarizatsiya qilishdan boshlaymiz: bu oylarni tejaydigan bir-ikki kunlik ish.