İş görüşmelerinin Kubernetes hakkında öğrettikleri

• Kubernetes, küçük şirketlerde bile teknik ölçeklenebilirlikten çok dağıtım biçimini standartlaştırma ve organizasyonel işleyiş sorunlarını çözme ölçütü olarak benimseniiyor
• Yakın zamandaki iş arama sürecinde konuşulan şirketlerin hepsi Kubernetes kullanıyordu; bu durum 5 yıl önceki VM·serverless·K8s birlikte var olma tablosundan farklıydı
• CTO'ların öne çıkardığı temel nedenler; her servisi aynı şekilde dağıtabilmek, operasyon bilgisini YAML ve Helm chart'larında bırakabilmek ve GitOps ile değişiklik geçmişini takip edebilmekti
• Küçük şirketler, HPA, Pod Disruption Budget, node affinity gibi gelişmiş özelliklerden çok organizasyonel faydalar nedeniyle karmaşık Kubernetes'i göze alıyor
• Erken aşamadaki şirketlerin ürüne odaklanmak için Kubernetes olmadan başlaması daha iyi olabilir; ihtiyaç ise CTO'nun mühendisliği tek başına üstlenmediği andan itibaren büyüyor

---

Son iş arayışında görülen değişim

• Yakın zamandaki iş arama sürecinde ilanları okuyup mülakatlara girerek yaklaşık on iki mühendislik ekibiyle konuşmanın sonucu olarak, konuşulan tüm şirketlerin Kubernetes kullandığı görüldü
• 5 yıl önceki iş arayışında ise Kubernetes'i nadiren kullanan bir grup, VM/VPS/EC2 üzerinde systemd kullanan bir grup ve Lambda ile Cloud Run gibi serverless kullanan bir grup bir arada bulunuyordu
• Şu anda çalışılan yer, Big Tech ölçeğinde sorunlara sahip olduğu için Kubernetes'e açıkça uygundu; ama sadece iki servisi olan 10 kişilik bir startup'ın bile Kubernetes kullanması şaşırtıcıydı
• Konuşulan şirketler mikroservis işletmiyor ya da çok yüksek ölçeğe yakın ortamlarda değildi; Kubernetes'in teknik yönlerine de büyük ilgi göstermiyorlardı

Kubernetes'i benimseme nedenleri ve karar ölçütleri

• Neden Kubernetes kullanılıyor?

  • İlk neden uniformity idi; tüm servisler aynı şekilde dağıtıldığında, yalnızca belirli bir servisin eski bir bare VM üzerindeki bash script'lerine ya da Docker Compose'a bağlı kalması durumu ortadan kalkıyor
  • İkinci neden paylaşılabilir ve işe alınabilir bilgi idi; Kubernetes ortak bir dil gibi kullanıldığından, yalnızca Helm chart'larına ve Kube ayarlarına bakarak bile mimariyi hızlıca kavramak mümkün oluyor
  • Bilgi insanların kafasında değil de YAML içinde kaldığında, biri ayrıldıktan sonra yerine gelen kişinin çalışma biçimini anlamak için haftalar harcaması daha az olası oluyor
  • Mevcut şirketteki on-call SRE, ilk kez gördüğü servisleri bile ekipler arasında Kubernetes kalıpları benzer olduğu için sürdürebiliyor
  • Bu avantaj yalnızca yapılandırma aşırı derecede özel değilse geçerli oluyor
  • Üçüncü neden izlenebilirlik idi; kümeye doğrudan kubectl apply -f çalıştırmak yerine Helm chart'larını git'e koyup MR onayı ve ardından FluxCD veya ArgoCD dağıtımıyla ilerlenirse değişiklik geçmişi korunuyor
  • Bu akış, GitOps ve Kubernetes doğal biçimde birbirine uyduğu için neredeyse ek maliyet olmadan uyumluluğa yardımcı oluyor
  • Mevcut şirket bu yöntemle ISO sertifikasyonunu sorunsuz geçiyor

