Kubernetes'te dışarıya trafik açma: Ingress ve Gateway API uygulaması

Kümedeki uygulamayı dışarıya açmanın yolları

Kubernetes'te bir uygulama pod'larda çalışır ve onlara kararlı bir adres veren nesne Service'tir. Service varsayılan olarak yalnızca küme içinden erişilebilir. Dışarıya açmanın temel yolları vardır: Service türünü NodePort yapmak, LoadBalancer yapmak ya da HTTP ve HTTPS trafiği için Ingress veya Gateway API kullanmak.

NodePort her düğümde bir port açar; deneme için pratiktir ama üretimde yönetimi zordur. LoadBalancer, bulut sağlayıcının yük dengeleyicisini Service başına ayırır; çok sayıda uygulamada hem maliyet hem yönetim yükü büyür. Ingress ve Gateway API ise tek bir giriş noktası üzerinden ana makine adı (host) ve yol (path) kurallarına göre birçok Service'e yönlendirme yapar. Bu sayfa o yöntemin, yani HTTP katmanında trafik yönlendirmenin adımlarını ele alır.

Ingress nedir ve çalışması için neye ihtiyaç var?

Ingress, kümeye gelen HTTP ve HTTPS isteklerinin hangi Service'e gideceğini tarif eden bir Kubernetes nesnesidir. Kural olarak şunu söyler: şu ana makine adına ve şu yola gelen istek, şu Service'in şu portuna gitsin.

Kritik nokta: yalnızca Ingress nesnesi oluşturmak hiçbir şey yapmaz. Resmî belgede belirtildiği gibi, Ingress'i hayata geçiren bir Ingress controller'a ihtiyaç vardır. Controller, kümede çalışan ve Ingress nesnelerini izleyip gerçek yönlendirmeyi yapılandıran bir bileşendir. Piyasada farklı controller'lar bulunur ve davranışları birbirinden küçük farklarla ayrılır; seçtiğiniz controller'ın belgesini okumak gerekir.

Bir diğer önemli bilgi: Ingress API'si kararlıdır, kaldırılması planlanmıyor, ama Kubernetes projesi artık geliştirilmediğini ve yeni işler için Gateway kullanımını önerdiğini belirtir. Mevcut kümeler Ingress ile çalışmaya devam eder; yeni tasarımlarda ise Gateway API'yi tartmak gerekir.

Adım adım Ingress yapılandırması

Basit bir yapılandırma şu adımlarla ilerler.

Birinci adım: Ingress controller kurulu ve çalışıyor olmalı. Kümede bir IngressClass tanımlıdır ve controller bu sınıfı sahiplenir. Hangi sınıfların bulunduğunu kubectl get ingressclass komutuyla görebilirsiniz.

İkinci adım: Uygulamanız için bir Service oluşturun (ClusterIP türü yeterlidir) ve pod'ların hazır olduğundan emin olun.

Üçüncü adım: Ingress nesnesini yazın. Aşağıdaki örnek kurguseldir; adlar ve ana makine adı size göre değişir:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-giris spec: ingressClassName: <sınıf-adı> rules: - host: uygulama.ornek.com http: paths: - path: /api pathType: Prefix backend: service: name: api port: name: http - path: / pathType: Prefix backend: service: name: web port: name: http

Bu kural, uygulama.ornek.com adresinde /api ile başlayan yolu api Service'ine, kalan her şeyi web Service'ine gönderir. ingressClassName alanı hangi controller'ın bu nesneyi işleyeceğini söyler; belge, bu alan boşsa varsayılan bir sınıf tanımlı olması gerektiğini belirtir.

Son adım: kubectl get ingress ve kubectl describe ingress ile durumu doğrulayın; controller'ın atadığı adresi DNS'te ana makine adına yönlendirin.

Yol eşleşmesi, TLS ve sık takılınan noktalar

pathType alanı yolun nasıl eşleşeceğini belirler. Exact değeri yolun birebir aynı olmasını ister; Prefix değeri yolu eğik çizgiyle bölünmüş öneke göre eşler; ImplementationSpecific ise eşleşmeyi controller'a bırakır. Hangisini seçtiğinize dikkat edin: aynı yol için Exact ve Prefix kuralları birlikte varsa hangisinin önce çalıştığı, controller'ın belgesinden öğrenilmelidir.

TLS için Ingress içinde tls bölümüne ana makine adı ve sertifikayı taşıyan bir Secret'in adı yazılır. Sertifikayı elle yönetebilir ya da bir sertifika otomasyon aracına bırakabilirsiniz; otomasyon yolu yenileme yükünü ortadan kaldırır. Sertifika yönetimi ayrı bir konu olduğundan, uygulamaya almadan önce ortamınızın sertifika sürecini netleştirin.

