Ana içeriğe atla
Bu kılavuz, tam AgentEye yığınını adanmış bir Kubernetes kümesine dağıtır:
  • ClickHouse 24.8 — kanonik olaylar ve değerlendirmeler analitikleri depolama (100 GiB kalıcı birimli StatefulSet). Gerekli: sunucu bunu olmadan başlamayı reddeder.
  • PostgreSQL 16 — kuruluşlar, API anahtarları, kullanıcılar, panolar, kaydedilmiş sorgular ve kimlik doğrulama için ilişkisel/meta veri depolaması (50 GiB kalıcı birimli StatefulSet)
  • Redis 7.2 — isteğe bağlı paylaşılan önbellek ve hız sınırlama arka ucu; sunucu ve panel kullanılamadığında zarif bir şekilde bozulur
  • AgentEye Sunucusu — olay alımı, analitikleri ve anahtar yönetimi için Rust API (2 kopya)
  • AgentEye Paneli — Next.js web kullanıcı arayüzü (2 kopya)
  • AI asistanı (ajan hizmeti) — isteğe bağlı panel içi salt okunur asistan, 9100 portunda; bir LLM uç noktası yapılandırılana kadar pasif
  • Traefik (genel) — toplayıcı trafiği için giriş denetleyicisi, mTLS ile korumalı
  • Traefik (panel) — panel için giriş denetleyicisi, yalnızca VPN/IP-izin listesi
  • cert-manager — TLS sertifikaları ve mTLS CA
  • Yedekleme CronJob — 03:00 UTC’de PostgreSQL + ClickHouse’un günlük birleştirilmiş dökümü
  • Sertifika Yenileme İzleyicisi — istemci sertifikaları sona ermek üzereyken uyarı gönderir
Tahmini süre: ilk dağıtım için 60-90 dakika. Exosphere’nin tüm bunları sizin adınıza yönettiği yönetilen dağıtım modeli için enterprise-docs/managed-deployment.md bölümüne bakın.

Ön Koşullar

Başlamadan önce her doğrulama komutunu çalıştırın. Her kontrol başarılı olmalıdır.
GereksinimMinimumDoğrulama KomutuBeklenen Sonuç
Kubernetes kümesi1.27+kubectl versionServer Version >= v1.27
Kustomize (kubectl ile paketlenmiş)Kustomize v1.14+ (kubectl 1.27+ içinde bulunur)kubectl kustomize --helpKullanım metni yazdırır
Helmv3helm versionVersion:"v3.x.x"
cluster-admin RBACkubectl auth can-i create namespacesyes
Varsayılan StorageClasskubectl get storageclassEn az bir satır (default) olarak işaretlenmiş
LoadBalancer desteğiBuluta bağlı (EKS, GKE, AKS varsayılan olarak bunu destekler)
GitHub PATecho $AGENTEYE_TOKENBoş olmayan (enterprise-docs/github-token.md bölümüne bakın)
opensslopenssl versionOpenSSL 1.x veya 3.x
Bulut depolama paketiPostgreSQL + ClickHouse yedekleri için (S3, GCS veya Azure Blob)
Küme boyutlandırması: Minimum 3 düğüm, her biri 4 vCPU / 8 GB RAM. Tam gereksinimler için enterprise-docs/managed-deployment.md bölümüne bakın.

Tüm kontrolleri aynı anda çalıştırın

Dağıtım şekli

Alım uç noktası kontrol ettiğiniz bir ana bilgisayar adında sunulur (örn. ingest.your-company.example). cert-manager, Let’s Encrypt’den HTTP-01 üzerinden genel olarak güvenilir bir TLS sertifikası talep eder, bu nedenle toplayıcılar sunucu sertifikasını sistem güven deposuna karşı doğrular ve müşteri başına CA sabitleme yoktur. Panel uç noktası aynı şekilde çalışır: kontrol ettiğiniz ikinci bir ana bilgisayar adında sunulur (örn. agenteye.your-company.example) ve panel Traefik LoadBalancer’ına işaret eder; cert-manager, o LoadBalancer üzerinden Let’s Encrypt sertifikasını yayınlar. Tarayıcılar uyarısız güvenilir bir sertifika alır.
Sertifika yayınlama ve yenileme HTTP-01 üzerinden doğrular, bu nedenle her iki LoadBalancer de genel internetten 80 portu üzerinde erişilebilir olmalıdır. Panel LoadBalancer’ını IP ile kısıtlama yapmanız gerekiyorsa, yenileme sessizce başarısız olmayacağı için öncelikle destek ekibiyle DNS-01 çözücüsü koordine edin ve sertifika sona ermez.

Manifestleri Alın

