Kubernetes’te eBPF Tabanlı Cilium Kurulumu ve Hubble ile Ağ Gözlemlenebilirliği: Adım Adım Rehber

eBPF ve Cilium Neden Gündemde?

Kubernetes kümelerinde ağ katmanını hızlandırmak, gözlemlenebilirliği artırmak ve güvenliği sadeleştirmek için en çok konuşulan çözümlerden biri Cilium. Temelindeki eBPF (extended Berkeley Packet Filter) sayesinde paketleri çekirdek seviyesinde akıllıca işler, iptables tabanlı zincirlerin karmaşıklığını ve maliyetini azaltır. Bu da daha düşük gecikme, daha yüksek throughput ve net politika yönetimi sağlar. Üstelik Hubble bileşeniyle, canlı trafiği ve servis topolojisini sezgisel şekilde izleyebilirsiniz.

Önkoşullar

Bu rehberi uygulamak için çalışan bir Kubernetes kümesine ve küme yöneticisi yetkisine (cluster-admin) ihtiyacınız var. Çekirdek (Linux kernel) 5.4+ sürümü ve eBPF özelliklerinin etkin olması önerilir. kubectl ve Helm araçlarının yüklü olduğundan emin olun. Yönetilen bulut kümelerinde (EKS/AKS/GKE) Cilium desteklenir; ancak ağ eklentisi değiştirme adımları sağlayıcıya göre farklılık gösterebilir. Mevcutta başka bir CNI kullanıyorsanız, çakışmaları önlemek için ilgili eklentiyi temizlemeniz gerekir.

Kurulum: Helm ile Cilium

İlk adım olarak Helm deposunu ekleyip, Cilium’u kube-system ad alanına kuracağız. Eğer kube-proxy hâlen etkinse “partial” mod güvenli bir başlangıçtır; kube-proxy’yi tamamen devreden çıkarıp Cilium’u tam vekil (“strict”) olarak da kullanabilirsiniz.

Helm deposunu ekleyin ve güncelleyin
helm repo add cilium https://helm.cilium.io
helm repo update

Seçenek A — kube-proxy ile birlikte (kısmi değiştirme)
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=partial \
--set hubble.enabled=true

Seçenek B — kube-proxy’siz (tam değiştirme)
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=strict \
--set k8sServiceHost=<API-SERVER-IP> \
--set k8sServicePort=6443 \
--set hubble.enabled=true

İsteğe bağlı olarak, pod’lar arası trafiği şifrelemek için WireGuard’ı etkinleştirebilirsiniz. Bu, özellikle çok kiracılı ortamlarda veya düğümler arası segmentasyonun kritik olduğu durumlarda faydalıdır:

helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set encryption.enabled=true \
--set encryption.type=wireguard

Hubble ile Canlı Trafik ve Politikaları İzleme

Hubble, Cilium’un ağ akışlarını, DNS isteğini, servis iletişimini ve politika kararlarını gözlemlemenizi sağlar. Hubble Relay ve Hubble UI bileşenlerini açarak tarayıcı üzerinden topolojiyi inceleyebilirsiniz.

Hubble Relay ve UI’ı etkinleştirme
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true

Cilium CLI ile durum ve bağlantı testleri yapmak iyi bir pratiktir. Eğer cilium-cli yüklü değilse, sisteminize uygun binary’yi indirip PATH’e ekleyin. Kurulumdan sonra:

cilium status --namespace kube-system
cilium connectivity test --namespace kube-system

Hubble UI’a erişmek için port yönlendirme kullanabilirsiniz:

kubectl -n kube-system port-forward svc/hubble-ui 12000:80
Ardından tarayıcınızda http://localhost:12000 adresini açarak servis haritasını, akışları ve politikaların etkisini canlı izleyin.

Örnek CiliumNetworkPolicy

Cilium, Kubernetes NetworkPolicy’yi destekler; ayrıca daha ifade gücü yüksek CiliumNetworkPolicy (CNP) kaynakları sunar. Aşağıdaki örnek, sadece aynı ad alanındaki “frontend” etiketli pod’lardan “backend”e 8080/TCP erişimi veriyor ve DNS’i izinli kılıyor:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: backend-allow-frontend
namespace: app
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
- toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"

Bu politikayı uyguladıktan sonra Hubble UI veya hubble observe ile akışları takip ederek beklenen kısıtlamaların aktif olduğunu doğrulayın. Politika yazarken etiket tutarlılığı, ad alanı kapsamı ve port-protokol eşleşmelerine dikkat edin.

Sorun Giderme İpuçları

Kurulumda çoğunlukla iki tür sorunla karşılaşılır: eski CNI artıklarının çakışması ve çekirdek özellikleri. Daha önce Calico, Flannel vb. kullanıyorsanız, /etc/cni/net.d altındaki eski konfigürasyonları temizlediğinizden emin olun. Düğümleri yeniden başlatmak, CNI eklentisinin tutarlı şekilde devreye girmesine yardımcı olur.

Cilium pod’larının loglarını kontrol etmek genelde yeterli ipucunu verir: kubectl -n kube-system logs -l k8s-app=cilium. eBPF haritalarıyla ilgili hata görürseniz, çekirdek özelliklerini ve gerekli sysctl ayarlarını doğrulayın. Ağ tıkanmaları için cilium bpf metrics list ve cilium status çıktıları yol göstericidir.

Performans ve Güvenlik Notları

eBPF tabanlı yönlendirme ve servis yük dengeleme, özellikle yüksek pod yoğunluğu olan kümelerde belirgin CPU kazanımı sağlar. WireGuard şifreleme, düğümler arası trafiği güvenli kılarken, Egress Gateway özelliği dışa giden trafiğin sabit bir çıkış IP üzerinden çıkmasını sağlayabilir. DNS görünürlüğü, servis keşfi sorunlarını hızla ayıklamanıza yardım eder. Tüm bu bileşenler birlikte, daha şeffaf, hızlı ve güvenli bir Kubernetes ağı sunar.

Sonuç

