Gateway Runtime'ları
Gateway Altyapısı, Apinizer platformunda API Proxy'lerin çalışacağı Gateway Runtime ortamlarını oluşturmak ve yönetmek, Kubernetes kaynaklarını yönetmek, Gateway Engine yapılandırması yapmak, SSL/TLS sertifikaları yapılandırmak ve API trafik log konnektörlerini yönetmek için gerekli tüm araçları sunar.
Modül Bileşenleri
Gateway Altyapısı modülü aşağıdaki sayfalar üzerinden yönetilir:
Gateway Runtime ortamları oluşturma, Gateway Engine yapılandırması, ortam yayımlama ve metrik izleme.
Dağıtık Cache Server'ları oluşturma ve yapılandırma. Cache Server'ları Gateway pod'larından bağımsız namespace'lerde çalışabilir.
Apinizer Platformu ortamlarının genel ayarları, deployment ve pod yönetimi, monitör ve ayarlar.
Gateway Runtime ortamlarındaki API trafiğini diğer ortamlara göndermek için konnektör yapılandırması.
Apinizer modüllerini (Manager, Gateway, Portal) SSL/TLS sertifikaları ile güvenli şekilde başlatma ve HTTPS bağlantıları sağlama.
Gateway Runtime Nedir?
Gateway Runtime (Ortam), bir kuruluştaki API Proxy'leri için bir çalışma zamanı yürütme bağlamıdır (Runtime Execution Context). Bir veya birden fazla API Proxy'e erişilebilmesi için Gateway Runtime ortamına dağıtılması gerekir. Bir API Proxy tek bir Gateway Runtime ortamına veya birden çok ortama dağıtılabilir.
Sistem Genel Ayarlar ekranı üzerinden, Kubernetes Namespace ve Resource'lar Apinizer ile yönetilsin seçeneği Aktif olarak işaretlendiğinde gelmektedir.
Bir Gateway Runtime ortamı, Gateway'leri çalıştırmak için sistem kaynağı olarak yalıtılmış, izole bir alan sağlar. Apinizer platformunda birden çok Gateway Runtime ortamı oluşturulmasına izin verir.
Gateway Runtime yönetimi iki şekilde gerçekleştirilir:
- Apinizer Tarafından Yönetilen (Managed by Apinizer): Gateway Runtime'ları için gereken tüm Kubernetes tanımları API Manager ekranı üzerinden oluşturulur ve yönetilir
- Uzak Gateway (Remote Gateway): API Manager ekranında mevcut Kubernetes tanımlarının sadece standart verileri kaydedilir
Gateway Runtime'ları ve Cache Server'ları ayrı ayrı yönetilmektedir. Cache Server oluşturma ve yönetimi için Dağıtık Cache sayfasına bakabilirsiniz.
:::
Gateway Runtime Rolleri
Bir Gateway Runtime ortamı, Üretim (Production), Geliştirme/Test (Development/Test) olarak farklı rollerde oluşturulabilir.
Burada dikkat edilmesi gereken nokta, istemcinin API Proxy'e erişebilmesi için en az bir Gateway Runtime ortamına dağıtılmış olması gerekir.
Test environment'da etkin olan API Proxy'ler veya Uygulamalar'ı test etmek amaçlı kullanılır. Donanımdaki kaynakların yeterliliğini ölçmek için de test yapılabilir.
Eğer test ortamından uzak bir ürün geliştirme yapılırsa ilerleme konusunda sorunlar yaşatabilir.
Production ortamında etkin olan API Proxy'ler veya Uygulamalar'a son kullanıcıların kullanımı için kullanılır. Bu ortam istemcilerin yükünü taşıyabilecek şekilde tasarlanmıştır.
Gateway Runtime Mimarisi
Gateway Runtime ortamı, birçok API'nin birden çok ekibe veya projeye yayıldığı ortamlarda kullanılmak üzere tasarlanmıştır. Apinizer'daki Gateway Runtime kavramı birebir Kubernetes'deki namespace'e denk gelmektedir.
Apinizer'da oluşturduğunuz ve dağıttığınız Gateway Runtime ortamı Kubernetes'de bir namespace olarak oluşturulmaktadır. Bir Gateway Runtime ortamı içinde namespace, deployment (dağıtım), pod, replica set, service ve access URL (erişim adresi) bileşenleri bulunur.
Apinizer Platformu ile oluşturulan tüm Gateway Runtime ortamları da Kubernetes kümesinin içinde yer alır.
Kubernetes Namespace Kavramı:
Kubernetes kümeleri büyük miktarda bağlantısız iş yüklerini eş zamanlı olarak yönetebilir. Kubernetes, küme içindeki objelerin karmaşasını gidermek için namespace denilen bir kavram kullanır.
Namespace'ler objelerin birbirleriyle gruplanmasına ve bu grupların bir birim gibi filtrelenip kontrol edilmesine imkan sağlar. İster özelleştirilmiş erişim kontrol politikalarını uygulamak, ister bir test ortamı için tüm birimleri ayırmak için kullanılsın, namespace'ler objeleri bir grup olarak yönetmek için güçlü ve esnek bir yapıdır.
Namespace'ler küme içindeki obje isimleri için bir faaliyet alanı sağlar. Bir namespace içindeki isimler özgün olmalı iken, farklı namespace'lerde aynı isim kullanılabilir.
Detaylı bilgi için Kubernetes Dokümantasyonu.
Gateway Runtime Bileşenleri
Namespace
Apinizer Platformundaki Gateway Runtime kavramı, Kubernetes ortamındaki Namespace kavramına karşılık gelmektedir.
Log Konnektörleri
Oluşturulan Gateway Runtime ortamındaki tüm API Trafiğinin ve isteklerin loglanacağı log konnektörleri tanımlarıdır.
Deployment (Dağıtım)
Gateway Runtime olarak deployment tanımlanır:
- Gateway Runtime (Worker Server): Apinizer Platform'un çekirdek (core) modülüdür, tüm API isteklerinin BackendAPI'ye yönlendirilmesinden sorumludur ve Policy Enforcement Point olarak çalışır. Gateway Runtime'ları artık Cache Server'larından bağımsız olarak yönetilir ve farklı namespace'lerde çalışabilir.
Service (Servis)
Gateway Runtime Service (Gateway Runtime servisi), Gateway Runtime Deployment'da yer alan Gateway pod'una erişebilmek için oluşturulur. Servis, tüm pod'lara gelen istekleri karşılayan katmandır. Konum olarak pod'ların önünde yer alır.
Servis bilgisi her Gateway Runtime ortamı oluşturulduğunda tanımlanır. Fakat küme içindeki tüm Gateway pod'larının bir servis ile yönetilmesi önemlidir. Ayrıca Apinizer Platformu'nda servis portları da özgün olmalıdır. Varsayılan olarak NodePort kullanılmakta ve bunun haricindeki servis tipleri Apinizer tarafından desteklenmemektedir.
Access URL (Erişim Adresi)
Access URL, Proxy'nin dış erişim adresidir. https:// <your-IP-address> şeklinde belirtilir. Dışarıdan erişim adres bilgisi kullanılarak Proxy'lere mesaj
gönderilebilir.
Gateway Runtime Erişim Adresi
Bir API Proxy'e, dağıtıldığı Gateway Runtime ortamının erişim adresi üzerinden erişilebilir.
Erişim Adresi Yapısı
Bir API Proxy'nin erişimi adresi şöyle olsun:
http://demo.apinizer.com/apigateway/myproxy
| Bileşen | Açıklama |
|---|---|
http://demo.apinizer.com/ | Gateway Runtime Erişim Adresi |
apigateway/ | Root Context |
myproxy | API Proxy Relative Path |
Erişim Adresi Yapılandırması
Gateway Runtime ortamı için tanımlanacak erişim adresi genelde, WAF veya Nginx gibi bir load balancer'da tanımlanan DNS adresidir. Apinizer'da tanımlanan Gateway Runtime ortamları Kubernetes'de bir namespace'e karşılık gelmektedir. Namespace içinde çalışan Gateway pod'larına erişim için Apinizer tarafından otomatik bir NodePort tipinde Kubernetes servisi oluşturulmaktadır. Gateway Runtime ortamı oluştururken Engine Service Port'a girilen değer ile bir servis oluşturulmaktadır.
Örnek Servis Yapılandırması
Gateway pod'larına erişmek için örnek bir servis bilgisi:
Eğer Engine Service Port değeri 30080 (default değerdir ve her Gateway Runtime ortamı için farklı olmalıdır) ise, WAF'da veya Nginx sunucunuzdaki DNS tanımına aşağıdaki gibi belirtmek gerekir:
http://kubernetes-worker-node-IP:30080/
Gateway Runtime Oluşturma
Gateway Runtime ortamı oluştururken genel tanım bilgilerini içeren görsellere aşağıda yer verilmiştir:
Gateway Runtime ortamı oluştururken genel tanım bilgilerini içeren alanlar:
| Alan | Açıklama |
|---|---|
| Yönetim Türü (Managed Type) | Gateway Runtime'ın nasıl yönetileceğini belirler. Apinizer Tarafından Yönetilen (Managed by Apinizer): Apinizer namespace, deployment, service ve tüm gerekli Kubernetes kaynaklarını otomatik olarak oluşturur. Uzak Gateway (Remote Gateway): Gateway pod'unuzun çalıştığından ve erişilebilir olduğundan emin olun. Apinizer sadece bağlantı detaylarını kaydeder, deployment'ı yönetmez. |
| Tür (Type) | Lisans'a ve kullanılan ortama uygun bir değer seçilmesi gerekmektedir. Test veya Üretim (Production) seçilebilir. |
| İletişim Protokolü Türü (Communication Protocol Type) | HTTP, gRPC, HTTP+Websocket iletişim protokollerinden birisi seçilebilir. |
| Ad (Name) | Gateway Runtime ortamının adı. Kubernetes'teki namespace'e karşılık gelmektedir. |
| Anahtar (Key) | Oluşturulan Gateway Runtime ortamı için kullanılan ve ortama özgü kısaltılmış bir anahtardır. |
| Erişim URL Adresi (Access URL) | Gateway Runtime ortamı içinde çalışan API Proxy'lerin dış erişim adresidir. |
| Açıklama (Description) | Yönetim kolaylığı ve önemli notlar için kullanılabilir. |
| Ortam Yayımlama Erişimi / Proje (Environment Publishing Access / Projects) | Gateway Runtime ortamının kullanılabileceği projeleri buradan seçebilir ya da tüm projelerde kullanılabilmesi için seçimi boş bırakılabilir. Eğer bir veya birden çok proje seçimi yapılırsa, yeni oluşturulan projelerde de kullanılmak için onların da eklenmesi gerekmektedir. Varsayılan değer olarak seçimsiz gelir. |
| Node Listesi (Node List) | Oluşturulan Gateway Runtime ortamının hangi kubernetes sunucularında çalışacağı seçilir. |
Namespace Bağımsızlığı:
Gateway pod'ları ve Cache Server pod'ları artık farklı Kubernetes namespace'lerinde çalışabilir. Gateway pod'ları
diğer namespace'lerdeki Cache Server'larına Kubernetes service discovery kullanarak eri şebilir (örn:
http://cache-http-service.apinizer-cache.svc.cluster.local:8090). Bu, daha esnek bir altyapı yönetimi sağlar ve
Gateway ve Cache iş yüklerini ayırmanıza olanak tanır.
İletişim Protokolü Türü Seçimi:
API Proxylerin hangi Gateway Runtime ortamına deploy edilebileceğini burada seçilen tür belirler:
- REST ve SOAP API Proxyler → HTTP tipindeki Gateway Runtime ortamına
- gRPC API Proxyleri → gRPC tipindeki Gateway Runtime ortamına
- Websocket API Proxyler → HTTP+Websocket tipindeki Gateway Runtime ortamına deploy edilebilir
Proje Seçimi: Proje seçilmesi durumunda sadece o proje içerisinde yer alan API Proxy'lerin bu Gateway Runtime ortamına deploy edilebileceği anlamına gelir.
Yönetim API Erişim Endpoint'leri
Gateway ve Cache iletişimi için birden fazla Yönetim API Erişim Endpoint'i yapılandırabilirsiniz. Her endpoint yapılandırması şunları içerir:
| Alan | Açıklama |
|---|---|
| Ad | API endpoint yapılandırması için açıklayıcı bir ad (örn: "Üretim Cluster", "DR Site") |
| Gateway Yönetim API'si Erişim URL'si | Gateway sunucunuzun health check adresi. Apinizer Yönetim Konsolu, Gateway pod'larına konfigürasyon güncellemeleri için bu adrese bağlanır. Örnek: http://worker-management-api-http-service.prod.svc.cluster.local:8091 |
| Cache Yönetim API'si Erişim URL'si | Cache Server'ınızın health check adresi. Gateway pod'ları Cache Server'larına bağlanmak için bu URL'yi kullanır. Örnek: http://cache-http-service.apinizer-cache.svc.cluster.local:8090 |
Çoklu Endpoint'ler:
Farklı senaryolar için birden fazla Yönetim API endpoint'i yapılandırabilirsiniz:
- Çok bölgeli dağıtımlar: Her bölge için ayrı endpoint'ler yapılandırın
- Yüksek erişilebilirlik: Failover için yedek endpoint'ler kurun
- Cluster ayrımı: Farklı Kubernetes cluster'ları için farklı endpoint'ler kullanın
Birden fazla endpoint yapılandırıldığında, Ek Değişkenler'deki environmentClusterName değişkeni ile hangi
endpoint'in kullanılacağını seçebilirsiniz.
Endpoint Yapılandırması:
- Her endpoint'te hem Gateway hem de Cache Yönetim API URL'leri yapılandırılmalıdır
- URL'ler cross-namespace iletişim için Kubernetes service discovery formatını kullanmalıdır
- Yönetim Konsolu, Gateway pod'ları ve Cache Server pod'ları arasında ağ bağlantısının olduğundan emin olun
API Proxy Trafik Log Konnektörleri
Gateway Runtime ortamındaki tüm API Proxy Trafiğinin ve uzantılarının loglanacağı log konnektörleri buradan tanımlanır.
API Proxy Trafik Log Konnektörü tanımlamalarını içeren görsele aşağıda yer verilmiştir:
Gateway Runtime ortamına konnektör ekleme hakkında daha fazla bilgi için bu sayfaya bakın.
Gateway Engine Konfigürasyonu
Gateway engine, Kubernetes ortamındaki Gateway pod'larına karşılık gelmektedir.
- Gateway engine (
apinizer-worker): Apinizer Platform'un çekirdek (core) modülüdür, tüm API isteklerinin BackendAPI'ye yönlendirilmesinden sorumludur ve Policy Enforcement Point olarak çalışır
Gateway engine tanımlamalarını içeren görsellere aşağıda yer verilmiştir:
Temel Ayarlar
| Alan | Açıklama |
|---|---|
| Sayı (Count) | Gateway engine sayısı, Kubernetes deployment'taki "replicas" değerine karşılık gelmektedir. Oluşturulacak Kubernetes Cluster'da oluşacak Pod sayısını belirtir. |
| CPU | Pod'un kullanacağı maksimum CPU core sayısı bilgisidir. |
| Bellek (Memory) | Pod'un kullanacağı maksimum bellek değeridir. |
| Bellek Birimi (Memory Unit) | Bellek için gerekli olan değerin birimi seçilir; MB, GB. |
Önerilen Değerler (Benchmark Tierlarına Göre):
| Tier | CPU | Bellek Boyutu | Kullanım Amacı |
|---|---|---|---|
| W1 | 1 | 2 GB | Test / PoC |
| W2 | 2 | 2 GB | Küçük production |
| W4 | 4 | 4 GB | Standart production |
| W8 | 8 | 8 GB | Yüksek hacimli production |
JVM bellek ve GC ayarları, container kaynak limitine göre entrypoint tarafından otomatik yapılandırılır. W1/W2 için heap %60, W4/W8 için %65 olarak ayrılır. Manuel -Xmx/-Xms parametresi gerekmez. Ayrıntılı benchmark verileri ve kapasite rehberi için Kapasite Planlama sayfasına bakabilirsiniz.
Servis Erişim Bilgileri
- HTTP Etkin (HTTP Enabled): Varsayılan olarak seçili olarak gelir
- HTTPS Etkin (HTTPS Enabled): HTTPS kullanılmak istenirse bu seçenek de seçilir, bu durumda şifreleme için gerekli dosyalar yüklenmelidir
- mTLS: HTTPS protokolü üzerinde çalıştığından sadece HTTPS ayarı açıkken seçilebilir
Keystore ve Truststore: HTTPS protokülü seçildiğinde, keystore ve truststore dosyaları JKS veya PFX formatında yüklenebilir.
Servis Portları: 30080-32767 aralığında bir servisin portu girilir. Servis Kubernetes'te NodePort olarak oluşacaktır.
Gateway Yönetim API Servisi:
- API Gateway Yönetimi API erişimi için HTTP hizmeti oluşturun (
httpServiceForManagementAPIEnabled): Etkinleştirildiğinde, Gateway Yönetim API erişimi için ayrı bir HTTP servisi oluşturur. Bu servis, Apinizer Yönetim Konsolu'nun Gateway pod'larıyla konfigürasyon güncellemeleri için iletişim kurmasında kullanılır. - API Gateway Yönetimi API erişimi için HTTPS hizmeti oluşturun (
httpsServiceForManagementAPIEnabled): Etkinleştirildiğinde, Gateway Yönetim API erişimi için ayrı bir HTTPS servisi oluşturur. Keystore ve truststore dosyalarının yüklenmesi gerekir. Yönetim Konsolu ile Gateway pod'ları arasında güvenli iletişim gerektiğinde bu seçeneği kullanın.
Yönetim API Servisleri:
Bu servisler, API Proxy trafiği için kullanılan ana HTTP/HTTPS servislerinden ayrıdır. Özellikle şunlar için kullanılır:
- Yönetim Konsolu'ndan Gateway pod'larına konfigürasyon güncellemeleri
- Health check'ler ve izleme
- Yönetim işlemleri
Bu servisler etkinleştirildiğinde, Yönetim API Erişim Endpoint'leri bölümünde ilgili URL'leri yapılandırmalısınız.
gRPC Protokolü Özel Ayarları
Eğer Gateway Management API, gateway pod'lar ile HTTPS üzerinden iletişim kuracaksa:
- API Geçidi Yönetimi API erişimi için HTTPS hizmeti oluşturun seçeneği seçilir
- Keystore ve truststore dosyaları JKS veya PFX formatında yüklenebilir
- Gateway Sunucusu Erişim URL'si girilir
Örnek: https://worker-http-service.prod.svc.cluster.local:8443
gRPC Tuning Parametreleri:
| Değişken | Açıklama | Varsayılan |
|---|---|---|
tuneGrpcKeepAliveTime | gRPC keep-alive zamanı (saniye) | 120 |
tuneGrpcKeepAliveTimeout | gRPC keep-alive timeout (saniye) | 20 |
tuneGrpcMaxMessageSize | gRPC maksimum mesaj boyutu (byte) | 4194304 (4MB) |
tuneGrpcMaxHeaderListSize | gRPC maksimum header list boyutu (byte) | 8192 |
tuneGrpcMaxConnectionAge | gRPC maksimum bağlantı yaşı (saniye) | 3600 |
tuneGrpcMaxConnectionAgeGrace | gRPC maksimum bağlantı yaşı grace period (saniye) | 30 |
tuneGrpcMaxConnectionIdle | gRPC maksimum bağlantı idle süresi (saniye) | 300 |
tuneGrpcMaxInboundMessageSize | gRPC maksimum inbound mesaj boyutu (byte) | 4194304 (4MB) |
tuneGrpcMaxInboundMetadataSize | gRPC maksimum inbound metadata boyutu (byte) | 8192 |
tuneGrpcHandshakeTimeout | gRPC handshake timeout (saniye) | 20 |
tuneGrpcPermitKeepAliveTime | gRPC permit keep-alive zamanı (saniye) | 120 |
tuneGrpcThreadPoolSize | gRPC thread pool boyutu | CPU sayısı * 2 |
WebSocket Ayarları
WebSocket Tuning Parametreleri:
| Değişken | Açıklama | Varsayılan |
|---|---|---|
tuneWebsocketIdleTimeout | WebSocket idle timeout (saniye) | 60 |
tuneWebsocketBufferSize | WebSocket buffer boyutu (byte) | 65536 |
tuneWebsocketTcpNoDelay | WebSocket TCP no delay (true/false) | true |
CORS Ayarları
CORS Ayarlarının Kullanım Amacı:
Bu CORS (Cross-Origin Resource Sharing) parametreleri, token alımı için gelen isteklerde kullanılır. Token alımı için gelen isteklere Management Konsol üzerinden politika eklenmez; bu ayarlar Gateway Runtime ortamı konfigürasyonu ile verilir. Bu parametreler normal API Proxy akışında kullanılmaz, sadece token alımı endpoint'leri için geçerlidir.
CORS (Cross-Origin Resource Sharing) Parametreleri:
| Değişken | Açıklama | Varsayılan |
|---|---|---|
tokenCorsAccessControlAllowOrigin | Access-Control-Allow-Origin header değeri | - |
tokenCorsAccessControlAllowCredentials | Access-Control-Allow-Credentials header değeri | - |
tokenCorsAccessControlAllowMethods | Access-Control-Allow-Methods header değeri | - |
tokenCorsAccessControlAllowHeaders | Access-Control-Allow-Headers header değeri | - |
tokenCorsAccessControlOrigin | Origin header değeri | - |
tokenCorsAccessControlRequestMethod | Access-Control-Request-Method header değeri | - |
tokenCorsAccessControlRequestHeaders | Access-Control-Request-Headers header değeri | - |
tokenCorsAccessControlExposeHeaders | Access-Control-Expose-Headers header değeri | - |
tokenCorsAccessControlMaxAge | Access-Control-Max-Age header değeri (saniye) | - |
X-Forwarded-For Ayarları
X-Forwarded-For Ayarlarının Kullanım Amacı:
Bu X-Forwarded-For parametreleri, token alımı için gelen isteklerde kullanılır. Token alımı için gelen isteklere Management Konsol üzerinden politika eklenmez; bu ayarlar Gateway Runtime ortamı konfigürasyonu ile verilir. Bu parametreler normal API Proxy akışında kullanılmaz, sadece token alımı endpoint'leri için geçerlidir.
X-Forwarded-For Parametreleri:
| Değişken | Açıklama | Varsayılan |
|---|---|---|
tokenXForwardedForIpHeader | X-Forwarded-For IP header adı | - |
tokenXForwardedForIpOrder | X-Forwarded-For IP sıralama (FIRST/LAST) | LAST |
Güvenlik Yapılandırması
Ek Değişkenler ile güvenlik yapılandırması yapılabilir:
| Değişken | Açıklama | Varsayılan Değer | Olası Değerler | Hedef Java Property |
|---|---|---|---|---|
jdkTLSVersions | Desteklenecek TLS protokol versiyonlarını belirler | TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 | SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 | https.protocols, jdk.tls.client.protocols, jdk.tls.server.protocols |
jdkTLSDisabledAlgorithms | Güvenlik nedeniyle devre dışı bırakılacak TLS algoritmalarını belirler | RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL | RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, SSLv3, TLSv1, TLSv1.1 | jdk.tls.disabledAlgorithms |
jdkCertPathDisabledAlgorithms | Sertifika doğrulama sürecinde kullanılmayacak algoritmaları belirler | JDK varsayılan değeri kullanılır | MD2, MD5, SHA1, RSA keySize değerleri, DSA keySize değerleri, EC keySize değerleri | jdk.certpath.disabledAlgorithms |
jdkCipherSuites | Kullanılacak şifreleme takımlarını belirler | JDK varsayılan değeri kullanılır | TLS 1.3 için: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256; TLS 1.2 için: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384; Legacy için: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA | https.cipherSuites |
jdkAllowUnsafeProtocols | Güvenli olmayan protokollerin kullanımına izin verilip verilmeyeceğini belirler | false | true, false | https.protocols.allow_unsafe, jdk.tls.client.protocols.allow_unsafe |
Önemli Notlar:
-
Ek değişkenler ayarlanmadığında:
- TLS Versions için "TLSv1, TLSv1.1, TLSv1.2, TLSv1.3" kullanılır
- TLS Disabled Algorithms için "RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL" kullanılır
- Diğer parametreler için JDK'nın varsayılan değerleri kullanılır
-
Güvenlik Önerileri:
- TLSv1.2 ve üstü versiyonların kullanılması önerilir
- GCM modlu şifreleme takımları tercih edilmelidir
- Zayıf algoritmalar (RC4, DES, 3DES) devre dışı bırakılmalıdır
- Anahtar boyutları yeterli güvenlik seviyesinde olmalıdır (RSA için en az 2048 bit, EC için en az 224 bit)
-
Performans Etkisi:
- Şifreleme takımlarının sıralaması performansı etkileyebilir
- Çok fazla şifreleme takımının devre dışı bırakılması eski sistemlerle uyumluluk sorunlarına neden olabilir
Ek Değişkenler (Additional Variables)
Pod içinde çalıştırılacak varsayılan ve opsiyonel değişkenler ve değerleri tanımlanır.
Önemli Değişkenler:
| Değişken | Hedef Ortam | Açıklama |
|---|---|---|
JAVA_OPTS | Hepsi | JVM Heap değerlerini ayarlar |
WORKER_TIMEZONE | Hepsi | Worker süreci için varsayılan saat dilimini belirler. IANA zaman dilimi adları (örn. Europe/Istanbul) veya sabit ofset (örn. +03:00) kabul edilir. Tanımlanmadığında konteyner sistem saat dilimine (genellikle UTC) düşer. Zaman tabanlı değişken çözümlemesini, zaman kısıtlamalı politikaları ve kendi saat dilimi bilgisi taşımayan tüm alanları etkiler. |
tuneWorkerThreads | HTTP Worker, HTTP+Websocket, Management API | Sunucunun minimum Worker thread sayısı. Tier varsayılanları: W1=128, W2=256, W4=512, W8=1536 |
tuneWorkerMaxThreads | HTTP Worker, HTTP+Websocket, Management API | Sunucunun maksimum Worker thread sayısı. Tier varsayılanları: W1=256, W2=512, W4=1024, W8=3072 |
tuneBufferSize | HTTP Worker, HTTP+Websocket, Management API | Thread'in yazma işlemi için kullanacağı buffer alanı (varsayılan: 16384 byte) |
tuneIoThreads | HTTP Worker, HTTP+Websocket, Management API | IO Thread sayısı. Tier varsayılanları: W1=2, W2=4, W4=8, W8=16 |
tuneBacklog | HTTP Worker, HTTP+Websocket, Management API | Backlog değeri. Tier varsayılanları: W1=2048, W2=4096, W4=8192, W8=16384 |
tuneRoutingConnectionPoolMaxConnectionPerHost | HTTP Worker, HTTP+Websocket, Management API | Host başına maksimum bağlantı sayısı. Tier varsayılanları: W1=250, W2=500, W4=1000, W8=2000 |
tuneRoutingConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | Toplam maksimum bağlantı sayısı. Tier varsayılanları: W1=500, W2=1000, W4=2000, W8=4000 |
tuneRoutingConnectionPoolMinThreadCount | HTTP Worker, HTTP+Websocket, Management API | Routing Connection Pool minimum thread sayısı |
tuneRoutingConnectionPoolMaxThreadCount | HTTP Worker, HTTP+Websocket, Management API | Routing Connection Pool maksimum thread sayısı |
tuneElasticsearchClientIoThreadCount | HTTP Worker, HTTP+Websocket, Management API | Elasticsearch Client IO Thread sayısı |
tuneMaxConcurrentRequest | HTTP Worker, HTTP+Websocket, Management API | Maksimum eşzamanlı istek sayısı. Tier varsayılanları: W1=500, W2=750, W4=3000, W8=10000 |
tuneMaxQueueSize | HTTP Worker, HTTP+Websocket, Management API | Maksimum kuyruk boyutu (varsayılan: 0) |
tuneCacheConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | Cache Connection Pool toplam maksimum bağlantı sayısı (varsayılan: 2048) |
tuneApiCallConnectionPoolMaxConnectionPerHost | HTTP Worker, HTTP+Websocket, Management API | API Call Connection Pool host başına maksimum bağlantı sayısı (varsayılan: 256) |
tuneApiCallConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | API Call Connection Pool toplam maksimum bağlantı sayısı (varsayılan: 4096) |
multipartConfigMaxFileSize | HTTP Worker, HTTP+Websocket, Management API | Multipart config maksimum dosya boyutu (varsayılan: 100MB) |
multipartConfigMaxRequestSize | HTTP Worker, HTTP+Websocket, Management API | Multipart config maksimum istek boyutu (varsayılan: 100MB) |
multipartConfigFileSizeThreshold | HTTP Worker, HTTP+Websocket, Management API | Multipart config dosya boyutu eşiği (varsayılan: 100MB) |
defaultCharset | HTTP Worker, HTTP+Websocket, Management API | Varsayılan karakter seti (varsayılan: UTF-8) |
deploymentTimeout | HTTP Worker, HTTP+Websocket, Management API | Deployment timeout süresi saniye cinsinden (varsayılan: 30) |
tuneReadTimeout | HTTP Worker, HTTP+Websocket, Management API | İstemciden veri okuma timeout'u. Client veri göndermezse bu süre sonunda bağlantı kapatılır (varsayılan: 30000 ms / 30 saniye) |
tuneNoRequestTimeout | HTTP Worker, HTTP+Websocket, Management API | Bağlantı kurulduktan sonra request gelmeme timeout'u. Bağlantı kurulup istek gönderilmezse bu süre sonunda bağlantı kapatılır (varsayılan: 60000 ms / 60 saniye) |
http2Enabled | HTTP Worker, HTTP+Websocket, Management API | HTTP/2 protokolünü etkinleştirir (varsayılan: false) |
environmentClusterName | HTTP Worker, HTTP+Websocket, Management API | Ortam cluster adı |
tuneAsyncExecutorCorePoolSize | HTTP Worker, HTTP+Websocket, Management API | Async executor core pool boyutu (varsayılan: tuneWorkerThreads) |
tuneAsyncExecutorMaxPoolSize | HTTP Worker, HTTP+Websocket, Management API | Async executor maksimum pool boyutu (varsayılan: tuneWorkerMaxThreads) |
tuneAsyncExecutorQueueCapacity | HTTP Worker, HTTP+Websocket, Management API | Async executor kuyruk kapasitesi (varsayılan: tuneMaxQueueSize > 0 ? tuneMaxQueueSize : 1000) |
METRICS_ENABLED | HTTP Worker, HTTP+Websocket, Management API | Metrik toplama özelliğinin açık olup olmadığı (varsayılan: false) |
logLevel | Hepsi | Uygulama loglarının seviyesi (ERROR, WARNING, INFO, DEBUG, TRACE, OFF) |
tuneMaxDecompressedBodySize | HTTP Worker, HTTP+Websocket, Management API | Sıkıştırılmış (gzip, deflate, brotli, zstd) istek veya yanıt gövdesinin açıldıktan sonraki maksimum boyutu (byte). Sıkıştırma bombası saldırılarına karşı koruma sağlar (varsayılan: 2147483648 / 2 GB) |
Sıkıştırma Bombası Koruması:
Gateway, sıkıştırılmış istek ve yanıt gövdelerini açarken maksimum boyut limiti uygulayarak sıkıştırma bombası saldırılarına karşı koruma sağlar. Küçük boyutlu sıkıştırılmış bir gövde, açıldığında gigabyte'larca bellek tüketebilir — tuneMaxDecompressedBodySize parametresi bu durumu engeller.
Varsayılan değer 2 GB olarak belirlenmiştir ve mevcut kullanım senaryolarının büyük çoğunluğunu kapsar. Güvenlik gereksinimlerinize göre bu değeri düşürebilirsiniz (örneğin 50 MB = 52428800, 100 MB = 104857600). Değer byte cinsinden belirtilir.
Bu limiti çok düşük ayarlamak, büyük boyutlu meşru istek veya yanıtların reddedilmesine neden olabilir. Ortamınızdaki tipik istek boyutlarını göz önünde bulundurarak uygun bir değer belirleyin.
Asenkron İşlemler Thread Pool'u:
RestApi Politası ve Script politikası, asenkron işlemler için ManagementConfig'de yapılandırılan merkezi thread pool'u kullanır. Bu, thread yönetimini iyileştirir ve kaynak kullanımını optimize eder. Gateway Runtime ortamlarında gerçekleştirilen asenkron işlemler, bu ayrı thread pool tarafından yönetilir ve optimal performans ve kaynak tahsisi için belirli parametrelerle yapılandırılabilir.
Kullanım Senaryoları:
- Rest API Politikası: Harici servislere yapılan asenkron HTTP çağrıları
- Script Politikası: Ana istek thread'ini bloklamayan asenkron script çalıştırmaları
- Loglama İşlemleri: Asenkron log yazma işlemleri
- Trafik Aynalama: İsteklerin ikincil endpoint'lere asenkron olarak aynalanması
Yapılandırma Kılavuzu:
tuneAsyncExecutorCorePoolSize: Pool'da canlı tutulan minimum thread sayısı (varsayılan:tuneWorkerThreadsile aynı)tuneAsyncExecutorMaxPoolSize: Oluşturulabilecek maksimum thread sayısı (varsayılan:tuneWorkerMaxThreadsile aynı)tuneAsyncExecutorQueueCapacity: Yeni thread'ler oluşturulmadan önce kuyrukta bekleyebilecek maksimum görev sayısı (varsayılan:tuneMaxQueueSize> 0 ise bu değer, aksi halde 1000)
Thread Pool Boyutlandırma:
Asenkron executor thread pool'u ana worker thread pool'undan ayrıdır. Toplam thread sayısının (worker thread'leri + asenkron executor thread'leri) sisteminizin kapasitesini aşmadığından emin olun. Bu değerleri yapılandırırken CPU core'ları ve belleği göz önünde bulundurun.
Tier Bazlı Önerilen Thread ve Bağlantı Değerleri:
Aşağıdaki değerler wrk2 yük testleriyle doğrulanmış optimum ayarlardır. Her tier için entrypoint varsayılan olarak bu değerleri otomatik uygular; üretim ortamı ihtiyacınıza göre ince ayar yapabilirsiniz.
| Tier | CPU | tuneIoThreads | tuneWorkerThreads | tuneWorkerMaxThreads | tuneBacklog | tuneMaxConcurrentRequest |
|---|---|---|---|---|---|---|
| W1 | 1 | 2 | 128 | 256 | 2048 | 500 |
| W2 | 2 | 4 | 256 | 512 | 4096 | 750 |
| W4 | 4 | 8 | 512 | 1024 | 8192 | 3000 |
| W8 | 8 | 16 | 1536 | 3072 | 16384 | 10000 |
Routing Bağlantı Havuzu (tuneRoutingConnectionPoolMaxConnectionPerHost / tuneRoutingConnectionPoolMaxConnectionTotal):
| Tier | Max Conn/Host | Max Conn Total | ES Max Conn/Host |
|---|---|---|---|
| W1 | 250 | 500 | 8 |
| W2 | 500 | 1000 | 16 |
| W4 | 1000 | 2000 | 32 |
| W8 | 2000 | 4000 | 128 |
Java Options Uyarısı:
Apinizer entrypointi, JVM heap değerlerini tier ve container bellek limitine göre otomatik yapılandırır:
- W1 / W2 (2 GB):
MaxRAMPercentage=60— heap ~1.2 GB - W4 (4 GB):
MaxRAMPercentage=65— heap ~2.6 GB - W8 (8 GB):
MaxRAMPercentage=65— heap ~5.2 GB
UseContainerSupport varsayılan olarak aktiftir. -Xmx / -Xms değerleri verildiğinde otomatik boyutlandırma devre dışı kalır; bu değerleri yalnızca özel bir gereksinim varsa kullanın. GC algoritması olarak G1GC kullanılır.
Host Takma Adlarını Ayarlama
Host Takma Ad (Host Alias) Nedir? Neden ihtiyaç duyulur?
Ağda bulunan IP adresleri bazen host isimleri arkasına konulabilir. Bunlar eğer nameserver ya da host dosyasına tanımlanmamışsa ya da bir şekilde Apinizer'ın bunları çözmesi sağlanamamışsa, Gateway pod'larının bu isimleri çözmesi için Host Alias tanımı yapılmalıdır.
Kubernetes üzerinde host adları ya da bunlara karşılık gelen IP adreslerine, takma host isimleri verilebilir. Bu ayar, deployment.yaml dosyası içinde tanımlanır.
Burada yapılan değişikliklerin etkinleşmesi için republish işlemi gerekmektedir. Versiyon güncellemesine nazaran bu işlemde bir kaç dakikalık kesinti olacağına dikkat edilmelidir.
Örnek Kullanım:
| IP Address | Host Aliases |
|---|---|
| 10.10.10.10 | alias_name, other_alias_name |
Host takma adı ayarlarını içeren görsele aşağıda yer verilmiştir:
Gateway Runtime Ortamı Yayımlama
Bir Gateway Runtime ortamı yayımlamak için Yayınlanmamış (Unpublished) butonuna tıklanır.
Gelen pencereden işlemi onaylamak için Yayınla (Publish) butonuna tıklanır ve Gateway Runtime ortamı Kubernetes sunucusuna dağıtılır.
Gateway Runtime Ortamı Yeniden Yayınlama
Yayımlanmış durumda olan bir Gateway Runtime ortamının üzerine gelerek Yayınlanmış (Published) butonuna tıklanır.
Gelen pencereden işlemi onaylamak için Yeniden Yayınla (Republish) butonuna tıklanır.
Gateway Runtime Ortamı Yeniden Yayınla işleminden sonra, Pod'lar da yeniden başlatılır (restart).
Yeniden yayınlama işlemi sırasında birkaç dakikalık kesinti olabilir. Bu işlem, Gateway Engine konfigürasyonu, Host Takma Adları ve diğer ortam ayarlarındaki değişikliklerin etkinleşmesi için gereklidir.
JWT Token Doğrulama Anahtarı
Gateway Runtime ortamı kaydedilmiş ise JWT Token Doğrulama Anahtarı üretilmiştir. Bu token, kimlik doğrulama politikaları için Apinizer Token Servisi üzerinden token üretmede yer alan private key'in değeridir. Eğer kullanıcı kendi token'ını üretmek isterse buradaki private key'den faydalanmalıdır.
Bu bilgilere erişmek için JWT Token Doğrulama Anahtarı (JWT Token Validation Keys) tabına gidilir.
Kullanılabilir İşlemler:
- Redeploy: Mevcut anahtarın değişiklik yapılmadan sunuculara tekrar yüklenmesi
- Regenerate & Deploy: Yeni anahtar üretilip sunuculara yüklenmesi
- Upload & Deploy: PEM Encoded Private Key dosyası yüklenerek yeni anahtar üretilmesi
Gateway Runtime Ortamı Silme
Gateway Runtime ortamı seçerek, en altta bulunan Gateway Runtime Ortamı Sil (Remove Environment) tabından Gateway Runtime Ortamı Sil (Remove Environment) diyerek Gateway Runtime ortamı ile ilgili bilgileri veritabanından silinmiş olur.
Dikkat: Silme işlemi tamamlandığında bu Gateway Runtime ortamında kayıtlı tüm API Proxy'lerin yüklemesi de silinir ve bu Gateway Runtime ortamına daha önceden yüklenmiş olan API Proxy'lere bu Gateway Runtime ortamı üzerinden artık erişilemez.
Metrik Monitörü
Kubernetes üzerindeki Gateway pod'larının durumunu izlemek için Gateway Runtime ortamı listesinden ilgili Gateway Runtime ortamının Podlar (Pods) linkine tıklanır.
Podlar ekranını içeren görsele aşağıda yer verilmiştir:
Eğer tüm Gateway Runtime ortamlarının metriklerine erişmek isterseniz Kubernetes İş Yükleri sayfasına tıklayınız.
Diagnostics
Gateway Runtime'ların detaylı sistem metriklerine, JVM bilgilerine, thread durumlarına ve performans verilerine erişebilirsiniz. Diagnostics sayfasına Gateway Runtime ortamı listesinden ilgili Gateway Runtime ortamının Diagnostics butonuna tıklayarak erişebilirsiniz.
Diagnostics özellikleri, kullanımı ve detaylı bilgiler için Environment Diagnostics sayfasına bakın.