• Varılan sonuç

  • CTO'ların seçimi aptalca bir tercih değil, gerçek sorunları çözen bir yaklaşımdı
  • Kubernetes, teknik sorunlara yönelik teknik bir çözüm gibi görünüyordu; ancak birçok CTO, beklenenden daha fazla teknik olmayan faydalarla ilgileniyordu
  • Küçük şirketlerin teknik sorunları, Kubernetes'i zorunlu kılacak düzeyde değil; manifest'lerde topologySpreadConstraints, HPA, Pod Disruption Budget ya da node affinity kurallarının bulunmama ihtimali yüksek
  • Bu şirketler, VM kullandıklarındakiyle benzer sayıda node'u korurken bile organizasyonel faydalar için karmaşık bir yazılımı işletmenin maliyetini kabul ediyor

• Neden dönüşüm yakın zamanda yaşandı?

  • 5 yıl önce VM ve systemd, serverless ve Kubernetes'in hepsi seçenek olarak masadaydı; bugün ise iş ilanlarında VM + systemd kombinasyonu neredeyse kaybolmuş, serverless niş bir alan olarak kalmış ve Kubernetes kazanmış durumda
  • Dönüşümün zamanlamasının nedeni tamamen net değil
  • Olası nedenler; EKS, GKE, AKS gibi yönetilen Kubernetes hizmetlerinin olgunlaşmış olması ve Kubernetes bilen insanların sayısının yeterince artmasıyla başka yöntemler için işe alım yapmanın daha zor hâle gelmesi olabilir
  • Helm, başkalarının yaptığı chart'ları olduğu gibi kullanma seçeneğini gerçekçi bir opsiyon hâline getirdi

• Kubernetes'i ne zaman kullanırdım?

  • Kişisel ölçüt, CTO'nun artık tek mühendis olmadığı an
  • İkinci mühendis katıldığında, sunucuyu bizzat kurmamış birinin de dağıtım yapabilmesi gerekir; bunun için herkese SSH anahtarı vermek yerine uygun erişim kontrolü gerekir
  • Sonunda birileri şirketten ayrılır ve insanların sahip olduğu operasyon bilgisi de onlarla birlikte gidebilir
  • Bu noktadan sonra bilgi, insanlardan çok sistemin içinde kalmalıdır
  • Bundan önceki aşamada cluster debug etmek gerçekten zordur ve ürüne harcanması gereken enerji altyapıya gidebilir
  • Büyük bir müşteriyle görüşmeden hemen önce CrashLoopBackOff yaşayan bir pod'un nedenini iki saat boyunca aramak yerine, VPS üzerinde acilen git pull ile düzeltmek daha hızlı ve anlaşılır bir acil durum müdahalesi olabilir

[GN⁺]

Lobste.rs görüşleri

• Avrupa tarafında sebep açık. CTO'lar, K8s üzerine koyarlarsa yönetilen K8s sağlayıcısını birkaç hafta içinde değiştirebileceklerine inanıyor
  Bunun doğru olduğu anlamına gelmiyor ama gerçekten böyle düşünüyorlar. PR ortamlarının da daha kolay olacağını sanıyorlar
  Ama asıl mesele sağlayıcı değiştirme. Önümüzdeki birkaç yıl içinde ABD ile bağlantılı sağlayıcıların kullanımının yasaklanmasının gündeme gelebileceğini öngörüyorlar; özellikle GDPR, finansal sistemler vb. alanlarda bu ihtimal yüksek. Bu yüzden bu riske karşı hazırlık yapmış durumdalar

