Gateway API’yi kind ile Deneme: Lokal Lab Kurulumu

Geçen hafta bir müşterinin AKS cluster’ında Ingress’ten Gateway API’ye geçiş planını konuşurken, ekipten bir arkadaş “abi biz bunu önce bir yerde deneyelim de görelim, prod’a direkt sokmayalım” dedi (şaşırtıcı ama gerçek). Haklıydı. Tahmin eder mısınız? Bizim Logosoft’ta da kural aynı, prod’a gitmeden önce muhtemelen bir lab kuruyoruz; ama her seferinde yeni bir Azure subscription açmak, AKS ayağa kaldırmak, üstüne bir de Application Gateway for Containers ayarlamak, açık konuşayım, hem vakit yiyor hem de gereksiz masraf çıkarıyor.

Eh, İşte tam bu noktada kind (Kubernetes in Docker) devreye giriyor. Laptop’ta Docker varsa, 5 dakika içinde Gateway API denemesi yapabileceğiniz bir lab ortamı kurabiliyorsunuz, hani öyle uzun uzun uğraştıran cinsten değil. Bedava sayılır. Hızlı da. Bir şey ters giderse de kind delete cluster deyip sıfırdan başlamak mümkün,. “bozdum galiba” paniği çok kısa sürüyor.

Gateway API de bu karmaşayı toparlamak için çıktı. SIG-Network’ün resmî projesi olarak geliyor ve üç temel kaynak üstünden ilerliyor: GatewayClass hangı controller’ın kullanılacağını söylüyor, Gateway dinleyicileri ve portları tanımlıyor, HTTPRoute işe asıl routing kurallarını taşıyor. Sorumluluk da daha temiz ayrılıyor; platform ekibi Gateway tarafını kuruyor, uygulama ekibi kendi HTTPRoute’unu yazıyor.

İnanın, Şey, bu ayrım kağıt üstünde küçük görünüyor ama pratikte baya iş görüyor. Kurumsal tarafta çalışanlar bilir, bir yerde platform ekibi altyapıyı yönetirken başka bir ekip sadece route tanımıyla uğraşıyorsa kavga azalıyor (tamamen bitmiyor tabii),. Kim neyi değiştirebilir sorusu en azından daha net hâle geliyor.

Hmm, bunu nasıl anlatsamdı…

İşte, peki neden?

Bence Gateway API’nın asıl olayı teknik oyuncaklardan çok RBAC tarafında yatıyor. Bir bankacılık projesinde Ingress kullanırken “uygulama ekibi annotation’ları değiştirip TLS politikasını bozuyor” diye sürekli gerilim çıkıyordu. Gateway API’de bu mesele yapısal olarak daha temiz çözülmüş.

Neyse uzatmayalım, yukarıda bahsettiğim olayın özü şu: Ingress çoğu zaman tek bir kapı gıbı davranıyor ama arkada farklı ekiplerin farklı beklentileri var; Gateway API işe o kapının önüne biraz düzen koyuyor, yanı herkesin elini aynı anda her yere sokmasını zorlaştırıyor. Açık konuşayım, ilk bakışta fazla teorik gıbı durabiliyor ama güvenlik. Sahiplik konusu devreye girince fark hemen hissediliyor.

Neden kind? Minikube ya da k3d Değil de?

Küçük bir detay: Açık konuşayım: minikube da ölür, k3d de ölür. Hatta ikisiyle de (belki yanılıyorum ama) Gateway API’yi rahatça yoklayabilirsiniz, yanı iş görürler. Ama ben kind tarafına biraz daha fazla meylediyorum, çünkü birkaç pratik sebep var (bu konuda ikircikliyim). Bunlar günlük kullanımda insanın canını daha az sıkıyor.

Birinçisi, kind tamamen Docker container’ları üzerinde dönüyor — VM yok, Hyper-V’yi aç kapa derdi yok, bir ayar yapıp sonra neden çalışmadı diye ekran başında bakınma işi azalıyor. İkincisi, sigs.k8s.io altında olduğu için Kubernetes ekibinin kendi conformance testlerinde kullandığı araçlardan biri; yanı “production gıbı davranma” kısmında fena durmuyor. Üçüncüsü — ve bence en tatlı tarafı bu — cloud-provider-kind diye bir bileşeni var ki, hem LoadBalancer Service’leri hem de Gateway API controller tarafını tek pakette toparlıyor, baya iş görüyor.

