Kubernetes Nedir? K8s ve Konteyner Orkestrasyonu Kurumsal Rehberi

Kısaca Kubernetes Nedir?

Kubernetes, birden fazla sunucu üzerinde çalışan konteyner tabanlı uygulamaların deployment, scaling, networking, recovery ve lifecycle yönetimini otomatikleştiren açık kaynaklı bir orkestrasyon platformudur.

Kubernetes temel olarak şu problemleri çözer:

• Konteynerlerin uygun sunuculara yerleştirilmesi
• İstenen sayıda uygulama kopyasının sürekli çalıştırılması
• Çöken workload'ların yeniden oluşturulması
• Uygulama servislerinin birbirini bulması
• Gelen trafiğin çalışan uygulama kopyalarına dağıtılması
• Uygulamaların yatay olarak ölçeklendirilmesi
• Yeni uygulama sürümlerinin kontrollü dağıtılması
• Persistent storage bağlanması
• Configuration ve secret yönetimi
• Cluster kaynaklarının ekipler arasında paylaşılması

Kubernetes Ne Demektir?

Kubernetes adı Yunancada "dümenci" veya "kaptan" anlamına gelen bir kelimeden gelir.

Platform ilk olarak Google'daki container operasyon deneyimlerinden doğmuş, daha sonra açık kaynaklı hale gelmiş ve Cloud Native Computing Foundation - CNCF çatısı altında geliştirilmiştir.

Kubernetes bugün cloud-native uygulama altyapısının temel standartlarından biri olarak:

• Public cloud
• Private cloud
• On-premises
• Colocation
• Hybrid cloud
• Edge

ortamlarında kullanılabilir.

K8s Ne Demektir?

K8s, Kubernetes kelimesinin yaygın kullanılan kısaltmasıdır.

Kubernetes kelimesindeki ilk "K" ile son "s" arasında sekiz harf bulunduğu için:

K + 8 + s = K8s

kısaltması kullanılır.

Konteyner Nedir?

Konteyner, bir uygulamanın kodunu ve çalışması için gerekli bağımlılıkları taşınabilir bir çalışma paketi içinde bir araya getiren uygulama dağıtım yöntemidir.

Bir container image tipik olarak:

• Uygulama kodunu
• Runtime'ı
• Kütüphaneleri
• Sistem bağımlılıklarını
• Başlangıç konfigürasyonunu

içerir.

Bunun sonucu olarak geliştirme, test ve production ortamları arasında daha tutarlı bir uygulama paketi kullanılabilir.

Ancak container kullanmak tek başına büyük ölçekli operasyon problemini çözmez.

Neden Konteyner Orkestrasyonuna İhtiyaç Duyulur?

Bir uygulama birkaç konteynerden yüzlerce veya binlerce konteynere büyüdüğünde deployment, scheduling, recovery, networking ve scaling işlemlerinin manuel yönetimi operasyonel olarak sürdürülemez hale gelir.

Örneğin 50 mikroservisten oluşan bir uygulamada her mikroservisin:

• Birden fazla replica'sı
• Farklı CPU ve memory ihtiyacı
• Farklı deployment sıklığı
• Farklı network erişim politikası
• Farklı scaling ihtiyacı

olabilir.

Cluster operatörünün manuel olarak şu kararları vermesi gerekir:

• Hangi container hangi sunucuda çalışacak?
• Sunucu kapasitesi yeterli mi?
• Container çöktüğünde ne olacak?
• Sunucu arızalanırsa workload nereye taşınacak?
• Yeni sürüm nasıl dağıtılacak?
• Trafik artınca replica sayısı nasıl değişecek?

Kubernetes bu kararların önemli bölümünü deklaratif ve otomatik bir kontrol modeline dönüştürür.

Docker ile Kubernetes Arasındaki Fark Nedir?

Docker ve Kubernetes aynı işi yapan rakip teknolojiler değildir. Docker ağırlıklı olarak container image oluşturma ve container geliştirme deneyimiyle ilişkilidir. Kubernetes ise container tabanlı workload'ların bir cluster üzerinde orkestrasyonunu sağlar.

Kubernetes Docker Kullanıyor mu?

Kubernetes cluster'larında Docker ile oluşturulmuş container image'ları kullanılabilir, ancak Kubernetes'in Docker Engine ile özel dockershim entegrasyonu artık Kubernetes'in parçası değildir.

Modern Kubernetes node'larında kubelet, container runtime ile Container Runtime Interface - CRI üzerinden iletişim kurar.

Yaygın runtime seçenekleri:

• containerd
• CRI-O
• CRI uyum katmanı üzerinden desteklenen diğer runtime'lar

Docker ile developer laptop'ında image oluşturmak ve aynı OCI uyumlu image'ı Kubernetes üzerinde çalıştırmak mümkündür.

Dolayısıyla "Kubernetes Docker'ı desteklemiyor" ifadesi de "Kubernetes node'ları doğrudan Docker kullanır" ifadesi de gereğinden fazla basitleştirilmiş olur.

Kubernetes Cluster Nedir?

Kubernetes cluster, control plane ve bir veya daha fazla worker node'dan oluşan, container workload'ların koordineli şekilde çalıştırıldığı altyapıdır.

Basit olarak:

Control Plane - karar verir

Worker Node - workload'u çalıştırır

Kubernetes Mimarisinin Temel Bileşenleri Nelerdir?

Control Plane

Control plane, cluster'ın istenen durumunu yönetir ve workload'ların hangi node'larda nasıl çalışacağını koordine eder.

kube-apiserver

Kubernetes API'sini sunan temel control plane bileşenidir.

Kullanıcılar, controller'lar, automation sistemleri ve diğer cluster bileşenleri Kubernetes ile API Server üzerinden iletişim kurar.

etcd

Kubernetes API verisinin tutulduğu dağıtık ve tutarlı key-value store'dur.

