Yönetilen Kubernetes
Uygulamalarınızı Kubernetes'e taşıyın, altındaki her katman hazır gelsin
Siparişiniz onaylandığında cluster'ınız ağı, yük dengeleyicisi, genel IP adresi ve özel imaj deposuyla birlikte kendiliğinden kurulur. Tam yetkiyle, alıştığınız araçlarla dağıtırsınız ve verileriniz Türkiye dışına çıkmaz.
Neden şimdi
- Servisleriniz birkaç sanal sunucuya dağılmış container'larla çalışıyor ve her yayın elle yapılıyor. Bir sunucu kapandığında üzerindeki servisler de duruyor; Kubernetes'te aynı servisler node'lara yayılır, biri düşünce kopyası başka bir node'da açılır.
- Kampanya sabahı sipariş servisi yük altında yavaşlıyor, aynı sunucudaki raporlama servisi de kaynağı paylaşıyor. Kubernetes'te her servis ayrı ölçeklenir; yalnız yük alan servise kopya eklenir.
- Kendi kurduğunuz cluster'da kontrol katmanı tek bir sunucuda duruyor; o sunucu yeniden başlarken kimse dağıtım yapamıyor. Bu üründe kontrol katmanı üç node'da çalışır ve biri düşünce API yanıt vermeye devam eder.
- Genel imaj deposunun çekme sınırı yeni ortam kurulumlarını yarıda bırakıyor, ekip saatlerce bekliyor. Burada cluster bileşenleri ve genel imajlar Nesnet'in kendi deposundan ve önbelleğinden gelir.
- Bir müşteriniz verisinin Türkiye'de kalmasını sözleşmeye yazdı ve yurt dışındaki Kubernetes hizmetiniz bu şartı karşılamıyor. Nesnet cluster'ları Türkiye'deki iki veri merkezinde çalışır; veri ülke dışına çıkmaz.
Neler değişir
| Bugün | Nesnet ile |
|---|---|
| Ağ, yük dengeleyici, depolama ve imaj deposu ayrı ayrı kurulur; cluster haftalar sonra hazır olur. | Sipariş onaylandığında bütün katmanlar tek akışta kurulur; ilk cluster yarım saatten kısa sürede kullanıma açılır. |
| Kontrol katmanı tek sunucuda durur; o sunucu giderse dağıtım da gider. | Üç control-plane node'dan biri kaybedilse de API çalışır ve kubeconfig adresiniz değişmez. |
| Her yeni servis için ayrı genel IP, ayrı kural ve ağ ekibine ayrı talep gerekir. | Servisi LoadBalancer olarak tanımlarsınız; genel IP ve yük dengeleme kendiliğinden gelir. |
| Kubernetes sürüm yükseltmesi bir hafta sonu projesine dönüşür. | Yükseltmeyi portaldan başlatırsınız; worker'lar yeni sürümle açılan node'larla değiştirilir. |
| Destek talebiniz ağ, depolama ve Kubernetes sağlayıcıları arasında dolaşır. | Cluster'ı ve altındaki katmanları aynı Nesnet ekibi kurar ve işletir; sorunu tek bir yere, Nesnet destek ekibine bildirirsiniz. |
Bugünden canlıya: nasıl işler
- 1
Keşif görüşmesi
Kaç cluster'a, hangi node boyuna ve kaç worker'a ihtiyacınız olduğu Nesnet ekibiyle bir görüşmede netleşir. Mevcut container'larınızı ve manifestlerinizi birlikte gözden geçirir, taşımanın sırasını belirlersiniz.
- 2
Teklif ve sipariş
Teklif cluster, worker node ve yük dengeleyici satırlarından oluşur. Sipariş onaylandığı anda kurulum sizden ayrıca bir istek beklemeden başlar.
- 3
Cluster kendiliğinden kurulur
Ağ geçidi, çıkış IP'si, ağ, yük dengeleyici ve cluster Nesnet'in otomasyonuyla sırayla açılır. Portalda durum hazır olduğunda admin yetkili kubeconfig dosyasını indirirsiniz.
- 4
İlk dağıtım
İmajlarınızı özel depoya gönderir, uygulamanızı kubectl ya da Helm ile dağıtır ve servisinizi LoadBalancer ya da Ingress ile dışarıya açarsınız. Mevcut bir sistemi taşıyorsanız önce kritik olmayan bir servis yeni cluster'da denenir.
- 5
Büyüme ve yükseltme
Yük arttıkça worker havuzlarını büyütür ya da yeni havuz eklersiniz; yeni Kubernetes sürümü çıktığında yükseltmeyi portaldan başlatırsınız. Altındaki platformun yamaları Nesnet ekibi tarafından düzenli uygulanır.
Neler alırsınız
Yarım saatte hazır cluster
Sipariş onaylandığı anda kurulum kendiliğinden başlar; ağ geçidi, çıkış IP'si, ağ, yük dengeleyici ve cluster tek bir otomasyon akışında sırayla açılır. Nesnet'in ölçümünde ilk cluster bütün bu katmanlarla birlikte yaklaşık 22 dakikada kullanıma hazır oldu.
API'niz tek bir sunucuya bağlı kalmaz
Üretim cluster'larında kontrol katmanı üç ayrı node üzerinde çalışır; biri kaybedilse de Kubernetes API yanıt vermeye devam eder. API adresi sabit bir sanal IP'de durduğu için kubeconfig dosyanızı node değiştikçe güncellemeniz gerekmez.
Servisinizi tek satırla internete açın
Bir servisi LoadBalancer tipinde tanımladığınızda yük dengeleyicide sanal servis açılır ve servise Nesnet'in kendi adres bloğundan bir genel IP atanır. Yük dengeleyici her cluster'a dahil gelir; ayrı bir cihaz siparişi ya da ağ ekibine talep gerekmez.
Tek adresten birçok servis
Ingress kurallarıyla dışarıdan gelen HTTP ve HTTPS trafiği alan adına ve yola göre cluster içindeki doğru servise yönlendirilir. Onlarca mikroservisiniz olsa da her biri için ayrı bir genel IP ayırmanız gerekmez.
Pod taşınsa da veri yerinde
Veritabanı ve dosya tutan uygulamalarınız kalıcı disklerini node'un üzerinde değil, dağıtık NVMe depolamada tutar. Pod başka bir node'a geçtiğinde diski de yeni node'a bağlanır; uygulama kaldığı yerden aynı veriyle açılır.
Yanlışlıkla silinen disk verisini korur
Cluster açılırken varsayılan depolama sınıfının dosya sistemini (ext4 ya da xfs) ve geri alma politikasını siz seçersiniz. Retain seçildiğinde PersistentVolumeClaim silinse de disk yerinde kalır ve içindeki veri elle geri alınabilir.
İşe göre ayrı worker havuzları
Web, arka plan işi ve veritabanı gibi farklı yükler için ayrı worker havuzları açar, her havuzun node boyunu, sayısını ve disk boyutunu ayrı belirlersiniz. Havuzlar portaldan eklenip büyütülür; yoğun bir dönemde yalnız ihtiyaç duyan havuza node eklenir.
Küçük başlayın, büyüdükçe node ekleyin
Worker node'lar S (2 vCPU, 4 GB RAM), M (4 vCPU, 8 GB) ve L (8 vCPU, 16 GB) boylarında gelir. Bir test ortamı birkaç küçük node ile başlar, üretim büyük node'larla büyür; worker sayısı cluster tanımındaki tek bir değerle değişir.
Kubernetes sürümünü portaldan yükseltin
Yeni bir Kubernetes sürümü kullanılabilir olduğunda cluster bilgisinde yükseltme seçeneği görünür ve tek bir işlemle başlatılır. Worker'lar yerinde yamalanmaz, yeni sürümle açılan node'lar eskilerinin yerini alır; işlem sürerken cluster listesinde ilerleme göstergesi görünür.
İmajlarınız size ait bir depoda
Cluster ile birlikte yalnız kurumunuza açık bir özel imaj deposu gelir ve gönderdiğiniz her imaj güvenlik açıklarına karşı taranır. Bilinen bir açığı taşıyan imajı üretime almadan önce görür, düzeltilmiş sürümü derleyip yeniden gönderirsiniz.
Dış depo kesintisi kurulumu durdurmaz
Herkese açık imaj depolarından çektiğiniz imajlar Nesnet'in kendi deposundaki önbellekten gelir ve her yeni ortam için yeniden indirilmez. Dış bir deponun çekme sınırı ya da kesintisi, kampanya günü açmanız gereken yeni ortamı yarıda bırakmaz.
Alıştığınız araçlarla tam yetki
Cluster'ın tam yetkili kubeconfig dosyasını portaldan alır, kubectl, Helm ve bugünkü manifestlerinizle hiçbir değişiklik yapmadan çalışırsınız. Operatör, CRD ya da kendi denetleyicinizi kurmak için kimseden izin istemeniz gerekmez.
Bütün cluster'larınız tek ekranda
Geliştirme, test ve üretim cluster'larınızın kuruluyor ya da hazır durumunu, control-plane ve worker sayılarını bulut portalında tek ekranda görürsünüz. Kurulumun hangi aşamada olduğunu sormak için e-posta yazmanız ya da destek talebi açmanız gerekmez.
Veritabanı ve kuyruk aynı portaldan
Yönetilen Uygulamalar ile PostgreSQL, MySQL, MongoDB ve Redis gibi veritabanları, kuyruk ve analitik motorlarıyla birlikte aynı portaldan doğrudan cluster'ınıza kurulur. Uygulama ile veritabanı aynı ağda konuşur; veritabanı için ayrı bir sunucu kurup işletmeniz gerekmez.
Ofis ağınızla çakışmayan adresler
Pod ve servis ağları, şirket ağlarında yaygın kullanılan özel adres bloklarının dışındaki aralıklardan adres alır. Ofisinizi cluster'a VPN ile bağladığınızda adres çakışması yüzünden ağ planınızı baştan yazmanız gerekmez.
Servisler arası trafiği kurallarla sınırlayın
Ağ politikalarıyla hangi pod'un hangi servisle konuşabileceğini siz belirlersiniz; örneğin ödeme servisine yalnız sipariş servisi ulaşır. Kurallar standart Kubernetes nesneleri olarak yazılır ve uygulamanızın manifestleriyle birlikte sürümlenir.
Her ekibe yalnız kendi alanı
Ad alanları ve rol tabanlı erişim denetimiyle (RBAC) her ekibe yalnız kendi uygulamalarını görme ve değiştirme yetkisi verirsiniz. Bir geliştiricinin test ortamındaki yetkisi, üretimdeki servise dokunma yetkisi anlamına gelmez.
Yapay zekâ işleri için GPU'lu node
Model çıkarımı ve görüntü işleme gibi işler için cluster'a GPU'lu bir worker havuzu eklenebilir. GPU isteyen pod'lar yalnız bu havuza yerleşir; diğer servisleriniz standart node'larda çalışmaya devam eder ve GPU kaynağını boşuna tüketmez.
Yanlış bir silme cluster'ı baştan kurdurmaz
Ad alanlarınız ve kalıcı diskleriniz S3 uyumlu nesne depolamaya her gün yedeklenir; gerektiğinde tek bir ad alanı ya da disk geri yüklenir. Yanlışlıkla silinen bir deployment ya da bozulan bir veri, cluster'ı yeniden kurmadan geri gelir.
Cluster'ınızın sağlığını izleyin
Node'ların işlemci, bellek ve disk kullanımı ile pod yeniden başlatmaları İzleme ve Uyarılar ürününde takip edilir; eşik aşıldığında uyarı alırsınız. Kapasite eklemeye tahminle değil, ölçülen kullanıma bakarak karar verirsiniz.
Neden Nesnet
Verileriniz Türkiye'de kalır
Cluster'larınız, kalıcı diskleriniz ve imajlarınız Equinix İstanbul (Dudullu) ve Türk Telekom Ankara veri merkezlerindeki Nesnet altyapısında durur. Verinin hangi ülkede tutulduğunu müşterinize sözleşmede açıkça yazabilirsiniz.
Cluster'ı ve altını aynı ekip kurar
Bulut portalı, sanal ağ, yük dengeleyici, imaj deposu ve cluster aynı Nesnet ekibinin otomasyonuyla kurulur; arada başka bir tedarikçi yoktur. Ağda ya da depolamada çıkan bir sorun da Nesnet'in sorumluluğundadır.
Nesnet kendi ürünlerini aynı platformda çalıştırır
Nesnet'in abonelikle sunduğu yazılım ürünleri ve www.nesnet.com, müşterilere teslim edilen Kubernetes altyapısının aynısında çalışır. Size kurulan cluster da aynı otomasyondan çıkar; Nesnet'in kendi işini taşıyan yolu kullanırsınız.
Standart Kubernetes, kilit yok
Cluster upstream uyumlu, standart Kubernetes'tir; Nesnet'e özgü bir kaynak türüne ya da araca bağlanmazsınız. Manifestleriniz ve Helm chart'larınız başka bir ortamda nasıl çalışıyorsa burada da öyle çalışır, ayrılırken de yanınızda gelir.
Kendi IP alanı, iki operatörlü bağlantı
Servislerinizin dışa açılan adresleri Nesnet'in kendi IP alanından gelir ve Nesnet internete iki ayrı üst operatör üzerinden bağlanır. Servisinizin adresi başka bir sağlayıcının adres havuzuna ya da tek bir hatta bağlı kalmaz.
Tek aylık fatura, e-Fatura
Cluster, worker node ve yük dengeleyici kalemleri tek bir aylık faturada, e-Fatura biçiminde gelir. Yurt dışı kartla ödeme takibi muhasebe ekibinizin işi olmaktan çıkar.
Örnek senaryolar
Sanal sunuculardaki container'lar tek cluster'da
Durum
Bir yazılım ekibi servislerini birkaç sanal sunucuda container olarak çalıştırıyor. Her yayın elle yapılıyor, bir sunucu kapandığında üzerindeki servisler de duruyor ve trafik elle başka sunucuya çevriliyor.
Sonuç
Ekip üç control-plane ve üç M boy worker ile bir cluster alıyor; servisler node'lara yayılıyor, düşen bir kopya başka bir node'da kendiliğinden açılıyor. Dışa açılan servisler LoadBalancer ya da Ingress ile yayınlanıyor, imajlar özel depoda taranıyor.
Geliştirme ve üretim ayrı cluster'larda
Durum
Abonelikle yazılım satan bir firma geliştirmedeki denemelerin üretimi etkilemesinden çekiniyor. Aynı cluster'da ad alanlarıyla ayırmak kaynak tüketimi ve erişim yetkileri açısından yetmiyor.
Sonuç
Geliştirme için S boy, üretim için L boy worker'lı iki ayrı cluster açılıyor; her biri kendi yük dengeleyicisiyle geliyor. CI/CD Hattı ile push geliştirme cluster'ına, onaylı sürüm üretime gidiyor; veritabanı üretimde Yönetilen Uygulamalar ile yedekli kuruluyor.
Kampanya haftasında yalnız sipariş servisi büyüyor
Durum
Bir e-ticaret ekibinin sipariş servisi kampanya haftasında olağan günlerin birkaç katı istek alıyor. Aynı sunuculardaki raporlama ve yönetim servisleri de bu sırada kaynak istiyor.
Sonuç
Kampanyadan önce worker havuzuna node ekleniyor ve sipariş servisinin kopya sayısı artırılıyor; diğer servisler olduğu gibi kalıyor. Hafta bitince havuz eski boyuna iniyor; eklenen node'lar faturada kendi satırlarında görünüyor.
Yurt dışından Türkiye'ye taşınan yazılım ürünü
Durum
Bir yazılım firmasının ürünü yurt dışındaki bir bulutta Kubernetes üzerinde çalışıyor. Yeni bir kurumsal müşteri, verisinin Türkiye'de durmasını sözleşmeye şart olarak yazıyor.
Sonuç
Aynı manifestler ve Helm chart'larıyla Nesnet'te bir cluster ayağa kalkıyor; önce test ortamı taşınıp deneniyor. Geçiş günü DNS kaydı yeni yük dengeleyiciye çevriliyor, eski ortam geri dönüş için bir süre açık tutuluyor.
Genel depo sınırına takılan kurulumlar
Durum
Bir ekibin yeni ortam kurulumları genel bir imaj deposunun çekme sınırına takılıp yarıda kalıyor. Aynı imajlar her ortam için tekrar tekrar dışarıdan indiriliyor.
Sonuç
Cluster bileşenleri Nesnet'in imaj deposundan geliyor; ekibin kullandığı genel imajlar da o deponun önbelleği üzerinden çekiliyor. Dış deponun sınırı ya da kesintisi yeni ortamın açılmasını engellemiyor.
Kim neyi yapar
| Nesnet | Siz |
|---|---|
| Cluster'ı ağı, ağ geçidi, çıkış IP'si, yük dengeleyicisi ve genel IP'leriyle birlikte kurar. | Uygulamalarınızın manifestlerini, Helm chart'larını ve dağıtımını siz yönetirsiniz. |
| Altındaki bulut portalını, sanal ağı, depolamayı ve fiziksel sunucuları işletir; platform yamalarını düzenli uygular. | Ad alanlarını, erişim yetkilerini (RBAC), ağ politikalarını ve uygulama sırlarını siz tanımlarsınız. |
| Özel imaj deposunu, güvenlik taramasını ve genel depolar için önbelleği sağlar. | Pod'larınızın kaynak limitlerini ve sağlık kontrollerini (readiness, liveness) siz belirlersiniz. |
| Yönetim katmanını müşteri iş yüklerinden ayrı bir ortamda tutar. | Kaç worker'a ve hangi node boyuna ihtiyaç duyduğunuza siz karar verirsiniz. |
| Yeni Kubernetes sürümlerini portalda yükseltme seçeneği olarak sunar. | Sürüm yükseltmesinin zamanını siz seçer, uygulamanızı yeni sürümde siz doğrularsınız. |
Kimler için
Kubernetes bilen yazılım ekipleri
Kubernetes'i bilen ama cluster'ın altındaki ağı, depolamayı ve yük dengelemeyi kurmakla vakit kaybetmek istemeyen ekipler. Bu katmanlar cluster ile aynı akışta hazır gelir; ekip ilk gün dağıtıma geçer.
Ortamlarını ayrı tutmak isteyenler
Geliştirme, test ve üretimi ayrı cluster'larda tutmak isteyen ekipler. Her cluster kendi yük dengeleyicisi ve genel IP'leriyle açılır; bir ortamdaki deneme ötekine sıçramaz.
Abonelikle yazılım satan firmalar
Kubernetes, özel imaj deposu, dağıtım hattı ve nesne depolamayı aynı sağlayıcıda, aynı ağda toplamak isteyen yazılım firmaları. Müşterilerine verinin Türkiye'de durduğunu yazılı olarak söyleyebilirler.
Kubernetes ekibi olmayan geliştiriciler
Cluster yönetimini öğrenmeye vakti olmayan geliştirici ekipleri. CI/CD Hattı ile birlikte kurulduğunda push test ortamına, onaylanan sürüm üretime çıkar.
Sanal sunuculardan container'a geçenler
Servislerini birkaç sanal sunucuya dağıtmış, her yayını elle yapan ekipler. Aynı imajlar Kubernetes'te node'lara yayılır, düşen kopya kendiliğinden yeniden açılır ve tek komutla ölçeklenir.
Uygun olmayabilir
Tek bir web uygulaması, API ya da statik site yayınlayan ve cluster görmek istemeyen ekipler. Bu durumda Nesly Sunucusuz Platform daha uygundur; kodunuzu push edersiniz, node ya da kubeconfig ile hiç karşılaşmazsınız.
Kubernetes'e taşınacak container'ı olmayan, tek bir sunucuda çalışan klasik uygulamalar. Bu durumda Sanal Sunucular daha uygundur; uygulama bugünkü hâliyle bir sanal makineye taşınır.
Altyapının içi
Cluster'lar bulut portalındaki Kubernetes eklentisiyle, Kubernetes'in kendi cluster yaşam döngüsü standardı (Cluster API) üzerinden kurulur; düğümler kurumsal destekli bir Kubernetes dağıtımının imajlarıyla açılır. API uç noktası sabit bir sanal IP'de tutulur, pod'lar arası ağ standart bir CNI eklentisiyle kurulur. LoadBalancer tipindeki servisler platformun yük dengeleme katmanında sanal servis olarak açılır; kalıcı diskler CSI sürücüsüyle dağıtık NVMe depolamadan gelir. Bileşen imajları Nesnet'in kendi imaj deposundan çekilir. Nesnet bu katmanların üstüne kendi otomasyonunu ekler: organizasyon, ağ geçidi, çıkış (egress) IP'si, ağ, yük dengeleyici ve cluster tek bir akışta kurulur ve cluster açıldığında imaj deposu da kullanıma hazırdır.
Yapı taşları
- Bulut portalı ve API
- kiracı portalı; cluster'ın çalıştığı kaynak alanı
- Kubernetes yaşam döngüsü eklentisi
- portaldan cluster kurulumu, büyütme, sürüm yükseltme ve silme (Cluster API)
- Kurumsal Kubernetes dağıtımı
- uyumlu Kubernetes sürümleri ve düğüm imajları
- Yük dengeleme katmanı
- LoadBalancer servisleri için sanal servis
- Pod ağı (CNI)
- pod'lar arası ağ ve ağ politikaları
- Sabit API adresi
- control-plane API için tek bir sanal IP
- İmaj deposu ve tarama
- kurumunuza ait depo, güvenlik taraması, genel depolar için önbellek
- Dağıtık NVMe depolama
- kalıcı disklerin durduğu depolama
Diğer seçeneklerle karşılaştırma
| Seçenek | Ne zaman doğru seçim |
|---|---|
| Kendi sanal sunucularınıza Kubernetes kurmak | Her bileşenin sürümünü ve ayarını kendiniz seçmek istiyorsanız ve cluster'ı ayakta tutacak deneyimli bir ekibiniz varsa doğru seçimdir. Nesnet'in Sanal Sunucular hizmeti bu kurulum için taban olabilir; ağ, yük dengeleyici ve depolama entegrasyonu sizde kalır. |
| Nesly Sunucusuz Platform | Bir web uygulaması, API ya da statik site yayınlıyorsanız ve cluster yönetmek istemiyorsanız daha az iş çıkarır. Derleme, adres ve HTTPS platformda hazırdır. |
| Yurt dışındaki çok bölgeli bir bulutun Kubernetes hizmeti | Kullanıcılarınız birçok kıtaya dağılmışsa ve verinin Türkiye'de kalması gibi bir şartınız yoksa, birden çok bölgede cluster açabilen bir sağlayıcı daha uygun olabilir. |
Teknik özellikler
| Kubernetes | Standart, upstream uyumlu |
|---|---|
| Varsayılan Kubernetes sürümü | 1.33.1 |
| Kurulum | Portaldan, bildirimsel cluster yaşam döngüsüyle |
| Worker güncellemesi | Node yerinde yamalanmaz, yenisiyle değiştirilir |
| Control-plane node (üretim varsayılanı) | 3 |
|---|---|
| Worker node (üretim varsayılanı) | 3 |
| Control-plane API adresi | Sabit sanal IP |
| S | 2 vCPU · 4 GB RAM · 50 GB disk |
|---|---|
| M | 4 vCPU · 8 GB RAM · 100 GB disk |
| L | 8 vCPU · 16 GB RAM · 200 GB disk |
| Pod ağı / servis ağı | 100.96.0.0/11 / 100.64.0.0/13 |
|---|---|
| LoadBalancer servisi | Yük dengeleyici üzerinde sanal servis |
| Servis genel IP'si | Nesnet IP alanından, /32 tahsis |
| Yük dengeleyici | Her cluster'a bir tane, otomatik |
| Varsayılan StorageClass | ext4, CSI, silmede disk de silinir (Delete) |
|---|---|
| Cluster açılışında seçilebilir | Geri alma Delete ya da Retain; dosya sistemi ext4 ya da xfs |
| Depolama katmanı | Tamamı NVMe |
| Sürüm yükseltme | Portaldan, yeni sürüm kullanılabilir olduğunda |
|---|---|
| Worker havuzları | Birden çok; her biri ayrı sayı, disk ve politika |
| Cluster boyutlandırma | Havuzların yeniden boyutlandırılmasıyla |
| Ingress | TCP / HTTP / HTTPS yönlendirme |
| Ölçülen kurulum süresi | Yaklaşık 22 dakika (ağ, yük dengeleyici ve IP dahil; 1 control-plane + 1 worker ile ölçüldü) |
|---|---|
| Veri merkezleri | Equinix İstanbul (Dudullu), Türk Telekom Ankara; veri Türkiye'de kalır |
Bir şey bozulursa
Bir control-plane node'u kapanırsa
Üç control-plane node'dan biri kaybedildiğinde cluster'ın durum veritabanı kalan iki node ile çoğunluğu korur ve Kubernetes API çalışmaya devam eder. Sanal IP çalışan bir node'a geçtiği için kubeconfig adresi değişmez.
Bir worker node bozulursa
Bozuk worker yerinde onarılmaz. Yeni bir node sanal makinesi açılır, eskisi kaldırılır; pod'lar sağlam node'larda yeniden zamanlanır.
Pod başka bir node'a geçerse
Kalıcı diskler node'un üzerinde değil, bulut depolamasında durur. Pod yeni bir node'a geçtiğinde CSI sürücüsü diski o node'a bağlar ve veri yerinde kalır.
Fiziksel bir sunucu arızalanırsa
Node'lar Nesnet bulutunda sanal makine olarak çalışır ve platformda yüksek erişilebilirlik açıktır. Fiziksel sunucu arızasında bu sanal makineler platformdaki diğer sunucularda yeniden başlatılır, misafir işletim sistemi yanıt vermezse sanal makine yeniden başlatılır.
Sık sorulan sorular
Fiyatlandırma ve ilk adım
Fiyatlandırma
Yönetilen Kubernetes kullandığınız kaynağa göre aylık faturalanır. Fatura bir cluster birimi ile S, M ya da L boyundaki worker node birimlerinden oluşur; node'ların vCPU, bellek ve diski sanal sunucu kaynaklarıyla aynı satırlarda sayılır. Her cluster'a bir yük dengeleyici eklenir; teklifinizi Nesnet ekibi bu kalemlere göre hazırlar.
Fiyatı belirleyenler
- Worker node sayısı ve boyu (S, M, L)
- Cluster sayısı; örneğin geliştirme ve üretimin ayrı cluster'larda tutulması
- Her cluster'a eklenen yük dengeleyici
- Cluster'a kurulan veritabanı ve kuyruk uygulamalarının worker'larda tükettiği vCPU, RAM ve disk
Nasıl başlarsınız
- 1.Formu doldurun ya da 0800 606 1071'i arayın.
- 2.Cluster sayısı ve node boyu bir görüşmede netleşir; teklif bu satırlarla hazırlanır.
- 3.Sipariş onaylanınca cluster kurulur, kubeconfig dosyanızı portaldan indirirsiniz.
Cluster'ı Nesnet kursun, ekibiniz ürüne odaklansın
Kaç cluster ve hangi node boyu gerektiğini Nesnet ekibine anlatın; aynı iş günü içinde dönüş yapılır. Ağ, yük dengeleme, depolama ve imaj deposu cluster ile birlikte gelir, verileriniz Türkiye'de kalır.