Kubernetes 2.0 nasıl bir şey olurdu?

 (matduggan.com)
4 puan yazan GN⁺ 2025-06-21 | 2 yorum | WhatsApp'ta paylaş
  • Kubernetes, son 10 yılda konteyner orkestrasyonu alanındaki yeniliğe öncülük etti
  • Mevcut YAML yapılandırması, etcd bağımlılığı, Helm paket yönetimi gibi alanlarda çeşitli sınırlamalar ve iyileştirme ihtiyaçları gözlemleniyor
  • HCL’nin benimsenmesi, takılabilir depolama, yeni bir paket yöneticisi (KubePkg), IPv6’nın varsayılan hale gelmesi gibi başlıklar Kubernetes 2.0’daki değişim unsurları olarak tartışılıyor
  • Bugünkü açık yapı önemli olsa da, varsayılanlar ve resmi yön gösterimi ekosistem inovasyonu üzerinde belirleyici etki yaratıyor
  • Kubernetes’in, sürekli ve yıkıcı iyileştirmeler yoluyla daha geniş kullanıcı ve organizasyonlara uygun hale gelmesi gerektiği ortaya konuyor

Kubernetes’in 10 yılı: başarı ve sınırlar

Başlangıç ve büyüme

  • 2012~2013’te Google içindeki Linux konteyner sistemi Borg hakkında söylentiler sysadmin topluluğuna yayılmaya başladı
  • 2014’te Kubernetes duyuruldu; ilk zamanlarda adı bile telaffuzu zor bir isimdi
  • Microsoft, RedHat, IBM, Docker gibi büyük şirketlerin hızla katılmasıyla Kubernetes ekosistemin standardı haline gelmeye başladı
  • 2015’te v1.0’ın yayımlanması ve CNCF’nin kuruluşuyla birlikte gerçek anlamda açık bir ekosistem oluştu

Başlıca yenilik noktaları

Konteynerlerin büyük ölçekte yönetimi

  • Kubernetes, konteyner tabanlı yazılım geliştirme ve dağıtım için ölçeklenebilirlik sağladı
  • Basit geliştirme ortamlarından binlerce sunucuya uzanan büyük ölçekli, aynı ortam dağıtımlarını mümkün kıldı
  • Kurumlar, monolitik yapıdan dağıtık mikroservislere geçiş için önemli bir zemin buldu

Düşük maliyetli bakım ve kendini iyileştirme

  • Sunucu yönetimi, "Simpsons" (her sunucuya takma ad verilen, elle işletilen) döneminden "UUID" (tamamen değiştirilebilir, otomatikleştirilmiş, stateless) dönemine hızla geçti
  • Makine ömrü, OS destek süresi gibi kavramlar neredeyse ortadan kalktı; arıza durumunda “node’u yeniden oluşturma” ile sistem otomatik toparlanır hale geldi
  • Birçok Linux becerisi artık zorunlu olmaktan çıkıp “olsa iyi olur” seviyesine geldi

Batch işleri ve Job yönetimi

  • Geçmişte “yalnızca cron için ayrılmış kutulara” dayanan batch işleme, kuyruk tabanlı otomasyon işleri ve yeniden deneme mekanizmalarıyla değiştirildi
  • İş başarısız olduğunda otomatik yeniden başlatma ve esnek işleme sayesinde operasyonel verimlilik ve geliştirici memnuniyeti ciddi biçimde arttı

Servis keşfi ve yük dengeleme

  • IP adreslerini sabit yazmak yerine dahili DNS tabanlı servis adlandırma sistemi benimsendi
  • API, sabit IP ve hostname ile servisler arası bağlantılar basitleştirildi; dış servisler de iç servisler gibi ele alınabilir hale geldi

Kubernetes 2.0: temel iyileştirme önerileri

YAML’den HCL’ye: yapılandırma dilinin değişmesi