Cilium + Hubble ikilisi, Kubernetes ağını sadece çalışır halde tutmakla kalmaz; aynı zamanda onu ölçülebilir, şeffaf ve yönetilebilir kılar. Bu rehberde temel kurulum, Hubble ile gözlemlenebilirlik ve örnek bir politika akışı sunduk. İlk başarıyı aldıktan sonra, servis mesh entegrasyonları, egress kontrolü ve gelişmiş akış metrikleri gibi özelliklerle kurulumunuzu genişletebilirsiniz. Üretim ortamında versiyon yükseltme ve yedeklilik planlarını da dahil ederek, Cilium’un gücünü güvenle ölçeklendirin.

Docker Buildx ile Çok Mimarili İmaj Oluşturma ve Cosign ile İmzalama (Güncel Rehber)

Giriş

Apple Silicon (ARM64) cihazların yaygınlaşması ve edge sunucuların çoğalmasıyla, tek bir mimariye derlenmiş konteyner imajları hızla demode oldu. Üretim ortamında aynı uygulamayı hem linux/amd64 hem de linux/arm64 üzerinde sorunsuz çalıştırmak için Docker Buildx ile çok mimarili (multi-arch) imaj üretmek artık bir zorunluluk. Bu yazıda, Buildx’i etkinleştirme, çok mimarili push, önbellek optimizasyonu ve imaj imzalama (Sigstore Cosign) adımlarını pratik ve güncel bir yaklaşımla anlatıyorum.

Neden Çok Mimarili İmaj?

M1/M2/M3 Mac’lerde lokal geliştirme yapıp, üretimde x86_64 (amd64) sunuculara deploy etmek en yaygın senaryo. Multi-arch sayesinde tek bir etiket ile iki mimariyi de içeren bir manifest yayınlarsınız; docker pull işlemi çalıştığı platforma uygun katmanı otomatik indirir. Böylece ayrı Dockerfile’lar, ayrı registry etiketleri ve karmaşık akışlar ortadan kalkar.

Önkoşullar

- Docker 20.10+ ve BuildKit etkin (varsayılan).
- QEMU emülasyonu için binfmt kurulumu (host’ta veya builder içinde).
- Bir container registry (Docker Hub, GHCR, ECR vb.).
- Opsiyonel: İmaj imzalama için Cosign ve SBOM üretimi.

Buildx’i Etkinleştirme ve Binfmt Kurulumu

Önce Buildx sürümünüzü kontrol edin: docker buildx version. Yeni bir builder oluşturup varsayılan yapın: docker buildx create --name multi --use. Gerekirse platform emülasyonu için docker run --privileged --rm tonistiigi/binfmt --install all komutunu çalıştırın. Bu adım, ARM64 makinede amd64 image derlemek gibi çapraz mimari senaryoları mümkün kılar.

Tek Komutta Çok Mimarili İmaj Üretme

Proje dizininizde basit bir Dockerfile olduğunu varsayalım. Multi-arch build ve push için şu kalıbı kullanabilirsiniz: docker buildx build --platform linux/amd64,linux/arm64 -t kullanici/uygulama:1.0 --push . Bu komut, her iki mimari için ayrı katmanlar üretir ve registry’e tek bir manifest altında yükler. Test etmek için docker buildx imagetools inspect kullanici/uygulama:1.0 çıktısında iki platformu görmelisiniz.

Performans ve Önbellek İpuçları

Yapı sürelerini kısaltmak için BuildKit cache kullanın. Registry tabanlı önbellek için: --cache-to type=registry,ref=kullanici/uygulama:cache,mode=max ve --cache-from type=registry,ref=kullanici/uygulama:cache seçeneklerini ekleyin. Ayrıca, Dockerfile’ı katman dostu yazmak (bağımlılıkları erken kopyalamak, --mount=type=cache kullanımı, çok aşamalı derleme) build sürelerini dramatik şekilde azaltır.

CI/CD’de Otomasyon (GitHub Actions Örneği)

CI’da tipik akış: checkout → docker/setup-qemu-action ile QEMU → docker/setup-buildx-action ile Buildx → registry’ye login → docker buildx build --platform linux/amd64,linux/arm64 --push. Sürüm etiketlerini v1.2.3, latest ve commit SHA gibi çoklu tag’lerle birlikte yayınlamak, tüketicilerin sağlam bir sürüm stratejisi izlemesine yardımcı olur.

Güvenlik: Cosign ile İmaj İmzalama ve SBOM

Supply chain güvenliği artık lüks değil. Cosign ile imajlarınızı imzalayarak, imajın sizden çıktığını kanıtlayabilirsiniz. Adımlar basit: cosign generate-key-pair ile bir anahtar çifti üretin; cosign sign --key cosign.key kullanici/uygulama:1.0 ile imzalayın; doğrulama için cosign verify --key cosign.pub kullanici/uygulama:1.0 çalıştırın. Build aşamasında SBOM eklemek için Buildx’in --sbom=true ve --provenance=mode=max seçeneklerini kullanabilir, yazılım bileşen envanterini otomatik üretip imajla ilişkilendirebilirsiniz.

Yaygın Hatalar ve Çözüm Yolları

- “no match for platform in manifest”: Multi-arch manifest push edilmemiş olabilir; --push bayrağını ve --platform listesini kontrol edin.
- Temel imaj arm64 yok: Kullandığınız base image’in her iki mimari için resmi desteği olduğundan emin olun. Örneğin alpine, debian ve ubuntu çoğunlukla multi-arch sunar.
- Yavaş build: QEMU emülasyonu doğal olarak yavaştır; mümkünse native runner kullanın (amd64 için amd64 runner). Cache’i registry’ye yazmayı ve tekrar kullanmayı unutmayın.
- İmza doğrulanmıyor: Doğru public key kullandığınızdan ve imzanın ilgili etikete uygulandığından emin olun. CI ortamında key yönetimi için OIDC ile keyless imzalama da değerlendirilmelidir.

En İyi Uygulamalar

- Tag stratejisi: semver (+ latest), commit SHA ve platform bağımsız tek etiket kullanın.
- Reproducible build: Sabit bağımlılık versiyonları ve belirli builder sürümleri seçin.
- Güvenlik: İmza ve SBOM’u pipeline’ın ayrılmaz parçası haline getirin, hatalı doğrulamada deploy’u durdurun.
- Gözlemlenebilirlik: Build süreleri, cache isabet oranı ve başarısızlık nedenlerini CI’da raporlayın.

Sonuç

