Portlar ve erişim
Kubernetes'te Orbtrace'e nasıl eriştiğiniz ve herhangi bir portu nasıl değiştireceğiniz — 8080'deki uygulama, Collector'ınızın OTLP portları ve Doris/Postgres/Valkey portları.
Gerçekten açtığınız her adres sizin seçiminizdir — varsayılan port numaralarının hiçbiri, sisteme nasıl eriştiğinize sabit kodlanmış değildir:
| Port | Kime ait | Nasıl değiştirilir |
|---|---|---|
| 8080 | Orbtrace uygulaması + UI | Kubernetes'te 8080'i doğrudan yayınlamazsınız — Orbtrace'e kendi host adınız üzerinden Ingress / Route ile (443) erişirsiniz. Bunun yerine bir Service açarsanız, portu orbtrace.service.port'tur. (Docker Compose'da host portunu yeniden eşleyin, ör. 9000:8080.) |
| 4317 / 4318 | Sizin Collector'ınız (OTLP gRPC / HTTP) | Orbtrace'in portları değil — Orbtrace OTLP'yi hiç almaz. Bunları Collector'ınızın receiver yapılandırmasında seçersiniz. |
| 9030 / 8030 | Doris FE (MySQL query / HTTP) | Doris'inizin kullandığı porta yönlendirin: doris.queryPort ve doris.httpPort. |
| 5432 / 6379 | Postgres / Valkey (ya da Redis) | Harici olduğunda postgres.port / valkey.port. Gömülü olduğunda yalnızca küme içinden erişilir ve hiçbir zaman yayınlanmaz. |
Sabit olan tek değer, uygulamanın iç container portudur (8080) — Service ve Ingress'in arkasında durur ve doğrudan erişilmesi hiç gerekmez, o yüzden değiştirmek için bir sebep yoktur. Bir kullanıcının ya da uygulamanın bağlandığı her şey (host adınız, Collector'ınızın OTLP portları, Doris/Postgres/Valkey portlarınız) tamamen sizin kontrolünüzdedir.
Sağlık probe'ları (readiness / liveness)
Chart, Kubernetes probe'larını uygulamanın actuator endpoint'lerine bağlar — hem ayar yapmak hem de kendi harici izlemeniz için bilmeniz yararlıdır:
| Endpoint | Kim kullanır | Neyi içerir | Erişim |
|---|---|---|---|
/actuator/health/readiness | startup + readiness probe'ları | readinessState + Doris/Postgres bağlantısı — erişilemeyen bir veri deposu pod'u NotReady yapar (trafik ona yönlenmez) | anonim, yalnızca status |
/actuator/health/liveness | liveness probe'u | yalnızca livenessState — veri depoları bilinçli olarak hariçtir; bir Doris kesintisi uygulamayı asla restart-loop'a sokmaz | anonim, yalnızca status |
/actuator/health | sizin izlemeniz / curl kontrolleri | bileşik (composite) | anonim çağrılar yalnızca {"status":"UP"} görür; bileşen bazlı döküm kimlik doğrulaması ister (show-details: when-authorized) |
Probe endpoint'leri bilinçli olarak anonimdir — kubelet token taşıyamaz; kilitlenselerdi pod hiç Ready olamazdı. İç bilgi sızdırmazlar: host adları, sürümler ve bileşen detayları kimlik doğrulamasının arkasında kalır. Route/Ingress catch-all olduğu için dışarıdan da erişilebilirler; içerik yalnızca status olduğundan risk düşüktür, ama politikanız gerektiriyorsa /actuator/*'ı edge'de kapatın (Ingress path kuralı, ayrı bir Route path'i ya da WAF) — kubelet cluster içinden probe atmaya devam eder, etkilenmez.
Ayar. En çok ihtiyaç duyacağınız düğme ilk açılış bütçesidir: uygulama, web portunu açmadan önce tüm Doris şemasını uygular; startup probe'u bunu beklemek zorundadır. orbtrace.startupProbe.failureThreshold (varsayılan 60, ×10 sn = 10 dakika) bu bekleme süresidir — yavaş ya da çok büyük bir Doris için artırın. Diğer tüm kadanslar da aynı şekilde ayarlanabilir (chart ≥ 2.0.7): orbtrace.readinessProbe.* ve orbtrace.livenessProbe.*, her biri initialDelaySeconds / periodSeconds / failureThreshold / timeoutSeconds alır — ör. IOPS'u kısıtlı node'larda timeoutSeconds'ı, kısa Doris kesintileri pod'u rotasyondan çıkarmasın diye readinessProbe.failureThreshold'u artırın. Probe path'leri sabit uygulama endpoint'leridir. SMTP ve Quartz sağlık göstergeleri bileşikten bilinçli olarak çıkarılmıştır — bir mail sunucusu hıçkırığı pod'u düşüremez.