İşte tam da bu noktada devreye giriyor.

Geçen ay bir eğitimde minikube ile aynı senaryoyu kurmaya çalışan bir kursiyer vardı; MetalLB kurulumu, IP havuzu ayarı, sonra bir de servis erişimi derken iş uzadı da uzadı. Kind ile aynı şey üç komutta halloldu, şaşırdım açıkçası. Evet, bazen bu kadar basit oluyor.

Neyse, peki neden?

Önceden Lazım Olanlar

Şunu fark ettim: Başlamadan önce makinede birkaç araç kurulu olsun. Çok uzatmayalım; Docker olmadan zaten bu iş yürümüyor, kubectl’i de herhalde söylemeye gerek yok. Yine de listede dursun çünkü sonradan “şey eksikti galiba” demek istemiyoruz.

• Docker — kind ve cloud-provider-kind’ın motoru. Docker Desktop da ölür, native Docker da ölür; hangisi rahatsa önü kullanın.
• kubectl — bunu zaten kullanıyorsunuzdur sanırım.
• kind — Go ile yazılmış tek binary. brew install kind ya da Windows için scoop işinizi görür.
• curl — test ederken kullanacağız. Zaten çoğu sistemde var, yoksa da kısa sürede hallediliyor.

İnanın, Bir uyarı düşeyim: Docker Desktop kullanıyorsanız ve Windows’taysanız, WSL2 backend’in açık olduğuna bakın. Hyper-V backend ile bazen network tarafında garip şeyler yaşadım; sebebini tam çözememiştim açıkçası. WSL2’ye geçince düzeldi (ki bu çoğu kişinin gözünden kaçıyor). Yanı sorun Kubernetes’ten çok ortamdan çıkabiliyor, önü da kenara not etmek lazım.

Peki, tam da öyle.

Cluster’ı Ayağa Kaldırma

Şimdi işin kalbine geliyoruz. İlk adımda kind cluster’ı kuracağız, hepsi bu. Tek satır yeter:

kind create cluster --name gateway-lab

Bu komut single-node bir Kubernetes cluster’ı ayağa kaldırıyor. Birkaç saniye içinde toparlıyor, sonra da sessizce bekliyor. --name vermenizi özellikle öneririm, çünkü sonra bir bakıyorsunuz elinizde birkaç cluster olmuş (ben mesela “gateway-lab”, “service-mesh-lab” gıbı tematik isimler kullanıyorum), karışmasın diye bu küçük detay baya iş görüyor.

Cluster ayakta mı, ona bakalım:

kubectl get nodes
kubectl cluster-info --context kind-gateway-lab

cloud-provider-kind Kurulumu

Bi saniye — Burada iş biraz ilginçleşiyor. cloud-provider-kind bizim için iki kritik işi üstleniyor: LoadBalancer tipindeki Service’lere gerçek IP veriyor (normalde kind tarafında bunlar “pending” kalıyor), bir de Gateway API controller’ını implement ediyor — yanı Gateway. HTTPRoute kaynaklarını gerçekten çalıştıran motor kısmı burada dönüyor.

Bir bonus daha var. Gateway API CRD’lerini de otomatik kuruyor. Eskiden bunları tek tek kubectl apply ile yüklerdik, açık konuşayım biraz uğraştırıyordu; şimdi tek hamlede halloluyor, fena değil.

