Kurulum
Topoloji gereksinimleri ve yayımlanmamış sınırlar
Yüksek erişilebilirliğin tek bir uygulama ayarı değil, paylaşılan veri ve platform bileşenleri tasarımı olduğunu değerlendirin.
Gerekli tasarım alanları
Paylaşılan PostgreSQL, ortak storage, session/topoloji, ingress, rollout ve platform bileşenleri birlikte ele alınmalıdır.
Chart'ta bulunan yapı taşları
Kaynak Helm chart varsayılan olarak 3 replica, 3–10 arası HPA, minAvailable 2 PodDisruptionBudget, 60 saniye termination grace, preStop gecikmesi ve hostname/zone topology spread alanlarını sunar. En az üç schedulable worker node ve Metrics Server gibi chart dışı ön koşullar ayrıca sağlanmalıdır. Bunlar platform mekanizmalarıdır; ölçülmüş yüksek erişilebilirlik sonucu veya hazır SLA değildir.
Probe ve trafik davranışı
Startup probe migration ve başlangıç tamamlanmasını; readiness database ve etkin storage erişimini; liveness ise yalnız sürecin ilerleyebildiğini ölçmelidir. Bağımlılık kesintisi pod'u yeniden başlatma döngüsüne sokmak yerine readiness ile trafikten çıkarmalı, liveness eşiği geçici PostgreSQL/S3 kesintisinden ayrılmalıdır.
Veri ve platform ön koşulları
Tüm application replica'ları aynı PostgreSQL doğruluk durumuna ve aynı artifact içeriğine erişmelidir. S3-compatible shared storage veya gerçekten ortak RWX filesystem kullanılmalı; node-local volume çoklu replica için ortak storage kabul edilmemelidir.
- PostgreSQL failover, connection timeout ve pool yeniden bağlanma davranışı
- Storage endpoint veya mount kesintisinin readiness ve paket isteklerine etkisi
- Ingress'in hazır olmayan pod'u trafikten çıkarma ve uzun upload/download davranışı
- Node/zone dağılımı, kapasite, HPA metriği ve disruption budget'ın birlikte çalışması
- Uzun süren task lease/retry davranışının replica kaybında korunması
- Ortak RWX support-log claim'i üzerinden pod bazlı logların korunması ve Support bundle içinde birleştirilmesi
Dağıtık iş sahipliği
Cleanup, storage transfer, scan evaluation, OSV ve partition-retention işleri kalıcı PostgreSQL durumu ile owner-check'li lease kullanır; her replica kurtarılabilir işleri yeniden dispatch edebilir ancak aynı lease iki worker tarafından yürütülmemelidir. Replica kaybı testinde lease expiry/renewal, resume cursor'ı, duplicate side effect ve terminal audit/operation kaydı birlikte doğrulanmalıdır.
Failover kabul planı
Hedef topoloji üretim sayılmadan önce kontrollü arıza senaryolarıyla ölçülmelidir. Her test başlangıç yükünü, hata enjeksiyonunu, kullanıcı etkisini, recovery süresini, veri bütünlüğünü ve operasyon kanıtını kaydetmelidir.
- Tek application pod ve worker node kaybı
- Ingress controller veya DNS/TLS yenileme kesintisi
- PostgreSQL primary failover ve geçici bağlantı kaybı
- S3 endpoint/RWX mount gecikmesi veya erişilemezliği
- OSV, scan, cleanup ve storage-transfer görevi sırasında replica kaybı
Yayımlanmayan kanıt
Hazır kapasite profili, node sayısı, failover kabul sonucu, RTO/RPO veya SLA yayımlanmış değildir.
Yayınlanabilmesi için gerekli çıktı
Bu sayfanın durumu ancak belirli release/topoloji için tekrarlanabilir yük profili, tarihli failover sonuçları, veri tutarlılığı kontrolleri, ölçülmüş recovery süreleri, kapasite sınırları ve onaylı operasyon sahipliği yayımlandığında doğrulanmış olarak değiştirilebilir.
Kod, chart ve canlı uygulama doğrulaması — 3 Ağustos 2026
Güncel 943c2c6 kaynak kodunda PostgreSQL tabanlı Spring Session, owner-check'li HA job lease/heartbeat, reclaim edilebilir task/scan lease'leri ve shared-storage readiness uygulaması doğrulandı; ilgili hedefli suite 31/31 geçti. Helm lint başarılı oldu ve render çıktısı HPA 3–10, minAvailable 2 PDB, RWX claim'ler, hostname/zone spread, 60 saniye termination grace ve ayrı startup/readiness/liveness probe'larını içerdi. Canlı ortamda bu sağlık uçları UP ve Support yüzeyi erişilebilirdi. Cluster topolojisine erişilmedi ve kontrollü pod/node, PostgreSQL, storage veya ingress arızası uygulanmadı; task lease devri, veri tutarlılığı ve recovery süresi ölçülmedi. Bu nedenle Doğrulama bekliyor durumu korunmuştur.