Test edin:
Beklenen sonuç: dosya var. Yoksa, klonlama başarısız oldu — AGENTEYE_TOKEN öğesini kontrol edin. Dizin yapısı:
Temel, yapılandırdığınız iki genel ana bilgisayar adı için Let’s Encrypt sertifikaları da dahil olmak üzere tam bir dağıtım için gereken her kaynağı içerir. Bir kaplama, belirli bir ortam için temeli yamaları (örn. özel görüntü etiketleri, kaynak sınırları, env kablolama). Üçüncü taraf dizini harici altyapı için Helm değerleri dosyalarını içerir.
Sağlık izleme (isteğe bağlı): sunucunun hazırlık sondası zaten Postgres + ClickHouse sağlığını yansıtır ve third-party/robusta/, Slack’e opt-in Kubernetes native pod-hata uyarısı ekler. enterprise-docs/health-monitoring.md bölümüne bakın.

Aşama 1 — Üçüncü Taraf Altyapısı (~30 dk)

1.1 cert-manager’ı kurun

cert-manager, HTTPS için TLS sertifikalarını ve mTLS istemci sertifikaları için kullanılan özel CA’yı yönetir.
Test edin:
Beklenen sonuç: 3 pod tümü Runningcert-manager, cert-manager-cainjector, cert-manager-webhook.
Beklenen sonuç: en az certificates.cert-manager.io, clusterissuers.cert-manager.io, issuers.cert-manager.io. Başarısız olursa: CrashLoopBackOff içindeki pod’lar genellikle CRD’lerin yüklenmediği anlamına gelir. --set crds.install=true ile yeniden çalıştırın. Webhook pod’ları hazırlık kontrolünde başarısız olursa, 30 saniye bekleyin ve tekrar kontrol edin — başlamak biraz zaman alabilir.

1.2 Traefik’i kurun — Genel Alım Denetleyicisi

Bu Traefik örneği, harici bir LoadBalancer’da toplayıcı trafiğini işler. TLS’yi sonlandırır ve alım uç noktasında mTLS (istemci sertifikası doğrulama) uygular.
Test edin:
Beklenen sonuç: 1 pod Running.
Beklenen sonuç: IngressClass var (varsayılan sınıf değildir). Başarısız olursa: kubectl describe pod -n traefik-public <pod-name> ile görüntü çekme hataları veya kaynak kısıtlamaları kontrol edin.

1.3 Traefik’i kurun — Panel Denetleyicisi

Bu Traefik örneği, panel’i IP izin listesi ile sınırlandırılmış adanmış bir LoadBalancer’da sunar.
Bu örnek için iki izin listesi mekanizması verilir. Bu kılavuz values-dashboard.yaml kullanır ve erişimi taşınabilir service.loadBalancerSourceRanges alanı ile kısıtlar. Parallel values-internal.yaml da AWS ortamları için sağlanır ve bunun yerine service.beta.kubernetes.io/aws-load-balancer-source-ranges ek açıklamasını tercih eder. Birini seçin ve tutarlı kullanın; aşağıdaki adımlar values-dashboard.yaml olduğunu varsayar.
Kurmadan önce, izin verilen kaynak IP’lerini ayarlamak için third-party/traefik/values-dashboard.yaml öğesini düzenleyin. loadBalancerSourceRanges alanı, hangi IP’lerin panele erişebileceğini kontrol eder. Varsayılan olarak 0.0.0.0/0 (tüm IP’ler) olarak ayarlanır; bunu VPN, ofis veya bilinen çıkış IP’lerinize kısıtlayın.

Tek bir IP’yi izin listesine ekleyin

Birden fazla IP’yi izin listesine ekleyin

Her IP veya CIDR bloğu için bir giriş ekleyin. /32 soneki tek bir IPv4 adresini eşleştirir; CIDR bloğu (örn. /24) bir aralığı eşleştirir. Tek tek IP’leri ve aralıkları serbestçe karıştırabilirsiniz:
Listeyi korurken ipuçları:
  • Her satırda bir giriş tutun ve her IP’nin sahibini veya amacını tanımlayan kısa # yorumu ekleyin; gelecekteki operatörlerin bir giriş hala gerekli olup olmadığını belirlemek için kullandığı şey budur.
  • Her zaman CIDR gösterimini kullanın. 203.0.113.10 gibi çıplak IP, bulut sağlayıcı tarafından reddedilir; 203.0.113.10/32 kullanın.
  • IPv6 aralıkları için eşdeğer /128 (tek adres) veya daha büyük CIDR’ı kullanın, örn. 2001:db8::1/128. Tüm bulut sağlayıcılar IPv6 kaynak aralıklarını desteklemez; sağlayıcınızın LoadBalancer belgelerine bakın.
  • Liste bir VEYA’dır: trafik, kaynak herhangi bir giriş ile eşleşirse izin verilir.
