Amazon Elastic Kubernetes Service (EKS), Kubernetes control plane operasyonunun AWS tarafından yönetildiği managed Kubernetes servisidir. Uygulama workload'ları EC2 worker node'larda, managed node group'larda, Fargate üzerinde veya uygun mimarilerde EKS Auto Mode ile çalıştırılabilir.

EKS için EC2 worker node zorunlu mu?

Hayır. EKS workload'ları managed node group veya self-managed EC2 node'larda çalıştırılabilir; uygun workload'larda AWS Fargate ya da EKS Auto Mode seçenekleri de değerlendirilebilir. Seçim workload, maliyet, kontrol ve operasyon ihtiyacına göre yapılmalıdır.

EKS cluster maliyeti nasıl oluşur?

EKS maliyeti yalnız cluster control plane ücretinden oluşmaz. Worker compute, EBS, load balancer, NAT, data transfer, logging, observability, backup ve kullanılan managed servisler toplam maliyeti belirler. Ayrıca engineering ve operasyon zamanı da toplam sahip olma maliyetine dahil edilmelidir.

EKS küçük ekipler için mantıklı mı?

Her zaman değil. Kubernetes'in deployment standardizasyonu, isolation, autoscaling ve platform ihtiyacı gerçek bir problem çözüyorsa EKS anlamlı olabilir. Basit birkaç servisi olan küçük ekiplerde operasyon karmaşıklığı, daha basit compute veya container platformlarına göre gereksiz yük oluşturabilir.

AWS EKS nedir? Production Kubernetes rehberi | Dynamis

Q: EKS ile Kubernetes aynı şey mi?

EKS, Kubernetes'in AWS üzerinde yönetilen bir dağıtımıdır. Kubernetes API ve ekosistemi korunurken control plane lifecycle ve AWS entegrasyonlarının bir bölümü AWS tarafından yönetilir. Worker node, workload, network policy, security ve uygulama operasyonu yine mimariye göre ekip sorumluluğunda kalır.

Kısaca

Amazon EKS (Elastic Kubernetes Service), Kubernetes control plane operasyonunun AWS tarafından yönetildiği managed Kubernetes servisidir. Ancak EKS kullanmak Kubernetes operasyonunu tamamen ortadan kaldırmaz; workload, node kapasitesi, network, identity, observability, upgrade planı ve maliyet hâlâ doğru tasarlanmalıdır.

Dynamis Teknoloji'de EKS'i yalnız 'cluster açma' işi olarak değil, control plane + compute + network + identity + observability + deployment + cost birlikte ele alınan production platformu olarak değerlendiriyoruz.

AWS EKS nedir?

Amazon EKS, Kubernetes workload'larını AWS üzerinde çalıştırmak için kullanılan managed Kubernetes servisidir.

AWS control plane katmanının availability ve lifecycle operasyonunun önemli bölümünü yönetirken, workload tarafında şu kararlar devam eder:

worker compute modeli
pod ve service network
ingress / load balancing
IAM entegrasyonu
storage
autoscaling
observability
upgrade
backup
security policy
cost optimization

EKS ile Kubernetes aynı şey mi?

EKS, upstream Kubernetes API ve ekosistemini AWS üzerinde managed service modeliyle sunar.

Yani kubectl, Deployment, Service, ConfigMap, Secret ve diğer Kubernetes objeleri aynı temel modele dayanır.

Fark, control plane ve AWS entegrasyonlarının bir bölümünün managed hale gelmesidir.

EKS mimarisinde hangi katmanlar var?

Production EKS mimarisini şu katmanlarda düşünün:

Kubernetes control plane
worker compute
VPC ve subnet
CNI / pod networking
IAM
ingress / load balancer
storage
DNS
observability
autoscaling

Bu katmanların her biri ayrı failure ve maliyet alanı oluşturabilir.

Control plane'i kim yönetir?

Amazon EKS Kubernetes control plane'i AWS tarafından yönetilen bir servis olarak çalıştırır.

Bu, etcd ve API server gibi control plane bileşenlerini sizin ayrı EC2 instance'larda kurma ihtiyacınızı ortadan kaldırır.

Ancak cluster version, add-on compatibility, workload upgrade ve policy kararları hâlâ operasyon planı gerektirir.

Worker compute seçenekleri nelerdir?

Managed Node Groups

EKS managed node group, EC2 worker node'ların provision ve lifecycle yönetimini basitleştirir.

AWS node group içinde EC2 Auto Scaling Group kullanır ve node update/termination sürecinde Kubernetes drain akışını yönetir.

Bu model çoğu standart production workload için güçlü bir başlangıçtır.

Self-managed nodes

AMI, bootstrap, kernel veya node lifecycle üzerinde daha fazla kontrol gerekiyorsa self-managed EC2 node kullanılabilir.

Kontrol artarken operasyon sorumluluğu da artar.

AWS Fargate

Fargate uygun pod'ları ayrı EC2 worker node yönetmeden çalıştırma seçeneği sunabilir.

Ancak workload tipi, DaemonSet ihtiyacı, networking, storage ve cost modeli açısından her cluster için doğru seçim değildir.

