Kubernetes ve Docker, hazır bir yol olarak işletiliyor.
Bunları kendi ürünlerimizin altında işleten mühendislerden konteynerler, kümeler, Helm ve GitOps. Ekiplerinizin üzerinde düşünmeden devreye alma yaptığı platform.
- Docker
- Kubernetes
- Helm
- ArgoCD
- Terraform
- GitHub Actions
Docker bize dizüstü bilgisayarda, CI’da ve canlı ortamda aynı şekilde çalışan tek bir artefakt verdi.
Kubernetes ise bu artefaktı bir yere yerleştirmek, ayakta tutmak, ölçeklemek ve ona trafik yönlendirmek için tek bir API verdi — AWS, Azure, Google Cloud ya da Türkiye’deki bir kabinette, aynı manifest dosyalarıyla. Kendi ürünlerimizin — Loyalty & Retention, Sales Performance, Order & Supply Management ve Workflow & Procurement — üzerinde çalıştığı teknoloji yığınının bir parçasıdır; ürünlerimiz DevOps & Cloud ekibimizin işlettiği kümelerde çalışır.
Değer, zamanlayıcının kendisinde değil. Bir kümenin ucuzlattığı şeylerde: otomatik geri alma ile kademeli devreye almalar, bir metriğe göre yatay ölçekleme, düğüm arızasında kendi kendine iyileşme ve bir servisin tüm şeklinin yazıldığı ve gözden geçirildiği tek bir yer — manifest dosyası. Buna sahip ekipler küçük değişiklikleri sık sık yayınlayabilir. Sahip olmayan ekipler hafta sonları büyük değişiklikler yayınlar.
Kullanmadığımız durumlar: üç mühendisin baktığı, trafiği istikrarlı tek bir monolit kümeye ihtiyaç duymaz; yönetilen konteyner servisleri (ECS, Azure Container Apps, Cloud Run) ya da Vercel gibi bir PaaS bunu platform işinin çok küçük bir bölümüyle taşır. Bunu değerlendirmede, yazılı olarak, kimse bir kontrol düzlemi satın almadan önce söyleriz.
Kubernetes üzerinde teslim ettiğimiz altı şey.
Kod olarak yönetilen kümeler
Terraform’da tanımlanmış EKS, AKS ve GKE kümeleri — düğüm havuzları, IAM veya workload identity, ağ, özel uç noktalar — her ortam için yeniden üretilebilir ve bir müşteri kanıt görmek istediğinde silinip yeniden kurulabilir.
Uygulama ekipleri için hazır yol
Bir temel Helm chart’ı, her dil için bir Dockerfile şablonu, derleyen, tarayan, imzalayan ve devreye alan bir CI hattı. Yeni bir servis, panoları ve uyarıları baştan bağlanmış hâlde canlı ortama çıkabilir.
GitOps ile teslimat
ArgoCD kümeleri Git’ten uzlaştırır; böylece hedeflenen durum bir pull request’te gözden geçirilir ve sapma görünür olur. Geri alma bir revert’tir, bir kriz odası değil.
Ingress, service mesh ve zero-trust ağ
Ingress denetleyicileri, uyum gereksinimlerinin şart koştuğu yerde servisler arası mTLS, varsayılanı reddetmek olan ağ politikaları ve izin listesine alınmış, kaydı tutulan dış trafik.
Dikkatle ele alınan durumlu iş yükleri
Kafka, Redis ve arama kümeleri; operatörler, kalıcı diskler ve provası yapılmış geri yüklemelerle Kubernetes üzerinde çalışır. PostgreSQL genellikle yönetilen serviste kalır ve nedenini açıklarız.
Konteynerlere geçiş
Bir bulut geçişi sırasında legacy Java, .NET ve Node.js servislerinin konteynerleştirilmesi — her seferinde tek bir iş yükü, aynı ingress’in arkasında ve geçiş kanıtlanana kadar VM’e geri alma imkânıyla.
Ne zaman tercih edilmeli.
Çok sayıda servis işletiyorsanız, birden fazla ekip birbirinden bağımsız devreye alma yapıyorsa, trafik elle ölçeklemeyi zahmetli kılacak kadar değişkense ya da birden fazla bulutta veya şirket içi bir veri merkezinde aynı platforma ihtiyacınız varsa Kubernetes’i seçin. Bir platform ekibinin kümeyi sahiplenebildiği ve uygulama ekiplerinin onu hazır yol üzerinden kullandığı ortamlara uygundur. Ağ politikası, admission control ve her değişikliğin kod olarak denetim izine ihtiyaç duyan, düzenlemeye tabi kurumlara da uygundur.
Tek bir uygulama varsa ve kümeyi işletecek bir platform ekibi yoksa başka bir yere bakın — kontrol düzlemi, kimsenin istemediği ikinci bir ürüne dönüşür. İş yükü, yönetilen bir konteyner servisinin ya da bir PaaS’ın sorunsuz çalıştırdığı bir web sitesi veya API ise ve kurumunuz gözlemlenebilirliğe yatırım yapmaya henüz hazır değilse de başka bir yere bakın; izler ve panolar olmadan Kubernetes, yerini aldığı VM’lerden daha zor işletilir.
Güvenle geri alınabilen ve ileri taşınabilen bir devreye alma.
image: registry.odeontech.internal/loyalty-api:2.14.3
replicas: 3
# Pods only receive traffic once they can actually serve it
readinessProbe: { httpGet: { path: /ready, port: 8080 }, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /live, port: 8080 }, periodSeconds: 10 }
resources:
requests: { cpu: 250m, memory: 512Mi }
limits: { memory: 512Mi }
# Never lose the last healthy replica during a rollout or a node drain
strategy: { rollingUpdate: { maxUnavailable: 0, maxSurge: 1 } }
podDisruptionBudget: { minAvailable: 2 }
+ autoscaling: { min: 3, max: 12, targetCPU: 65 }
topologySpreadConstraints: zoneTeslim ettiğimiz hâliyle bir küme.
Teslim ettiğimiz kümelerde bulunanlar.
- Her şey kod olarak. Küme, düğüm havuzları, namespace’ler, RBAC ve eklentiler Terraform’da; iş yükleri Helm ya da Kustomize’da; her ikisi de pull request’lerde gözden geçirilir. Dizüstü bilgisayardan canlı ortama
kubectl applyyok. - Küçük, yeniden üretilebilir imajlar. Çok aşamalı Dockerfile’lar, distroless ya da slim temel imajlar, root olmayan kullanıcılar, sabitlenmiş digest’ler ve her derleme için bir SBOM. İmajlar CI’da taranır ve bir küme onları kabul etmeden önce imzalanır.
- Her pod’da requests ve limits, bellek limitleri requests ile eşit olacak şekilde; böylece zamanlayıcının gördüğü tablo gerçekle örtüşür. Dikey öneriler sizinle belirlenen bir ritimde düzenli olarak gözden geçirilir; kapasiteyi kimse tahminle belirlemez.
- Doğruyu söyleyen problar. Readiness gerçek bağımlılıkları, liveness yalnızca sürecin kendisini yansıtır, startup probları da yavaş JVM’leri kapsar — çünkü yanlış bir prob, yavaş bir veritabanını yeniden başlatma fırtınasına çevirir.
- İlk devreye almadan itibaren gözlemlenebilirlik: varsayılan olarak gönderilen OpenTelemetry izleri, Prometheus metrikleri ve yapılandırılmış loglar, yanlarında SLO panoları ve kullanıcıların hissettiği belirtiler üzerinden uyarı.
- Varsayılanı reddet olan ağ politikası her namespace’te, CSI üzerinden bir vault’tan ya da bulutun secret yöneticisinden alınan sırlar ve ayrıcalıklı pod’lar ile imzasız imajları reddeden admission politikaları.
- Disruption budget’ları, dağıtım kısıtları ve provası yapılmış düğüm boşaltmaları — bir küme yükseltmesi ya da bir spot geri alımı rutindir, önce aynı sürümlerle staging ortamında test edilir.
- Bir runbook ve bir maliyet raporu. Yükseltme, geri alma, ölçekleme, geri yükleme ve nöbet prosedürleri yazılı olarak; namespace başına maliyet ilk devreye almadan itibaren görünür, böylece doğru boyutlandırma bir proje değil bir alışkanlık olur.
Kümeyle birlikte genellikle teslim edilenler.
- Küme ve landing zone için Terraform modülleri, belgelenmiş bir ortam terfi yoluyla birlikte
- Bir temel Helm chart’ı ve ekiplerinizin kullandığı her dil için Dockerfile şablonları
- İmajları derleyen, test eden, tarayan, imzalayan ve yayınlayan CI hatları ve bunları devreye alan bir ArgoCD application set’i
- Kod olarak dışa aktarılmış Grafana panoları, uyarı kuralları ve SLO tanımları
- Otomatik ölçekleme eşiklerini belirleyen yük testi sonuçları
- Yükseltme, geri alma, olay müdahalesi ve felaket kurtarma için runbook’lar, ekibinizle birlikte bir game day’de provası yapılmış olarak
Sık sorulan sorular
Komşu teknoloji yığınları ve onları kullanan hizmetler.
Devreye almalar günün en sıradan olayı olsun ister misiniz?
Kaç servis işlettiğinizi ve bugün bunları nasıl devreye aldığınızı anlatın. Bir Kubernetes mühendisi okur ve nasıl yaklaşacağımızı yazılı olarak iletir.