Kubernetes’in itibar sorunu var: sektörün yarısı onu bir rozet gibi takıyor, diğer yarısı vergi gibi görüyor. Benim için kullanım noktası belli bir araç. Bir pazarlama sitesi ya da MVP, süreç yöneticisi ve CI işi olan tek bir sunucuda gayet iyi çalışır — bu sitenin dağıtımı da böyle yapılıyor. Kubernetes; birden fazla hizmet, değişken yük ve aynı altyapıya dağıtım yapan birden fazla ekip olduğunda anlam kazanmaya başlar.
Her şey konteynerle başlar. Multi-stage Dockerfile, küçük bir çalışma zamanı imajı, geliştirme bağımlılığı olmaması, root olmayan kullanıcı ve konteyner başına tek süreç. Next.js uygulaması standalone modunda derlenir; NestJS API’si yalnızca dist ve production node_modules içerir. Aynı imaj CI’dan staging’e, oradan production’a gider. Her ortam için yeniden derleme yapılmaz; yalnızca ortam değişkenleri, ConfigMap’ler ve Secret’lar üzerinden yapılandırma değişir.
Her gün kullandığım nesneler azdır: hizmet başına bir Deployment, önünde bir Service, dış trafik için TLS’li bir Ingress ve gerçekten yükü dalgalanan bileşenler için bir HorizontalPodAutoscaler. Her konteynere kaynak requests ve limits verilir; bunlar olmazsa scheduler tahminde bulunur. Readiness ve liveness probe’ları bilerek ayrı tutulur: readiness «henüz trafik gönderme», liveness «beni yeniden başlat» der. İkisini karıştırmak yavaş bir veritabanını yeniden başlatma fırtınasına çevirir. Her Node.js hizmeti ayrıca SIGTERM’i işler ve sürmekte olan istekleri tamamlar; böylece rolling update bir ödemeyi yarıda bırakmaz.
Her şey web sunucusu değildir. Kuyruk worker’ları kendi Deployment’larında çalışır ve CPU’ya değil kuyruk birikimine göre ölçeklenir. Rapor, temizlik ve ödeme sağlayıcısıyla mutabakat gibi planlanmış işler concurrencyPolicy: Forbid ayarlı CronJob’lar olarak yürür; yavaş bir çalışma sonrakiyle çakışmaz. Veritabanı migration’ları uygulama açılırken değil, rollout öncesinde Job olarak çalışır; aynı anda başlayan beş replica şemayı beş kez taşımaya kalkmamalı. PostgreSQL’i StatefulSet’te tutmak yerine RDS gibi yönetilen hizmet olarak tercih ederim — küme stateless hizmetler içindir.
Manifest’ler Git’te tutulur ve kod gibi incelenir. Helm veya Kustomize kullanan CI pipeline’ı ya da Argo CD ile GitOps üzerinden dağıtılır; böylece geri dönüş gece yarısı kubectl oturumu değil, bir revert olur. Dizüstünden kubectl apply öğrenmek içindir, production için değil. Log’lar stdout’a ve merkezi depoya, metrikler Prometheus ile Grafana’ya gider; ummak yerine kubectl rollout status ile dağıtımı izlerim. AWS’de bu genellikle yönetilen node group’lara sahip EKS demektir; ekip control plane’e değil ürüne zaman ayırır.
İki sayfalık bir site için Kubernetes’i, ortada hizmetler yokken service mesh’i, depoda düz YAML olarak secret’ları ve «staging’de çalıştı» diye limitsiz pod’ları reddederim. Kümeye ihtiyacınız olup olmadığından emin değilseniz hizmetleri, trafiği ve ekip büyüklüğünü gönderin. Kubernetes mi, tek makinede birkaç konteyner mi, yoksa Vercel gibi bir platform mu gerektiğini ve her seçeneğin yaklaşık aylık maliyetini dürüstçe söylerim.
Bir sonraki ürüne kalacak birini verin.
Başlamaya hazır mısınız? Bana yazın — hemen başlayabilir ve kalabilirim. İki haftalık devir değil, uzun vadeli iş birliği. Projenizi, gereksinimleri ve ilerlemenin en iyi yolunu konuşalım.