Dosyayı düzenledikten sonra aşağıdaki helm install adımına gidin. Denetleyici zaten kuruluysa, aynı bayraklarla helm upgrade çalıştırın veya çalışma zamanında Service’i yamalayın (sonraki bölüm).

İzin listesini çalışma zamanında güncelleyin

Helm yükseltmesi yapıştırmadan, Service’i doğrudan yamalayarak izin verilen IP’leri değiştirebilirsiniz. Yama tüm listeyi değiştirir; yalnızca yenisini değil, tutmak istediğiniz her IP’yi dahil edin. Listeyi yeni bir IP seti ile değiştirmek için:
Mevcut girişleri kaybetmeden bir IP’yi güvenli bir şekilde eklemek için, önce geçerli listeyi okuyun, sonra birleştirilmiş küme ile yamalayın:
Çalışma zamanı yamaları values-dashboard.yaml öğesine geri kaydedilmez. Değişikliği gelecekteki Helm yükseltmeleri arasında tutmak için değerleri dosyasını da güncelleyin ve işleyin.
Sonra kurun:
Test edin:
Beklenen sonuç: 1 pod Running.
Beklenen sonuç: IngressClass var.

1.4 LoadBalancer’ları bekleyin

Devam etmeden önce her iki Traefik örneğinin harici IP’leri olması gerekir.
Test edin: Her iki service de EXTERNAL-IP gösterir (<pending> değil). Hala beklemede ise, atamayı izleyin:
IP göründükten sonra Ctrl+C tuşuna basın. IP ataması tipik olarak 2-5 dakika alır. Başarısız olursa: 10 dakika sonra <pending> genellikle bulut sağlayıcının LoadBalancer sağlayamadığı anlamına gelir. Kontrol edin: alt ağ etiketleri (EKS kubernetes.io/role/elb gerektirir), VPC yapılandırması, hizmet kotaları ve iç LB ek açıklamasının iç örnek için ayarlandığını kontrol edin.

Aşama 2 — Gizlilikler Oluşturun (~10 dk)

Tüm gizlilikler, uygulama dağıtılmadan önce el ile oluşturulur. Bu, hassas değerlerin hiçbir zaman manifest dosyalarında görünmemesini sağlar.

2.1 Ad alanını oluşturun

Test edin:
Beklenen sonuç: durum Active.

2.2 Görüntü çekme gizliliği

Bu gizlilik, ghcr.io ile doğrulama yapar ve AgentEye kapsayıcı görüntülerini çeker. PAT’ınızı nasıl oluşturacağınız hakkında enterprise-docs/github-token.md bölümüne bakın.
Test edin:
Beklenen sonuç: kubernetes.io/dockerconfigjson. Test edin (derin) — jetonu yapabilir doğrula gerçekten görüntüleri çeker: Kaplamanızda kustomization.yaml dosyasında sabitlenen server görüntü etiketini kullanın (şu anda hem paketlenmiş acme kaplamasında hem de temel dağıtımda v0.0.1-beta.48). Bu kontrol sürümler arasında kaymaması için aşağıdaki etiketi dağıttığınız etiket ile değiştirin:
Beklenen sonuç: günlüklerde ok yazdırıldı. Başarısız olursa: ErrImagePull veya 401 Unauthorized PAT’ın geçersiz olduğu veya read:packages kapsamından yoksun olduğu anlamına gelir. enterprise-docs/github-token.md öğesini yeniden kontrol edin.

2.3 PostgreSQL kimlik bilgileri

Önemli: -hex (değil -base64) kullanarak parolayı oluştururuz. Base64 çıkışı +, / ve = içerebilir ve bu da DATABASE_URL bağlantı dizesini bozar. Ayrıntılar için enterprise-docs/troubleshooting.md bölümüne bakın.
POSTGRES_PASSWORD öğesini hemen gizli yöneticiye depolayin. Yedekten geri yüklerseniz veya doğrudan veritabanına bağlanırseniz buna ihtiyacınız olur.
Test edin:
Beklenen sonuç: gizlilik var.
Beklenen sonuç: 48 (24 hex bayt = 48 karakter).

2.4 Yönetici API anahtarı

Yönetici anahtarı bootstrap kimlik bilgisidir. Sunucu, her başlangıçta tüm izinleriyle bunu upsert eder. 3. Aşama’da kapsam alınmış toplayıcı anahtarları oluşturmak için kullanın. Tam izinler modeli için enterprise-docs/api-keys.md bölümüne bakın.
ADMIN_KEY öğesini hemen gizli yöneticiye depolayin.
Test edin:
Beklenen sonuç: gizlilik var.

