Kong API gateway nasıl kurulur ve işletilir: servisten eklentiye adım adım

Kong bir isteği nasıl işler?

API gateway, istemcilerle arka uç servisler arasına oturan tek giriş noktasıdır. Kong'da bir istek şu yolu izler: istemci gateway'e gelir, Kong isteği tanımlı kurallarla eşleştirir, eklentiler (kimlik doğrulama, hız sınırı, dönüşüm) sırayla çalışır ve sonunda istek arka uçtaki servise iletilir; yanıt da aynı yoldan geri döner.

Bu akışı temsil eden temel varlıklar Kong belgesinde şöyle tanımlanır. Gateway Service, arka uç servisi temsil eder ve Kong ile o servis arasındaki bağlantı bilgisini tutar. Route, gelen istekleri tanımlı kurallara göre eşleştirip belirli bir servise yönlendirir. Upstream ise bir servisin tek bir adres yerine gelişmiş trafik yönetimi gerektirdiği durumlarda devreye girer. Belgenin önerdiği genel yaklaşım, her arka uç servis için bir Gateway Service tanımlamaktır. Eklentiler ise bu varlıklara ya da bütün gateway'e bağlanan, istek yaşam döngüsüne müdahale eden modüllerdir.

Kurulum öncesi kararlar

Kurulumdan önce şu soruları yanıtlayın.

