Container Platform Çözümleri: Kurumsal Ortamda Konteyner Teknolojisini Doğru Kurmak

Konteyner teknolojisi artık yeni bir kavram değil. Pek çok ekip Docker’ı yıllardır kullanıyor, bazı uygulamalar çoktan Kubernetes üzerine taşındı. Ama “konteynerleri kullanmak” ile “konteyner platformunu kurumsal düzeyde işletmek” arasında ciddi bir mesafe var.

Bu mesafeyi net görmek için birkaç soruyu yanıtlamak gerekiyor: Konteynerlerin üretim ortamında izolasyonu kim garanti ediyor? Registry’deki imajların güvenliği nasıl denetleniyor? Geliştirici dizüstünden production cluster’a kadar konfigürasyon tutarlılığı nasıl sağlanıyor? Cevaplar çoğu zaman net değil; işler o zaman zorlaşıyor.

Bu yazıda konteyner platformlarının teknik katmanlarını, yaygın sorunları ve kurumsal ortamda sağlam bir yapı kurmanın ne anlama geldiğini ele alıyoruz.

Konteyner Nedir, Sanal Makineden Farkı Nerede?

Klasik bir soruyla başlayalım çünkü ikisi hala sıkça karıştırılıyor. Sanal makine, hypervisor üzerinde tam bir işletim sistemi kopyası çalıştırır. Her VM’in kendi kernel’ı, kendi bellek alanı ve kendi disk imajı vardır. Bu güçlü bir izolasyon sağlar ama ağır bir yük getirir.

Konteyner ise host işletim sisteminin kernel’ını paylaşır. İzolasyon, Linux’un iki temel mekanizması üzerine kurulu: namespace’ler ve cgroup’lar. Namespace’ler süreçlerin birbirini görmemesini sağlar, cgroup’lar ise CPU, bellek ve disk I/O kaynaklarını sınırlar.

Tabloya bakarak “o zaman her şeyi konteynere taşıyalım” sonucuna atlamak doğru değil. Sanal makinelerin güçlü güvenlik izolasyonu gerektiren workload’lar için hala geçerli bir yeri var. Doğru soru hangisinin daha iyi olduğu değil, hangisinin hangi iş yükü için uygun olduğu.

OCI Standartı: Temel Kavramları Netleştirmek

Konteyner dünyasında terminoloji karmaşası büyük. Docker, Podman, containerd, CRI-O kelimeler birbirine karışıyor. Bunları anlamak için önce Open Container Initiative (OCI) standartını bilmek gerekiyor.

OCI, Linux Foundation bünyesinde yönetilen ve konteyner imajı ile çalıştırma ortamını tanımlayan açık bir standarttır. İki temel spesifikasyon içeriyor:

• Image Spec: Konteyner imajının katmanlar halinde nasıl paketleneceğini tanımlıyor
• Runtime Spec: Çalışma zamanının konteyneri nasıl başlatacağını, durdurur ve sileceğini tanımlıyor

Bu standart sayesinde Docker ile build edilen bir imaj, Podman ile de çalışıyor. OpenShift’te koşan uygulama, standart bir Kubernetes cluster’ında da aynı şekilde çalışıyor. Vendor lock-in riskini azaltan şey büyük ölçüde bu ortak dil.

İlginizi Çekebilir: Yapay Zekâ Gelişmeleri ve OpenShift AI Platform

Container Runtime: runc, crun ve gVisor

Konteyner çalıştırma işini aslında düşük seviyeli bir runtime üstleniyor. En yaygın olanı runc; OCI runtime spesifikasyonunun referans implementasyonu. Ama hepsi bu kadar değil:

• crun: C ile yazılmış, runc’a göre daha hızlı başlangıç süresi ve daha düşük bellek kullanımı sunuyor
• gVisor (runsc): Google’ın geliştirdiği, kullanıcı alanında çalışan bir kernel katmanı ekleyen sandbox runtime. Host kernel’a erişimi sınırlıyor, güvenlik izolasyonunu güçlendiriyor
• Kata Containers: Her konteyneri hafif bir sanal makine içinde çalıştırıyor; hem konteyner esnekliğini hem VM güvenliğini hedefliyor

