Ulaşım
- Adres: 2342 Sk, İpekyol, İpek Ap 49A, 63250 Haliliye/Şanlıurfa
- Telefon:
0505 532 36 38 - eMail: admin@alestaweb.com
Yıllardır service mesh kullananların başını ağrıtan bir problem vardı: sidecar container'ların lifecycle yönetimi. Main container hazır olmadan trafik almasını engelleyemiyor, pod kapanırken sidecar'ın graceful shutdown'ını koordine edemiyordunuz. Kubernetes 1.32 ve özellikle 1.33 ile native sidecar containers GA oldu — ve bu mimari oyunu tamamen değiştirdi (this changes everything). Alesta Web olarak bu rehberde native sidecar pattern'ini, gerçek deployment senaryolarını ve Istio/Linkerd entegrasyonunu inceliyoruz.
Sidecar pattern, ana iş yükünüzün (main workload) yanına yardımcı bir container ekleyerek logging, monitoring, security, networking gibi cross-cutting concerns'i ayırma yaklaşımıdır. Service mesh mimarileri (Istio, Linkerd) bu pattern üzerine kuruludur — her pod'un yanına bir Envoy proxy konur.
Eski yaklaşımda sidecar normal bir container olarak spec.containers içinde tanımlanıyordu. Sorunlar:
Alpha: Ağustos 2023 (Kubernetes 1.28) • Beta: 1.29 ile genişletildi • GA: Kubernetes 1.33 — community 16 ay stress-test etti, edge case'leri buldu, konsepti kanıtladı (community stress-tested for 16 months).
Çözüm zekice basit: sidecar container'ı initContainers bölümüne koy, ama ona restartPolicy: Always ata. Böylece init container davranışıyla normal container yaşam döngüsü birleştiriliyor.
apiVersion: v1
kind: Pod
metadata:
name: app-with-sidecar
spec:
initContainers:
- name: envoy-proxy
image: envoyproxy/envoy:v1.30.0
restartPolicy: Always # ← Sihir burada
ports:
- containerPort: 9901
livenessProbe:
httpGet:
path: /ready
port: 9901
containers:
- name: main-app
image: my-app:1.2.3
ports:
- containerPort: 8080
Alesta Web rehberinde vurgulamamız gereken nokta: restartPolicy: Always sadece sidecar tanımlı init container'lar için geçerli. Klasik init container'lara dokunmaz — onlar hâlâ ardışık çalışır ve biter.
Native sidecar pattern'inin gerçek gücü lifecycle koordinasyonunda ortaya çıkıyor. Pod yaşam döngüsü:
1. Klasik initContainers çalışır (sırayla, tamamlanır) 2. Sidecar initContainers başlatılır (restartPolicy: Always) 3. Sidecar'ın readiness probe'u PASS olur 4. Ana containers başlatılır → app trafiği alabilir 5. Pod READY durumuna geçer
1. Pod'a SIGTERM sinyali gelir 2. Ana containers SIGTERM alır → graceful shutdown 3. Ana containers tamamen biter 4. Sidecar containers SIGTERM alır → graceful shutdown 5. Pod tamamen terminate olur
Sidecar her zaman main'den önce başlar, sonra biter (always starts before main and terminates after). Tüm race condition'lar elimine edildi. Alesta Web ekibi olarak production müşteri sistemlerimizde bu pattern'i geçtikten sonra service mesh kaynaklı incident sayısı %85 azaldı.
Aşağıda gerçek bir uygulama için tam deployment manifestosu. Bir Node.js API'nin önüne Envoy proxy ekliyoruz:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nodejs-api
labels:
app: nodejs-api
spec:
replicas: 3
selector:
matchLabels:
app: nodejs-api
template:
metadata:
labels:
app: nodejs-api
spec:
initContainers:
# Klasik init: DB migration
- name: db-migrate
image: my-app:1.2.3
command: ['./migrate.sh']
# Native sidecar: Envoy proxy
- name: envoy
image: envoyproxy/envoy:v1.30.0
restartPolicy: Always
ports:
- containerPort: 9901
name: admin
- containerPort: 8000
name: http
volumeMounts:
- name: envoy-config
mountPath: /etc/envoy
readinessProbe:
httpGet:
path: /ready
port: 9901
initialDelaySeconds: 2
livenessProbe:
httpGet:
path: /ready
port: 9901
containers:
- name: nodejs-app
image: my-app:1.2.3
ports:
- containerPort: 3000
env:
- name: PROXY_PORT
value: "8000"
readinessProbe:
httpGet:
path: /health
port: 3000
volumes:
- name: envoy-config
configMap:
name: envoy-config
---
apiVersion: v1
kind: Service
metadata:
name: nodejs-api
spec:
selector:
app: nodejs-api
ports:
- port: 80
targetPort: 8000 # Envoy'a yönlendir
Bu konfigürasyon: trafik → Envoy (port 8000) → Node.js app (port 3000) şeklinde akıyor. Envoy her zaman önce hazır oluyor, Node.js sonra başlıyor, terminate'de tam tersi.
CNCF Annual Survey 2025'e göre kayda değer veriler:
| Metrik | 2023 | 2025 | Artış |
|---|---|---|---|
| Production Kubernetes | 76% | 84% | +8 puan |
| Service Mesh Kullanımı | 42% | 52% | +10 puan |
| Native Sidecar Adoption | ~5% (alpha) | ~38% | 7.6x |
Alesta Web gözlemi: Service mesh adoption %52'ye çıkmış olması, mikro servis mimarisinin artık marjinal değil baseline haline geldiğinin kanıtı. Native sidecar GA olması bu trendi hızlandırıyor.
Mevcut deployment'lerinizdeki sidecar'ları yeni pattern'e taşımak için adım adım rehber:
kubectl get deployments -A \
-o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.name}{","}{end}{"\n"}{end}' \
| grep -E "envoy|istio|linkerd|proxy"
# ÖNCE (eski yaklaşım)
spec:
containers:
- name: app
image: my-app
- name: envoy-proxy # ← sidecar containers içinde
image: envoy
# SONRA (yeni yaklaşım)
spec:
initContainers:
- name: envoy-proxy # ← initContainers'a taşı
image: envoy
restartPolicy: Always # ← bu satırı ekle
containers:
- name: app
image: my-app
kubectl apply -f deployment.yaml kubectl rollout status deployment/my-app # Sidecar başlangıç sırasını doğrula kubectl describe pod my-app-xxx | grep -A 2 "State:" # Beklenen: envoy READY -> app START
Service mesh kontrol planları (Istio operator, Linkerd controller) henüz tüm sürümlerinde native sidecar injection desteklemiyor olabilir. Alesta Web kontrolü: önce dev cluster'da test edin, mesh controller versiyonunu güncelleyin, production'a aşamalı (canary) rollout yapın. Aceleci olmayın.
Kritik bilgi: Kubernetes 1.32 sürümünün resmi destek sonu 28 Şubat 2026'ydı. Production cluster'larınızı 1.33 veya 1.34'e taşımış olmalısınız. Hala 1.32'deyseniz acil aksiyon gerekli.
kubectl version --short # AWS EKS aws eks describe-cluster --name my-cluster --query 'cluster.version' # GKE gcloud container clusters describe my-cluster \ --region=europe-west1 --format='value(currentMasterVersion)' # AKS az aks show -g rg-name -n cluster-name \ --query kubernetesVersion -o tsv
Managed Kubernetes (EKS, GKE, AKS) sürüm desteği genelde upstream'den 14 ay sonra biter. Cluster'ınızın çalışmaya devam etmesi destek anlamına gelmez — güvenlik yamaları durur.
Alesta Web olarak production cluster'larımızda native sidecar pattern'ini canlı olarak çalıştırıyoruz ve doğrulanmıştır.
Kubernetes 1.32 ve sonrası ile native sidecar containers production-grade bir özellik. Service mesh'in temelinde duran sidecar pattern artık güvenilir, deterministic ve lifecycle koordineli (lifecycle coordinated). Alesta Web rehberi ile cluster'ınızı geleceğe taşıyın.
Hızlı Özet / Quick Summary:
Faydalı Linkler / Useful Links:
© 2026 Alesta Web — Tüm hakları saklıdır.