Cluster state açısından kritik olduğu için etcd:

• Yedeklenmeli
• Yetkisiz erişimden korunmalı
• Yüksek erişilebilirlik tasarımıyla işletilmeli

kube-scheduler

Henüz bir node'a atanmamış Pod'ları değerlendirir ve uygun worker node'a yerleştirir.

Scheduler karar verirken:

• CPU ve memory request'leri
• Node uygunluğu
• Affinity ve anti-affinity
• Taint ve toleration
• Topology kuralları

gibi kriterleri kullanabilir.

kube-controller-manager

Kubernetes'in reconciliation loop'larını çalıştıran controller'ları yönetir.

İstenen durum ile gerçek durum arasındaki fark tespit edildiğinde controller sistemi tekrar istenen duruma getirmeye çalışır.

cloud-controller-manager

Cloud ortamlarında Kubernetes'i ilgili cloud sağlayıcısının:

• Load balancer
• Node
• Routing

gibi altyapı servisleriyle entegre edebilir.

Worker Node Nedir?

Worker node, uygulama Pod'larının fiilen çalıştığı Kubernetes compute sunucusudur.

kubelet

Her node üzerinde çalışan kubelet, API üzerinden node'a atanmış Pod tanımlarını takip eder ve container'ların istenen şekilde çalışmasını sağlar.

Container Runtime

Container image'larını çalıştıran düşük seviyeli runtime katmanıdır.

containerd ve CRI-O yaygın örneklerdir.

kube-proxy

kube-proxy, birçok Kubernetes deployment'ında Service networking için node üzerindeki network kurallarını yönetir.

Bununla birlikte modern Kubernetes networking mimarilerinde kube-proxy kullanımı zorunlu değildir. Bazı CNI ve eBPF tabanlı çözümler Service routing fonksiyonunu farklı şekilde uygulayabilir.

Pod Nedir?

Pod, Kubernetes'te oluşturulabilen ve schedule edilebilen en küçük workload birimidir.

Bir Pod:

• Bir veya birden fazla container
• Ortak network namespace
• Ortak IP adresi
• Paylaşılan volume'lar

içerebilir.

Çoğu uygulamada bir Pod içinde tek ana application container bulunur.

Sidecar pattern gibi durumlarda aynı Pod içinde ek container'lar kullanılabilir.

Pod ile Container Arasındaki Fark Nedir?

Container uygulamanın çalışan process paketidir. Pod ise Kubernetes'in bir veya daha fazla container'ı ortak network ve storage bağlamı içinde yönettiği orkestrasyon birimidir.

Kubernetes doğrudan "container replica sayısı" yerine çoğunlukla Pod yaşam döngüsünü yönetir.

Deployment Nedir?

Deployment, stateless uygulamalar için istenen Pod sayısını, container image sürümünü ve rollout davranışını tanımlayan Kubernetes workload kaynağıdır.

Deployment ile:

• Replica sayısı belirlenebilir.
• Yeni image sürümü dağıtılabilir.
• Rolling update yapılabilir.
• Eski revision'a rollback yapılabilir.

Deployment arka planda ReplicaSet kaynaklarını kullanarak Pod sayısını yönetir.

Kubernetes Güncelleme Başarısız Olursa Otomatik Rollback Yapar mı?

Kubernetes Deployment rollback mekanizması sunar ancak yeni deployment başarısız olduğunda her durumda otomatik olarak önceki sürüme dönmez.

Kubernetes rollout'un ilerlemediğini tespit edebilir ve durumu raporlayabilir.

Otomatik rollback için genellikle:

• CI/CD pipeline
• GitOps controller
• Progressive delivery platformu
• Custom deployment automation

gibi ek operasyon mekanizmaları kullanılır.

ReplicaSet Nedir?

ReplicaSet, belirlenen sayıda aynı Pod replica'sının çalışır durumda olmasını sağlayan Kubernetes controller kaynağıdır.

Production uygulamalarda ReplicaSet çoğunlukla doğrudan oluşturulmaz.

Deployment tarafından otomatik olarak yönetilir.

StatefulSet Nedir?

StatefulSet, stabil kimlik, sıralı deployment ve kalıcı storage ilişkisi gerektiren stateful uygulamalar için kullanılan Kubernetes workload kaynağıdır.

StatefulSet şu tür workload'larda değerlendirilebilir:

• Database cluster'ları
• Distributed data platformları
• Message broker sistemleri
• Stable hostname gerektiren uygulamalar

Ancak bir uygulamanın Kubernetes üzerinde StatefulSet ile çalışabilmesi, otomatik olarak o uygulamanın production için güvenli veya operasyonel olarak kolay olduğu anlamına gelmez.

Backup, replication, quorum ve disaster recovery ayrıca tasarlanmalıdır.

DaemonSet Nedir?

DaemonSet, belirli veya tüm worker node'larda bir Pod kopyasının çalışmasını sağlayan Kubernetes workload kaynağıdır.

Yaygın kullanım alanları:

• Log agent
• Monitoring agent
• Security agent
• Node-level network component
• Storage agent

Job ve CronJob Nedir?

Job

Job, belirli bir görevin başarılı şekilde tamamlanmasını hedefleyen batch workload kaynağıdır.

Örnek:

• Data migration
• Report generation
• Batch processing

CronJob

CronJob, Job kaynaklarının belirli bir schedule'a göre çalıştırılmasını sağlar.

Örneğin:

• Gece veri işleme
• Periyodik cleanup
• Scheduled reporting

Service Nedir?

Kubernetes Service, değişken Pod IP'lerinin önüne stabil bir ağ erişim noktası koyarak bir grup Pod'a tutarlı erişim sağlayan abstraction'dır.

Pod'lar:

• Yeniden oluşturulabilir
• Farklı node'a taşınabilir
• Yeni IP alabilir

ancak Service aynı mantıksal endpoint üzerinden erişim sağlayabilir.