Kurumsal güvenlik gereksinimi yüksek ortamlarda gVisor ya da Kata Containers tercih edilebiliyor. OpenShift, RuntimeClass mekanizmasıyla farklı workload’lar için farklı runtime’lar kullanmaya izin veriyor.

Podman: Daemon’sız Konteyner Yönetimi

Docker’ın en bilinen mimari özelliği daemon tabanlı çalışması. Tüm konteyner operasyonları root yetkisiyle çalışan dockerd üzerinden geçiyor. Bu, geliştiriciler için pratik ama kurumsal güvenlik açısından sorunlu bir tasarım.

Podman bu yaklaşımı tersine çeviriyor. Bir daemon yok; her komut doğrudan ilgili sistem çağrısını yapıyor. Daha da önemlisi, Podman rootless modda çalışabiliyor: konteyner, normal bir kullanıcı yetkileriyle başlatılıyor ve host’ta root erişimi olmayan bir süreç olarak koşuyor.

Rootless Konteyner ve User Namespace

Rootless Podman, Linux user namespace’lerini kullanıyor. Konteyner içinde root gibi görünen UID 0, aslında host üzerinde yetkisiz bir kullanıcıya eşleniyor. Bunu doğrulamak için basit bir test:

Bu ayrım kritik. Konteynerden bir şekilde kaçılsa bile saldırgan host üzerinde yetkisiz bir kullanıcı oluyor; root erişimi elde edemiyor.

Podman ve Systemd Entegrasyonu

Podman’ın bir diğer kurumsal avantajı systemd ile doğal entegrasyonu. Podman generate systemd komutu, bir konteyner için systemd servis dosyası üretiyor. Bu sayede konteynerler sistem servisleri gibi yönetiliyor: otomatik başlangıç, yeniden başlatma politikaları ve servis bağımlılıkları standart systemd mekanizmalarıyla tanımlanabiliyor.

İmaj Güvenliği: Registry’den Production’a Güven Zinciri

Konteyner güvenliğinin en kritik ama en az konuşulan boyutu imaj güvenirliliği. Bir uygulama production’da çalışırken aslında o imajın içindeki her şey de çalışıyor: base OS katmanları, kütüphaneler, bağımlılıklar. Bunların herhangi birinde bir CVE varsa uygulama da etkileniyor.

İmaj Tarama ve CVE Yönetimi

Red Hat’in container catalog’unda yayımlanan imajlar, Clair tarama motoru kullanılarak sürekli analiz ediliyor. Her imaj katmanındaki paketler bilinen CVE veritabanlarıyla karşılaştırılıyor ve Health Index skoru atanıyor. Bu skoru düşüren bir güvenlik açığı çıktığında Red Hat, base imajı güncelleyip yeni bir build yayınlıyor.

Kurumsal ortamda bu mekanizmanın çalışması için iki şeyin doğru kurgulanmış olması gerekiyor: uygulamaların güncellenmiş base imajları otomatik olarak yakalaması ve registry’e gönderilen her imajın taramadan geçmesi. İkincisini sağlamak için Quay.io ya da on-premise kurulan Red Hat Quay tercih ediliyor.

İmaj İmzalama ve Sigstore

İmaj tarama yeterli değil; imajın değiştirilmediğini de doğrulamak gerekiyor. Sigstore projesi (cosign aracı), imajları kriptografik olarak imzalamayı ve bu imzaları OCI registry’de saklamayı mümkün kılıyor:

OpenShift, cluster genelinde imza doğrulamayı Image Policy mekanizmasıyla zorunlu kılabiliyor. İmzalanmamış ya da güvenilmeyen kaynaktan gelen imajlar cluster’da çalıştırılamıyor.

İlginizi Çekebilir: Modern Veri Merkezlerinde Görünürlük: Cisco MDS SAN Analytics ile Tanışın

OpenShift Container Platform: Kurumsal Yapı Taşları

