Kubernetes Sunucu Kiralama: Cluster ve Maliyet Rehberi

Kubernetes sunucu kiralama, konteyner tabanlı uygulamalar için bir veya daha fazla fiziksel ya da sanal sunucunun Kubernetes cluster mimarisine uygun seçilmesi ve işletilmesidir. Kurumlar bu modeli web uygulamalarını ölçeklemek, mikroservisleri ayırmak ve kontrollü dağıtımlar yapmak için değerlendirebilir. Ancak yalnız birkaç sunucu kiralamak Kubernetes yönetimi, yüksek erişilebilirlik, kalıcı depolama veya 7/24 destek hizmetinin otomatik olarak sağlandığı anlamına gelmez.

Kısa cevap: Önce uygulamalarınızın CPU/RAM tüketimini, veri ve ağ bağımlılıklarını, beklenen eş zamanlı trafiği ve kesintiye dayanıklılığını ölçün. Sonra control plane ve worker kaynaklarını, node hata alanlarını, ağ politikasını, depolama ve yedekleme hedefini ayrı ayrı planlayın. Satın alacağınız hizmetin yalnız altyapı mı yoksa yönetilen Kubernetes işletimi mi olduğunu yazılı teklifte netleştirin. Mevcut bir cluster'ı taşırken uygulama sürümleri ve veri geri dönüşü birlikte sınanmalıdır.

1. Kubernetes ne işe yarar, her projeye gerekli midir?

Kubernetes, konteynerleştirilmiş iş yüklerinin istenen duruma göre dağıtılması, güncellenmesi ve izlenmesi için kullanılan bir platformdur. Pod, Deployment, Service ve diğer nesneler uygulama parçalarının nerede ve kaç kopyayla çalışacağını tanımlar. Resmî Kubernetes platform açıklaması ölçekleme, servis keşfi, güncelleme ve hata sonrası yeniden zamanlama gibi yeteneklerin nasıl sunulduğunu anlatır.

Bununla birlikte Kubernetes bir veritabanı, hazır yedekleme ürünü, otomatik güvenlik sertifikası veya tüm işletim hizmetlerini tek pakette sunan platform değildir. Küçük bir web uygulaması için tek sanal sunucu ve basit dağıtım hattı daha ekonomik ve yönetilebilir olabilir. Birden çok servis, yoğun sürüm çıkışı, ekip ayrımı ve kapasite dalgalanması başladığında Kubernetes'in operasyon maliyeti daha anlamlı hale gelebilir.

Özellikle e-ticaret ve web uygulamaları çözümlerinde kampanya trafiği, ödeme servisleri, arka plan işler ve veritabanı bağımlılıkları ayrı değerlendirilmelidir. Kubernetes seçimini popülerlik üzerinden değil, ölçülen teknik ihtiyaç ve işletme ekibinin yetkinliği üzerinden yapın.

2. Control plane, worker node ve etcd neyi yönetir?

Bir Kubernetes cluster, yönetim kararlarını veren control plane ile uygulama podlarını çalıştıran worker node kaynaklarından oluşur. Control plane API sunucusu, planlayıcı ve denetleyici bileşenlerini içerir; etcd, cluster durumuyla ilgili kritik verileri saklar. Worker node üzerinde konteyner çalışma zamanı ve pod yönetim bileşenleri bulunur. Resmî cluster mimarisi bu ayrımı açıklıyor.

Bu mimariyi teklif ederken yönetim ve uygulama trafiği arasındaki sorumlulukları açık yazın. Control plane'in yedeklenmesi, worker kaynaklarının işletimi, container runtime güncellemeleri, sertifika yenilemeleri, API erişimi, gözlemlenebilirlik ve cluster sürüm yükseltmeleri aynı hizmet olmayabilir.

Bir node'un çalışıyor görünmesi uygulamanın sağlıklı olduğu anlamına gelmez. Pod hazır olma kontrolleri, arka plan kuyruklarının tüketimi, dış servislerin erişimi ve gerçek kullanıcı isteği seviyesi ayrıca izlenmelidir. Kurumun kendi sistem ekibi bu katmanları yönetemiyorsa operasyonu ayrı fiyatlandırmak gerekir.