ClusterIP, NodePort ve LoadBalancer Arasındaki Fark Nedir?

Production uygulamalarda gerçek trafik mimarisi cloud provider, on-prem network ve kullanılan load balancer implementasyonuna göre değişir.

Ingress Nedir?

Ingress, HTTP ve HTTPS trafiğini hostname ve path gibi kurallara göre Kubernetes Service kaynaklarına yönlendirmek için kullanılan Kubernetes API kaynağıdır.

Bir Ingress kaynağının çalışabilmesi için cluster'da ayrıca uygun bir Ingress Controller bulunması gerekir.

Ancak yeni Kubernetes mimarilerinde önemli bir gelişme vardır:

Kubernetes projesi yeni trafik yönetimi tasarımlarında Gateway API kullanımını önermektedir. Ingress API desteklenmeye devam etse de API geliştirme açısından dondurulmuştur.

Gateway API Nedir?

Gateway API, Kubernetes service networking için Ingress modelinden daha role-oriented, expressive ve extensible bir trafik yönetimi API ailesidir.

Temel kaynaklar arasında:

• GatewayClass
• Gateway
• HTTPRoute

bulunur.

Gateway API:

• Infrastructure ekipleri
• Cluster operator'ları
• Application developer'lar

arasında daha net sorumluluk ayrımı sağlamayı hedefler.

Namespace Nedir?

Namespace, Kubernetes kaynaklarını tek bir cluster içinde mantıksal gruplara ayırmaya yarayan organizasyon ve yönetim mekanizmasıdır.

Örnek:

• production
• staging
• development
• team-a
• team-b

Namespace tek başına güçlü bir güvenlik izolasyonu değildir.

Gerçek tenant izolasyonu için:

• RBAC
• NetworkPolicy
• ResourceQuota
• Pod Security kontrolleri
• Admission policy

gibi ek mekanizmalar gerekir.

ConfigMap ve Secret Nedir?

ConfigMap

ConfigMap, uygulama image'ından bağımsız configuration bilgisinin Kubernetes kaynakları üzerinden yönetilmesini sağlar.

Secret

Secret, password, token veya key gibi hassas verileri Kubernetes API objesi olarak yönetmek için kullanılır.

Ancak:

Kubernetes Secret kullanmak tek başına güçlü secret management anlamına gelmez.

Production ortamlarında ayrıca:

• etcd encryption at rest
• RBAC
• External secret manager
• Secret rotation
• Audit log

gibi kontroller değerlendirilmelidir.

Kubernetes Storage Nasıl Çalışır?

Kubernetes container yaşam döngüsünden bağımsız kalıcı veri ihtiyacını PersistentVolume ve PersistentVolumeClaim gibi storage abstractions üzerinden yönetebilir.

PersistentVolume - PV

Cluster'a sunulan kalıcı storage kaynağını temsil eder.

PersistentVolumeClaim - PVC

Uygulamanın belirli storage kapasitesi ve özellikleri için yaptığı talebi temsil eder.

StorageClass

Farklı storage sınıflarının ve dynamic provisioning politikasının tanımlanmasını sağlar.

Kubernetes storage altyapısı çoğunlukla Container Storage Interface - CSI sürücüleri üzerinden fiziksel veya cloud storage sistemleriyle entegre edilir.

Kubernetes Nasıl Çalışır?

Kubernetes deklaratif bir model kullanır: kullanıcı istediği son durumu API'ye bildirir, controller'lar gerçek durum ile istenen durum arasındaki farkı sürekli azaltmaya çalışır.

Basitleştirilmiş süreç:

1. Developer veya CI/CD sistemi Kubernetes API'ye Deployment tanımı gönderir.
2. API Server isteği doğrular ve cluster state'e kaydeder.
3. Deployment controller gerekli ReplicaSet'i oluşturur.
4. ReplicaSet gerekli Pod'ları oluşturur.
5. Scheduler Pod'ları uygun node'lara yerleştirir.
6. Node üzerindeki kubelet container runtime aracılığıyla container'ları çalıştırır.
7. Controller'lar sistemin istenen durumda olup olmadığını sürekli kontrol eder.

Declarative Infrastructure Ne Demektir?

Geleneksel imperative modelde operatör sisteme:

"Bir sunucu oluştur, uygulamayı başlat, ikinci kopyayı aç"

gibi adımlar verir.

Kubernetes'te ise:

"Bu uygulamadan her zaman 5 replica çalışsın."

denir.

Bir Pod kaybolduğunda Kubernetes toplam replica sayısının 4'e düştüğünü görür ve yeni Pod oluşturarak istenen duruma dönmeye çalışır.

Bu reconciliation modeli Kubernetes'in temel mimari prensibidir.

Kubernetes Self-Healing Nasıl Çalışır?

Kubernetes, controller ve health-check mekanizmaları sayesinde beklenen durumda olmayan workload'ları yeniden oluşturabilir veya trafik dışına çıkarabilir.

Self-healing örnekleri:

• Çöken container'ın yeniden başlatılması
• Kaybolan Pod yerine yeni Pod oluşturulması
• Arızalı node üzerindeki workload'un başka node'larda yeniden oluşturulması
• Ready olmayan Pod'un Service trafiğinden çıkarılması

Liveness, Readiness ve Startup Probe Nedir?

Liveness Probe

Uygulamanın hala çalışabilir durumda olup olmadığını kontrol eder.

Readiness Probe

Pod'un kullanıcı trafiği almaya hazır olup olmadığını belirler.

Startup Probe

Yavaş başlayan uygulamalara başlangıç için daha uzun tolerans tanınmasını sağlar.

Probe'ların yanlış tasarlanması production ortamında gereksiz restart ve outage oluşturabilir.

Kubernetes Autoscaling Nasıl Çalışır?

