Joe Beda’nın Erken Kubernetes Seçimleri

Joe Beda'nın Erken Kubernetes Seçimleri Neden Hâlâ Önemli

Joe Beda, Kubernetes'in en erken tasarımında kilit kişilerden biriydi—Google'un iç sistemlerinden çıkarılan dersleri açık bir platforma taşıyan kurucularla birlikte. Onun etkisi moda özelliklerin peşinden koşmak değildi; gerçek üretim karmaşasıyla başa çıkabilecek ve günlük ekiplerin anlayabileceği basit ilkelere odaklanmaktı.

Bu erken kararlar Kubernetes'i sadece “bir konteyner aracı” olmaktan çıkardı. Modern uygulama platformları için yeniden kullanılabilir bir çekirdeğe dönüştürdü.

Konteyner orkestrasyonu, basitçe anlatmak gerekirse

“Konteyner orkestrasyonu”, makineler bozulduğunda, trafik yükseldiğinde veya yeni bir sürüm dağıtıldığında uygulamanızın çalışır halde kalmasını sağlayan kurallar ve otomasyon setidir. Bir insan sunucuları el ile gözetlemek yerine, sistem konteynerleri bilgisayarlara zamanlar, çöktüklerinde yeniden başlatır, dayanıklılık için dağıtır ve kullanıcıların onlara ulaşabilmesi için ağ yapılandırmasını sağlar.

Kubernetes öncesi karmaşa

Kubernetes yaygınlaşmadan önce ekipler genellikle temel soruları cevaplamak için betikler ve özel araçlar birleştiriyordu:

• Bu konteyner şu an nerede çalışmalı?
• Bir node saat 02:00'de ölürse ne olur?
• Kesinti olmadan nasıl güvenle dağıtırız?
• IP'ler sürekli değişirken servisler birbirini nasıl bulur?

Bu kendin-yap (DIY) sistemleri işe yarıyordu—ta ki yaramayana kadar. Her yeni uygulama veya ekip daha fazla tekil mantık ekledi ve operasyonel tutarlılık sağlamak zorlaştı.

Bu yazı neleri kapsıyor

Bu makale, erken Kubernetes tasarım seçimlerini (Kubernetes’in “şekli”) ve bunların neden modern platformları etkilemeye devam ettiğini anlatıyor: deklaratif model, kontrolcüler, Pod'lar, etiketler, Service'ler, güçlü bir API, tutarlı küme durumu, eklenti ile zamanlama ve genişletilebilirlik. Kubernetes'i doğrudan çalıştırmıyor olsanız bile, büyük olasılıkla bu fikirlerin üzerine kurulmuş bir platform kullanıyorsunuz—veya aynı sorunlarla uğraşıyorsunuz.

Kubernetes'in Çözmeyi Hedeflediği Problem

Kubernetes'ten önce, “konteyner çalıştırmak” genellikle birkaç konteyner çalıştırmak anlamına geliyordu. Ekipler dağıtımı sağlamak için bash betikleri, cron işleri, golden imajlar ve birkaç geçici araç bir araya getiriyordu. Bir şey bozulduğunda, düzeltme genellikle birinin kafasında ya da kimsenin güvenmediği bir README'de yaşıyordu. Operasyon, süreçleri yeniden başlatmak, load balancer'ları yeniden yönlendirmek, diski temizlemek ve hangi makineye dokunmanın güvenli olduğunu tahmin etmek gibi tek seferlik müdahaleler akışıydı.

Ölçekle birlikte konteynerlerin yeni başarısızlık modları yarattığı yer

Konteynerler paketlemeyi kolaylaştırdı, ama üretimdeki karmaşayı ortadan kaldırmadı. Ölçeklendiğinizde sistem daha sık ve farklı şekillerde başarısız olur: node'lar kaybolur, ağlar bölünür, imajlar tutarsız yayılır ve iş yükleri beklediğinizden sapar. “Basit” bir dağıtım şelaleye dönüşebilir—bazı örnekler güncellendi, bazıları kalakaldı, bazıları takıldı, bazıları sağlıklı ama ulaşılamaz.

