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'ları
Gateway Runtime ortamları oluşturma, Gateway Engine yapılandırması, ortam yayımlama ve metrik izleme.
Dağıtık Cache
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.
Kubernetes İş Yükleri
Apinizer Platformu ortamlarının genel ayarları, deployment ve pod yönetimi, monitör ve ayarlar.
Gateway Runtime Ortamlarına Konnektör Eklenmesi
Gateway Runtime ortamlarındaki API trafiğini diğer ortamlara göndermek için konnektör yapılandırması.
SSL/TLS ile Apinizer Modüllerini Başlatma
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) veya Sandbox 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
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.
Sandbox Environment
Sandbox ortamında etkin olan API Proxy’ler ve Uygulamalar, geliştirme (development) ve test etme sürecinde
kullanılır. Bu ortam, production sürecini etkilemeden ve üretim sürecine yakın olarak güvenli test yapabilme
imkanı sağlar.Ürünün production environment üzerindeki durumunu taklit ettiği için önemlidir. Mesela, ilgili API Proxy’e
poliçe ekleyip production environment üzerinde erişim öncesinde test etmeyi kolaylaştırır.
Böylelikle production environment’ın güvenliğini sağlar ve bir geliştiricinin (developer) yanlışlıkla canlıdaki
(production) bir uygulamayı değiştirme riskini ortadan kaldırmasına yardımcı olur. Ayrıca uygulamanın
çalıştığından emin olarak son kullanıcının erişmesi de sağlanır.
Production Environment
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
Namespace
Apinizer Platformundaki Gateway Runtime kavramı, Kubernetes ortamındaki Namespace kavramına karşılık
gelmektedir.
Log Konnektörleri
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)
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)
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 (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:| 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:Gateway Runtime Oluşturma
Gateway Runtime ortamı oluştururken genel tanım bilgilerini içeren görsellere aşağıda yer verilmiştir:
| 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.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
environmentClusterName değişkeni ile hangi
endpoint’in kullanılacağını seçebilirsiniz.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 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
Temel Ayarlar
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. |
| CPU | Bellek Boyutu |
|---|---|
| 1 | 2GB |
| 2 | 4GB |
| 4 | 6GB |
| 8 | 10GB |
Servis Erişim Bilgileri
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
- 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
Ek Değişkenler (Additional Variables)
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 |
tuneWorkerThreads | HTTP Worker, HTTP+Websocket, Management API | Sunucunun minimum Worker thread sayısı |
| (varsayılan: 1024) | ||
tuneWorkerMaxThreads | HTTP Worker, HTTP+Websocket, Management API | Sunucunun maksimum Worker thread sayısı |
| (varsayılan: 2048) | ||
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ı (varsayılan: CPU core sayısı) |
tuneBacklog | HTTP Worker, HTTP+Websocket, Management API | Backlog değeri (varsayılan: 1000) |
tuneRoutingConnectionPoolMaxConnectionPerHost | HTTP Worker, HTTP+Websocket, Management API | Host başına |
| maksimum bağlantı sayısı (varsayılan: 1024) | ||
tuneRoutingConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | Toplam maksimum |
| bağlantı sayısı (varsayılan: 2048) | ||
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ı |
| (varsayılan: tuneWorkerMaxThreads * tuneIoThreads) | ||
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) |
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ı
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)
gRPC Protokolü Özel Ayarları
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
https://worker-http-service.prod.svc.cluster.local:8443gRPC 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 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ı
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.
| 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ı
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.
| 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ı
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 |
|---|---|---|
jdkTLSVersions | Desteklenecek TLS protokol versiyonları | TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 |
jdkTLSDisabledAlgorithms | Güvenlik nedeniyle devre dışı bırakılacak TLS algoritmaları | RC4, DES, |
| MD5withRSA, DH keySize < 768… | ||
jdkCipherSuites | Kullanılacak şifreleme takımları | JDK varsayılan değeri |
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. Örnek Kullanım:| IP Address | Host Aliases |
|---|---|
| 10.10.10.10 | alias_name, other_alias_name |
Gateway Runtime Ortamı Yayımlama
1
Yayınlanmamış Gateway Runtime Ortamını Seç
Bir Gateway Runtime ortamı yayımlamak için Yayınlanmamış (Unpublished) butonuna tıklanır.
2
İşlemi Onayla
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
1
Yayınlanmış Gateway Runtime Ortamını Seç
Yayımlanmış durumda olan bir Gateway Runtime ortamının üzerine gelerek Yayınlanmış (Published) butonuna
tıklanır.
2
Yeniden Yayınla
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).
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.