VERSION=$(basename $(curl -s -L -o /dev/null -w '%{url_effective}' \
https://GitHub.com/kubernetes-sigs/cloud-provider-kind/releases/latest))
Docker run -d --name cloud-provider-kind --rm \
--network host \
-v /var/run/Docker.sock:/var/run/Docker.sock \
registry.k8s.io/cloud-provider-kind/cloud-controller-manager:${VERSION}

Şöyle ki, Dikkat etmeniz gereken nokta şu: --network host Linux’ta sorunsuz çalışıyor. MacOS tarafında iş biraz değişiyor. Docker Desktop’ın host network desteği hâlâ tam oturmuş değil, yanı Maç kullanıyorsanız. LoadBalancer IP’sine erişemiyorsanız şaşırmayın; cloud-provider-kind’ın README’sindeki Mac-specific notlara bakın, orada port-forwarding ile bir workaround anlatıyorlar. Daha fazla bilgi için Foundry Agent Memory: Procedural Bellek ile Üretime Hazır yazımıza bakabilirsiniz.

Bende ilk denemede hata çıktı, hem de klasik bir hata: “permission denied while trying to connect to the Docker daemon socket”. Çözüm basit gıbı görünüyor ama can sıkıyor; ya sudo ile çalıştıracaksınız ya da kullanıcıyı Docker grubuna ekleyeceksiniz (inanın bana). Bir kerelik dert, sonra unutuyorsunuz.

kubectl get gatewayclass

apiVersion: v1
kind: Namespace
metadata:
name: gateway-infra
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: gateway-infra
spec:
gatewayClassName: cloud-provider-kind
listeners:
— name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
spec:
replicas: 2
selector:
matchLabels: { app: demo }
template:
metadata:
labels: { app: demo }
spec:
containers:
— name: web
image: nginxdemos/hello:plain-text
ports:
— containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: demo-svc
spec:
selector: { app: demo }
ports:
— port: 80
targetPort: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: demo-route
spec:
parentRefs:
— name: my-gateway
namespace: gateway-infra
hostnames:
— "demo.local"
rules:
— matches:
— path:
type: PathPrefix
value: /
backendRefs:
— name: demo-svc
port: 80

kubectl get gateway -n gateway-infra -w

GATEWAY_IP=$(kubectl get gateway my-gateway -n gateway-infra -o jsonpath='{.status.addresses[0].value}')
curl -H "Host: demo.local" http://$GATEWAY_IP/

İnanın, Sorun 1: Gateway IP “pending” kalıyor, bir türlü atanmyor. Bakın, çözüm basit gıbı duruyor ama bazen değil; cloud-provider-kind container’ı düşmüş olabiliyor, o yüzden Docker ps ile bakın, sonra loglara göz atın, çünkü bende bir keresinde Docker daemon yeniden başlamıştı ve container’ı resmen kaybetmiştim.

Sorun 2: curl 404 dönüyor. Peki neden? Çoğu zaman işin aslı Host header’ında gizli oluyor; HTTPRoute‘ta hostnames: ["demo.local"] dediyseniz, curl tarafında da -H "Host: demo.local" vermek gerekiyor, yanı küçük bir detay bütün işi bozabiliyor.

Eh, Sorun 3: macOS’ta LoadBalancer IP’sine erişilemiyor. Hmm, burada kısa cevap yok; Docker Desktop’ın network namespace izolasyonu macOS’ta biraz farklı davranıyor (evet, can sıkıcı), bu yüzden cloud-provider-kind‘ın GitHub issue’larında dönen tartışmalara bakınca nedenini daha net görüyorsunuz.

İnanın, Bir de şunu unutmayın: kind’ın Kubernetes versiyonunu kafanıza göre seçebiliyorsunuz. Mesela kind create cluster --image kindest/node:v1.32.0 diyerek istediğiniz sürümü açabilirsiniz; bugün şart olmayabilir. Yeni Gateway API özelliklerine geçince bu ayar işinize yarıyor, hatta ben bunu sonradan fark ettim. Kubernetes v1.36: Askıdaki Job’lara Kaynak Ayarı Geldi yazımda yeni versiyondaki başka değişikliklere de bakmıştım.

Sonraki Adımlar — Lab’ı Nereye Götürebilirsiniz?

Temel kurulum tamam. Şimdi işin tadı çıkıyor, çünkü lab’ı gerçek senaryolara biraz eğip bükebilirsiniz:

• Canary deployment: İki HTTPRoute backendRef’i tanımlayıp weight’lerle trafiği %90/%10 diye bölün. İlk bakışta basit duruyor, ama canlıya yakın bir testte bu küçük ayrım baya işe yarıyor.
• Header-based routing: “X-Beta-User: true” header’ı geleni yeni sürüme, diğerlerini eskiye yönlendirin. Hani bazen “bu kullanıcıyı ayrı bir yola alayım” dersiniz ya, işte tam o iş.
• TLS terminasyonu: cert-manager ile self-signed bir sertifika üretip Gateway’in HTTPS listener’ına bağlayın. Kolay gıbı görünüyor, ama sertifika zinciri ve listener eşleşmesi kısmında insan bir an durup ekrana bakıyor.
• Cross-namespace routing: ReferenceGrant ile farklı namespace’lerdeki Service’lere route açın — bu özellik Ingress’te yoktu. Açık konuşayım, burada Gateway API’nın eli Ingress’e göre daha rahat.
• GAMMA initiative: Service Mesh entegrasyonu için Gateway API’nın mesh tarafını deneyin. Şey, ilk başta biraz soyut geliyor ama meshin içine girince taşlar yerine oturuyor.

Eğer AI/agent tarafıyla da ilgileniyorsanız, Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak yazımda Kubernetes üzerinde agent çalıştırırken Gateway API’nın nasıl bir routing katmanı olarak işe yaradığını anlatmıştım. Orada da aynı mantık var aslında; trafik nereye gidecek, kim neyi görecek, hangı istek hangı kapıdan geçecek (ve neden oradan geçecek), bunları netleştirince geri kalan taraf daha derli toplu oluyor.

Peki sonra ne yaparsınız? Deneyin. Bozun. Tekrar kurun. Evet.

Sıkça Sorulan Sorular

Gateway API, Ingress’in yerini alıyor mu?

Kısa cevap: Hayır, en azından önümüzdeki birkaç yıl için değil. Ingress milyonlarca cluster’da koşuyor ve deprecate edilmesi planlanmıyor. Ama yeni projelerde Gateway API tercih ediliyor. Bence Ingress, Kubernetes’in “klasik” çözümü olarak daha uzun süre hayatımızda kalacak.

kind production için kullanılabilir mi?

İşte, küçük bir detay: Vallahi hayır. kind’ın adı zaten “Kubernetes IN Docker” — yanı her şey Docker container’larının içinde koşuyor. Tek node, kalıcı storage yok, HA yok. Açıkçası bunu production’da kullanan birini görürsem şaşırırım. Sadece development, test ve CI/CD pipeline’larında kullanın. Production için AKS, EKS, GKE ya da kendi bare-metal cluster’ınız daha mantıklı.

cloud-provider-kind’ı silersem Gateway’lere ne ölür?

Gateway’ler “Programmed” statüs’ünü kaybediyor ve trafik akmıyor. CRD’ler kalıyor ama controller olmadığı için hiçbir şey işlenmiyor. Yanı aslında ortada öksüz kaynaklar kalıyor. Cluster’ı temizlemek istiyorsanız önce HTTPRoute’ları. Gateway’leri silin, sonra cloud-provider-kind’ı durdurun — bu sıralamayı es geçmeyin.

AKS’te Gateway API’ye nasıl başlayabilirim?

İki yol var. Birinçisi Application Gateway for Containers — managed bir çözüm, hani IP, sertifika, ölçeklendirme gıbı dertleri Azure çekiyor. İkincisi, NGINX Gateway Fabric veya Istio gıbı açık kaynak bir controller’ı AKS üzerine kurmak. Tecrübeme göre küçük ekipseniz birinciyi tercih edin; mesh entegrasyonu hedefleyen bir mimariniz varsa ikinciyi düşünün.

Evet, doğru duydunuz.

HTTPRoute dışında başka route tipleri var mı?

Evet, birkaç tane daha var. TCPRoute, UDPRoute, TLSRoute ve GRPCRoute mevcut. TCP/UDP route’lar şu an experimental kanalda. gRPC tarafı işe stable’a yakın geliyor (inanın bana). Mesela bir Redis cluster’ını Gateway üzerinden expose etmek istiyorsanız TCPRoute tam size göre.

Kaynaklar ve İleri Okuma

Kubernetes Gateway API Resmî Dokümantasyonu — spec, kavramlar ve implementation listesi için ilk durağınız.

cloud-provider-kind GitHub Reposu — kurulum detayları, platforma özel notlar. Issue tracker.

kind Resmî Sitesi — kind’ın tüm konfigürasyon seçenekleri. Multi-node cluster örnekleri.

Azure Application Gateway for Containers — production’a geçtiğinizde AKS tarafında managed seçenek.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Kubernetes v1.36 Controller Staleness: Artık Daha Az Acı29 Nis 2026

SAP Sapphire 2026: Azure Tarafında Yeni Dönem Başlıyor16 May 2026

CodeAct ve Hyperlight: Agent'ları Tek Hamlede Hızlandırmak23 Nis 2026

Claude Opus 4.7 GitHub Copilot'ta: Ne Değişiyor?17 Nis 2026