به گزارش از وبسایت cncf
سازمانهایی که داراییهای VM خود را از هایپروایزرهای سنتی به KubeVirt مهاجرت میدهند، اغلب درمییابند که ابزارهای مشاهدهپذیری Kubernetes عمدتاً بر بار کاری مبتنی بر کانتینر طراحی شدهاند و برای ماشینهای مجازی مناسب نیستند. اگرچه KubeVirt ماشینهای مجازی را بهعنوان پاد زمانبندی میکند، رفتارهای عملکردی مهمی مانند تأخیر زمانبندی Kubernetes، توان عملیاتی درایور CSI و سربار پوشش SDN با هم تعامل میکنند و معیارهای متداول pod‑محور را پوشش نمیدهند. 🙂
تیمهای پلتفرم به پاسخهای قابل اندازهگیری و تکرارشونده برای پرسشهایی نیاز دارند که معیارهای کانتینری آنها را نادیده میگیرد؛ از جمله:
• زمان آماده (Ready time): زمان دیواری از لحظه فراخوانی API تا زمانی که شبکهٔ سیستمعامل میهمان کاملاً در دسترس و تأیید شده است — نه صرفاً وضعیت pod/Running.
• ظرفیت انفجاری (Boot storm capacity): رفتار و محدودیت زیرسیستم ذخیرهسازی هنگام ایجاد همزمان چندین VM (طوفان راهاندازی).
• زمان بیحسی مهاجرت زنده (Live Migration Stun Time): پنجره قطعی در سطح شبکه در طول انتقال زنده VMI از طریق شبکهٔ همپوشان.
برای اندازهگیری این ویژگیهای عملیاتی، تیم پروژه ابزار بنچمارک KubeVirt به نام virtbench را توسعه داد: یک چارچوب CLI متنباز برای اجرای تستهای استرس قابل تکرار در خوشههای مجهز به KubeVirt — از جمله KubeVirt روی OpenShift و سایر محیطها با مکانیزمهای ذخیرهسازی سازگار با CSI. این ابزار کمک میکند تا اثر بارگذاری سالم روی VMها حتی وقتی حجم کاری کلاس VM کاهش مییابد، ملموس و قابل ردیابی شود. 🧰
سه عدم تطابق معماری مهم که موجب مشکلات مشاهدهپذیری میشوند عبارتاند از:
1) آمادگی Pod ≠ آمادگی VM: شرط Kubernetes Ready زمان شروع کانتینر را منعکس میکند که اغلب در میلیثانیه رخ میدهد، در حالی که یک VMI تا زمانی که هستهٔ میهمان راهاندازی نشده و سرویسهای فضای کاربر فعال نشده و عامل میهمان ضربان قلب گزارش نکرده است، از نظر عملیاتی آماده نیست. معیارهای متکی بر pod/Running میتوانند زمان واقعی آمادهشدن را با دقت دقیقهای پنهان کنند.
2) بارگذاری CSI برای ماشینهای چنددیسکی: VMهای تولیدی معمولاً به چند PVC نیاز دارند — یک حجم بوت، یک swap و یک یا چند حجم داده با IOPS بالا. معیارهای کانتینری معمولاً توانایی درایور CSI را برای تهیه و اتصال همزمان چندین دستگاه بلوک به یک VMI اندازهگیری نمیکنند؛ virtbench چنین سناریوهایی را شبیهسازی و مسیر DataVolume → PVC → اتصال دستگاه بلوک را تحت بار میسنجد.
3) مهاجرت زنده از طریق شبکهٔ همپوشان در مقابل vMotion: در حالی که vMotion حافظهٔ در حال اجرا را از طریق کانالی اختصاصی با پهنای باند بالا منتقل میکند، KubeVirt مهاجرت زنده را از طریق پوشش SDN خوشه (مثلاً OVN‑Kubernetes) انجام میدهد که تأخیر اضافه میکند و با ترافیک بار کاری رقابت میکند. virtbench زمان stun (مدت زمانی که رابط شبکهٔ VMI در دسترس نیست) را در سناریوهای متوالی و موازی اندازهگیری میکند.
روش اندازهگیری آمادگی VM در virtbench به این شکل است:
• API Trigger: virtbench اشیاء VirtualMachine را به API سرور Kubernetes ارسال میکند و درایور CSI منابع DataVolume و PVC مرتبط را ایجاد میکند.
• ردیابی وضعیت ماشین: CLI، وضعیت VMI را نظرسنجی کرده و زنجیرهٔ وضعیت را دنبال میکند: Pending → Scheduled → Bound → Running.
• کاوش شبکهٔ میهمان: یک ssh-test-pod مستقر در داخل خوشه بهطور پیوسته پروبهای TCP را به آدرس IP اختصاصیافته هر VMI میفرستد.
• تکمیل اندازهگیری: تایمر فقط در صورت موفقیتآمیز بودن دستدهی TCP بسته میشود — که نشان میدهد پشتهٔ شبکهٔ میهمان کاملاً عملیاتی است. نتایج بهصورت ساختارمند JSON و CSV منتشر شده و سپس در یک داشبورد HTML تعاملی برای تحلیل ارائه میشوند.
virtbench چهار موتور بنچمارک داخلی دارد که هر کدام بهصورت ماژول جداگانه علیه KubeVirt و APIهای ذخیرهسازی اجرا میشوند: DataSource Clone، Migration، Capacity و Failure Recovery. این ابزار شش سناریوی آزمون آماده دارد که شامل مواردی مانند VM Provisioning و Storage efficiency، Single‑node boot storm، Cluster‑level boot storm، Live Migration، Chaos benchmark (عملیات همزمان مانند ایجاد، تغییر اندازه، شبیهسازی، ریبوت و snapshot) و آزمونهای HA از طریق Fence Agents برای سنجش زمان تا بازیابی میشود.
نتایج بهصورت خودکار در داشبوردهای چندنموداری نشان داده میشوند. هر نمودار به یک مرحلهٔ اندازهگیری اختصاص دارد: مدت زمان ایجاد (آبی) نشاندهندهٔ تأخیر ارائه به ازای هر VM تحت بار متوالی است، طوفان راهاندازی (سبز) پوششدهندهٔ تأخیر تحت درخواستهای همزمان و نقاط اشباع در درایور CSI است، و Live Migration (نارنجی) مدت زمان مهاجرت به ازای هر VMI و زمان بیحسی را در طول توالیهای تخلیهٔ گره نشان میدهد. در خلاصهٔ Creation، زمان end‑to‑end به سه زیرزمان تقسیم میشود: clone_duration (زمان کپی CSI)، run_time (شروع کانتینر kubelet) و ping_time (کاوشگر شبکهٔ میهمان) تا مشخص شود رگرسیون از کدام لایه ناشی میشود.
در مقایسه با ابزارهای دیگر: kube‑burner بیشتر روی API/control plane و زمانبندی تمرکز دارد، ابزارهای fio/iperf روی میکرو‑بنچهای دیسک و شبکه کار میکنند، اما virtbench مسیر داده را اندازهگیری میکند و شاخصهایی مانند سرعت کپی، زمان راهاندازی سیستمعامل و دسترسی شبکه را بر مبنای سناریوهای VM‑محور میسنجد. هدف این است که پاسخ شفافتری به پرسش «عملیات چقدر طول کشید؟» برای محیطهای KubeVirt ارائه شود.
اجرای اولیهٔ virtbench برای ادغام با خطهای CI طراحی شده است؛ بنابراین میتوانید آن را قبل و بعد از تغییرات زیرساختی (بهروزرسانی آرایههای ذخیرهسازی، تغییر CNI، ارتقاء نسخهٔ Kubernetes و…) اجرا کنید تا رگرسیونهای عملکردی پیش از ورود به تولید شناسایی شوند. توجه داشته باشید که دادههای بنچمارک بسیار وابسته به محیط هستند؛ در نسخههای آینده ابزارهایی مانند fio درون VM نیز برای سنجش I/O داخلی اضافه خواهد شد.
این پروژه متنباز است و مشارکت جامعه را میپذیرد: github.com/portworx/kubevirt-benchmark. از مشارکتها و بازخوردها بهویژه در زمینهٔ موارد آزمایشی تکرارشونده، مقایسهٔ پلتفرمها و ارائهٔ ماژولهای بنچمارک اضافی از اپراتورهای اجراکنندهٔ KubeVirt در محیطهای تولیدی استقبال میشود. 🚀