OpenShift’i sıradan Kubernetes’ten ayıran şeyler teoride değil pratikte ortaya çıkıyor. Aynı YAML’ı OpenShift’e uygulamak çoğu zaman vanilla Kubernetes’e göre daha kısıtlayıcı bir deneyim sunuyor. Bu kısıtlamalar güvenlik sertleştirmesinin bir parçası.

Security Context Constraints

Kubernetes’te PodSecurityPolicy (kaldırıldı) ya da Pod Security Admission ile yapılan kısıtlamalar OpenShift’te Security Context Constraints (SCC) ile yönetiliyor. SCC, bir pod’un hangi yetkilere sahip olabileceğini tanımlıyor:

Bu SCC, root olarak çalışmayı, host network’e erişimi ve host PID namespace’ini tamamen engelliyor. Pod bu kısıtlamaların dışına çıkmaya çalışırsa admission controller tarafından reddediliyor; scheduler’a bile ulaşamıyor.

Build Süreçleri: Source-to-Image

OpenShift’in geliştirici deneyimini farklılaştıran özelliklerden biri Source-to-Image (S2I). Geliştirici sadece uygulama kaynak kodunu gönderiyor; S2I uygun builder imajını seçiyor, derlemeyi yapıyor ve çalıştırılabilir bir konteyner imajı üretiyor. Dockerfile yazmak gerekmiyor.

S2I’ın kurumsal avantajı sadece kolaylık değil. Builder imajlarını merkezi olarak sertifikalı versiyon olarak yönetebiliyorsunuz. Tüm Python uygulamalarının aynı sertifikalı Python runtime’ı üzerine build olduğunu garanti etmek, güvenlik açısından önemli bir kontrol noktası.

Operator Framework ile Uygulama Yaşam Döngüsü

Kubernetes’te stateful uygulamaları yönetmek zordur. Veritabanları, mesaj kuyrukları ve dağıtık sistemler, deployment’ın çok ötesinde operasyonel bilgi gerektirir: yedekleme, yük devretme, sürüm yükseltme, shard yönetimi. Operator Framework bu operasyonel bilgiyi kod olarak kapsülüyor.

Bir Operator, sürekli çalışan bir kontrolör döngüsüdür. Kümenin gerçek durumunu istenen durumla karşılaştırır ve fark varsa düzeltici aksiyon alır. Örneğin PostgreSQL Operator, primary node çöktüğünde bir replica’yı otomatik olarak primary’ye terfi ettirir ve bağlantı havuzunu günceller.

Bu tanımla birlikte 3 node’lu, günlük incremental ve haftalık full yedeklemeli bir PostgreSQL cluster’ı kuruluyor. Operator gerisini hallediyor.

İlginizi Çekebilir: Red Hat OpenShift: Kubernetes’ten Kurumsal Platforma Geçiş Rehberi

Konteyner Ortamında Gözlemlenebilirlik

On yıl önce bir sunucunun sorun yaşadığını anlamak görece kolaydı: tek bir makineye bakıyordunuz. Konteyner ortamında ise onlarca, yüzlerce pod aynı anda çalışıyor. Bir sorun yaşandığında hangi pod, hangi node, hangi versiyon, hangi commit sorularını hızla yanıtlayabilmek gerekiyor. Bunu mümkün kılan gözlemlenebilirlik üç sütun üzerine kurulu.

Metrikler: Prometheus ve Alertmanager

OpenShift, cluster metriklerini Prometheus ile topluyor. Platform metrikleri (node CPU/bellek, etcd gecikme, API server istek oranı) built-in geliyor; uygulama metrikleri ise ServiceMonitor nesnesiyle Prometheus’a tanıtılıyor:

Alertmanager, tanımlanan eşikler aşıldığında PagerDuty, Slack ya da e-posta gibi kanallara bildirim gönderiyor. Kritik alertlerin gecede ekibi uyandırmaması için inhibition kuralları ve routing politikaları doğru yapılandırılması gerekiyor; bu kurguyu baştan düzgün yapmak ilerleyen dönemde çok vakit kazandırıyor.

Loglar: Loki ve OpenShift Logging