2.5 Kimlik doğrulama yapılandırması (panel girişi)

Panel, kullanıcı girişi için e-posta + OTP kullanır. Bu gizlilik olmadan sunucu hala başlar ve ADMIN_KEY API yolu çalışır, ancak hiçbir kullanıcı UI üzerinden giriş yapamaz. Tüm anahtarlar temel manifestte optional: true olarak başvurulur, bu nedenle kısmi gizlilikler (veya hiç gizlilik) iyidir; sunucu belgelenen varsayılanlara geri döner. Her şeyi bir agenteye-auth gizliliğine bundleme, yetkilendirme yüzeyinin tek bir yerde döndürülebilir olmasını sağlar.
AnahtarAmaç
ADMIN_EMAILBootstrap yönetici kullanıcısı. Her başlangıçta tüm izinlerle oluşturulur ve dashboard aracılığıyla silme/izin düzenlemelerinden korunur. Olmadan hiçbir yönetici tohumlanmaz ve ilk giriş imkansızdır.
ALLOWED_EMAILSVirgülle ayrılmış izin listesi. Tam adresleri (user@example.com) ve alan adı joker karakterlerini (*@example.com) destekler. Olmadan hiçbir kullanıcı giriş yapamaz veya oluşturulamaz.
SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, SMTP_FROMOTP kodları göndermek için SMTP röle. SMTP_HOST ayarlanmazsa, OTP kodları gerçek e-posta teslimatı yerine sunucunun stdout’una kaydedilir (ilk başlangıç sigara testleri için yararlı). Gerçek e-posta teslimi için tüm SMTP anahtarlarını birlikte sağlayın.
SMTP_TLSstarttls (varsayılan), tls veya none birisi.
DEFAULT_ORG_NAME, DEFAULT_ORG_SLUGİsteğe bağlı. Yerleşik default kuruluşa dostça bir görüntü adı ve URL slug’u verin, böylece örn. /default yerine /acme adresinde yaşasın. Slug 1-40 küçük harfli alfasayısal ile tek iç tire olmalıdır. Her iki tarafı da ayarlı bırakın jenerik default öğesini tutmak için.
SMTP kimlik bilgilerini gizli yöneticiye depolayin.
Test edin:
Beklenen sonuç: doldurduğunuz anahtarlar çıkışta görünür.

2.6 Çok kiracılı org izolasyon anahtarı (isteğe bağlı)

Tek kiracılı bir dağıtım için bunu atlayın; sunucu yerleşik bir geliştirme varsayılanında çalışır ve bir default org’u iyiyse sunmaktadır. İkinci bir kuruluş oluşturmadan önce, güçlü, kararlı bir ORG_CH_SECRET ayarlayın: her org’un ClickHouse parolası HMAC(ORG_CH_SECRET, org_id) olarak türetilir, bu nedenle genel olarak bilinen geliştirme varsayılanı genel olarak türetilebilir per-org kimlik bilgileri sağlayacaktır. agenteye-orgctl org create komutu (§7.6 Sağlama kuruluşları bölümüne bakın) sunucu hala yerleşik geliştirme varsayılanında iken çalışmayı reddeder.
Sunucu bunu isteğe bağlı bir secretKeyRef üzerinden okur, bu nedenle asla oluşturmayan tek kiracılı bir küme hala normal şekilde başlar. Değeri kararlı ve tüm çoğaltmalar arasında özdeş tutun; döndürme her org’un türetilmiş ClickHouse parolasını geçersiz kılar ve bu yapı zamanı yeniden sağlanması tüm çoğaltmalar arasında değer tutarlı olduğunda iyileştirir (kararlı bir değerle kayan bir yeniden başlatma işlemi bunu iyileştirir). deploy/base/server/secret.example.yaml bölümüne bakın.
ORG_CH_SECRET öğesini gizli yöneticiye depolayin ve sırası olmadan döndürmeyin.

2.7 Tüm gizlilikleri doğrulayın

Beklenen çıkış (herhangi bir varsayılan gizlilik arasında):
Dört temel gizlilik (agenteye-admin-key, agenteye-auth, agenteye-image-pull, agenteye-postgres) devam etmeden önce mevcut olmalıdır. agenteye-org-ch-secret yalnızca çok kiracılı dağıtımlar için gereklidir (bkz. §2.6).

Aşama 3 — Uygulamayı Dağıtın (~5 dk)

3.1 Genel ana bilgisayar adlarını yapılandırın

