در VCF 9.1، Kubernetes دیگر یک قابلیت جانبی برای چند تیم توسعه نیست. VMware vSphere Kubernetes Service 3.6 یا VKS 3.6 به Runtime داخلی پلتفرم برای ساخت و اداره کلاسترهای Kubernetes تبدیل شده است؛ Runtimeای که از همان زیرساخت vSphere استفاده میکند، اما Lifecycle، شبکه، سیستمعامل Nodeها و سیاستهای عملیاتی را با مدل اعلانی Kubernetes مدیریت میکند.
ارزش این نسخه صرفاً در پشتیبانی از Kubernetes 1.35 خلاصه نمیشود. VKS 3.6 در VCF 9.1 مقیاس Control Plane را افزایش میدهد، Provisioning و Upgrade را سریعتر میکند، Multi-Network را به قابلیت رسمی تبدیل میکند و برای Workloadهای سازمانی امکاناتی مانند TuneD Profile، AppArmor، Node Firewall، RHEL 9 و Image Baker را وارد مسیر پشتیبانیشده میکند. این مقاله VKS را از زاویه معماری و تصمیم عملیاتی بررسی میکند و با معرفی کوتاه Kubernetes در مقاله مقایسه VVF و VCF 9.1 همپوشانی ندارد.
VKS 3.6 چیست و در VCF 9.1 کجا قرار میگیرد؟
VKS نام سرویس Kubernetes یکپارچه با vSphere است. Supervisor لایه کنترل زیرساخت را فراهم میکند و VKS Service با استفاده از Cluster API و Providerهای vSphere، کلاسترهای Workload را ایجاد و اداره میکند. کاربر بهجای ساخت دستی VM، نصب Kubernetes و وصلهکردن ابزارهای Lifecycle، مشخصات مطلوب کلاستر را در قالب API یا YAML تعریف میکند؛ سرویس نیز Node، شبکه، Storage و نسخه Kubernetes را با همان Desired State هماهنگ نگه میدارد.
این مدل با Container Service در VCF Automation تفاوت دارد. Container Service برای اجرای مستقیم Container با پیچیدگی کمتر مناسب است؛ VKS زمانی انتخاب میشود که تیم به API کامل Kubernetes، Namespace، Operator، CNI، CSI، Helm و کنترل Lifecycle کلاستر نیاز دارد. رابطه این دو در مقاله VCF Automation 9.1 و Operations Orchestrator توضیح داده شده است.
معماری VKS 3.6 در VCF 9.1
Supervisor
Supervisor نقطه اتصال vSphere و Kubernetes است. Namespace، دسترسی، Quota، Storage Policy، شبکه و Supervisor Serviceها در این لایه تعریف میشوند. Supervisor جای Workload Cluster را نمیگیرد؛ وظیفهاش ارائه Control Plane زیرساخت و APIهایی است که ساخت و اداره کلاسترهای VKS را ممکن میکنند.
VKS Service و Cluster API
VKS Service منطق Lifecycle کلاستر را ارائه میدهد. Cluster API و CAPV وضعیت مطلوب را به VMهای Control Plane و Worker تبدیل میکنند. در VKS 3.6، ClusterClass نسخهدار مانند builtin-generic-v3.6.0 قالب قابلیتها و متغیرهای کلاستر را مشخص میکند. تغییر YAML میتواند Rolling Update ایجاد کند؛ بنابراین ویرایش Spec یک تغییر زیرساختی واقعی است، نه صرفاً تغییر فایل متنی.
VKR و Imageهای Node
نسخه Kubernetes و Image سیستمعامل با vSphere Kubernetes Release یا VKR به Lifecycle متصل میشود. Broadcom برای Photon OS و Ubuntu Image آماده ارائه میکند. VKS 3.6 همچنین Image Baker را بهصورت Plugin در VCF CLI عرضه کرده تا تیم بتواند Image سفارشی و تکرارپذیر بسازد. این روش نسبت به Snapshot گرفتن از یک VM زنده، قابل ممیزیتر و مناسبتر برای محیطهای محدود است.
شبکه، Load Balancer و Storage
VKS میتواند بر بستر NSX VPC یا vSphere Distributed Switch کار کند؛ قابلیتها و Objectهای شبکه در این دو Backend یکسان نیستند. برای انتشار Kubernetes API و Serviceها به Load Balancer نیاز است و Storage پایدار از طریق vSphere CSI و Storage Policy ارائه میشود. انتخاب StorageClass، Binding Mode و Failure Domain مستقیماً بر Availability کلاسترهای Multi-Zone اثر دارد.
مقایسه نسل vSphere 8، VCF 9.0 و VCF 9.1
| حوزه | vSphere 8 / TKG Service | VCF 9.0 | VCF 9.1 + VKS 3.6 |
|---|---|---|---|
| جایگاه Kubernetes | Workload Management و TKG Service در vSphere | گذار به نام و مدل VKS در پلتفرم VCF 9 | Runtime داخلی و مقیاسپذیر برای Private Cloud |
| نسخه Kubernetes | وابسته به TKr و Patch همان نسل | وابسته به VKS/VKR منطبق | پشتیبانی از Kubernetes 1.35 با VKS 3.6 |
| شبکه Node | تمرکز بر شبکه اصلی و الگوهای نسل قبل | پایه معماری جدید NSX VPC و VDS | Multi-NIC اعلانی روی NSX VPC و VDS |
| سیستمعامل Node | Photon، Ubuntu و Windows براساس Release | Imageهای منطبق با VKR | RHEL 9 و Mixed-OS در کنار Photon، Ubuntu و Windows |
| Day-2 Operations | Lifecycle مبتنی بر TKG Service | یکپارچگی بیشتر با VCF | Pre-check مستمر Upgrade، TuneD، AppArmor و Firewall API |
| توزیع Image | Content Library و Repositoryهای نسل قبل | گذار به Depot و Harbor | VCF Software Depot و Regional/VVF Harbor با مسیر مجزای آفلاین |
این مقایسه به معنی Upgrade مستقیم هر محیط vSphere 8 به VKS 3.6 نیست. Supervisor، نسخه vCenter/ESXi، Networking Backend، VKS Service، ClusterClass و VKR باید با Matrix و Release Notes همان Build تطبیق داده شوند. نام Kubernetes 1.35 نیز بهتنهایی برای تعیین سازگاری کافی نیست؛ Build کامل VKR ملاک است.
مهمترین قابلیتهای VKS 3.6
Kubernetes 1.35 با دوره پشتیبانی توسعهیافته
VKS 3.6 از Kubernetes 1.35 پشتیبانی میکند. Broadcom برای هر نسخه Kubernetes دوره پشتیبانی توسعهیافته ۲۴ماهه با همپوشانی نسخهها اعلام کرده است. این ویژگی برای سازمانی مهم است که نمیتواند همه کلاسترها را همزمان Upgrade کند. بااینحال، «۲۴ ماه» جای برنامه Upgrade را نمیگیرد؛ Add-onها، APIهای Deprecated و Compatibility نرمافزارهای داخل کلاستر باید پیش از پایان Support بررسی شوند.
مقیاس بیشتر و عملیات سریعتر
طبق معرفی رسمی VCF 9.1، یک Control Plane میتواند تا ۵۰۰ کلاستر Workload را پشتیبانی کند. Broadcom همچنین تا ۷۰ درصد Provisioning سریعتر و تا ۷۵ درصد Upgrade سریعتر را اعلام کرده است. این اعداد نتیجه آزمونهای Vendor هستند و نباید بدون Sizing و Benchmark به SLA هر محیط تبدیل شوند. DNS، IPAM، Datastore، Admission Webhook و ظرفیت زیرساخت میتوانند نتیجه واقعی را تغییر دهند.
Upgrade Readiness Checkهای پیوسته
VKS 3.6 بررسی آمادگی Upgrade را از یک تست لحظهای به Condition پیوسته نزدیک میکند. تضادهای رایج در Policy Engine، Admission Webhook و PodDisruptionBudget از طریق وضعیت SystemCheckSucceeded زودتر دیده میشوند. مزیت اصلی، کشف Blocker پیش از Maintenance Window است؛ اما تیم عملیات همچنان باید Backup، Drain Behavior، PDB و Rollback Plan را کنترل کند.
TuneD Profile برای Workloadهای حساس
تغییر دستی sysctl یا sysfs روی Nodeهای Managed معمولاً با تعویض Node از بین میرود و Configuration Drift ایجاد میکند. VKS 3.6 پروفایلهای TuneD را به شکل اعلانی و پشتیبانیشده ارائه میدهد. Profile میتواند به Node Pool مشخص اعمال شود؛ برای مثال Nodeهای پایگاهداده تنظیم حافظه متفاوتی از Nodeهای عمومی داشته باشند. Profile داخلی نقطه شروع است و Custom Profile باید در محیط آزمایش و با معیار Performance معتبر شود.
RHEL 9 و کلاسترهای Mixed-OS
RHEL 9 در VKS 3.6 برای Control Plane و Worker پشتیبانی میشود و میتواند کنار Photon OS 5، Ubuntu 22.04/24.04 و Windows Server 2022 قرار گیرد. این قابلیت به معنی رایگانبودن Subscription ردهت نیست. Entitlement و Credential رجیستری RHEL جداگانه لازم است و Image باید با Image Baker و مشخصات رسمی ساخته شود.
امنیت و Governance در سطح Node
قوانین Firewall مربوط به HostPort و NodePort اکنون میتوانند از Cluster Configuration و بهصورت API-driven مدیریت شوند؛ در نتیجه نیاز به DaemonSetهای Privileged برای بازکردن پورت کاهش مییابد. روی Linux، Backend مبتنی بر nftables برای kube-proxy نیز پشتیبانی میشود. AppArmor Profileها را میتوان بهصورت Custom Resource تعریف کرد تا روی همه Workerها یا Node Pool منتخب بارگذاری و همگام شوند.
مالک Workload Cluster همچنین میتواند بدون Credential مربوط به vCenter، Support Bundle بسازد. این تغییر ساده به نظر میرسد، اما Least Privilege و مرزبندی مسئولیت تیم Kubernetes و تیم زیرساخت را بهتر میکند.
Multi-Network؛ قابلیت مهم VKS 3.6 در VCF 9.1
در بسیاری از کلاسترها، Management، Kubernetes API، Pod Traffic، Storage و جریان داده روی یک NIC حمل میشوند. VKS 3.6 امکان تعریف Primary و Secondary Interface برای Nodeها را در Cluster Spec فراهم میکند. توپولوژی شبکه همراه Lifecycle کلاستر مدیریت میشود و میتوان Secondary NIC را برای Node Poolهای متفاوت Override کرد.
| Interface | نقش | محدودیت کلیدی |
|---|---|---|
| Primary، معمولاً eth0 | Control Plane، Service Discovery، Pod-to-Pod و مسیر اصلی | پس از ساخت کلاستر قابل تغییر نیست |
| Secondary، eth1 تا eth9 | Storage، Data، Multicast یا مسیر تخصصی | اضافه میشود، اما حذف کامل Interface نیازمند بازسازی کلاستر است |
| Pod Secondary NIC | Interface و IP مجزا برای Pod منتخب | به CNI و تنظیمات مربوط مانند Antrea IPAM نیاز دارد |
افزودن eth1 بهتنهایی Traffic برنامه را جابهجا نمیکند. Secondary NIC مسیر پیشفرض ندارد و Application باید برای استفاده از آن پیکربندی شود. Node-level Multi-NIC مستقل از Antrea است، اما Pod-level Multi-NIC به قابلیتهای CNI وابسته است.
NSX VPC در برابر VDS
Multi-Network روی NSX VPC و VDS پشتیبانی میشود. در NSX VPC، Objectهایی مانند Subnet و SubnetSet با API گروه NSX استفاده میشوند؛ در VDS، Object نوع Network از Network Operator بهکار میرود. توپولوژی Legacy مبتنی بر NSX-T T1 بدون VPC در این قابلیت پشتیبانی نمیشود.
در VDS، Port Group مربوط به Secondary NIC باید Trunk Mode، Forged Transmits و MAC Learning را همزمان داشته باشد. برای NSX VPC نیز DHCP باید برای Subnet ثانویه غیرفعال و Static IP Allocation خاموش باشد تا در Rolling Update و Scale-out، IP بیاستفاده انباشته نشود. SR-IOV همراه VLAN Tagging در این Release فقط روی VDS پشتیبانی میشود و Windows Node Pool از Secondary NIC پشتیبانی نمیکند.
برای دید عمیقتر شبکه و امنیت، مقاله نقش NSX و vDefend در VCF 9 مکمل این بخش است. Multi-NIC مرز توپولوژیک ایجاد میکند، اما جای Firewall Policy، NetworkPolicy و کنترل امنیتی Pod را نمیگیرد.
Storage، Zone و Availability
در کلاستر Multi-Zone، Placement Node و Volume باید هماهنگ باشد. KB رسمی Broadcom نشان میدهد پس از ارتقا به VKS 3.6 و VCF 9.1، Namespaceای که از Single-Zone به Multi-Zone تبدیل شده ممکن است با TopologyReconciled: False مواجه شود؛ بهخصوص وقتی Failure Domain صریح تعریف نشده و StorageClass از Binding Mode نوع Immediate استفاده میکند.
راهکار طراحی این است که برای هر Node Pool، Failure Domain مشخص شود یا StorageClass دارای WaitForFirstConsumer انتخاب شود. تغییر هرکدام میتواند Rolling Update ایجاد کند. انتخاب Storage Policy باید با معماری vSAN 9.1، Zone Failure و نیاز Stateful Workload هماهنگ باشد.
سناریوی واقعی: پلتفرم Kubernetes برای بانک یا فروشگاه آنلاین
فرض کنیم سازمان سه گروه Workload دارد: سرویسهای عمومی، پایگاهدادههای حساس به Latency و پردازشهای مالی با الزام جداسازی شبکه. یک طراحی منطقی میتواند چنین باشد:
- Supervisor و Namespaceها با Quota و دسترسی تفکیکشده آماده شوند.
- کلاستر VKS با Primary Network محدود برای Control Plane ساخته شود.
- Secondary NIC مجزا برای Storage و Data روی Node Poolهای لازم تعریف شود.
- Node Pool پایگاهداده با TuneD Profile و StorageClass دارای Late Binding ساخته شود.
- AppArmor، Firewall Rule و Admission Policy در قالب Git نگهداری شوند.
- ابتدا یک کلاستر Pilot با همان CNI، CSI و Add-onهای Production Upgrade شود.
- شاخصهای Provisioning Time، Drain، PDB، Volume Attach و Network Throughput ثبت شوند.
در این سناریو، داشتن ۵۰۰ کلاستر هدف نیست؛ امکان ایجاد کلاسترهای کوچکتر میتواند Blast Radius و مرزبندی تیمها را کاهش دهد. تعداد کلاستر باید از Tenant Model، هزینه عملیات، Address Space و ظرفیت Control Plane استخراج شود.
محدودیتها و خطاهای شناختهشده
Rollout متوقف در VKS 3.6.1 و 3.6.2
Broadcom برای حالتی که Upgrade VCF 9.1 با Rollout کلاستر همزمان میشود، مشکل Missing VirtualMachineGroup و ناهماهنگی تعداد Workerها را مستند کرده است. در این وضعیت CAPV ممکن است VM جدید نسازد. اجرای دستورهای اصلاحی KB باید با Backup، Maintenance Window و بررسی Support انجام شود؛ دستکاری Replica بدون شناخت Objectهای CAPI میتواند وضعیت را پیچیدهتر کند.
Primary و Secondary Network قابل بازگشت ساده نیستند
Primary Network پس از ساخت کلاستر تغییر نمیکند. Secondary Interface قابل اضافهشدن است، اما حذف کامل آن نیازمند Destroy و Recreate کلاستر است. بنابراین IP Plan و Network Objectها باید قبل از Production نهایی شوند.
نسخه 3.7 جای 3.6 را در همه محیطها نمیگیرد
Broadcom در ژوئن ۲۰۲۶ VKS 3.7 را نیز معرفی کرده است. این موضوع VKS 3.6 را خودکار منسوخ نمیکند. نسخه قابل نصب تابع VCF Build، VKS Service، VKR، Compatibility و Support Policy است. این مقاله مشخصاً Baseline همراه VCF 9.1 و VKS 3.6 را بررسی میکند؛ برای Upgrade به 3.7 باید Release Notes همان نسخه جداگانه ارزیابی شود.
محیط آفلاین، Harbor و محدودیت دسترسی در ایران
در VCF 9.1 متصل به اینترنت، تعریف استاندارد VKS Service، Image Bundle را از VCF Operations Software Depot و آدرس داخلی depot.kube-system.svc دریافت میکند. Regional Harbor یا VVF Harbor این زنجیره را پشتیبانی میکند. در VCF Automation، Regional Harbor در Workflow پلتفرم مستقر میشود؛ در VVF نصب Harbor مسیر دستیتری دارد.
برای محیط Air-Gapped باید تعریف Legacy متناسب استفاده شود تا Image Reference به Repository درست اشاره کند. استفاده از Standard YAML متصل در محیط آفلاین میتواند خطای DNS یا Registry Authentication ایجاد کند. KB 442742 نمونه واضح تفاوت فایلهایی مانند vsphere-kubernetes-service-legacy-3.6.2+v1.35.yaml و نسخه Standard را توضیح میدهد.
در ایران، ریسک عملی علاوه بر اتصال اینترنت شامل Entitlement، دریافت Binary، Credential رجیستری RHEL، گواهی داخلی و بهروزرسانی CVEهاست. مستندات عمومی Broadcom دسترسی منطقهای را تضمین نمیکنند. راهکار فنی، Repository داخلی کنترلشده، Harbor با Backup، Mirror قانونی Imageها، Hash Verification و Runbook برای Disconnected Depot است. Download Token یا فایلهای ناشناس جای Entitlement و زنجیره تأمین معتبر را نمیگیرند.
VKS در مسیر آموزش VMware و VCF
VKS مرز میان تیم مجازیسازی و Platform Engineering را کمرنگ میکند. در مسیر آموزش VMware و آموزش مجازی سازی ابرکلاس، یادگیری VKS باید پس از vSphere Networking، Storage Policy، DNS، Certificate و Load Balancer انجام شود. سپس Kubernetes API، YAML، CNI، CSI، Cluster API و GitOps وارد مسیر میشوند.
در آموزش VVF تمرکز میتواند روی Supervisor، Namespace، VKS و زیرساخت vSphere باشد؛ در آموزش VCF موضوعاتی مانند VCF Automation، Fleet Operations، NSX VPC، Regional Harbor و Disconnected Depot نیز به Scope اضافه میشوند. مشاهده سلامت و هزینه VKS از طریق VCF Operations 9.1 نیز بخش مهم Day-2 Operations است.
چکلیست پیش از Production
- Build دقیق VCF، VKS Service، ClusterClass و VKR با Release Notes تطبیق داده شده است.
- DNS، NTP، Certificate، IP Pool و Load Balancer ظرفیت کافی دارند.
- Primary Network و Secondary Interfaceها پیش از ساخت نهایی شدهاند.
- StorageClass، Binding Mode و Failure Domain برای Zoneها کنترل شدهاند.
- CNI، CSI، Admission Webhook و Operatorها در Pilot Upgrade آزموده شدهاند.
- Harbor، Software Depot و مسیر آفلاین Backup و Monitoring دارند.
- Support Bundle، Rollback، PDB و Maintenance Window مستند شدهاند.
جمعبندی فنی
VKS 3.6 در VCF 9.1 یک Kubernetes Distribution ساده نیست؛ یک لایه Lifecycle برای تبدیل vSphere به بستر Platform Engineering است. قابلیتهای مهم آن از یک سمت Scale و سرعت را افزایش میدهند و از سمت دیگر، تنظیمات تخصصی شبکه، Kernel، OS و Security را به مدل اعلانی و قابل پشتیبانی میآورند.
بااینحال، پلتفرم پیچیدگی Kubernetes را حذف نمیکند. Multi-NIC بدون Routing و CNI درست، Multi-Zone بدون Storage Binding درست و Air-Gapped بدون Harbor و Depot درست به مشکل تبدیل میشوند. انتخاب موفق VKS زمانی است که تیم زیرساخت و تیم Kubernetes یک Design مشترک برای Network، Storage، Lifecycle و Supply Chain داشته باشند.
سؤالات متداول
VKS 3.6 از چه نسخه Kubernetes پشتیبانی میکند؟
این نسخه Kubernetes 1.35 را وارد VKS میکند. برای نصب باید Build کامل VKR و Compatibility محیط بررسی شود.
آیا VKS 3.6 فقط در VCF قابل استفاده است؟
VKS بخشی از قابلیت Kubernetes در پلتفرم vSphere/VCF است و جایگاه دقیق آن در VVF و VCF تابع بسته، معماری و سرویسهای مصرفی است. قابلیتهایی مانند VCF Automation و Regional Harbor دامنه VCF را گستردهتر میکنند.
آیا Multi-Network ترافیک Pod را خودکار به NIC دوم میفرستد؟
خیر. افزودن Secondary NIC فقط توپولوژی را ایجاد میکند. برای استفاده Node یا Pod از آن باید Route، CNI و تنظیم Application تعریف شود.
آیا میتوان Primary NIC را بعداً تغییر داد؟
خیر. Primary Network در زمان ساخت تثبیت میشود. Secondary NIC قابل اضافهشدن است، اما حذف کامل آن نیز نیازمند بازسازی کلاستر است.
آیا RHEL 9 Image آماده Broadcom است؟
VKS 3.6 از RHEL 9 از طریق BYOI و Image Baker پشتیبانی میکند. Subscription و Credential ردهت لازم است. Broadcom برای Photon و Ubuntu Image آماده ارائه میکند.
برای VKS آفلاین چه چیزی حیاتی است؟
Harbor داخلی، Bundle و YAML متناسب با Air-Gapped، Image Mirror معتبر، DNS داخلی و زنجیره بهروزرسانی امنیتی. استفاده اشتباه از Standard YAML متصل میتواند Reconcile را متوقف کند.