3. Kubernetes için VPS mi dedicated sunucu mu kiralanmalı?

Daha küçük test ve geliştirme ortamlarında uygun VPS veya bulut sunucu kiralama seçenekleri değerlendirilebilir. Sürekli yüksek CPU/RAM tüketimi, ağ ayrımı ve özel disk gerektiren üretim ortamlarında dedicated fiziksel sunucu kiralama seçenekleri incelenebilir. Tek başına donanımın ayrılmış olması, node'ların arızada otomatik ve kayıpsız çalışacağını garanti etmez.

Mimari birden çok lokasyonu veya mevcut fiziksel sunucuları kapsıyorsa özel bulut ve hibrit altyapı yaklaşımı değerlendirilebilir. Teklifte node sayısını değil, gerçek iş yükü kapasitesi ve gelecekteki arıza senaryosunu esas alın.

4. Yüksek erişilebilirlik için kaç Kubernetes node gerekir?

HA, tek komutla etkinleşen mutlak kesintisizlik değildir. Üretim için control plane çoğunlukla birden fazla node üzerinde planlanır ve uygun ön uç erişimiyle birlikte çalışır. Kubeadm'in yüksek erişilebilirlik kurulum rehberi stacked control plane ve dış etcd olmak üzere farklı topolojileri ele alır; bu kurulum rehberi kendi ön koşullarını ve yedeklilik gereksinimlerini belirtir.

Tek node cluster test amacıyla kurulabilir. Buna karşılık kritik uygulamalar için birden çok control plane, yeterli worker kapasitesi ve fiziksel hata alanlarının ayrılığı düşünülmelidir. Üç sanal node'un aynı fiziksel sunucuya, aynı depolama denetleyicisine veya tek ağ cihazına bağlı olması beklenen dayanıklılığı azaltır.

Arıza tatbikatında tek worker kaybı, control plane erişim kaybı, depolama hatası, DNS kesintisi ve planlı yükseltme koşullarını ayrı deneyin. Kullanıcı isteğinin başarılı olması için uygulamanın kendi veritabanı ve bağlantı bağımlılıkları da ayakta olmalıdır. Cluster kurulu olması, finansal veya ticari kayıp riskini sıfırlamaz.

5. CPU, RAM ve request/limit değerleri nasıl boyutlandırılır?

Kubernetes podlarının CPU ve bellek gereksinimleri request ve limit kavramlarıyla tanımlanabilir. Request, zamanlayıcının podu yerleştirirken kullandığı kapasite beklentisini; limit ise çalışma sırasında uygulanabilen sınırı ifade eder. Resmî pod kaynak yönetimi belgeleri bu farkı ve bellek sınırı aşıldığında oluşabilecek süreç sonlandırmalarını açıklar.

Kapasite hesabında toplam iş yükü request değerlerini, sistem bileşenlerinin tüketimini, bakım sırasında boşta kalması gereken rezervi, ek sidecar konteynerlerini ve beklenen yatay büyümeyi dikkate alın. Kullanıcıların az olduğu saatte görülen CPU ortalamasına göre bütün cluster'ı boyutlandırmak kampanya veya batch yoğunluğunda kaynak yetersizliği doğurabilir.

Ölçüm için gerçek CPU çekirdek zamanı, bellek çalışma kümesi, bellek taşması, pod başlangıç süresi, ağ trafiği, disk gecikmesi ve pod yeniden başlatma sayılarını kaydedin. Node başına teorik RAM toplamı, uygulama için tamamının tahsis edilebilir olduğu anlamına gelmez.

6. Kalıcı depolama, PVC ve veritabanı güvenliği

Kubernetes podları yeniden oluşturulabilir; ancak kalıcı uygulama verisinin aynı kolaylıkla yeniden üretilebildiği varsayılmamalıdır. PersistentVolume, PersistentVolumeClaim ve StorageClass; uygulamanın depolama ihtiyacını tanımlamak ve uygun depolama çözümüyle ilişkilendirmek için kullanılır. Kubernetes StorageClass belgeleri dinamik disk sağlama yöntemini anlatır.

