Teknoloji

Ekiplerinizin ticket açmadan dağıtım yapabildiği cluster’lar

Çoğu cluster her seferinde bir ekip ve bir istisnayla büyür. GitOps’u, otomatik ölçeklemeyi, politikaları ve bir yükseltme rutinini kurarız; böylece platform, üzerine daha fazla ekip geldikçe öngörülebilir kalır.

Görüşme talep edin Bulut ve Platform Mühendisliği’ni inceleyin

Süre: Aşama başına 4 ila 12 hafta
Model: Aşamalı program
Çıktı: GitOps ile yönetilen cluster’lar ve golden path’ler

Bu hizmete ihtiyaç duyduğunuzun işaretleri

Bunların her biri cluster’da, Git geçmişinde ya da bulut faturasında görülebilir.

Değişiklikler cluster’a bir dizüstü bilgisayardan kubectl ile gidiyor; üretimdeki durum artık Git ile örtüşmüyor.
Cluster yükseltmeleri, sürümün desteği bitmek üzere olana kadar erteleniyor, sonra aceleyle yapılıyor.
Bir ekibin iş yükü diğerlerini aç bırakıyor, çünkü request ve limit değerleri ya eksik ya da eski bir örnekten kopyalanmış.
Pod’lar CPU’ya göre ölçekleniyor ama asıl sinyal kuyruk uzunluğu; yeni node’lar ani yük geçtikten sonra geliyor.
Her pod diğer her pod’la konuşabiliyor ve kimse bir varsayılan belirlemediği için container’lar root olarak çalışıyor.
Her ekibin kendi Helm chart’ları ve pipeline’ları var; yeni bir servis bir haftalık kopyalamayla ayağa kalkıyor.
Bir namespace’in ya da bir ekibin neye mal olduğunu kimse söyleyemiyor; cluster faturası yönetilmek yerine tartışılıyor.

Bir cluster, bir platform değildir

Kubernetes her ekibe aynı API’yi ve çok az varsayılanı verir. Kiracılık, kaynak talepleri, ağ kuralları ve değişikliklerin nasıl uygulanacağı konusunda ortak kararlar yoksa her ekip boşlukları kendi yöntemiyle doldurur. Cluster çalışır, ama her yükseltme, her olay ve her yeni servis bir öncekinden daha pahalıya gelir.

Akla gelen çözümler her ekibe ayrı bir cluster ya da sıfırdan kurulan yeni bir platformdur. İlki yükseltmeleri ve maliyeti katlar, ikincisi teslimatı aylarca durdurur. Biz bunun yerine çalışan cluster’lar üzerinde çalışırız: Git’i tek giriş yolu yapan Argo CD ya da Flux ile GitOps; HPA, KEDA ve Cluster Autoscaler ya da Karpenter ile gerçek sinyali izleyen otomatik ölçekleme; namespace namespace uygulanan network policy’ler ve Pod Security Standards; her minor sürümü planlı bir olaya dönüştüren bir yükseltme rutini.

Bulut ve Platform Mühendisliği daha geniş platformu kurar: hesaplar, ağlar, altyapı kodu ve teslim hatları. Bu hizmet ise Kubernetes katmanının kendisiyle ve ekiplerin onun üzerinde çalışmak için izlediği yollarla ilgilidir.

Kapsama girenler ve girmeyenler

Dahildir

Cluster topolojisi ve kiracılık: neyin bir cluster’ı, bir node pool’u ya da bir namespace’i paylaşacağı
Drift tespiti ve ortamlar arası terfi ile birlikte Argo CD ya da Flux üzerinden GitOps
Gerçek sinyale göre ayarlanmış HPA, KEDA ve Cluster Autoscaler ya da Karpenter ile otomatik ölçekleme
Varsayılan olarak network policy’ler, Pod Security Standards ve admission politikaları
Control plane, node’lar ve eklentiler için yükseltme stratejisi ve test edilmiş bir işletim kılavuzu
Golden path’ler: ekiplerin yardım almadan kullandığı servis şablonu, temel manifest’ler ve pipeline
Namespace ve ekip bazında maliyet görünürlüğü; gerçek kullanıma göre boyutlandırılmış request değerleri

Dahil değildir

Uygulamaların Kubernetes’te çalışacak şekilde yeniden yazılması
Cluster dışındaki bulut hesapları, ağlar ve landing zone’lar
Devirden sonra cluster’lar için nöbet hizmeti
Ticari Kubernetes dağıtımları için lisans satışı

İş nasıl ilerler

