Ana içeriğe geç

Edge instance'lar

"Edge instance" DT Edge Platform'un DB'sinde kaydettiğiniz bir Kubernetes cluster'ı temsil eden bir satırdır. Satır DT Edge Platform'dan o cluster'ı yönetmeye yetecek state'i tutar — ama cluster'ın kendisini değil.

Satırda ne var​

  • Identity — name, description, opsiyonel categories, telemetry_id (bu edge'in metric + log'larını bu satıra bağlayan UUID)
  • Ownership — org_id (public edge'ler için NULL)
  • kubeconfig — master AES-GCM key ile şifreli
  • Status — active / in_progress / failed
  • Health — healthy / degraded / unreachable / unknown, artı son prob timestamp'i + hata mesajı
  • Provisioner link — bu edge upstream Provisioner üzerinden oluşturulduysa provisioner_cluster_id

Satırda olmayan şey: per-edge Prometheus / OpenSearch / Grafana URL'leri. Observability sistem seviyesinde merkezi yapılandırılır; per-edge isolation telemetry_id üzerinden metric label seviyesinde olur.

İki oluşturma yolu​

Upload kubeconfig (her zaman mevcut)​

Cluster zaten var. Bir kubeconfig yapıştırırsınız; DT Edge Platform şifreler + saklar; erişilebilirliği onaylamak için prob çalıştırır; durumu active'e flip eder.

%99 zaman kullanacağınız yol bu, kendi elinizle provision ettiğiniz cluster'lar, cloud k8s servislerinden cluster'lar (GKE / EKS / AKS) ve başka tool tarafından provision edilen edge cluster'lar dahil.

Provision new cluster (yapılandırılmışken)​

DT Edge Platform upstream Provisioner servisini bir VM IP listesinden yeni bir k3s cluster spawnlamak için çağırır. Provisioner SSH üzerinden ansible çalıştırır; bittiğinde DT Edge Platform'u cluster.ready ile webhook'lar ve DT Edge Platform kubeconfig'i fetch eder.

Bu yol sadece admin sistem ayarlarında provisioner_url + admin key yapılandırdığında yüzeylenir. Onsuz UI'da görünmez.

Kubeconfig şifrelemesi size ne verir​

  • DB'de at-rest — kolon kubeconfig_enc bytea, AES-GCM ciphertext. Plaintext kubeconfig SQL üzerinden okunamaz.
  • Bellek içinde — sadece ona ihtiyaç duyan request handler içinde decrypt edilir (helm install, health prob vs), hemen kullanılır, disk'e yazılmaz.
  • UI'da — asla. "kubeconfig'i göster" butonu yok; kullanıcılar edge hakkında metadata görür ama altta yatan kimlik bilgilerini değil.
  • Audit log'da — sanitised. Her mutasyonu kaydeden middleware kubeconfig field'larını saklamadan önce strip eder.

Master key (ENCRYPTION_KEY env) rotate edilirse her şifreli column re-encryption gerektirir — bkz. backend operations docs. Casually değiştirmeyin.

telemetry_id — stabil identifier​

Her edge BeforeCreate'te mint edilen bir telemetry_id UUID alır. Bu UUID:

  • Her edge cluster'ının Prometheus'undaki remote-write config'i tarafından yazılan label, DT Edge Platform'un central Prometheus'unun query'leri scope etmesi için
  • Her edge cluster'ında fluent-bit tarafından eklenen field, DT Edge Platform'un central OpenSearch'ünün log query'lerini scope etmesi için
  • Backend'in PromQL alarm query'lerine enjekte ettiği matcher, org X için bir alarm kuralının org X'in edge'lerine scope edilmesi için

Neden UUID, name değil? Çünkü name düzenlenebilir. staging-cluster'i staging-cluster-deprecated'e yeniden adlandırırsanız eski isme pinned her Grafana sorgusu ve alarm kuralını bozmamak istersiniz. UUID asla değişmez.

telemetry_id'yi düzenlemeye admin drawer'ında prominent uyarı ile izin verilir — sadece kontrollü migration sırasında yapın. "Ne bozulur" footprint'i geniştir.

Public vs org-scoped​

org_id IS NULL bir edge'i public yapar — install hedefi olarak her org'a görünür.

  • Public edge'ler admin-published'tır. Yalnızca super-admin'ler oluşturabilir ve yalnızca aktif lisans MaxPublicEdges > 0 taşıdığında. Paylaşılan altyapı için faydalı (her ekibin deploy yapabileceği bir dev/test cluster).
  • Org-scoped edge'ler (yaygın durum) bir org'a aittir. Sadece o org'un üyeleri görür.
  • Release ownership ayrı takip edilir: helm_release_snapshots.installed_by_org_id her release'i hangi org'un kurduğunu kaydeder. Public edge'te Org A'nın release'leri Org B'ye görünür (ki isimde tesadüfen çakışmasınlar) ama sadece Org A onları mutate edebilir.

Sağlık prob'ları​

Periyodik bir background job (varsayılan 30 dakikada bir) her edge'in apiserver'ını prob eder:

  • /version + /api/v1/nodes çağırır
  • Kaydeder: response time, kube version, total node count, ready node count, varsa hata mesajı
  • health_status + last_checked_at + last_health_error günceller

Prob'lar kullanıcının iznine ihtiyaç duymaz — DT Edge Platform olarak çalışırlar. Başarısızlıklar edge'i unreachable olarak damgalar, listede kırmızı rozet olarak yüzeylenir.

Başarısız bir prob başka şeyi bozmaz. Edge veritabanında kalır; bir sonraki prob (veya manuel recheck) onu geri çevirebilir. Erişilemez bir edge'e karşı operation'lar denediğinizde "timeout" yerine daha faydalı bir hatayla yüksek sesle fail eder.

Bir edge'i kaldırdığınızda​

  • DB satırı soft-delete olur (deleted_at set)
  • Edge install dropdown'larında ve listelerde görünmemeye başlar
  • Gerçek cluster'daki helm release'lere dokunulmaz. DT Edge Platform sadece onları yönetmeyi bırakır. Onları temizlemek istiyorsanız cluster'da direkt helm uninstall kullanın.
  • Bu edge'e bağlı alarm kuralları yetim hale gelir (telemetry_id matcher'ları canlı bir şeyle eşleşmez). Edge kaldırdıktan sonra alarmları gözden geçirin.
  • Fleet capacity snapshot'ı kaldırmayı bir sonraki aggregator pass'inde (~15 dk) yansıtır — bkz. Nasıl yapılır: fleet quota exceeded'i çöz.

Ayrıca bakın​