Docker Buildx, çok mimarili konteyner üretimini günlük pratiğin doğal bir parçası haline getiriyor. Doğru yapılandırmayla tek komutta amd64 ve arm64 için imaj üretip push edebilir, CI/CD’de otomatikleştirip, Cosign ile imzalayarak supply chain güvenliğini güçlendirebilirsiniz. Bu yaklaşım, hem geliştirici deneyimini iyileştirir hem de üretim ortamlarında taşınabilirlik ve güvenilirliği artırır.

Ollama ve ChromaDB ile RAG: Kendi Verinizle Yerel Yapay Zekâ Sohbet Botu Nasıl Kurulur?

RAG nedir ve neden önemli?

Retrieval-Augmented Generation (RAG), bir dil modelinin cevap üretmeden önce bir vektör veritabanından ilgili parçaları geri çağırdığı, bu sayede daha doğru ve kaynaklı yanıtlar ürettiği bir yaklaşımdır. Güncel kurumsal ihtiyaçlarda gizlilik, maliyet kontrolü ve özelleştirme kritik hale geldiği için RAG, özellikle şirket içi dokümanlar, bilgi tabanları ve politikalar üzerinde çalışan sohbet botları için en verimli yöntemlerden biri olarak öne çıkıyor.

Bu rehberde, tamamen yerel çalışan bir kurulumla Ollama (yerel LLM çalıştırma), ChromaDB (vektör veritabanı) ve Python kullanarak adım adım bir RAG sistemi kurulumu yapacağız. Amaç, Türkçe metinlerle yüksek doğrulukta, düşük gecikmeli ve veri gizliliği korunan bir sohbet deneyimi sunmak.

Gerekenler ve mimari

Bileşenler: Ollama (Llama 3 veya benzeri açık kaynak model), ChromaDB (kalıcı vektör deposu), bir gömme (embedding) modeli (örn. intfloat/multilingual-e5-base), Python 3.10+, LangChain veya minimal kendi kodunuz. İsteğe bağlı olarak PDF/Word dosyaları için pypdf veya docx desteği ekleyebilirsiniz.

Akış: Dokümanları parçalara ayır → Embedding ile vektörleştir → ChromaDB’de indeksle → Soru geldiğinde benzer parçaları getir → Model için talimat şablonuna (prompt) enjekte et → Yanıtı oluştur ve kaynakları göster.

Kurulum adımları

1) Ollama’yı kurun. Resmi site üzerinden işletim sisteminize uygun paketi indirin. Model indirmek için komut satırında şu adımı uygulayın:
ollama pull llama3
Ardından test amaçlı kısa bir deneme yapabilirsiniz:
ollama run llama3

2) Python ortamını hazırlayın. Ayrı bir sanal ortam tercih edin:
python -m venv .venv && source .venv/bin/activate (Windows için .venv\Scripts\activate)
pip install chromadb sentence-transformers langchain langchain-community pypdf

Veri hazırlığı: parçalama ve temizleme

İyi bir RAG’in temeli, doğru parça boyutları ve temiz veridir. Türkçe belgelerde 300–500 token’lık parçalar pratikte iyi sonuç verir. Parçaları ayırırken başlık bilgilerini ve içerik konusunu korumaya çalışın. Örneğin bir politika belgesinde bölüm başlığını her parçaya meta veri olarak ekleyin. Bu, hem geri çağırmayı hem de kaynakları kullanıcıya göstermeyi kolaylaştırır.

Temizlik aşamasında gereksiz boşlukları, tekrar eden sayfa altbilgilerini ve tablo görsellerinden gelen çöp metinleri temizleyin. PDF okuyucu olarak pypdf kullanabilir, Markdown veya HTML dokümanlarını doğrudan metne dönüştürebilirsiniz.

ChromaDB ile vektör indeksleme

Embedding için çok dilli ve Türkçe performansı yüksek bir model seçin. “intfloat/multilingual-e5-base”, hız/doğruluk dengesiyle güvenilir bir tercih. Basit bir akış şöyle olabilir: Belgeleri oku → Böl → Her parça için embedding hesapla → ChromaDB’ye “persist_directory” ile kalıcı olarak yaz. Bu sayede uygulama yeniden başladığında indeksi tekrar oluşturmadan kullanabilirsiniz.

Koleksiyonlarınızı konuya göre ayırın (örn. “insan_kaynaklari”, “urun_dokumantasyonu”). Meta veriye kaynak adı, sayfa numarası, bölüm ve tarih gibi alanlar eklemek, yanıtların izlenebilirliğini artırır.

Sorgulama: RAG adım adım

Kullanıcıdan gelen soruyu önce bir sorgu embedding’ine dönüştürün, ardından ChromaDB’den en ilgili 3–5 parçayı çekin. Bu parçaları modelinize şu yapıda verin: kısa bir talimat + kullanıcı sorusu + “bağlam” bölümü (geri çağrılan parçalar). Örnek şablon yaklaşımı: “Aşağıdaki bağlamdan faydalanarak soruya kısa ve kaynaklı bir yanıt ver. Bağlamda yoksa tahmin yürütme.”

Ollama tarafında llama3 modelini çağırırken sıcaklık (temperature) düşük (0.1–0.3) tutulduğunda halüsinasyon azalır. Yanıtın sonuna “Kaynaklar” başlığı ile geri çağrılan parçaların referanslarını eklemek, güven inşa eder ve SEO açısından “uzman” hissiyatı yaratır.

İyileştirme: yeniden sıralama ve çoklu sorgu

Bazı senaryolarda temel benzerlik araması yeterli olmaz. Açık kaynak yeniden sıralayıcılar (örn. bge-reranker-large) ile ilk 20 sonucu alıp en iyi 5’ini rerank ederek doğruluğu yükseltebilirsiniz. Ayrıca multi-query tekniği ile kullanıcı sorusunu farklı biçimlerde genişletip (eş anlamlılar, farklı bağlamlar) birleştirilmiş sonuçlar elde etmek de hatırlamayı artırır.

Soru ön-işleme katmanında yazım hatalarını düzeltmek, alan terimlerini sözlükten normalleştirmek ve tarih-sayı gibi varlıkları standart forma getirmek, özellikle kurumsal dokümanlarda fark yaratır. Halüsinasyonları azaltmak için “sadece bağlamdan yanıt ver, bağlam yoksa ‘yok’ de” gibi net kurallar koyun.

