Sidecar deseni: uygulamanın yanında çalışan yardımcı kapsayıcı
Sidecar deseni, ana uygulamanın yanında çalışan yardımcı bir kapsayıcıdır; günlükleme, ağ ve güvenlik gibi ortak işleri uygulama kodundan ayırır.
Sidecar deseni nedir?
Sidecar deseni, ana uygulamanın yanında, aynı çalışma ortamında koşan ve ona yardımcı hizmetler sunan ayrı bir bileşendir. Adını motosiklete takılan yan arabadan alır: motosiklet ana yoldur, yan araba onu tamamlar ama ayrı bir gövdedir.
Kubernetes ortamında bu bileşen genellikle uygulama kapsayıcısıyla aynı pod içinde çalışan ikinci bir kapsayıcıdır. Aynı ağ alanını ve istenirse aynı depolama alanını paylaşır, ama ayrı bir imajdan gelir, ayrı güncellenir ve ayrı kaynak sınırlarıyla çalışır.
Neden kullanılır?
Mikroservis mimarisinde her servisin günlük toplama, ağ şifrelemesi, yeniden deneme, yapılandırma yenileme gibi ortak ihtiyaçları vardır. Bunları her servisin koduna gömmek tekrar ve tutarsızlık yaratır; farklı dillerde yazılmış servislerde de zor sürdürülür.
Sidecar bu ortak işleri uygulama kodundan ayırır. Uygulama yalnız iş mantığına odaklanır, yardımcı işi sidecar üstlenir. Bu ayrım uygulama kodunu değiştirmeden yeni yetenek eklemeyi, hizmet dilinden bağımsız çalışmayı ve ortak bileşenin merkezden güncellenmesini mümkün kılar.
Nasıl çalışır?
Pod içindeki kapsayıcılar yerel ağı paylaştığı için sidecar, uygulamayla localhost üzerinden konuşabilir. Bir günlük sidecar'ı uygulamanın yazdığı dosyayı ortak bir birimden okuyup merkezi sisteme gönderir. Bir ağ sidecar'ı ise uygulamaya gelen ve giden trafiği kendi üzerinden geçirir.
Service mesh yapılarında bu ikinci tür kullanılır. Istio gibi araçlar, pod'a otomatik olarak bir vekil (proxy) kapsayıcısı ekler; bu işleme sidecar enjeksiyonu denir. Uygulama başka bir servisle konuştuğunu sanır, aslında trafik önce sidecar'dan geçer; şifreleme (mTLS), yönlendirme, yeniden deneme ve metrik toplama orada yapılır.
Örnek: günlük toplama ve vekil
Örneğin bir ödeme servisi dosyaya günlük yazıyor ve merkezi bir günlük sistemi bunları toplamak istiyor. Servisin koduna günlük gönderme mantığı eklemek yerine yanına bir günlük sidecar'ı konur: bu kapsayıcı dosyayı okur ve sisteme iletir. Hedef sistem değiştiğinde yalnız sidecar güncellenir.
Bir başka örnekte, servisler arası iletişimi şifrelemek gerekir. Her servisin kendi sertifikayı yönetmesi yerine mesh'in sidecar vekili şifrelemeyi ve sertifika yenilemeyi üstlenir. Örnekler kurgusaldır ama deseni gösterir.
Avantajları ve bedeli
Avantajlar: ortak yeteneklerin tek yerde yönetilmesi, dilden bağımsızlık, uygulama koduna dokunmadan davranış ekleme, yardımcı bileşenin bağımsız güncellenmesi ve ayrı kaynak sınırlarıyla izole edilmesi.
Bedeller de vardır: her pod'a ek kapsayıcı eklenir, bu CPU ve bellek maliyeti demektir; trafik bir ek sıçrama yapar ve küçük de olsa gecikme getirir; sidecar sürümlerinin güncellenmesi pod'ların yeniden başlatılmasını gerektirebilir; sorun giderme katman sayısı arttıkça zorlaşır. Bu nedenle bazı mesh çözümleri sidecar kullanmayan işletim biçimleri de sunar. Istio'nun ambient modu bunlardan biridir.
İlişkili kavramlar
Service mesh, sidecar vekilleri ağı üzerine kurulu bir iletişim katmanıdır. API gateway ise dış dünyadan gelen isteklerin giriş noktasıdır; sidecar ise servisler arası iç trafiğe odaklanır. Ambassador ve adapter desenleri sidecar ailesinin akrabalarıdır: ambassador dış servislere erişimi vekâlet eder, adapter çıktı biçimini standartlaştırır.
Kubernetes'te init container uygulama başlamadan çalışıp biten bir hazırlık adımıdır; sidecar ise uygulamayla birlikte yaşar. Bu fark yaşam döngüsü yönetimini etkiler.
Mindset programlarında nerede çalışılır?
Sidecar, platform ve DevOps ekiplerinin Kubernetes üzerinde kullandığı temel desenlerden biridir. Kubernetes ile Orkestrasyon programı iş yükü kaynaklarını, servis ve ağ yönetimini, yapılandırma ve gizli yönetimini kapsar; pod yapısını kavramak için uygun başlangıçtır.
Istio ile Service Mesh Uygulamaları programı mimariyi, kurulumu ve sidecar enjeksiyonunu, trafik yönetimini, mTLS güvenliğini, gözlemlenebilirliği ve ambient modunu işler. Linkerd ile Hafif Service Mesh İşletimi programı hafif bir yaklaşımı otomatik mTLS ve gözlemlenebilirlikle ele alır. Kubernetes İleri Seviye: Operator ve CRD Geliştirme programı ise kabul kancaları gibi genişletme mekanizmalarına yöneliktir.
İlgili Mindset programı
Kubernetes ile Orkestrasyon
Sık sorulan sorular
Sidecar ile ayrı bir mikroservis arasındaki fark nedir?
Sidecar, ana uygulamayla aynı pod'da ve aynı yaşam döngüsünde çalışır; yerel ağ üzerinden hızlı konuşur. Ayrı bir mikroservis ise bağımsız dağıtılır ve ağ üzerinden uzaktan çağrılır. Sidecar uygulamaya özgü yardımcı iştir, mikroservis kendi başına bir iş yeteneğidir.
Her pod için sidecar şart mı?
Hayır. Yalnız ortak bir ihtiyaç olduğunda anlamlıdır. Basit uygulamalarda kapsayıcıyı çoğaltmak gereksiz yüktür. Service mesh kullanmıyorsanız ağ sidecar'ına ihtiyaç duymazsınız; günlük gibi ihtiyaçlar için bazı ortamlar düğüm düzeyinde toplayıcıları tercih eder.
Sidecar uygulama performansını etkiler mi?
Etkiler: ek kaynak tüketir ve ağ trafiği bir ara durak daha geçer. Etkinin boyutu sidecar'ın işine ve yapılandırmasına bağlıdır. Üretime almadan önce kendi iş yükünüzde ölçmek ve kaynak sınırlarını bilinçli ayarlamak gerekir.
Sidecar desenini yalnız Kubernetes mi kullanır?
Hayır. Desen kavram olarak platformdan bağımsızdır; ana sürecin yanında çalışan yardımcı süreç fikridir ve sanal makinelerde ya da düğüm üzerinde de uygulanabilir. Ancak en yaygın uygulama alanı, kapsayıcıların bir pod içinde bir arada çalışabildiği Kubernetes ortamıdır.
İlgili rehberler
İlgili eğitimler
Kategori: DevOps ve Bulut Teknolojileri