YAML’in sınırları

  • YAML görünüşte okunması kolay ve JSON ile XML’den daha iyi gibi dursa da, hata üretme eğilimi, tip desteği eksikliği ve zor hata ayıklama gibi ciddi sorunlar barındırıyor
  • Örnek: Norveç sorunu (NO değerinin false olarak yorumlanması), girinti hataları, sayı ve string karışıklığı gibi çok sayıda arıza kaynağı içeriyor

Alternatif: HCL’nin benimsenmesi

  • HCL (HashiCorp Configuration Language), Terraform’un standart formatı olarak güçlü tip sistemi, doğrulama, fonksiyonlar ve koşullu dallanma gibi üstün özellikler sunuyor
  • Zaten kayda değer sayıda Kubernetes kümesi Terraform ile birlikte HCL kullanıyor
  • HCL; tip güvenliği, tekrarın azaltılması, dinamik ayarlar, yineleme, koşul mantığı, güçlü yorum desteği, modülerlik ve geçerlilik kontrolü gibi alanlarda YAML’den daha kuvvetli özelliklere sahip
  • Açık kaynak lisans uyumluluğu konusu (MPL 2.0 → Apache 2.0 uyumu) hâlâ sürse de, kalite artışı için taşıdığı değer yeterince büyük
Örnek: HCL vs YAML
  • Tipler, değişkenler, fonksiyonlar, koşullar ve döngüler gibi HCL avantajları sayesinde yapılandırma hataları baştan önlenebilir; bakım kolaylaşır ve karmaşık ortamlarda tutarlılık sağlanır

etcd yerine alternatiflerin desteklenmesi

  • etcd güçlü bir çözüm olsa da, küçük kümelerde veya düşük donanımlı ortamlarda gereğinden fazla kaynak tüketebiliyor
  • Kine gibi takılabilir backend’lerin resmi olarak desteklenmesiyle varsayılan veri deposu esnekliğinin artırılması gerektiği savunuluyor
  • Örnek: k8s-dqlite: dağıtık SQLite+Raft ile hafif ve esnek bir veri katmanı sunuyor

Helm’in ötesine geçmek: yerel bir paket yöneticisi

Helm’in sınırları

  • Helm, geçici bir hack çözümünün standarda dönüşmüş hali olarak; şablon karmaşıklığı, zor hata ayıklama, bağımlılık/sürüm çakışmaları ve yetersiz doğrulama gibi çeşitli sorunlar taşıyor
  • Birden fazla chart’ın yinelenmesi, sürüm uyumsuzlukları, namespace’ler arası kurulum zorlukları, chart arama/metadata eksikliği, semantik sürümlendirmeye uyumsuzluk ve güvensiz CRD yönetimi gibi pek çok pratik sorun yaşanıyor

Yeni paket sistemi önerisi: KubePkg

  • Kubernetes kaynakları biçiminde paketleri, bağımlılıkları, semantik sürümleri, güvenliği, yaşam döngüsünü ve metadata’yı kapsayıcı biçimde yönetir
  • Gelişmiş yaşam döngüsü hook’ları, durum ve yedekleme/kurtarma stratejileri, deklaratif yapılandırma, doğrulanabilir imzalama süreçleri, audit kayıtları ve kurumsal politika denetimleriyle tam donanımlı olması önerilir
  • Linux paket yöneticilerinin güçlü yanlarını devralarak gerçek altyapı yönetiminde yüksek güvenilirlik ve tutarlılık sağlamayı hedefler

Başlıca gereksinimler

  1. Tamamen Kubernetes’e özgü yerel kaynak yapısı
  2. Durumlu uygulamalar için yerleşik destek
  3. İmzalama/doğrulama/güvenlik taraması süreçlerinin güçlendirilmesi
  4. Yapısal deklaratif yapılandırma + şema doğrulama
  5. Tüm yaşam döngüsünün kontrolü ve kolay Upgrade/Hook desteği
  6. Linux tarzı bağımlılık/sürüm çözümleme
  7. Değişiklik geçmişi ve denetim izi
  8. Kurum bazlı politika uygulayabilme
  9. Tanıdık Linux paket yönetimi UX’i

