Ana içeriğe geç

Kubernetes'e Kurulum

Apinizer modülleri Kubernetes üzerinde iki farklı yöntem ile kurulabilir: ham Kubernetes Manifest YAML dosyaları ile ya da Helm chart kullanılarak. Aşağıdaki üst sekmelerden tercih ettiğiniz dağıtım yöntemini, alt sekmelerden ise kurmak istediğiniz modülü seçebilirsiniz. Her modülün kendine ait kaynak gereksinimleri, ortam değişkenleri ve servis tanımları vardır.

Kurulum Akışı​

MongoDB (Önkoşul)

Apinizer Manager metadata, deploy edilmiş proxy snapshot'ları ve Integration scheduler kuyruğu için MongoDB zorunludur. Hangi runtime ortamını seçerseniz seçin (Kubernetes, Docker, Sanal Sunucu), MongoDB kurulması gereklidir. Üretim ortamında replica set önerilir.

MongoDB Kurulumu sayfasından detaylı adımları izleyin.

API Manager

Apinizer Yönetim Konsolu (API Manager), Apinizer platformunun merkezi kontrol ve yönetim bileşenidir. API Trafik Yöneticileri, API'leri yöneten kişiler ve sistem yöneticileri bu uygulama üzerinden kullanıcı ve yetkilendirme yönetimi, ortam kurulumu, deployment yönetimi ve lisans anahtarı yüklemesini gerçekleştirir. API Manager ayağa kalktıktan sonra diğer modülleri kurabilirsiniz.

Gateway