Kubernetes ekosisteminde scaling yalnızca Pod sayısını artırmak anlamına gelmez. Pod, kaynak ve node kapasitesi farklı katmanlarda ölçeklenebilir.

Horizontal Pod Autoscaler - HPA

HPA workload replica sayısını gözlenen metriklere göre artırıp azaltabilir.

Kullanılabilecek metrikler:

• CPU
• Memory
• Custom metric
• External metric

Kubernetes'in herhangi bir web trafiğini otomatik olarak anlayıp scale etmesi garanti değildir. Trafik veya business metric bazlı scaling için uygun metric pipeline ve HPA configuration gerekir.

Vertical Pod Autoscaler - VPA

VPA ekosistemde Pod'ların CPU ve memory resource request değerlerini workload kullanımına göre önermeye veya desteklenen kullanım modelinde ayarlamaya yardımcı olabilir.

Node Autoscaling

Pod'lar mevcut node kapasitesine sığmadığında cluster'ın worker node kapasitesinin artırılması gerekebilir.

Bu iş managed cloud ortamlarında Cluster Autoscaler, Karpenter benzeri bileşenler veya sağlayıcıya özgü mekanizmalarla gerçekleştirilebilir.

Resource Request ve Limit Nedir?

Resource request scheduler'ın Pod için ayırmayı planladığı CPU ve memory ihtiyacını, limit ise container'ın kullanabileceği maksimum kaynak sınırını tanımlamak için kullanılır.

Yanlış resource configuration:

• Node kapasitesinin boşa gitmesine
• CPU throttling'e
• OOM kill olaylarına
• Scheduling sorunlarına
• Gereksiz cloud maliyetine

neden olabilir.

Kubernetes maliyet optimizasyonunun en önemli alanlarından biri doğru requests ve limits tasarımıdır.

Kubernetes Yüksek Erişilebilirlik Sağlar mı?

Kubernetes yüksek erişilebilir uygulama mimarisi kurmak için önemli mekanizmalar sağlar ancak yalnızca cluster kurmak uygulamayı otomatik olarak yüksek erişilebilir hale getirmez.

Yüksek erişilebilirlik için:

• Birden fazla application replica
• Birden fazla worker node
• Control plane redundancy
• Zone veya rack dağılımı
• Pod anti-affinity
• Topology spread
• Health probe
• PodDisruptionBudget
• Yedekli storage

birlikte değerlendirilmelidir.

PodDisruptionBudget - PDB Nedir?

PodDisruptionBudget, planlı ve gönüllü cluster operasyonları sırasında aynı anda kaç uygulama Pod'unun unavailable olabileceğini sınırlandırmaya yardımcı olan Kubernetes policy kaynağıdır.

Örneğin node maintenance veya drain sırasında kritik bir uygulamanın bütün replica'larının aynı anda kapatılmasını engellemek için kullanılabilir.

PDB:

• Her türlü arızayı önlemez.
• Donanım arızasını engellemez.
• Yanlış uygulama tasarımını düzeltmez.

Ancak kontrollü cluster operasyonları sırasında availability hedeflerini korumaya yardımcı olur.

Kubernetes Networking Nasıl Çalışır?

Kubernetes networking modeli Pod'ların birbirleriyle ve Service kaynaklarıyla iletişim kurabilmesini sağlayan cluster ağ katmanına dayanır.

Production ortamında ağ mimarisi genellikle şu bileşenleri içerir:

• CNI plug-in
• Pod networking
• Service networking
• DNS
• Ingress veya Gateway
• Load balancer
• NetworkPolicy
• North-south traffic
• East-west traffic

CNI Nedir?

Container Network Interface - CNI, Kubernetes node ve Pod networking'inin network plug-in'leri tarafından uygulanmasını sağlayan ekosistem standardıdır.

Kullanılan CNI çözümü:

• Network routing
• NetworkPolicy desteği
• Observability
• Encryption
• eBPF

gibi cluster davranışlarını etkileyebilir.

Kubernetes Cloud Bağımsız mıdır?

Kubernetes açık ve taşınabilir bir orchestration API'si sunduğu için workload'ların farklı altyapılar arasında taşınmasını kolaylaştırabilir, ancak Kubernetes kullanmak vendor lock-in'i tamamen ortadan kaldırmaz.

Core Kubernetes kaynakları:

• Deployment
• Service
• ConfigMap
• StatefulSet

farklı ortamlarda benzer şekilde kullanılabilir.

Ancak uygulama şu bağımlılıkları kullanıyorsa taşınabilirlik azalabilir:

• Cloud-specific LoadBalancer
• Managed database
• Provider-specific CSI storage
• IAM integration
• Provider-specific autoscaling
• Proprietary observability services

Kubernetes vendor lock-in riskini azaltabilir ancak mimari kararlar hala önemlidir.

Çoklu altyapı yönetiminin genel çerçevesi için Hibrit Bulut Nedir? içeriğini inceleyebilirsiniz.

Kubernetes Public Cloud'da mı, Private Cloud'da mı Çalıştırılmalıdır?

Kubernetes public cloud, private cloud ve on-premises altyapıda çalışabilir. Doğru ortam güvenlik, veri lokasyonu, ölçek, maliyet ve operasyon gereksinimine göre seçilmelidir.

Dedicated ve kontrollü altyapı gereksinimleri için Ixpanse Özel Bulut hizmeti de değerlendirilebilir.

Yönetilen Kubernetes ile Self-Managed Kubernetes Arasındaki Fark Nedir?

Managed Kubernetes modelinde cluster control plane operasyonlarının önemli bölümü sağlayıcı tarafından yönetilir. Self-managed modelde ise control plane dahil Kubernetes platformunun yaşam döngüsünden kurum sorumludur.

Managed Kubernetes control plane operasyonunu azaltır ancak:

• RBAC
• NetworkPolicy
• Application security
• Resource sizing
• Observability
• Backup
• Cost management

gibi konular müşteri sorumluluğunda kalmaya devam eder.

