Kubernetes Nedir? Üretim Kümesi, Güvenlik ve İşletim Rehberi

Control plane, worker node ve uygulama kaynakları aynı istenen durum modelinde çalışır

Bir Kubernetes kümesinde API server bütün yönetim isteklerinin giriş noktasıdır. Scheduler henüz düğüme atanmamış pod'lar için CPU, bellek, kısıt ve yerleşim koşullarını değerlendirir; controller manager kaynakların istenen sayıda ve durumda kalmasını gözetir. Küme durumu ve yapılandırma verisi etcd içinde tutulduğu için etcd erişilebilirliği, yedeği ve geri dönüş prosedürü control plane sürekliliğinin temel parçalarıdır. Worker node üzerinde kubelet pod tanımlarını uygular, container runtime iş yüklerini çalıştırır ve ağ eklentisi pod iletişimini sağlar. Deployment stateless uygulamalarda kopya sayısı ile kontrollü sürüm geçişini, StatefulSet kararlı kimlik ve depolama ilişkisini, DaemonSet ise her uygun düğümde çalışması gereken ajanları yönetir. Bu kaynakların doğru seçilmesi yalnızca YAML söz dizimi değil, uygulamanın durum, başlatma sırası, kapanma ve veri davranışını anlamayı gerektirir.

Pod'lar geçicidir; yeniden oluşturulduklarında IP ve çalıştıkları node değişebilir. Service, seçici etiketlerle sağlıklı pod grubuna kararlı bir sanal erişim noktası sunar. Dış trafik Ingress veya Gateway API gibi bir giriş katmanıyla yönlendirilebilir; hangi bileşenin TLS sonlandırdığı, kimlik doğruladığı, hız sınırladığı ve log tuttuğu açık olmalıdır. CoreDNS, container registry, sertifika otoritesi, zaman kaynağı, yük dengeleyici ve depolama sistemi görünmeyen ama kritik bağımlılıklardır. Tek bir uygulama sayfası açılıyor diye küme sağlıklı kabul edilmez; API, DNS, ağ, storage ve kontrol döngülerinin her biri ayrı izlenir. Kaynak tanımlarında uygulama sahibi, namespace, sürüm, image kaynağı, port, health probe, kaynak isteği ve limiti, secret bağımlılığı, kalıcı volume ve dış hizmetler belgelenir. Böylece sorun çıktığında pod'u yeniden başlatmak yerine hangi kontrol katmanının hedef durumdan saptığı anlaşılır.

Küme topolojisi

Control plane, worker, etcd, yük dengeleyici, DNS, registry, ağ eklentisi ve depolama bileşenleri fiziksel ve mantıksal bağımlılıklarıyla çizilir.

İş yükü türü

Deployment, StatefulSet, DaemonSet, Job ve CronJob seçimi uygulamanın durum, zamanlama, ölçek ve kapanma davranışına göre yapılır.

Servis erişimi

Service, Ingress veya Gateway, TLS sonlandırma, DNS, dış IP ve firewall akışı tek rota üzerinde doğrulanır.

Kaynak tanımı

CPU ve bellek isteği/limiti, probe, image, port, secret, volume, affinity ve kesinti bütçesi uygulama sahibiyle belirlenir.

Platform bağımlılığı

API, etcd, CoreDNS, registry, sertifika, NTP, depolama ve dış kimlik hizmetlerinin arıza davranışı belgelenir.

Kubernetes kararı uygulama portföyü, ekip modeli ve toplam işletim yüküyle verilmelidir

Kubernetes en çok bağımsız sürümlenen birden fazla servis, otomatik yerleştirme, yatay ölçek, sık dağıtım ve standart platform ihtiyacı olduğunda değer üretir. Buna karşılık tek parça uygulama, sabit yük, özel donanıma sıkı bağlı yazılım veya container desteği zayıf ticari ürünlerde taşınma maliyeti faydayı aşabilir. İlk analizde uygulamanın stateless ve stateful bileşenleri, veritabanı konumu, yerel dosya kullanımı, lisans bağımlılığı, ağ portları, kesinti toleransı, sürüm yöntemi ve gözlemleme gereksinimi çıkarılır. Container imajına alınabilmek uygulamanın Kubernetes'e hazır olduğu anlamına gelmez; health endpoint, kontrollü kapanma, dış yapılandırma, yatay kopya ve kalıcı veri davranışı da uyumlu olmalıdır. Pilot, en kritik sistemle değil temsil gücü yüksek fakat geri dönüşü kolay bir uygulamayla başlatılır. Başarı ölçütü yalnızca pod'un çalışması değil dağıtım süresi, hata oranı, kaynak kullanımı, geri dönüş, güvenlik ve işletim çabasındaki değişimdir.