• Şirket ölçeğinden bağımsız olarak, teknoloji sektörünün yönünü tamamen kaybettiğinin kanıtı gibi görünüyor. Stack'ler giderek daha tek tip ve daha karmaşık hale geldi, sonuç olarak da dişini sıkmadan kullanabileceğin ürün ve hizmetler bulmak daha zorlaştı

  • Alt seviye katmanlar o kadar hatalı ve karmaşık ki, hayatta kalmak için sonunda Kubernetes gibi bir şey inşa etmek zorunda kalıyorsun. Stack'in daha da yükselmesini istemiyorsak, alt katmanları iyileştirmemiz gerekiyor
    Çok daha iyi işletim sistemi temel bileşenlerine ihtiyaç var. Örneğin container'lar, tutarlı bir tasarım olmadan çekirdeğin çeşitli izolasyon özelliklerinin karıştırılmasından oluşuyordu ve bu yüzden deliklerle doluydu
    Bugün container izolasyonu çok daha iyi ama bu, baştan güvenlik ve doğruluk düşünülerek tasarlanmış olmasından değil, sorun çıktıkça yamalanmış olmasından kaynaklanıyor. Kernel devasa teknik borçla yüzleşene ya da biri taşınmaya değer bir kernel yapana kadar bunun üzerine bir şeyler yığmaya devam edeceğiz

• Yeterince karmaşık her deployment aracı, sonunda geçici çözümlerle yapılmış, gayriresmî biçimde tanımlanmış, bol hatalı ve yavaş bir yarım Kubernetes uygulaması içermeye başlar

  • “Yarım” ifadesi doğru. Sadece o yarımın, tam da gereken yarım olması meselesi var
    2009'da milyar dolarlık bir SaaS e-ticaret şirketinin nasıl kurgulandığını ya da devasa bir AAA çok oyunculu oyunun çevrimiçi backend'inin nasıl çalıştığını uzun uzun anlatabilirim; bunlar tek makine deployment'ından ziyade kesinlikle Kubernetes'e daha yakındı
    Ama daha hızlıydılar ve organizasyonun tam olarak ihtiyaç duyduğu şekilde opinionated idiler; ürün gereksinimleriyle çakışacak şekilde değil
    Kubernetes'in “hatalı” görünmesi çoğu zaman çekirdek sistemin kendisinden değil, onu istediğimiz gibi çalıştırmak için üstüne koyduğumuz sayısız arayüz katmanından kaynaklanıyor
  • Bu, Kubernetes değil Erlang için geçerli bir söz. Kubernetes için hiç mantıklı değil

• Sorun şu ki çoğu organizasyon K8s'i yarım yamalak benimsiyor, bunu yönetecek bir DevOps ekibi bile kuruyor ama sonunda K8s ile ilgili yazma, deployment, debugging ve operasyon işlerinin hepsini yine yazılım mühendislerinin sırtına yüklüyor
  İyi bir DevOps ekibi, kurum içinde Heroku benzeri bir deneyim sunmalı. Gerekli kaynakları tanımlayıp main'e merge ettiğinde deployment gerçekleşmeli; saçma bir GitOps/DevOps dashboard'unda neyin ters gittiğini aramak zorunda kalmamalısın
  Heroku geliştirici deneyiminin zirvesiydi ve bence K8s sonrası bunu kaybettik

  • Pod'ların node üzerinde çalıştığını görmek dışında, Heroku ile Kubernetes kullanım deneyimi arasında büyük bir fark olduğunu sanmıyorum
    Elbette Heroku; veritabanı entegrasyonu ya da git push ile deployment gibi daha bütünleşik bir deneyim sunuyor, ama Kubernetes üzerinde özel bir kabuk yapmak çok da iyi değil. Sonunda tüm parametreleri olduğu gibi geçiriyorsun

• Sektörde teknoloji benimseme her zaman “raf ürünü gibi al, gerekmezse çıkar” ilkesiyle ilerler. Bu da onun son örneklerinden biri

• “Bilgi insanlarda değil, sistemde olmalı” cümlesi, uzun zamandır muğlak biçimde düşündüğüm şeyi çok iyi ifade ediyor
  Bu tür biçimselleştirme, ancak süreçteki değişkenlik azaldığında mümkün oluyor. Önce insan yapar, sonra süreç belgelenir, sonra script'e dökülür, en sonunda da otomatikleştirilir
  Popüler araçların ya da ekosistemlerin yaygın iş akışlarında bu aşamaların çoğunu neredeyse bedavaya elde ediyorsun

