Vysvetlenie

Odporúčaný prístup: SeaweedFS ako S3 vrstva nad NFS

SeaweedFS je pre tvoj prípad lepší ako MinIO alebo Garage, z týchto dôvodov:

• Malé objekty ukladá do veľkých volume súborov (append), takže na NFS ide pár veľkých súborov namiesto tisícov malých. To je presne to, čo NFS zvláda dobre.
• Má licenciu Apache 2.0 a aktívny vývoj.
• Metadáta filera môžeš dať do PostgreSQL, ktorý už máte, a nemusia byť na NFS.
• Garage potrebuje metadáta (LMDB/SQLite) na lokálnom rýchlom disku a na NFS ich mať nechceš.

Architektúra:

Loki (distributed) ──S3──> SeaweedFS S3 gateway
                              ├─ master  x3  (malé PVC na NFS)
                              ├─ filer   x2  (metadata → PostgreSQL)
                              └─ volume  xN  (PVC na NFS, veľké)

SeaweedFS (Helm, orientačne, kľúče si over vo values.yaml danej verzie chartu):

yaml

master:
  replicas: 3
  defaultReplication: "000"   # NFS už rieši redundanciu, nereplikuj 3x na to isté pole
  data:
    type: persistentVolumeClaim
    storageClass: nfs-sc
    size: 5Gi
volume:
  replicas: 3                  # viac volume serverov = viac paralelného I/O
  dataDirs:
    - name: data
      type: persistentVolumeClaim
      storageClass: nfs-sc
      size: 500Gi
      maxVolumes: 0
filer:
  replicas: 2
  # store → postgres2 cez WEED_POSTGRES2_* env premenné
  s3:
    enabled: true
    enableAuth: true

Ak sa dá, každý volume server nech má PVC z iného NFS exportu alebo inej cesty k poľu. Lepšie tak rozložíš záťaž.

Loki values:

yaml

minio:
  enabled: false
loki:
  storage:
    type: s3
    bucketNames:
      chunks: loki-chunks
      ruler: loki-ruler
      admin: loki-admin
    s3:
      endpoint: http://seaweedfs-s3.seaweedfs.svc:8333
      accessKeyId: ${S3_ACCESS_KEY}
      secretAccessKey: ${S3_SECRET_KEY}
      s3ForcePathStyle: true
      insecure: true
  schemaConfig:
    configs:
      - from: "2024-01-01"
        store: tsdb
        object_store: s3
        schema: v13
        index: { prefix: index_, period: 24h }

Výkon: kde sa reálne vyhráva

1. Cache (memcached) dimenzuj veľkoryso. chunksCache a resultsCache bežia v RAM, takže čím viac dát sa číta z cache, tým menej sa siaha na NFS. Pri NFS backende je to najväčšia páka na query výkon.
2. WAL ingesterov nedávaj na NFS. Fsync na NFS je pomalý. Máš dve možnosti:
   • local-path alebo ephemeral disk nodu (emptyDir) a k tomu replication_factor: 3. Strata dát hrozí len pri súčasnom páde viacerých ingesterov.
   • NFS PVC je bezpečnejšie, ale ingest bude pomalší.
3. Väčšie chunky = menej objektov. Nastav chunk_target_size: 1572864 a max_chunk_age: 2h, vyššie chunk_idle_period.
4. Compactor a retencia. Zapni retention_enabled a rozumnú retenciu, aby bucket nerástol donekonečna.
5. NFS mount options v StorageClass. Odporúčam nfsvers=4.1, rsize/wsize=1048576, hard, noatime a ideálne nconnect=8, ak to kernel na TKG nodoch podporuje.

Migrácia z MinIO

Ak máš v MinIO dáta, ktoré chceš zachovať, prekopíruj ich cez rclone sync minio:loki-chunks seaweed:loki-chunks (a to isté pre ruler a admin bucket) a až potom prepni Loki. Ak ide o nový alebo testovací deployment, stačí prepnúť storage a začať načisto.

Moje odporúčanie: najprv sa spýtaj storage tímu na natívne S3. Ak ho nemajú, nasaď SeaweedFS s filer metadátami v PostgreSQL a WAL ingesterov daj na lokálny disk s RF 3.

Jak to spravit ? 

Postup na zajtra:

bash

# 1. Odinštaluj starý Loki a zmaž MinIO PVC
helm uninstall loki -n loki
kubectl -n loki get pvc            # zmaž export-*-loki-minio-* a staré ingester PVC
kubectl -n loki delete pvc <...>
 
# 2. SeaweedFS
kubectl create ns seaweedfs
kubectl apply -f seaweedfs-s3-secret.yaml
helm repo add seaweedfs https://seaweedfs.github.io/seaweedfs/helm && helm repo update
helm upgrade --install seaweedfs seaweedfs/seaweedfs -n seaweedfs -f values-seaweedfs.yaml
kubectl -n seaweedfs get pods -w

# 3. Buckety
for b in loki-chunks loki-ruler loki-admin; do
  kubectl -n seaweedfs exec seaweedfs-master-0 -- sh -c "echo 's3.bucket.create -name $b' | weed shell"