İlk soru, yapılandırma nerede tutulacak? Kong, yapılandırmayı bir veri tabanında tutabilir (yönetim API'siyle değiştirilir) ya da veri tabanı olmadan, deklaratif bir dosyadan okuyabilir. Dosya tabanlı kurulum, yapılandırmayı sürüm kontrolüne almayı kolaylaştırır; veri tabanlı kurulum ise çalışma zamanında dinamik değişiklik için esneklik sağlar.

Sonraki soru, nerede çalışacak? Konteyner ile yerelde denemek kolaydır; üretimde ise genellikle Kubernetes üzerinde, birden çok kopya olarak çalıştırılır. Kopyaların arkasında bir yük dengeleyici bulunur.

Son soru, yönetim yüzeyi kime açık? Yönetim API'si her şeyi değiştirebilir; bu yüzden asla genel ağa açılmamalı, yalnızca iç ağdan ve kimlik doğrulamayla erişilebilir olmalıdır. İstemci trafiğini karşılayan proxy portu ile yönetim portu ayrı ağ kurallarına sahip olmalıdır.

İlk servis ve route'u tanımlamak

Yönetim API'si ile servis oluşturmak, Kong belgesindeki örnek biçiminde şöyledir:

curl -i -X POST http://localhost:YONETIM_PORTU/services/ \ --header "Content-Type: application/json" \ --data '{"name": "order-service", "url": "http://orders.internal:PORT"}'

Ardından bu servise bağlı bir route eklenir; route, hangi isteklerin bu servise gideceğini yol, alan adı ya da metot gibi koşullarla belirler. Örneğin /orders yoluyla başlayan istekler sipariş servisine yönlendirilir. Route oluştuktan sonra gateway'in proxy portuna bu yolla bir istek atarak arka uçtan yanıt aldığınızı doğrulayın.

Yönetim API'si dışında deklaratif yaklaşım için decK aracı kullanılır: YAML dosyasında servisleri, route'ları ve eklentileri tanımlarsınız. Dosya, Kong belgesindeki örnekte olduğu gibi bir servis adı ve url alanıyla başlar. Aracı dosyayı gateway'e uygulayacak, mevcut durumla farkı gösterecek şekilde çalıştırırsınız. Bu yöntemin gücü, yapılandırmanın kod incelemesinden geçmesi ve geri alınabilir olmasıdır.

Eklentilerle kimlik doğrulama ve trafik yönetimi

Gateway'in asıl değeri, ortak işleri her servise kopyalamak yerine tek yerde çözmesidir. Eklentileri şu gruplara ayırabilirsiniz:

• Kimlik doğrulama ve yetkilendirme: anahtar tabanlı, belirteç tabanlı ya da dış kimlik sağlayıcılı doğrulama eklentileri. Eklentiyi bir servise, route'a ya da tüm gateway'e uygulayabilirsiniz. Kimliği doğrulanan istemciyi temsil etmek için Consumer kavramı kullanılır ve kısıtlar tüketici bazında verilebilir.
• Trafik yönetimi: hız sınırlama, istek boyutu sınırı, önbellekleme ve yeniden deneme gibi koruyucu eklentiler. Hız sınırı için policy olarak local, cluster ya da redis seçilebilir.
• Dönüşüm ve gözlemlenebilirlik: başlık ekleme ya da silme, istek ve yanıt dönüşümü, günlük ve metrik gönderimi.

Eklenti uygularken kapsamı iyi seçin: bütün gateway'e uygulanan bir eklenti her isteğe maliyet ekler. Önemli bir ilke, kimlik doğrulamayı gateway'de yapsanız bile arka uç servislerin kendi yetki denetimini sürdürmesidir; gateway atlanabilir ya da yanlış yapılandırılabilir.

Kubernetes üzerinde işletmek

Kubernetes ortamında Kong'u kümenin giriş katmanı olarak kullanmak yaygındır. Bu durumda yönlendirme kuralları, Kubernetes kaynakları üzerinden tanımlanır ve denetleyici bunları gateway yapılandırmasına çevirir. Böylece uygulama ekipleri kendi servislerinin yönlendirmesini, servisi dağıttıkları yerde tanımlar; platform ekibi ise gateway'in kendisini işletir.

İşletimde şu noktalara bakın: gateway kopyaları yatay ölçeklenebilmeli; yapılandırma değişikliği kesintisiz uygulanmalı; sağlık kontrolleri doğru ayarlanmalı; eklenti sürümleri kontrollü güncellenmeli. Arka uç servis adresleri değişiyorsa (pod'lar yer değiştiriyor) upstream ve sağlık denetimi ile ölü hedeflere trafik gitmesini engelleyin.

Dağıtım sırasında yeni sürümü küçük bir trafik payıyla denemek mümkündür: ağırlıklı yönlendirme ile eski ve yeni sürüm yan yana çalışır, hata oranı izlenir ve sorun yoksa pay artırılır.

Gözlemlenebilirlik ve sorun giderme

Gateway tüm trafiğin geçtiği nokta olduğu için izleme açısından en değerli yerlerden biridir. Ölçülmesi gerekenler: servis ve route bazında istek sayısı, hata oranları, yanıt süresi ve gateway'in kendi eklediği gecikme. Bu metrikleri bir izleme sistemine gönderin ve servis bazlı panolar kurun.

Sorun giderme akışı genellikle şu sırayla ilerler: önce isteğin gateway'e ulaşıp ulaşmadığına bakın, sonra route eşleşmesini kontrol edin (yanlış yol ya da alan adı eşleşmesi sık görülür), ardından eklentilerin isteği reddedip reddetmediğine bakın (kimlik doğrulama, hız sınırı), son olarak arka uç servisin yanıtını inceleyin. Gateway'in dönen hata kodu bunların hangisi olduğunu çoğu zaman ayırt eder: gateway kaynaklı reddetme ile arka uçtan gelen hata farklı görünür.

Her istek için bir izleme kimliği başlığı üretip arka uçlara iletmek, uçtan uca izlemeyi mümkün kılar.

Sık yapılan hatalar

• Yönetim yüzeyini dışarıya açmak. Tüm yapılandırma tek bir istekle değiştirilebilir.
• Yapılandırmayı elle ve kayıtsız değiştirmek. Hangi ortamın neden farklı davrandığı bilinmez; deklaratif dosya ve sürüm kontrolü kullanın.
• Gateway'i iş mantığı taşıyan bir yere çevirmek. Karmaşık dönüşümler ve kurallar gateway'de birikirse tek hata noktası ve bakım yükü olur.
• Tek kopya çalıştırmak. Gateway'in kendisi tek hata noktasıdır.
• Eklentileri kapsam düşünmeden her yere uygulamak.
• Sağlık denetimi tanımlamamak. Ölü arka uçlara trafik gönderilir.
• Arka uç servisleri tamamen gateway'in kimlik doğrulamasına güvenerek korumasız bırakmak.

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

Kong ile API Gateway İşletimi programı bu sayfanın konusunu uçtan uca izliyor: mimari ve kurulum, service, route ve upstream yapılandırması, kimlik doğrulama ve yetkilendirme, trafik yönetimi eklentileri, Kubernetes entegrasyonu ve otomasyon, gözlemlenebilirlik ve işletim. Program, API'lerin ortak giriş noktasını işletecek platform, DevOps ve altyapı ekipleri ile gateway'e geçmeyi planlayan backend ekipleri için uygun görünüyor.

Kurumsal bir ekip için bu çalışma, hangi çapraz kesen işlerin (kimlik doğrulama, sınırlama, günlükleme) gateway'e taşınacağını ve hangilerinin servislerde kalacağını birlikte karara bağlamak için bir fırsattır.