cert-manager, Let’s Encrypt sertifikalarını istemeden önce alım ve panel ana bilgisayar adlarına ihtiyaç duyar. Şablonu kopyalayın ve her ikisini ayarlayın:
domain.env gitignore edilir; her dağıtıma yerel kalır. Kustomize yapı, eğer herhangi bir anahtar eksikse sessizce başarısız olur.
DNS önce çözümlenmelidir. LB’leri henüz işaret etmek zorunda değilsiniz (Aşama 1.2 tamamlanana kadar yoklar), ancak 3.2 adımında ACME yayını her ana bilgisayar adı LoadBalancer’ına çözümlenene kadar yeniden dener. Şimdi DNS ayarlayabilir (Aşama 1.4’te yakalanan LB ana bilgisayar adlarını kullanarak) veya devam edin ve kayıtları Aşama 4’te ekleyin.

3.2 Manifestleri uygulayın

Taze bir yükleme için tabanı doğrudan uygulayın veya bu ortam için bir kaplamayı kestiyseniz (kaplamalar görüntü etiketlerini, env değişkenlerini ve kaynak sınırlarını sabitler; temel sertifikalarını ve yönlendirmesini devralırlar):
Kaplamalar tabanı otomatik olarak içerir; birini uygulayın, her ikisini değil.

3.3 Pod’ları bekleyin

Bekleme, veri düzlemi pod’larına kapsama alınır. İsteğe bağlı agent (AI asistanı) ve redis pod’ları onlarla birlikte başlar; asistan LLM uç noktasını sağlayana kadar pasif kalır (enterprise-docs/assistant.md bölümüne bakın) ve Redis, en iyi çalışma şansı yapan bir önbellektir, bu nedenle ne platform’un trafik sunmasına hazır olması gerekir. Test edin:
Beklenen sonuç (isteğe bağlı agent ve redis pod’ları da görünür ve Running öğesine ulaşır):
Başarısız olursa:
Pod DurumuMuhtemel NedenHata Ayıklama Komutu
ImagePullBackOffKötü görüntü çekme gizliliği veya PATkubectl describe pod <name> -n agenteye
CrashLoopBackOffKötü ortam değişkenleri (örn. DATABASE_URL)kubectl logs <name> -n agenteye
PendingYetersiz CPU/bellek veya düğüm yokkubectl describe pod <name> -n agenteye (Olayları kontrol edin)

3.4 Depolamayı doğrulayın

Beklenen sonuç, her ikisi de Bound durumuyla:
PVCKapasiteYedekler
postgres-data-postgres-050GiPostgreSQL ilişkisel/meta veri depolaması
clickhouse-data-clickhouse-0100GiClickHouse olayları + değerlendirmeler analitikleri depolaması
İsteğe bağlı önbellek için bir redis-data-redis-0 PVC (1Gi) de görünür. Başarısız olursa: Pending anlamına gelir StorageClass ses seslerini sağlayamaz. kubectl get storageclass öğesini kontrol edin ve varsayılan bir tane olduğundan emin olun. Üretim için, ClickHouse birimini hızlı bir SSD StorageClass’a yerleştirin (örn. AWS’de gp3, GCP’de pd-ssd); kompaksiyon verimlilik yavaş diskler üzerinde zarar görür.

3.5 Sertifikaları doğrulayın

Beklenen sonuç: 3 sertifika, tümü Ready: True:
AdİhraçcıAmaç
mtls-caselfsignedmTLS istemci sertifikaları yayınlayan özel CA (10 yıl geçerlilik)
ingest-tlsletsencrypt-prodAlım uç noktası için genel TLS sertifikası (90 gün, otomatik yenilenmiş)
dashboard-tlsletsencrypt-prodPanel için genel TLS sertifikası (90 gün, otomatik yenilenmiş)
Eğer ingest-tls veya dashboard-tls Ready değilse: kubectl describe certificate <name> -n agenteye çalıştırın ve Olayları okuyun. Yaygın nedenler:
  • DNS henüz LB’ye işaret etmiyor. Let’s Encrypt, ana bilgisayar adını çözümler ve doğrulamak için 80 numaralı porta çarpar — INGEST_DOMAIN genel LB’ye, DASHBOARD_DOMAIN panel LB’ye çözümlenmelidir. CNAME/Diğer ad yayılana kadar, sipariş pending kalır. DNS doğru olduktan sonra, cert-manager otomatik olarak yeniden dener (Sertifika’yı silmeye gerek yok).
  • Ana bilgisayar adı yerine konmamış. dnsNames hala INGEST_DOMAIN_PLACEHOLDER / DASHBOARD_DOMAIN_PLACEHOLDER okuyorsa, 3.1. adımı atlattınız — base/certificates/domain.env öğesini oluşturun ve yeniden uygulayın.
  • Dashboard Traefik, zorluk sunmıyor (dashboard-tls sadece). Panel Traefik örneği, paketlenmiş değerler dosyasıyla kurulmalıdır (Aşama 1.2), cert-manager’ın HTTP-01 çözücüsünü sunan kapsama alınmış Ingress sağlayıcısını etkinleştirir. Olmadan kurulu bir örnek, zorluk yönlendirilemez ve sipariş pending sonsuza kadar kalır.