Performans, güvenlik ve üretime alma

CPU ile başlayıp gerekirse GPU’ya geçin. Düşük bellekli sistemlerde quantized (örneğin Q4_0) model varyantları iyi sonuç verir. ChromaDB tarafında kalıcı dizin SSD üzerinde olmalı ve düzenli olarak koleksiyon boyutu ile gecikmeyi izleyin. Top_k değerini 3–8 arasında test ederek doğruluk/performans dengesini bulun.

Üretim ortamında bir FastAPI uç noktası ile sorgulama zincirinizi sunabilirsiniz. Yanıtları ve kullanılan kaynakları log’layarak kalite ölçümü yapın. Kişisel veriler içeren dokümanlarda yerel çalışmanın avantajı büyüktür; ağ dışına veri çıkarmadan kurumsal uyumluluk hedeflerine yaklaşabilirsiniz.

Sonuç

Ollama + ChromaDB ile kurulan yerel RAG yığını, maliyeti düşük, gizliliği yüksek ve yönetilebilir bir yapay zekâ çözümü sunar. Doğru parça boyutu, iyi bir embedding modeli ve dikkatli şablonlama ile Türkçe içerikte dahi oldukça isabetli yanıtlar elde edebilirsiniz. Bu rehberi temel alarak önce küçük bir pilot oluşturun, ardından veri kapsamını ve değerlendirme metriklerini (doğruluk, geri çağırma, MRR) aşamalı olarak genişletin. Böylece güncel ve ileri seviye bir deneyimi, tamamen kendi verinizle kontrol ederek hayata geçirebilirsiniz.

HTTP/3 ve QUIC Etkinleştirme Rehberi: Nginx ve Cloudflare ile Daha Hızlı Web

Giriş

Web sitenizi hızlandırmanın en etkili yollarından biri, HTTP/3 ve QUIC protokolünü devreye almak. 2024 ve sonrasında modern tarayıcıların büyük bölümü HTTP/3’ü yerleşik destekliyor ve başta mobil kullanıcılar olmak üzere gecikmeye duyarlı senaryolarda ciddi kazanımlar sağlıyor. Bu rehberde, HTTP/3 (QUIC) nedir, neden önemlidir ve Cloudflare ile Nginx üzerinde nasıl etkinleştirilir adım adım anlatıyorum. Ayrıca doğru test ve ölçüm yöntemleriyle kurulumun gerçekten işe yarayıp yaramadığını nasıl doğrulayabileceğinizi paylaşıyorum.

HTTP/3 ve QUIC Nedir, Neden Önemli?

HTTP/3, Google’ın QUIC protokolü üzerine inşa edilen ve TCP yerine UDP kullanan modern bir HTTP sürümüdür. Paket kaybı durumunda daha hızlı toparlanma, bağlantı göçü (Wi‑Fi’dan hücresel ağa geçerken bağlantının kopmaması), başlık sıkıştırması (QPACK) ve 0‑RTT gibi özelliklerle özellikle mobil ve yüksek gecikme senaryolarında daha düşük TTFB ve daha tutarlı yükleme süreleri sağlar.

HTTP/3 devreye alındığında siteniz HTTP/2 ve HTTP/1.1’e geriye dönük uyumluluğu korur. Yani destekleyen tarayıcılar otomatik olarak h3 kullanırken, diğerleri mevcut protokollere düşer. Bu da canlıya geçişte riskleri minimize eder.

Önkoşullar ve Uyum

- Sunucu veya CDN tarafında TLS 1.3 etkin olmalı. HTTP/3, TLS 1.3 gerektirir.

- Güvenlik duvarınızda UDP 443 açık olmalı. QUIC, TCP yerine UDP üzerinde çalışır.

- Tarayıcılarınız güncel olmalı. Chrome, Edge, Safari ve Firefox’un güncel sürümleri HTTP/3’ü destekler.

Cloudflare Üzerinden HTTP/3’i Açma

1) Cloudflare Paneline girin ve ilgili alan adını seçin. SSL/TLS bölümünde modunuzu “Full (strict)” olacak şekilde ayarlayın. Bu, güvenli uçtan uca bağlantıyı sağlar.

2) “Network” sekmesine gidin ve “HTTP/3 (with QUIC)” seçeneğini aktif edin. Cloudflare kenarlarında Alt-Svc başlığı otomatik olarak eklenecek, tarayıcılar h3’e geçecektir.

3) Güvenlik duvarı kurallarınızın UDP 443 trafiğini engellemediğini doğrulayın. Bazı kurum ağlarında UDP kısıtlı olabilir; gerçek kullanıcıların deneyimi bu durumdan etkilenebilir.

4) Test: Chrome DevTools’u açın (F12), Network sekmesinde “Protocol” sütununu görünür yapın. Sayfanızı yenileyin; isteklerin “h3” olarak geldiğini görmelisiniz. Alternatif olarak curl ile “curl -I --http3 https://alanadiniz.com” komutunu deneyebilirsiniz.

Nginx ile (Origin) HTTP/3 Yayını

Cloudflare kullanmıyorsanız veya origin’den doğrudan HTTP/3 sunmak istiyorsanız Nginx’in HTTP/3 desteğini etkinleştirmeniz gerekir. Nginx 1.25+ ile QUIC/HTTP/3 desteği mevcuttur ancak uygun şekilde derlenmiş paket (BoringSSL/QuicTLS ile) kullanmanız veya dağıtımınızın hazır paketlerini tercih etmeniz gerekir. Alternatif olarak Caddy gibi H3’ü daha kolay etkinleştiren sunucular da tercih edilebilir.

Nginx tarafında örnek bir yaklaşım: 443’te UDP ve TCP dinleyin, TLS 1.3’ü zorunlu kılın ve tarayıcıları HTTP/3’e yönlendirmek için Alt-Svc başlığı ekleyin. Yapılandırma mantığı şu şekildedir: 1) “listen 443 quic reuseport;” satırıyla QUIC’i açın. 2) “listen 443 ssl http2;” satırıyla H2 geri dönüşünü sağlayın. 3) “ssl_protocols TLSv1.3;” ile TLS 1.3’ü zorunlu tutun. 4) “add_header Alt-Svc 'h3=":443"; ma=86400';” başlığıyla tarayıcıya H3 desteğini duyurun. 5) Geçerli bir “ssl_certificate” ve “ssl_certificate_key” tanımlayın.