OpenShift Logging stack’i, cluster’daki tüm pod loglarını topluyor, yapılandırıyor ve sorgulanabilir hale getiriyor. Güncel kurulumlar Elasticsearch yerine Loki’yi tercih ediyor. Loki, logları indekslemek yerine etiketlere göre gruplayan bir yaklaşım kullanıyor; bu sayede depolama maliyeti düşüyor ve büyük ölçekte performans artıyor.

Uygulamaların structured log (JSON formatında) yazması, Loki sorgularının çok daha verimli çalışmasını sağlıyor. Düz metin log yazan uygulamalarda regex tabanlı sorgular yazmak zorunda kalıyorsunuz; bu hem yavaş hem de bakımı zor.

Distributed Tracing: Tempo ve OpenTelemetry

Bir HTTP isteği on farklı mikroservisten geçiyorsa ve 800ms sürüyorsa, bu sürenin hangi serviste harcandığını log’lardan anlamak neredeyse imkansız. Distributed tracing tam bu sorunu çözüyor.

OpenTelemetry, uygulama koduna eklenen bir enstrümentasyon kütüphanesiyle her isteği trace ID ile etiketliyor ve her servis atlamasını span olarak kaydediyor. Bu veriler Tempo’ya gönderiliyor ve Grafana üzerinden görselleştiriliyor. Bottleneck olan servis tek bakışta görünür hale geliyor.

Sekom’un Container Platform Yaklaşımı

Konteyner platformu projelerinin büyük kısmı ilk kurulumda başarıyla tamamlanıyor. Asıl zorluk 6-12 ay sonra ortaya çıkıyor: cluster büyüdükçe operasyon karmaşıklaşıyor, güvenlik açıkları birikiyor, etcd büyüyor, sertifikalar yenilenmesi gerekiyor.

Sekom, bu gerçeği bilerek projelere yaklaşıyor. Teknik mimari kadar Day-2 operasyon modeli de kapsam dahilinde.

İmaj Fabrikası Kurulumu: Her kurumun ihtiyacına özel bir “imaj fabrikası” kurgulanıyor. Sertifikalı base imajlar merkezi Quay registry’de yönetiliyor, her build otomatik taramadan geçiyor ve imzalanıyor. Geliştirici ekipler bu fabrikadan onaylı imajları kullanıyor.

Platform Mühendisliği: Geliştiricilerin Kubernetes detaylarıyla uğraşmadan uygulama deploy edebileceği self-servis mekanizmaları kuruluyor. Namespace otomasyonu, kaynak kota yönetimi ve network policy şablonları bu kapsamda ele alınıyor.

Güvenlik Sertleştirme: CIS Benchmark ve DISA STIG referans alınarak cluster sertleştirme yapılıyor. SCC politikaları, admission webhook’lar ve network policy matrisi kurumun risk iştahına göre konfigüre ediliyor.

Kapasite Yönetimi: Cluster’ın ne zaman ölçeklenmesi gerektiğini önceden görmek, reaktif büyümeden çok daha az maliyetli. Vertical Pod Autoscaler önerileri ve Cluster Autoscaler konfigürasyonu bu çalışmanın bir parçası.

Konteyner platformu kurmak, Kubernetes ya da OpenShift kurmakla eş anlamlı değil. Güvenli imaj zinciri, doğru runtime seçimi, işlevsel gözlemlenebilirlik stack’i ve sürdürülebilir bir operasyon modeli olmadan platform zamanla borca dönüşüyor.

İyi haber şu: bunların hepsi çözülmüş problemler. Doğru araç seçimi ve mimarisi ile kurumsal konteyner platformu güvenilir, ölçeklenebilir ve yönetilebilir bir yapıya kavuşuyor.

Mevcut altyapınızı optimize etmek, mimari eksikleri gidermek veya yeni bir konteyner platformu projesini hayata geçirmek için Sekom’un uzman teknik ekibiyle hemen iletişime geçebilirsiniz. Güçlü Red Hat iş ortaklığımız, köklü bilgi birikimimiz ve başarı hikayelerimizle modernizasyon yolculuğunuzda yanınızdayız.