Kubernetes Güvenli midir?

Kubernetes güçlü güvenlik mekanizmaları sunar ancak güvenli bir Kubernetes ortamı otomatik olarak oluşmaz. Cluster, workload, identity, network ve software supply chain katmanlarının doğru yapılandırılması gerekir.

Temel güvenlik alanları:

• RBAC
• Least privilege
• NetworkPolicy
• Pod Security Standards
• Secret management
• Image scanning
• Image signing
• Admission policy
• Runtime security
• Audit logging
• Node hardening
• Patch management

Kubernetes cluster güvenliğinin CI/CD ve application lifecycle ile birlikte ele alınması gerekir.

Bu yaklaşımın geliştirme perspektifi için DevSecOps Nedir? rehberini inceleyebilirsiniz.

RBAC Nedir?

Role-Based Access Control - RBAC, Kubernetes API üzerinde hangi kullanıcı veya service account'un hangi kaynaklarda hangi işlemleri gerçekleştirebileceğini tanımlayan yetkilendirme modelidir.

Production ortamında:

• cluster-admin kullanımını sınırlandırmak
• Service account yetkilerini daraltmak
• Namespace bazlı erişim tanımlamak
• Least privilege uygulamak

kritik güvenlik kontrolleridir.

NetworkPolicy Nedir?

NetworkPolicy, Pod'lar arasındaki ve Pod'ların dış sistemlerle olan ağ iletişimini policy bazında sınırlamak için kullanılan Kubernetes kaynağıdır.

Örneğin frontend Pod'larının yalnızca backend Service'e, backend'in ise yalnızca belirli database endpoint'ine erişmesine izin veren zero-trust benzeri mikrosegmentasyon modeli oluşturulabilir.

NetworkPolicy'nin gerçekten uygulanması kullanılan CNI çözümünün bu özelliği desteklemesine bağlıdır.

Kubernetes Observability Neden Zordur?

Kubernetes ortamları dinamik olduğu için yalnızca sunucu uptime izlemek yeterli değildir. Pod, container, node, application, network ve distributed request katmanları birlikte gözlemlenmelidir.

Gerekli telemetry genellikle:

• Metrics
• Logs
• Distributed traces
• Events
• Audit logs

katmanlarını içerir.

İzlenebilecek temel metrikler:

• CPU usage
• Memory usage
• Pod restart count
• Pending Pod sayısı
• Node availability
• Request latency
• Error rate
• Network traffic
• Storage latency

Büyük Kubernetes ortamlarında oluşan log ve metric hacminin operasyonel olarak anlamlandırılması AIOps kullanım senaryolarını da güçlendirir. Konunun devamı için AIOps Nedir? rehberini inceleyebilirsiniz.

Kubernetes ile DevOps Arasındaki İlişki Nedir?

Kubernetes DevOps'un kendisi değildir. Ancak CI/CD, Infrastructure as Code, GitOps ve otomatik deployment süreçlerinin üzerinde çalışabileceği standart bir application platformu sağlayabilir.

Tipik pipeline:

1. Developer kodu commit eder.
2. CI pipeline testleri çalıştırır.
3. Container image oluşturulur.
4. Security scan yapılır.
5. Image registry'ye gönderilir.
6. Deployment manifest veya Helm configuration güncellenir.
7. Kubernetes yeni sürümü rollout eder.
8. Monitoring ve health check sonuçları takip edilir.

GitOps Nedir ve Kubernetes ile Nasıl Çalışır?

GitOps, Kubernetes cluster'ın istenen konfigürasyonunu Git repository içinde tanımlayıp bir controller aracılığıyla cluster'ın gerçek durumunu bu tanımla sürekli eşleştirme yaklaşımıdır.

Avantajları:

• Değişiklik geçmişi
• Code review
• Rollback kolaylığı
• Environment consistency
• Auditability

GitOps özellikle büyük Kubernetes ortamlarında manuel `kubectl` değişikliklerini azaltmak için önemli bir operasyon modeli olabilir.

Helm Nedir?

Helm, Kubernetes uygulama kaynaklarını paketlemek, parametrik hale getirmek ve farklı ortamlara tekrarlanabilir biçimde dağıtmak için kullanılan package manager ekosistemidir.

Helm chart içinde:

• Deployment
• Service
• ConfigMap
• Ingress veya Gateway config
• Secret template

gibi Kubernetes kaynakları birlikte yönetilebilir.

Kubernetes Uygulama Modernizasyonunda Nasıl Kullanılır?

Kubernetes, monolitik bir uygulamayı otomatik olarak modern hale getirmez. Ancak modernize edilmiş mikroservis ve container tabanlı uygulamaların standardize edilmiş şekilde işletilebileceği bir platform sağlar.

Application modernization süreci tipik olarak:

1. Uygulamaların analiz edilmesi
2. Monolitik bağımlılıkların belirlenmesi
3. Uygun servislerin containerize edilmesi
4. CI/CD süreçlerinin kurulması
5. State ve storage mimarisinin tasarlanması
6. Kubernetes deployment modelinin kurulması
7. Observability ve security'nin eklenmesi

adımlarını içerir.

Daha geniş dönüşüm perspektifi için Bulut Mimarileri ve Uygulama Modernizasyonu içeriğini inceleyebilirsiniz.

Kubernetes Maliyetleri Azaltır mı?

Kubernetes maliyeti otomatik olarak azaltmaz. Doğru resource sizing, autoscaling ve node yönetimiyle kaynak verimliliğini artırabilir, ancak yanlış yapılandırılmış cluster maliyeti yükseltebilir.

Maliyet artışına neden olabilecek durumlar:

• Gereğinden büyük node'lar
• Yüksek resource request'leri
• Idle cluster'lar
• Aşırı replica sayısı
• Kullanılmayan persistent volume'lar
• Gereksiz LoadBalancer kaynakları
• Cross-zone network trafiği
• Cloud egress
• Observability data maliyeti