Yerel NVMe, ağ depolaması veya harici veritabanı seçenekleri farklı gecikme, çoğaltma ve kurtarma davranışlarına sahiptir. Her depolama sürücüsü aynı snapshot, expansion veya çoklu node erişim yeteneğine sahip değildir. Veritabanını StatefulSet içine koymak otomatik yedek veya veri bütünlüğü garantisi oluşturmaz.

Veritabanı, medya yüklemeleri, oturum verileri ve kimlik bilgileri için ayrı saklama ve kurtarma politikaları belirleyin. Canlı PVC ile ilişkili snapshot, kümeden bağımsız yedeklemenin yerine geçmez. Kurumun RPO/RTO değerleri yazılı olmadan belirli bir geri dönüş süresi taahhüt etmeyin.

7. Ağ güvenliği: CNI, NetworkPolicy, ingress ve TLS

Kubernetes ağında podlar arası iletişim, servis erişimi, dış internet çıkışı ve yönetim API'sine erişim ayrı güvenlik sınırlarıdır. NetworkPolicy, uygun ağ eklentisi (CNI) tarafından desteklenmesi koşuluyla belirli trafik akışlarını sınırlandırabilir. Resmî NetworkPolicy açıklaması uyumlu CNI olmadan yalnız kural nesnesi oluşturmanın ağ trafiğini engellemeyeceğini belirtir.

Namespace kullanmak her durumda güçlü bir güvenlik veya müşteri izolasyonu sınırı değildir. Role-Based Access Control (RBAC), sınırlı servis hesapları, gizli bilgi yönetimi, pod güvenlik politikaları, uygun TLS sonlandırması ve ağ denetimi birlikte tasarlanmalıdır. Özellikle Kubernetes API sunucusunu ve yönetim araçlarını internete kontrolsüz biçimde açmayın.

Yük dengeleyici, reverse proxy, ingress ya da Gateway API seçimi altyapıya ve sürüme bağlıdır. Ağ güvenliği, VPN ve firewall hizmetleri ile Kubernetes içindeki NetworkPolicy'nin hangi riski kimin yöneteceği teklif içinde ayrılmalıdır.

8. Yatay ölçekleme ve güncelleme: neden tek başına yeterli değil?

Horizontal Pod Autoscaler (HPA), belirli metriklere göre uygulama kopyalarının sayısını ayarlayabilir. Kubernetes HPA belgeleri kaynak request değerlerinin ve kullanılabilir metrik altyapısının önemini açıklar. Yeni pod başlatılabilmesi, node üzerinde yeterli kaynak veya ayrıca node kapasitesini artıran bir mekanizma gerektirir.

2026'daki Kubernetes 1.37 teknik açıklamasında uygun harici/nesne metrikleriyle sıfır replika ölçekleme desteğinin beta olduğu anlatılır. Bu, bütün HTTP uygulamalarının otomatik olarak sıfır kopyaya indirilebileceği anlamına gelmez; bekleyen isteklerin korunması ve soğuk başlatma süresi ayrıca tasarlanmalıdır.

Rolling update ve geri dönüş politikasında uygulama sürümünün yanı sıra veritabanı şeması, migration ve API uyumluluğu kontrol edilmelidir. Otomatik dağıtım olsa bile ödeme, stok veya kullanıcı oturumu gibi kritik akışlarda gözlem ve gerektiğinde güvenli rollback gerekir.

9. Kubernetes yedekleme: etcd ile uygulama verisi farklıdır

etcd, cluster nesneleri ve yönetim durumuna ilişkin verileri saklar. Resmî etcd işletim rehberi yedekleme ve uygun geri yükleme süreçlerinin önemini vurgular. Ancak etcd yedeği, podların kullandığı harici veritabanı veya PersistentVolume içeriğinin tam yedeği değildir.