done
kubectl -n seaweedfs exec seaweedfs-master-0 -- sh -c "echo 's3.bucket.list' | weed shell"

 # 4. Loki
helm upgrade --install loki grafana/loki -n loki -f values-loki-nc.yaml

Čo som zmenil a na čo si dať pozor:

• Storage kľúče v pôvodnom súbore chart ignoroval. Chart chce bucketNames a camelCase kľúče (accessKeyId, s3ForcePathStyle), nie access_key_id. Fungovalo ti to len preto, že minio.enabled: true konfiguráciu prepísal.
• replication_factor: 1 a zoneAwareReplication: false. Chart má default RF 3, takže s 1 ingesterom by zápisy padali. Keď pôjdeš na 3 ingestery, vráť RF na 3.
• maxVolumes: 90 vo SeaweedFS. NFS CSI hlási voľné miesto celého share, nie veľkosť PVC. Bez explicitného limitu by si SeaweedFS mohol zabrať viac, ako chceš.
• Heslo v secrete aj v Loki values musí byť rovnaké. Zmeň ZmenMa-LokiS3-Secret123 na oboch miestach.
• Názov služby. Ak by sa S3 service nevolala seaweedfs-s3, over to cez kubectl -n seaweedfs get svc a uprav endpoint.
• Kľúče v SeaweedFS chart-e. Mám ich podľa aktuálnej štruktúry chartu, ale ak helm niečo odmietne, porovnaj s helm show values seaweedfs/seaweedfs.

Rýchly test po nasadení:

bash

kubectl -n loki logs deploy/loki-distributor | grep -i error
kubectl -n loki logs sts/loki-ingester | grep -iE "s3|flush|error"

PRECO DO PICI TAK ZLOZITO ? 

Nie je to až také zvláštne, len Loki rieši iný problém ako Prometheus. Rozdiel je v architektúre, nie v módnosti.

Prometheus je jeden proces s lokálnym diskom. Jedna inštancia zapisuje do svojho TSDB a nič iné k tým dátam nepristupuje. Preto mu stačí obyčajný disk. Mimochodom, Prometheus NFS oficiálne nepodporuje a dokumentácia výslovne varuje pred poškodením TSDB na ne-POSIX filesystémoch. Že ti to ide, je skôr šťastie. A keď chceš Prometheus škálovať alebo držať dlhú históriu (Thanos, Mimir), skončíš presne pri object storage ako Loki.

Loki v distributed móde je veľa procesov nad tými istými dátami. Ingester zapisuje, querier číta, compactor prepisuje a maže, index-gateway servíruje index. Všetky musia vidieť rovnaké dáta naraz, a to z rôznych nodov. Na to potrebuješ zdieľané úložisko, ktoré zvládne súbežný prístup bez lockov. Object storage je na to najjednoduchší a najlacnejší model, lebo objekty sa nikdy nemenia, len vznikajú a mažú sa.

Logov je rádovo viac ako metrík. Loki šetrí tak, že indexuje iba labely a samotné logy ukladá ako komprimované chunky. Takže potrebuje veľa lacného miesta a vysokú priepustnosť pri čítaní, a to je presne silná stránka S3.

Loki ale vie fungovať aj jednoducho, ako Prometheus. V monolitickom režime (deploymentMode: SingleBinary) beží ako jeden pod s filesystem storage na obyčajnom RWO PVC, bez S3, SeaweedFS aj MinIO. Grafana ho odporúča zhruba do 20 GB logov denne. Obmedzenia sú, že nemáš horizontálne škálovanie ani HA a pri reštarte podu je chvíľu výpadok.

Pre test, alebo ak objem logov nie je veľký, je SingleBinary na nfs-csi-sc úplne legitímna voľba a ušetrí ti celú S3 vrstvu. Distributed so SeaweedFS má zmysel až pri vysokom objeme alebo keď potrebuješ HA.

SINGLE NODE setup

Inštalácia:

bash

helm uninstall loki -n loki
kubectl -n loki delete pvc --all      # staré MinIO/ingester PVC
helm upgrade --install loki grafana/loki -n loki -f values-loki-single.yaml

Na čo si dať pozor:

• Vždy len 1 replika. Pri filesystem storage nesmieš singleBinary.replicas zvýšiť, dve repliky by si prepisovali dáta.
• Všetky dáta sú na jednom PVC. WAL, index aj chunky idú do /var/loki. NFS PVC by malo byť mountnuté s nfsvers=4.1 a hard, nie soft, inak hrozí poškodenie TSDB.
• Veľkosť PVC NFS CSI nevynucuje. Rast dát drží len retencia 720h, takže sleduj zaplnenie share.
• Pri reštarte podu je krátky výpadok. Zápisy sa bufferujú v agentoch (Alloy/Promtail), takže logy sa nestratia.
• Prechod na distributed nie je bezbolestný. Ak budeš neskôr chcieť ísť na distributed so SeaweedFS, dáta sa nedajú jednoducho previesť. Prakticky to znamená začať načisto alebo nechať starý Loki dobehnúť retenciu.