Container Image, Runtime ve Kubernetes Temelleri

Ön koşul: Linux process, filesystem, network, identity, cgroups, SELinux ve workload placement kavramlarını açıklayabilmelisin. Bu dersin sonunda image, registry, runtime, container, Pod, controller, Service, configuration, secret ve persistent storage sınırlarını ayıracak; build’den production’a provenance, security, resource ve lifecycle kanıtı kuracak; Arven uygulaması için container uygunluğu, Kubernetes gereksinimi, POC, risk/TBD ve yeniden açma koşulu üreteceksin. Yaklaşık 32 dakika anlatı ve örnek, 18 dakika uygulama, 12 dakika bilgi kontrolleridir.

Container image çalışan process değildir; uygulama binary’si, runtime dependency, filesystem katmanları, config varsayılanları ve metadata içeren değişmez bir dağıtım artefact’ıdır. OCI Image Specification manifest, config, layer ve digest ilişkisini; Distribution Specification registry ile taşıma davranışını; Runtime Specification unpack edilmiş bundle’ın çalıştırılma sınırını tanımlar. Uyumlu format taşınabilirliği artırır fakat kernel, architecture, driver, network, storage ve managed platform davranışının aynı olduğunu kanıtlamaz. Tag değişebilir; digest içerik adresli kimlik sağlar. Production manifest’i image digest’e sabitlenir, build kaynağı ve commit ile ilişkilendirilir. Base image kaynağı, package listesi, SBOM, licence, vulnerability sonucu, signature/attestation, build runner ve promotion kaydı supply chain kanıtıdır. Aynı source’tan yeniden build her zaman bit düzeyinde aynı sonucu vermeyebilir; kilitli dependency, hermetic build ve reproducibility beklentisi açık yazılır. Registry availability, immutability, replication, retention, garbage collection, access, audit ve recovery ayrıca tasarlanır. Image içine secret, private key, ortam özel endpoint veya değişken veri gömülmez. Minimal image attack surface’i azaltabilir; debug araçlarının yokluğu için ephemeral debug ve runbook gerekir. CVE varlığı otomatik iş etkisi değildir; reachability, exploitability, mevcut kontrol ve SLA ile önceliklendirilir. Ancak “çalışıyor” gerekçesiyle patch borcu belirsiz bırakılamaz. Build, scan, sign, promote, deploy ve revoke kapıları ayrı yetki ve kayıt taşır.

Container, host kernel üzerinde izole edilmiş process grubudur; sanal makine gibi ayrı kernel sağlamaz. Namespace process, mount, network, IPC ve kullanıcı görünümünü; cgroups kaynak hesabı ve sınırını; capability, seccomp, SELinux/AppArmor ve filesystem izinleri erişim alanını daraltır. Bu katmanlar defence-in-depth oluşturur. Privileged çalışma, host namespace, geniş capability, hostPath veya container socket erişimi izolasyon sınırını ciddi biçimde büyütür ve istisna kanıtı gerektirir. Runtime image’ı çeker, doğrular, unpack eder ve process’i oluşturur; Kubernetes ortamında kubelet CRI üzerinden runtime ile konuşur. Container engine, low-level OCI runtime ve orchestrator aynı bileşen değildir. Rootless çalışma host üzerindeki yetkiyi azaltır; kullanıcı namespace ve subordinate ID davranışı network, port ve volume erişimini etkileyebilir. Rootless etiketi uygulamanın içeride root UID kullanmadığını veya tüm saldırı yollarının kapandığını tek başına kanıtlamaz. Container writable layer geçicidir. Logu yalnız dosyaya, state’i container katmanına yazmak restart ve reschedule sonrasında kayba yol açar. Config ve secret image’dan ayrılır; secret’ın API, etcd, node, environment, volume, log ve backup izleri değerlendirilir. CPU request/limit, memory request/limit, ephemeral storage ve process/file limitleri gerçek load testine dayanır. Memory limit aşımı OOM kill; aşırı düşük CPU limiti throttling ve latency üretir. Host kernel, runtime, node OS ve registry patch sorumluluğu container kullanınca kaybolmaz.