Değişikliklerden sonra Nginx’i yeniden yükleyin ve curl ile “--http3” bayrağını kullanarak test edin. Ayrıca tarayıcı geliştirici araçlarında protokol sütununu kontrol ederek canlı doğrulama yapabilirsiniz.

Performans Ölçümü ve Doğrulama

- Laboratuvar testleri: WebPageTest üzerinde “Advanced Settings” kısmından “HTTP/3 allowed” seçeneği ile koşun, TTFB ve “First Byte Out” metriklerini karşılaştırın. Lighthouse ve Chrome User Timing ile de sayfa içi işaretleri gözlemleyin.

- Gerçek kullanıcı verisi (RUM): Eğer mümkünse tarayıcı API’lerinden (PerformanceNavigationTiming) TTFB ve “connection type” bilgilerini toplayın. Mobil ağlarda H3 farkı daha belirgin çıkar.

- Doğrulama araçları: https://http3check.net ve https://quic.rocks gibi siteler hızlı doğrulama sunar. Cloudflare kullanıyorsanız Analytics > Performance bölümünde HTTP/3 istek yüzdesini görebilirsiniz.

Yaygın Sorunlar ve Çözümler

- UDP 443 kapalı: Birçok kurum veya ISS, UDP’yi kısıtlayabilir. Sunucu ve ağ sınırlarınızda bu portun açık olduğundan emin olun.

- Eski TLS yapılandırması: HTTP/3 sadece TLS 1.3 ile çalışır. Orijin veya CDN tarafında TLS 1.2’ye zorlayan kurallar mevcutsa kaldırın.

- Alt-Svc gecikmesi: Tarayıcılar Alt-Svc keşfini önbelleğe alır. İlk ziyarette HTTP/2, sonraki ziyaretlerde HTTP/3 görebilirsiniz. Testleri birden çok yenilemeyle yapın.

- Orijin ve CDN çakışması: Hem CDN hem orijin H3 sunuyorsa, tünelleme ve başlıklar beklenmedik etkileşime girebilir. Genellikle CDN üzerinden H3 sunmak en basit ve tutarlı yaklaşımdır.

Sonuç

HTTP/3 ve QUIC, özellikle mobil ve yüksek gecikmeli ortamlarda sitenizin algılanan hızını artırır, paket kaybından daha az etkilenir ve bağlantı değişimlerinde kullanıcı deneyimini korur. Cloudflare gibi bir CDN ile etkinleştirmek yalnızca birkaç tıklama sürer; orijin üzerinde Nginx ile kurulum ise biraz daha teknik olsa da kalıcı bir kazanım sağlar. Kurulumu tamamladıktan sonra doğru ölçümlerle etkiyi doğrulayın; TTFB, ilk boyama ve etkileşime geçiş metriklerinde genellikle kayda değer iyileşmeler göreceksiniz.

WebGPU ile Tarayıcıda Makine Öğrenmesi: ONNX Runtime Web ile GPU Hızlandırmalı Görüntü Sınıflandırma

Giriş

WebGPU, tarayıcıda modern grafik ve hesaplama iş yüklerini donanıma yakın performansla çalıştırmaya imkan tanıyor. Bu makalede, ONNX Runtime Web kullanarak WebGPU üzerinde GPU hızlandırmalı bir görüntü sınıflandırma örneğini adım adım kuracağız. Amaç, ek bir sunucuya gerek kalmadan, tamamen istemci tarafında çalışan ve gerçek zamanlıya yakın tepki veren bir makine öğrenmesi deneyimi elde etmek.

Neden WebGPU ve ONNX Runtime Web?

WebGL veya WASM ile kıyaslandığında WebGPU, paralel iş yüklerini daha verimli planlayarak tensör işlemlerini hızlandırır. ONNX Runtime Web ise aynı model dosyasını hem WebGPU hem WASM üzerinde çalıştırabilen esnek bir yürütme altyapısı sunar. Bu sayede destekli cihazlarda GPU, diğerlerinde otomatik olarak CPU kullanılabilir; uygulama tek kod tabanıyla geniş bir cihaz yelpazesini kapsar.

Ön Koşullar ve Ortam

- Chrome 121+ veya Edge 121+ gibi WebGPU destekli bir tarayıcı kullanın. Firefox’ta Nightly sürümünde dom.webgpu.enabled bayrağıyla çalışır. Safari’de ise güncel sürümler kısmi destek verir. Uygulamayı güvenli kökenden (https veya localhost) barındırın.

- Node.js 18+ ve npm gereklidir. Örnek, vanilla JS ve Vite ile hazırlanacaktır.

Proje Kurulumu

1) Yeni bir proje oluşturun: npm create vite@latest webgpu-ml -- --template vanilla

2) Klasöre girin ve bağımlılıkları ekleyin: cd webgpu-ml && npm i onnxruntime-web

3) Basit bir dizin yapısı oluşturun: /public/model/mobilenetv3.onnx ve etiketler için /public/model/labels.json. ONNX modelini ONNX Model Zoo’dan veya dönüştürdüğünüz bir MobileNetV3 modelinden alabilirsiniz.

Temel Kod: Oturum, Ön İşleme, Çıkarım

Aşağıdaki kod, WebGPU destekli bir tarayıcıda modeli başlatır, bir görüntüyü 224x224’e ölçekler, normalleştirir, tensöre çevirir ve çıkarım yapar. Destek yoksa WASM’e otomatik düşer.

import * as ort from 'onnxruntime-web';
// 1) Oturum oluşturma (GPU + CPU yedekli)
const session = await ort.InferenceSession.create('/model/mobilenetv3.onnx', {
  executionProviders: ['webgpu', 'wasm'],
  graphOptimizationLevel: 'all'
});

async function loadImageToTensor(imgEl) {
  const size = 224;
  const canvas = document.createElement('canvas');
  canvas.width = size; canvas.height = size;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(imgEl, 0, 0, size, size);
  const { data } = ctx.getImageData(0, 0, size, size);
  const mean = [0.485, 0.456, 0.406];
  const std = [0.229, 0.224, 0.225];
  const chw = new Float32Array(1 * 3 * size * size);
  for (let i = 0; i < size * size; i++) {
    const r = data[i * 4] / 255, g = data[i * 4 + 1] / 255, b = data[i * 4 + 2] / 255;
    chw[i] = (r - mean[0]) / std[0];
    chw[i + size * size] = (g - mean[1]) / std[1];
    chw[i + 2 * size * size] = (b - mean[2]) / std[2];
  }
  return new ort.Tensor('float32', chw, [1, 3, size, size]);
}