Kubernetes FinOps İçin Hangi Metrikler İzlenmelidir?

• CPU request vs usage
• Memory request vs usage
• Idle node capacity
• Namespace maliyeti
• Application maliyeti
• Storage maliyeti
• Network egress
• Load balancer maliyeti
• Spot veya reserved capacity kullanımı
• Cluster utilization

Kaynakların teknik olarak çalışması yeterli değildir. Hangi workload'un ne kadar kaynak ve bütçe tükettiği görünür hale getirilmelidir.

Kubernetes AI ve GPU İş Yüklarında Kullanılabilir mi?

Evet. Kubernetes GPU tabanlı training, inference ve diğer accelerator workload'ların scheduling ve lifecycle yönetiminde kullanılabilir.

GPU ortamında ek olarak:

• GPU device plug-in
• GPU node pool
• Taint ve toleration
• Node affinity
• GPU scheduling
• High-speed network
• High-performance storage

gibi katmanlar gerekir.

Kubernetes GPU kaynağını schedule edebilir ancak GPU workload'un kendisini otomatik olarak ekonomik hale getirmez.

Model serving, GPU utilization, batching ve inference ekonomisi ayrıca tasarlanmalıdır.

Production AI altyapısı için AI Inference Nedir? içeriğini inceleyebilirsiniz.

Kubernetes Ne Zaman Kullanılmalıdır?

Kubernetes, container workload sayısı ve operasyonel karmaşıklık manuel yönetim sınırını aştığında, otomatik scaling, recovery ve standardizasyon ihtiyacı belirginleştiğinde anlamlı hale gelir.

Özellikle:

• Çok sayıda mikroservis varsa
• Sık deployment yapılıyorsa
• Birden fazla ekip aynı platformu kullanıyorsa
• Traffic önemli ölçüde değişiyorsa
• High availability gerekiyorsa
• Hybrid veya multi-environment deployment gerekiyorsa
• DevOps ve automation olgunluğu varsa

Kubernetes güçlü bir platform tercihi olabilir.

Kubernetes Ne Zaman Kullanılmamalıdır?

Kubernetes operasyonel karmaşıklığı, çözdüğü problemlerden büyükse kullanılması gereken bir teknoloji değildir.

Şu senaryolarda daha basit platformlar daha doğru olabilir:

• Tek küçük uygulama
• Düşük ve stabil trafik
• Az sayıda container
• Sınırlı DevOps ekibi
• Basit VM deployment'ı yeterliyse
• Yüksek availability ihtiyacı sınırlıysa

Kubernetes kullanmak teknik olgunluk göstergesi değildir.

Doğru teknoloji, şirketin gerçek problemine göre en düşük toplam karmaşıklıkla çözüm sunan teknolojidir.

Kubernetes Geçişi İçin Kurumsal Yol Haritası

Adım 1: İş Problemini Tanımlayın

Kubernetes hangi problemi çözecek?

• Deployment hızı mı?
• Scalability mi?
• Hybrid cloud mu?
• Standardizasyon mu?
• Availability mi?

Adım 2: Uygulamaları Sınıflandırın

Stateless, stateful, batch ve legacy workload'lar ayrılmalıdır.

Adım 3: Container Readiness Analizi Yapın

Uygulamanın:

• Configuration
• Storage
• Session
• Logging
• Dependency

modeli incelenmelidir.

Adım 4: Platform Modelini Seçin

Public cloud, private cloud, hybrid veya on-premises model belirlenmelidir.

Adım 5: Managed mı Self-Managed mı Karar Verin

Ekip kapasitesi gerçekçi değerlendirilmelidir.

Adım 6: Network ve Storage Tasarlayın

CNI, CSI, load balancer ve ingress/gateway modeli production öncesi netleştirilmelidir.

Adım 7: Security Baseline Oluşturun

RBAC, NetworkPolicy, Pod Security, image policy ve secret management standartlaştırılmalıdır.

Adım 8: CI/CD veya GitOps Kurun

Production değişiklikleri manuel yönetim yerine version-controlled automation ile yapılmalıdır.

Adım 9: Observability Kurun

Metrics, logs, traces ve alerts deployment öncesi planlanmalıdır.

Adım 10: Pilot Workload ile Başlayın

İlk Kubernetes projesi şirketin en kritik ve en karmaşık sistemi olmamalıdır.

Kubernetes Operasyonunda Hangi KPI'lar İzlenmelidir?

• Cluster availability: Cluster kontrol düzlemi ve node erişilebilirliği
• Pod availability: İstenen ve hazır replica oranı
• Pod restart rate: Container restart sıklığı
• Pending Pod: Schedule edilemeyen workload sayısı
• Deployment success rate: Başarılı deployment oranı
• Deployment frequency: Deployment sıklığı
• Change failure rate: Hata yaratan deployment oranı
• MTTR: Sorun sonrası toparlanma süresi
• CPU utilization: Kullanılan CPU kapasitesi
• Memory utilization: Kullanılan memory kapasitesi
• Request vs usage ratio: Rezerve edilen ve kullanılan kaynak farkı
• Node utilization: Worker node kaynak verimliliği
• Cost per application: Uygulama bazlı altyapı maliyeti

Kubernetes Projelerinde Sık Yapılan Hatalar

1. Kubernetes'i Amaç Olarak Görmek

Kubernetes bir iş hedefi değil, belirli operasyon problemlerini çözmek için kullanılan platformdur.

2. Monoliti Değiştirmeden Kubernetes'e Taşımak

Legacy uygulamayı container'a koymak mimari sorunları otomatik olarak çözmez.

3. Requests ve Limits Tanımlamamak

Capacity planning ve scheduling öngörülemez hale gelir.

4. Namespace'i Güvenlik İzolasyonu Sanmak

