Brendan Burns'in Kubernetes dönemindeki orkestrasyon fikirlerine — deklaratif istenen durum, controller'lar, ölçeklendirme ve servis operasyonları — ve neden standartlaştıklarına dair pratik bir inceleme.
Kubernetes sadece yeni bir araç getirmedi—onlarca (veya yüzlerce) servis çalıştırırken "günlük operasyon"un nasıl göründüğünü değiştirdi. Orkestrasyondan önce ekipler genellikle aynı tekrar eden sorulara cevap bulmak için betikler, manuel runbook'lar ve birikmiş bilgiye güvenirlerdi: Bu servis nerede çalışmalı? Değişikliği nasıl güvenli şekilde dağıtırız? Bir node gece 2'de öldüğünde ne olur?
Özünde orkestrasyon, niyetiniz ("bu servisi şöyle çalıştır") ile makinelerin arızalanması, trafiğin kayması ve kesintisiz dağıtımlar gibi dağınık gerçeklik arasındaki koordinasyon katmanıdır. Her sunucuyu özel bir kar tanesi olarak görmek yerine, orkestrasyon hesaplamayı bir havuz olarak ele alır ve iş yüklerini taşınabilir, planlanabilir birimler olarak görür.
Kubernetes, ekiplerin istediklerini tanımladığı ve sistemin sürekli olarak gerçeği bu tanıma uydurmaya çalıştığı bir modeli popülerleştirdi. Bu değişim önemlidir çünkü operasyonları kahramanlıklardan ziyade tekrarlanabilir süreçlere dönüştürür.
Kubernetes, çoğu servis ekibinin ihtiyaç duyduğu operasyonel sonuçları standartlaştırdı:
Bu yazı Kubernetes ile ilişkili fikirler ve kalıplara (ve Brendan Burns gibi liderlerin etkisine) odaklanır; kişisel bir biyografi değildir. "Nasıl başladı" veya "neden böyle tasarlandı" gibi iddialar halka açık kaynaklara—konferans konuşmaları, tasarım belgeleri ve upstream dokümantasyon—dayandırılmalıdır, böylece anlatı efsaneye dönüşmez.
Brendan Burns, Joe Beda ve Craig McLuckie ile birlikte Kubernetes'in üç orijinal kurucusundan biri olarak geniş çapta tanınır. Google içindeki erken Kubernetes çalışmalarında Burns, teknik yönü şekillendirmeye ve projeyi kullanıcılara anlatma biçimine katkıda bulundu—özellikle "yazılımı nasıl işletirsiniz" sorusunun vurgulanmasında, sadece "konteynerleri nasıl çalıştırırsınız" değil. (Kaynaklar: Kubernetes: Up & Running, O’Reilly; Kubernetes proje deposu AUTHORS/maintainers listeleri)
Kubernetes, bitmiş bir dahili sistem olarak "sadece yayımlanmadı"; kamuya açık şekilde, büyüyen katkıda bulunanlar, kullanım durumları ve kısıtlamalarla birlikte inşa edildi. Bu açıklık projeyi farklı ortamlarda ayakta kalabilecek arayüzlere itti:
Bu işbirlikçi baskı, Kubernetes'in neyi optimize ettiğini etkiledi: birçok ekibin üzerinde uzlaşabileceği paylaşılan ilkelere ve tekrarlanabilir kalıplara yöneldi, araçlarda anlaşmasalar bile.
Kubernetes'in "dağıtım ve operasyonu standartlaştırdığı" söylenirken genellikle her sistemi aynı yaptığı kastedilmez. Kastedilen, ekipler arasında tekrarlanabilecek ortak bir sözlük ve iş akışları sunmasıdır:
Bu ortak model, dokümantasyonun, araçların ve ekip uygulamalarının bir şirketten diğerine taşınmasını kolaylaştırdı.
Kubernetes (açık kaynak proje) ile Kubernetes ekosistemini ayırmak faydalıdır.
Proje, platformu uygulayan çekirdek API ve kontrol düzlemi bileşenleridir. Ekosistem ise etrafında büyüyen dağıtımlar, yönetilen hizmetler, eklentiler ve CNCF projeleridir. İnsanların güvenip kullandığı birçok gerçek dünya "Kubernetes özelliği" (gözlemlenebilirlik yığınları, politika motorları, GitOps araçları) çekirdek projede değil, bu ekosistemde yaşar.
Deklaratif yapılandırma, sistemleri tanımlama biçiminde basit bir kaymadır: yapılacak adımları listelemek yerine istediğiniz son durumu belirtirsiniz.
Kubernetes terimleriyle, platforma "bir konteyner başlat, sonra bir port aç, sonra çökerse yeniden başlat" demek yerine "bu uygulamadan üç kopya çalışmalı, bu porttan erişilebilir, bu container imajını kullanmalı" diye belirtirsiniz. Kubernetes, gerçeği bu tanımla eşleştirmekle sorumludur.
Emredici operasyonlar bir runbook gibidir: geçen sefer işe yarayan komutların dizisi, bir şey değiştiğinde tekrar yürütülür.
İstenen durum ise daha çok bir sözleşme gibidir. Nihaî sonucu bir yapılandırma dosyasında kaydedersiniz ve sistem sürekli olarak bu sonuca doğru çalışır. Bir şey saparsa—bir örnek ölür, bir node kaybolur, manuel bir değişiklik girerse—platform uyumsuzluğu fark eder ve düzeltir.
Önce (emredici runbook düşüncesi):
Bu yaklaşım işe yarar, ama kolayca "kar tanesi" sunuculara ve sadece birkaç kişinin güvendiği uzun bir kontrol listesine dönüşebilir.
Sonra (deklaratif istenen durum):
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout
spec:
replicas: 3
selector:
matchLabels:
app: checkout
template:
metadata:
labels:
app: checkout
spec:
containers:
- name: app
image: example/checkout:1.2.3
ports:
- containerPort: 8080
Dosyayı (örneğin image veya replicas'ı güncellemek) değiştirirsiniz, uygulayınca Kubernetes'in controller'ları çalışıp çalışanın gerçeği beyana uydurmaya çalışır.
Deklaratif istenen durum, "bu 17 adımı yap"ı "bunu böyle tut"a çevirerek operasyonel emeği azaltır. Ayrıca yapılandırma sürüklenmesini azaltır çünkü gerçek kaynak açıklıdır ve genellikle versiyon kontrolünde tutulur—sürprizler daha kolay görülebilir, denetlenebilir ve tutarlı şekilde geri alınabilir.
Kubernetes "kendi kendine yönetiyormuş" hissi verir çünkü basit bir kalıp etrafında inşa edilmiştir: ne istediğinizi tanımlarsınız ve sistem sürekli olarak gerçeği bu tanıma yaklaştırmaya çalışır. Bu kalıbın motoru controller'dır.
Controller, kümenin mevcut durumunu izleyen ve bunu YAML'da (veya API çağrısında) beyan ettiğiniz istenen durumla karşılaştıran bir döngüdür. Bir fark gördüğünde, bu farkı azaltmak için harekete geçer.
Bir kerelik bir betik değildir ve bir insanın tıklamasını beklemez. Tekrar tekrar çalışır—gözlemle, karar ver, harekete geç—böylece her an değişime yanıt verebilir.
Bu tekrar eden karşılaştırma ve düzeltme davranışına uzlaştırma (reconciliation) denir. Bu, "kendini iyileştirme" vaadinin arkasındaki mekanizmadır. Sistem arızaları sihirle engellemez; sapmayı fark edip düzeltir.
Sapma sıradan nedenlerle oluşabilir:
Uzlaştırma, Kubernetes'in bu olayları niyetinizi yeniden kontrol etmek ve onu geri yüklemek için sinyal olarak ele alması anlamına gelir.
Controller'lar tanıdık operasyonel sonuçlara dönüşür:
Önemli olan, semptomların peşinden manuel olarak koşmamanızdır. Hedefi beyan edersiniz ve kontrol döngüleri sürekli olarak "bunu böyle tutma" işini yapar.
Bu yaklaşım tek bir kaynak tipine bağlı değildir. Kubernetes aynı controller-ve-uzlaştırma fikrini birçok nesnede kullanır—Deployment, ReplicaSet, Job, Node, Endpoint ve daha fazlası. Bu tutarlılık, Kubernetes'in bir platform haline gelmesinin büyük bir nedenidir: kalıbı bir kez anladığınızda, yeni yetenekler ekledikçe sistemin nasıl davranacağını tahmin edebilirsiniz (aynı döngüyü takip eden özel kaynaklar dahil).
Kubernetes sadece "konteynerleri çalıştır" yapsaydı bile, ekipler en zor kararı; hangi iş yükünün nerede çalışacağına karar vermekle baş başa kalırdı. Planlayıcı, Pod'ları kaynak ihtiyaçları ve tanımladığınız kurallar temelinde otomatik olarak doğru node'lara yerleştiren yerleşik sistemdir.
Bu önemlidir çünkü yerleşim kararları doğrudan çalışma süresini ve maliyeti etkiler. Kalabalık bir node'da sıkışmış bir web API'si yavaşlayabilir veya çöker. Bir batch işi gecikme hassasiyeti yüksek hizmetlerin yanına yerleştirilirse gürültülü-komşu sorunları yaratabilir. Kubernetes bunu bir spreadsheet ve SSH rutininin yerine tekrarlanabilir bir ürün yeteneğine dönüştürür.
Temel düzeyde scheduler, Pod'un isteklerini karşılayabilecek node'ları arar.
Bu tek alışkanlık—gerçekçi istekler belirlemek—kritik servislerin her şeyle rekabet etmeyi bırakması sayesinde rastgele kararsızlığı sıklıkla azaltır.
Kaynakların ötesinde, üretim kümelerinin çoğu birkaç pratik kurala dayanır:
Planlama özellikleri ekiplerin operasyonel niyetini kodlamasına yardımcı olur:
Pratik çıkarım: planlama kurallarını ürün gereksinimleri gibi ele alın—bunları yazın, gözden geçirin ve tutarlı şekilde uygulayın—böylece güvenilirlik gece 2'de doğru node'u hatırlayan birine bağlı kalmaz.
Kubernetes'in en pratik fikirlerinden biri, ölçeklendirmenin uygulama kodunu değiştirmeyi veya yeni bir dağıtım yaklaşımı icat etmeyi gerektirmemesi gerektiğidir. Eğer uygulama bir konteyner olarak çalışabiliyorsa, aynı iş yükü tanımı genellikle yüzlerce veya binlerce kopyaya büyüyebilir.
Kubernetes ölçeklendirmeyi iki ilişkili karara ayırır:
Bu ayrım önemlidir: 200 pod isterken kümeye sadece 50 yer varsa, "ölçeklendirme" bekleyen işlerin kuyruğuna dönüşür.
Kubernetes genellikle üç autoscaler kullanır, her biri farklı bir kaldıraç üzerine odaklanır:
Birlikte kullanıldığında, ölçeklendirmeyi "gecikmeyi sabit tut" veya "CPU yüzde X civarında tut" gibi politika haline getirir; manuel müdahale değil.
Ölçeklendirme sadece girdiler kadar iyidir:
Tekrarlanan iki hata: yanlış metrikle ölçeklendirme (CPU düşükken istekler zaman aşımına girer) ve eksik kaynak istekleri (autoscaler kapasiteyi öngöremez, pod'lar çok sıkışır ve performans tutarsızlaşır).
Kubernetes'in popülerleştirdiği büyük değişimlerden biri, "dağıtım"ı tek seferlik bir komut değil, sürekli yönetilen bir kontrol problemi olarak ele almaktır. Rollout'lar ve rollback'ler birinci sınıf davranışlardır: hangi sürümü istediğinizi beyan edersiniz ve Kubernetes değişimi adım adım uygularken gerçekten güvenli olup olmadığını sürekli kontrol eder.
Bir Deployment ile rollout, eski Pod'ların yeni olanlarla kademeli olarak değiştirilmesidir. Her şeyi durdurup yeniden başlatmak yerine, Kubernetes kapasiteyi koruyarak ve yeni versiyon gerçek trafikte doğrulanırken adım adım değişikliğe gider.
Yeni versiyon başarısız olmaya başlarsa, rollback acil bir prosedür değildir. Önceki bilinen iyi ReplicaSet'e geri dönebilir ve controller'ın eski durumu geri yüklemesine izin verebilirsiniz.
Sağlık kontrolleri, rollout'ları umut temelli olmaktan ölçülebilir hale getirir.
Doğru kullanıldığında probe'lar, Pod'lar başlatıldığı için iyi görünen ama gerçekte istekleri reddeden dağıtımları azaltır.
Kubernetes yerel olarak rolling update sağlar, ancak ekipler genellikle üstüne ekstra desenler ekler:
Güvenli dağıtımlar sinyallere dayanır: hata oranı, gecikme, doygunluk ve kullanıcı etkisi. Birçok ekip rollout kararlarını SLO'lar ve hata bütçeleri ile ilişkilendirir—bir canary çok fazla bütçe yakarsa, terfi durur.
Amaç, geri almanın gerçek göstergelere dayalı otomatik tetiklenmesi, böylece "geri alma"nın tahmin edilebilir bir sistem tepkisi olmasıdır—gece geç saatlerdeki kahramanlık anı değil.
Bir konteyner platformu, uygulamanız hareket ettikten sonra diğer parçaların hâlâ uygulamanızı bulabilmesi halinde ancak "otomatik" hisseder. Gerçek üretim kümelerinde pod'lar sürekli oluşturulur, silinir, yeniden planlanır ve ölçeklenir. Her değişiklik IP adreslerini konfigürasyonlarda güncellemeyi gerektirseydi, operasyonlar sürekli bir meşguliyete dönüşür ve kesintiler olağan olurdu.
Servis keşfi, istemcilere değişen bir backend kümesine güvenilir bir şekilde ulaşma yolu vermektir. Kubernetes'te ana değişim, bireysel örneklere hedeflenmeyi bırakıp bir isimlendirilmiş servise hedeflenmektir ("10.2.3.4 çağır" yerine "checkout çağır"). Platform, bu isim için hangi pod'ların hizmet verdiğini halleder.
Bir Service, bir grup pod için sabit bir ön kapıdır. Küme içinde alttaki pod'lar değişse bile tutarlı bir isim ve sanal adrese sahiptir.
Bir selector, Kubernetes'in hangi pod'ların o ön kapının arkasında olduğunu belirlemesidir. Çoğunlukla app=checkout gibi etiketleri eşler.
Endpoints (veya EndpointSlices), seçiciyle şu anda eşleşen gerçek pod IP'lerinin canlı listesidir. Pod'lar ölçeklenip yeniden planlandığında bu liste otomatik olarak güncellenir—istemciler aynı Service adını kullanmaya devam eder.
Operasyonel olarak bu şunları sağlar:
Kümeye dışarıdan yönelen (north–south) trafik genellikle bir Ingress veya daha yeni Gateway yaklaşımı kullanılarak yönetilir. Her ikisi de hostname veya path'e göre istekleri yönlendirebileceğiniz kontrollü bir giriş noktası sağlar ve genellikle TLS terminasyonu gibi konuları merkezileştirir. Önemli fikir yine aynıdır: arka plan hizmetleri değişirken dış erişimi sabit tutmak.
Kubernetes'te "kendini iyileştirme" sihir değil. Bu, bir dizi otomatik tepkinin birleşimidir: yeniden başlat, yeniden planla ve değiştir. Platform, beyan ettiğiniz istenen durumu izler ve gerçeği buna doğru itmeye devam eder.
Bir süreç sonlanır veya bir container sağlıksız hale gelirse, Kubernetes onu aynı node üzerinde yeniden başlatabilir. Bu genellikle şunlarla tetiklenir:
Yaygın üretim akışı: tek bir container çöküyor → Kubernetes yeniden başlatıyor → Service sadece sağlıklı Pod'lara trafiği yönlendiriyor.
Bir node tamamen çökerse (donanım sorunu, kernel panic, ağ kaybı), Kubernetes node'u erişilemez olarak tespit eder ve işi başka yere taşır. Yüksek düzey:
Bu, küme düzeyinde "kendini iyileştirme"dir: sistem kapasiteyi insanlar SSH'lamayı beklemek yerine yerine koyar.
Kendini iyileştirme ancak doğrulayabilirseniz önemlidir. Ekipler genellikle şunları izler:
Kubernetes olsa bile, "iyileşme" koruyucuları yanlışsa başarısız olabilir:
İyileştirme iyi kurulursa, kesintiler daha küçük ve daha kısa olur—ve daha da önemlisi ölçülebilir hale gelir.
Kubernetes sadece konteyner çalıştırabildiği için kazanmadı. Kazanmasının nedeni en yaygın operasyonel ihtiyaçlar için standart API'ler sunmasıydı—dağıtım, ölçeklendirme, ağ ve gözlemlenebilirlik gibi. Ekipler aynı "nesne" biçimi (Deployment, Service, Job gibi) üzerinde anlaşınca, araçlar organizasyonlar arasında paylaşılabilir, eğitim basitleşir ve dev-ops elden teslimleri kabile bilgisinden kurtulur.
Tutarlı bir API, dağıtım pipeline'ınızın her uygulamanın tuhaflıklarını bilmesine gerek kalmaması demektir. Aynı Kubernetes kavramlarını kullanarak aynı eylemleri—oluştur, güncelle, geri al ve sağlık kontrol et—uygulayabilir.
Ayrıca hizalanmayı geliştirir: güvenlik ekipleri politika olarak koruyucuları ifade edebilir; SRE'ler ortak sağlık sinyalleri etrafında runbook'ları standardize edebilir; geliştiriciler paylaşılan bir sözlükle sürümleri düşünebilir.
Platform değişimi Custom Resource Definitions (CRD) ile belirginleşir. CRD, kümeye yeni bir nesne türü eklemenizi sağlar (ör. Database, Cache, Queue) ve bunu yerleşik kaynaklarla aynı API kalıplarıyla yönetmenize izin verir.
Bir Operator, bu özel nesneleri istenen durumla uzlaştıran bir controller ile eşleştirilir—yedekleme, failover veya sürüm yükseltmeleri gibi önceden manuel olan görevleri otomatikleştirir. Temel fayda sihir değil; Kubernetes'in her şeye uyguladığı aynı kontrol döngüsü yaklaşımını yeniden kullanmaktır.
Kubernetes API-odaklı olduğu için modern iş akışlarıyla temiz entegrasyon sağlar:
Eğer bu fikirler üzerine daha pratik dağıtım ve operasyon rehberleri arıyorsanız, /blog'a göz atın. Ücret ve yönetişim değerlendirmeleri için /pricing'i inceleyebilirsiniz.
Kubernetes'in en büyük fikirleri—birçoğu Brendan Burns'in erken çerçevesiyle ilişkilendirilebilir—VM'lerde, serverless'de veya daha küçük bir konteyner kurulumunda bile iyi şekilde tercüme edilebilir.
İstenen durumu yazın ve otomasyonun bunu uygulamasına izin verin. Terraform, Ansible veya bir CI pipeline'ı fark etmez; konfigürasyonu tek doğruluk kaynağı olarak ele alın. Sonuç daha az manuel dağıtım adımı ve çok daha az "benim makinemde çalıştı" sürprizidir.
Tek seferlik betikler yerine uzlaştırma kullanın. Bir kerelik çalışıp uman betikler yerine, anahtar özellikleri sürekli doğrulayan döngüler oluşturun (sürüm, konfig, örnek sayısı, sağlık). Bu, tekrarlanabilir operasyonlar ve arızalardan sonra öngörülebilir kurtarma sağlar.
Planlama ve ölçeklendirmeyi açık ürün özellikleri haline getirin. Ne zaman ve neden kapasite ekleyeceğinizi (CPU, kuyruk derinliği, gecikme SLO'ları) tanımlayın. Kubernetes autoscaling olmasa bile ekipler ölçek kurallarını standardize edebilir, böylece büyüme uygulamayı yeniden yazmayı veya birini uyandırmayı gerektirmez.
Dağıtımları standardize edin. Kademeli güncellemeler, sağlık kontrolleri ve hızlı geri alma prosedürleri değişiklik riskini azaltır. Bunu load balancer'lar, feature flag'ler ve gerçek sinyallerle kapalı dağıtım pipeline'larıyla uygulayabilirsiniz.
Bu kalıplar kötü uygulama tasarımını, güvenli olmayan veri geçişlerini veya maliyet kontrolünü tek başına çözmez. Hâlâ versiyonlanmış API'lara, geçiş planlarına, bütçe/limitlere ve deploy'ları müşteri etkisiyle ilişkilendiren gözlemlenebilirliğe ihtiyacınız var.
Tek bir müşteri yüzlü servisi seçin ve kontrol listesini uçtan uca uygulayın, sonra genişletin.
Eğer yeni servisler inşa ediyorsanız ve "hızlıca dağıtılabilir bir şeye" ulaşmak istiyorsanız, Koder.ai size chat tabanlı bir spesifikasyondan tam bir web/backend/mobil uygulama üretebilir—genellikle frontend için React, backend için Go ve PostgreSQL, mobil için Flutter—ve ardından kaynak kodunu dışa aktararak burada tartışılan Kubernetes kalıplarını (deklaratif konfigürasyonlar, tekrarlanabilir rollout'lar ve rollback-dostu operasyonlar) uygulayabilirsiniz. Maliyet ve yönetişim değerlendirmeleri için /pricing'i inceleyin.
Orkestrasyon, niyetinizi (ne çalıştırılmalı) gerçek dünyadaki değişimle (node arızaları, kademeli dağıtımlar, ölçekleme olayları) koordine eder. Bireysel sunucuları yönetmek yerine iş yüklerini yönetirsiniz ve platform bunları otomatik olarak yerleştirir, yeniden başlatır ve değiştirir.
Pratikte, şu şekillerde azaltır:
Deklaratif yapılandırma, istediğiniz sonucu belirtir (ör. “bu imajdan 3 kopya, şu port üzerinden erişilebilir”), adım adım prosedür yazmak yerine.
Hemen kullanabileceğiniz faydalar:
Controller'lar, mevcut durum ile istenen durumu karşılaştıran ve aradaki farkı kapatmak için harekete geçen sürekli çalışan kontrol döngüleridir.
Bu yüzden Kubernetes “kendi kendini yönetir” gibi görünür:
Scheduler, her Pod’un hangi Node üzerinde çalışacağını, kısıtlamalar ve mevcut kapasite temelinde belirler. Rehberlik etmezseniz gürültülü komşular, hotspot'lar veya aynı node üzerinde toplanmış replikalar gibi sorunlar ortaya çıkabilir.
Operasyonel niyeti kodlamak için yaygın kurallar:
Requests, scheduler’a bir Pod’un neye ihtiyacı olduğunu söyler; limits ise ne kadar kullanabileceğini sınırlar. Gerçekçi request yoksa yerleşim tahminine dönüşür ve kararlılık genellikle zarar görür.
Pratik başlangıç önerisi:
Bir Deployment dağıtımı eski Pod’ları kademeli olarak yenileriyle değiştiren kontrollü bir geçiştir; hedef kullanılabilirlik korunmaya çalışılır.
Dağıtımları güvenli tutmak için:
Kubernetes varsayılan olarak rolling güncelleme sağlar, ancak ekipler genellikle ek desenler kullanır:
Risk toleransına, trafik şekline ve regresyonları ne kadar hızlı tespit edebildiğinize göre seçim yapın (hata oranı/gecikme/SLO tüketimi).
Bir Service, değişen bir Pod kümesi için sabit bir ön kapıdır. Labels/selectors hangi Pod’ların o kapının arkasında olduğunu belirler; EndpointSlices ise o seçiciyi şu anda karşılayan gerçek Pod IP’lerinin yaşayan listesini tutar.
Operasyonel olarak bunun anlamı:
service-name çağırırAutoscaling her katmanın net sinyallere sahip olduğunda iyi çalışır:
Yaygın hatalar:
CRD’ler, kümeye yeni API nesneleri eklemenizi sağlar (ör. Database, Cache) böylece üst düzey sistemleri aynı Kubernetes API kalıplarıyla yönetebilirsiniz.
Operator’lar, bu özel kaynakları istenen durumla uzlaştıran controller’lar ile eşleştirir ve genellikle şu işleri otomatikleştirir:
Bunları üretim yazılımı gibi değerlendirin: olgunluk, gözlemlenebilirlik ve hata modlarını incelemeden güvenmeyin.