async function classify(imgEl) {
  const input = await loadImageToTensor(imgEl);
  const feeds = { [session.inputNames[0]]: input };
  const outputMap = await session.run(feeds);
  const logits = outputMap[session.outputNames[0]].data;
  // Softmax ve top-k
  const exps = logits.map(x => Math.exp(x - Math.max(...logits)));
  const sum = exps.reduce((a, b) => a + b, 0);
  const probs = exps.map(e => e / sum);
  const topK = [...probs].map((p, i) => ({ i, p })).sort((a, b) => b.p - a.p).slice(0, 5);
  const labels = await fetch('/model/labels.json').then(r => r.json());
  return topK.map(({ i, p }) => ({ label: labels[i], prob: p }));
}

Performans İpuçları

- FP16 kullanımı: Bazı modelleri yarım hassasiyetle (Float16) çalıştırmak bellek ve bant genişliği kullanımını düşürerek hız kazandırır. Modeliniz FP16’ya dönüştürülmüşse WebGPU’da belirgin fark görebilirsiniz.

- Girdi boyutu: 224x224 yerine 192x192 gibi daha küçük boyutlar deneyerek gecikmeyi azaltın. Bu değişim doğruluk kaybı ile hız kazanımı arasında bir denge gerektirir.

- Ortak önbellek: Modeli uygulama yaşam döngüsü boyunca bir kez yükleyip aynı oturumu tekrar kullanın. Tekrarlı session.create maliyetlidir.

- Grafik optimizasyon seviyesi: graphOptimizationLevel: 'all' çoğu senaryoda iyi sonuç verir. Bazı modellerde extended veya basic de test edilmeli.

- Çalışma zamanında veri kopyalarını azaltın: Canvas’tan aldığınız ImageData yerine WebCodecs API ile VideoFrame kullanmak (destekliyse) dönüşümleri hızlandırabilir.

Uyumluluk ve Geriye Dönük Çalışma

WebGPU her cihazda aynı düzeyde mevcut olmayabilir. executionProviders: ['webgpu', 'wasm'] sıralaması sayesinde GPU destekli tarayıcılarda hızlanır, diğerlerinde WASM’e düşer. Bu yaklaşım üretim ortamında kesintisiz deneyim sağlar. Ayrıca HTTPS ve güvenli bağlam zorunluluğuna dikkat edin; yerel geliştirmede localhost istisnadır.

Hata Ayıklama

- Model giriş/çıkış adları: session.inputNames ve session.outputNames ile doğrulayın; ONNX ihracında katman adları değişmiş olabilir.

- Bellek taşmaları: Büyük modeller mobil cihazlarda bellek sınırlarına takılabilir. Modeli quantize ederek (INT8/UINT8) veya daha hafif mimarilere geçerek çözebilirsiniz.

- WebGPU hataları: Tarayıcı konsolunda validation error mesajlarını kontrol edin. Sürücü veya adaptör sınırlamaları için navigator.gpu.requestAdapter() ile dönen limitleri inceleyin.

Gerçek Hayat Senaryoları

- Ürün arama: Kullanıcı yüklediği fotoğrafla eşleşen kategoriye gerçek zamanlı yönlendirme.

- İçerik güvenliği: Tarayıcıda ön filtreleme yaparak sunucu maliyetini ve gecikmeyi azaltma.

- Eğitim: Etkileşimli ML demoları ve ders materyalleri, laboratuvar kurulumları olmadan, yalnızca bir URL ile erişilebilir.

Sonuç

WebGPU ve ONNX Runtime Web birlikteliği, tarayıcıda makine öğrenmesi için yeni bir performans eşiği oluşturuyor. Doğru model seçimi, hafif ön/son işleme ve dikkatli optimizasyonlarla, mobil dahi pek çok cihazda tatmin edici hızlara ulaşmak mümkün. Bu temel iskeleti kullanarak; nesne tespiti, metinden görüntü üretimi veya konuşma tanıma gibi daha karmaşık senaryolara ilerleyebilirsiniz. Üstelik tümü, kullanıcı verisini cihazdan çıkarmadan, gizlilik dostu bir şekilde.

GitHub Actions ile Docker Buildx Kullanarak Çok Mimarili İmaj (amd64 + arm64) Yayınlama Rehberi

Kapsayıcı tabanlı dağıtımların hızla arttığı günümüzde, tek bir mimariye bağlı kalmak ciddi bir kısıt olabilir. Özellikle bulut sağlayıcılar ve edge cihazları (Raspberry Pi gibi ARM tabanlı sistemler) söz konusu olduğunda, amd64 ve arm64 için tek bir sürüm hattından imaj üretebilmek büyük avantaj sağlar. Bu yazıda, GitHub Actions ve Docker Buildx kullanarak çok mimarili (multi-arch) imajı nasıl inşa edip hem Docker Hub hem de GHCR’ye nasıl yayınlayacağınızı adım adım anlatıyorum.

Neden Buildx? Buildx, BuildKit’i temel alır ve çoklu platform inşa, gelişmiş önbellekleme, yerleşik SBOM/provenance gibi özellikleri etkinleştirir. Bunun anlamı: Tek bir pipeline ile linux/amd64 ve linux/arm64 hedeflerini derleyebilir, tek bir manifest altında birleştirip push edebilirsiniz.

Önkoşullar ve depo ayarları

- GitHub repository’nizde Actions etkin olmalı.
- Docker Hub’a push edecekseniz bir erişim token’ı oluşturun ve GitHub’da Settings > Secrets and variables > Actions altında DOCKERHUB_USERNAME ve DOCKERHUB_TOKEN olarak ekleyin.
- GHCR (GitHub Container Registry) kullanacaksanız, secrets.GITHUB_TOKEN çoğu durumda yeterlidir. Özel bir PAT kullanıyorsanız gerekli scope’lar: write:packages ve read:packages.

Workflow mantığı