RBAC ve NetworkPolicy olmadan yeterli izolasyon sağlanmaz.

5. Secret'ları Güvenli Sanmak

Secret management ayrı güvenlik tasarımı gerektirir.

6. Stateful Workload'u Stateless Gibi Yönetmek

Data consistency, backup ve replication ayrıca planlanmalıdır.

7. Observability'yi Sonradan Eklemek

Production incident sırasında cluster'ın ne yaptığını anlamak zorlaşır.

8. Her Workload İçin Kubernetes Kullanmak

Basit workload'larda operasyon maliyeti faydadan büyük olabilir.

9. Sadece Pod Autoscaling Yapmak

Node kapasitesi artmıyorsa yeni Pod'lar Pending durumda kalabilir.

10. Backup'ı Yalnızca Persistent Volume Snapshot Sanmak

Application state, Kubernetes resource configuration ve recovery süreci birlikte değerlendirilmelidir.

11. Upgrade Stratejisi Olmadan Cluster Kurmak

Kubernetes ve bağlı ekosistem sürekli güncellenir.

CNI, CSI, ingress/gateway controller ve CRD compatibility upgrade öncesi değerlendirilmelidir.

Ixpanse ile Kubernetes ve Konteyner Altyapısı

Kubernetes yalnızca cluster kurulumundan oluşmaz. Production ortamında compute, storage, network, güvenlik, observability, yedeklilik, backup ve operasyon süreçlerinin birlikte çalışması gerekir.

Ixpanse'in Özel Bulut altyapısı, şirketlerin daha kontrollü ve özelleştirilebilir cloud ortamlarında modern application workload'ları çalıştırabilmesi için altyapı katmanı sağlar.

Kubernetes cluster'larının sürekli işletimi ise yalnızca compute sağlamakla sınırlı değildir.

Ixpanse'in Yönetilen Hizmetler yaklaşımı:

• Altyapı yönetimi
• Cloud operasyonu
• Kapasite planlaması
• Monitoring
• Güvenlik konfigürasyonu
• Container ve Kubernetes ortamlarının yönetimi

gibi operasyon alanlarını kapsayan bir model sunar.

Hybrid Kubernetes mimarilerinde network bağlantısı da kritik hale gelir.

Ankara IX tarafındaki Direct Internet Access, Cloud Interconnect ve yönetilen nokta bağlantıları, veri merkezi, private cloud ve dış cloud ortamları arasındaki network mimarisinin tasarlanmasında değerlendirilebilir.

Uygulamaların monolitik yapıdan container ve mikroservis modeline dönüştürülmesi ise yalnızca altyapı projesi değildir.

Bu dönüşümün mimari perspektifi için Bulut Mimarileri ve Uygulama Modernizasyonu, güvenlik perspektifi için DevSecOps, çoklu ortam yönetimi için ise Hibrit Bulut rehberlerini inceleyebilirsiniz.

Kubernetes'e geçiş, private cloud üzerinde cluster tasarımı veya mevcut Kubernetes ortamının operasyonel modelini değerlendirmek için Ixpanse uzman ekibiyle iletişime geçebilirsiniz.

Sonuç

Kubernetes, container tabanlı uygulamaları birden fazla sunucu üzerinde deklaratif, otomatik ve ölçeklenebilir şekilde yönetmek için kullanılan orchestration platformudur.

• Kubernetes container oluşturmaz, container workload'larını orkestre eder.
• Docker image'ları Kubernetes üzerinde çalışabilir ancak Kubernetes'in dockershim entegrasyonu artık kullanılmaz.
• Modern Kubernetes node'ları CRI uyumlu container runtime kullanır.
• Pod Kubernetes'in temel workload birimidir.
• Deployment stateless uygulama rollout ve replica yönetimini sağlar.
• StatefulSet stateful workload'lar için stabil kimlik ve storage ilişkisi sağlar.
• Service dinamik Pod'ların önüne stabil network erişimi koyar.
• Yeni trafik mimarilerinde Gateway API giderek Ingress'in yerine konumlanmaktadır.
• HPA workload replica sayısını metriklere göre ayarlayabilir ancak doğru metric pipeline gerekir.
• Kubernetes yüksek erişilebilirlik araçları sağlar ancak application HA ayrıca tasarlanmalıdır.
• Managed Kubernetes control plane yükünü azaltır ancak security ve application operasyon sorumluluğunu ortadan kaldırmaz.
• Kubernetes vendor lock-in'i azaltabilir ancak provider-specific servisler hala bağımlılık yaratabilir.
• Kubernetes her uygulama için doğru çözüm değildir.
• Gerçek kurumsal değer automation, standardizasyon, resilience ve operasyonel ölçekten gelir.

Kubernetes kararı verilirken temel soru:

"Kubernetes kullanabilir miyiz?"

değil,

"Uygulama ölçeğimiz, deployment hızımız ve operasyonel karmaşıklığımız Kubernetes'in getirdiği platform yükünü haklı çıkarıyor mu?"

olmalıdır.

Kubernetes Hakkında Sıkça Sorulan Sorular

Kubernetes nedir?

Kubernetes, container tabanlı uygulamaların birden fazla sunucu üzerinde deployment, scaling, networking ve lifecycle yönetimini otomatikleştiren açık kaynaklı container orchestration platformudur.

K8s ne demektir?

K8s, Kubernetes kelimesinin yaygın kısaltmasıdır. İlk K ve son s arasında sekiz harf bulunduğu için K8s ifadesi kullanılır.

Kubernetes ne işe yarar?

Kubernetes container workload'ların scheduling, scaling, recovery, networking, service discovery, configuration ve rollout süreçlerini otomatikleştirir.

Docker ile Kubernetes arasındaki fark nedir?

Docker container image oluşturma ve container geliştirme ekosistemiyle ilişkilidir. Kubernetes ise container tabanlı workload'ların çoklu sunucu üzerinde orkestrasyonunu sağlar.