On-premises küme donanım, ağ, depolama, control plane, sertifika, yama ve kapasite sorumluluğunu kuruma verir. Yönetilen Kubernetes hizmeti control plane işlerinin bir kısmını sağlayıcıya bırakabilir; buna karşın bulut ağı, kimlik, maliyet, veri konumu ve sağlayıcıya özgü bileşenler yine tasarlanmalıdır. Küme sayısı da önemlidir: geliştirme, test ve üretimi tek kümede yalnız namespace ile ayırmak belirli riskleri paylaşır; her ortam için ayrı küme ise maliyet ve yönetim yükünü artırır. Multi-tenant yapılarda veri ve ekip sınırları, kaynak kotası, ağ politikası, secret yönetimi ve yönetici yetkisi birlikte değerlendirilir. Maliyet hesabı yalnız node fiyatından oluşmaz; yedek kapasite, storage IOPS, veri transferi, log/metric saklama, güvenlik araçları, lisans, destek, nöbet ve yükseltme süresi de eklenir. Platform sahibi, uygulama ekibi ve güvenlik ekibinin sorumluluk matrisi kurulmadan teknik standartlar sürdürülebilir hale gelmez.

• Uygulama sayısı, sürüm sıklığı, yatay ölçek ihtiyacı, stateful bileşenler, lisanslar ve kesinti hedeflerini tek portföy tablosunda değerlendirin.
• On-premises, yönetilen hizmet ve hibrit seçeneklerini kontrol düzlemi, veri konumu, ağ, kimlik, maliyet ve işletim sorumluluğuyla karşılaştırın.
• Geliştirme, test ve üretim ayrımında ortak hata alanı, yetki sınırı, maliyet ve operasyon kapasitesini birlikte tartın.
• İlk pilotu temsil gücü yüksek fakat geri dönüşü kolay iş yüküyle yapın; dağıtım, geri alma, arıza ve güvenlik senaryolarını ölçün.
• Platform, uygulama, network, güvenlik ve yedekleme ekiplerinin sahipliklerini RACI benzeri açık bir sorumluluk tablosuna bağlayın.

RBAC, ağ politikası ve yazılım tedarik zinciri küme güvenliğinin birlikte çalışan katmanlarıdır

Kubernetes API'sine erişim güçlü kimlik doğrulama ve en az yetki ilkesiyle yönetilir. Kullanıcılara ve service account'lara mümkün olduğunda namespace düzeyinde RoleBinding verilir; geniş ClusterRoleBinding hakları gerekçe ve süre olmadan kullanılmaz. Varsayılan service account her pod için otomatik yetkili kabul edilmez. Yönetici işlemleri kişisel hesap, MFA destekli kimlik ve kayıtlı oturumla yapılır; acil durum yetkisi ayrı prosedüre bağlanır. Secret nesnesi bir erişim kontrol katmanıdır fakat varsayılan olarak güvenli kasa yerine geçmez; etcd şifreleme, dış secret yöneticisi, anahtar döndürme ve görüntüleme yetkisi birlikte planlanır. Pod Security Standards, ayrıcalıklı container, hostPath, host network, root kullanıcı ve Linux capability kullanımını sınırlar. NetworkPolicy pod'ların hangi kaynak ve hedeflerle konuşabileceğini tanımlar, ancak seçilen CNI eklentisinin bu politikayı gerçekten uyguladığı test edilmelidir. Varsayılan reddetme yaklaşımı DNS, izleme ve gerekli platform akışlarıyla kontrollü biçimde açılır.

Yazılım tedarik zinciri container registry'den başlar. İmajlar güvenilen pipeline tarafından değişmez sürüm veya digest ile üretilir; açık latest etiketiyle neyin çalıştığı belirsiz bırakılmaz. Temel imaj, paket ve uygulama bağımlılıkları zafiyet taramasından geçer; kritik bulgular için istisna sahibi ve bitiş tarihi bulunur. İmzalama ve admission politikası kullanılıyorsa yalnız doğrulanmış kaynaktan gelen imajların çalışması sağlanabilir. API audit kayıtları, yönetici değişiklikleri, başarısız erişimler ve policy ihlalleri merkezi log sistemine gönderilir. Kubeconfig, registry anahtarı ve CI/CD service account bilgileri kod deposunda veya ortak klasörde tutulmaz. Sertifika süreleri, desteklenen Kubernetes sürümü ve bileşen version skew politikası izlenir; yükseltme önce test kümesinde ve geri dönüş planıyla uygulanır. Güvenlik denetimi yalnız manifest taraması değildir; node işletim sistemi, runtime, ingress, storage, yedek, dış kimlik ve yönetim ağı da aynı kapsamda değerlendirilir.