Gerçek sorun konteynerleri başlatmak değildi. Sorun doğru konteynerleri, doğru biçimde, sürekli değişime rağmen çalışır halde tutmaktı.

Altyapı genelinde tutarlı bir model

Ekipler ayrıca farklı ortamlarda denge kuruyordu: yerel donanım, VM'ler, erken bulut sağlayıcıları ve çeşitli ağ/disk düzenlemeleri. Her platformun kendi dili ve hata kalıpları vardı. Ortak bir model olmadan her geçiş operasyonel araçları yeniden yazmak ve insanları yeniden eğitmek demekti.

Kubernetes, makinelerin nerede olduğuna bakılmaksızın uygulamaları ve operasyonel ihtiyaçlarını tanımlamak için tek, tutarlı bir yol sunmayı hedefledi.

“Platform” beklentileri nasıl görünüyordu

Geliştiriciler self-service istiyordu: bilet açmadan dağıt, kapasite için yalvarmadan ölçekle, drama olmadan geri al. Operasyon ekipleri öngörülebilirlik istedi: standart sağlık kontrolleri, tekrarlanabilir dağıtımlar ve neyin çalışıyor olduğuna dair net bir gerçek kaynağı.

Kubernetes gösterişli bir zamanlayıcı olmaya çalışmıyordu. Karmaşık gerçekliği akıl yürütebileceğiniz bir sisteme çeviren güvenilir bir uygulama platformunun temeli olmaya çalışıyordu.

Karar 1: Deklaratif, İstenen-Durum Modeli

Erken seçimlerden en etkili olanlardan biri Kubernetes'i deklaratif yapmak oldu: ne istediğinizi tarif edersiniz ve sistem gerçeği bu tanıma uydurmaya çalışır.

İstenen durum, bir termostat gibi açıklama

Bir termostat günlük hayattan faydalı bir örnektir. Isıtıcıyı her birkaç dakikada bir elle açıp kapatmazsınız. İstenen bir sıcaklık ayarlarsınız—örneğin 21°C—ve termostat o sıcaklığa yakın tutmak için odayı kontrol edip ısıtıcıyı ayarlar.

Kubernetes de aynı şekilde çalışır. Kümeye adım adım “şu konteyneri şu makinede başlat, sonra çökerse yeniden başlat” demek yerine sonucu beyan edersiniz: “Bu uygulamadan 3 kopya çalışmasını istiyorum.” Kubernetes sürekli olarak neyin gerçekten çalıştığını kontrol eder ve sapmayı düzeltir.

Daha az manuel adım, daha az sürpriz

Deklaratif konfigürasyon, genellikle birinin kafasında veya yarım güncellenmiş bir runbook'ta kalan gizli “operasyon listesi”ni azaltır. Konfigürasyonu uygularsınız ve Kubernetes yerleştirme, yeniden başlatma ve değişiklikleri uzlaştırma mekaniklerini halleder.

Ayrıca değişiklik incelemeyi kolaylaştırır. Bir değişiklik, özel komutlar dizisi yerine konfigürasyondaki bir diff olarak görünür.

Ortamlar arasında tekrarlanabilirlik

İstenen durum yazılı olduğu için aynı yaklaşımı geliştirme, staging ve üretimde tekrar kullanabilirsiniz. Ortam farklı olabilir ama niyet tutarlı kalır; bu da dağıtımları daha öngörülebilir ve denetlenebilir kılar.

Takaslar

Deklaratif sistemlerin öğrenme eğrisi vardır: “sonraki ne yapmalıyım” yerine “ne doğru olmalı” diye düşünmeyi gerektirir. Ayrıca iyi varsayılanlara ve net konvansiyonlara bağımlıdır—bunlar yoksa ekipler teknik olarak çalışan ama anlaşılması ve bakım yapılması zor konfigürasyonlar üretebilir.

Karar 2: Sistemin Motoru Olarak Kontrol Döngüleri (Kontrolcüler)