Pipeline’da sırasıyla QEMU etkinleştirmesi (arm64 emülasyonu için), Buildx builder kurulumu, metadata/etiket üretimi, cache ayarı, çok mimarili build ve push adımları yer alacak. Ek olarak SBOM ve provenance (inşa kanıtı) bilgilerini de ekleyebiliriz.

Örnek workflow (/.github/workflows/release.yml)

name: release-multi-arch
on:
push:
tags:
- 'v*.*.*'
jobs:
build-and-push:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
id-token: write
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up QEMU
uses: docker/setup-qemu-action@v3
with:
platforms: arm64
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Docker metadata
id: meta
uses: docker/metadata-action@v5
with:
images: |
ghcr.io/<kullanici>/<imaj-adi>
<kullanici>/<imaj-adi>
tags: |
type=semver,pattern={{version}}
type=semver,pattern={{major}}.{{minor}}
type=raw,value=latest
- name: Login to Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Login to GHCR
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push multi-arch
uses: docker/build-push-action@v6
with:
context: .
file: ./Dockerfile
platforms: linux/amd64,linux/arm64
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha
cache-to: type=gha,mode=max
provenance: true
sbom: true

Önemli noktalar ve iyi uygulamalar

• QEMU: Yerel runner’ınız x86 ise, arm64 imajı için QEMU emülasyonu gerekir. docker/setup-qemu-action bunu sizin yerinize yapar. Performans, yerel ARM runner’a göre daha düşük olabilir; kritik projelerde self-hosted ARM runner düşünebilirsiniz.

• Metadata ve etiketleme: docker/metadata-action; semver uyumlu etiketleri (v1.2.3, 1.2, latest) otomatik üretir. Böylece kullanıcılarınız ister sürüm sabitlemesi, ister “latest” ile hızlı çekim yapabilir.

• Cache: GHA (GitHub Actions) cache’i ile katmanlar arası hız kazanırsınız. Dockerfile’ınızı cache verimini maksimize edecek şekilde düzenleyin: bağımlılık kurulumunu, sık değişen dosyalardan önce konumlandırmayın. Örneğin, package.json kopyası ve “npm ci” adımları, uygulama kodlarından önce gelmeli.

• Güvenlik: provenance: true ve sbom: true ile tedarik zinciri bilgilerini imaja iliştirebilirsiniz. Cosign ile imzalama eklemek isterseniz OIDC tabanlı keyless imzayı tercih edin; sigstore/cosign-installer ve “cosign sign” adımıyla workflow’u genişletebilirsiniz.

• Çok kayıtlı push: Yukarıdaki örnek aynı anda hem GHCR hem Docker Hub’a push eder. Kimlik bilgileri doğru ise manifest listesi, her iki registry’de de aynı etiketlerle yer alır.

Sorun giderme

• “no match for platform in manifest” hatası: Çekmeye çalıştığınız hedef platform için imaj manifest’i yoktur. buildx ile push sonrası, “docker buildx imagetools inspect <image:tag>” çıktısında amd64 ve arm64 görünmelidir.

• QEMU ile yavaş derleme: Bazı bağımlılıklar (ör. kriptografik kütüphaneler) arm64 derlemede ciddi süre alabilir. Mümkünse çok aşamalı (multi-stage) Dockerfile kullanın ve ağır kısımları önbelleğe alın. Alternatif olarak self-hosted arm64 runner veya BuildKit’in uzak builder modlarını düşünebilirsiniz.

• Önbellek isabeti düşükse: “cache-from: type=gha” etkin olmasına rağmen isabet zayıfsa, Dockerfile adımlarının sıralamasını gözden geçirin. “COPY . .” gibi geniş kapsamlı kopyalar, küçük değişikliklerde bile önbelleği bozabilir. Yalnızca gerekli dosyaları kopyalayın.

• Docker Hub hız limitleri: Anonim veya düşük planlı hesaplarda rate limit’e takılabilirsiniz. Login adımı şarttır. Gerekiyorsa workflow’u yeniden deneme stratejisiyle (retry) sarmalayın.

Performans ve maliyet ipuçları