Hafta 1 ila 2Cluster’ları okuyun. Cluster’lara, Git depolarına ve fatura verisine salt okunur erişimle sürümleri, eklentileri, kiracılığı, politikaları, ölçekleme ayarlarını ve değişikliklerin üretime nasıl ulaştığını kayda geçiririz. Bulgular riske göre sıralanır.
Hafta 3 ila 6Git’i yetkili kılın. Argo CD ya da Flux, en az kritik olandan başlayarak dağıtımları namespace namespace devralır. Elle yapılan değişiklikler önce drift olarak görünür, sonra durur.
Hafta 5 ila 10Korkulukları ekleyin. Pod Security Standards ve admission politikaları önce audit modunda başlar, raporlar temizlenince zorunlu hale gelir. Network policy’ler ve kaynak varsayılanları namespace namespace yayılır; otomatik ölçekleme yük testleriyle ayarlanır.
Hafta 8 ila 12Yolu döşeyin. Desenler bir golden path’e dönüşür: bir şablon, temel manifest’ler ve bir pipeline. Bu yolla yardım almadan dağıtım yapan ilk ekip aşamanın sonunu işaret eder.
Süreç boyuncaErişimi dar tutun. Erişim varsayılan olarak salt okunurdur; araçları kurmak için gereken yazma yetkisi aşama bitince kaldırılır.

Elinize ne geçiyor

Tüm çıktılar sizindir: kod, raporlar, diyagramlar ve kaynak dosyaları, hepsi kendi depolarınızda.

Cluster incelemesi

Bugünkü topoloji, sürümler, kiracılık ve riskler; hedef tasarım ve diyagramların kaynak dosyalarıyla.

GitOps depoları

Cluster’larınızda çalışan Argo CD ya da Flux yapılandırması, ortamlar arası terfi ve drift uyarıları.

Politika seti

Network policy’ler, Pod Security Standards seviyeleri ve admission kuralları; her istisna yazılı olarak.

Ölçekleme yapılandırması

HPA, KEDA ve node ölçekleme ayarları; nasıl tepki verdiklerini gösteren yük testi sonuçlarıyla.

Yükseltme kılavuzu

Control plane, node pool’lar ve eklentiler için test edilmiş bir sıra ve sonraki sürümlerin takvimi.

Golden path ve maliyet görünümü

Servis şablonu, temel manifest’ler ve OpenCost ya da sağlayıcınızın maliyet verisi üzerine kurulu, namespace bazında maliyet görünümü.

Hangi durumda doğru hizmet değil

Trafiği durağan tek bir uygulama. Yönetilen bir container servisi ya da birkaç sanal makine genellikle daha kolay işletilir.
Asıl hedefi tüm servislerde daha düşük bir bulut faturası olan kurumlar. Bulut Maliyet Optimizasyonu cluster’ların ötesine bakar.
Kubernetes’i kendileri adına bir sağlayıcının işletmesini isteyen kurumlar. Platformu ekibinizle birlikte kurar ve ekibinize devrederiz.

Sık sorulanlar

Hangi dağıtımlar ve sürümlerle çalışıyorsunuz?

EKS, AKS ve GKE gibi yönetilen servislerle ve kendi yönettiğiniz upstream Kubernetes cluster’larıyla. Yükseltmeler, upstream projenin desteklediği son üç minor sürüme ve sağlayıcınızın kendi takvimine göre planlanır.

Argo CD mi, Flux mı?

İkisi de olgun CNCF projeleridir. Argo CD, birçok ekibin benimsemesini kolaylaştıran bir web arayüzüyle gelir; Flux daha hafiftir ve mevcut araçlarla iyi birleşir. Birini zaten kullanıyorsanız onu koruruz.

Politikaları zorunlu kılmak çalışan iş yüklerini bozar mı?

Sırayla yapılırsa bozmaz. Politikalar audit ya da warn modunda başlar, raporlar hangi iş yüklerinin takılacağını gösterir ve ekipler bunları düzeltir; zorunluluk ancak ondan sonra, namespace namespace açılır.

İzleme ve nöbet bu işin neresinde?

Cluster’ın doygunluk, bekleyen pod’lar ve başarısız rollout’lar gibi önemli sinyalleri sunmasını sağlarız. Servis seviyesi hedefleri, alarmlar ve olay yönetimi pratiği Gözlemlenebilirlik ve SRE hizmetinin konusudur.

Aşama bittiğinde ne olur?

Ekibiniz cluster’ları işletim kılavuzlarıyla yönetir ve yazma yetkisi kaldırılır. İlk yükseltmeyi kendi başınıza yaparken destek isterseniz, bir gömülü mimar ekiple haftada 2 ila 3 gün çalışabilir.

Önce kısa bir teknik sohbetle başlayalım

Otuz dakika. Cluster’larınızı ve ekiplerinizi anlatırsınız, işi yürütecek mimar nereden başlayacağımızı söyler.

Görüşme talep edin info@futureformative.net