Varsayılanın IPv6’ya çevrilmesi

  • Bugün IPv6 ve dualstack desteklense de varsayılan hâlâ IPv4
  • Kümeler arası iletişim, NAT sorunları ve IP kıtlığı gibi problemleri çözme; daha basit ağ yapısı ve yerleşik IPSec gibi avantajlar sunma potansiyeli var
  • Çok sayıda IP gerektiren ortamlarda (örnek: /20 aralığı, 40 node, node başına 30 pod) IPv4 sınırına hızla ulaşılıyor
  • Public IPv6 ortamlarında işletimin sadeleşmesi, bulut kullanıcılarının kazanılması ve özel adres alanı yönetim yükünün azalması gibi pratik faydalar açık

Sonuç: değişim ihtiyacı ve varsayılanların gücü

  • “Bu açık bir platform, topluluk kendi yolunu bulur” görüşü bulunsa da, varsayılanlar sektörün davranış biçimini yönlendirir
  • Kubernetes 2.0 için resmi bir vizyon, iyi tasarım ve güçlü varsayılanlar gereken bir dönemdeyiz
  • Sektör standardı ve küresel veri merkezi işletiminin fiili merkezi konumuna uygun yenilikçi bir sıçrama için önemli bir an
  • Mobil, web ve diğer teknoloji alanlarında cesur değişimlerin tüm ekosistemi dönüştürdüğünü daha önce defalarca gördük
  • Kubernetes’in de artık simgesel bir 2.0 ile bir sonraki adımını düşünme zamanı geldi

İlgili okumalar

2 yorum

 
kaydash 2025-06-23

Açık kaynağı bir araya getirerek oluşturulmuş vanilla k8s'i kurup işletebilecek mühendislerin gelecekte de azınlıkta kalacağını düşünüyorum.
Tıpkı Hadoop cluster'ını Cloudera platformu olarak paketlenmiş halde satın almadan, vanilla Hadoop ekosistemini işletebilen mühendislerin son derece az sayıda olması gibi.
 