Bu nedenle iki ayrı kapsam belirleyin: cluster konfigürasyonunun geri kazanılması ve uygulamanın veriyle birlikte geri döndürülmesi. Versiyonlanmış manifest/Helm ayarları, registry erişimi, secret yönetimi, PVC verisi, veritabanı tutarlılığı ve dış servis kimlikleri de kurtarma senaryosuna dahildir.

Kritik sistemler için yedekleme ve felaket kurtarma hizmetlerinin teklifte hangi katmanı kapsadığı açıkça yazılmalı; bağımsız hedef ve izole ortamda restore testi planlanmalıdır. Cluster'ı yeniden kurabilmek ve müşteri sipariş verisini eksiksiz geri getirebilmek aynı başarı ölçütü değildir.

10. Yönetilen Kubernetes ile altyapı kiralama arasındaki fark

Bir sağlayıcı yalnız fiziksel/sanal kaynak kiralayabilir. Başka bir teklif node işletim sistemi, Kubernetes kurulumu, CNI, ingress, sürüm yükseltmesi, izleme, güvenlik güncellemesi ve olay müdahalesini içerebilir. Sözleşmedeki kapsam değiştikçe toplam iş yükü ve sorumluluk matrisi değişir.

Örneğin gece alarm veren dolu PVC, sertifikası süresi dolan ingress veya pod scheduling sorunu için kimin müdahale edeceği önceden belirlenmelidir. Yönetilen hizmetin kapsamına yedekleme, cluster yükseltmesi, uygulama kodu hatası ve veritabanı kurtarma otomatik olarak dahil sayılmaz. Yönetilen sunucu hizmetleri bu operasyon sınırlarını belirlemek için karşılaştırma noktasıdır.

Gizli anahtarlar, kubeconfig erişimi ve servis hesaplarının yetkileri müşterinin ve sağlayıcının ayrı sorumluluklarında tutulmalıdır. İşten ayrılan çalışanların erişimini kapatma, olağanüstü değişiklikleri kaydetme ve yönetici yetkilerini düzenli gözden geçirme süreçlerini teklif aşamasında sorun.

11. Kubernetes sunucu kiralama maliyeti nelerden oluşur?

Maliyet yalnız node sayısı veya vCPU fiyatıyla belirlenmez. Control plane, worker kaynakları, kullanılabilir depolama, internet çıkışı, yük dengeleme, lisanslı bileşenler, günlük loglar, yedek saklama, izleme ve operasyon emeği farklı kalemlerdir. Aynı miktarda CPU/RAM sunan iki mimari, yedeklik ve yönetim farklı olduğu için aynı hizmet değildir.

İlk karşılaştırmada mevcut cluster maliyetini, üçüncü taraf yönetilen hizmet bedelini ve kurum içi ekip zamanını ayrı ayrı hesaplayın. Kaynaklar düşük kullanım gösterdiği için bütün node'ları kapatmak mümkün olmayabilir; control plane ve kritik servisler için sabit kapasite ihtiyacı kalabilir.

12. Satın alma öncesi Kubernetes teknik kontrol listesi

1. Uygulamaları stateless, stateful, batch ve kritik servisler olarak ayırın.
2. Gerçek CPU/RAM ve ağ yükünü, tepe kullanımı ve büyüme planıyla ölçün.
3. Control plane ve worker rollerini, node/zone hata alanlarını belirleyin.
4. İş yükü request/limit değerlerini, kaynak rezervini ve ölçekleme eşiğini yazın.
5. Depolama sürücüsü, PVC erişim türü ve kurtarma ihtiyaçlarını doğrulayın.
6. CNI, NetworkPolicy, TLS, RBAC ve yönetici VPN erişimini test edin.
7. Secret, konteyner imajı ve yazılım tedarik zinciri sorumluluğunu belirleyin.
8. etcd yedeğini, veritabanı/PV yedeğinden ayrı tasarlayın.
9. Node kaybı, sürüm yükseltmesi, rollback ve veri geri yükleme tatbikatı yapın.
10. Hizmetin yalnız sunucu mu yoksa yönetilen Kubernetes mi olduğunu sözleşmeye yazın.