Eğer mtls-ca Ready değilse: cert-manager kendisi sağlıksızdır. Aşama 1.1’den cert-manager pod’larını yeniden kontrol edin.

3.6 CronJob’ları doğrulayın

Beklenen sonuç:
AdZamanlamaAmaç
agenteye-backup0 3 * * *03:00 UTC’de günlük Postgres + ClickHouse yedeklemesi
cert-renewal-check0 3,15 * * *03:00 ve 15:00 UTC’de sertifika sona erme uyarıları

3.7 Sunucunun doğru şekilde başlatıldığını doğrulayın

Test edin: Sunucunun 8080 portunda dinlediğini gösteren bir başlangıç satırı arayın. Veritabanı bağlantısı hataları olmamalıdır (sunucu Ready raporlamadan önce PostgreSQL ve ClickHouse’a erişilebildiğini gerektirir). Başarısız olursa: En yaygın neden, DATABASE_URL öğesini kıran POSTGRES_PASSWORD içinde URL-güvenli olmayan karakterlerdir. enterprise-docs/troubleshooting.md bölümüne bakın.

3.8 Panel’in sunucuya bağlandığını doğrulayın

Test edin: Çıkışta ECONNREFUSED veya benzer hatalar olmadan Ready arayın. Başarısız olursa: server Service’in var olup olmadığını kontrol edin (kubectl get svc server -n agenteye) ve AGENTEYE_SERVER_URL panel dağıtımında http://server:8080 olarak ayarlandığını kontrol edin.

Aşama 4 — Ağ Erişimi (~5 dk)

4.1 LoadBalancer adreslerini alın

AWS EKS’te LoadBalancer’lar IP yerine ana bilgisayar adı döndürür. Yukarıdaki komutlarda .ip öğesini .hostname ile değiştirin.
Test edin:
Her ikisi de boş olmayan olmalıdır.

4.2 DNS’i LoadBalancer’lara işaret edin

base/certificates/domain.env öğesinden ana bilgisayar adlarının LoadBalancer’larına çözümlenecek şekilde DNS kayıtları oluşturun — INGEST_DOMAIN genel Traefik LB’ye, DASHBOARD_DOMAIN panel Traefik LB’ye:
  • AWS Route 53: Alias = Yes ile A kaydı, hedef = LB ana bilgisayar adı. Düz A → IP kullanmayın; ELB IP’leri döner.
  • Başka herhangi bir sağlayıcı: Ana bilgisayar adından LB ana bilgisayar adına CNAME.
Doğrulayın:
Sırasıyla $PUBLIC_IP ve $INTERNAL_IP ile aynı adres döndürmelidir (veya EKS’te aynı *.elb.amazonaws.com ana bilgisayar adlarına çözümlenmelidir). DNS çözümlendikten sonra, cert-manager 3.5. Aşamadaki beklemede olan ACME siparişlerini bir dakika içinde tamamlar. Hem ingest-tls hem de dashboard-tls Ready: True gösterin kadar kubectl get certificates -n agenteye öğesini yeniden çalıştırın.

4.3 Alım uç noktasına ulaşın

Genel alım uç noktası karşılıklı TLS’yi uygular, bu nedenle her istek (/health dahil) istemci sertifikası sunmalıdır. İlk istemci sertifikasını 5. Aşama’da yayınlarsınız; zaten birini varsa, şimdi erişilebilirliği doğrulayın:
Beklenen sonuç: {"status":"ok"}. -k gerekmez — sunucu sertifikası INGEST_DOMAIN için genel bir CA’ya zincirler, bu nedenle sistem güven deposuna karşı doğrulanır. Raw LoadBalancer IP/ana bilgisayar adı tarafından değil, INGEST_DOMAIN ana bilgisayar adı (sertifika ile eşleşen) tarafından alım uç noktasına ulaşın. Panel uç noktası, genel olarak güvenilir bir sertifika ile DASHBOARD_DOMAIN öğesinde sunulur ve mTLS arkasında değildir, bu nedenle -k ve istemci sertifikası yoktur:
Raw LB adresinden değil, ana bilgisayar adı tarafından panele ulaşın — sertifika DASHBOARD_DOMAIN öğesine bağlanır, bu nedenle ham adres sertifika adı uyuşmazlığı gösterir. Başarısız olursa: curl asılı kalırsa, LB’nin makinenizden erişilebildiğini kontrol edin (VPN, güvenlik grupları, güvenlik duvarı kuralları). Alım ana bilgisayar adında certificate required el sıkışma hatası, hiçbir istemci sertifikasının sunulmadığı anlamına gelir; önce 5. Aşama’yı tamamlayın. Alım ana bilgisayar adında TLS doğrulama hatası, sunucu sertifikasının henüz bitmemiş olduğu anlamına gelir; 3.5. Aşamaya geri dönün ve orada sorunu çözün.

