Karşılaştırma · Bulut Altyapısı
GKE, EKS ve AKS: Kubernetes İşletim Sorumlulukları Karşılaştırması
Yönetilen Kubernetes control plane işletimini azaltır; uygulama güvenliği, namespace yetkileri, image politikası ve veri kurtarma müşterinin tasarımında kalır. GKE, EKS ve AKS aynı…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Yönetilen Kubernetes control plane işletimini azaltır; uygulama güvenliği, namespace yetkileri, image politikası ve veri kurtarma müşterinin tasarımında kalır. GKE, EKS ve AKS aynı Kubernetes kavramlarını kullanırken node, ağ ve kimlik entegrasyonları farklıdır.
Karşılaştırmayı seçilen çalışma kipinde yapın: GKE Standard/Autopilot, EKS node/Fargate/ilgili yönetilen seçenekleri ve AKS node pool veya desteklenen yönetim kipi aynı sorumluluk sınırını sunmaz. Varsayılan değerleri genel üstünlük diye sunmayın; bölge ve sürüm kapsamını kaydedin.
Kalıcı volume snapshot’ı uygulama tutarlılığı ve başka kümeye restore ile test edilir. Aynı YAML taşınabilir görünse bile storage class, load balancer annotation, identity binding ve egress davranışı sağlayıcı bağımlılığı oluşturur.
- 1Uygulama ve namespace
- 2Pod kimliği/ağ
- 3Node ve upgrade
- 4Veri ve kabul testi
Tasarım parametreleri
- Node yaşam döngüsü
- Patch, drain, surge kapasitesi ve sürüm destek penceresini seçilen modda belirleyin.
- Ağ adres kapasitesi
- Pod/service CIDR, CNI ve IP tahsis modeli büyüme sınırını etkiler.
- İş yükü kimliği
- Podlara uzun ömürlü cloud key koymak yerine desteklenen kimlik entegrasyonunu kullanın.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Platform | Temel entegrasyon | Pilot odağı |
|---|---|---|
| GKE | Google Cloud IAM/VPC | Standard/Autopilot sorumluluk sınırı |
| EKS | AWS IAM/VPC | Node/compute ve IP modeli |
| AKS | Entra/Azure ağ ve disk | Node pool, kimlik ve upgrade |
Hesap ve uygulama örneği
Altı node’lu uygulamada bir node yükseltilirken kapasite hedefi korunmalı. Üç platformda aynı replica, kaynak isteği, disruption budget ve trafik profiliyle pilot yapın. Node maliyetine cluster, load balancer, NAT/egress, log ve volume ücretlerini ekleyin; liste fiyatı olmadan net toplam iddia etmeyin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Upgrade podları durduruyor | Yetersiz replica, PDB veya surge kapasitesi. | Drain olayları ve pending pod nedenlerini inceleyin. |
| Taşınan YAML çalışmıyor | Sağlayıcıya özel storage/identity bağımlılığı. | Annotation, class ve IAM eşleşmelerini karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Çalışma kipini açık belirtin.
- Node upgrade pilotu yapın.
- Pod kimliklerini test edin.
- IP büyümesini hesaplayın.
- Başka kümeye restore yapın.
- Tüm bağımlı servis maliyetlerini dahil edin.
İlgili kavramlar
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.