Kubernetes container çalıştırmanın ötesinde desired state ve reconciliation sunar. Pod en küçük deploy edilebilir birimdir; içindeki container’lar aynı node’da birlikte schedule edilir ve network/storage context paylaşır. Pod kalıcı sunucu kimliği değildir; controller arızalı Pod yerine yenisini oluşturur. Deployment çoğunlukla stateless replica ve rollout; StatefulSet kararlı identity/order ve storage ilişkisi; DaemonSet node başına workload; Job tamamlanan iş için kullanılır. Controller seçimi uygulamanın state ve lifecycle davranışına dayanır. Service değişen Pod’lara kararlı erişim ve load distribution sağlar; Ingress/Gateway dış HTTP yönlendirmesini, NetworkPolicy izinli trafik sınırını ele alır. Bunlar DNS, CNI, load balancer, certificate ve firewall dependency’lerini ortadan kaldırmaz. ConfigMap hassas olmayan config; Secret hassas veri taşır, fakat encryption, RBAC, rotation ve kullanım izi ayrıca doğrulanır. PersistentVolume/PVC storage talebini bağlar; access mode, topology, latency, snapshot, backup, restore, expansion ve reclaim davranışı veri hizmeti sözleşmesidir. Scheduler request, affinity, taint/toleration, topology ve policy ile node seçer; gerçek capacity ve failure domain sonucu ayrıca ölçülür. Readiness başarısızsa Pod Service trafiğinden çıkar; liveness başarısızlığı restart tetikleyebilir; startup probe yavaş başlangıcı korur. Yanlış liveness bağımlılık arızasında restart fırtınası yaratabilir. Graceful termination, preStop, termination grace, disruption budget, replica/topology spread ve rollout stratejisi birlikte test edilir. Control plane sağlığı ile mevcut data plane ve yeni scheduling/değişiklik yeteneği ayrı değerlendirilir.

Arven sipariş API’sini container’a almayı değerlendirir. Uygulama iki Linux node’da çalışır; release kurulumu kırılgan, dependency sürümleri farklı ve kampanya ölçeği değişkendir. Container image tekrarlanabilir artefact ve hızlı rollout sağlayabilir. Ancak uygulama local session/file tutuyor, batch aynı database’e yoğun bağlanıyor, certificate elle yenileniyor ve ekip Kubernetes işletmemiştir. “Container’a aldık” bu borçları çözmez; state, health, secret, resource ve operasyon sözleşmeleri yeniden tasarlanır. Üç seçenek karşılaştırılır: systemd altında OCI container ile tek/az node; yönetilen veya kurum içi Kubernetes; mevcut VM hizmetini iyileştirme. Kubernetes ancak replica scheduling, self-healing, rollout, policy ve ortak platform değeri operasyon maliyetini aşıyorsa seçilir. Tek servis için cluster; control plane, node pool, CNI, CSI, registry, ingress, certificate, observability, backup, upgrade, security ve on-call sorumluluğu getirir. POC source-to-image provenance, digest/signature, non-root/read-only çalışma, secret rotation, resource pressure, probe ayrımı, graceful termination, rollback, node kaybı, registry kesintisi, persistent state, network policy ve log/metric correlation ölçer. Koşullu öneri; session dışsallaştırılır, local file kaldırılır, one-node/zone adverse capacity doğrulanır, supply chain kapıları çalışır, ekip RACI/runbook/on-call kazanır ve üç yıllık TCO kabul edilirse Kubernetes’tir. Aksi halde OCI container plus systemd veya iyileştirilmiş VM daha düşük karmaşıklıkla hedefi karşılayabilir. State modeli, replica ihtiyacı, regülasyon, platform paylaşımı veya ekip kabiliyeti değişirse karar yeniden açılır.