Aşama 5 — mTLS İstemci Sertifikaları Yayınlayın (~10 dk her küme)

Toplayıcılar iki faktör ile kimlik doğrulama yapar: istemci sertifikası (taşıma katmanı, isteğin yetkili bir kümeden geldiğini kanıtlar) ve API anahtarı (uygulama katmanı, isteğin events:add izni olan bir toplayıcıdan geldiğini kanıtlar). Sızan anahtar sertifika olmadan işe yaramaz; çalınan sertifika geçerli anahtar olmadan işe yaramaz.

5.1 Sertifika yayınlayın

Toplayıcıları çalıştıran her kümenin kendi istemci sertifikasına ihtiyacı vardır. Manifest dizininden:
<cluster-name> öğesini anlamlı bir tanımlayıcıyla değiştirin (örn. us-east-1-prod, staging). Test edin: Komut ==> Done! yazdırır ve çıkış dosyalarını listeler.
Beklenen sonuç: Ready: True. issued/<cluster-name>/ içindeki çıkış dosyaları:
DosyaAmaç
client.crtİstemci sertifikası (90 gün geçerlilik)
client.keyİstemci özel anahtarı
ca.crtSunucu doğrulaması için CA sertifikası
collector-mtls-secret.yamlToplayıcı kümesi için uygulamaya hazır Kubernetes Gizliliği

5.1b Alternatif teslimat: AWS Gizlilikler Yöneticisi