GN⁺ 2025-06-21
Hacker News görüşleri

  • Kubernetes ile ilgili en büyük sorun bence bunun “kendiliğinden çalışan” bir sistem olmaması. Gerçekten production’da sorunsuz şekilde servis işletebilen mühendis sayısı az; bir de Kubernetes cluster’ını doğrudan VM’ler üzerinde kurup sürdürmek daha da zor. Bu yüzden son dönemde öne çıkan serverless girişimlerinin arkasında, bunun (1) çok zaman tükettiği, (2) çok hataya açık olduğu ve (3) production ortamında başarısız olma olasılığının yüksek olduğu yönünde yaygın bir algı var. Kubernetes 2.0’da herkesin kolayca kendi dağıtım platformunu self-host edebildiği ve güvenle kullanabildiği, ama aynı zamanda küçük ve güçlü bir orkestratör çekirdeğini koruyan bir yöne gidilmesi gerektiğini düşünüyorum. Şu anda Rivet adında bir orkestratör ve deployment platformu geliştiriyorum; bunu Rivet açık kaynak serverless platformu olarak sunuyorum ama kendi kendime sık sık “Kubernetes 2.0 nasıl bir şey olmalı?” diye düşünüyorum. İnsanların Rivet’i beklediğimden daha geniş senaryolarda kullanması da giderek artıyor. Rivet’in en büyük gücü, Kubernetes controller seviyesinde işlevleri çok kolay geliştirmeyi mümkün kılması; bu sayede oyun sunucuları, tenant başına deployment, gelişmiş iş yükü orkestrasyonu, multi-tenancy, tenant bazlı faturalandırma ve güçlü operator tasarımları gibi çok farklı senaryolarda kullanılabiliyor.

    • Bu bakış açısı bende oldukça ters etki yaratıyor. Yaş ilerledi, biraz da alaycı oldum herhalde; çünkü bunu çok sık görüyorum. X teknolojisi fazla ağır geliyor, biri de “Ben bunu kullanmadan laptop’ta basitçe çalıştırmak istiyorum” deyip Y teknolojisini yapıyor. Sonra Y de popülerleşiyor ve iş laptop dışına çıkınca ölçeklenebilirlik ihtiyacıyla bir sürü özellik eklenip ağırlaşıyor. Derken biri çıkıp “Artık Y de fazla ağır” diyerek aynı cümleyi tekrar ediyor. Bu tam bir 'Zaman Çarkı' gibi; başı da sonu da olmayan bir döngü.

    • Gerçekte ise k3s (hafif k8s) bakım açısından gerçekten çok kolay. k3s otomatik güncelleme ve uygun eviction kurallarıyla neredeyse hiç dokunmak gerekmiyor; Ceph gibi storage çözümleri zor geliyorsa Lemon ya da Longhorn gibi “sıfır yönetim” alternatifleri de var. Binlerce Helm chart mevcut, o yüzden karmaşık veritabanlarını bile 1 dakikada ayağa kaldırmak mümkün. Servis deployment’ı da sık kullanılan Helm template’lerini kullanıyorsan çok kolay. Helm kusursuz değil ama istediğin gibi kurarsan değer tamamlama gibi imkanlardan da faydalanabiliyorsun. Giriş eşiği serverless’tan biraz daha yüksek olabilir ama bir hafta öğrenip production’da gerçekten büyük paralar tasarruf etmek buna fazlasıyla değer.

    • Kubernetes’in çözdüğü problem “Bunu nasıl deploy ederim?” sorusu. Rivet’in docs’una baktım; sadece tek container, Docker Compose ve manuel deployment (docker komutları) var. Gerçekçi olarak böyle bir serverless altyapısını gerçek ölçekte bu şekilde deploy etmek mümkün mü emin değilim. İlk sorum şu olurdu: “Bu noktada Rivet’i Kubernetes üzerinde (container, kube-virt vb.) çalıştırmak mümkün değil mi?” Docker Compose’un Kubernetes’ten daha sağlam ya da daha ölçeklenebilir olabileceğini sanmıyorum. Eğer öyle değil de bulut hizmeti satılacaksa, bu da Kubernetes 2.0 fikriyle pek uyuşmuyor. Rivet’i kendim host edecek olsam, muhtemelen dokümantasyonu değiştirip Kubernetes üzerinde çalıştırılabilir hale getirirdim.

    • Cluster bakımını bulut sağlayıcısına devredip “k8s as a service” kullanıyorsan, tam olarak hangi kısmın bu kadar karmaşık geldiğini merak ediyorum. Ayar alanı geniş ama production’a alınacak bir servis için aslında çok az sayıda ayarı bilmek yetiyor. Docker Compose’dan biraz daha karmaşık bir konfigürasyonla k8s’e deploy etmek gayet mümkün. Ama çoğu uygulama için bu “biraz daha” bile gereksiz olabilir. Aslında Docker Compose tam da insanların istediği yaygın ihtiyacı karşılıyordu; sürdürülen ilginin az olması üzücü.

    • Altyapı işletiminde benim deneyimim şu: “kendiliğinden çalışan” diye bir şey hiç olmayacak. Heroku bile ölçeklenince sorun çıkarıyor. Herkesin kolayca benimseyebileceği bir deployment platformu isteniyorsa, Kubernetes’i belirli bir PaaS’ın temel primitive’i olarak görmek daha gerçekçi. Rivet ilginç; bazı açılardan BEAM ekosisteminden fikirler de taşıyor. Ben kişisel olarak devasa deployment’tan çok sağlamlık ve local-first konularına daha fazla önem veriyorum.

  • “Low maintenance” ha... EKS (managed k8s) yoğun kullanıyorum; cluster’ın durumu için doğrudan endişelenmem gerekmiyor (tabii node’ları bozmanın yaratıcı yollarını bulmam ayrı mesele). Kubernetes gerçekten “olabildiğince az bakım gerektiriyor” gibi davranıyor ama pratikte tam bir bakım yığını. Sadece yaml verip yazılımı dünyaya deploy edebilmek gerçekten etkileyici. Ama bunun bedeli de karmaşık bakım. Cluster kurulumu, ArgoCD bootstrap’i, hub-spoke modelinde diğer cluster’ları kaydetmek sadece sirkin ilk sahnesi. Sonra CNCF Landscape tooling içinden işe yarar operator’leri kuruyorsun; bir de yan araçlar geliyor, birincil olmasalar da fiilen zorunlular ve en az 30 kadar şey dönmeye başlıyor. values.yaml ayarlamak bir iki saatlik iş değil; çoğu zaman ArgoCD ve template işleriyle uğraşıyorsun. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> bir başka values.yaml derken tek bir boolean değeri geçirmek için bile zaman harcıyorsun. Cluster/operator güncelleme döngüleri de hızlı, yani bakım işi hiç bitmiyor. Karpenter ile autoscaling yapınca node değişimi ve kesintisiz geçiş ayrı bir akrobasi oluyor (stateful uygulamalar k8s’te iki kat “eğlenceli”). Özet: gerçek “Low maintenance” ifadesi tam anlamıyla ironik.

    • “Low maintenance” sonuçta alternatiflere göre göreli bir kavram. Benim deneyimimde k8s ile aynı kalitede hizmeti sağlamak için ölçekleme, failover, rollback, disaster recovery, DevOps ve bağımsız cluster ayağa kaldırma gibi işlerin toplam bakım yükü çok daha düşüktü. Her durumda böyle olmayabilir ama benim deneyimim bu yönde.

    • Son iki yıldır hetzner üzerinde k3s kullanıyorum ve %100 uptime gördüm. Bakım yükü o kadar düşük ki bir ara master node’un SSH anahtarını bile kaybettim; buna rağmen tüm cluster’ı yeniden provision etmek, doküman güncellemesi dahil, sadece 90 dakika sürdü. Gerçekten acil olsaydı 15 dakikada bile halledilirdi. Aylık 20 euroya, biraz storage ve Cloudflare ile otomatik DNS entegrasyonu dahil, ARM tabanlı 3 node + 1 master k8s cluster’ı çalıştırıyorum.

    • Ama aslında yönettiğin şey Kubernetes’in kendisi değil; CI/CD sistemi, secret management sistemi, veritabanı operasyon otomasyonu gibi yan sistemler. Eskiden bunları yaml yerine cron job, ansible, systemd, bash script gibi şeylerle yapıyor olurdun.

    • Sanki sirki kendi ellerinle kurmuşsun. O kadar çok şey kurmamalısın. Her yeni eklenen bileşen teknik borç ve bakım maliyeti getirir; ücretsiz araçlar için de bu geçerli. Autoscaling’in getirdiği borç ve bakım maliyeti tasarruftan fazlaysa, kapatmak daha iyidir.

    • Benzer servisleri tek tek kurup işletseydin bakım yükü çok daha büyük olurdu. Buna rağmen Kubernetes, yangını çıkarıp sonra kendi haline bırakılabilecek kadar yönetimi kolay bir şey. Tabii ne yaptığını biliyor olman lazım ki “havalı görünen araçlar” kurma tuzağına düşmeyesin.

  • K8S yaml’a zorlamıyor da. Bu en idiomatic yol olabilir ama zorunlu değil. kubectl apply en başından beri json destekliyordu; endpoint de json ve grpc. jsonnet gibi çeşitli dillerden config üretmek mümkün. İkinci olarak, Helm chart’larda dependency ve dependency ordering neden bu kadar mesele oluyor merak ediyorum. Kubernetes’in temel idiomu döngüde yatıyor: bağımlılık yoksa uygulama bunu recoverable error olarak görür ve mümkün olana kadar tekrar dener. Ya da crash eder, ReplicaSet controller otomatik yeniden başlatır. Chart içinde dependency yoksa dependency çakışması da yoktur. Gerçekten bağımlı olunan bir uygulamaysa, bağımlı app/service’i Helm chart’ın içine dahil etmek daha doğru.

    • (ana görüşten alıntı) > crash durumunda ReplicaSet controller’ın uygulamayı yeniden başlatması yeterli değil. Örneğin keycloak’ın ayağa kalkması 1 dakika sürüyorsa, ona bağımlı servis keycloak olmadan hemen crash ediyor; sonra retry ederken throttle’a takılıyor ve keycloak açıldıktan sonra bile 5-10 dakika boşuna bekliyor. Eğer bağımlılık ilişkisi netse, ana container’a geçmeden önce init container ile bağımlı servisin hazır olduğunu kontrol etmek daha uygun. Kubernetes’te açık bir start dependency tanımlama özelliği olsa güzel olurdu. Crash edip birkaç kez tekrar denedikten sonra throttle yemek çözüm değil. Dependency diye bir gerçeklik var.

    • Bana göre bağımlılık hataları mutlaka recoverable olmalı. Geçmişte aslında kullanılmayan bir dependency yüzünden fail-closed davranıştan kaynaklanan bir kesinti yaşadım. Sunucular arası bağımlılıkların neredeyse hepsi soft dependency. Downstream dependency çalışmıyorsa uygulama 500 döner, load balancer da unhealthy sunucudan kaçınır.

    • “supposed to” diyorsunuz ama bu daha çok in-house yazılım stack’i kurulan durumlar için iyi çalışıyor. Docker desteği olan eski yazılımların sonradan Kubernetes’te çalıştırılabilir hale getirildiği çok örnek var. Geliştirici kendi felsefesine göre araç yapar ama insanlar yine kendi istedikleri şekilde kullanır ve sonuç bazen tam karmaşa olur. Sonuçta insanlara çeşitli özellikler ve seçenekler vermek zorundasın; piyasa da onu istediği gibi kullanır.

    • “Kubernetes’in temel mimari özelliği = reconciliation loop” sözüne çok katılıyorum. Mevcut durumu gözlemle, istenen durumla arasındaki farkı bul, sonra sadece o fark kadar uygula. Ve bunu sonsuza kadar tekrar et. Başarı/başarısızlık yok; sadece mevcut durumla hedef durum arasındaki farkı iteratif olarak çözmek var. Bu desenin, PID kontrol gibi makine kontrol sistemlerindeki 'good enough technology' yaklaşımına benzediğini düşünüyorum.

    • “yaml yerine json da kullanılabilir” diyerek bu konuyu eleştirmek bence meseleyi kaçırmak. Kimsenin gerçekten önemsediği nokta bu değil. Gereksiz bir takılma gibi geliyor.

  • yaml’ı HCL ile değiştirme fikrine kesinlikle karşıyım. HCL geliştirici açısından zor, okuması da güç. Import desteği, debug zorluğu gibi kullanılabilirlik tarafında çok şikayetim var. Neden protobuf benzeri bir arayüz tanım dilini merkeze koyup, kullanıcıların istediği forma dönüştürmesine imkan verilmediğini anlamıyorum.

    • HCL berbat. k8s yaml’ı bana hiçbir zaman yetersiz gelmedi. Eğer konfigürasyon bu kadar karmaşıksa, sorun config map’ten çok uygulamanın tasarımındadır.

    • Aslında HCL, JSON ya da YAML fark etmez; istemci tarafında serialize/deserialize etmek yeterli. Yani bu Kubernetes’in kendi sorunu değil, sadece dış bir dönüşüm katmanı.

    • Kubernetes arayüz tanımları zaten protobuf tabanlı (CRD’ler hariç).

    • HCL ile ilgili asıl şikayetim for loop sözdizimi. Gerçekten korkunç.

    • “HCL geliştiriciler için zor, lint ya da debug etmek güç” denmesi bana daha çok yeni bir şey öğrenmek istememek gibi geliyor. Sanki karmaşık bir alanı öğrenme zorluğu ile HCL öğrenmeyi karıştırıyorlar.

  • “Kubernetes 2.0” tarzında nebulous projesini geliştiriyorum (hala pre-alpha aşamasında). Hedef; dünya genelinde dağıtık ve hafif bir yapı, laptop’ta tek binary olarak çalışabilme ama bulutta binlerce node’a kadar ölçeklenebilme, Tailnet ağ yapısı, BitTorrent storage, multi-tenancy, live migration vb. Gereksinimlerin çoğu ML operasyonlarından, özellikle de GPU kıtlığından doğdu; gelecekte ML sıradanlaştığında bu yaklaşım da varsayılan hale gelebilir.

    • Live migration ilginç. Biz şu anda birden fazla cluster ve bulut arasında autoscaling tabanlı fiyatlandırma stratejisi kullanıyoruz; live migration ise tamamen başka bir zorluk seviyesi.

    • Bu Kubernetes değil, GPU operasyonuna özel ayrı bir sistem.

    • “Küresel dağıtık” yapı aslında bir non-requirement bile olabilir. Tailnet’i varsayılan ağ olarak kullanıyorsan, benim ilk çıkarmak isteyeceğim özellik bu olurdu. Kubernetes’in tek NIC varsayımı bulut odaklı sıkıcı bir miras (çeşitli CNI’lar ve son dönemde Multus gibi projeler sevindirici; bkz: redhat blogu). Multi-tenant tasarımın k8s’ten somut farkı ne, onu merak ediyorum. Storage için BitTorrent kullanırsan ve public container image’ları da böyle paylaşırsan, egress trafik ücretleri korkunç olur.

    • GitHub’da Chart.yaml görüyorum; hatta provider_aws.yaml gibi template’ler de var, bunlar hiç görmek istemediğim kod kalıpları.

  • Kubernetes’in bugün bile gerçekten çok karmaşık olduğunu düşünüyorum. Yaygınlaşmış olması, bunu daha az hissettirdi sadece. Kubernetes 2.0’da kullanıcı deneyiminin, özellikle sık yapılan işlemlerin (uygulama deployment’ı, servisi dışarı açma, service account/image değiştirme vb.) daha sade olmasını isterim. Ama şu an her şeyin odağında LLM var; bu yüzden böyle bir devam geliştirmesi zor görünüyor.

    • Kubernetes’te çok fazla soyutlama katmanı var. Pod’lar harika bir temel kavram ama deployment, rep set, namespace gibi şeyler eklenince insan Docker Swarm kadar basit olmasını diliyor. Terraform da tek katmanlıydı ve öğrenmesi kolay gelmişti. K8s’in öğrenme eğrisinin gerçekten ne kadar dik olduğunu yeni yeni fark ediyorum.

    • Bu, “bilgisayar programlarındaki tür ayrımı insanın algısal bir sonucu” diye düşündüren bir mesele. Operator/controller yapısı geçmişteki COM/CORBA gibi aşırı soyutlanmış hissettiriyor (hem iyi hem kötü anlamda). Basit uygulamalar için daha kısıtlı bir k8s-lite daha uygun olabilir. Öte yandan, karmaşık ortamlarda mevcut k8s soyutlamaları bile yetersiz kalabiliyor. Tek bir sistemin (ister Kubernetes 2.0 ister başka bir şey olsun) gerçek dünyadaki tüm sorunları sarıp sarmalayarak insanların geliştirebileceği veya tasarlayabileceği bir seviyede kalıp kalamayacağından emin değilim.

  • “Sane default”, yani özel bir seçim yapmasan bile ağ/storage/load balancer gibi konularda varsayılan olarak yeterince mantıklı gelen bir sistem istiyorum. yaml da HCL de hoşuma gitmiyor. Daha iyi bir config yöntemi gerekli ve sadece dili değiştirmekle çözülecek bir problem de değil. IPv6’nın kesinlikle gerekli olduğunu düşünüyorum. Docker, container ve Kubernetes iç yapıda IPv6-only olmalıydı; IPv4 ise ingress controller seviyesinde istisna olarak ele alınmalıydı.

    • “Sane defaults” ile “managed servis müşterisine dönüştürme” arasında doğası gereği bir gerilim var. K8s’i ne kadar uzun izlersem, storage/networking gibi konularda “batteries not included” felsefesinin o kadar güçlendiğini ve AWS/GCP gibi şirketlerin bunu pahalı entegrasyon servisleri olarak sattığını görüyorum. Fiiliyatta gerçek dünya K8s’i bazen açık kaynak olmaktan çok, bulut boşluklarını dolduran ürünlerin satışını artıran bir araç gibi duruyor.

    • (kişisel deneyim) Terraform/HCL’nin YAML’a göre daha iyi yanı, görünmez karakterlere dayanmaması nedeniyle daha okunaklı olması.

    • Tam da bu “sane defaults” yüzünden k3s bana çok daha çekici geliyor.

  • Bir 2.0 sürümü için bu istek listesi biraz mütevazı kalıyor. Çevremdeki herkes production k8s karmaşıklığından şikayetçi. Geriye dönük uyumlulukla sadeliği aynı anda nasıl sağlayacağımız asıl mesele. Genelde backward compatibility yüzünden karmaşıklık patlıyor; yeni sistem hem eskiyi hem yeniyi taşımak zorunda kalıyor.

    • Sonuçta tartışma, “karmaşıklığı nereden ve ne kadar azaltabiliriz?” sorusuna dönüyor. Şimdiye kadar gördüğüm çoğu k8s soyutlaması ya çok küçük bir alanı kapsıyor (Heroku tarzı wrapper’lar) ya da kendi DSL’ini getirip öğrenme eğrisini daha da yükseltiyor (sonunda hem karmaşık k8s’i hem de ek bir DSL’i öğrenmek gerekiyor).

  • Ben zaten Terraform ile cluster ve uygulamaları yönetirken “Kubernetes 2.0 dünyasında” yaşadığımı hissediyorum.

    • HCL/type/resource dependency/data manipulation imkanlarını doğrudan kullanabiliyorum
    • tf apply ile cluster, node’lar, bulut entegrasyonları (S3 vb.) ve cluster içindeki servisleri tek seferde kurabiliyorum
    • Terraform module ile kodu yeniden kullanıyor, k8s dışı altyapıyı da birleştiriyorum. Örneğin Cloudflare ZeroTrust module’ü ile 5 satır kodla public SSO endpoint’i sağlayabiliyorum. (cluster’a cloudflared deploy edip Cloudflare API tunnel config’i kurarak)
    • Büyük altyapı sağlayıcıları kendi Terraform module’lerini iyi hazırlamış durumda; provider lockfile ile module/provider dependency yönetimi de rahat
    • Helm Terraform provider ile Helm chart’ları da rahatça yönetiyorum. Özellikle sadece “namespace oluştur + operator deploy et + custom resource oluştur” işi yapan chart’larda, operator’ü kurup CRD’leri Terraform’dan doğrudan yönetiyorum
    • Eksisi, apply sürecinin orchestration’ı biraz zahmetli (YAML tarafında da benzer); biz bunu Spacelift ile çözüyoruz
    • Aslında sistem durumunu hem k8s state hem Terraform state olarak iki kez yönetmek verimsiz. Kaynaklar mutating webhook vb. ile değişirse “computed fields” ayarı da gerekiyor. Bu yüzden uygulama seviyesindeki yönetimi Terraform’da tercih etmiyorum. Ama cluster’ın kendisini Terraform ile yönetmek bence gayet mantıklı.

  • Frontend geçmişinden geldiğim için Kubernetes bana oldukça sezgisel gelmişti. Daha önce veri girdileriyle reaktif olarak UI oluşturuyordum; şimdi ise kontrol düzlemindeki resource ve config’leri hedef duruma getiren kod yazıyormuşum gibi geliyor.