Kubernetes Docker kullanıyor mu?

Docker ile oluşturulan OCI uyumlu image'lar Kubernetes üzerinde kullanılabilir ancak Kubernetes'in Docker Engine ile özel dockershim entegrasyonu Kubernetes 1.24 ile kaldırılmıştır. Node'larda CRI uyumlu runtime kullanılır.

Kubernetes cluster nedir?

Kubernetes cluster, control plane ile bir veya daha fazla worker node'dan oluşan ve container workload'ların koordineli olarak çalıştırıldığı altyapıdır.

Pod nedir?

Pod, Kubernetes'in oluşturup schedule edebildiği en küçük workload birimidir ve bir veya daha fazla container içerebilir.

Deployment nedir?

Deployment, stateless uygulamalarda istenen replica sayısını, container image sürümünü ve rollout davranışını tanımlayan Kubernetes kaynağıdır.

StatefulSet nedir?

StatefulSet, stabil network kimliği ve kalıcı storage ilişkisi gerektiren stateful uygulamaları yönetmek için kullanılan Kubernetes workload kaynağıdır.

DaemonSet nedir?

DaemonSet, belirli veya tüm Kubernetes worker node'larında bir Pod kopyasının çalıştırılmasını sağlayan workload kaynağıdır.

Kubernetes Service nedir?

Service, değişken Pod IP adreslerinin önüne stabil bir network endpoint koyarak belirli Pod grubuna tutarlı erişim sağlar.

Ingress nedir?

Ingress, HTTP ve HTTPS trafiğini hostname ve path kurallarına göre Kubernetes Service kaynaklarına yönlendirmek için kullanılan API kaynağıdır. Çalışması için Ingress Controller gerekir.

Gateway API nedir?

Gateway API, Kubernetes service networking için role-oriented ve extensible trafik yönetimi sunan API ailesidir. Kubernetes projesi yeni kullanım senaryolarında Gateway kullanımını Ingress yerine önermektedir.

Namespace nedir?

Namespace Kubernetes kaynaklarını tek cluster içinde mantıksal gruplara ayırır. Tek başına güçlü güvenlik izolasyonu sağlamaz.

ConfigMap nedir?

ConfigMap, application configuration bilgisinin container image'dan ayrı olarak Kubernetes içinde yönetilmesini sağlar.

Kubernetes Secret güvenli midir?

Secret hassas veriyi Kubernetes kaynağı olarak tutar ancak tek başına tam bir secret management çözümü değildir. Encryption, RBAC, rotation ve external secret manager gibi ek kontroller gerekebilir.

Kubernetes autoscaling nasıl çalışır?

Horizontal Pod Autoscaler CPU, memory veya custom ve external metrics kullanarak workload replica sayısını artırıp azaltabilir. Node kapasitesinin ayrıca ölçeklenmesi gerekebilir.

Kubernetes self-healing nedir?

Self-healing, Kubernetes controller'larının çöken veya kaybolan workload'ların yerine yeni Pod oluşturması ve uygun olmayan Pod'ları trafik dışına çıkarabilmesi gibi mekanizmaları ifade eder.

Kubernetes otomatik rollback yapar mı?

Kubernetes rollback mekanizması sunar ancak hatalı rollout her durumda otomatik olarak önceki sürüme dönmez. Otomatik rollback genellikle CI/CD, GitOps veya progressive delivery mekanizmalarıyla tasarlanır.

Kubernetes cloud bağımsız mıdır?

Kubernetes core API'leri farklı altyapılarda yüksek taşınabilirlik sağlar ancak cloud-specific storage, network, identity ve managed service bağımlılıkları tam taşınabilirliği azaltabilir.

Managed Kubernetes nedir?

Managed Kubernetes, control plane kurulumu, bakımı ve upgrade süreçlerinin önemli bölümünün sağlayıcı tarafından yönetildiği Kubernetes hizmet modelidir.

Kubernetes güvenli midir?

Kubernetes RBAC, NetworkPolicy ve Pod Security gibi güçlü güvenlik mekanizmaları sunar ancak güvenli sonuç için bu kontrollerin doğru yapılandırılması gerekir.

Kubernetes maliyeti azaltır mı?

Doğru resource sizing ve autoscaling ile kaynak kullanımını iyileştirebilir ancak overprovisioning, idle node ve yanlış konfigürasyon maliyeti artırabilir.

Kubernetes küçük projeler için gerekli midir?

Genellikle hayır. Küçük ve basit uygulamalarda Kubernetes'in operasyonel karmaşıklığı sağladığı faydadan daha yüksek olabilir.

Kubernetes AI ve GPU workload'larında kullanılabilir mi?

Evet. Kubernetes GPU tabanlı training ve inference workload'larını schedule edebilir ancak GPU networking, storage, scheduling ve maliyet optimizasyonu ayrıca tasarlanmalıdır.

Ixpanse Kubernetes altyapısını nasıl destekler?

Ixpanse private cloud, yönetilen hizmetler, cloud operasyonu, monitoring, connectivity ve Kubernetes ortamı yönetimi gibi altyapı ve operasyon katmanlarıyla container tabanlı uygulamaların production ortamlarını destekleyebilir.

İlgili İçerikler

• Bulut Mimarileri ve Uygulama Modernizasyonu
• Hibrit Bulut Nedir?
• Yönetilen Hizmetler Nedir?
• DevSecOps Nedir?
• AIOps Nedir?
• AI Inference Nedir?
• Özel Bulut
• Yönetilen Hizmetler
• Ankara IX

Teknik Kaynaklar

• Kubernetes Documentation - Kubernetes Components 
• Kubernetes Documentation - Container Runtimes 
• Kubernetes Documentation - Horizontal Pod Autoscaling 
• Kubernetes Documentation - Ingress 
• Kubernetes Documentation - Gateway API 
• Kubernetes Documentation - Pod Disruptions