• Çok fazla DevOps yapmıyorum; şu anda systemd ve ara sıra kullandığım podman container'larıyla sistemler gayet iyi çalışıyor. IoT/AgTech tarafında çalışıyorum
  Bu yazıda, teknik olmayan yöneticilerden sık duyulan türden “iddialar” var. Aşağı yukarı “Karşı taraf da LoRa kullanıyor değil mi? O zaman tamamdır? Yarın yayına çıkabiliriz, değil mi?” gibi
  Başarının önündeki tek engelin heterojenlik olduğu gibi bir inanç var. İki sistem Fiber, Modbus kullanıyorsa ya da “bir API'si varsa”, doğrudan bağlayıp “1 + 1'in toplamından büyük” o harika deneyimi yaratabileceklerini düşünüyorlar
  Ama iki yazılım düşük seviyeli birlikte çalışabilirlik standartlarında anlaşmış diye, kolay parse edilen veriyi nasıl yorumlayıp faydalı kullanacağına karar vermek gibi asıl iş ortadan kalkmıyor
  İki kişinin aynı dili konuşabilmesi, artık yapılacak iş kalmadığı anlamına gelmez. Ortak bir dil kullanmak, ekibin bir kısmının o aracı kullanırken o gün bildiği koşullar altında verdiği kararları da ortadan kaldırmaz
  İlk zamanlarda bilim/mühendislik dünyasında Fortran ortak dildi ama bu, meslektaşlarının yaptığı işe tamamen şaşırma ya da onu yeniden yazma ihtiyacını ortadan kaldırmamıştı
  K8s'in değerine ya da bugün bir “standart” haline gelmiş olmasına itirazım yok. Ama bunun belli tür programlama problemlerini ortadan kaldırdığı iddiasına katılmak zor. Çirkinliğin korunumu yasası hâlâ geçerli

• Kubernetes fena olmayan bir deployment platformu

• Deployment biçimi de başka bir sebep. Canton node işleri yapıyorum ve üst akıştaki Canton yazılımı ile ilgili uygulamalar Helm chart'ları olarak geliyor
  Kubernetes'in bizim işimize uygun olup olmamasından bağımsız olarak — bence değil — yazılım bu şekilde dağıtılıyor ve destekleniyor. Bu yolun dışına çıkarsan, Kubernetes'le uğraşmaktan daha fazla iş çıkıyor

• Bu yazı bana bir tek fazla AI yazmış gibi mi geliyor bilmiyorum
  Yine de ana fikrine katılıyorum. Homelab/self-hosting kurulumlarımı, özel systemd ayarları, hatırlamadığım shell komutları ve “lanet olsun, o kurulum prosedürünü hangi Markdown dosyasına yazmıştım?” halinden çıkarmaya çalışıyorum ve bu gerçekten ferahlatıcı
  Henüz gerçek bir sürekli deployment sistemi kullanmıyorum ama küçük bir apply shell script'i ve birkaç YAML dosyasıyla felaket durumunda bile %90 oranında geri dönebileceğimi hissetmek güzel
  systemd kavramsal olarak basit ama yeniden üretilebilirlik açısından karmaşık; Kubernetes ise bunun tersi. Kavramsal maliyeti daha yüksek ama yeniden üretilebilirlik ve onun getirdiği kavrayış çok daha güçlü. En azından şu an böyle görüyorum
  Hâlâ Kubernetes öğrenme sürecinin ortasındayım ama son zamanlarda kullanmaktan epey keyif alıyorum

  • 10 yıl önce katılırdım ama bugün farklı namespace seçenekleri ve dinamik kullanıcı entegrasyonu nedeniyle systemd de “bir başka canavar” gibi geliyor
    Bu tür birinci sınıf tanımlara sahip dikey entegrasyon yanlış yön gibi görünüyor
  • Bunun AI tarafından yazılıp yazılmadığı çok da önemli değil. Önemli olan iyi yazılmış olup olmaması