Şu noktalar sık hata kaynağıdır: • Ingress oluştu ama adres atanmadı: Controller kurulu değil ya da ingressClassName hatalı. • Yönlendirme çalışıyor ama uygulama yanıt vermiyor: Service'in seçicisi pod etiketleriyle eşleşmiyor ya da pod'lar hazır değil, Service'in uç noktası boş. • Alt yolda yayınlanan uygulamalar bozuluyor: Uygulama kök yolda çalışmayı bekliyor, yol yeniden yazma gerekiyor ve bu controller'a özgü bir ayardır. • Her controller farklı davranıyor: Aynı nesne farklı controller'da farklı sonuç verebilir; ek davranışlar çoğunlukla annotation'larla ayarlanır ve taşınabilir değildir. • HTTP dışındaki trafik: Ingress yalnızca HTTP ve HTTPS kurallarını destekler; diğer protokoller için NodePort ya da LoadBalancer türü Service gerekir.

Gateway API: rol ayrımıyla yeni model

Gateway API, Ingress'in sınırlarını aşmak için geliştirilen, kümeye eklenen özel kaynaklar ailesidir. Kubernetes belgesi tasarım hedeflerini dışa dönük, taşınabilir, genişletilebilir ve rol odaklı olarak sıralar. Başlıca kaynaklar şunlardır:

• GatewayClass: Ortak yapılandırmaya sahip bir gateway kümesini ve onu yöneten controller'ı tanımlar.
• Gateway: Trafiği karşılayan altyapının bir örneğidir, örneğin bir bulut yük dengeleyicisi ya da küme içi proxy; dinleyicileri (protokol, port, ana makine adı) tanımlar.
• HTTPRoute: Bir Gateway dinleyicisinden gelen HTTP trafiğinin hangi arka uçlara gideceğini belirler.
• GRPCRoute: Aynı fikrin gRPC trafiği için olan karşılığıdır.

Bir HTTPRoute örneği:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: uygulama-rotasi spec: parentRefs: - name: ortak-gateway hostnames: - "uygulama.ornek.com" rules: - matches: - path: type: PathPrefix value: /api backendRefs: - name: api port: <servis-portu>

Rol ayrımı pratik bir fark yaratır: altyapı sağlayıcı GatewayClass'ı, küme operatörü Gateway'i, uygulama geliştiricisi kendi ad alanındaki rotaları yönetebilir. Varsayılan olarak bir Gateway yalnızca kendi ad alanındaki rotaları kabul eder; başka ad alanlarından rota almak için allowedRoutes ayarı gerekir. Ingress'te annotation'larla yapılan başlık eşleştirme ve trafik ağırlıklandırma gibi özellikler, Gateway API'de standart alanlar olarak bulunur.

Ingress mi Gateway API mi? Karar ve geçiş notları

Karar için pratik bir çerçeve: mevcut bir kümede basit host ve yol kuralları çalışıyorsa Ingress'i sürdürmenin acil bir sebebi yoktur. Birden çok ekibin aynı giriş noktasını paylaştığı, başlık tabanlı yönlendirme ya da trafik bölme gibi gelişmiş ihtiyaçların olduğu ve annotation karmaşasından kaçınmak istediğiniz kümelerde Gateway API daha doğru bir temeldir. Yeni kurulan platformlarda ise projenin yönü Gateway'i gösterir.

Geçişte şu adımlar işe yarar: önce mevcut Ingress nesnelerinin envanterini çıkarın ve hangi annotation'lara dayandıklarını kaydedin. Seçtiğiniz controller'ın Gateway API desteğini ve hangi özellikleri karşıladığını belgesinden doğrulayın. Ardından test ortamında paralel bir Gateway kurup trafiği aşama aşama taşıyın; eski Ingress'i hemen silmeyin. DNS geçişini son adım yapın ve geri dönüş planınızı hazır tutun.

Hangi yolu seçerseniz seçin, controller sürümü, desteklenen özellikler ve güvenlik güncellemeleri sürekli takip edilmesi gereken işletme konularıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Giriş trafiği yönetimi, platform ve DevOps ekiplerinin düzenli uğraştığı bir konudur. Mindset kataloğundaki "Kubernetes Gateway API ve Ingress Yönetimi" programı doğrudan bu konuya odaklanır: kümeye giren trafiğin mimarisi, Ingress controller seçimi ve kurulumu, Gateway API kaynak modeli, TLS ve güvenlik, gelişmiş trafik desenleri ile geçiş planlaması modülleri vardır. Mevcut Ingress yapısını Gateway API'ye taşıyacak ekipler için uygundur.

"Kubernetes ile Orkestrasyon" programı ise iş yükleri, servis ve ağ yönetimi gibi temel katmanları anlatır; giriş trafiğine geçmeden önce Service ve iş yükü mantığını oturtmak isteyen mühendisler için başlangıç noktasıdır.