Kimlik ve RBAC

İnsan ve service account kimlikleri ayrılır; namespace düzeyinde en az yetki, kişisel yönetici hesabı, MFA ve süreli acil erişim uygulanır.

Pod güvenliği

Root, privileged, hostPath, host network, capability, seccomp ve salt okunur dosya sistemi gereksinimleri politika ile sınırlandırılır.

Ağ politikası

Namespace ve uygulama akışları varsayılan reddetme temelinde tanımlanır; CNI tarafından uygulanması paket akışıyla test edilir.

İmaj güveni

Registry kaynağı, digest, zafiyet taraması, imza, admission kararı ve istisna süresi dağıtım pipeline'ında görünür olur.

Denetim ve sürüm

API audit, node logları, sertifika süreleri, desteklenen sürüm, yükseltme sırası ve güvenlik duyuruları merkezi olarak izlenir.

Yüksek erişilebilirlik, yedekleme ve gözlemleme kontrollü arıza testleriyle kanıtlanır

Üretim kümesinde tek control plane veya tek load balancer ortak hata noktasıdır. Kubernetes belgeleri kritik iş yükleri için control plane bileşenlerinin çoğaltılmasını, API trafiğinin sağlıklı örneklere dağıtılmasını ve etcd'nin düzenli yedeklenmesini önerir. Ancak üç node bulunması tek başına yüksek erişilebilirlik sağlamaz; node'lar aynı güç, switch, storage veya fiziksel konumu paylaşıyorsa arıza alanı devam eder. Worker kapasitesi bir node kaybında kritik pod'ları çalıştıracak payı içermelidir. PodDisruptionBudget planlı bakım sırasında erişilebilir kopya sayısını korumaya yardım eder, fakat plansız arızayı veya hatalı uygulama sürümünü tek başına çözmez. Topology spread ve anti-affinity kopyaları farklı node veya zone'lara dağıtabilir. Stateful uygulamalarda depolama katmanının replikasyon, fencing, snapshot ve toparlanma davranışı ayrıca test edilir. etcd yedeği küme durumunu korur; uygulama veritabanı, persistent volume ve dış servis verilerinin yedeği için ayrı plan gerekir.

Gözlemleme metric, log ve trace verilerini uygulama bağlamıyla birleştirir. Node hazır değil, pod yeniden başlıyor veya disk doluyor sinyali tek başına iş etkisini anlatmaz; servis hata oranı, gecikme, kuyruk, başarı oranı ve kullanıcı akışıyla ilişkilendirilir. Alarmın sahibi, önceliği ve müdahale adımı runbook içinde bulunur. Kabul testinde control plane örneği, worker node, network eklentisi, CoreDNS, registry, storage, ingress ve dış kimlik bağlantısı kontrollü kesilir. Kritik uygulamanın başka node'a yerleşme süresi, bağlantı kaybı, veri tutarlılığı ve kullanıcı etkisi ölçülür. etcd, manifest, secret ve persistent veriden ayrı geri dönüş senaryoları çalıştırılır. Yükseltme testi node boşaltma, uygulama dağıtımı, hatalı sürüm geri alma ve şema değişikliği gibi gerçek işlemleri kapsar. As-built dosyada küme topolojisi, namespace ve uygulama envanteri, erişim, network policy, storage class, yedek, sertifika, sürüm, izleme, alarm ve kabul kanıtları tutulur.

• Control plane, etcd, load balancer, worker, switch, güç ve storage arıza alanlarını fiziksel bağımsızlıklarıyla birlikte değerlendirin.
• Etcd yedeği, cluster manifestleri, secret verisi, persistent volume ve uygulama veritabanı için ayrı koruma ve geri dönüş planı hazırlayın.
• Node kaybı, pod yeniden yerleşimi, DNS, ingress, registry, storage ve kimlik kesintilerinde kullanıcı etkisini ve toparlanma süresini ölçün.
• Metric, log ve trace verisini servis seviyesi göstergeleriyle ilişkilendirin; her alarmın sahibi ve runbook adımı olsun.
• Küme yükseltmesi, node drain, hatalı sürüm geri alma, sertifika yenileme ve yedekten dönüşü planlı tatbikat takvimine bağlayın.