فناوری · زیرساخت کلاستر
Kubernetes در دزکوب
بستر پایه و منبع حقیقت
- نسخهٔ پینشده
- ⟦V_KUBERNETES⟧
- لایسنس
- Apache 2.0
- گروه در استک
- زیرساخت کلاستر
Kubernetes چیست
سامانهٔ ارکستراسیون بار کاری که امروز استاندارد صنعتیِ عملاً پذیرفتهشده است. کارش این است که وضعیت مطلوب را بگیرد و پیوسته واقعیت را به سمت آن براند.
چرا این را انتخاب کردیم
| گزینهای که رد شد | چرا نه |
|---|---|
| ارکستراسیون سبکتر (Swarm و مشابه) | مدل شبکه و استوریج و افزونهپذیریشان برای ماشین مجازی و GPU کافی نیست |
| مدیریت مستقیم ماشین مجازی بدون ارکستراتور | آنوقت باید جدولبندی، سلامت، شبکه و استوریج را خودمان بنویسیم |
| پلتفرم اختصاصی خودمان | قفلِ تأمینکننده برای مشتری، و بازنویسی چیزی که ده سال بالغ شده |
دلیل تعیینکننده
Kubernetes به ما اجازه داد ماشین مجازی و container را زیر یک مدل بیاوریم. این کل موقعیتیابی دزکوب را ممکن کرد.
ما دقیقاً چطور استفادهاش میکنیم
- منبع حقیقت. هر نوشتنی به Kubernetes میرود؛ دیتابیس ما یک projection است که با watch بازسازی میشود.
- درگاه واحد. هیچ سرویسی مستقیم با API server حرف نمیزند؛ همه از یک واسط عبور میکنند.
- برچسب مالکیت پایدار. هر منبعی که میسازیم برچسب مالکیت میگیرد تا ردیابیاش ممکن باشد.
- نقش حداقلی. کنترلپلن با نقشی محدود کار میکند، نه با دسترسی کامل کلاستر.
- همهچیز شیء استاندارد است. هیچ CRD اختصاصی و اجباریای برای تعریف بار کاری شما نمیسازیم.
برای شما چه چیزی عوض میشود
- دو دنیای جدا برای VM و containerیک بستر
- مهارت انحصاری محصولمهارت قابل استخدام و مستند
- خروج = مهاجرت کاملخروج = یک کلاستر استاندارد باقی میماند
مرزها و محدودیتها
این سکشن در هر صفحهٔ فناوری اجباری است. هر ابزاری مرزی دارد؛ صفحهای که مرزش را نگوید، بقیهاش هم قابل اتکا نیست.
- Kubernetes خودش پیچیده است. بخش بزرگی از کار دزکوب، پنهان کردن همین پیچیدگی است — ولی وقتی چیزی عمیقاً خراب شود، دانش Kubernetes لازم میشود.
- ارتقای نسخهٔ اصلی کلاستر یک عملیات برنامهریزیشده است، نه یک دکمه.
اینها را هم ببینید
این را روی زیرساخت خودتان ببینید.
همین مؤلفه را در کلاستر شما پیکربندی میکنیم و نشان میدهیم.