Apinizer'ın asıl API Gateway modülüdür. API isteklerinin gelen noktası ve yönetim politikalarının uygulandığı yer burasıdır. API Manager üzerinden en az bir environment tanımlanması zorunludur. Gateway, Managed (Apinizer tarafından yönetilen, K8s cluster'a dağıtılan) veya Remote (harici cluster'a kurulu, Manager tarafından yönetilen) olarak kurulabilir.

Opsiyonel Modüller​

Aşağıdaki modüller API yönetimi için gerekli değildir; ancak özel gereksinimlerinize (cache, zamanlı işler, geliştirici portali, yüksek hacim logging) göre kurabilirsiniz.

Cache

Paylaşımlı Hazelcast cache kümesi. Rate limit, JWT token cache, cluster genelinde durum paylaşımı ve distributed lock'lar için önerilir. Managed (K8s) veya Remote olarak kurulabilir.

Integration

Quartz tabanlı görev zamanlayıcı. Zamanlı API çağrıları, batch işler, webhook trigger'ları ve periyodik senkronizasyon işlemleri için kullanılır.

API Portal

Geliştiriciler için API katalog ve self-service portalı. API tüketicileri bu portal üzerinden token oluşturur, API'leri keşfeder, dokümantasyonu okur ve test eder.

Elasticsearch

Yüksek hacim API trafik loglarının gerçek zamanlı indexlenmesi ve analizi. Elasticsearch kurmazsanız loglar MongoDB'ye yazılır — ancak yüksek trafikli ortamlarda Elasticsearch önerilir.

SSL ile API Manager

API Manager uygulaması için HTTPS terminasyonu. Load balancer veya reverse proxy kullanarak Manager trafiğini şifreli hale getirin.

ipucu

Aşağıdaki sekmelerden tercih ettiğiniz dağıtım yöntemini (Manifest YAML veya Helm Chart) seçin; her yöntem aynı kurulum adımlarını izler.

Apinizer modüllerini ham Kubernetes Manifest (YAML) dosyaları ile cluster üzerinde adım adım kurar. Bu yöntem cluster'a tam kontrol sağlar; her modülün Deployment, Service, ConfigMap, Secret, RBAC ve Ingress tanımlarını ayrı dosyalar halinde uygular. Helm gibi paket yöneticisi kullanmaz, doğrudan kubectl apply -f ile çalışır.

API Manager ve Gateway kurulumları zorunludur — Apinizer'ın asıl API Gateway'i bu Gateway modülüdür. Aşağıdaki adımları sırayla uygulayın: önce API Manager ayağa kalkmalı, ardından en az bir Gateway kurulup Manager üzerinden environment olarak tanımlanmalıdır. Cache, Integration ve API Portal modülleri opsiyoneldir ve sayfanın alt kısmındaki sekmelerden kurulabilir.

API Manager Kurulumu​

Apinizer Yönetim Konsolu (API Manager), Apinizer'ın yönetildiği bileşendir. API Trafik Yöneticileri, API'leri yöneten kişiler ve API tüketicileri bu uygulama üzerinden gerekli işlemlerini yapabilirler.

bilgi

Apinizer imajları Kubernetes ortamına deploy edildikten sonra Apinizer tarafından size verilen Lisans Anahtarını veri tabanına eklemeniz gerekir.

Kurulum Öncesi Adımlar​

uyarı

MongoDB kurulumu zorunludur — Apinizer'ı çalıştırmadan önce ayağa kalkmış bir MongoDB instance'ınız olmalı. Manager metadata'sı, deploy edilmiş proxy snapshot'ları, Integration scheduler kuyruğu ve audit kayıtları tamamen MongoDB üzerinde tutulur. Hangi runtime'ı (Kubernetes, Docker veya Sanal Sunucu) seçerseniz seçin bu bağımlılık değişmez.

Üretim için replica set önerilir; tek node sadece PoC / geliştirme için uygundur. Kurulum adımları için → MongoDB Kurulumu sayfasından devam edin.

not

Elasticsearch, API trafik loglarının indekslenmesi ve aranması için önemlidir; opsiyoneldir. Elasticsearch kurmazsanız trafik logları MongoDB üzerine yazılır — yüksek trafikli ortamlar için Elasticsearch önerilir. Detay için → Elasticsearch Kurulumu sayfasına bakın.

Kubernetes Yetkilerinin Tanımlanması ve Namespace'lerin Oluşturulması​

Apinizer'ın oluşturulan Namespace'deki pod'lara erişim için Kubernetes API'sinin izinlerin tanımlanması gerekmektedir.

Kubernetes'de ClusterRole ve ClusterRoleBinding, Kubernetes küme düzeyinde rol ve rol atama mekanizmalarını sağlar. Bu iki kaynak, küme yöneticilerinin ve uygulama geliştiricilerinin Kubernetes kaynaklarına erişim ve izinlerini yönetmelerini sağlar.

Ortam (Environment) yönetimleri API Manager üzerinden yapılacaksa, Apinizer'ın Kubernetes API'lerine erişip, Namespace, Deployment, Pod, Service oluşturma, silme, güncelleme ve izleme işlemlerini yapabilmesi için yetkilerin tanımlanması gerekir.

Kubernetes yönetimi Apinizer ile yapılıyor ise​

Aşağıdaki adımda, Kubernetes üzerinde Role ve RoleBinding oluşturup yetkiler tanımlanır. Bu adımda oluşturulacak tüm environment'lar için yetki verilir.

vi apinizer-role.yaml
apinizer-role.yaml — Apinizer namespace + RBAC
apiVersion: v1
kind: Namespace
metadata:
  name: apinizer
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: apinizer-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: apinizer-role
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:serviceaccounts
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: apinizer-role
rules:
  - apiGroups:
      - ''
    resources:
      - nodes
      - services
      - namespaces
      - pods
      - endpoints
      - pods/log
      - secrets
      - configmaps
    verbs:
      - get
      - list
      - watch
      - update
      - create
      - patch
      - delete
  - apiGroups:
      - apps
    resources:
      - deployments
      - replicasets
      - statefulsets
      - configmaps
    verbs:
      - get
      - list
      - watch
      - update
      - create
      - patch
      - delete
kubectl apply -f apinizer-role.yaml

Kubernetes yönetimi Apinizer ile yapılmıyor ise​

Burada sadece Apinizer namespace'indeki manager uygulaması için yetkiler ayarlanır.

vi apinizer-manager-role.yaml
apinizer-manager-role.yaml — Manager-only namespace + RBAC
apiVersion: v1
kind: Namespace
metadata:
  name: apinizer
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: manager-serviceaccount
  namespace: apinizer
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: apinizer-role
  namespace: apinizer
rules:
  - apiGroups:
      - ''
    resources:
      - services
      - namespaces
      - pods
      - endpoints
      - pods/log
      - secrets
    verbs:
      - get
      - list
      - watch
      - update
      - create
      - patch
      - delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: manager-serviceaccount-apinizer-role-binding
  namespace: apinizer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: apinizer-role
subjects:
  - kind: ServiceAccount
    name: manager-serviceaccount
    namespace: apinizer
kubectl apply -f apinizer-manager-role.yaml

Yapılandırma Parametreleri​

API Manager, API'lerin, Politikaların, Kullanıcı, Credential'ların ve konfigürasyonların tanımladığı ve API Trafik ve Analitik verilerinin görüntülenip analiz edildiği web tabanlı bir yönetim arayüzüdür. API Manager'ın Kubernetes'e deployment'ı öncesi aşağıdaki değişkenleri kendi ortamınıza uygun şekilde konfigüre edin.

  • APINIZER_VERSION - Hangi Apinizer versiyonunu kuracağınızı belirten parametredir. Mevcut sürümleri görmek için lütfen tıklayınız. Yeni kurulumlarda her zaman en son sürümü kullanmanız önerilir. Sürüm notlarını incelemek için lütfen tıklayınız.
  • MONGO_DBNAME - Apinizer konfigürasyonları için kullanılacak veritabanı URL bilgisi. Varsayılan olarak "apinizerdb" ismi kullanılması önerilir.
  • MONGOX_IP ve MONGOX_PORT - MongoDB sunucularına ait IP ve port bilgileri. MongoDB varsayılan portu 25080'dir. Apinizer varsayılan olarak 25080 portunu kullanır.
  • MONGO_USERNAME ve MONGO_PASSWORD - MongoDB uygulamanıza ait Apinizer için tanımlanmış, ilgili veritabanı üzerinde yetkili ya da o veritabanı oluşturma yetkisine sahip olan kullanıcıya ait olan bilgiler.
  • YOUR_LICENSE_KEY - Apinizer tarafından tarafınıza gönderilen lisans anahtarı.
  • K8S_ANY_WORKER_IP - Apinizer kurulumu tamamlandığında herhangi bir web tarayıcıdan Apinizer Yönetim Konsolu arayüzüne erişebilmeniz için Kubernetes Cluster'ınızdan bir IP gerekmektedir. Bu genelde Kubernetes Worker sunucularından biri olarak tercih edilir ve daha sonra bir Yük Dağıtıcı (Load Balancer) ve DNS arkasına konulması önerilir.

Mongodb bilgileriyle secret oluşturulması​

MongoDB veritabanı bağlantı bilgilerinizi kubernetes deployment'larda Encoded bir şekilde kayıtlı olması tavsiye edilmektedir. Bunun için Linux tabanlı bir işletim sisteminin terminalinde aşağıdaki adımları uygulayın.

DB_URL='mongodb://<MONGO_USERNAME>:<MONGO_PASSWORD>@<MONGO1_IP>:<MONGO1_PORT>,<MONGO2_IP>:<MONGO2_PORT>,<MONGO3_IP>:<MONGO3_PORT>/?authSource=admin&replicaSet=apinizer-replicaset'

DB_NAME=<MONGO_DBNAME>
# <MONGO_DBNAME> değişkeni için default önerimiz "apinizerdb" ismidir

echo -n ${DB_URL} | base64
# Bunun çıktısını bir sonraki adımda <ENCODED_URL> değişkeni yerine koyacağız

echo -n ${DB_NAME} | base64
# Bunun çıktısını bir sonraki adımda <ENCODED_DB_NAME> değişkeni yerine koyacağız
vi secret.yaml

Mongodb bilgileriyle secret yaml'ının hazırlanması:

mongo-secret.yaml — MongoDB connection secret
apiVersion: v1
kind: Secret
metadata:
  name: mongo-db-credentials
  namespace: apinizer
type: Opaque
data:
  dbUrl: <ENCODED_URL>
  dbName: <ENCODED_DB_NAME>
kubectl apply -f secret.yaml

API Manager'in Kubernetes deployment'ı​

Aşağıdaki örnek yaml dosyasını sistemlerinize uygun olacak şekilde değiştirerek Kubernetes Cluster'ınıza yükleyin.

vi apinizer-manager-deployment.yaml
apimanager-deployment.yaml — API Manager Deployment + Service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apimanager
  namespace: apinizer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apimanager
      version: v1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: apimanager
        version: v1
    spec:
      containers:
      - env:
        - name: JAVA_OPTS
          value: '-XX:MaxRAMPercentage=75.0 -Dlog4j.formatMsgNoLookups=true'
        - name: SPRING_PROFILES_ACTIVE
          value: prod
        - name: WORKER_DEPLOYMENT_TIMEOUT
          value: '120'
        - name: SPRING_SERVLET_MULTIPART_MAX_FILE_SIZE
          value: '70MB'
        - name: SPRING_SERVLET_MULTIPART_MAX_REQUEST_SIZE
          value: '70MB'
        - name: SPRING_DATA_MONGODB_URI
          valueFrom:
            secretKeyRef:
              key: dbUrl
              name: mongo-db-credentials
        - name: SPRING_DATA_MONGODB_DATABASE
          valueFrom:
            secretKeyRef:
              key: dbName
              name: mongo-db-credentials
        name: apimanager
        image: apinizercloud/apimanager:<APINIZER_VERSION>
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          limits:
            cpu: 1
            memory: 3Gi
        startupProbe:
          failureThreshold: 12
          httpGet:
            path: /apinizer/management/health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 10
        readinessProbe:
          failureThreshold: 12
          httpGet:
            path: /apinizer/management/health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 10
        livenessProbe:
          failureThreshold: 12
          httpGet:
            path: /apinizer/management/health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 10
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      hostAliases:
      - ip: "<IP_ADDRESS>"
        hostnames:
        - "<DNS_ADDRESS_1>"
        - "<DNS_ADDRESS_2>"
bilgi

Eğer Ortamlar Apinizer Üzerinden Yönetilmeyecekse Manager'ın Deployment'ı Değiştirilir

Deployment objelerinin gerekli ServiceAccount'a bind olabilmesi için spec alanına aşağıdaki gibi serviceAccountName alanı eklenir:

spec:
  serviceAccountName: manager-serviceaccount
bilgi

Ortam Değişkenleri

Apinizer API Manager, Spring Boot alt yapısından çalışır. Spring Boot'da Ortam değişkenlerini genellikle alt çizgi (_) kullanarak ve büyük harfle ifade eder. Bu nedenle örneğin, spring.servlet.multipart.max-file-size ve spring.servlet.multipart.max-request-size özelliklerini ortam değişkenleri olarak ayarlarken alt çizgi kullanmanız gerekebilir.

Örnek: SPRING_SERVLET_MULTIPART_MAX_FILE_SIZE ve SPRING_SERVLET_MULTIPART_MAX_REQUEST_SIZE ortam değişkenlerini olarak tanımlayabilirsiniz.

Eğer NGINX gibi bir proxy sunucu kullanıyorsanız ve dosya yükleme limitini artırmak istiyorsanız, NGINX yapılandırma dosyasına aşağıdaki ayarı eklemeniz gerekmektedir:

http {
  ...
  client_max_body_size 70M; # 70MB dosya limiti
  ...
}
bilgi

Ortam Değişkenleri

Deployment işlemleri veri bütünlüğünün sağlanması amacıyla senkron olarak yapılmaktadır. WORKER_DEPLOYMENT_TIMEOUT parametresi, API Manager üzerinden veya Management API ile yapılan deploy işleminin kaç saniye sonra zaman aşımına uğrayacağını ifade eder.

env:
  - name: WORKER_DEPLOYMENT_TIMEOUT
    value: '120'

API Manager için Kubernetes Servis oluşturun:

vi apinizer-manager-service.yaml
apimanager-service.yaml — API Manager Service
apiVersion: v1
kind: Service
metadata:
  name: apimanager
  namespace: apinizer
  labels:
    app: apimanager
spec:
  selector:
    app: apimanager
  type: NodePort
  ports:
    - name: http
      port: 8080
      nodePort: 32080
kubectl apply -f apinizer-manager-deployment.yaml
kubectl apply -f apinizer-manager-service.yaml
bilgi

API Manager Kubernetes üzerinde deploy olurken manager isminde ve NodePort tipinde bir Kubernetes servisi oluşturur. Bu servis kubernetes dışından API Manager'a erişim için gereklidir. Ancak sizi bu servisi silip Ingress veya kurumunuzda bağlantı yöntemi için hangi yapıyı kullanıyorsanız ona göre uyarlayabilirsiniz.

Bu işlem sonrasında oluşturulan pod'u takip etmek ve logunu incelemek için aşağıdaki ilk kodu çalıştırıp pod ismi alınır ve ikinci kodda kullanılır.

kubectl get pods -n apinizer
kubectl logs <PODADI> -n apinizer
uyarı

Apinizer imajları Kubernetes ortamına deploy edildikten sonra Apinizer tarafından size verilen Lisans Anahtarını veri tabanına eklemeniz gerekir.

API Manager lisans anahtarının girilmesi​

Apinizer tarafından size verilen Lisans Anahtarını aşağıdaki gibi bir .js dosyasında güncelleyip veri tabanındaki lisans bilgisi güncellenebilir.

vi license.js
db.general_settings.updateOne(
  {"_class":"GeneralSettings"},
  { $set: { licenseKey: '<YOUR_LICENSE_KEY>'}}
)

Oluşturulan license.js MongoDB sunucusu üzerinde çalıştırılır. Matched = 1 şeklinde bir sonuç görülmesi beklenir.

mongosh mongodb://<MONGODB_IP>:<MONGO_PORT>/<MONGO_DBNAME> --authenticationDatabase "admin" -u "apinizer" -p '<MONGO_PASSWORD>' < license.js

Kurulum işlemi başarılı olduysa aşağıdaki adresten Apinizer API Manager (Yönetim Konsolu'na) erişebilirsiniz.

http://<K8S_ANY_WORKER_IP>:32080

Varsayılan Kullanıcı Adı: admin

Varsayılan Kullanıcı Parola: Apinizer destek ekibinden yardım isteyin.

uyarı

Apinizer Yönetim Konsoluna ilk girişiniz sonrasında şifrenizi değiştirmeniz önerilir.

Parola Değiştir Sayfası
Parola Değiştir sayfası - İlk giriş sonrası şifre değiştirme ekranı
not

HTTPS/SSL ile Apinizer Manager'ı çalıştırmak istiyorsanız — TLS sertifikası, JKS/PKCS12 dönüşümü, K8s Secret oluşturma ve SSL etkin Deployment YAML örneği için sayfanın alt kısmındaki API Manager'ı SSL ile Başlatmak sekmesine bakın. HTTPS opsiyoneldir; production'da TLS önerilir ancak PoC ortamında HTTP de çalışır.

Sıradaki Adım — Gateway Kurulumu (Zorunlu)​

API Manager kurulumu ve Lisans Anahtarı tanımı tamamlandığında Yönetim Konsoluna giriş yapabilirsiniz. Sıradaki adım Gateway kurulumu ve environment tanımıdır — bu adım zorunludur; Apinizer'ın asıl API Gateway'i bu modüldür ve Manager üzerinden en az bir environment olarak tanımlanmalıdır. Cache, Integration ve API Portal modülleri opsiyoneldir ve aşağıdaki sekmelerden bağımsız olarak kurulabilir. Önerilen sıra: Gateway → Cache → Integration → API Portal.

Apinizer'in en önemli bileşenidir. İstemcilerden gelen isteklerin karşılandığı, Politika Uygulama Noktası (Policy Enforcement Point) olarak görev yapan, isteği tanımlanmış politikalara göre işleyip backend API/servise yönlendiren modüldür. Gateway kurulumu zorunludur ve Manager üzerinden en az bir Gateway tanımlanmalıdır.

Gateway iki şekilde tanımlanabilir:

  • Managed Gateway — Apinizer hedef Kubernetes cluster'ı yönetir; Manager UI üzerinden environment oluşturulduğunda namespace, RBAC, Deployment, Service ve secret kopya işlemlerini Apinizer otomatik yapar.
  • Remote Gateway — Gateway'in çalışacağı cluster Apinizer yönetiminde değildir. Operatör manuel olarak YAML manifest'lerini deploy eder ve Manager'a bağlantı adreslerini "Remote Gateway" olarak tanımlar.

Managed Gateway Nedir?​

Apinizer'ın Kubernetes cluster'ında hem Yönetim hem Provisioning rolünü üstlendiği modeldir. Manager UI'dan yeni bir Gateway environment oluşturduğunuzda Apinizer:

  • Hedef namespace'i oluşturur
  • Gerekli Role, ServiceAccount ve RoleBinding'leri uygular
  • Gateway ve (varsa) Cache Deployment'larını yayar
  • HTTP/HTTPS Service'leri ve isteğe bağlı NodePort'ları açar
  • MongoDB secret'ını hedef namespace'e kopyalar
  • Pod sayısını, JVM parametrelerini, kaynak limitlerini UI üzerinden kontrol etmenizi sağlar

Bu model PoC'den production'a en hızlı yol olarak önerilir. Manuel YAML hazırlığı yoktur.

Önkoşullar​

API Manager çalışır durumda

API Manager'a admin kullanıcısı ile giriş yapılmış olmalı. Eğer Manager kurulu değilse yukarıdaki API Manager Kurulumu bölümünden devam edin.

Apinizer Kubernetes yönetim modu aktif

System Settings → General Settings'te "Apinizer üzerinden Kubernetes yönetimi" seçeneği işaretli olmalı. Bu seçenek kapatıldığında Manager sadece Remote Gateway oluşturabilir.

Cluster RBAC'ı uygulanmış

Manager'ın hedef cluster'a deploy yapabilmesi için API Manager Kurulumu adımındaki apinizer-role.yaml ve apinizer-manager-role.yaml (cluster-wide) uygulanmış olmalı.

Docker imajlarına erişim

Cluster, apinizercloud/worker:<APINIZER_VERSION> ve apinizercloud/cache:<APINIZER_VERSION> imajlarını çekebilmeli (internet veya internal registry üzerinden).

Yeni Gateway Oluşturma​

Manager UI'da Sunucu Yönetimi → Gateway Runtime'ları sayfasında Yeni butonuna tıklayın. Açılan form aşağıdaki bölümleri içerir.

Managed Gateway Environment oluşturma formu

1. Platform Seçimi​

İlk adım hangi platformda Gateway çalıştıracağınızı seçmektir.

SeçenekAçıklama
KubernetesGateway Kubernetes cluster'ında pod olarak çalışır. Apinizer (Managed) veya operatör (Remote) tarafından yönetilebilir.
Sanal Sunucu / Docker (Standalone)Gateway bare-metal Linux veya Docker container olarak çalışır. Bu durumda her zaman Remote olarak tanımlanır.

Managed Gateway için Kubernetes seçin.

2. Yönetim Tipi​

SeçenekAçıklama
Apinizer Tarafından Yönetilen (Managed)Apinizer Manager UI tüm Kubernetes nesnelerini otomatik oluşturur.
Remote GatewayOperatör manuel YAML deploy eder; Manager sadece bağlantı bilgilerini tutar.

Bu sekmede Apinizer Tarafından Yönetilen seçili kabul edilir.

3. Temel Bilgiler​

AlanAçıklamaValidation
Ortam TipiDEV, TEST, PROD vb. ortam sınıflandırması.Zorunlu
İletişim Protokolü TürüHTTP, HTTPS, gRPC, WebSocket. Tek environment'ta tek protokol türü çalışır; karışık protokol için ayrı environment'lar oluşturun.Zorunlu
Ortam Adı (Name)Gateway environment'ının görüntülenecek adı. Kubernetes namespace olarak da bu kullanılır.a-z 0-9 ve - karakterleri; 3-64 karakter; eşsiz
Ortam Anahtarı (Environment Key)API URL'lerinin path prefix'i olarak da kullanılır (örn: /test/...).a-zA-Z - karakterleri; 3-24 karakter; eşsiz
Erişim Adresi (Access URL)Bu Gateway'e dış dünyadan erişim için kullanılacak public URL (Load Balancer / Ingress / NodePort önündeki host).Zorunlu
AçıklamaOperatör notları.Opsiyonel

4. Node Yönetimi (Node List)​

Gateway pod'larının çalışacağı Kubernetes node'larını sınırlamak için nodeSelector/nodeAffinity listesi belirleyebilirsiniz. Boş bırakılırsa Kubernetes scheduler default davranışı uygular.

ipucu

Yüksek trafikli ortamlarda Gateway'i adanmış node'larda çalıştırmak gürültülü komşu (noisy neighbor) etkisini azaltır.

5. Gateway Kaynak Yapılandırması​

AlanAçıklamaVarsayılan
Replica CountAynı anda çalışacak Gateway pod sayısı. Production için ≥ 2 önerilir.1
CPU LimitPod başına CPU limit (core).4
Memory LimitPod başına memory limit.4
Memory UnitMi / Gi.Gi

CPU değeri değiştiğinde Apinizer JVM tuning parametrelerini (tuneWorkerThreads, tuneIoThreads, vb.) otomatik hesaplayıp Ek Değişkenler tablosuna yansıtır.

6. Host Aliases​

Gateway pod'larının /etc/hosts'una eklenecek IP ↔ hostname eşlemeleri. Backend'in DNS'i çözmeyen kapalı bir ortamda çalışıyorsa veya hardcoded IP/host eşleştirmesi gerekiyorsa burada tanımlayın. Bu alan yalnızca Managed Gateway'de UI üzerinden tanımlanır; Remote Gateway'de operatör manifest içinde hostAliases bloğunu kendisi yazar.

Ortamı Yayınlama (Publish)​

Form doldurulduktan sonra Oluştur butonuna basın. Apinizer:

  1. Hedef namespace'i oluşturur (Ortam Adı = namespace adı)
  2. RBAC, ServiceAccount, Deployment, Service'leri uygular
  3. MongoDB secret'ını namespace'e kopyalar
  4. Pod'ların Ready durumuna geçmesini bekler
  5. Environment'ı published olarak işaretler

Yayım sonrası Manager → Gateway Runtime'ları sayfasında ortamı görebilir, API Proxy'leri bu ortama deploy edebilirsiniz.

bilgi

Detaylı Gateway Runtime yönetimi, JWT token doğrulama anahtarı, metrik monitörü ve diagnostics için → Gateway Runtime'ları sayfasına bakın.

Ortak Ayarlar (Her İki Yöntem İçin)​

Managed veya Remote ayrımından bağımsız olarak Manager UI üzerinden Gateway environment formunda doldurulan aşağıdaki alanlar, her iki yöntem için de aynı şekilde geçerlidir. Bu bölüm form üzerinde Managed Gateway ve Remote Gateway için ortak görüntülenen alt-bölümleri açıklar.

Yönetim API Erişim Endpoint'leri (Management API Access Endpoints)​

not

Bu bölüm opsiyoneldir — hem Managed hem Remote Gateway için form üzerinde zorunlu değildir. Ancak Gateway'in en doğru şekilde çalışabilmesi (proxy yayım, sağlık kontrolü, diagnostics) için en az bir endpoint tanımlamanız şiddetle önerilir. Tanım yapılmadığında Manager Gateway pod'larına bağlanamaz ve yayım/izleme işlemleri başarısız olur.

Bu endpoint'ler Apinizer Yönetim Konsolu'nun Gateway pod'larına proxy yayım (deploy), sağlık kontrolü (health check) ve diagnostics için bağlandığı adreslerdir. Form üzerinde Gateway ve Cache Yönetim API'si Erişim URL'leri başlığı altında bir tablo olarak görünür.

Her endpoint girişi üç alandan oluşur:

AlanAçıklamaÖrnek
Ad (Name)Endpoint'in tanımlayıcı adı; çoklu cluster / DR site ayrımı için kullanılır.Production Cluster, DR Site, Region-EU
Gateway Yönetim API'si Erişim URL'siGateway Management API'sine HTTP/HTTPS erişim adresi.http://gateway-management-api-http-service.prod.svc.cluster.local:8091
Cache Yönetim API'si Erişim URL'si(Varsa) Cache Management API'sine erişim adresi.http://cache-http-service.apinizer-cache.svc.cluster.local:8090

Çoklu endpoint senaryoları:

  • Multi-region / DR: Birden fazla cluster'da çalışan Gateway için her cluster ayrı bir endpoint olarak tanımlanır.
  • HA setup: Aynı Gateway için redundant management URL'leri.
  • Multi-cluster: Manager farklı bir cluster'da, Gateway başka cluster'da; her hedef cluster için ayrı endpoint girilir.

Birden fazla endpoint tanımlandığında, Manager'ın bir API Proxy deploy işleminde hangi endpoint'i kullanacağı environmentClusterName Ek Değişkeni (Additional Variable) üzerinden belirlenir. Bu değişken Gateway pod'unun hangi cluster'a ait olduğunu işaretler; Manager deploy sırasında bu cluster adına eşleşen endpoint'i seçer.

Cross-namespace iletişim için Kubernetes service discovery formatı kullanılır:

<service-name>.<namespace>.svc.cluster.local:<port>
uyarı

Tanımlanan her endpoint hem Gateway hem Cache Management API URL'i içermelidir (Cache yoksa Cache alanı boş bırakılabilir). Bu adresler Apinizer Manager'dan ağ üzerinden erişilebilir olmalı — aksi halde proxy publish, health check ve diagnostics başarısız olur.

bilgi

Bu endpoint'ler API Proxy trafiği için kullanılan ana HTTP/HTTPS servislerinden ayrıdır. Yalnızca yönetim işlemleri (konfigürasyon push, health, izleme) için kullanılır.

Ortam Yayımlama Erişimi (Environment Publishing Access)​

Bu alt-bölüm, bu Gateway environment'ına hangi projelerin API Proxy'lerini deploy edebileceğini kısıtlar. Form üzerinde Projelerden Ortama Erişilebilirlik başlığı altında çoklu seçim listesi olarak görünür.

Davranış:

  • Boş bırakılırsa: Tüm projeler bu environment'a deploy edebilir (varsayılan).
  • Bir veya daha fazla proje seçilirse: Sadece listedeki projeler bu environment'a deploy edebilir.
  • Sonradan eklenen yeni projeler otomatik olarak listeye dahil edilmez — operatörün manuel olarak eklemesi gerekir.
ipucu

Bir proje seçildiğinde, sadece o proje içindeki API Proxy / API Proxy Group / Credential / Connection nesneleri bu Gateway environment'a deploy edilebilir. Bu, ortam izolasyonu (ör. prod ortamına yalnızca prod projelerinin erişmesi) için temel mekanizmadır.

uyarı

Daha önce listede yer alan bir projeyi listeden çıkardığınızda, o projeye ait API Proxy, API Proxy Group, Credential ve Connection nesneleri bu environment'tan otomatik olarak undeploy edilir. İşlem geri alınamaz; undeploy edilen nesneler yeniden deploy edilmek istendiğinde manuel olarak yayınlanmalıdır.

API Proxy Trafik Log Konnektörleri (API Traffic Log Connectors)​

Bu Gateway environment'ı içindeki API Proxy'lerin trafik log'larının yazılacağı konnektörleri tanımlar. Form üzerinde API Trafik Log Konnektörleri başlığı altında görünür; birden fazla konnektör eklenebilir, her birinin enabled / disabled toggle'ı vardır.

Apinizer üzerinden akacak trafik loglarının nereye gönderileceği bilgisinin Apinizer'a tanımlanması gerekmektedir. Bu tanımlama Sistem Ayarları → Bağlantı Yönetimi sayfasındaki konnektörler aracılığıyla yapılır. API Trafik ve API Analitik verilerinizi kendi log sistemleriniz ile yönetecekseniz size uygun entegrasyon ayarlarından uygun gördükleriniz tanımlanabilir. Eğer özel bir seçiminiz yoksa Apinizer'ın Analitik ve İzleme kabiliyetlerinden tam manada yararlanabilmeniz için veri yönetimi de Apinizer'dan ayarlanacak şekilde bir Elasticsearch konnektörü kullanabilirsiniz.

Desteklenen konnektör tipleri:

uyarı

Hiçbir Elasticsearch konnektörü atanmazsa form üzerinde sarı uyarı çıkar: API Trafik log'ları Elasticsearch'e gönderilmez ve log yönetimi tamamen operatöre kalır. Apinizer'ın Dashboard / Log Görüntüleyici / Raporlama özelliklerinin çalışabilmesi için en az bir Elasticsearch konnektörü tanımlanması önerilir.

Ön koşul: Konnektör seçilebilmesi için önce Sistem Ayarları → Bağlantı Yönetimi sayfasından konnektör tanımı yapılmış olmalıdır.

Detay için: Gateway Ortamlarına Konnektör Eklenmesi.

Protokol ve Güvenlik Ayarları (Protocol and Security Settings)​

Gateway'in gelen verileri kabul ederken kullanacağı ağ protokolleri (HTTP, HTTPS) ve zorunlu güvenlik mekanizmalarını (mTLS, Keystore/Truststore) tanımlar. Form üzerinde Protokol ve Güvenlik Ayarları başlığı altında görünür.

HTTP / HTTPS / mTLS Aktivasyonu​

Alani18n KeyAçıklama
Gateway'in HTTP protokolü etkinhttpEnabledGateway HTTP üzerinden istek kabul eder. Varsayılan olarak seçili gelir.
Gateway'in SSL protokolü etkinhttpsEnabledGateway HTTPS üzerinden istek kabul eder. Açıldığında Keystore/Truststore dosyaları yüklenmelidir.
mTLS EtkinmtlsEnabledSadece HTTPS aktifken ve gRPC haricinde kullanılabilir. Etkinleştirildiğinde client sertifika doğrulaması yapılır.

Sertifika Dosyaları (HTTPS aktifse)​

HTTPS aktif edildiğinde aşağıdaki sertifika alanları doldurulur:

AlanFormatAçıklama
Keystore.jks veya .pfxGateway TLS sunucu sertifikası.
Truststore.jks veya .pfxGüvenilen client / CA sertifikaları (mTLS için zorunlu).
Keystore ŞifresistringŞifreli saklanır (UI'da gizli giriş).
Truststore ŞifresistringŞifreli saklanır (UI'da gizli giriş).

Kubernetes Servis Tanımlama (defineServiceInKubernetes)​

Form üzerinde Kubernetes'te servis tanımlayın başlığı altında görünür. Apinizer'ın Gateway için Kubernetes Service nesnelerini otomatik oluşturmasını kontrol eder.

Seçeneki18n KeyAçıklama
Gateway Yönetim API HTTP ServisihttpServiceForManagementAPIEnabled (createHttpServiceForGatewayManagementAPI)"Gateway Servisi'nin HTTP Portunu (8091), özel bir ClusterIP Servisi aracılığıyla dahili küme erişimine aç" — Manager'ın Gateway pod'larına konfigürasyon güncellemesi için.
Gateway Yönetim API HTTPS ServisihttpsServiceForManagementAPIEnabled (createHttpsServiceForGatewayManagementAPI)"Gateway Servisi'nin HTTPs Portunu (8443), özel bir ClusterIP Servisi aracılığıyla dahili küme erişimine aç" — yönetim trafiği için TLS gerektiğinde.
Gateway Servisi NodePort (HTTP)unsecureNodePortEnabled (createServiceForGatewayServiceAccess)"Gateway Servis erişimi için servis oluştur" — Gateway external HTTP trafiği için NodePort.
Gateway Servisi Güvenli NodePort (HTTPS)secureNodePortEnabled (createSecureServiceForGatewayServiceAccess)"Gateway Servis erişimi için güvenli servis oluştur" — Gateway external HTTPS trafiği için NodePort.

NodePort port aralığı: 30080-32767.

not

Bu alt-bölüm sadece Managed Gateway için anlamlıdır. Remote Gateway seçiminde Apinizer Kubernetes Service nesnelerini yönetmez — operatör Service YAML'larını manuel olarak yazar ve kubectl apply ile cluster'a uygular. Remote Gateway'de bu seçeneklerin etkisi yoktur.

not

Gateway'in ek değişkenleri (JVM tuning, gRPC, WebSocket, CORS, güvenlik, vb.) ve konfigürasyon ayarları (System Settings, Backup, vb.) için Gateway Ayarları sayfasına bakın.

bilgi

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.

uyarı

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.

bilgi

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: tuneWorkerThreads ile aynı)
  • tuneAsyncExecutorMaxPoolSize: Oluşturulabilecek maksimum thread sayısı (varsayılan: tuneWorkerMaxThreads ile 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)
uyarı

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.

ipucu

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.

TierCPUtuneIoThreadstuneWorkerThreadstuneWorkerMaxThreadstuneBacklogtuneMaxConcurrentRequest
W1121282562048500
W2242565124096750
W448512102481923000
W8816153630721638410000

Routing Bağlantı Havuzu (tuneRoutingConnectionPoolMaxConnectionPerHost / tuneRoutingConnectionPoolMaxConnectionTotal):

TierMax Conn/HostMax Conn TotalES Max Conn/Host
W12505008
W2500100016
W41000200032
W820004000128
uyarı

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.

not

Gateway'in ek değişkenleri (JVM tuning, gRPC, WebSocket, CORS, güvenlik, vb.) ve konfigürasyon ayarları (System Settings, Backup, vb.) için Gateway Ayarları sayfasına bakın.

Opsiyonel Modüller​

Aşağıdaki modüller opsiyoneldir; ihtiyaca göre seçilen sırada kurulabilir. Önerilen sıra: Cache → Integration → API Portal. API Manager'ı HTTPS/SSL ile çalıştırmak için en alttaki SSL sekmesine bakın.

Apinizer Cache Kurulumu​

API Cache Server, dağıtılmış önbellekte saklayarak hem bileşenlerin paylaştığı verileri yönetir, hem de performans iyileştirmesi sağlar. Hazelcast tabanlı bir cluster olarak çalışır; Worker'lar quota, OIDC token cache, circuit breaker durumları ve benzeri paylaşılan veriler için Cache'e bağlanır.

Cache modülü opsiyoneldir — kurulmadığı durumda bu özellikleri kullanan politikalar devre dışı kalır. Production'da en az bir Cache Server tanımlanması şiddetle önerilir.

Cache iki şekilde tanımlanabilir:

  • Managed Cache (Apinizer Yönetiminde) — Manager UI üzerinden tek-tıkla; Apinizer namespace, deployment, service ve secret kopya işlemlerini otomatik yapar.
  • Remote Cache Server (Manuel Deploy) — operatör manuel olarak YAML deploy eder; Manager sadece Cache Management API URL'lerini tutar.
uyarı

Eğer Cache Server standalone (Docker, Sanal Sunucu veya bare-metal Linux) kurulduysa, mutlaka Remote Cache Server seçeneğini seçerek Manager'a register etmelisiniz. Standalone Cache'ler Manager tarafından deploy edilemez; sadece bağlantı bilgileri (Cache Management API URL) kaydedilir.

Managed Cache Nedir?​

Apinizer'ın Cache Server'ı Kubernetes cluster'ında otomatik olarak provision ettiği modeldir. Manager UI'dan yeni bir Cache Server oluşturduğunuzda Apinizer:

  • Hedef namespace'i oluşturur (veya mevcut bir namespace'i kullanır)
  • Cache Server Deployment'ını uygular (Hazelcast-based cluster)
  • HTTP (8090) ve Hazelcast (5701) Service'lerini açar
  • MongoDB secret'ını hedef namespace'e kopyalar
  • Pod sayısını, JVM parametrelerini, kaynak limitlerini UI'dan kontrol etmenizi sağlar

Apinizer'ın Worker'ları (Gateway pod'ları) bu Cache'e quota sayaçları, OIDC token cache, circuit breaker durumları ve circuit-breaker open state gibi paylaşılan veriler için bağlanır.

Önkoşullar​

API Manager çalışır durumda

Manager'a admin kullanıcısı ile giriş yapılmış olmalı.

Apinizer Kubernetes yönetim modu aktif

System Settings → General Settings'te "Apinizer üzerinden Kubernetes yönetimi" işaretli olmalı.

Cluster RBAC uygulanmış

API Manager Kurulumu adımındaki apinizer-role.yaml ve apinizer-manager-role.yaml (cluster-wide) uygulanmış olmalı.

Docker image erişimi

Cluster, apinizercloud/cache:<APINIZER_VERSION> imajını çekebilmeli.

Yeni Cache Server Oluşturma​

Manager UI'da Sunucu Yönetimi → Dağıtık Cache sayfasına gidin ve Yeni (+) butonuna tıklayın.

Managed Cache Server oluşturma formu

1. Tipi (Type) — Yönetim Modeli​

Seçeneki18n KeyAçıklama
Apinizer Tarafından YönetilenmanagedByApinizerApinizer namespace, deployment, service ve tüm gerekli K8s kaynaklarını otomatik oluşturur.
Uzak Cache ServerremoteCacheManuel deploy edilmiş Cache'e bağlanır. (Bu sub-tab'da Managed seçilir.)

2. Ad (Name)​

Cache Server'ın görüntülenecek adı. Validation: eşsiz olmalı.

3. Namespace Yapılandırması​

SeçenekAçıklama
Yeni Namespace Oluştur (createNewNamespace)Apinizer girilen isimle yeni namespace oluşturur. Validation: RFC 1123 label (3-63 karakter, lowercase alphanumeric + -, alfanumerik karakterle başlayıp bitmeli). Örnek: my-cache-ns, prod-cache, 123-abc.
Mevcut Namespace Kullan (useExistingNamespace)Cluster'da var olan bir namespace listeden seçilir.

4. Cache Yönetim API Erişim URL'leri (Cache Management API Access URLs)​

API Manager ve Gateway'in bu Cache Server ile iletişim kuracağı endpoint(ler). Tabloda her satır için:

AlanAçıklamaÖrnek
Ad (Name)Endpoint için tanımlayıcı isimProduction, DR Site
Cache Server Erişim URL'siCache Server health-check ve API endpoint adresihttp://cache-http-service.prod.svc.cluster.local:8090
Durum (Status)Otomatik bağlantı kontrolü — Reachable / Not Reachable / Checking...
ipucu

Multi-cluster / DR senaryoları için birden fazla URL eklenebilir. Form üzerinde anlık Test API Connection butonu ile bağlantı doğrulaması yapılır.

5. Cache Kaynak Yapılandırması (Cache Resource Configuration)​

Alani18n KeyVarsayılanAçıklama
Replica SayısıreplicaCount1Cache pod sayısı. Production için ≥ 2 önerilir (Hazelcast cluster).
CPUcpu1Pod başına CPU limit (core).
Bellekmemory1Pod başına memory limit.
Bellek BirimimemoryUnitGiMi / Gi.

6. Ek Değişkenler (Additional Variables)​

Cache pod'una geçirilecek ek environment değişkenleri. Tabloda Anahtar (Key) ve Değer (Value) sütunları. Önemli ön-tanımlı değişkenler:

Tomcat Ayarları (Cache HTTP Management API için):

  • SERVER_TOMCAT_MAX_THREADS (1024)
  • SERVER_TOMCAT_MIN_SPARE_THREADS (512)
  • SERVER_TOMCAT_ACCEPT_COUNT (512)
  • SERVER_TOMCAT_MAX_CONNECTIONS (1024)
  • SERVER_TOMCAT_CONNECTION_TIMEOUT (20000 ms)
  • SERVER_TOMCAT_KEEPALIVE_TIMEOUT (60000 ms)
  • SERVER_TOMCAT_MAX_KEEPALIVE_REQUESTS (10000)
  • SERVER_TOMCAT_PROCESSOR_CACHE (512)

Hazelcast Cluster Ayarları:

  • HAZELCAST_IO_WRITE_THROUGH (false)
  • HAZELCAST_MAP_LOAD_CHUNK_SIZE (10000)
  • HAZELCAST_MAP_LOAD_BATCH_SIZE (10000)
  • HAZELCAST_CLIENT_SMART (true)
  • HAZELCAST_MAPCONFIG_BACKUPCOUNT (1)
  • HAZELCAST_MAPCONFIG_READBACKUPDATA (false)
  • HAZELCAST_MAPCONFIG_ASYNCBACKUPCOUNT (0)
  • HAZELCAST_OPERATION_RESPONSEQUEUE_IDLESTRATEGY (block)
  • HAZELCAST_MAP_WRITE_DELAY_SECONDS (5)
  • HAZELCAST_MAP_WRITE_BATCH_SIZE (100)
  • HAZELCAST_MAP_WRITE_COALESCING (true)
  • HAZELCAST_MAP_WRITE_BEHIND_QUEUE_CAPACITY (100000)

Diğer:

  • CACHE_QUOTA_TIMEZONE (+03:00) — Quota policy hesaplaması için
  • JAVA_OPTS — JVM heap parametreleri
  • CACHE_SERVICE_NAME — Hazelcast service discovery için (default: cache-hz-service)
uyarı

HAZELCAST_OPERATION_RESPONSEQUEUE_IDLESTRATEGY değerini "backoff" yaparsanız: Cache pod'u CPU limitinin %90-100'ünü sürekli kullanacaktır. %5-10 performans artışı sağlar ancak CPU tüketimi yüksektir. Production'da dikkatli kullanın.

7. Kubernetes'te Servis Tanımlayın (Define the service in Kubernetes)​

createK8sService checkbox ile aktif edilir. Bu seçenek şiddetle önerilir — Cache Server'a Manager ve Gateway pod'larından erişim için zorunludur.

Alani18n KeyAçıklama
Servis AdıserviceNameK8s Service objesi adı (örn: cache-http-service)
Servis TipiserviceTypeCluster IP (default, küme içi erişim) veya Node Port (dış erişim)
NodePortnodePortSadece NodePort tipinde zorunlu (30080-32767 aralığı)
bilgi

ClusterIP Cache ve Gateway/Manager arasındaki dahili iletişim için en iyisidir. Çoğu durumda NodePort gerekmez.

8. Host Alias Yapılandırması (Host Alias Configuration)​

Cache pod'larının /etc/hosts'una eklenecek IP ↔ hostname eşlemeleri. DNS'te olmayan host adlarını çözümlemeniz gerektiğinde kullanılır. Tabloda IP Adresi ve Host İsimleri sütunları.

9. Node İsim Listesi Yapılandırması (Node Name List Configuration)​

Cache pod'larının zamanlanacağı Kubernetes node'larını sınırlamak için nodeSelector / nodeAffinity belirleyin. Boş bırakılırsa Kubernetes scheduler default davranışı uygular.

Yayınlama (Publish)​

Form doldurulduktan sonra Publish butonuna basın. Apinizer:

  1. Hedef namespace'i (varsa kullanır, yoksa oluşturur)
  2. MongoDB secret'ını kopyalar
  3. Cache Deployment'ı uygular
  4. HTTP + Hazelcast Service'leri oluşturur
  5. Pod'ların Ready durumuna geçmesini bekler
  6. Cache Server'ı Published olarak işaretler

Yayım sonrası Gateway environment'ları otomatik olarak bu Cache'i kullanmaya başlar.

bilgi

Detaylı Cache yönetimi (monitoring, diagnostics, restart) için → Dağıtık Cache sayfasına bakın.

En son tarihinde güncellendi