Kubernetes'e dağıtım

Tek bir helm install, durumsuz Orbtrace sunucusunu (replika + HPA) ve opsiyonel yedek CronJob'larını çalıştırır ve ihtiyaç duyduğu üç veri deposundan ikisini varsayılan olarak — Postgres ve Valkey — küme içinde gömülü kurar (ikisi de bir VM ya da yönetilen servise yönlendirilebilir). Telemetri deposu (Doris) ile Collector, her zaman sizin çalıştırdığınız iki parçadır; chart yalnızca onlara bağlanır.

Üç veri deposunun her biri küme içinde gömülü çalıştırılabilir ya da küme dışında sizin çalıştırdığınız bir şeye yönlendirilebilir. Kutudan çıktığı haliyle neyi alacağınız ve neyi sizin sağladığınız tam olarak şöyle:

Orbtrace'in çalışmak için ihtiyaç duydukları

Orbtrace'in dört çalışma-zamanı bağımlılığı vardır. Chart ilk ikisini gömülü kurar; son ikisini her zaman siz sağlarsınız:

• Postgres 18 + pgvector — ayarlar, kullanıcılar ve RCA vektör deposu. ("pgvector", yalnızca vector uzantısı etkinleştirilmiş Postgres'tir — kurulacak egzotik bir şey yok.)
• Valkey (ya da herhangi bir Redis-uyumlu sunucu) — önbellek. Orbtrace ona Redis protokolüyle konuşur, dolayısıyla Valkey yerine düz Redis de çalışır.
• Apache Doris — log, trace ve metrikler için telemetri deposu. Chart'a göre her zaman haricidir.
• Bir OpenTelemetry Collector — toplama. Orbtrace OTLP'yi kendisi almaz; bir Collector telemetrinizi Doris'e yazar. Bkz. Entegrasyon desenleri.

Küme için ayrıca Helm 3.8+, hızlı SSD destekli bir StorageClass ve — bir Doris BE'nin çalıştığı her node'da — kernel ayarları (vm.max_map_count ≥ 2000000, swap kapalı) gerekir. Tam Doris gereksinimleri Doris kurulumu sayfasındadır.

Önerdiğimiz mimari

Üretim için, durumlu veritabanlarını Kubernetes dışında — DBA'larınızın yönettiği VM'lerde ya da yönetilen servislerde — çalıştırmanızı ve Helm'in yalnızca durumsuz uygulamayı kurmasını öneririz:

Veritabanlarını neden küme dışında tutmalı?

Postgres ve Doris, yeniden oluşturamayacağınız veriyi tutar — ayarlarınızı ve tüm telemetrinizi. Kubernetes, serbestçe silip yeniden kurabileceğiniz durumsuz uygulamalar için tasarlanmıştır; veritabanları ise tam tersidir. Onları küme dışında tutmak bu veriyi korur ve işletmeyi kolaylaştırır:

• Yanlış bir helm uninstall verinizi silemez. Bir veritabanı küme içinde çalışırken, diski (bir PersistentVolumeClaim) Helm release'ine aittir — release'i ya da namespace'i silin, volume ve içindeki tüm telemetriniz de onunla birlikte silinebilir. VM'de ya da yönetilen serviste çalışan bir veritabanı hiçbir Helm komutunun erişemeyeceği yerdedir.
• Day-2 veritabanı işi ait olduğu yerde kalır. Yedekler, sürüm yükseltmeleri, failover ve tuning — DBA'larınızın (ya da RDS gibi yönetilen bir servisin) zaten yaptığı rutin veritabanı işleridir. Küme içinde gömülüyken bu iş Kubernetes ekibinize düşer ve her veritabanı yeniden başlatması ya da yükseltmesi artık aynı node'lar için uygulamayla yarışır.
• OpenShift'te güvenlik-politikası sürtüşmesi olmaz. OpenShift'in varsayılan restricted-v2 politikası, veritabanı imajlarının beklediği çoğu şeyi engeller (sabit kullanıcı ID'leri, volume sahipliği), bu yüzden gömülü bir veritabanının başlaması için bile ek geçici çözümler gerekir. Harici bir veritabanı bunu tümüyle aşar.

Valkey istisnadır. Yalnızca önbellek tutar — otomatik yeniden oluşturulan, kaybı sorun olmayan veri — dolayısıyla korunacak bir şey yoktur. Onu küme içinde gömülü bırakmak üretimde bile uygundur.

Uygulamayı harici çalışan depolara bağlamak için bunları my-values.yaml'ınıza koyun — chart'ın kendi varsayılanlarının üstüne katmanlanan, yalnızca değiştirdiğiniz anahtarları içeren küçük bir overrides dosyası (bkz. Helm ile kurun). Chart'ın values.yaml'ı otomatik tabandır; siz yalnızca değiştirdiklerinizi listelersiniz. Her <…>'yi kendi değerinizle değiştirin; gerisi olduğu gibi bırakabileceğiniz varsayılanlardır:

postgres:
  mode: external
  host: <postgres-host-unuz> # VM / yönetilen Postgres+pgvector, kümeden erişilebilir
  port: 5432 # varsayılan — yalnızca sizinki farklıysa değiştirin
  database: orbtrace # oluşturduğunuz DB — herhangi bir ad olur, bu yalnızca varsayılan
  username: orbtrace # oluşturduğunuz kullanıcı — o da sizin seçiminiz
  password: <postgres-parolanız> # ya da düz parola yerine existingSecret kullanın
 
# Valkey varsayılan olarak gömülü kalır (önerilir). Onu da dışarı almak için yorumu kaldırın:
# valkey:
#   mode: external
#   host: <valkey-ya-da-redis-host-unuz>
#   port: 6379
 
doris:
  mode: external # varsayılan — chart Doris'i hiçbir zaman çalıştırmaz
  host: <doris-fe-host-unuz> # VM / yönetilen / operatör Doris'inizin FE adresi
  queryPort: 9030 # varsayılan Doris MySQL query portu
  httpPort: 8030 # varsayılan Doris HTTP (Stream Load) portu

Kubernetes'e dağıtım adımları

Bunları sırayla izleyin:

1. Veri depolarını sağlayın — Postgres + pgvector ve Valkey'i getirin (gömülü, VM/yönetilen ya da Docker).
2. Doris kurulumu — chart'ın hiçbir zaman kurmadığı telemetri deposu (operatör, VM/yönetilen ya da değerlendirme için Compose).
3. Helm ile kurun — kimlik doğrulayın, değerleri düzenleyin, helm install ve doğrulayın.
4. OpenShift / OKD — OpenShift'teyseniz, SCC overlay'i ve node tuning.
5. Portlar ve erişim — Orbtrace'e nasıl erişilir ve herhangi bir port nasıl değiştirilir.

Orbtrace ayağa kalkınca telemetriyi bağlayın — Collector, kendiniz çalıştırdığınız iki parçanın sonuncusudur. Yeni bir OTel Collector kurun ya da Orbtrace'in dorisexporter'ını mevcut OTel pipeline'ınıza ekleyin (yeniden platformlamaya gerek yok). Her iki yol da, referans Collector yapılandırmasıyla birlikte, Entegrasyon desenleri sayfasındadır.

Yönetilen bir bulut kümesinde mi (EKS / AKS / GKE) çalışıyorsunuz? Sağlayıcıya özgü seçimler için Buluta dağıtım'a bakın.