Genel Bakış
Container Management, uygulamaların Docker gibi araçlarla paketlenen container imajları hâlinde çalıştırıldığı ortamların uçtan uca yönetilmesidir. Bu yönetim; imajların üretilmesi ve saklanmasından Kubernetes cluster'larının kurulmasına, dağıtım hatlarının işletilmesinden güvenlik politikalarının, kapasitenin ve sürüm yükseltmelerinin takibine kadar uzanır. Indexline'ın yönetilen servis modelinde platformun tasarımı, kurulumu ve günlük operasyonu tek bir sorumluluk altında toplanır; uygulama ekipleri ise kendi kodlarına ve iş hedeflerine odaklanabilir.
Container teknolojisinin önemi, uygulamanın çalıştığı ortamı kodla birlikte taşınabilir ve tekrarlanabilir hâle getirmesinden gelir. "Benim makinemde çalışıyordu" sorunu ortadan kalkar; geliştirme, test ve canlı ortamlar aynı imajla çalışır. Kubernetes bu imajları onlarca veya yüzlerce sunucu üzerinde orkestre ederek otomatik ölçekleme, kendi kendini onarma ve kesintisiz sürüm geçişi (rolling update) sağlar. Sonuç olarak dağıtım sıklığı artarken hata oranı ve geri dönüş süresi azalır.
Teknik ekosistem geniş ve hızlı değişen bir yapıdadır. Kubernetes yaklaşık dört ayda bir yeni minor sürüm yayınlar ve her sürüm sınırlı bir süre desteklenir; Kubernetes 1.24 ile dockershim'in kaldırılması gibi değişiklikler, node'larda containerd ve CRI-O gibi CRI uyumlu runtime'lara ya da cri-dockerd adaptörüne geçişi gerekli kılmıştır. Bunun yanında Helm, Argo CD ve Flux gibi dağıtım araçları; Calico ve Cilium gibi ağ eklentileri; Harbor gibi registry'ler ve Prometheus tabanlı izleme bileşenleri bir arada çalışır. Bu bileşenlerin uyumlu ve güncel tutulması başlı başına uzmanlık gerektirir.
Container platformunu kontrolsüz bırakmanın riskleri çoğu zaman sessizce birikir. Güncellenmemiş cluster'lar desteği biten sürümlerde kalır ve kritik güvenlik yamalarından mahrum olur. Zafiyet taramasından geçmeyen imajlar, aşırı yetkili service account'lar ve açık bırakılmış API uç noktaları saldırı yüzeyini genişletir. Kaynak limitleri tanımlanmayan iş yükleri birbirini etkileyerek beklenmedik kesintilere yol açar; atıl node'lar ve doğru boyutlandırılmamış pod'lar ise bulut faturasını gereksiz biçimde büyütür.
Indexline, container yönetimini tek seferlik bir kurulum projesi olarak değil, sürekli işletilen bir platform hizmeti olarak ele alır. Mevcut uygulama portföyü ve ekip olgunluğu değerlendirilerek on-premise, bulut veya hibrit ortamda doğru Kubernetes dağıtımı seçilir; GitOps, imaj güvenliği, gözlemlenebilirlik ve yedekleme baştan mimarinin parçası olarak tasarlanır. Devreye alma sonrasında 7/24 izleme, planlı sürüm yükseltmeleri, kapasite ve maliyet optimizasyonu ile düzenli raporlama SLA güvencesiyle sürdürülür.
Nasıl Çalışır?
Keşif ve Değerlendirme: Mevcut uygulamalar, Docker kullanımı, dağıtım süreçleri ve altyapı envanteri incelenir. Container'a uygunluk, bağımlılıklar ve ekip yetkinliği raporlanır.
Platform Mimarisi: On-premise, bulut veya hibrit hedefe göre Kubernetes dağıtımı, cluster topolojisi, ağ eklentisi, depolama sınıfları ve namespace stratejisi tasarlanır.
Cluster Kurulumu: Cluster'lar Terraform ve Ansible gibi IaC araçlarıyla tekrarlanabilir biçimde kurulur. Yüksek erişilebilir control plane, ingress ve sertifika yönetimi yapılandırılır.
İmaj ve Registry Yönetimi: Dockerfile'lar optimize edilir, çok aşamalı (multi-stage) build ve minimal base imaj kullanımı yaygınlaştırılır. Özel registry, zafiyet taraması ve imaj imzalama devreye alınır.
CI/CD ve GitOps: Uygulama ve altyapı tanımları Git deposunda tutulur. Helm veya Kustomize paketleri ile Argo CD ya da Flux üzerinden otomatik, denetlenebilir dağıtım hattı kurulur.
Güvenlik ve Politika: RBAC, Pod Security Standards, network policy, secret yönetimi ve Kyverno veya OPA Gatekeeper ile politika denetimi uygulanır. CIS Kubernetes Benchmark'a göre sıkılaştırma yapılır.
Gözlemlenebilirlik ve Yedekleme: Prometheus, Grafana ve merkezi log altyapısı ile cluster ve uygulama metrikleri izlenir. Velero ile cluster kaynakları ve kalıcı veriler düzenli olarak yedeklenir.
Yönetilen Operasyon: 7/24 izleme, olay müdahalesi, planlı Kubernetes sürüm yükseltmeleri, kapasite planlama ve aylık maliyet ve performans raporlaması SLA kapsamında yürütülür.
Temel Özellikler
Kubernetes Yaşam Döngüsü Yönetimi
Cluster kurulumu, node havuzu yönetimi, sertifika yenileme ve desteklenen sürümlere planlı yükseltme Indexline tarafından üstlenilir; desteği biten sürümde kalma riski ortadan kalkar.
GitOps Tabanlı Dağıtım
Argo CD veya Flux ile Git deposu tek doğruluk kaynağı olur. Her değişiklik izlenebilir, onaylanabilir ve tek adımda geri alınabilir.
İmaj Güvenliği ve Tedarik Zinciri
Trivy gibi araçlarla imaj zafiyet taraması, Harbor tabanlı özel registry ve Cosign ile imaj imzalama sayesinde yalnızca doğrulanmış imajlar canlıya ulaşır.
Politika ve Erişim Denetimi
RBAC, namespace izolasyonu, network policy ve Kyverno veya OPA Gatekeeper kurallarıyla güvenlik standartları otomatik olarak uygulanır.
Otomatik Ölçekleme
Horizontal Pod Autoscaler, Cluster Autoscaler ve olay tabanlı ölçekleme için KEDA ile kapasite talebe göre dinamik olarak ayarlanır.
Çoklu Cluster Yönetimi
Farklı ortam ve lokasyonlardaki cluster'lar Rancher gibi merkezi yönetim katmanlarıyla tek panelden yönetilir; politika ve erişim tutarlılığı sağlanır.
Gözlemlenebilirlik Paketi
Prometheus, Grafana, merkezi log toplama ve uyarı kuralları hazır gelir. Pod, node ve uygulama seviyesinde performans görünürlüğü sağlanır.
Yedekleme ve Felaket Kurtarma
Velero ile cluster kaynakları ve kalıcı birimler yedeklenir; farklı cluster veya lokasyona geri yükleme senaryoları düzenli olarak test edilir.
Faydalar ve Avantajlar
Dağıtım süreleri günlerden dakikalara iner; ekipler yeni özellikleri daha sık ve daha düşük riskle canlıya alır.
Geliştirme, test ve canlı ortamlar aynı imajla çalıştığından ortam farklılığından kaynaklanan hatalar azalır.
Kubernetes uzmanı istihdam etme ve elde tutma yükü ortadan kalkar; platform operasyonu SLA güvencesiyle yürütülür.
Planlı sürüm yükseltmeleri ve sürekli zafiyet taraması ile platform güncel ve güvenli kalır.
Doğru kaynak limitleri, right-sizing ve otomatik ölçekleme sayesinde altyapı maliyetleri kontrol altına alınır.
Kendi kendini onaran yapı ve kesintisiz sürüm geçişleri uygulama erişilebilirliğini artırır.
GitOps ile her değişiklik kayıt altına alınır; denetim, uyumluluk ve KVKK gereksinimleri için izlenebilirlik sağlanır.
Sektörel Kullanım Senaryoları
Finans / Bankacılık
Mobil bankacılık arka uç servisleri Kubernetes'e taşındı; GitOps ve imaj imzalama ile haftalık sürüm döngüsü günlük dağıtıma dönüştü, tüm değişiklikler denetim için kayıt altına alındı.
Perakende / E-Ticaret
Kampanya dönemlerinde HPA ve Cluster Autoscaler ile sepet ve ödeme servisleri otomatik ölçeklendi; yoğunluk sonrasında kapasite küçültülerek altyapı maliyeti yaklaşık %35 azaldı.
Sağlık
Hastane bilgi sistemine bağlı entegrasyon servisleri on-premise Kubernetes üzerinde container'laştırıldı; hasta verisi yurt içinde kalırken sürüm geçişleri kesintisiz hâle geldi.
Üretim
Fabrikalardaki uç (edge) sunucularda çalışan hafif Kubernetes cluster'ları merkezi panelden yönetilmeye başlandı; uygulama güncellemeleri tüm tesislere tek noktadan dağıtıldı.
Kamu
Vatandaş hizmet portalı mikroservis mimarisine geçirildi; CIS Benchmark sıkılaştırması ve network policy'ler ile güvenlik denetimlerinde bulgu sayısı belirgin biçimde azaldı.
Telekom
Onlarca cluster'dan oluşan dağınık yapı merkezi yönetime alındı; planlı sürüm yükseltmeleriyle desteği biten Kubernetes sürümü kalmadı, olay müdahale süresi yarıya indi.
Indexline Yaklaşımı
Container dönüşümünde en sık yapılan hata, her uygulamayı aynı anda ve aynı yöntemle Kubernetes'e taşımaya çalışmaktır. Indexline önce uygulama portföyünü değerlendirir; durumsuz (stateless) ve sık değişen servisler ilk dalgada taşınırken, ağır durum bilgisi taşıyan veya lisans kısıtı olan sistemler için ayrı bir yol haritası çizilir. Böylece erken kazanımlar hızla elde edilir ve ekipler yeni çalışma modeline kademeli olarak alışır.
Platformun kendisini bir ürün gibi ele alıyoruz. Uygulama ekiplerinin ihtiyaç duyduğu namespace, CI/CD şablonları, gözlemlenebilirlik ve güvenlik varsayılanları standart bir "altın yol" olarak sunulur. Geliştiriciler her seferinde altyapı detaylarıyla uğraşmak yerine onaylı şablonlarla self-service ilerler; platform ekibi ise tutarlılığı ve güvenliği merkezi olarak korur. Bu model, ekip ve uygulama sayısı arttığında bile platformun dağınıklaşmasını önler ve yeni bir servisin canlıya alınma süresini belirgin biçimde kısaltır.
Güvenlik, sonradan eklenen bir katman değil, tasarımın başlangıç noktasıdır. İmaj kaynağından dağıtıma kadar tedarik zinciri doğrulanır, en az yetki ilkesine göre RBAC tanımlanır, pod'lar arası trafik network policy ile sınırlandırılır ve secret'lar harici kasalarda tutulur. Bu yaklaşım Zero Trust prensipleriyle uyumludur ve KVKK gibi mevzuat gereksinimleri için ihtiyaç duyulan denetim kanıtlarının üretilmesini kolaylaştırır.
Kubernetes ekosisteminin hızlı sürüm döngüsü, yönetilen servis modelinin en kritik değer noktasıdır. Indexline sürüm yükseltmelerini önce test cluster'larında doğrular, kullanımdan kaldırılan API'leri önceden tespit eder ve canlı ortam geçişlerini planlı bakım pencerelerinde, geri dönüş planıyla gerçekleştirir. Ingress controller, ağ eklentisi ve izleme bileşenleri gibi eklentilerin yeni sürümle uyumluluğu da aynı döngüde kontrol edilir. Böylece platform hem güncel hem de öngörülebilir kalır.
Son olarak container platformunun değeri ölçülebilir olmalıdır. Dağıtım sıklığı, değişiklik başarısızlık oranı, ortalama onarım süresi ve kaynak kullanım verimliliği gibi metrikler düzenli olarak raporlanır. Aylık değerlendirmelerde maliyet, kapasite ve güvenlik bulguları birlikte ele alınarak platform, iş hedefleriyle hizalı biçimde sürekli iyileştirilir.
Sık Sorulan Sorular
Docker ile Kubernetes arasındaki fark nedir?
Docker, uygulamayı bağımlılıklarıyla birlikte container imajı olarak paketlemeye ve tek bir sunucuda çalıştırmaya yarar. Kubernetes ise bu container'ları birden fazla sunucu üzerinde orkestre eder; zamanlama, ölçekleme, servis keşfi, kendi kendini onarma ve sürüm geçişlerini yönetir. Docker ile üretilen imajlar Kubernetes üzerinde sorunsuz çalışır.
Kubernetes 1.24 sonrası Docker imajlarımız çalışmaya devam eder mi?
Evet. Kubernetes 1.24 ile kaldırılan dockershim, Docker Engine'in runtime olarak doğrudan kullanılmasını sağlayan ara katmandı. Docker ile oluşturulan imajlar OCI standardına uygun olduğundan containerd veya CRI-O üzerinde aynı şekilde çalışır. Değişiklik esas olarak node seviyesindeki runtime yapılandırmasını etkiler; Docker soketine doğrudan bağlanan izleme veya build araçları varsa bunların da gözden geçirilmesi gerekir.
Yönetilen Kubernetes mi, kendi kurulumumuz mu tercih edilmeli?
Bulut sağlayıcıların EKS, AKS veya GKE gibi servisleri control plane yönetimini üstlenir ve hızlı başlangıç sağlar. Veri yerelleştirme, maliyet veya donanım kontrolü gereken durumlarda on-premise dağıtımlar daha uygundur. Indexline her iki modelde de cluster operasyonunu, güvenliği ve uygulama dağıtımlarını yönetebilir; seçim iş yükü ve mevzuat gereksinimlerine göre birlikte yapılır.
Kubernetes sürüm yükseltmeleri ne sıklıkla yapılmalı?
Kubernetes yaklaşık dört ayda bir yeni minor sürüm yayınlar ve her sürüm yaklaşık 14 ay yama desteği alır. Bu nedenle cluster'ların yılda en az bir veya iki kez yükseltilmesi gerekir. Yükseltmeler minor sürümleri atlamadan sırayla yapılmalı, kaldırılan API'ler önceden tespit edilmeli ve önce test ortamında doğrulanmalıdır.
Veritabanlarını container içinde çalıştırmak doğru mu?
StatefulSet, kalıcı birimler ve operator'ler sayesinde veritabanları Kubernetes üzerinde çalıştırılabilir; ancak bu, depolama performansı, yedekleme ve operasyon olgunluğu gerektirir. Kritik ve yüksek hacimli veritabanları için çoğu zaman yönetilen veritabanı servisi veya ayrı sunucular daha pratiktir. Karar iş yükü özelinde değerlendirilir.
Container güvenliği nasıl sağlanıyor?
Güvenlik katmanlı olarak ele alınır: minimal base imajlar ve zafiyet taraması, imaj imzalama, root olmayan kullanıcıyla çalışma, Pod Security Standards, RBAC, network policy ve harici secret yönetimi. Çalışma zamanında Falco gibi araçlarla şüpheli davranışlar tespit edilir ve loglar SIEM'e aktarılabilir.
Mevcut uygulamalarımızı yeniden yazmamız gerekir mi?
Her zaman gerekmez. Birçok uygulama kodda küçük değişikliklerle container'laştırılabilir; yapılandırmanın ortam değişkenlerine taşınması ve logların standart çıktıya yazılması gibi adımlar çoğu zaman yeterlidir. Monolitik uygulamalar önce olduğu gibi taşınabilir, ardından ihtiyaç duyulan bölümler kademeli olarak mikroservislere ayrılabilir.
Hizmet kapsamında sorumluluklar nasıl paylaşılıyor?
Indexline platform katmanını; cluster sağlığını, sürüm yükseltmelerini, güvenlik politikalarını, izleme ve yedeklemeyi SLA kapsamında üstlenir. Uygulama kodu ve iş mantığı müşteri ekiplerinde kalır. Sorumluluk sınırları ve eskalasyon adımları başlangıçta RACI matrisi ile netleştirilir.