EKS Auto Mode

EKS Auto Mode, compute autoscaling, node lifecycle ve bazı core infrastructure bileşenlerinde AWS'nin yönetim kapsamını genişletir.

AWS dokümantasyonuna göre Auto Mode node provisioning, patching ve node lifecycle gibi operasyonların daha büyük bölümünü EKS'e devreder. Buna karşılık managed instance'lar daha kısıtlı erişim ve özelleştirme modeline sahiptir. citeturn603052search1turn603052search2

Managed Node Group mu, Auto Mode mu?

Tek bir doğru cevap yoktur.

Managed Node Group daha fazla klasik EC2 kontrolü sunarken EKS Auto Mode node ve altyapı operasyonunun daha büyük bölümünü otomatikleştirir.

Seçim yaparken:

custom AMI ihtiyacı
node-level access
kernel / runtime customization
autoscaling beklentisi
operasyon kapasitesi
maliyet modeli

birlikte değerlendirilmelidir.

VPC ve subnet tasarımı

EKS production network tasarımı cluster başarısının kritik parçalarından biridir.

Kontrol edin:

public/private subnet dağılımı
Availability Zone sayısı
pod IP kapasitesi
NAT kullanımı
load balancer placement
private endpoint ihtiyacı
security group

Pod IP tüketimi özellikle büyük cluster'larda VPC CIDR planını etkileyebilir.

EKS networking neden önemlidir?

Kubernetes Service ve pod network davranışı AWS VPC modeliyle birlikte çalışır.

Yanlış network tasarımı:

IP exhaustion
gereksiz NAT maliyeti
cross-AZ trafik
erişim problemi

oluşturabilir.

Identity ve IAM

EKS'te iki ayrı identity katmanını ayırmak gerekir:

cluster access / operator identity
workload identity

Workload'ların AWS servislerine erişimi için pod seviyesinde IAM entegrasyonu kullanılmalıdır.

Static AWS access key'lerini Kubernetes Secret içinde uzun süre tutmak yerine IAM tabanlı workload identity yaklaşımı tercih edilmelidir.

EKS Pod Identity ve IAM role yaklaşımı

AWS, Kubernetes workload'larının AWS servislerine erişimi için EKS Pod Identity ve IAM roles for service accounts gibi mekanizmalar sunar.

Amaç her workload'a yalnız gerekli AWS permission'larını vermektir.

Least privilege burada kritik prensiptir.

Ingress ve Load Balancer

HTTP/HTTPS trafiği için Kubernetes ingress veya Gateway API modeli AWS load balancer entegrasyonlarıyla birlikte kullanılabilir.

Production tasarımında:

TLS
health check
target type
internal/public exposure
WAF ihtiyacı
cross-zone davranışı

değerlendirilmelidir.

Storage

Stateful workload'larda storage tasarımı ayrıca ele alınmalıdır.

Tipik seçenekler:

EBS
EFS
application-native external storage

Persistent volume kullanımı backup stratejisinin yerine geçmez.

EKS add-on'ları

Cluster lifecycle içinde bazı AWS/Kubernetes entegrasyonları add-on olarak yönetilebilir.

Örnek:

VPC CNI
CoreDNS
kube-proxy
EBS CSI Driver

Add-on version'ları cluster upgrade planının parçası olarak takip edilmelidir.

EKS upgrade nasıl planlanmalı?

Kubernetes cluster upgrade yalnız control plane version değiştirmek değildir.

Sıra genel olarak:

deprecated API kontrolü
add-on compatibility
control plane upgrade
node upgrade
workload test
observability doğrulaması

şeklinde planlanmalıdır.

Production öncesinde staging veya düşük riskli cluster üzerinde test yapılması değerlidir.

Observability

Production EKS için minimum görünürlük:

node health
pod restart
pending pod
CPU / memory request vs usage
deployment availability
ingress error / latency
cluster events
application logs

olmalıdır.

CloudWatch, Prometheus, Grafana veya başka observability stack'leri ihtiyaca göre kullanılabilir.

Observability Nedir? metric, log ve trace farklarını açıklar.

Resource request ve limit neden kritik?

Yanlış request değerleri:

node kapasitesinin gereksiz dolu görünmesine
autoscaler'ın fazla node açmasına
pod scheduling problemlerine

yol açabilir.

Bu nedenle gerçek kullanım ile request/limit değerleri düzenli karşılaştırılmalıdır.

Autoscaling

EKS'te birden fazla autoscaling katmanı vardır:

pod autoscaling
node autoscaling
workload-specific scaling

Pod scale-out çalışırken node kapasitesi yetmiyorsa node provisioning de doğru çalışmalıdır.

Cluster Autoscaler ve Karpenter

Node autoscaling için Kubernetes Cluster Autoscaler veya Karpenter gibi yaklaşımlar kullanılabilir.

Yeni cluster tasarımında EKS Auto Mode da node lifecycle ve autoscaling için alternatif oluşturur.

Aynı cluster'da birden fazla node provisioning yaklaşımı kullanılıyorsa ownership sınırları net olmalıdır.