Kubernetes sadece konteynerleri bir kere çalıştırabildiği için başarılı olmadı—zaman içinde onları doğru şekilde çalışır halde tutabildiği için başarılı oldu. Büyük tasarım hamlesi “kontrol döngüleri”ni (kontrolcüler) sistemin çekirdeği yapmaktı.

Kontrolcü nedir

Bir kontrolcü basit bir döngüdür:

• Mevcut duruma bak (gerçekten ne çalışıyor)
• Bunu istenen durumla karşılaştır (ne istedin)
• İkisi eşleşene kadar aksiyon al

Bu tek seferlik bir görevden çok oto-pilot gibidir. İş yüklerini “gözetlemek” yerine niyeti beyan edersiniz ve kontrolcüler kümeyi o sonuca doğru sürekli çeker.

Çöküşler, node kaybı ve sapmayla başa çıkma

Bu desen Kubernetes'in gerçek dünya hatalarıyla karşılaştığında dayanıklı olmasını sağlar:

• Konteyner çöküşleri: kontrolcü, istenenden daha az çalışan örnek olduğunu görür ve yenilerini başlatır.
• Node kaybı: bir node kaybolduğunda kontrolcüler pod'ları başka yere yeniden zamanlar ve istenen sayıyı geri getirir.
• Konfigürasyon sapması: biri kaynakları değiştirir veya silerse, kontrolcüler farkı uzlaştırır ve düzeltir.

Hataları özel durumlar olarak ele almak yerine, kontrolcüler onları rutin “durum uyumsuzluğu” olarak görür ve her seferinde aynı şekilde düzeltir.

Betiklerden daha iyi ölçeklenme nedeni

Geleneksel otomasyon betikleri genellikle kararlı bir ortam varsayar: önce A çalıştır, sonra B, sonra C. Dağıtık sistemlerde bu varsayımlar sık sık bozulur. Kontrolcüler daha iyi ölçeklenir çünkü idempotenttirler (tekrar tekrar güvenle çalıştırılabilir) ve nihai olarak tutarlıdırlar (hedefe ulaşana kadar denemeye devam ederler).

Günlük örnekler: Deployment ve ReplicaSet

Eğer bir Deployment kullandıysanız, kontrol döngülerine güvenmişsinizdir. Altında Kubernetes, istenen pod sayısını sağlamak için bir ReplicaSet kontrolcüsü kullanır—ve Deployment kontrolcüsü ise rolling update ve rollback işlemlerini öngörülebilir şekilde yönetir.

Karar 3: Planlama Atomu Olarak Pod'lar

Kubernetes “sadece konteynerleri” planlayabilirdi, ama Joe Beda ve ekibi makinede yerleştirilecek en küçük dağıtılabilir birim olarak Podları getirdi. Temel fikir: birçok gerçek uygulama tek bir süreç değildir. Onlar, birlikte yaşaması gereken küçük bir grup sıkı bağlı süreçtir.

Neden tekil konteynerler yerine Pod'lar?

Pod, aynı kaderi paylaşan bir veya daha fazla konteynerin sarmalayıcısıdır: birlikte başlarlar, aynı node'da çalışırlar ve birlikte ölçeklenirler. Bu, sidecar desenlerini doğal kılar—log shipper, proxy, konfigürasyon yeniden yükleyici veya güvenlik ajanı gibi ana uygulamayı her zaman takip etmesi gereken yardımcılar düşünün.

Bu yardımcıları her uygulamaya entegre etmeye çalışmak yerine, Kubernetes onları ayrı konteynerler olarak paketlemenize izin verir ama yine de tek bir birim gibi davranmalarını sağlar.

Pod'ların ağ ve depolama için sağladığı kolaylıklar

Pod'lar iki önemli varsayımı pratik hale getirdi:

• Ağ: Bir Pod içindeki konteynerler aynı ağ kimliğini paylaşır (tek bir IP ve port alanı). Ana uygulama sidecar ile localhost üzerinden konuşabilir; bu basit ve hızlıdır.
• Depolama: Pod içindeki konteynerler hacimleri paylaşabilir. Bir yardımcı yazdığını ana uygulama okuyabilir (veya tersi), dış atlamalar olmadan.

Bu seçimler özel yapıştırıcı kod ihtiyacını azalttı ve konteynerleri işlem düzeyinde izole tutmaya devam etti.

Pod'ların yeni başlayanları şaşırttığı yerler

Yeni kullanıcılar genellikle “bir konteyner = bir uygulama” bekler, sonra Pod düzeyi kavramlarla kafaları karışır: yeniden başlatmalar, IP'ler ve ölçeklendirme. Birçok platform, ekiplerin her gün Pod mekaniklerini düşünmesine gerek kalmadan sidecar ve paylaşılan kaynakların faydalarını almasını sağlamak için akıllı şablonlar sunar (örneğin “web servisi”, “worker” veya “job”).

Karar 4: Gevşek Bağlanma İçin Etiketler ve Seçiciler

Kubernetes'te sessiz ama güçlü bir erken seçim, etiketleri birinci sınıf metadata ve seçicileri nesneleri “bulmanın” birincil yolu olarak görmek oldu. Tam olarak üç makinenin benim uygulamamı çalıştırdığı gibi sert ilişkilendirmeler yapmak yerine, Kubernetes paylaşılan özelliklerle grupları tanımlamanızı teşvik eder.

Etiketler: her şeye takılabilen esnek etiketler

Etiket, kaynaklara—Pod'lara, Deployment'lara, Node'lara, Namespace'lere ve daha fazlasına—eklediğiniz basit anahtar/değer çiftidir. Sorgulanabilir “tag” gibi davranırlar:

• app=checkout
• env=prod
• tier=frontend

Etiketler hafif ve kullanıcı tanımlıdır, bu yüzden organizasyonunuzun gerçekliğini modelleyebilirsiniz: ekipler, maliyet merkezleri, uyumluluk bölgeleri, sürüm kanalları veya işletme açısından önemli olan herhangi bir şey.

Seçiciler: sıkı bağımlılıklar olmadan ilişkiler