Sertifikanın tüketeni diskten client.crt ve client.key gereken bir Kubernetes Pod’u ise — uygulamayı uygulama pod’ında kenar aracı olarak çalıştırdığınızda tipik durum — sertifika paketini AWS Gizlilikler Yöneticisi’ne itin. Uygulama pod’u ardından Gizlilikler Depolama CSI Sürücüsü üzerinden IRSA ile bunu takar ve sertifika döndürme tamamen uygunsuz.
Yeniden çalıştırıldıktan sonra (yenileme), komut dosyası aynı gizlilik üzerinde PutSecretValue öğesini çağırır, bu nedenle ARN ve ad kararlı kalır. CSI Sürücüsü, döndürme yoklama aralığını seçer ve dosyaları pod’un içinde yeniden yazar. Önkoşullar:
  • aws CLI v2 AWS hesabınıza kimlik doğrulama.
  • jq yüklü.
  • AWS_REGION ortam değişkeni ayarlandı.
  • Arayanızın kimliğinde IAM izinleri (Resource arn:aws:secretsmanager:<region>:<account>:secret:agenteye/mtls-client/* kapsamı):
    • secretsmanager:CreateSecret
    • secretsmanager:DescribeSecret
    • secretsmanager:PutSecretValue
    • secretsmanager:TagResource
Komut dosyası bu modda ne yapar:
Adımİşlem
1Cert-manager aracılığıyla sertifikayı yayınlar / yeniden çıkarır (varsayılan mod gibi).
2agenteye/mtls-client/<cluster-name> üzerinde DescribeSecret öğesini çağırır ve oluştur-vs-güncelle’ye karar verir.
3İlk çalıştırmada: CreateSecret öğesini üç tuşlu JSON yükü (client.crt, client.key, ca.crt) ile, etiketli AgentEyeCluster=<cluster-name>. Sonraki çalıştırmalarda: yeni sürüm yayınlamak için PutSecretValue; etiket TagResource aracılığıyla yenilenir.
4Başarılı yükleme sonrasında issued/<cluster-name>/ adresini siler. Herhangi bir başarısızlıkta, dizin korunur, böylece yeniden deneyin.
Gizlilik silme işaretlenmişse, komut dosyası size yeniden denemeden önce aws secretsmanager restore-secret --secret-id agenteye/mtls-client/<cluster-name> çalıştırmanız gerektiğini söyleyen açık bir hatayla başarısız olur. Tam pod kablolama (SecretProviderClass, IRSA kurulumu, döndürme davranışı, sorun giderme) için enterprise-docs/single-pod-deployment.md bölümüne bakın.

5.2 Sertifikanın çalıştığını doğrulayın

Verilen sertifikayı mTLS giriş tablosuna karşı test edin:
Beklenen sonuç: {"status":"ok"} Başarısız olursa:
HataNedenÇözüm
certificate requiredSertifika sunulmuyorcurl komutundaki dosya yollarını kontrol edin
bad certificateCA uyuşmazlığıSertifikanın mtls-ca-issuer tarafından yayınlandığını doğrulayın: kubectl describe certificate mtls-client-<name> -n agenteye
connection refusedYanlış ana bilgisayar adı veya LB erişilemez/etc/hosts veya DNS’i kontrol edin

5.3 Toplayıcı kümesine teslim edin

collector-mtls-secret.yaml öğesini toplayıcı kümesini işleten ekibe gönderin. Bunu uygularlar:
Sonra toplayıcıyı gizliliği takmak ve sertifika yollarını kullanmak için yapılandırın:
Kubernetes birim bağlamalarını içeren tam toplayıcı kurulumu için enterprise-docs/collector-installation.md bölümüne bakın. Test edin (toplayıcı kümesinde):
Beklenen sonuç: 3 veri anahtarı (client.crt, client.key, ca.crt) ile gizlilik var.

5.4 Sertifika yaşam döngüsü

ÖzellikDeğer
İstemci sertifika geçerliliği90 gün
Otomatik yenilemecert-manager sona ermeden 15 gün önce yeniler
CA geçerliliği10 yıl
Sona erme uyarılarıCronJob sona ermeden 30 gün önce uyarı gönderir (Aşama 6)
cert-manager, AgentEye kümesinde sertifikayı otomatik olarak yeniler, ancak yenilenen sertifika toplayıcı kümesine yeniden teslim edilmelidir. issue-client-cert.sh öğesini yeniden çalıştırın ve eski sertifika sona ermeden önce collector-mtls-secret.yaml öğesini yeniden uygulayın. --save-to aws-secrets-manager kullanıyorsanız (bkz. § 5.1b), aynı komutu yeniden çalıştırın. Komut dosyası aynı gizlilik üzerinde PutSecretValue öğesini çağırır; pod’lar Gizlilikler Depolama CSI Sürücüsü aracılığıyla gizliliği taksa, sonraki döndürme yoklaması (varsayılan: her saat) yeni sürümü seçer, pod yeniden başlatması gerekmez.

5.5 Sertifikayı iptal edin

Bir kümenin toplayıcı erişimini hemen engellemek için:
Test edin: 5.2. adımdan curl komutu artık TLS el sıkışma hatası ile başarısız olur.

Aşama 6 — Sertifika Yenileme İzlemesi (~2 dk)

Yerleşik bir CronJob, her 12 saatte bir (03:00 ve 15:00 UTC) çalışır ve agenteye.io/cert-type=mtls-client ile etiketlenmiş tüm istemci sertifikalarını kontrol eder. Herhangi bir sertifika sona ermesine 30 gün kaldığında uyarı gönderir.

6.1 Slack bildirimlerini etkinleştirin (isteğe bağlı)

Bu gizlilik olmadan, CronJob hala çalışır ve sertifika durumunu stdout’a kaydeder. Test edin:
Beklenen sonuç: gizlilik var.

6.2 CronJob’u test edin

Beklenen sonuç: sertifikaların ve sona erme durumlarının bir listesi. Slack web kancası yapılandırılmışsa, Slack kanalında uyarı mesajını kontrol edin. Başarısız olursa: RBAC’ı kontrol edin — CronJob’un ServiceAccount’u cert-manager Certificate kaynaklarında get, list izinlerine ihtiyaç duyar. Şu komutla doğrulayın: kubectl describe role cert-renewal-check -n agenteye. Test işini temizleyin:

Aşama 7 — Uçtan Uca Doğrulama

Bu aşama, tüm işlem hattının çalıştığını doğrular: sağlık kontrolü, anahtar oluşturma, olay alımı ve panel görüntüsü.
Not: Aşağıdaki örnekler, alım uç noktasına ham LoadBalancer adresi (${PUBLIC_IP}) tarafından ulaşır; bu nedenle -k geçerler; sunucu sertifikası INGEST_DOMAIN öğesine bağlanır, host adı değil, INGEST_DOMAIN LB IP’ye bağlanır, bu nedenle ana bilgisayar adı kontrol atlanır. Alım uç noktası her yola mTLS uygular, bu nedenle her çağrı istemci sertifikası (--cert/--key) da sunmalıdır. Genel sertifikayı da doğrulamak için https://ingest.your-company.example/... yerine ${PUBLIC_IP} öğesini hedefleyin ve -k kaybı düşürün.

7.1 Sağlık kontrolü

Beklenen sonuç: HTTP 200 ile {"status":"ok"}.

7.2 Kapsamlı toplayıcı anahtarları oluşturun