Task group — bir xil job yoki deployment maqsadiga xizmat qiladigan bir nechta taskni mantiqiy va rejalashtirish birligi sifatida birlashtiruvchi tuzilmadir. Nomad kabi schedulerlarda group ichidagi tasklar bir nodega joylashtirilishi, umumiy tarmoq va volume dan foydalanishi hamda birgalikda yangilanishi mumkin.
Guruhlash sababi
Application process, log sidecar va local proxy bir-biriga localhost, shared directory yoki bir xil lifecycle orqali bog‘liq bo‘lishi mumkin. Ularni task groupga qo‘yish schedulerga bitta allocation ichida joylashtirish imkonini beradi. Mustaqil masshtablanishi kerak bo‘lgan servislarni bir groupga majburlash esa har o‘zgarishda hammasini ko‘paytiradi.
Guruh chegarasi “bir featurega tegishli” degan umumiylikdan ko‘ra runtime couplingga asoslanadi. Ikki task faqat API orqali tarmoqda gaplashsa, alohida group va service discovery ko‘proq mos bo‘lishi mumkin.
Umumiy resurslar
Tasklar allocation filesystemidagi umumiy katalogdan foydalanishi mumkin. Secrets va template lar group yoki task scope da beriladi. Network namespace umumiy bo‘lsa port to‘qnashuvi oldindan aniqlanadi. Volume lifecycle va write concurrency aniq boshqariladi.
Resource request tasklar bo‘yicha yig‘ilib, groupni joylashtirishga ta’sir qiladi. Bitta sidecar memory limitdan chiqsa faqat o‘zi yoki butun allocation qayta ishga tushishi scheduler semantikasiga bog‘liq. Group darajasidagi ephemeral disk barcha task yukini hisobga oladi.
Lifecycle va bog‘liqlik
Prestart task main applicationdan oldin migration yoki config tayyorlashi mumkin. Poststart yordamchi jarayon keyin ishga tushadi. Sidecar uzoq yashaydi, batch hook esa muvaffaqiyatli tugab chiqadi. Start order readinessning o‘rnini bosmaydi; process ishga tushgani xizmat tayyorligini anglatmaydi.
Health check va restart policy task failureiga qanday javob berilishini belgilaydi. Critical sidecar ishlamasa application trafik olmasligi kerak. Optional telemetry task xatosi esa asosiy xizmatni doim to‘xtatishi shart emas. Bog‘liqlik darajasi explicit yoziladi.
Scaling va update
Group count oshirilganda barcha tarkibiy tasklardan iborat yangi allocationlar yaratiladi. Applicationga bir proxy sidecar nisbati 1:1 saqlanadi. Agar proxy resursi katta bo‘lsa, har replica uchun takrorlanish xarajati hisobga olinadi.
Rolling update group allocationlarini belgilangan parallelism bilan almashtiradi. Canary yangi group versiyasini kichik countda yaratadi. Healthy deadline, min healthy time va auto-revert siyosati rolloutning muvaffaqiyatini belgilaydi.
Xatolarni tahlil qilish
Group status ichidagi har task state va event alohida ko‘riladi. “Allocation failed” umumiy xabar ortida image pull, port collision, hook exit yoki volume mount xatosi bo‘lishi mumkin. Loglar task nomi va allocation ID bilan ajratiladi.
Reschedule boshqa nodega yangi allocation yaratadi, restart esa mavjud allocation ichidagi taskni qayta boshlashi mumkin. Lokal ephemeral data bu farqda yo‘qolishi ehtimol. Stateful task uchun persistent volume va placement cheklovi rejalashtiriladi.
Service registration
Group tasklari service registryga alohida yoki umumiy endpoint sifatida ro‘yxatdan o‘tishi mumkin. Health check qaysi task xizmatga tayyorligini bildiradi. Allocation almashtirilganda eski registration deregister qilinmasa trafik o‘lik manzilga yuboriladi. Sidecar proxy registration metadata orqali upstream policy olishi mumkin.
Security boundary
Bir network namespace va shared volume tasklar orasida ishonchni kengaytiradi. Sidecar buzilsa application traffic yoki secretlarga kira olishi mumkin. Faqat zarur mount va environment beriladi, task userlari ajratiladi. Group ichidagi localhost avtomatik ravishda xavfsiz kanal deb qabul qilinmaydi.
Capacity
Tasklardan biri juda katta request bersa butun groupni joylashtirish qiyinlashadi. Scheduler alohida nodelarda bo‘sh resurs bo‘lsa ham groupni bo‘la olmaydi. Runtime coupling zarur bo‘lmasa, komponentni alohida jobga ajratish bin-packing va mustaqil scalingni yaxshilaydi.
Bog‘liq tushunchalar
Nomad, Task, Job, Allocation, Sidecar, Scheduler, Rolling update