Sidecar pattern — asosiy ilova bilan bir xil deployment birligida yonma-yon ishlaydigan yordamchi process yoki container orqali umumiy funksiyani ajratish arxitektura usulidir. Nom mototsikl yonidagi aravachadan olingan. Sidecar ilova lifecycle’iga bog‘langan, lekin uning kod bazasi va ba’zan texnologiyasidan mustaqil bo‘ladi.
Joylashuv modeli
Kubernetes Pod ichidagi containerlar bir network namespace va localhost’ni bo‘lishadi, volume’larni birga mount qilishi mumkin. Asosiy container biznes funksiyasini, sidecar esa proxy, log agent, configuration reloader yoki credential yangilashni bajaradi. Pod rejalashtirilganda ikkalasi bir node’da ishlaydi.
Virtual mashina yoki oddiy process muhitida ham sidecar qo‘llanadi: yordamchi daemon asosiy xizmat bilan bir hostda ishlaydi. Muhim belgi — u masofadagi umumiy service emas, aynan ilova nusxasiga yaqin companion hisoblanadi.
Qo‘llanishlar
Service mesh data-plane proxy har podning inbound va outbound trafikini boshqarib, mTLS, retry va telemetry beradi. Log sidecar umumiy volume’dagi faylni o‘qib, markaziy tizimga yuboradi. Secret agent qisqa muddatli credential olib, ilovaga fayl yoki lokal API orqali yetkazadi.
Configuration sidecar tashqi manbani kuzatib, faylni yangilashi yoki ilovaga reload signali yuborishi mumkin. Adapter legacy formatni zamonaviy protokolga o‘giradi. Bu funksiyalarni har til va jamoada qayta yozish o‘rniga standart komponent ishlatiladi.
Afzalliklar
Cross-cutting concern biznes koddan ajraladi. Sidecar mustaqil versiyalanadi va turli tillardagi xizmatlarga bir xil siyosat beradi. Localhost aloqa masofadagi service’dan past latency hamda sodda discovery taqdim etadi.
Lifecycle birligi deploymentni tushunarli qiladi: ilova nusxasi bilan unga xizmat qiluvchi proxy birga yaratiladi va olib tashlanadi. Ammo bu bog‘liqlik start va shutdown tartibini aniq boshqarishni talab qiladi.
Xarajat va xavf
Har replica uchun sidecar CPU, xotira va connection sarflaydi. Yuzlab podlarda kichik overhead ham katta umumiy resursga aylanadi. Proxy data path’da bo‘lsa uning nosozligi yoki noto‘g‘ri configuration asosiy ilovani ishlamay qolishiga olib kelishi mumkin.
Sidecar version drift, security patch va observability alohida boshqariladi. Ilova tayyor bo‘lsa-yu sidecar hali ishga tushmagan holat uchun readiness probe kerak. Shutdownda proxy yangi trafikni to‘xtatib, mavjud ulanishlarni drain qiladi, so‘ng ilova yakunlanadi.
Chegaralar
Faqat bir hostga kerak bo‘lgan agent uchun DaemonSet sidecardan tejamkorroq bo‘lishi mumkin. Ko‘p xizmat bo‘lishadigan og‘ir funksiya alohida network service sifatida joylashtiriladi. Har requestni sidecar orqali o‘tkazish muammo yechmasa, ortiqcha murakkablik beradi.
Sidecar imtiyozi minimal bo‘ladi: umumiy volume va network ko‘rinishi hujum yuzasini kengaytirishi mumkin. Image provenance, capability, filesystem permission va egress policy asosiy container kabi tekshiriladi.
Init containerdan farqi
Init container asosiy ilova boshlanishidan oldin vazifani bajarib tugaydi; sidecar esa odatda ilova bilan parallel uzoq ishlaydi. Database migration yoki config faylini bir marta yaratish init vazifasiga mos, log forwarding esa sidecar talab qiladi. Platforma sidecar lifecycle’ini alohida qo‘llasa, startup order va pod tugashida yordamchi containerning kechroq to‘xtashi ta’minlanadi. Aks holda custom entrypoint yoki readiness orqali tartib boshqariladi. Bir sidecar ishlamay qolsa podning restart siyosati va asosiy ilovaga ta’siri oldindan belgilanadi.
Bog‘liq tushunchalar
Service mesh, Ambassador pattern, Adapter pattern, Kubernetes Pod, Reverse proxy, Init container