Bu liste otomatik bir kurulum reçetesi değildir; Kubernetes sürümü, uygulama mimarisi ve güvenlik politikası doğrulanmadan üretim değişikliği yapılmamalıdır. Gerçek teklif için mevcut node ve pod envanteri ile operasyon sorumluluklarının paylaşılması gerekir.

Sık sorulan sorular

1. Kubernetes sunucu kiralama için dedicated sunucu şart mı?

Hayır. Kubernetes uygun sanal veya fiziksel sunucular üzerinde çalışabilir. Dedicated seçimi daha öngörülebilir kaynak veya özel donanım gereksinimlerinde düşünülebilir. Performans ve işletim modeli ölçülen iş yüküne göre belirlenmelidir.

2. Tek sunucuya Kubernetes kurmak üretim için yeterli mi?

Tek sunucu test veya düşük riskli senaryolara uygun olabilir; fakat tek hata noktası taşır. Kritik iş yüklerinde control plane, worker, ağ ve depolama yedekliliği ayrı tasarlanmalıdır. Yalnız bir node'u cluster diye adlandırmak kesintisizlik garantisi değildir.

3. Üç worker node kullanmak yüksek erişilebilirliği garanti eder mi?

Hayır. Worker node sayısı yanında control plane, etcd, depolama, yük dengeleyici, uygulama kopyaları ve fiziksel hata alanları önemlidir. Üç node aynı fiziksel depolamaya bağlıysa ortak arıza riski devam eder.

4. Kubernetes StatefulSet veritabanını otomatik yedekler mi?

Hayır. StatefulSet ve kalıcı disk tanımları veri kullanımını organize eder; veritabanının tutarlı, farklı hata alanında saklanan ve geri yüklenebilen yedeğini otomatik garanti etmez. Ayrı yedek ve restore testleri gerekir.

5. Kubernetes NetworkPolicy tanımlamak yeterli ağ güvenliği sağlar mı?

Hayır. NetworkPolicy'nin uygulanması için onu destekleyen ağ eklentisi gerekir. Ayrıca API erişimi, TLS, RBAC, gizli bilgiler, container izinleri ve dış firewall/VPN kontrolleri değerlendirilmelidir.

6. Kubernetes HPA kullanmak sunucu faturasını otomatik düşürür mü?

Her zaman değil. HPA uygulama pod sayısını değiştirebilir; altyapı node kapasitesi ayrıca yönetilmelidir. Control plane, depolama ve sabit kapasite maliyetleri devam edebilir. Gerçek tasarruf ölçümle doğrulanmalıdır.

7. Kubernetes sunucusu kiralarken lisans veya destek dahil midir?

Tek bir standart paket yoktur. Açık kaynak Kubernetes kullanılması, işletim sistemi, üçüncü taraf ağ/depolama yazılımı, izleme, destek veya yönetilen hizmetin otomatik ücretsiz olduğu anlamına gelmez. Tüm bileşenleri yazılı teklif ve sorumluluk matrisiyle doğrulayın.

Kubernetes altyapınız için teknik keşif ve teklif

Kubernetes sunucu kiralama kararında önce uygulama sayısı, pod kaynak ihtiyaçları, control plane/worker topolojisi, ağ bağlantıları, kalıcı veri boyutu, hata toleransı ve destek modelini paylaşın. Bunun ardından VPS, dedicated veya hibrit kaynakların güvenlik, işletilebilirlik ve toplam maliyet açısından uygunluğunu değerlendirmek mümkündür.

Netsun Bilişim'in sağlayabileceği sunucu, ağ, depolama, güvenlik ve yönetim kapsamı teknik keşif ile yazılı teklif sonucunda kesinleşir; bu içerik belirli bir Kubernetes yönetilen platformu, hazır HA kurulumu, fiyat veya SLA garantisi vermez. Kubernetes sunucu altyapısı ihtiyacınız için teklif alın.