EKS high availability

EKS control plane managed olsa da workload availability otomatik olarak çözülmez.

Uygulama tarafında:

replica sayısı
pod anti-affinity / topology
multi-AZ node dağılımı
PodDisruptionBudget
database availability
load balancer health

gibi konular ayrı tasarlanmalıdır.

PodDisruptionBudget ne işe yarar?

PDB gönüllü disruption sırasında aynı anda kaç pod'un unavailable olabileceğini sınırlar.

Ancak her node termination senaryosunda mutlak availability garantisi sağlamaz.

Bu nedenle PDB, replica ve topology tasarımı birlikte ele alınmalıdır.

EKS security

Kontrol alanları:

IAM least privilege
cluster endpoint access
RBAC
network policy
secret management
image scanning
admission policy
node patching
audit logging

Managed control plane kullanmak workload security sorumluluğunu ortadan kaldırmaz.

Secrets nasıl yönetilmeli?

Kubernetes Secret yalnız base64 encode edilmiş veri modelidir; tek başına external secret management çözümü değildir.

Production ortamında KMS entegrasyonu, Secrets Manager veya benzeri secret lifecycle yaklaşımı değerlendirilebilir.

EKS maliyeti nasıl oluşur?

EKS toplam maliyetinde:

cluster control plane
worker compute
EBS / storage
load balancer
NAT
data transfer
observability
backup
external managed services

gibi kalemler bulunabilir.

EKS Auto Mode kullanılıyorsa güncel AWS pricing modelindeki ek yönetim ücretleri de ayrıca hesaplanmalıdır; bu yüzden implementasyon öncesi AWS'nin güncel EKS Pricing sayfası kontrol edilmelidir.

Kubernetes maliyeti neden yalnız node fiyatı değildir?

Platform engineering ve operasyon zamanı da gerçek TCO'nun parçasıdır.

Şunları dahil edin:

upgrades
incident response
monitoring
security
CI/CD
backup
capacity planning

EKS maliyeti nasıl optimize edilir?

Sağlıklı sıra:

workload request/usage görünürlüğü
idle workload temizliği
pod rightsizing
node rightsizing
autoscaling
Spot uygunluğu
storage/network optimizasyonu
commitment değerlendirmesi

Cloud Rightsizing Nedir? resource sizing yaklaşımını genel olarak açıklar.

Spot node kullanılabilir mi?

Interruption toleransı olan stateless workload'larda Spot kapasite değerlendirilebilir.

Ancak:

disruption handling
workload spread
on-demand fallback
PDB

doğru planlanmalıdır.

Küçük ekip için EKS mantıklı mı?

Her zaman değil.

Eğer ekipte:

birkaç basit servis
düşük deployment karmaşıklığı
sınırlı scaling ihtiyacı

varsa Kubernetes gereksiz platform overhead yaratabilir.

Küçük ekip için Kubernetes: ne zaman fazla gelir? bu kararı ayrıntılı ele alır.

EKS mi ECS mi?

Bu seçim yalnız teknik yetenek üzerinden yapılmamalıdır.

EKS daha taşınabilir Kubernetes API ve ekosistemi sunarken ECS AWS-native container operasyonunu daha basit hale getirebilir.

Kubernetes standardizasyonu gerçek ihtiyaç değilse ECS gibi daha basit model toplam operasyon yükünü azaltabilir.

EKS production checklist

cluster version
add-on compatibility
managed node / Auto Mode kararı
multi-AZ worker dağılımı
pod IP kapasitesi
IAM workload identity
RBAC
ingress / LB
storage
request / limit
autoscaling
observability
backup
upgrade planı
security policy
cost review

Dynamis EKS operasyonunda ne yönetir?

Dynamis ihtiyaca göre:

EKS architecture
cluster deployment
managed node groups / compute model
networking
IAM
ingress
observability
upgrades
autoscaling
backup
incident
cost optimization

alanlarını yönetebilir.

DevOps ve Kubernetes hizmeti, EKS dahil production Kubernetes operasyonunu uçtan uca ele alır.

AWS hesabınızın genel operasyonu için ayrıca AWS yönetim hizmeti kullanılabilir.

Sık yapılan hatalar

Managed service olduğu için operasyon yok sanmak: Workload, node, network ve upgrade sorumlulukları devam eder.

Request/limit vermemek: Scheduling ve autoscaling davranışı bozulabilir.

IAM key'lerini pod içine gömmek: Workload identity kullanın.

Cluster upgrade'i yalnız control plane değişimi sanmak: Add-on, node ve workload compatibility'yi test edin.

Her workload için EKS seçmek: Platform overhead ile business ihtiyacını karşılaştırın.

Sonuç

Amazon EKS, AWS üzerinde production Kubernetes çalıştırmak için güçlü bir managed platformdur; ancak başarı yalnız cluster oluşturmakla gelmez.

Compute modeli, network, identity, observability, upgrade, security ve maliyet birlikte tasarlanmalıdır.

AWS EKS Nedir? Kubernetes AWS Üzerinde Nasıl Yönetilir?