Kong, Nginx/OpenResty tabanlı bir API gateway‘dir. Mikroservis sayısı arttığında istemci trafiğini tek tek backend’lere dağıtmak yerine kimlik, kota, yönlendirme ve gözlemlenebilirlik politikalarını merkezi bir edge katmanında yönetmeyi sağlar.
Mono’da kullanım alanları
- API gateway kurulumu (kimlik, rate-limit, log)
- Mikroservis trafiği için merkezi politikalar
- Kong Ingress Controller ile Kubernetes entegrasyonu
Üretim kararları
Kong kurulumunda gateway’in kendisi kadar control plane/data plane ayrımı, konfigürasyonun sürümlenmesi, plugin güvenliği ve hata durumundaki davranış önemlidir. Her endpoint’e aynı middleware zincirini uygulamak yerine public, partner ve internal API’ler için açık politikalar tanımlanmalıdır.
API gateway ne zaman gerekli hâle gelir?
Bir reverse proxy birkaç servisin alan adı yönlendirmesini rahatlıkla çözebilir. Asıl ihtiyaç; farklı API tüketicilerine farklı erişim, kota ve izleme politikaları uygulandığında değişir. Aynı doğrulama kodunun birçok serviste tekrar edilmesi veya partner API’lerinin ayrı işletim kuralları gerektirmesi, gateway değerlendirmesini anlamlı kılar.
Kong üzerinde kimlik doğrulama yapılması, uygulamadaki bütün yetkilendirmeyi ortadan kaldırmaz. Bir token’ın geçerli olması ile kullanıcının belirli bir siparişi görmeye yetkili olması farklı kontrollerdir. Gateway ortak erişim politikasını uygular; kaynak ve iş kuralı bazlı yetkilendirme uygulamada kalır. Ayrıca Kong Gateway ile servisler arası iletişimi yöneten service mesh aynı ürün veya aynı sorumluluk değildir.
Dağıtım modelini seçmek
| Model | Dikkat noktası |
|---|---|
| Veritabanlı geleneksel kurulum | Veritabanı erişimi, yedekleme ve sürüm yükseltme sırası planlanır. |
| Deklaratif, DB-less kurulum | Konfigürasyonun tamamının sürümlenmesi ve node’lara tutarlı dağıtılması gerekir. |
| Control plane/data plane ayrımı | Seçilen ürün ve sürümün desteği, bağlantı kaybı ve sertifika yönetimi doğrulanır. |
| Kubernetes controller | Kaynak sahipliği, namespace sınırları ve controller yetkileri belirlenir. |
Eklentilerin her dağıtım modelinde veya ürün paketinde aynı özelliklerle çalıştığı varsayılmamalıdır. Kimlik sağlayıcı entegrasyonu, gelişmiş rate limiting ve yönetim yetenekleri için ilgili sürümün özellik ve lisans kapsamı incelenir. Yalnızca lisans ücretini değil, gateway’in işletim sorumluluğunu da maliyet hesabına katmak gerekir.
Rate limiting ve hata davranışı
Kota anahtarı IP adresi, tüketici veya kimlik bilgisi olabilir. Ortak NAT arkasındaki kullanıcıları tek IP üzerinden sınırlandırmak meşru trafiği engelleyebilir. Birden fazla gateway node’unda yerel sayaç kullanılması ise toplam kotanın beklenenden farklı uygulanmasına neden olabilir. Paylaşılan sayaç altyapısının gecikmesi ve arızada uygulanacak politika tasarımın parçasıdır.
Retry davranışı özellikle ödeme veya sipariş oluşturma gibi işlemlerde dikkat ister. Aynı isteğin tekrar gönderilmesi için idempotency desteği ve backend sözleşmesi bilinmelidir. Eklenti sırası da sonucu değiştirebilir: kimlik doğrulamasından önce veya sonra uygulanan kota aynı kullanıcı grubunu sınırlamayabilir.
Mono’nun API işletim yaklaşımı
Çalışma API envanteriyle başlar: public, partner ve internal servisler, tüketici kimlikleri ve mevcut hata oranları çıkarılır. Politikalar tek bir pilot API’de doğrulanır; loglarda token ve kişisel veri tutulmaması sağlanır. Konfigürasyon değişiklikleri kod incelemesinden geçirilir ve geri dönüş sürümü korunur. Böylece gateway, yeni bir merkezi arıza noktası olmadan yönetilebilir bir politika katmanı hâline gelir.
