Özet: Vanilla Kubernetes, CNCF tarafından sürdürülen upstream Kubernetes projesinin hiçbir vendor eklemesi veya çıkarması olmadan kurulmuş halidir. Maksimum esneklik ve vendor lock-in olmaması karşılığında üretim için yüksek operasyonel sorumluluk getirir; HA control plane, etcd yedekleme, CNI, CSI, ingress ve güvenlik bileşenleri tamamen ekibinizin yükümlülüğündedir. Çoğu kurum için yönetilen Kubernetes (KaaS) en düşük TCO'yu sunar.
Ana noktalar:
- Vanilla Kubernetes upstream kubernetes/kubernetes deposundan kubeadm ile kurulur ve hiçbir vendor eklentisi içermez.
- Üretim sınıfı bir vanilla küme için tipik olarak 2-4 SRE/DevOps mühendisinden oluşan özel bir platform ekibi gerekir.
- kubeadm yalnızca minimum çalışan bir küme oluşturur; CNI, CSI, ingress, izleme ve güvenlik bileşenleri sizin sorumluluğunuzdadır.
- Yönetilen Kubernetes (KaaS), vanilla'nın API uyumunu korurken operasyonel yükü sağlayıcıya devreder.
- Türkiye veri merkezinden çalışan KaaS, KVKK uyumunu doğrudan adresleyen en pratik yoldur.
Kubernetes etrafında o kadar çok dağıtım, ürün ve yönetilen hizmet var ki yeni bir BT yöneticisi için sınırları çizmek zorlaşıyor. EKS, AKS, GKE, OpenShift, Rancher, k3s, k0s, KubeSpray, RKE2 — hepsi "Kubernetes" diyor ama özelliklerinden lisans yapılarına, yönetim modellerinden kullanım amaçlarına kadar belirgin farklılaşıyorlar. Bu kalabalığın içinde "vanilla Kubernetes" terimi, herhangi bir vendor müdahalesi olmadan, doğrudan yukarı akış (upstream) kaynağından derlenmiş saf Kubernetes'i ifade eder.
Vanilla Kubernetes, hem teknik özgürlüğün hem operasyonel sorumluluğun zirvesidir: hiçbir vendor sizi belirli bir yola sokmaz ama aynı zamanda hiçbir vendor sizin elinizi tutmaz. Bu rehber, vanilla Kubernetes'i değerlendiren mimarlar ve DevOps liderleri için somut bir karar çerçevesi sunuyor: ne zaman vanilla doğru tercihtir, ne zaman bir dağıtım veya yönetilen hizmet daha verimlidir, gerçek operasyonel maliyet nedir ve Türkiye'de hangi seçenekler mevcuttur.
Sonunda Cloud4U Türkiye Managed Kubernetes (KaaS) hizmetinin, vanilla'nın esnekliğini yönetilen hizmetin operasyonel sadeliğiyle nasıl birleştirdiğini göreceksiniz.
Vanilla Kubernetes nedir?
Vanilla Kubernetes, CNCF (Cloud Native Computing Foundation) tarafından sürdürülen upstream Kubernetes projesinin doğrudan, hiçbir vendor eklemesi veya çıkarması olmadan kurulmuş halidir. "Vanilla" kelimesi yazılım dünyasında "düz, eklentisiz, varsayılan" anlamında kullanılır; tıpkı vanilyalı dondurmanın temel referans tat olması gibi.
Upstream Kubernetes projesinin tanımı
Upstream Kubernetes, CNCF (Cloud Native Computing Foundation) çatısı altında kubernetes/kubernetes GitHub deposunda geliştirilen, dünya genelinde binlerce geliştiricinin katkı sağladığı açık kaynak çekirdektir. Her üç ayda bir minör sürüm (1.32, 1.33, 1.34...) yayımlanır. Bu çekirdek API sunucusu (kube-apiserver), zamanlayıcı (kube-scheduler), denetleyici (kube-controller-manager), kubelet, kube-proxy ve etcd bağımlılığından oluşur. Vanilla derken kastedilen tam olarak budur.
kubeadm ile vanilla kurulum
Vanilla Kubernetes kurulumunun en yaygın yolu, resmi Kubernetes dokümantasyonunda ayrıntılı olarak belgelenen kubeadm aracıdır. kubeadm init ile control plane'i ayağa kaldırır, kubeadm join ile worker düğümleri eklersiniz. Kurulum sade ve eğiticidir; her bileşenin nereye yerleştiğini, sertifikaların nasıl oluşturulduğunu doğrudan görürsünüz. Ancak kubeadm sadece "minimum çalışan bir küme" kurar — ağ eklentisi (CNI), depolama eklentisi (CSI), ingress, izleme ve güvenlik bileşenleri sizin sorumluluğunuzdadır.
Vanilla'nın felsefesi: hiçbir şey eklenmemiş, hiçbir şey çıkarılmamış
Vanilla yaklaşımının temel cazibesi, açık kaynak değerlerine sadakattir: hiçbir vendor sürpriz lisans şartı koyamaz, hiçbir vendor eklentisi sizi belirli bir ürüne kilitler. Karşılığında "kullanıma hazır" değildir; üretim ortamı için kurulması ve sürdürülmesi gereken çok sayıda ek bileşen sizin tarafınızdadır.
Vanilla vs Kubernetes dağıtımları
| Dağıtım | Tip | Hedef kitle | Vendor desteği |
|---|---|---|---|
| Vanilla (kubeadm) | Saf upstream | Uzman ekip, öğrenme | Yok |
| k3s, k0s | Hafif | Edge, IoT, küçük küme | Topluluk + ticari |
| RKE2, Rancher | Üretim odaklı | Çoklu küme yönetimi | SUSE |
| OpenShift | Tam platform | Kurumsal, regüle | Red Hat |
| EKS, AKS, GKE | Yönetilen | Bulut müşterileri | Hyperscaler |
| Cloud4U KaaS | Yönetilen TR | Türk kurumlar, KVKK | Cloud4U Türkçe |
k3s ve k0s (hafif dağıtımlar)
k3s, Rancher (şimdi SUSE) tarafından geliştirilen, tek binary dosya halinde gelen hafif bir dağıtımdır. Kaynak ihtiyacı düşüktür (Raspberry Pi'de bile çalışır); edge bilgi işlem, IoT ağ geçitleri ve laboratuvar senaryoları için ideal. k0s, Mirantis tarafından sürdürülen benzer felsefede başka bir hafif dağıtımdır. Her ikisi de upstream Kubernetes API uyumudur ama paketleme ve varsayılanlar açısından farklılaşırlar.
RKE2 ve Rancher
RKE2 (Rancher Kubernetes Engine 2), üretim-odaklı, FIPS uyumlu, sertifikasyonlu bir Kubernetes dağıtımıdır. Rancher Manager arayüzü ile çoklu küme yönetimi sunar. Hem on-prem hem bulut senaryolarında çalışır; SUSE'nin ticari desteği mevcuttur.
Red Hat OpenShift
OpenShift, Kubernetes'in üzerine inşa edilmiş kapsamlı bir kurumsal platformdur. Kendi CI/CD'sini, kayıt defterini (registry), güvenlik politikalarını, operatör çatısını ve geliştirici deneyimini sunar. Banka, kamu ve regüle sektörlerde yaygın; karşılığında en yüksek lisans maliyeti ve daha "opinionated" bir yaklaşıma sahip. OpenShift'i çalıştırmak vanilla Kubernetes'i çalıştırmaktan oldukça farklıdır.
Managed servisler (EKS, AKS, GKE, Cloud4U KaaS)
Hyperscaler bulut sağlayıcıları (AWS, Azure, GCP) yönetilen Kubernetes hizmetleri sunar. Cloud4U Türkiye KaaS, aynı felsefeyi Türkiye veri merkezinden, KVKK uyumlu olarak ve Türkçe destekle sunar. Control plane sağlayıcı tarafında yönetilir; worker node'lar sizin kullanım kapsamınızda olabilir.
Vanilla Kubernetes'in avantajları
Vendor lock-in olmaması
Vanilla'nın en büyük cazibesi, hiçbir vendor sizi belirli bir yol haritasına kilitlememesidir. Lisans değişiklikleri (Broadcom-VMware örneğindeki gibi), beklenmedik fiyat artışları veya tedarikçi politika değişiklikleri sizi etkilemez. Açık kaynak çekirdek, Docker tabanlı container imajlarınızı standart bir API ile çalıştırır. Açık kaynak çekirdek size aittir; herhangi bir altyapıya — on-prem, herhangi bir bulut, edge — taşınabilir.
Topluluk hızında güncellemeler
Upstream Kubernetes her üç ayda bir minör sürüm yayımlar. Vendor dağıtımları bu sürümleri kendi sertifikasyon süreçlerinden geçirip 3-6 ay gecikme ile sunar. Vanilla kullanırsanız yeni özelliklere ve güvenlik yamalarına en hızlı erişimi siz alırsınız. Bu yetenek aynı zamanda risk de doğurur — düzgün test etmeden production'a almak ciddi sorunlara yol açabilir.
Tam kontrol ve özelleştirme
Hangi CNI'yi kullanacağınız (Calico, Cilium, Flannel), hangi ingress kontrolcüsünü tercih edeceğiniz (NGINX, Traefik, Istio Gateway), depolama eklentisi olarak ne ekleyeceğiniz (Longhorn, Ceph, Portworx) — hepsi sizin kararınızdır. Çok özel iş yükleri için bu özgürlük belirleyici olabilir.
Vanilla Kubernetes'in dezavantajları
Yüksek operasyonel yük
Vanilla Kubernetes "kurulum bittiğinde başlangıç biter" cümlesinin geçerli olduğu bir alandır. Sürüm yükseltmeleri, etcd bakımı, sertifika döngüsü, control plane yedekleme, güvenlik yaması, monitoring stack — hepsinin sahibi ekibinizdir. Tipik bir üretim vanilla kümesi için 2-4 kişilik özel bir platform ekibi gerekir.
HA, etcd, ağ ve depolama sorumluluğu sizde
Tek control plane düğümlü vanilla kurulumu sadece test ortamı içindir. Üretim için en az 3 control plane düğümü, yedeklenmiş etcd, doğru yapılandırılmış CNI, persistent volume sağlayan bir CSI ve yük dengeleyici entegrasyonu gerekir. Bu bileşenlerin her birinde "sessiz" hatalar (yanlış MTU, etcd disk yavaşlığı, yanlış IPAM havuzu) küme genelinde gizli problemlere yol açabilir.
Üretim için eksik bileşenler
Vanilla kubeadm kurulumu üretimde işe yarayan bir küme oluşturmaz; üzerine ingress, sertifika yönetimi, izleme, log toplama, RBAC politikaları, ağ politikası motoru, secret yönetimi, GitOps aracı ve yedekleme çözümü eklemeniz gerekir. Bu eklemeler bir alışveriş listesi değildir; aralarındaki uyum, sürüm uyumluluğu ve operasyon devamlılığı ayrı bir uzmanlık alanıdır.
Üretime hazır vanilla için kontrol listesi
HA control plane ve etcd yedekleme
En az 3 control plane düğümü ve harici (veya stacked) etcd kümesi kurun. etcd'nin saatlik snapshot yedeklerini başka bir lokasyona aktarın; geri yükleme tatbikatını ayda en az bir kez yapın. etcd çöktüğünde tüm küme bilgisini kaybedersiniz; bu yüzden en kritik bileşendir.
Ingress, cert-manager, sertifika yönetimi
NGINX Ingress Controller veya Traefik gibi bir ingress kontrolcüsü kurun. Let's Encrypt veya iç CA için cert-manager ile otomatik sertifika yönetimi yapılandırın. TLS yenileme yapılmadığında üretim kesintisi sürpriz değildir.
Observability (Prometheus, Grafana, Loki)
Üretim kümesi için Prometheus + Grafana metrik yığını, Loki veya ELK log yığını ve Tempo veya Jaeger trace yığını standarttır. Alert kurallarının ve dashboard'ların hazır gelmesi için kube-prometheus-stack gibi Helm chart'lar başlangıç olarak iyi bir tercihtir.
Güvenlik (RBAC, NetworkPolicy, OPA)
Cluster-wide RBAC politikalarınızı tanımlayın; her servis hesabı için en az ayrıcalık prensibini uygulayın. NetworkPolicy ile pod-pod ve namespace-namespace iletişimi kısıtlayın. OPA Gatekeeper veya Kyverno ile policy-as-code uygulayın; örneğin "tüm pod'lar resource limit'leri tanımlamalı" veya "image sadece güvenilir registry'den olabilir" gibi kuralları otomatik dayatın.
Operasyonel maliyet karşılaştırması
Vanilla için gereken SRE / DevOps saatleri
Üretim sınıfı bir vanilla Kubernetes kümesinin operasyonu için tipik olarak 2-4 SRE / DevOps mühendisi gerekir. Türkiye'de tecrübeli bir Kubernetes mühendisinin yıllık toplam maliyeti 1,5-3,5 milyon TL bandındadır. Üç kişilik bir ekip 5-10 milyon TL'lik yıllık operasyon maliyeti demektir; donanım veya bulut altyapısı bunun üzerine eklenir.
Dağıtım kullanmanın maliyeti
OpenShift, Rancher, RKE2 gibi dağıtımlar lisans veya abonelik ücreti ister ama karşılığında belirli bir kurumsal destek alırsınız. OpenShift düğüm başına yıllık abonelik birkaç bin dolardan başlar; büyük bir küme için yüz binlerce dolarlık fatura mümkündür. Lisans tasarrufunu kendi ekip maliyetinizle karşılaştırmak gerekir.
Managed Kubernetes ile TCO örneği
| Senaryo | Yıllık operasyon | Yıllık altyapı | Toplam |
|---|---|---|---|
| Vanilla on-prem (3 ekip) | 7.500.000 TL | 600.000 TL | 8.100.000 TL |
| OpenShift on-prem | 3.000.000 TL (azaltılmış ekip) | 2.500.000 TL (lisans + DC) | 5.500.000 TL |
| Yönetilen K8s (KaaS) | 1.500.000 TL (uygulama ekibi) | 1.800.000 TL | 3.300.000 TL |
Bu örnek rakamlar tek bir orta ölçekli küme içindir. Sonuç sizin senaryonuza göre değişir, ancak çoğu kurumda yönetilen Kubernetes en düşük TCO'yu sunar.
Vanilla Kubernetes ne zaman doğru seçimdir?
Yüksek özelleştirme ihtiyacı
Hiperölçekli (hyperscale) SaaS şirketleri, çok özelleşmiş ağ ve depolama gereksinimleri olan platform şirketleri, küme planlayıcısını veya scheduler'ı kendi ihtiyaçlarına göre uzatmak isteyen ekipler vanilla'dan değer çıkarır. Bu seviyede özelleştirme isteyen ekip sayısı çoğu kurumda azdır.
Air-gapped ve regüle ortamlar
İnternete bağlı olmayan (air-gapped) askeri, kamu veya regüle finans ortamlarında hiçbir bulut servisi kullanılamaz. Vanilla, böyle ortamlarda kendi imaj kayıt defterinizle ve kendi mirror'larınızla çalışan tek seçenek olabilir. Karşılığında operasyon yükü en üst seviyededir.
Öğrenme ve laboratuvar kullanımı
Kubernetes'i derinden öğrenmenin en iyi yolu vanilla'yı kubeadm ile kurmaktır. Her bileşeni manuel olarak yerleştirmek, sertifikaları görmek, etcd'yi yedeklemek — bu pratik bilgi başka şekilde edinilmez. CKA (Certified Kubernetes Administrator) sınavına hazırlık vanilla pratiği üzerinden ilerler.
Türkiye'de Kubernetes ekosistemi
Türk DevOps talent havuzu
Türkiye'de Kubernetes ekosistemi son birkaç yılda hızla olgunlaştı. İstanbul ve Ankara'daki büyük şehirlerde tecrübeli Kubernetes mühendisi bulmak mümkün ama nadir; talep arzı geride bırakıyor. Bu da vanilla operasyonu için ekip kurmayı zorlaştırıyor, yönetilen hizmetlerin değer önerisini güçlendiriyor.
KVKK uyumlu cluster mimarisi
KVKK çerçevesinde Kubernetes üzerinde çalışan uygulamaların kişisel veri işlemesi, ayrı bir uyum katmanını gündeme getirir. Verinin nerede tutulduğu, log ve audit kayıtlarının nasıl korunduğu, dış servislere veri akışının nasıl yönetildiği — hepsi proje başında planlanmalıdır. Türkiye veri merkezinden çalışan bir küme bu uyumu büyük ölçüde basitleştirir.
Türkiye veri merkezinde yönetilen K8s
Yerel yönetilen Kubernetes hizmetleri (Cloud4U Türkiye KaaS dahil), control plane'in operasyonunu üstlenirken verinin Türkiye'de kalmasını ve KVKK uyumunu garanti eder. Bu, hyperscaler bulut yönetilen hizmetlerine kıyasla en belirgin yerel avantajdır.
Sıkça sorulan sorular (SSS)
Vanilla Kubernetes ile başlamalı mıyım?
Öğrenmek için evet; üretim için ekibinizin Kubernetes operasyonu konusunda derin deneyimi yoksa hayır. Üretimde yönetilen Kubernetes veya kurumsal bir dağıtım çoğu zaman daha düşük risk ve daha düşük toplam sahip olma maliyeti (TCO) sunar.
Vanilla Kubernetes ne kadar bakım ister?
Üretim sınıfı bir küme için ayda en az birkaç gün eşdeğeri SRE çalışması — yamalama, sürüm yükseltme, izleme ve sorun giderme — gerekir. Olay (incident) yaşandığında gece nöbeti dâhil bu süre çok daha yükselir; 2-4 kişilik özel bir platform ekibi normaldir.
OpenShift vanilla mıdır?
Hayır, OpenShift Kubernetes API uyumlu olsa da kendi router'ı, DeploymentConfig objeleri, ImageStream'leri ve geliştirici arayüzü olan opinionated bir platformdur. Vanilla'nın "hiçbir şey eklenmemiş" felsefesinden belirgin biçimde uzaklaşır.
EKS / AKS / GKE vanilla mıdır?
Yakındır ama tam vanilla değildir; her hyperscaler kendi varsayılan CNI'sini, otomatik ölçekleyicisini ve kontrol düzlemi özelliklerini ekler. Uygulama uyumluluğu yüksektir; ancak Docker vs Kubernetes karşılaştırmasında olduğu gibi sınırların farkında olmak önemli.
Vanilla'dan yönetilen Kubernetes'e nasıl geçilir?
Helm chart, Kustomize manifestoları ve container imajları genelde uyumludur; geçiş çoğunlukla namespace bazlı manifesto deploy etmek kadar basittir. CNI ve depolama eklentileri farklı olabileceği için ağ politikalarını ve persistent volume claim'leri yeni ortamda mutlaka test edin.
Cloud4U Türkiye Managed Kubernetes (KaaS)
Vanilla Kubernetes'in esnekliğini ve açık kaynak özgürlüğünü kaybetmeden, operasyonel yükten ve ekip kurma maliyetinden kurtulmak istiyorsanız, Cloud4U Türkiye Managed Kubernetes (KaaS) sizin için tasarlandı.
- Türkiye veri merkezi, düşük gecikme: İstanbul veri merkezinden hizmet veren, KVKK uyumlu yönetilen K8s; yerel kullanıcılarınız için düşük gecikme.
- Otomatik güncelleme, HA ve yedekleme: Control plane yüksek erişilebilir; sürüm yükseltmeleri, etcd yedekleme ve sertifika döngüsü Cloud4U sorumluluğunda.
- Demo ve fiyat teklifi alın: Ücretsiz kavram kanıtlama (PoC) ile mevcut iş yüklerinizi gerçek ortamda deneyin; Türkçe destek ekibimizle doğrudan iletişim.
Kubernetes yatırımınızı vendor lock-in olmadan, üretim kalitesiyle hayata geçirmek için: Cloud4U Türkiye Managed Kubernetes hizmetini inceleyin ve demo görüşmesini bugün başlatın.
