Buluta dağıtım
Orbtrace'i yönetilen bir Kubernetes kümesinde — EKS, AKS ya da GKE — Helm yolu ile ve bulutun yönetilen Postgres'i, önbelleği, deposu ve yük dengeleyicisiyle çalıştırın.
Yönetilen bir bulut kümesine dağıtım, birkaç sağlayıcıya özgü seçimle birlikte Kubernetes (Helm) yoludur: hangi yönetilen Postgres'i kullanacağınız, volume'ları hangi storage class'ın desteklediği ve trafiğin kümeye nasıl ulaştığı. Öneri her yerde aynıdır — durumlu veritabanlarını yönetilen servisler (ya da VM'ler) olarak çalıştırın ve Helm yalnızca durumsuz uygulamayı kursun.
Yönetilen kümede — Helm kurar
Bulut-yönetilen / VM'ler — bunları siz çalıştırırsınız
Her bulutta şekil aynıdır: uygulamalar OTLP'yi Collector'ınıza gönderir, o da Doris'e yazar; durumsuz Orbtrace uygulaması telemetriyi geri okur ve ayarları + önbelleğini yönetilen Postgres + gömülü Valkey'de tutar. Kümede yalnızca uygulama ve geçici önbellek yaşar — kaybedemeyeceğiniz veri (yönetilen Postgres, Doris) pod yaşam döngüsünün dışında kalır. [Veritabanlarını neden küme dışında tutmalı?](/docs/deploy-kubernetes#why-keep-the-databases-outside-the-cluster) gerekçesi her sağlayıcıda geçerlidir.
Aşağıda listelenen her yönetilen bulut Postgres'i pgvector uzantısını destekler; bu da Orbtrace'in RCA vektör deposu için ihtiyaç duyduğu tek şeydir — dolayısıyla yönetilen Postgres, üç bulutta da kolay, önerilen seçimdir.
| AWS | Azure | GCP | |
|---|---|---|---|
| Yönetilen Kubernetes | EKS | AKS | GKE |
| Yönetilen Postgres + pgvector | RDS for PostgreSQL 18 | Azure Database for PostgreSQL (Flexible Server) | Cloud SQL for PostgreSQL |
| Önbellek (opsiyonel — Valkey gömülü kalır) | ElastiCache (Valkey/Redis) | Azure Cache for Redis | Memorystore (Redis) |
| Ayarlanabilir-IOPS StorageClass | gp3 (iops/throughput yükseltin) | Premium SSD v2 | Hyperdisk Balanced |
| Ingress / TLS | AWS Load Balancer Controller (ALB) + ACM | Application Gateway (AGIC) ya da ingress-nginx | GKE Ingress (GCLB) + yönetilen sertifika |
| Doris | küme içi doris-operator ya da EC2 VM'lerde | küme içi doris-operator ya da Azure VM'lerde | küme içi doris-operator ya da GCE VM'lerde |
Sağlayıcınızı seçin — pratikte bu seçim bir özellik eksikliğinden değil, zaten nerede olduğunuzdan (mevcut bulut hesabı, DBA'lar ve TLS/sır araçları) çıkar; Orbtrace üçünde de aynı çalışır:
- AWS'ye dağıtım (EKS) — RDS + ACM + AWS Load Balancer Controller.
- Azure'a dağıtım (AKS) — Flexible Server + Key Vault + Application Gateway (AGIC).
- GCP'ye dağıtım (GKE) — Cloud SQL + bir ManagedCertificate ve readiness probe'undan sıfır-yapılandırmalı LB sağlık kontrolleri.
Her bulutta aynı olan üç şey
Sağlayıcıya özgü sayfalar yalnızca servis adları ve annotation sözdiziminde farklılaşır. Arkalarındaki kararlar her yerde aynıdır:
- Doris'i çalıştırmak size aittir. Yönetilen bulutların hiçbiri Apache Doris'i servis olarak sunmaz. Onu kümede doris-operator ile ya da sağlayıcı VM'lerinde (EC2 / Azure VM'leri / GCE) çalıştırıp
doris.host'u ona yönlendirin — bkz. Doris kurulumu. Node kernel ayarı (vm.max_map_count ≥ 2000000), Doris BE'nin indiği node'lar için geçerlidir. - Diski ayarlayın — varsayılan class, Doris BE için fazla yavaştır. Her sağlayıcının varsayılan SSD class'ı IOPS'u disk boyutuna bağlar ya da düşük tutar; BE compaction ise IOPS'a bağımlıdır. Her sayfa, sağlayıcının bağımsız-ayarlanabilir diskini (IOPS'u yükseltilmiş gp3, Premium SSD v2, Hyperdisk Balanced) kullanır — bu, yavaş bir kümenin açık ara en yaygın nedenidir.
- Blok volume'lar bölgeye kilitlidir. Bir EBS volume / Azure disk / zonal PD tek bir bölgede yaşar, dolayısıyla bir Doris BE pod'u yalnızca verisinin bulunduğu yerde çalışabilir. Her BE'yi tek bir bölgede tutun (ya da anti-affinity ile bölge başına bir BE havuzu); durumsuz uygulama serbestçe yayılır. Her sayfa bunun nasıl yapılacağını gösterir.
Sağlamadan önce boyutlandırın
Önce Kapasite planlama hesaplayıcısını çalıştırın — Doris FE/BE sayılarını, node başına vCPU/bellek ve diski döndürür; her sağlayıcı sayfasındaki node-group / node-pool şekilleri doğrudan bunu izler.