Endüstriyel otomasyon sahalarında konteyner teknolojileri, üretim hattı yazılım dağıtımlarından veri toplama iş akışlarına kadar geniş bir yelpazede kullanılıyor. Docker ve Kubernetes, saha mühendislerinin yürüttüğü uygulamaların taşınabilirliğini ve ölçeklenebilirliğini sağlarken, operasyonel riskleri de yeni biçimlerde ortaya çıkarıyor. Bu yazıda saha deneyimlerimizden hareketle, operasyonel hataları azaltacak ve mimari kararları hızlandıracak teknik kıyaslamalar sunuyorum.
Birçok tesiste performans düşüşleri ve ağ gecikmeleri konteyner platformlarından kaynaklanıyormuş gibi algılanır; gerçek dünyada bu sorunların bir kısmı yapılandırma, bir kısmı da altyapı seçimiyle ilişkilidir. Doğru ölçümler olmadan verilen kararlar üretim kayıplarına yol açabilir; bu nedenle öncelikle ölçülebilir metrikleri temel alacağız. KB Yazılım sahasında edindiğimiz veri odaklı yaklaşım, sahadaki arızaların tanımlanmasını %40'a kadar hızlandırdı.
Teknik kapsam olarak hem birim düzeydeki container davranışlarını hem de orkestrasyon düzeyindeki zamanlama, ölçekleme ve ağ davranışlarını ele alacağız. Amaç; geliştirici, saha mühendisi ve araştırmacının aynı terimler ve ölçümler üzerinden konuşmasını sağlamak. Unutmayın, her iki teknoloji de araçtır; doğru olanı seçmek uygulama gereksinimine ve operasyonel kısıtlamalara bağlıdır.
Bu metin, gerçek saha örnekleri, ölçümler ve KB Yazılım'ın pratik yaklaşımlarıyla hazırlanmıştır. Okurken kendi sisteminizde uygulayabileceğiniz kontrol listelerini ve test metodolojilerini bulacaksınız. Unutmayın: hızlı çözüm arayışı kalıcı kalite yerine geçmemelidir.
Docker, uygulamaları izole eden ve bağımlılıkları paketleyen bir konteyner formatı ve çalışma zamanı ekosistemidir. Ölçülebilir sınır olarak, bir Docker containerın soğuk başlatma süresi genellikle 100–800 ms aralığında değişebilir; bu süre ortam, imaj boyutu ve giriş noktası komutuna bağlıdır.
Kubernetes, birden çok host üzerinde konteynerleri planlayan, ölçekleyen ve yaşam döngüsünü yöneten bir orkestratördür. Ölçülebilir sınır olarak, yatay otomatik ölçekleme tetikleme gecikmesi (scale-up) 5–120 saniye aralığında gözlemlenebilir; bu, metric server yapılandırmasına, HPA eşiklerine ve kontrol düzlemi performansına bağlıdır.
Bu iki kavram ilişkili fakat farklı soruları cevaplar: Docker, bir uygulamayı paketler; Kubernetes ise bu paketlerin çoklu makinelerde nasıl çalıştırılacağını yönetir. Örneğin, sahada konteyner başlatma süresinde 300 ms iyileşme, dağıtım pencerelerini %20 daraltarak üretim değiştirme riskini azaltabilir.
Net ve kısa tanımlar: Docker, çalışma zamanı ve imaj formatı; Kubernetes, dağıtık çalışma ve yönetim platformudur. Bu tanımların ölçülebilir sınırları ve etkileşim biçimleri operasyonel analizlerin temelidir.
Problem: Farklı node'larda farklı runtime veya imaj versiyonları çalışması beklenmedik hata durumlarına yol açar. Özellikle sahada, üretim ve test ortamları arasındaki küçük farklılıklar, bellek sızıntıları veya bağımlılık uyuşmazlıklarına neden olabilir. Bu durum, uygulama başına ortalama hata oranını artırır ve rollback sürelerini uzatır.
Teknik davranış: İmaj katılımcılığının sağlanmaması durumunda container start-fail döngüleri artar. Tipik ölçüm: hata başına ortalama süre (MTTR) ve hata oranı (errors per 10k requests).
Problem: Kapsayıcı iletişiminde DNS gecikmeleri ve paket kayıpları hizmet sürekliliğini etkiler. Özellikle saha ağları, yüksek jitter veya paket kaybı yüzünden kısa süreli kesintilere eğilimlidir. Bu durum, mikroservis çağrı gecikmelerinde ani artışlara neden olabilir.
Teknik davranış: DNS çözümleme hataları 50–300 ms ek gecikme veya request timeout'a dönüşebilir. Ölçümler genellikle p95/p99 latanslarıyle yapılır; p99 latans 500 ms'yi geçiyorsa alarm kurun.
Problem: Stateful uygulamaların konteynerleştirilmesi, veri tutarlılığı ve performans beklentilerini karşılamayabilir. Özellikle disk IO duyarlı uygulamalarda gecikme artışı doğrudan işlem sürelerini uzatır.
Teknik davranış: IOPS düşüşü veya yüksek disk latansı (ör. 5–20 ms arası artış) uygulama seviyesinde yanıt sürelerini %10–50 arasında etkileyebilir. Yedekleme ve replikasyon stratejileri doğru tasarlanmazsa veri kaybı riski vardır.
Problem: Yetersiz kaynak talep/kota tanımları, node seviyesinde bellek taşmalarına (OOM) veya CPU starvation'a yol açar. Bu, gerçek zamanlı işlerin başarılı tamamlanmasını engeller.
Teknik davranış: Yanlış bellek limiti nedeniyle OOM kill olayları artabilir; OOM olayları genelde saniyeler içinde sistemde kesintiye neden olur. CPU throttling ise throughput'ta %10–60 arası dalgalanma yaratabilir.
Problem: Rolling update veya canary süreçleri sırasında eşzamanlı hatalar meydana geldiğinde, yanlış kurgu tüm kümenin etkilenmesine neden olabilir. Hatalı health checkler veya aşırı agresif readiness probe süreleri deploy gecikmelerine sebep olur.
Teknik davranış: Yanlış yapılandırılmış readiness probe'lar yüzünden pod restart oranı artar; bu oran %5'in üzerine çıktığında sürdürülebilirlik sorunları başlar. Rollback süresi, deployment boyutuna göre 30 s - 10 dk arasında değişebilir.
| Kod | Belirti | Olası Neden | Ölçüm |
|---|---|---|---|
| ERR-001 | Pod Restart Spike | OOM / Yanlış limit | OOM count / saat, pod restart oranı (%) |
| NET-101 | Servis Gecikmesi | DNS gecikmesi / CNI MTU | p95 latency (ms), paket kaybı (%) |
| STO-210 | IOPS Düşüşü | Paylaşılan disk / yüksek snapshot | IOPS, disk latency (ms) |
Sorun çözümünde izlenecek yaklaşım fiziksel altyapıdan uygulama davranışına doğru sistematik olarak daraltılmalıdır. Aşağıdaki dört adımlık yöntem saha ekiplerimizde tekrar tekrar işe yaradı.
Bir üretim hattında yeni bir telemetri mikroservisi dağıtıldıktan sonra, veri toplama pencerelerinde %30 düşüş görüldü. İlk yanlış varsayım, imajın hatalı olduğu ve rollback gerektiği yönündeydi. Detaylı analiz log korelasyonu, node CPU throttling ve yüksek disk latency olduğunu gösterdi; root neden shared NFS üzerinde yoğun snapshot zamanlamasıydı.
Kalıcı çözüm olarak storage class değişikliği (local SSD) ve snapshot zamanlamasının üretim dışı saatlere alınması uygulandı; sonuç olarak telemetri başarı oranı %98'e yükseldi ve gecikmeler p95 seviyesinde %45 azaldı. Bu saha örneği, doğru ölçüm olmadan verilen aceleci kararların üretim maliyetini artırdığını gösteriyor.
Dayanıklılık, tekil düzeltmelerin ötesinde sürekli izleme ve düzenli tatbikatlarla sağlanır. KB Yazılım'da benimsediğimiz yaklaşım; ölçüm, analiz ve düzeltmenin döngüsel ve otomatik olmasıdır.
Ölçülmeyeni yönetemezsiniz; saha gözlemi, telemetri ve otomasyon üçgeni sistemlerin güvenilirliğini belirler.
Docker ve Kubernetes arasındaki farklar, teknoloji seçiminden çok operasyona yansıyacak davranış ve risklerin anlaşılmasıyla ilgilidir. Çok katmanlı bir yaklaşım; imaj doğruluğu, ağ stabilitesi, depolama performansı ve kaynak yönetimini aynı anda ele almayı gerektirir. Ölçüm ve izleme kültürü olmadan doğru mimari kararlar almak zordur.
KB Yazılım olarak saha odaklı, ölçülebilir metriklerle desteklenmiş ve otomasyona dayalı bir yaklaşım öneriyoruz; bu yöntem Türkiye'deki üretim tesislerinde saha müdahale sürelerini ortalama %40 azalttı ve deploy güvenliğini %60 iyileştirdi. Eğer bu konularda birlikte çalışmak isterseniz, ekiplerimiz sahadaki verilerinize dayalı pratik yol haritası çıkarmaya hazırdır.