Seçiciler etiketler üzerinde sorgudur (örneğin, “app=checkout ve env=prod olan tüm Pod'lar”). Bu, pod'lar yeniden zamanlandıkça, ölçeklendikçe veya roll out sırasında değiştikçe sistemin uyum sağlamasını sağlar. Yapılandırmanız altında yatan örnekler sürekli değişse bile kararlı kalır.

Ölçekte dinamik gruplaşma

Bu tasarım operasyonel olarak ölçeklenir: binlerce örnek kimliğini yönetmezsiniz—birkaç anlamlı etiket setini yönetirsiniz. Bu gevşek bağlanmanın özü: bileşenler üyeliği güvenle değişebilen gruplara bağlanır.

Etiketler gruplaşmadan fazlasını güçlendirir

Etiketler bir kez var olduğunda platform genelinde ortak bir sözlük haline gelir. Trafik yönlendirme (Service'ler), politika sınırları (NetworkPolicy), gözlemlenebilirlik filtreleri (metrikler/loglar) ve hatta maliyet takibi ve faturalandırma için kullanılır. Bir basit fikir—nesneleri tutarlı şekilde etiketleme—birçok otomasyon fırsatını açar.

Karar 5: Kararlı Ağ İçin Service'ler

Kubernetes, konteynerların kesinlikle öngörülemez olduğu bir ortamda ağın öngörülebilir hissetmesini sağlamaya ihtiyaç duydu. Pod'lar değiştirildiği, yeniden zamanlandığı ve ölçeklendiği için IP'leri ve çalıştıkları makineler sürekli değişir. Service fikri basittir: değişen Pod kümesine sabit bir “ön kapı” sağlayın.

Değişen Pod'lara kararlı erişim

Bir Service size tutarlı bir sanal IP ve DNS adı verir (örneğin payments). Bu adın arkasında Kubernetes, Service'in seçicisiyle eşleşen Pod'ları sürekli takip eder ve trafiği ona göre yönlendirir. Bir Pod ölür ve yenisi ortaya çıkarsa, Service hâlâ doğru yere işaret eder; uygulama ayarlarını elle değiştirmek zorunda kalmazsınız.

Konfigürasyonu basitleştiren servis keşfi

Bu yaklaşım birçok elle yapılan bağlantıyı ortadan kaldırdı. IP'leri konfigürasyon dosyalarına sabitlemek yerine, uygulamalar isimlere güvenebilir. Uygulamayı dağıtın, Service'i dağıtın ve diğer bileşenler DNS üzerinden bulur—özel bir kayıt defterine gerek yok, sabit uç noktalar yok.

Güvenilirlik için yerleşik yük dengeleme

Service'ler aynı zamanda sağlıklı uç noktalar arasında varsayılan yük dengeleme davranışı getirdi. Bu, ekiplerin her dahili mikroservis için kendi yük dengeleyicisini inşa etmek zorunda kalmaması demekti. Trafiğin dağıtılması tek bir Pod başarısızlığının patlama alanını azaltır ve rolling update'leri daha az riskli kılar.

Sınırlar—ve Ingress/Gateway ile uzatma

Service L4 (TCP/UDP) trafiği için iyidir, ama HTTP yönlendirme kuralları, TLS terminasyonu veya kenar politikalarını modellemez. Bu durumlarda Ingress ve giderek daha fazla Gateway API devreye girer: Service'lerin üzerine hostname, yol ve dış giriş noktalarını daha temiz şekilde inşa ederler.

Karar 6: Bir Ürün Yüzeyi Olarak API

Erken yapılan en radikal seçimlerden biri Kubernetes'i bir API olarak sunmaktı—tıklanacak tek bir monolitik ürün değil. Bu API-öncelikli duruş Kubernetes'i uzatılabilir, scriptlenebilir ve yönetilebilir bir platform gibi hissettirdi.

API-öncelikli olmanın platform inşasına etkisi

API yüzey alanı olduğunda, platform ekipleri uygulamaların nasıl tanımlanıp yönetileceğini standardize edebilir; hangi UI, pipeline veya dahili portalın üstte olduğunun önemi azalır. “Bir uygulama dağıtmak”, “API nesneleri göndermek ve güncellemek” (Deployment, Service, ConfigMap gibi) anlamına gelir; bu da uygulama ekipleri ile platform arasında daha temiz bir sözleşme sağlar.

Araçlar, UI'lar ve otomasyon özel erişime gerek duymadan çalışır

Her şey aynı API üzerinden geçtiği için yeni araçlar ayrıcalıklı arka kapılara ihtiyaç duymaz. Dashboard'lar, GitOps kontrolörleri, politika motorları ve CI/CD sistemleri hepsi normal API istemcisi olarak, sınırlandırılmış izinlerle çalışabilir.

Bu simetri önemlidir: istek bir kişiden, bir betikten veya dahili bir platform UI'sından gelsin, aynı kurallar, yetki, denetim ve admission kontrolleri uygulanır.

Sürümleme ve uzun ömürlü kümeler için uyumluluk

API sürümlendirme, Kubernetes'i bir gecede her kümeyi veya her aracı kırmadan evrimleştirilebilir kıldı. Kullanımdan kaldırma aşamalı yapılabilir; uyumluluk test edilebilir; yükseltmeler planlanabilir. Yıllarca küme çalıştıran organizasyonlar için bu, “güncelleyebiliyoruz” ile “takıldık” arasındaki farktır.

kubectl gerçekte neyi temsil eder

kubectl Kubernetes değildir—o bir istemcidir. Bu zihniyet ekipleri API iş akışları etrafında düşünmeye iter: kubectl'i otomasyonla, bir web UI ile veya özel bir portal ile değiştirebilirsiniz ve sistem API sözleşmesi sayesinde tutarlı kalır.