• Katman sayısını azaltın, gereksiz paketleri temizleyin (apk/apt ile “--no-cache” ve “rm -rf /var/lib/apt/lists/*”).
• Dil ekosistemlerinde üretim odaklı taban imajları (distroless, alpine, slim) tercih edin.
• Çok aşamalı derlemede builder imajını üretim katmanından ayırın; sadece çalışma zamanı için gereken dosyaları kopyalayın.

Sonuç

GitHub Actions ve Docker Buildx ikilisi, tek bir pipeline üzerinden hem amd64 hem de arm64 imajlarını üreterek modern dağıtım ihtiyaçlarınıza güçlü bir yanıt sunar. Doğru önbellekleme, tutarlı etiketleme ve güvenlik metadatalarıyla (SBOM, provenance) birlikte kullanıldığında, CI/CD hattınız hızlı, izlenebilir ve güvenli çalışır. Bu rehberi temel alarak projenizi kolayca ölçeklendirebilir, bulut ve edge senaryolarında tek bir imaj adını kullanarak tüm platformlara rahatlıkla dağıtım yapabilirsiniz.

Kubernetes Gateway API ile Ingress’ten Geçiş: Adım Adım Rehber ve En İyi Uygulamalar

Özet: Kubernetes’te trafiği yönetmek için yıllardır varsayılan seçenek olan Ingress, karmaşık senaryolarda yetersiz kalabiliyor. Gateway API, modern trafik yönetimi için daha esnek bir model sunuyor: roller ayrımı, zengin yönlendirme kuralları, taşınabilirlik ve genişletilebilirlik. Bu yazıda, Ingress’ten Gateway API’ye geçişi adım adım anlatıyor, örnek tanımlar ve en iyi uygulamalarla destekliyoruz.

Gateway API Nedir ve Neden Geçmeliyim?

Gateway API, Kubernetes’in ağ katmanında kaynak türlerini genişleterek standartlaştırılmış, sağlayıcıdan bağımsız bir trafik yönetim modeli sunar. Başlıca avantajları:

- Rollerin ayrımı: GatewayClass, Gateway ve HTTPRoute/GRPCRoute/TCPRoute nesneleriyle altyapı ve uygulama ekipleri sorumlulukları net şekilde paylaşır.
- Zengin ifade gücü: Header tabanlı yönlendirme, ağırlıklı trafik bölümü, mTLS, yeniden deneme/politikalar için geniş kapsam.
- Taşınabilirlik ve uyumluluk: Birçok sağlayıcı (NGINX, Kong, Istio, Cilium vb.) aynı API’yi destekler.
- Geleceğe uyum: Topluluk tarafından aktif geliştirilen ve conformance testleriyle doğrulanan bir standart.

Ön Koşullar ve Kurulum

Geçişe başlamadan önce Kubernetes 1.26+ ve seçtiğiniz bir Gateway sağlayıcısı (ör. NGINX, Kong, Istio) kurulu olmalı. CRD’leri etkinleştirmek için aşağıdaki komutu uygulayabilirsiniz (sürüm numarasını güncel olanla değiştirin):

kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0"

Sağlayıcınıza bağlı olarak bir GatewayClass gelir veya siz tanımlarsınız. Sağlayıcı dökümantasyonunda “GatewayClass name” önemlidir; az sonra Gateway nesnesinde bu ismi kullanacağız.

Ingress’ten Gateway API’ye Geçiş: Adım Adım

1) Mevcut Ingress haritasını çıkarın: Kümelerde hangi alan adları, yollar (path), TLS sertifikaları, backend servisleri ve ağırlıklandırmalar kullanılıyor? Bunları listeleyin. Bu, HTTPRoute’lara dönüşümde yol gösterici olacaktır.

2) GatewayClass ve Gateway tanımlayın: Altyapı ekibi bir GatewayClass sağlar. Ardından trafiğin dinleneceği Gateway nesnesi oluşturulur. Örnek bir Gateway mantığı şöyle olabilir:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge-gw
spec:
  gatewayClassName: nginx
  listeners:
  - name: web
    port: 80
    protocol: HTTP
  - name: web-tls
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: site-cert

3) HTTPRoute ile yönlendirme oluşturun: Ingress’teki host ve path kurallarını HTTPRoute’a taşıyın. Örnek bir kurgu:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
spec:
  parentRefs:
  - name: edge-gw
  hostnames:
  - shop.ornek.com
  rules:
  - matches:
    - path:
      type: PathPrefix
      value: /api
    backendRefs:
    - name: shop-api
      port: 8080

4) Trafik geçişini risksiz yönetin: Canlı geçişte aynı hostname altında iki servis arasında ağırlıklandırma kullanabilirsiniz. Örnek: eski servis %90, yeni servis %10.

- Ağırlıklandırma: backendRefs altında weight alanını kullanın (ör. weight: 90 ve weight: 10).
- Header tabanlı yönlendirme: Sadece belirli kullanıcı grubuna test için X-Canary: true başlığıyla yeni sürümü gösterin.
- Trafik yansıtma (mirror/tee) özelliği sağlayıcıya göre değişir; destekleniyorsa üretim verisini gölgeleme için kullanın.

5) TLS ve güvenlik: Sertifikaları Secret üzerinden terminate edin. Gateway seviyesinde mTLS veya HTTPRoute bazlı politika tanımlarıyla hassas uç noktaları koruyun. Bazı sağlayıcılar ReferenceGrant ile namespace’ler arası güvenli referanslamayı şart koşar.

6) Gözlemlenebilirlik ve hata ayıklama: Gateway ve Route’ların status alanlarını inceleyin. Olay kayıtları (kubectl describe), metrikler (Prometheus), loglar ve sağlayıcı panellerini birlikte kullanın. Uyuşmayan host veya listener isimleri en sık karşılaşılan kaynaklardır.

Ingress ve Gateway API Arasındaki Farkların Özeti

- Ingress tek bir kaynakla çok şeyi yapmaya çalışır; gelişmiş senaryolarda anotasyon bağımlılığı artar. Gateway API ise modülerdir: Gateway (giriş noktası), Route (uygulama yönlendirmesi) ve Policy (davranış) ayrıdır.
- Birden fazla ekip aynı Gateway’i paylaşabilir; uygulama ekipleri sadece kendi HTTPRoute’larını yönetir.
- Trafik türleri (HTTP, TCP, gRPC) için ayrı Route kaynaklarıyla net ayrımlar sağlanır.

En İyi Uygulamalar

- Adım adım geçiş: Tüm Ingress’leri tek seferde taşımak yerine domain veya mikroservis bazlı fazlara bölün.
- İsimlendirme stratejisi: Gateway, listener ve host adlarını tutarlı belirleyin. Ortak bir etiketleme şeması kullanın (ör. environment, team, cost-center).
- Politikaları merkezileştirin: Zorunlu güvenlik ve hız sınırlama (rate limit) kurallarını gateway seviyesinde; uygulama bazlı esnemeleri route seviyesinde yönetin.
- Conformance kontrolü: Sağlayıcınızın Gateway API uyumluluk seviyesi ve desteklediği ek özellikleri önceden doğrulayın.
- Geri dönüş planı: Canary ve header tabanlı yönlendirmeyle geri alma senaryolarını pratik edin.

Yaygın Hatalar ve Çözümler

- 404/Hostname uyuşmazlığı: HTTPRoute içindeki hostnames listesi, gelen isteğin SNI/Host başlığıyla birebir eşleşmelidir.
- Listener uyuşmazlığı: Route’un parentRefs alanındaki isim, ilgili Gateway listener’ı ile aynı port/protokole uygun olmalı.
- Namespace erişimi: Route’un referans verdiği Service farklı namespace’teyse ReferenceGrant gerektirebilir.
- TLS Secret formatı: tls.crt ve tls.key anahtarları doğru yerleştirilmelidir; yanlış format sertifika yüklenmesini engeller.

Sonuç

Gateway API, Kubernetes’te trafik yönetimini modernleştiriyor. İnce ayarlı yönlendirme, ekipler arası sınırların netleşmesi ve sağlayıcı bağımsızlığı sayesinde büyük ve regüle ortamlarda dahi güvenle ölçeklenebiliyor. Mevcut Ingress’lerinizi envanterleyip küçük adımlarla HTTPRoute’lara taşıyarak, TLS ve politikaları sistematik şekilde uyguladığınızda kesintisiz bir geçiş mümkün. Uzun vadede sade operasyon, daha öngörülebilir davranış ve standart bir ağ katmanı kazanırsınız.